Il arrive fréquemment qu'une entreprise doive modifier une application Visual Basic 6 dont elle a perdu le code source : corriger un texte, remplacer un logo, ajuster une fenêtre. Sans les fichiers .frm et .vbp d'origine, la tâche paraît impossible. Elle ne l'est pas — et la raison en dit long sur la façon dont Visual Basic a été construit.
Pourquoi c'est possible
Un exécutable Visual Basic 6 ne contient pas un bloc homogène. La logique y est compilée — traduite en P-Code ou en instructions machine — mais l'interface, elle, n'est pas compilée du tout : elle est décrite. Formulaires, contrôles, propriétés, ressources sont stockés comme des données structurées que le runtime lit au démarrage pour construire les fenêtres.
Or ce qui est décrit peut être relu, et donc réécrit. C'est l'héritage direct de l'origine du langage : le concepteur de formulaires et le moteur Basic étaient deux projets distincts, soudés en 1991, et le compilateur ne les a jamais traités de la même manière.
Le mode d'édition de design
VBReFormer ouvre l'exécutable, reconstruit l'arbre des formulaires et de leurs contrôles, et vous laisse modifier leurs propriétés visuelles — puis réécrit le binaire. Aucune recompilation, aucun environnement VB6 à reconstituer.
C'est d'ailleurs la fonction d'origine du produit. Sur sa plus ancienne page archivée, en octobre 2002, VBReFormer se décrivait exactement comme ceci : « semi-décompilateur permettant de récréer l'aspect visuel d'un projet Visual Basic ». L'édition d'interface n'est pas une fonction ajoutée après coup, c'est le point de départ.
La frontière : ce qui est atteignable et ce qui ne l'est pas
La distinction n'est pas une limite d'outil, c'est la même que celle du paragraphe précédent. Tout ce qui est décrit est modifiable ; tout ce qui est compilé demande autre chose.
Modifiable dans le binaire
- Libellés, titres de fenêtres, textes de boutons
- Images, icônes et ressources embarquées (
.frx) - Position, taille et propriétés des contrôles
- Couleurs, polices et attributs visuels des formulaires
- Entrées de menu
Hors de portée d'une édition d'interface
- Un calcul, une condition, une règle métier
- Le contenu d'un gestionnaire d'événement
- Une requête, un format de fichier, un protocole
- Tout comportement, par opposition à toute apparence
Quand l'édition suffit, quand il faut décompiler
Beaucoup de demandes qui semblent exiger une reprise complète du code n'en ont pas besoin. Autant le vérifier avant de s'engager dans une décompilation.
Le cas le plus courant
Une application interne encore utilisée quotidiennement, dont l'éditeur a disparu et dont le code source n'a jamais été archivé. L'entreprise change de nom, ou une mention légale devient obsolète, et un simple libellé bloque tout un service. C'est le scénario que l'on nous soumet le plus souvent, et c'est précisément celui que l'édition binaire règle sans détour.
Le reste — reconstruction complète du projet, décompilation de la logique — relève d'un autre travail, dont la couverture réelle est publiée avec ses dénominateurs : 1 153 correspondances documentées. Et si vous hésitez encore sur la nature de votre besoin, décompilateur ou désassembleur répond à la question d'avant.
Commencez par ouvrir votre binaire
La version gratuite de VBReFormer ouvre l'exécutable et vous montre l'arbre des formulaires, les contrôles et les ressources. Vous savez immédiatement si votre modification est à portée d'une édition d'interface.
Assurez-vous toujours de détenir les droits nécessaires sur l'application que vous modifiez.