exe-Dateien unterscheiden sich bei jedem build

[HHick123]

Hallo Leute, ich hab' schon wieder eine "lästige" Frage ;-)

Und zwar verwende ich, um die Versionen meiner Projekte zu verwalten, ein einfaches (aber meiner Meinung nach sehr nützliches) Compare-Tool (Beyond Compare).

Einen Haken hat die Sache jedoch: Wenn ich ein Delphi-Projekt bei identischen Sourcen neu kompiliere, dann unterscheidet sich die exe-Datei jedesmal ziemlich hinten in wenigen bytes. Ich vermute, da wird eine build-versionsnummer oder ähniches hineingepackt. Das ist natürlich ungünstig bezüglich des Compare-Tools....

Kann man das Delphi 6 (oder Turbo Delphi 2006 - da weiss ich momentan nicht, ob es auch auftritt) irgendwie ausreden???

Viele Grüße,
Helmut

[Luckie]

Hast du denn die Option "Buildnummer automatisch erhöhen" aktiviert?

[himitsu]

der Compiler baut ja auch noch andere Dinge ein ... z.B. die Compilierungszeit und diese ändert sich ja bekanntlich ständig :stupid:

[rwachtel]

Zitat:

Zitat von himitsu

der Compiler baut ja auch noch andere Dinge ein ... z.B. die Compilierungszeit [...]

Kannst Du das belegen?

[Luckie]

Reicht eine Funktion zum Auslesen selbiges?
http://www.michael-puff.de/Developer...TimeStamp.html

[rwachtel]

Zitat:

Zitat von Luckie

Reicht eine Funktion zum Auslesen selbiges? [...]

Perfekt, danke.

[sakura]

Zitat:

Zitat von Luckie

Reicht eine Funktion zum Auslesen selbiges?
http://www.michael-puff.de/Developer...TimeStamp.html

Nö :mrgreen:

...:cat:...
P.S.: Sorry, konnte ich mir gerade einfach nicht verkneifen :duck:

[Codewalker]

Theoretisch könnte man doch mit solchen Funktionen auch erkennen, in welcher Programmiersprache ein Programm entwickelt wurde, oder?

[himitsu]

Zitat:

Zitat von Codewalker

Theoretisch könnte man doch mit solchen Funktionen auch erkennen, in welcher Programmiersprache ein Programm entwickelt wurde, oder?

dazu gibt es auch schon einige Threads hier. jede Sprache hat ja ihre Eigenheiten und man kann somit "einfach" prüfen, ob bestimmte Strukturen vorhanden sind.

[ErazerZ]

Anhand der ersten Bytes beim EntryPoint kann man auch "leicht" herausfinden um welchen Compiler oder Execrypter es sich handelt.
Delphi erstellt auch zum Beispiel auch als einziger Compiler einige Resourcen die immer vorhanden sind bei jedem Programm. Diese können jedoch leicht gelöscht werden und somit ist das nicht sicher.

[HHick123]

Zitat:

Hast du denn die Option "Buildnummer automatisch erhöhen" aktiviert?

Ist nicht aktiviert...
Inkludiert der jetzt wirklich die Compilierungszeit? Wozu soll den das zum Kukuck gut sein?
Kann man das irgendwie verhindern? Vermutlich muß ich damit leben, oder?

[Luckie]

[quote="HHick123"]

Zitat:

Inkludiert der jetzt wirklich die Compilierungszeit? Wozu soll den das zum Kukuck gut sein?

Weil es eine nützliche Information ist.

Zitat:

Kann man das irgendwie verhindern?

Wahrscheinlich nicht, zumindest habe ich dafür noch keinen Schalter gefunden.

Zitat:

Vermutlich muß ich damit leben, oder?

Ja.

[rwachtel]

Zitat:

Zitat von Luckie

Zitat:

Zitat von HHick123

Inkludiert der jetzt wirklich die Compilierungszeit? Wozu soll den das zum Kukuck gut sein?

Weil es eine nützliche Information ist.

Sagt wer? Oder ist das ein Dogma?

[Vjay]

