BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 2 déc. 2012 à 10:47
NON, NON et NON !!!
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.
rebixav
Messages postés130Date d'inscriptiondimanche 16 décembre 2007StatutMembreDernière intervention28 janvier 2013 2 déc. 2012 à 07:34
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
encore désolé pour cette petite erreur
rebixav
Messages postés130Date d'inscriptiondimanche 16 décembre 2007StatutMembreDernière intervention28 janvier 2013 25 nov. 2012 à 20:16
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 !
voilà à plus !
xarier
Messages postés688Date d'inscriptionjeudi 26 décembre 2002StatutMembreDernière intervention19 mai 2005 26 juil. 2004 à 16:04
OKi Merci :)
jockos
Messages postés321Date d'inscriptiondimanche 22 octobre 2000StatutMembreDernière intervention14 mai 20052 26 juil. 2004 à 09:31
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...
++
xarier
Messages postés688Date d'inscriptionjeudi 26 décembre 2002StatutMembreDernière intervention19 mai 2005 25 juil. 2004 à 22:33
Merci je l'ai deja mais le prob c que il faut compiler sous line de command alors pourun porjet qui conteint plusieur fichier .h et .cpp et .rc c deficile (j'ai jamais essayre)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 juil. 2004 à 22:29
au fait j'y pense, tu peux compiler avec les kits gratos en version 2003 telechargeables chez MS.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 juil. 2004 à 22:28
bah si je me souviens bien, la difference etait pas enorme avec la version 2002 mais peut-etre que taille d'exe n'etait pas aussi bonne qu'avec la 2003, faudrait te le procurer.
xarier
Messages postés688Date d'inscriptionjeudi 26 décembre 2002StatutMembreDernière intervention19 mai 2005 25 juil. 2004 à 22:14
Merci mais javait deja tester ca et ca marche pas autre chose l'exe realiser sous vc++6 marche sous win95 et +
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
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 juil. 2004 à 21:46
faut aussi regler les options du compilo.
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.
xarier
Messages postés688Date d'inscriptionjeudi 26 décembre 2002StatutMembreDernière intervention19 mai 2005 25 juil. 2004 à 21:36
DITE J'ai une question je trouve que visual c++7 creé des prog plus gros(espace) que ceux de vc++6 car j'ai compiler le meme prog et c tjr la meme chose exe vc7>vc6 pourtant j'ai mis les deux compilateur en realised :)
jockos
Messages postés321Date d'inscriptiondimanche 22 octobre 2000StatutMembreDernière intervention14 mai 20052 23 févr. 2004 à 16:44
Menu - Project --> Settings... ou Alt+F7
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 21:53
Je n'ai plus de VS 6 depuis longtemps alors...
Devait y avoir un menu sur les options du projet ou tu trouves differents onglets, compilo, linker etc...
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 21:45
C ou kon parametre VC++ pour reduire la taille d'un prog ou d'une DLL?
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 21:12
c'est peut etre possible avec vs.net, mais avec vs6.0, je trouve pas, vous pouvez m'aider?
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 22 févr. 2004 à 20:43
_Jonathan> as tu regardé les fonctions d'un peu plus pres ?
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 ?
@+
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 20:40
Pour cela, voir reponse juste au dessus.
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 20:36
tu connais Dependency Walker for Win32 (Intel x86) ?
j'ai ouvert la DLL C avec,et sa m'indique qu'elle integre des fonctions de kernel32 (ou qu'elle en fait appel).
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 20:32
DLL C ne gere rien du tout. Les imports inutiles sont dus simplement au fait qu'on ne les enleve pas, faisable dans options linker.
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.
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 20:21
Bien sur.
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+
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 19:55
On a tous une idée... ???
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 19:52
En tout cas, l'avantage de l'ASM, c'est qu'il permet de compiler une DLL presque 10 fois plus petite que celle faite en C(++)
Reste a savoir ce que VC++ rajoute a sa DLL.
On a tous une idée...
a+
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 22 févr. 2004 à 17:42
Bonjour,
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 !
@+
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 16:50
A moins d'un compilo plus que exotique, increm une variable doit se faire idem en C ou en asm.
Je pense qu'il y a deja des mesures dans mes sources si je me souviens bien.
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 16:40
Tu pourrais mesurer le temps que met la DLL C/ASM a , par exemple, incrementer une variable 4294967296 fois pour pouvoir comparer la vitesse des 2 language.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 16:35
Vaste sujet qu'il est impensable de traiter ici.
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.
cs_GoldenEye
Messages postés527Date d'inscriptionvendredi 14 septembre 2001StatutMembreDernière intervention 6 octobre 20084 22 févr. 2004 à 16:32
Oui BruNews ça pourrait être intéréssant de monter un comparatif ASM/C à travers un profil d'exécution
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 16:24
Merci bien.
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?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 22 févr. 2004 à 16:22
s@ldon
Messages postés140Date d'inscriptionsamedi 1 novembre 2003StatutMembreDernière intervention30 septembre 20093 22 févr. 2004 à 16:17
utile ce genre de truc pour pouvoir creer un prog en vb qui a besoin de vitesse, genre jeux utilisant D3D.
Petites questions : Quel assembleur tu utilises?
Quel est le meilleur (gratuit ;) )?
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+