AJOUTER DES FONCTIONS A VB6 (ETUDE, ASSEMBLEUR X86, COMPILATION)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019
-
16 nov. 2003 à 00:02
mone et pock
Messages postés14Date d'inscriptionlundi 29 décembre 2003StatutMembreDernière intervention 3 janvier 2004
-
1 janv. 2004 à 10:55
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
mone et pock
Messages postés14Date d'inscriptionlundi 29 décembre 2003StatutMembreDernière intervention 3 janvier 2004 1 janv. 2004 à 10:55
Bravo, c'est un super travail!
on en est plus à savoir si c'est util ou pas...c'est excellent
kimmelf2
Messages postés267Date d'inscriptionlundi 22 septembre 2003StatutMembreDernière intervention27 novembre 2005 19 nov. 2003 à 02:51
moustachu> t'as du pot, l'aspirine viens de feter ses 150 ans ! :-D
cs_Kelpan
Messages postés70Date d'inscriptionmercredi 24 avril 2002StatutMembreDernière intervention17 septembre 2006 18 nov. 2003 à 08:31
Interressant et toujours bon à savoir
Bravo
cs_moustachu
Messages postés1079Date d'inscriptionjeudi 14 novembre 2002StatutMembreDernière intervention 1 janvier 2012 17 nov. 2003 à 09:43
J'arrive un peu tard dans le débat, mais il me semble que l'encyclopédie universalis est faite en VB, du moins la version 5. Il y a d'autres applis commerciales en VB (et qui tournent bien...)
En tous cas, bravo EBArtSoft, je suis sûr d'une chose, c'est que j'ai pas tout compris et que ça va encore me faire mal à la tête !!
++
Sirocooo
Messages postés412Date d'inscriptionmercredi 19 décembre 2001StatutMembreDernière intervention 7 avril 20081 17 nov. 2003 à 09:38
c'est de la haute voltige... bravo
Saros
Messages postés921Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention23 septembre 2010 16 nov. 2003 à 19:33
Y'a eu un bug oubliez le machin entre les crochets
Saros
Messages postés921Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention23 septembre 2010 16 nov. 2003 à 19:32
[Oubliez la question d'avant...]
Très joli travail, par contre c'est paradoxal, une fois qu'on s'y connait en ASM, on ne s'attarde plus trop à VB mais plus à C... C'est vrai que la question de la finalité est discutable...
Saros
Afyn
Messages postés608Date d'inscriptionsamedi 3 août 2002StatutMembreDernière intervention22 décembre 2016 16 nov. 2003 à 17:26
Continu dans cette voie, moi ça m'interesse. C'est sur qu'en dissecant le fonctionnement de VB comme tu le fais, tu trouveras des choses intéressantes, et tu en feras profiter la communauté ...
A quand les fonctions in-line en assembleur ou en C ? (style GFA basic)
Parce qu'a ce moment là, VB pourras aller trés vite et restera convivial, ce qui est sa première qualité
Merci pour ton Job
Bravo EB
A+
Afyn
Navedac
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 16 nov. 2003 à 14:10
Vois que je n'attaquais surtout pas le boulot d'EBArtSoft que je trouve tres bon au niveau didactique, c'etait juste pour discuter de la finalite.
ShadowMaster
Messages postés184Date d'inscriptionmercredi 27 novembre 2002StatutMembreDernière intervention18 août 2005 16 nov. 2003 à 14:05
"1) application graphique ne se fait pas en vb" <-LOL quand on veu on peu, il suffit de se creuser la tete comme le fait EBArtSoft (bravo :) ) pour optimisé les applications graphique. A la fin de son travail (tres gros travail) il aura prouvé et contredit deffinitivement la phrase suivante: "application graphique ne se fait pas en vb", c'est a cause de tel propos que la réputation de vb baisse alors que tout probleme a une solution, vb peu jouer dans la cours des grands si un temps soit peu on arrive à "triché".
Voila :) en tout cas je content de voir de tel source qui vont au dela des possibilité "prevu" de vb, encore toute mes felicitation EBArtSoft.
wonesek
Messages postés115Date d'inscriptionsamedi 2 février 2002StatutMembreDernière intervention13 mai 2006 16 nov. 2003 à 13:50
Recentrez le debat les amis, il ne faudrait pas que les commentaires sur cette sources parte en vrille entre pro dot net et irresistible du vb
sur un cd c rien...
mais fo avouer que presque tous les echanges se font via le net...
telecharger.com, p2p, etc... et là, 20Mo ça represente pas mal, surtout pour les 56 à 256kbps...
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 16 nov. 2003 à 13:17
20Mo de run time sur un CD d'install represente quoi ?
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 16 nov. 2003 à 13:00
BruNews> Je ne suis absolument pas d'accord avec toi tout d'abord
vb.net ne peut pas supplenter vb5/6 tout simplement a cause des 20Mo de run time qui l'accompagne et tant que microsoft n'inclura
pas ces run time dans une version de windows il sera tjrs difficile
de le faire avaler au utilisateur.
de plus dire que l'on ne fait pas d'application graphique en vb est une aberation total ... ce site et bien d'autre en sont la preuve vivante.
par contre je suis entierement concient qu'une application commercial
est rarement fait en vb ! c'est vrais
Et pour finir rien ne m'empeche au jour d'aujourd'hui d'appliquer
le meme principe dans un framework .net !
Bref je trouve tes affirmation absure... non vraiement
j'en fait des vrille sur moi meme ! lol
remarque, ya kan meme des fous pour coder des applications graphiques en vb... moi! mdr
mais bon, c tres lent, c clair, et c pas fait dans l'optique d'un freeware, mais juste d'un delire...
bon boulot dans tous les cas!
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 16 nov. 2003 à 10:17
Bien certain que appel vers DLL plus couteux que interne mais 2 raisons me font penser que tes competences sont employees dans ce cas a fond perdu:
1) application graphique ne se fait pas en vb.
2) vb est desormais voue a une mort assez rapide, le passage a .net est inexorable.
cs_EBArtSoft
Messages postés4525Date d'inscriptiondimanche 29 septembre 2002StatutModérateurDernière intervention22 avril 20199 16 nov. 2003 à 01:03
BruNews> tres bonne question, tu pense bien que j'y ai deja pensé
et la reponse, du moin ma reponses est : non ! le resultat n'est
pas le meme pour deux raisons :
1 - On evite l'emploi d'une dll donc on facilite la redistribution
la maitenance, l'installation et le debuggage du prog
2 - Voici le code d'un appel d'api dans vb :
004013D0 56 push esi
004013D1 E8 26 CE FF FF call 003FE1FC
004013D6 8B F0 mov esi,eax
004013D8 FF 15 34 10 40 00 call dword ptr ds:[401034h]
004013DE 8B C6 mov eax,esi
004013E0 5E pop esi
004013E1 C3 ret
ce qui veut dire en gros que pour un appel avec une api vb
va d'abord charger la dll rechercher le point d'entrée de la fonction
puis l'appeler faire des check de stack etc...
dans le cas d'un appel d'API avec une type lib le loader
vas charger les addresses des fonctions et la dll au lancement
du programme puis a chaque appel va pointer la table des import
avant d'appeler la fonctions :
maintenant voici le code d'un appel d'une fonction "'hacker" avec writeprocessmemery, vb va appeler directement la fonction comme
si elle avais été ecrite dans l'ide sans pratiquer aucun teste
004013D0 E8 9B F1 FF FF call 00400570
004013D8 C3 ret
donc on gagne des cycles et dans certain type d'application
comme par exemple une application graphique le moindre
cycle peut faire gagné un temp non negligable
Malheureusement la mise en oeuvre est trop complexe pour pouvoir
etre correctement utilisé... mais je travail justement dans l'optique
de faire qlq chose de digest et utile
@+
spy166
Messages postés207Date d'inscriptionjeudi 21 novembre 2002StatutMembreDernière intervention29 mars 2006 16 nov. 2003 à 01:02
Ouai, c'est intéressant mais bon, je trouve que c'est un peu trop se déchirer pour du vb.
Wazcrack
Messages postés34Date d'inscriptionjeudi 29 mai 2003StatutMembreDernière intervention17 mars 2004 16 nov. 2003 à 00:21
En tout les cas, bravo pour le boulot. Y'en a. Je suis encore au point d'en savoir autant au sujet de VB mais c'est plutot pertinent. Bonne continuation.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 16 nov. 2003 à 00:02
Force est de constater la masse de boulot produite mais a ce point la question de la finalite doit se poser. Booster vb c'est indispensable mais ecrire toutes ces fonctions en C ou ASM et produire une dll ne serait pas moins laborieux pour un resultat au moins egal ?
1 janv. 2004 à 10:55
on en est plus à savoir si c'est util ou pas...c'est excellent
19 nov. 2003 à 02:51
18 nov. 2003 à 08:31
Bravo
17 nov. 2003 à 09:43
En tous cas, bravo EBArtSoft, je suis sûr d'une chose, c'est que j'ai pas tout compris et que ça va encore me faire mal à la tête !!
++
17 nov. 2003 à 09:38
16 nov. 2003 à 19:33
16 nov. 2003 à 19:32
Très joli travail, par contre c'est paradoxal, une fois qu'on s'y connait en ASM, on ne s'attarde plus trop à VB mais plus à C... C'est vrai que la question de la finalité est discutable...
Saros
16 nov. 2003 à 17:26
A quand les fonctions in-line en assembleur ou en C ? (style GFA basic)
Parce qu'a ce moment là, VB pourras aller trés vite et restera convivial, ce qui est sa première qualité
Merci pour ton Job
Bravo EB
A+
Afyn
Navedac
16 nov. 2003 à 14:10
16 nov. 2003 à 14:05
Voila :) en tout cas je content de voir de tel source qui vont au dela des possibilité "prevu" de vb, encore toute mes felicitation EBArtSoft.
16 nov. 2003 à 13:50
en tout cas bonne source, l'idée est de toi EBA?
16 nov. 2003 à 13:36
mais fo avouer que presque tous les echanges se font via le net...
telecharger.com, p2p, etc... et là, 20Mo ça represente pas mal, surtout pour les 56 à 256kbps...
16 nov. 2003 à 13:17
16 nov. 2003 à 13:00
vb.net ne peut pas supplenter vb5/6 tout simplement a cause des 20Mo de run time qui l'accompagne et tant que microsoft n'inclura
pas ces run time dans une version de windows il sera tjrs difficile
de le faire avaler au utilisateur.
de plus dire que l'on ne fait pas d'application graphique en vb est une aberation total ... ce site et bien d'autre en sont la preuve vivante.
par contre je suis entierement concient qu'une application commercial
est rarement fait en vb ! c'est vrais
Et pour finir rien ne m'empeche au jour d'aujourd'hui d'appliquer
le meme principe dans un framework .net !
Bref je trouve tes affirmation absure... non vraiement
j'en fait des vrille sur moi meme ! lol
;-)
@+
16 nov. 2003 à 12:05
mais bon, c tres lent, c clair, et c pas fait dans l'optique d'un freeware, mais juste d'un delire...
bon boulot dans tous les cas!
16 nov. 2003 à 10:17
1) application graphique ne se fait pas en vb.
2) vb est desormais voue a une mort assez rapide, le passage a .net est inexorable.
16 nov. 2003 à 01:03
et la reponse, du moin ma reponses est : non ! le resultat n'est
pas le meme pour deux raisons :
1 - On evite l'emploi d'une dll donc on facilite la redistribution
la maitenance, l'installation et le debuggage du prog
2 - Voici le code d'un appel d'api dans vb :
004013D0 56 push esi
004013D1 E8 26 CE FF FF call 003FE1FC
004013D6 8B F0 mov esi,eax
004013D8 FF 15 34 10 40 00 call dword ptr ds:[401034h]
004013DE 8B C6 mov eax,esi
004013E0 5E pop esi
004013E1 C3 ret
ce qui veut dire en gros que pour un appel avec une api vb
va d'abord charger la dll rechercher le point d'entrée de la fonction
puis l'appeler faire des check de stack etc...
dans le cas d'un appel d'API avec une type lib le loader
vas charger les addresses des fonctions et la dll au lancement
du programme puis a chaque appel va pointer la table des import
avant d'appeler la fonctions :
004013D0 FF 25 00 10 40 00 jmp dword ptr ds:[401000h]
7347AC18 FF 74 24 08 push dword ptr [esp+8]
7347AC1C FF 74 24 08 push dword ptr [esp+8]
7347AC20 6A 00 push 0
7347AC22 E8 F0 53 FF FF call 73470017
7347AC27 8B 04 85 50 FC 39 73 mov eax,dword ptr [eax*4+7339FC50h]
7347AC2E C2 08 00 ret 8
maintenant voici le code d'un appel d'une fonction "'hacker" avec writeprocessmemery, vb va appeler directement la fonction comme
si elle avais été ecrite dans l'ide sans pratiquer aucun teste
004013D0 E8 9B F1 FF FF call 00400570
004013D8 C3 ret
donc on gagne des cycles et dans certain type d'application
comme par exemple une application graphique le moindre
cycle peut faire gagné un temp non negligable
Malheureusement la mise en oeuvre est trop complexe pour pouvoir
etre correctement utilisé... mais je travail justement dans l'optique
de faire qlq chose de digest et utile
@+
16 nov. 2003 à 01:02
16 nov. 2003 à 00:21
16 nov. 2003 à 00:02