Suite question souvent posee sur forum.
bnAdd et bnDiv dans dll version C et ASM.
Differents dossiers dans zip pour chaque version.
Prog VB demo fait par EBArtSoft, merci pour lui.
bnDiv prend 1er param en Byref, autre en Byval.
Txt joint explique.
Je retire une choses, que je vient de remarquer de très étranges ! Un bug après la compilation sous VB .EXE
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
J’ajoute quelque commentaire, puisque cela fait déjà 1 an que je fait des dll pour VB sous me même style !
...
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 !
Il faut dans ce cas faire un fichier Makefile (documente toi sur Internet si tu ne connaissais pas) et posséder dans son kit de développement l'outils make (c'est un programme qui va interpréter le contenu de ton fichier Make et effectuer diverses actions).
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...
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...
++
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.