Nun theoretisch, sofern es die Compilierungszeit ist, könntest du diese nachträglich gefahrlos aus X-en. Dazu musst du dir halt ein Programm schreiben, welches sich nach der Compilierung die Exe vornimmt. Glaube neuere IDEs können dies von sich aus für ältere braucht mein irgend ein jbg-Tool um dies zu automatisieren.

[Luckie]

Zitat:

Zitat von rwachtel

Zitat:

Zitat von Luckie

Zitat:

Zitat von HHick123

Inkludiert der jetzt wirklich die Compilierungszeit? Wozu soll den das zum Kukuck gut sein?

Weil es eine nützliche Information ist.

Sagt wer?

Sag ich.* ;)
*) Ob es da durch zu einem Dogma wird, sei mal dahingestellt. :mrgreen:

[HHick123]

Ok, nützlich ist es eventuell um festzustellen, ob der Kunde irgendwo die Sourcen geklaut hat und selbst kompiliert hat, andererseits war ich noch nie in der Verlegenheit, das prüfen zu wollen,

was ich aber halt schon öfters gebraucht hätte, wäre, schnell anhand der .exe festzustellen, ob die Version beim Kunden eh die ist, die ich gerade auf meinem PC kompiliere...

[Meflin]

Zitat:

Zitat von HHick123

was ich aber halt schon öfters gebraucht hätte, wäre, schnell anhand der .exe festzustellen, ob die Version beim Kunden eh die ist, die ich gerade auf meinem PC kompiliere...

Und wofür meinst du gibt es Versions- und Buildnummern :gruebel:

[Luckie]

Nö, es ist nützlich, wenn du wissen willst, was für eine Version der Kunde. Man kann zwar die Buildnummer automatisch hochzählen lassen, aber was, wen du kein Build ausgeliefert hats, sondern nur einfach kompiliert hast? Mit dem Datum weißt du immer von wann das Kompilat ist.

Zitat:

Zitat von HHick123

was ich aber halt schon öfters gebraucht hätte, wäre, schnell anhand der .exe festzustellen, ob die Version beim Kunden eh die ist, die ich gerade auf meinem PC kompiliere...

Und geanu da kann dir eben das Datum helfen.

[rwachtel]

Argh, das machen vielleicht Hinterhofkellerbudensoftwareschrauber aber bitte doch nicht profesionelle Softwareentwickler...

Sehr lesenswert dazu die schon einige Jahre(!) alten Artikel von Joel Spolsky:

The Joel Test: 12 Steps to Better Code
Daily Builds Are Your Friend

Mit modernen Continuous-Integration-Tools sind doch auch flexible, schnelle kundenspezifische Änderungen ein Kinderspiel.

[HHick123]

Zitat:

Und wofür meinst du gibt es Versions- und Buildnummern

Ja ich weiss schon, für was die gut sind.
Aber irgendwie find ich die Möglichkeiten der Versionsnummern ziemlich schwach, da sie wieder von mir abhängen, nämlich dass ich nicht vergesse, sie zu erhöhen. Die Buildnummer ist ja auch nur eine Hausnummer, weil ich je nach Gegebenheiten die Sourcen auf verschiedenen PCs kompiliere. Ausserdem hängt es wieder von mir ab, ob' ich sie erhöhen lasse oder nicht.
Den Sinn des Datums verstehe ich nicht ganz, da bräuchte ich ausserdem einen Kalender, indem genau steht an welchem Tag um welche Uhrzeit ich komiliert habe. Und was sollte ich mir dazunotieren? Jedes geänderte Zeichen? Das mach ich sicher nicht!

Ok, man könnte natürlich ein Versionsverwaltungssystem verwenden.

Man stelle sich folgendes Scenario vor:
Ich verschiebe ein Projekt über das Netzwerk auf den Zielrechner (was bei manchen Projekten bei unserem Firmennetzwerk schon gelegentlich eine Stunde dauern kann, öfters geht mit Testdaten zusammen in die zig-GB). So. Dann geh' ich in den entsprechenden Raum. Dort merk ich, irgendetwas passt nicht mit der dortigen Hardware oder Programmen von anderen zusammen. Ok. Ich ändere etwas. Dann komm' ich drauf, das war's nicht und ändere es wieder zurück. Jetzt kompiliere ich wieder. Der andere ändert z.B. seine Software oder die Hardware und es funktioniniert. Ich vergesse die ganze Sache und arbeite an etwas anderem.
Einige Zeit später komm' ich dorthin zurück, weil ich ein Feature einbauen soll. So. Welche Version hab' ich nun vor mir? Ich werfe ein Compare-Tool an und Vergleiche das Projekt mit meinem Referenz-Code auf meinem Arbeitsplatz-PC. Ok, es ist gleich, bis auf die .exe (die nehme ich vom Vergleich aus).
-> Schön wär's jetzt natürlich, wenn das ganze Verzeichnis bei gleicher Funktionalität auch wirklich gleich wäre, weil so hab' ich ja das Restrisiko, dass ich damals vielleicht vergessen haben könnte, zu kompilieren....

