AJOUTER DES FONCTIONS A VB6 (ETUDE, ASSEMBLEUR X86, COMPILATION)
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
16 nov. 2003 à 00:02
mone et pock Messages postés 14 Date d'inscription lundi 29 décembre 2003 Statut Membre Dernière intervention 3 janvier 2004 - 1 janv. 2004 à 10:55
mone et pock Messages postés 14 Date d'inscription lundi 29 décembre 2003 Statut Membre Derniè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.
https://codes-sources.commentcamarche.net/source/17964-ajouter-des-fonctions-a-vb6-etude-assembleur-x86-compilation
https://codes-sources.commentcamarche.net/source/17964-ajouter-des-fonctions-a-vb6-etude-assembleur-x86-compilation
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