Discussion :

[eric_marciano]

Bonjour,
J'ai un code très simple que je compile et link, qui donne donc un premier exe en résultat (en mode release). 2 minutes plus tard, je recompile exactement le même code, ce qui donne un autre exe.
Les 2 exe fonctionnent évidemment de façon identique, leur taille est identique aussi, mais en comparant les 2 fichiers exe on voit qu'il y a quelques octets différents par ci par là (4 différences en tout). Je voudrais bien savoir comment éviter cela. A priori ce n'est pas gênant car le comportement est toujours le même, mais comme je cherche à faire un checksum sur l'exe, le fait qu'il y ait des différences à chaque compilation me dérange fortement.

Savez-vous comment l'éviter?

Pour info, j'ai fait le test avec un petit projet Win32 Console qui affiche juste "Hello World". J'ai laissé les options par défaut qui font que je link avec uuid.lib. Pensant que ça venait de là, j'ai ignoré uuid.lib dans les options de link, mais le problème subsiste...

Toute aide est la bienvenue

Merci,
Eric

[Malinaka]

Bonjour,
Utilises tu un IDE pour faire ton exe? Parfois les IDE peuvent rajouter des en tête. Cela pourrait expliquer les différences.

[eric_marciano]

Bonjour,
Utilises tu un IDE pour faire ton exe? Parfois les IDE peuvent rajouter des en tête. Cela pourrait expliquer les différences.

Ah oui, j'ai oublié de préciser ça: j'ai fait le test avec Visual Studio 2003 et 2008. Dans les 2 cas, quasiment le même résultat.
Et effectivement c'est Visual Studio qui me met par défaut la lib uuid.lib à l'édition de liens.

Eric

[bacelar]

Cela n'a rien à voir avec l'IDE, qui n'est qu'un éditeur amélioré.

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

Ce n'est pas parce que le code source n'a pas changé que le résultat est identique. La configuration du projet, de l'environnement de compilation sont au moins aussi important que le code source.

Normalement, si aucune modification n'est faite dans les sources et dans la configuration des projets, VS ne recompile pas l'exécutable.

Il régénère l'exécutable s'il y a des modifications ou si vous lui forcez la main.
Et à chaque régénération, le linker met un nouveau timestamp.

Cela est extrêmement pratique quand vous utilisez un serveur de symbole et un serveur de code source hébergé dans un gestionnaire de configuration logiciel comme TFS ou ClearCase.

En résumé, si vous travaillez de manière professionnelle, c'est une obligation.

Donc chercher à éviter cette fonctionnalité serait s'interdire d'utiliser tous les outils modernes de traçabilité des codes sources.

Pourquoi le processus de calcul du checksum ne fait-il pas parti intégrante du processus de génération de l'exécutable ?

[eric_marciano]

Cela n'a rien à voir avec l'IDE, qui n'est qu'un éditeur amélioré.

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

Ce n'est pas parce que le code source n'a pas changé que le résultat est identique. La configuration du projet, de l'environnement de compilation sont au moins aussi important que le code source.

Normalement, si aucune modification n'est faite dans les sources et dans la configuration des projets, VS ne recompile pas l'exécutable.

Il régénère l'exécutable s'il y a des modifications ou si vous lui forcez la main.
Et à chaque régénération, le linker met un nouveau timestamp.

Cela est extrêmement pratique quand vous utilisez un serveur de symbole et un serveur de code source hébergé dans un gestionnaire de configuration logiciel comme TFS ou ClearCase.

En résumé, si vous travaillez de manière professionnelle, c'est une obligation.

Donc chercher à éviter cette fonctionnalité serait s'interdire d'utiliser tous les outils modernes de traçabilité des codes sources.

Pourquoi le processus de calcul du checksum ne fait-il pas parti intégrante du processus de génération de l'exécutable ?

Oui, en effet VS ne régénère l’exécutable que parce que je lui force la main. Et je fais cela sans rien changer ni au code, ni aux options de compilation/link. Donc la logique voudrait que l’exécutable soit le même la 2ème fois, au détail près du time stamp dont vous parlez.
Je ne dit pas que cette fonction n'est pas utile, mais dans le cas qui nous occupe, je voudrais la débrayer pour résoudre mon problème bien spécifique à ce projet seulement. Est-ce possible?
En fait, mon projet cible est une DLL qui s'auto-vérifie au moment où elle est chargée pour s'assurer que son code et ses ressources n'ont pas été modifiées. C'est une protection anti-piratage pour éviter que les hackers ne modifient le code de vérification de ma clé. Je sais que ce n'est pas infaillible, mais c'est toujours ça... DOnc s'il y a possibilité de débrayer le time stamp, ou s'il existe un autre moyen d'auto-vérifier la DLL, je suis preneur

Eric

[bacelar]

Pourquoi ne pas exclure le Timestamp de la vérification ?

[Mat.M]

La différence entre les exécutables est très probablement le timestamp de génération que le linker initialise pour avoir une traçabilité correcte des éléments compilés.

il y a fort à parier que cela ça l'explication oui