Derzeit entstehen bei επτ€σ neue DLLs wie nix Gutes. Das ist einerseits etwas Vorteilhaftes, weil dadurch weniger dieser Riesenklötze von Monolithen wie in der Vergangenheit entstehen, andererseits geht schnell aber 'mal der Überblick verloren. So beispielsweise bei der Frage, ob eine DLL auch wirklich an der virtuellen Adresse geladen werden kann, an der sie geladen werden soll. Weil kein Mensch das unmöglich von Hand überprüfen kann, habe ich am vergangenen Wochenende hierzu ein Tool geschrieben, das man einfach in den Buildprozess integrieren kann und das dem Buildmaster nicht nur sagen kann, ob jemand einfach nur geschlampt hat und sein Rebasing vergessen hat, sondern auch, ob es trotz aller guten Absichten bei eigentlich sauber ge-rebaseten (wie schreibt man das eigentlich?) DLLs irgendwelche Überlappungen in ihrem virtuellen Adreßraum gibt. Das Tool kann man hier runterladen und es wird so angewendet:

prefload dir <-e=excludefile> <-v> wildcards

also beispielsweise so:

prefload d:\devstudio\mysoftwareproduct\release *.dll *.ocx

Im Beispiel durchsucht es alle Dateien mit den Endungen dll und ocx unterhalb des Verzeichnisses d:\devstudio\mysoftwareproduct\release und stellt dabei potentielle Ladekonflikte fest. Wenn ein derartiger Ladekonflikt gefunden wird, wird er nach stdout geschrieben:

hornet.dll (10000000-10013000) has a conflict with ant.dll(10000000-10008000)

Und wenn irgendein solcher Ladekonflikt auftritt, dann kehrt das Tool auch mit einem Exitcode ungleich 0 zum Betriebssystem zurueck, was natürlich die Verwendung in einem batchbasierten System wie dem daily build besonders geschmeidig macht.

Der Clou ist natürlich, daß man mit dem Tool, für das ich mir gar nicht erst die Mühe eines UNICODE- oder x64-Builds gemacht habe, auch x64-Binaries ohne Probleme untersuchen kann. Möglich macht's der simple Aufbau von Windows PE-files. Man öffnet einfach ein PE-File mit plain-vanilla CreateFile und bildet es in ein memory mapped file ab. Ab da hangelt man sich anhand der Strukturen aus winnt.h an der Datei entlang um an die entscheidenden Informationen zu gelangen. Piece o' cake.

Was ich aber in keinster Weise weiß: Muß man das für DLLs, die aus managed code bestehen, eigentlich auch tun? Eigentlich schon, oder? DEI to the rescue!

Und das nächste Mal: Wozu überhaupt dieses gestörte Rebasing, tut doch schließlich auch so, oder!?!