P.S.: Nochetwas fällt mir ein: Es wäre nicht schlecht, wenn es eine Möglichkeit gäbe, die .dcu-Dateien etc. nach dem Kompilieren automatisch zu löschen, sodass durch das Kompilieren wirklich nur die .exe entsteht, dann könnte man noch besser vergleichen (die stören mich auch regelmäßig beim Vergleich)...

[rwachtel]

Zitat:

Zitat von HHick123

Zitat:

Und wofür meinst du gibt es Versions- und Buildnummern

Ja ich weiss schon, für was die gut sind.
Aber irgendwie find ich die Möglichkeiten der Versionsnummern ziemlich schwach, da sie wieder von mir abhängen, nämlich dass ich nicht vergesse, sie zu erhöhen. Die Buildnummer ist ja auch nur eine Hausnummer, weil ich je nach Gegebenheiten die Sourcen auf verschiedenen PCs kompiliere. Ausserdem hängt es wieder von mir ab, ob' ich sie erhöhen lasse oder nicht. [...]

Himmel, mit einem vernünftigen Build-Management und dem Einsatz von Continuous-Integration-Tools steht man doch gar nicht erst vor solch einem Problem. Versions-, Revisions- und Buildnummern werden dann z.B. zentral und automatisch verwaltet.

Zitat:

[...] Ok, man könnte natürlich ein Versionsverwaltungssystem verwenden. [...]

Ja, das ist ein Bestandteil.

Zitat:

Man stelle sich folgendes Scenario vor: [Beispiel]

Das ist ein Paradebeispiel für ein unorganisiertes resp. gar nicht erst vorhandenes Build-Management. Wenn ich das im Zusammenhang mit "Firmennetzwerk" lese, rollen sich mir die Fußnägel hoch.

Zitat:

P.S.: Nochetwas fällt mir ein: Es wäre nicht schlecht, wenn es eine Möglichkeit gäbe, die .dcu-Dateien etc. nach dem Kompilieren automatisch zu löschen, sodass durch das Kompilieren wirklich nur die .exe entsteht, dann könnte man noch besser vergleichen (die stören mich auch regelmäßig beim Vergleich)...

Auch das lässt sich mit den entsprechenden Tools realisieren.

[HHick123]

Zitat:

dem Einsatz von Continuous-Integration-Tools

Welches Tool würdest Du denn da konkret vorschlagen?

Zitat:

Zitat:

Man stelle sich folgendes Scenario vor: [Beispiel]

Das ist ein Paradebeispiel für ein unorganisiertes resp. gar nicht erst vorhandenes Build-Management. Wenn ich das im Zusammenhang mit "Firmennetzwerk" lese, rollen sich mir die Fußnägel hoch.

:-D Du wirst es nicht glauben, aber ich hab' einen ganz guten Ruf in der Fira bezüglich der Qualität meiner Programme (das muss ich zu meiner Ehrenrettung sagen). Vielleicht liegt das auch daran, dass ich so ziemlich der einzige bin, der Delphi verwendet...

Ja, ich bestreite ja auch gar nicht, dass ich meine builds nicht manage, denn ich schreibe meine Software so, dass die Funktionalität einfach nicht vom Datum des builds abhängt, sondern nur vom Quellcode. Glücklicherweise hat Delphi ja wenige Compilerschalter und die stehen bei mir halt einfach im Quellcode. Natürlich verwalte ich schon meine Versionen in bezug auf Funktionalität...

