DLL C ET ASM POUR VB
s@ldon
Messages postés
140
Date d'inscription
samedi 1 novembre 2003
Statut
Membre
Dernière intervention
30 septembre 2009
-
22 févr. 2004 à 16:17
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 2 déc. 2012 à 10:47
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 2 déc. 2012 à 10:47
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/20672-dll-c-et-asm-pour-vb
https://codes-sources.commentcamarche.net/source/20672-dll-c-et-asm-pour-vb
2 déc. 2012 à 10:47
En 32 bits, c'est le cas de VB6, il y a 12 octets d'empilés donc on depile 12 octets:
RET 12
Si tu ne l'écris pas, personne ne le fera pour toi.
Avec tout autre code, il n'y a qu'une inconnue, l'heure et/ou jour du plantage mais plantage il y aura.
2 déc. 2012 à 07:34
si vous mettez la procédure vide dll main comme cela :
DLLMAIN PROC
ret
DLLMAIN ENDP
vos programmes vb vont fonctionner, même compiler en .EXE
mais des fois en .EXE (1 chance sur 30 !!!) cela va vous donnez fichier introuvable .dll alors que votre dll est bien là ?!, et que votre programme VB lui fonctionne bien sauf aprés compilation(des fois)
il faut mettre comme cela :
DLLMAIN PROC
mov eax,1
ret
DLLMAIN ENDP
je présume que des fois windows lance cette dll main pour s'assurer qu'il y a un retour eax=1
encore désolé pour cette petite erreur
25 nov. 2012 à 20:16
...
je vous copie colle ce que j'ai écrie pour moi le mois dernier :
; lors d'un test avec des milliers de boucle :
; appelle d'une function VIDE en .BAS compiler exe 0.70s !
; appelle d'une function en .asm compiler en dll et appeler par exe 2.00s !
; donc une procédure dll est presque 3x plus lente au lancement !
; Aussi, si vous faite passé par byref ou byval une string plutôt que de donnée votre pointeur
; à la DLL(sous vb=strptr(a$) ou varptr(ch&), ceci va considérablement ralentir le passage; paramettre, string *10000 2xplus lent,string *100000 4xplus lent,...etc.
; par contre un code assembleur peut être 4 à 5 fois plus rapide qu'un .bas en exe !
; donc ne pas hésiter de faire des dll en .asm pour les procédure un peu gourmande en puissance !
; mais éviter de vouloir faire des procédure trop grosse, elle seront vite difficile
; à faire qu'en VB ! 1 à 2 pages de code ASM suffise !
; en asm dans les procédures on perd moins de vitesse a déclarer les variables
; mais elle ne sont pas mise à 0 !
ensuite il y a peu de temps je n'ai pas remarqué de problème à ecrire comme cela :
DLLMAIN PROC
ret
DLLMAIN ENDP
au lieu de :
DllMain PROC
mov eax, 1
ret 12
DllMain ENDP
...
en faite mes procédures vides sont :
.586
.model flat,stdcall
.code
;-----------------
DLLMAIN PROC
ret
DLLMAIN ENDP
....mes procédures...
end dllmain
...
une de mes procédure exemple :
DIV_PAR_2 PROC EXPORT LE_CHIFFRE:DWORD
mov eax,LE_CHIFFRE
shr eax,1
ret
DIV_PAR_2 ENDP
et puisque je tient cette procédure en main pour répondre au vitesse encore :
sous vb compilé j'ai : 1.82s pour ch&=100/2
alors qu'en lançant cette procédure dll j'ai 1.37s
donc cela va plus vite, oui mais, sous vb on peut aussi
utiliser ch&=100\2 et cela donne 0.15s, et cela donne toujours 50 !
mais lorsque l'on fait : ch2&=2, et toujours dans une boucle =>ch&=100\ch2& cela donne 2,12s !!!
tout cela prouve que le compilateur VB utilise aussi l'idée
de la fonction shr qui décalle les bits pour avoir une division sans virgule ultra rapide !
voilà à plus !
26 juil. 2004 à 16:04
26 juil. 2004 à 09:31
Ainsi, quand tu voudras recompiler tout ton projet, tu n'auras qu'à tapper "make" et si ton fichier MakeFile est bien écrit, tout ton projet sera recompiler (en réalité, uniquement les fichiers qui ont été mis à jour depuis la dernière compilation)...
Bref, document toi un peu sur Make et les fichiers "makefile" si tu ne connaissais pas...
++
25 juil. 2004 à 22:33
25 juil. 2004 à 22:29
25 juil. 2004 à 22:28
25 juil. 2004 à 22:14
prog realiser sous vc++7 marche que sous win200 plus ou il donne certain erreur
certe ca doit venenir des options mais j'ai tous changé et c le meme prob ;( ah pour l'info je utilise vc++7 2002
25 juil. 2004 à 21:46
Clic droit sur le nom du proj dans l'explor de solutions et clic 'proprietes'.
A l'inverse c'est VS 2003 qui peut creer EXEs plus petits.
Par contre toujours privilegier vitesse a la taille.
25 juil. 2004 à 21:36
23 févr. 2004 à 16:44
22 févr. 2004 à 21:53
Devait y avoir un menu sur les options du projet ou tu trouves differents onglets, compilo, linker etc...
22 févr. 2004 à 21:45
22 févr. 2004 à 21:12
22 févr. 2004 à 20:43
c'est juste des fonctions de verification de version et d'allocation
de memoire qui s'execute lors de l'appel de DLLMain.
Cela vient du fait que le compilateur prepare d'eventuel appel a
GetCommandLine, de creation de classe d'objet ou de gestion d'erreur
comme dit BruNews c'est entierement parametrable à partir de visual studio !
Personnellement j'ai vue aucun mot ressemblant a mircrosoft ou windows ou zone51 ! qui sait peut être il y a t'il des instructions caché
dans les mots ?
@+
22 févr. 2004 à 20:40
22 févr. 2004 à 20:36
j'ai ouvert la DLL C avec,et sa m'indique qu'elle integre des fonctions de kernel32 (ou qu'elle en fait appel).
22 févr. 2004 à 20:32
Si tu compares des executables en les editant au notepad, t'es bon pour garder idees et croyances erronees un moment encore.
Desassemble et tu verras ce qu'il y a, de simples segments prepares mais restes vides.
22 févr. 2004 à 20:21
Dans un premier temps, edite au bloc note les 2 DLL.
Tu verras apparaitre dans celle faite avec VC++ le mot runtime assez souvent(la DLL gere les erreurs)
Puis en dessous, on peut voir plein de fonctions de l'api windows(kernel32.dll)
bref, VC++ blinde juste la DLL pour bien montrer qu'elle a été faite avec un truc de microsoft...
voila, alors que la DLL ASM indique juste que la DLL ne peut pas s'executer en mode MS-DOS...
a+
22 févr. 2004 à 19:55
22 févr. 2004 à 19:52
Reste a savoir ce que VC++ rajoute a sa DLL.
On a tous une idée...
a+
22 févr. 2004 à 17:42
Un comparatif de la dll asm et c ne serait que pure perte de temps
car les routines ne represente respectivement que 4 et 15 lignes
pour des actions qui n'ont pas du tout besoin d'optimisation !
en effet on perd bcp plus de cycle lorsque vb appel la fonction
de la dll que dans la fonction elle même !
Pour ce qui est de tester l'incrementation d'une variable pour reprendre ce que disait _Jonathan c'est aussi en pure perte !
l'optimisation se fait toujours au cas par cas et l'emploi de
l'asm se fait souvent sur de petite portion de code. Et l'on
se rend souvent compte que le compilateur a deja pensé
à la meilleur solution !
Pour l'avoir testé je peut affirmer que l'addition d'une
variable de type long se fait exactement de la même
maniere une fois compilé en C/ASM/VB(Code Natif) !
Cela ne signifie pas que tout les language ce valent,
loin de la !
@+
22 févr. 2004 à 16:50
Je pense qu'il y a deja des mesures dans mes sources si je me souviens bien.
22 févr. 2004 à 16:40
22 févr. 2004 à 16:35
Bien en tendu on peut gagner en vitesse ecrit direct en asm mais il faut une longue pratique parce que produire plus mal qu'un compilo moderne arrive tres vite.
22 févr. 2004 à 16:32
22 févr. 2004 à 16:24
Autre question : Quel est l'avantage d'un language tel que l'assembleur face au C?
Y a t-il vraiment une difference de vitesse?
22 févr. 2004 à 16:22
http://www.movsd.com/
C'est celui que j'utilise toujours.
22 févr. 2004 à 16:17
Petites questions : Quel assembleur tu utilises?
Quel est le meilleur (gratuit ;) )?
a+