C'est un scénario que nous voyons chaque semaine : une application Visual Basic 6 tourne en production depuis quinze ou vingt ans, elle est critique pour l'activité — mais son code source a disparu. Le prestataire a fermé, le poste du développeur a été formaté, ou les fichiers .vbp et .frm dormaient sur un serveur qui n'existe plus. Tant que vous avez l'exécutable, tout n'est pas perdu.
Ce que contient réellement un .exe VB6
Un exécutable Visual Basic 6 n'est pas une boîte noire. Il embarque la description de son interface, ses ressources, ses références de composants, et sa logique compilée. Mais ces éléments n'ont pas subi le même traitement, et c'est ce qui détermine ce qu'une récupération peut rendre.
Ce que le binaire a conservé
- Formulaires, contrôles, menus, avec leurs propriétés et leur disposition
- Ressources embarquées : images, icônes, chaînes
- Noms des formulaires, des contrôles et des procédures publiques
- Références aux composants COM, OCX et ActiveX
- Déclarations d'API Win32 : nom de la fonction et bibliothèque
Ce que la compilation a supprimé
- Noms des variables locales
- Noms des procédures et variables privées
- Commentaires
- Constantes et énumérations, repliées à la compilation
- Indentation et mise en forme d'origine
Autrement dit : votre interface revient telle quelle, et votre logique revient sans ses étiquettes. Cette asymétrie n'est pas un défaut d'outillage, elle vient de la façon dont Visual Basic a été construit — le concepteur de formulaires et le moteur Basic avaient des origines séparées, et le compilateur ne les traite pas de la même manière.
Première étape : savoir à quoi vous avez affaire
Avant toute chose, déterminez si votre binaire a été compilé en P-Code ou en code natif. C'est ce qui conditionne la suite, et la réponse est dans le fichier — un champ des structures de description du projet porte le mode de compilation.
Le code natif est le cas le plus fréquent, pour une raison simple : c'était le réglage par défaut du compilateur à partir de Visual Basic 5. Mais les deux se rencontrent, et la distinction change le résultat attendu. Elle est détaillée dans P-Code ou code natif : ce que votre binaire rend.
Si votre besoin est seulement de lire une portion de logique et non de reconstruire un projet, vérifiez d'abord qu'un décompilateur est bien l'outil qu'il vous faut : décompilateur ou désassembleur.
La méthode
.frm, .ctl et .frx. C'est la partie la plus fiable : vous retrouvez vos écrans à l'identique.Ce qui revient, mesuré
Nous publions la couverture réelle du décompilateur plutôt que de la décrire. Les taux ci-dessous sont établis sur un banc de test de 207 programmes, compilés pour exercer le décompilateur sur l'ensemble du jeu d'instructions : 1 446 procédures et 11 836 instructions décodées. Ce corpus mesure la couverture de l'outil, pas la composition du parc installé.
Le détail est public, correspondance par correspondance : 1 153 correspondances documentées, avec pour chacune la fonction ou l'instruction d'origine et ce qui en est produit. Vous pouvez donc vérifier avant d'acheter ce qui sera reconnu dans votre cas.
Commencez par un diagnostic gratuit
La version gratuite de VBReFormer ouvre votre exécutable, identifie son mode de compilation et vous montre l'interface et les ressources récupérables. Vous savez exactement ce qui est récupérable avant de décider quoi que ce soit.
Pour la suite — décompilation du code natif et reconstruction du projet — VBReFormer couvre toute la chaîne. Et si votre besoin se limite à modifier l'interface sans rien reconstruire, c'est possible directement dans le binaire.
Assurez-vous de détenir les droits sur l'application concernée — le cas le plus courant étant la récupération de votre propre logiciel.