:wink: :wink: Ich sag' jetzt lieber nicht, bei welcher Firma ich arbeite, sie ist eh' negativ in den Schlagzeilen, aber: Du solltest erst mal unsere Leute sehen, die Testautomatisierungen mit Perl/Cygwin/MSDOS codieren und ihr Programmpaket - falls man das überhaupt so nennen kann - auf der ganzen Festplatte verstreuen... Da krieg ich echt die Kriese, denn die bekommen es trotz enormem Aufwand nicht hin, das ihr Skript auf mehr als einem einzigen bestimmten PC läuft!! Was das immer für ein Aufwad ist, wenn man es zum Laufen bekommen will... Auch unsere C++-Leute finden es ganz normal, wenn ihre Benutzeroberfläche nach 5-jähriger Enwicklungszeit immer noch laufend abschmiert - letzte Woche erlebt, hab' geglaubt, ich spinne... DIE bräuchten wirklich ein "build management" :lol:

Aber vielleicht brauch ich auch eines und weiss es nur noch nicht... :-D
Lasse mich gerne auf den richtigen Weg bringen...

Viele Grüße,
Helmut

[rwachtel]

Zitat:

Zitat von HHick123

Zitat:

dem Einsatz von Continuous-Integration-Tools

Welches Tool würdest Du denn da konkret vorschlagen?

Vorab erstmal bin ich froh, dass Du meine Kritik nicht in den falschen Hals bekommen hast... ;)

Bei mir ist zentrales Tool der FinalBuilder in der Professional-Version (wegen dem mitgelieferten Server). Was zwar auf der einen Seite daran liegt, dass er sowohl u.a. Delphi als auch .NET-Sprachen unterstützt (ich entwickle in letzter Zeit sehr viel in C#), aber auf der anderen Seite halte ich ihn für eines der leistungsfähigsten Build-/Continuous-Integration-Tools, die noch bezahlbar sind.

Zitat:

:-D Du wirst es nicht glauben, aber ich hab' einen ganz guten Ruf in der Fira bezüglich der Qualität meiner Programme (das muss ich zu meiner Ehrenrettung sagen). Vielleicht liegt das auch daran, dass ich so ziemlich der einzige bin, der Delphi verwendet...

Dass die Qualität Deiner Programme hoch ist wollte ich damit auch gar nicht bestreiten. Man macht sich meiner Meinung nach halt die Arbeit ohne vernünftiges Build-Management selbst schwer. So sind die (wiederverwendbaren) Build-Skripte z.B. so gestaltbar, dass die Änderungskommentare der in die Quellcodeverwaltung eingecheckten Revisionen automatisch in die technische Dokumentation aufgenommen werden.

Ich habe hier z.B. speziell für meine Delphi-Projekte eine virtuelle Maschine auf einem Server laufen, die jede(!) Nacht nach Änderungen im Subversion-Repository schaut und dann nach erfolgreichem Bestehen von Unit-Tests einen Build inkl. aktualisierter Dokumentationen gezippt auf einen FTP-Server ablegt und die entsprechenden Adressaten per eMail informiert. Geht irgendwas schief, bekommen nur die entsprechenden Entwickler eine eMail.

Zitat:

[...] hab' geglaubt, ich spinne... DIE bräuchten wirklich ein "build management" :lol: [...]

Oh ja, das kenne ich nur zu Genüge... ;)

Zitat:

Aber vielleicht brauch ich auch eines und weiss es nur noch nicht... :-D
Lasse mich gerne auf den richtigen Weg bringen...

Wie Joel Spolsky schon sagte: im Prinzip wird es bei professioneller Softwareentwicklung immer gebraucht. Ich persönlich benutze es aber ganz klar hauptsächlich aus Bequemlichkeit: es macht mir die Arbeit leichter und entbindet mich von (wiederkehrenden) unangenehmen und daher gerne (bewusst oder unbewusst) beiseite geschobenen Tätigkeiten, mit anderen Worten: es schafft mir Freiraum (sowohl im Kopf als auch zeitlich). Dass die Qualität der Builds steigt ist dabei ein angenehmer und gern mitgenommener Nebeneffekt... ;)

[HHick123]

Joel Spolsky, der Schöpfer von Excel und Visual Basic ist halt nicht gerade mein Vorbild....
;-) Aber ok...