Letzte Woche habe ich beschrieben, wie man aus .dsw-Dateien die Projektabhängigleiten grafisch darstellen kann. Der Code für dieses kleine Projekt kann aber nur die Abhängigkeiten eines Projekts darstellen, wie von den Entwicklern einmal so festgelegt wurde. Das Problem ist aber, daß sich mit der Zeit üblicherweise die Abhängigkeiten ändern, etwa durch Ergänzung neuer header oder libraries. Gerade wenn man so gefährliche Pseudo-Zeitsparfeatures von VC wie

#pragma comment (lib)

verwendet, passiert sowas schnell 'mal. Mit Glück wird dann ein einzelnes Projekt in einem dsw-File im Rahmen eines Komplettbuilds dann allenfalls über die alphabetische Reihenfolge korrekt gebuildet. Das ist für einen daily build zwar noch akzeptabel, aber für einen Maintenance-Entwickler nicht gerade das "warm and fuzzy feeling", das er braucht, um zu wissen, daß er keinen Rebuild von Allem (wie im daily build) für eine unschuldige kleine Änderung in einem Source File braucht.

Also, was kann man tun, wenn die Abhängigkeiten in einem .dsw-File mit 139 dsp-Files drin hoffnungslos verwahrlost sind und hinten und vorne nicht stimmen? Ganz einfach: Die Abhängigkeiten über einen korrekten daily build bestimmen. Die Abhängigkeiten sind nämlich - da staunt der Fachmann und der Laie wundert sich - just kidding! - natürlich auch in den gebuildeten Dateien versteckt. Schließlich muß ja der Loader von NT auch wissen, gegen welche Dateien ein PE-Binary implizit linkt. Diese Informationen kann man sich mit Hilfe eines der Schweizer Offiziersmesser einer jeden Visual C-Installation beschaffen, mit dumpbin.exe.

So kann man sich mit

dumpbin /imports dateiname

Die Importe der Datei dateiname anzeigen lassen und so ist in den letzten beiden Tagen am Feierabend und in der Mittagspause ein Tool entstanden namens bindep.exe, das man hier runterladen kann. Es geht davon aus, daß dumpbin über die Environment-Variable PATH gefunden wird und ruft für ein per Kommandozeile anzugebendes Verzeichnis für eine beliebige Anzahl von Wildcard-Patterns den dumpbin auf. Das Outputfile ist auch über die Kommandozeile anzugeben und ist natürlich ein dot file, das man dann dem dot-tool aus den Graphviz-Tools von AT&T einfüttern kann, so wie in meinem Posting von letzter Woche beschrieben. Man ruft das Tool also beispielsweise so auf:

bindep c:\windows c:\temp\hudel.dot /r *.exe *.dll

Diese Kommandozeile startet dieses Tool und läßt es rekursiv für alle EXE- und DLL-Dateien in c:\windows das dot file c:\temp\hudel.dot erzeugen. Dabei werden diejenigen Dateien, die per Delayload gelinkt werden, mit einer grauen Verbindungslinie gemalt, ansonsten in Schwarz. Das Ergebnis schaut dann beispielsweise für ein XP-System so aus.

Weil das Ganze aber natürlich sehr unübersichtlich werden kann, besteht auch die Möglichkeit, einzelne Dateien von der Betrachtung auszuschließen. Zu diesem Zweck legt man eine Textdatei an und gibt auf jeder Zeile den Namen einer auszuschließenden Datei an. Diese Datei nennt man excfile.txt und legt sie in dasselbe Verzeichnis wie die Datei bindep.exe. Für das eigene Softwareprojekt schreibt man also da die üblichen Verdächtigen wie kernel32.dll, advapi32.dll, user32.dll, etc.. und sieht dann nur noch die Abhängigkeiten seiner eigenen Exe-Dateien und DLLs untereinander. Für mein allseits beliebtes SUperior SU kommt dann beispielsweise sowas raus:

Wenn man nun noch einzelne Verzeichnisse vom Durchsuchen ausschließen will, macht man dasselbe wie mit der Datei excfile.txt aber nennt die Datei excdirs.txt und schreibt da die absoluten Pfade für nicht zu untersuchende Directories rein.

DISCLAIMER: Der Code in dem hier verlinkten Projekt ist lausig, schlimm und schlecht. Es ist eine üble Melange aus K&R-C, MFC, nicht abgefangenen Fehlern und Exceptions. Das ist nicht die Art und Weise wie ich Code schreibe, wenn man mich dafür bezahlt. An dieser Stelle halte ich mich an meinen treuen, braven Depp-uty der hier sagen würde: Der Proof-Of-Concept reicht!

Hinweis: Wer wirklich das Ganze für eine Windows-Installation ausprobieren will, sollte eine halbwegs neue Version von dumpbin verwenden, beispielsweise den von Visual Studio 2005. Der dumpbin von VC6 hat Probleme mit Binaries von neueren OS-Versionen.