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