Comparer VB6.exes

Question

Nous menons un projet de migration massif à la minute actuelle et nous essayons de valider le code déployé sur le domaine actif qui correspond au code que nous avons dans le contrôle de code source.

Évidemment, le code .net est facile à comparer car nous pouvons le désassembler. Je ne crois pas que cela soit possible dans les exe vb6 à cause du mode de compilation.

Quelqu'un at-il une idée de la façon dont je pourrais valider le code source et que l'exécutable compilé correspond au fichier que j'ai dans Live?

Merci

Answer 1

Visual Basic disposait de deux méthodes de compilation, l’une pour l’interprète (appelée P-code), permettant ainsi d’obtenir des fichiers binaires plus petits, et l’autre, générant le mot-clé "normal". fichier Windows .exe (appelé natif) qui a été introduit car il était censé être plus rapide que p-code; bien que la taille du fichier compilé ait augmenté avec cette option. Si votre compilation utilisait p-code, il est théoriquement possible de restaurer les sources.

Bien que ce soit assez difficile à faire, mais il existe des outils qui prétendent pouvoir le faire en partie, un que je connaisse (jamais essayé, mais il existe une version d'essai) est VB-decompiler http://www.vb-decompiler.org/

Answer 2

Malheureusement, c'est presque impossible. N'oubliez pas que le code VB6 compilé sur différentes machines aura des tailles d'exe et des exigences de déploiement différentes.

C’est pourquoi les anciens utilisateurs de VB’ers disposaient d’une machine dédiée pour compiler leur code.

Answer 3

Cela ne vous aidera pas avec les éléments déjà déployés, mais si vous augmentez le numéro de révision à chaque compilation (un paramètre de projet vous permet de le faire automatiquement), vous pourrez facilement comparer les numéros de version.

Answer 4

Mon ancienne société a acheté une copie de ce VB-Decompiler et, comme indiqué précédemment, VB5 / 6 génère un extra-code P, cet outil produisait du code et, dans le cas contraire, du code d'assemblage pouvant être "lu".

Answer 5

Si vous avez tout le code que vous avez compilé, vous pouvez comparer les CRC de ce code à ce qui est déployé sur le terrain. Mais si vous ne possédez pas le code compilé d'origine, en fonction de la manière dont vous l'avez compilé (si vous utilisez du code P plutôt que du code natif, vous pourrez peut-être désassembler mais le désassemblage ne ressemblera en rien à votre code source). Je doute que vous ayez fourni les PDB avec les exes, mais si vous le faisiez, vous pourriez certainement les utiliser pour les comparer au code source de votre référentiel.

Answer 6

Ayez un ordinateur de confiance capable de vérifier les différentes bibliothèques et exes que vous créez et de les compiler automatiquement. Gardez ceux-ci dans un endroit accessible en lecture seule. Effectuez ensuite une comparaison binaire entre le site déployé et votre site de comparaison.

Cependant, je ne suis pas sûr de la logique de désassemblage des unités conformes. Mon entreprise et la plupart des endroits que je connais utilisent une combinaison d’ordinateur de construction et de tests unitaires. Dans notre société, l’EXE que nous fabriquons est un shell très fin recouvrant de nombreuses bibliothèques. Par exemple, un clic de bouton sera transmis à une DLL UI Active X qui effectue le traitement réel. Après une compilation, nous exécutons un fichier EXE spécial qui exécute notre liste de tests unitaires. S'ils réussissent tous, nous savons que nos bibliothèques, où 90% de notre code est, sont bonnes. En ce qui concerne l’EXE actuel, nous avons une procédure manuelle qui prend environ deux heures, puis tout va bien. Il est rare que des erreurs se produisent dans le fichier EXE.