Komfortabler Dateimanager mit vielen Funktionen

Grenzgänge

By Sven on 02.08.2005 - 19:21 in Entwicklung

Unter Windows XP x64 erfolgt eine konsequente Trennung zwischen 32bit-Anwendungen und nativen 64bit-Anwendungen. Eine 64bit-Anwendung kann keine 32bit-Dll laden – damit haben momentan alle Entwickler zu kämpfen, die ihre 32bit-Module in das Kontextmenü des 64bit-Explorers einbinden möchten. Die einzige Lösung hierfür ist, die Shellerweiterung als 64bit-Version zu kompilieren.

Auf ein ähnliches Problem stößt man, wenn man eine native 64bit-Anwendung ausliefern möchte und einige Module nur als 32bit-Dll zur Verfügung stehen. Wenn die Module nicht überlebenswichtig sind, kann man sie vorerst auch ausklammern. Ein Beispiel hierfür ist Squeez, der in der 64bit-Ausgabe keine Anzeige von Bildern in der Schnellansicht erlaubt und auch keine ACE-Archive entpacken kann. Von den WinACE-Entwickler war bisher leider noch nicht zu erfahren, ob bzw. wann eine x64-Fassung der UnAceV2.dll zu erwarten ist. Mit der zunehmend immer geringeren Verbreitung von ACE-Archiven lässt sich die fehlende UnACE-Unterstützung aber sicher verschmerzen.

Ganz anders sieht es mit der Schnellansicht von Bildern aus, die im SpeedCommander noch eine sehr viel größere Bedeutung hat. Hierfür verwende ich seit einigen Jahren die PictView-Dll von Jan Patera. Diese Dll kann über 50 verschiedene Bildformate lesen und ist gerade einmal 191KB groß. Auf meine Anfrage zu einer x64-Version teilte mir Jan leider mit, dass er vorerst keine Umsetzung auf 64bit plane. Die Dll selbst benutzt viel Assemblercode, so dass eine Portierung auch nicht ganz einfach ist.

Beim Stöbern in der MSDN-Library entdeckte ich folgenden Satz:

On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL. However, 64-bit Windows supports remote procedure calls (RPC) between 64-bit and 32-bit processes (both on the same computer and across computers). On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client. Therefore, if you have a 32-bit DLL that is not COM-aware, you can wrap it in an out-of-process COM server and use COM to marshal calls to and from a 64-bit process.

„Gesagt, tun getan“ pflegte Onkel Hotte immer zu sagen. Mit externen COM-Servern hatte ich bisher noch keinerlei Erfahrung, aber glücklicherweise bietet das Visual Studio 2005 mit der ATL dafür eine umfangreiche Unterstützung dafür. Ein COM-Server ist mit wenigen Handgriffen erstellt. Zusätzlich benötigt man noch eine Proxy-Dll, deren Projekt auch gleich generiert wird.

Das COM-Objekt definiert eine einfache Schnittstelle für den Zugriff auf die PictView-Dll. Es bekommt den Namen für die anzuzeigende Datei übergeben, lädt die Dll und bekommt dann von der Dll ein Bitmap (HBITMAP) zurück. Dieses wird in ein DIB (Device Independent Bitmap) konvertiert und an den Aufrufer zurückgegeben. Die Konvertierung in ein DIB ist notwendig, da das Marshaling zwischen dem externen COM-Server und dem Client bei einigen Grafiken nicht korrekt funktioniert, wenn ein HBITMAP übertragen wird. Vermutlich gibt es da noch einen kleinen Fehler im Windows-Marshaling-Code für HBITMAPs.

Damit ist nun auch die letzte große Hürde für die 64bit-Version von SpeedCommander genommen, die nun bis auf die fehlende UnACE-Unterstützung keinerlei Einschränkungen gegenüber der 32bit-Version mehr hat.

Es können keine Kommentare abgegeben werden.

Top