Windows API-Deklarationen in VBA für 64-bit konvertieren

Von Philipp Stiefel, ursprünglich veröffentlicht 2020-12-03

Zuletzt geändert 2020-12-03

Seit Office 2010 sind alle Office-Anwendungen einschließlich Microsoft Access und VBA zusätzlich zur klassischen 32-Bit-Edition als 64-Bit-Edition verfügbar.

Um gelegentliche Missverständnisse auszuräumen. Du musst Office / Access nicht als 64-Bit-Anwendung installieren, nur weil du ein 64-Bit-Betriebssystem hast. Windows x64 bietet ein hervorragendes 32-Bit-Subsystem, mit dem du jede 32-Bit-Anwendung ohne Kompatibilitätsprobleme ausführen kannst.

Im Moment ist 64-Bit-Office / Access immer noch eher die Ausnahme als die Regel, aber dies ändert sich immer mehr.

Access - 32-Bit vs. 64-Bit

Wenn wir uns nur auf Microsoft Access konzentrieren, gibt eigentlich keinen zwingenden Grund, die 64-Bit-Edition anstelle der 32-Bit-Edition zu verwenden. Eher ist das Gegenteil der Fall. Es gibt mehrere Gründe, 64-bit Access nicht zu verwenden.

• Viele ActiveX-Steuerelemente, die häufig in der Access-Entwicklung verwendet werden, sind für 64-Bit noch nicht verfügbar. Ja, das ist im Jahr 2020 immer noch ein Problem, mehr als 10 Jahre nach der Veröffentlichung des ersten 64-Bit-Windows-Betriebssystems. (Die Microsoft-Common-Controls sind seit 2017 für 64-Bit verfügbar, es besteht jedoch immer noch Verwirrung über die Verwendung von MsComCtl.ocx in 64-Bit-Access.)
• Treiber / Connectoren für externe Systeme wie ODBC-Datenbanken und spezielle Hardware sind möglicherweise nicht verfügbar. - Obwohl dies heutzutage selten ein Problem sein sollte. Nur wenn du eine Verbindung zu einigen alten Legacy-Systemen herstellen möchtest, könnte dies noch ein Faktor sein.
• Außerdem erfordern Access-Anwendungen, die die Windows-API in ihrem VBA-Code verwenden, einige Migrationsarbeiten, um in einer x64-Umgebung richtig zu funktionieren.

Ich kenne nur einen Vorteil von 64-Bit-Access. Wenn man mehrere Formulare gleichzeitig öffnet, die jeweils eine große Anzahl von Unterformularen enthalten, z.B. auf einem Registersteuerelement, können auf 32-Bit-Systemen Fehler durch Speichermangel auftreten („System resource exceeded“, „There isn’t enough memory…“). Dieses Problem tritt nicht auf, wenn man dieselbe Anwendung in 64-bit-Access ausführt.

Leider ist Access (in dieser Hinsicht) ebenso wie Microsoft Excel Teil der Office Suite. Für Excel gibt es tatsächlich sinnvolle Anwendungsfälle für die 64-Bit-Edition. Wenn du Excel zur Berechnung großer Datenmodelle verwendest, z. B. Finanzrisiko-Kalkulationen, profitierst du wahrscheinlich von dem zusätzlichen Speicher, der einer 64-Bit-Anwendung zur Verfügung steht.

Unabhängig davon, ob du es als Access-Entwickler magst oder nicht, wirst du eventuell mit der 64-Bit-Edition von Microsoft Access konfrontiert, weil jemand in deiner oder der Organisation deines Kunden beschlossen hat, die 64-Bit-Edition der Microsoft Office Suite zu installieren.

Es ist nicht möglich, 32- und 64-Bit-Anwendungen aus der Microsoft Office-Suite auf einem Rechner zu kombinieren. Ausnahmen sind nur die 32-Bit (x86) Runtimes von Access 2007 und 2010. Diese können neben einer 64-Bit-Version von Office installiert werden. Bei späteren Versionen der Access Runtime ist das aber nicht mehr möglich.

Da wir nichts an der Verfügbarkeit von Drittanbietern-Komponenten für 64-bit ändern können, konzentriert sich dieser Artikel auf die Migration von Windows-API-Aufrufen in VBA zu 64-Bit-Kompatibilität.

Windows-API-Aufrufe in VBA auf 64-Bit migrieren

Glücklicherweise wurde die Windows-API vollständig auf 64-Bit portiert. Du wirst keine API-Funktion finden, die auf 32-Bit verfügbar war, aber unter 64-Bit nicht mehr. - Zumindest kenne ich keine.

Ich stoße jedoch häufig auf gängige Missverständnisse hinsichtlich der Migration der Windows-API-Aufrufe. Ich hoffe, ich kann sie mit diesem Text erläutern und korrigieren.

Aber fangen wir am Anfang an. Das allererste, was du siehst, wenn du eine Access-Anwendung in 64-Bit-Access kompilierst, die eine API-Deklaration enthält, die für 32-Bit in VBA geschrieben wurde, ist eine Fehlermeldung.

Kompilierungsfehler: Der Code in diesem Projekt muss für die Verwendung auf 64-Bit-Systemen aktualisiert werden. Überprüfen und aktualisieren Sie Declare-Anweisungen, und kennzeichnen Sie sie dann mit dem PtrSafe-Attribut.

Diese Meldung weist klar auf das Problem hin, aber du brauchst wahrscheinliche weitere Informationen, um die Lösung zu implementieren.

Mit der Einführung von Access 2010 hat Microsoft einen Artikel zur 32- und 64-Kompatibilität in Access veröffentlichte. Ich finde diesen Artikel sehr umfassend und ziemlich gut, aber viele Entwickler sind der Meinung, dass er unzureichend ist.

Zusätzlich wurde noch eine neue und, meiner Meinung nach, ausgezeichnete Einführung in die 64-Bit-Erweiterungen in VBA7 auf MSDN veröffentlichten. Er enthält eigentlich alle Informationen, die du brauchst. Trotzdem halte ich es für sinnvoll zu erläutern, wie du dies in deinem Projekt anwenden kannst.

Das PtrSafe-Schlüsselwort

Mit VBA7 (Office 2010) wurde dem VBA-Sprachumfang das neue Schlüsselwort PtrSafe hinzugefügt. Dieses neue Schlüsselwort kann (soll) in Declare-Anweisungen für API-Funktionsaufrufe aus externen DLL-Bibliotheken, wie der Windows-API verwendet werden.

Was bewirkt PtrSafe? Es bewirkt genau ... gar nichts. Richtig, es hat überhaupt keine Auswirkung auf die Funktionsweise des Codes.

Der einzige Zweck des PtrSafe-Attributs besteht darin, dass du, als Entwickler, der VBA-Laufzeitumgebung explizit bestätigst, dass du deinen Code überprüft hast und er alle Pointer im Zusammenhang mit dem API-Funktionsaufruf korrekt behandelt.

Da sich der Datentyp für Zeiger (Pointer) in einer 64-Bit-Umgebung unterscheidet (mehr dazu gleich), ist es dringend angeraten die API-Deklarationen zu prüfen und ggf. anzupassen. Wenn du deinen unveränderten 32-Bit-API-Code in einem 64-Bit-Kontext ausführen würdest, würde dies vielleicht funktionieren. - Manchmal. - Manchmal würde es einfach nicht funktionieren. Und manchmal überschreibt und korrumpiert es zufällige Bereiche im Arbeitsspeicher deines Computers und verursacht alle möglichen zufälligen Instabilitäten und Abstürze von Anwendungen. Es wäre sehr schwierig, diese Effekte auf die falsche API-Deklaration zurückzuführen.

Aus diesem nachvollziehbaren Grund ist das Schlüsselwort PtrSafe in 64-Bit-VBA für jede externe Funktionsdeklaration mit der Declare-Anweisung obligatorisch. Das Schlüsselwort PtrSafe kann auch in 32-Bit-VBA verwendet werden, ist dort jedoch aus Gründen der Abwärtskompatibilität optional.

Der LongLong Datentyp

Die Datentypen Integer (16-Bit-Integer) und Long (32-Bit-Integer) bleiben in 64-Bit-VBA unverändert. Sie sind immer noch 2 Byte und 4 Byte groß und ihr Bereich möglicher Werte ist der gleiche wie unter 32-Bit. Dies gilt nicht nur für VBA, sondern für die gesamte Windows 64-Bit-Plattform. Generische Datentypen behalten ihre ursprüngliche Größe bei.

Wenn du jetzt eine echte 64-Bit-Ganzzahl in VBA verwenden möchtest, musst Sie du den neuen LongLong Datentyp verwenden. Dieser Datentyp ist nur in 64-Bit-VBA verfügbar, nicht in der 32-Bit-Version. Im Zusammenhang mit der Windows-API verwendest du diesen Datentyp aber nur sehr, sehr selten. Es gibt eine viel bessere Alternative.

Der LongPtr Datentyp

Unter 32-Bit-Windows sind alle Zeiger auf Speicheradressen 32-Bit-Ganzzahlen. In VBA haben wir diese Zeigervariablen als Long deklariert. Unter 64-Bit-Windows wurden diese Zeiger in 64-Bit-Ganzzahlen geändert, um den größeren Speicherplatz zu adressieren. Daher können wir den unveränderten Long-Datentyp offensichtlich nicht mehr verwenden.

Theoretisch könntest du den neuen LongLong Typ verwenden, um ganzzahlige Zeigervariablen in 64-Bit-VBA-Code zu deklarieren. In der Praxis solltest du das nicht tun.

Insbesondere für Zeiger hat Microsoft einen völlig neuen und sehr cleveren Datentyp eingeführt. Der LongPtr Datentyp. Das Besondere am LongPtr Typ ist, dass es eine 32-Bit-Ganzzahl ist, wenn der Code in 32-Bit-VBA ausgeführt wird, und eine 64-Bit-Ganzzahl, wenn der Code in 64-Bit-VBA ausgeführt wird.

LongPtr ist der perfekte Typ für jeden Zeiger oder Handle in deiner Declare-Anweisung. Du kannst diesen Datentyp in beiden Umgebungen verwenden. Er hat immer die richtige Größe, um die Zeigergröße in der jeweiligen Umgebung abzubilden.

Missverständnis: "Du solltest alle Long-Variablen in deinen Funktions- und Typdeklarationen in LongPtr-Variablen ändern, wenn du deinen Code für 64-Bit anpasst."

Falsch!

Wie oben erwähnt, hat sich die Größe der generischen 32-Bit-Datentypen nicht geändert. Wenn eine API-Funktion einen Long Integer für 32-Bit erwartet, erwartet sie weiterhin einen Long Integer für 64-Bit.

Nur wenn ein Funktionsparameter oder ein Rückgabewert einen Zeiger auf einen Speicherort oder ein Handle darstellt (z. B. Window Handle (HWND) oder Picture Handle), handelt es sich um eine 64-Bit-Ganzzahl. Nur diese Art von Funktionsparametern sollten als LongPtr deklariert werden.

Wenn du LongPtr falsch für Parameter verwendest, die einfach Long Integer sein sollten, funktionieren Ihre API-Aufrufe möglicherweise nicht oder haben unerwartete Nebenwirkungen. Insbesondere, wenn Sie LongPtr in Typdeklarationen falsch verwenden. Dies stört die sequenzielle Struktur des Typs und der API-Aufruf löst einen Typenkonflikt-Fehler aus.

Das hWnd-Argument ist ein Handle eines Fensters, daher muss es ein LongPtr sein. nCmdShow ist ein Int32, es sollte sowohl in 32-Bit als auch in 64-Bit als Long deklariert werden.

Übersieh nicht ein sehr wichtiges Detail. Nicht nur deine Declare-Anweisung sollten mit dem LongPtr-Datentyp geschrieben werden, deine Prozeduren, die die externe API-Funktion aufrufen, müssen auch den LongPtr-Typ für alle Variablen verwenden, die an ein solches Funktionsargument übergeben werden.

VBA7 vs. WIN64 Compiler-Konstanten

Ebenfalls neu in VBA7 sind die beiden Compilerkonstanten Win64 und VBA7. VBA7 ist wahr, wenn dein Code in der VBA7-Umgebung (Access / Office 2010 und höher) ausgeführt wird. Win64 ist wahr, wenn dein Code tatsächlich in der 64-Bit-VBA-Umgebung ausgeführt wird. Win64 ist nicht wahr, wenn du eine 32-Bit-VBA-Anwendung auf einem 64-Bit-System ausführen.

Missverständnis: "Du solltest die WIN64-Compiler-Konstante verwenden, um die verschiedenen Fassungen deines Codes zu unterscheiden, wenn du Kompatibilität mit 32-Bit-VBA / Access beibehalten möchtest."

Falsch!

Für 99% aller API-Deklarationen ist es völlig irrelevant, ob dein Code in 32-Bit-VBA oder in 64-Bit-VBA ausgeführt wird.

Wie oben erläutert, ist das PtrSafe Schlüsselwort auch in 32-Bit-VBA verfügbar. Und was noch wichtiger ist, der LongPtr Datentyp ist es auch. Du kannst und solltest also API-Code schreiben, der in beiden Umgebungen ausgeführt wird. In diesem Fall musst du wahrscheinlich nie bedingte Kompilierung verwenden, um beide Plattformen mit deinem Code zu unterstützen.

Möglicherweise liegt jedoch ein anderes Problem vor. Wenn du nur auf Access (Office) 2010 und höher abzielst, ist meine obige Aussage uneingeschränkt korrekt. Wenn dein Code jedoch auch in einer älteren Version von Access ausgeführt werden soll, musst du tatsächlich bedingte Kompilierung verwenden. Du musst dich allerdings immer noch nicht um 32/64-Bit kümmern. Du musst die Access / VBA-Version prüfen, in der dein Code ausgeführt wird.

Du kannst die VBA7 Kompilerkonstante verwenden, um Code für verschiedene Versionen von VBA zu schreiben. Hier ist ein Beispiel dafür.

Hier ist ein Screenshot dieses Codes im 64-Bit-VBA-Editor. Beachte die rote Markierung der alten API-Deklaration. Dieser Codeabschnitt ist markiert, erzeugt jedoch keinen tatsächlichen Fehler. Durch die bedingte Kompilierung wird der Code in dieser Umgebung niemals kompiliert.

Wann wird die WIN64 Compilerkonstante verwendet?

Es gibt Situationen, in denen du immer noch auf Win64 prüfen musst. Auf der x64-Plattform stehen einige neue API-Funktionen zur Verfügung, die auf der 32-Bit-Plattform einfach nicht vorhanden sind. Daher möchtest du möglicherweise eine neue API-Funktion unter x64 und eine andere Implementierung unter x86 (32-Bit) verwenden.

Ein Beispiel hierfür ist die GetTickCount-Funktion. Diese Funktion gibt die Anzahl der Millisekunden seit dem Start des Systems zurück. Ihr Rückgabewert ist ein Long. Die Funktion kann die Tick-Anzahl nur 49,7 Tage lang zurückgeben, bevor der Maximalwert von Long erreicht ist. Um dies zu verbessern, gibt es eine neuere GetTickCount64-Funktion. Diese Funktion gibt eine ULongLong zurück, eine 64-Bit-Ganzzahl ohne Vorzeichen. Die Funktion ist auch unter 32-Bit-Windows verfügbar, kann dort jedoch nicht verwendet werden, da in VBA kein geeigneter Datentyp für die Verarbeitung des Rückgabewerts vorhanden ist.

Wenn du die 64-Bit-Version der Funktion verwenden möchtest, wenn dein Code in einer 64-Bit-Umgebung ausgeführt wird, musst du die Win64-Konstante verwenden.

In diesem Beispiel habe ich den plattformabhängigen Code auf ein Minimum reduziert, indem ich beide Versionen der Funktion als GetTickCount deklariert habe. Nur auf 64-Bit verwende ich den Alias GetTickCount64, um die neuen 64-Bit-Version dieser Funktion aufzurufen. Die "richtige" Deklaration des Rückgabewertes wäre LongLong für die 64-Bit-Version und nur Long für die 32-Bit-Version gewesen. Ich verwende LongPtr als Rückgabewerttyp für beide Deklarationen, um Plattformabhängigkeiten im aufrufenden Code zu vermeiden.

Eine häufiger Fallstrick - Die Größe benutzerdefinierter Typen

Es gibt einen häufigen Fallstrick, der zu meiner Überraschung kaum erwähnt wird.

Viele API-Funktionen, die einen benutzerdefinierten Typ (User Defined Type = UDT) verwenden, der als eines ihrer Argumente übergeben wird, erwarten über die Größe dieses Typs informiert zu werden. Dies geschieht normalerweise entweder dadurch, dass die Größe in einem Element innerhalb der Struktur gespeichert wird, oder sie wird als separates Argument an die Funktion übergeben.

Häufig verwenden Entwickler die Len-Funktion, um die Größe des Typs zu bestimmen. Das ist falsch, funktioniert aber normalerweise auf der 32-Bit-Plattform - rein zufällig. Leider schlägt es auf der 64-Bit-Plattform meistens fehl.

Um das Problem zu verstehen, musst du zwei Dinge über das Innenleben von Windows wissen.

1. Die Elemente benutzerdefinierter Typen werden nacheinander im Speicher ausgerichtet. Ein Mitglied nach dem anderen.
2. Windows verwaltet seinen Speicher in kleinen Blöcken. Auf einem 32-Bit-System sind diese Blöcke immer 4 Byte groß. Auf einem 64-Bit-System haben diese Blöcke eine Größe von 8 Byte.

Wenn mehrere Elemente eines benutzerdefinierten Typs vollständig in einen solchen Block passen, werden sie in nur einem dieser Teile gespeichert. Wenn ein Teil eines solchen Blocks bereits gefüllt ist und das nächste Element in der Struktur nicht in den verbleibenden Bereich passt, wird er in den nächsten Block eingefügt und der verbleibende Bereich im vorherigen Block bleibt ungenutzt. Dieser Vorgang wird als Padding bezeichnet.

In Bezug auf die Größe benutzerdefinierter Typen erwartet die Windows-API, dass die vollständige Größe des Typs im Speicher angegeben wird. Einschließlich der Bereiche, die wegen des Paddings leer sind, aber berücksichtigt werden müssen, um auf den gesamten Speicherbereich zuzugreifen und die genauen Positionen der einzelnen Elemente des Typs zu bestimmen.

Die Len-Funktion addiert die Größe aller Elemente in einem Typ, zählt jedoch nicht die leeren Speicherbereiche, die möglicherweise durch das Padding erstellt wurden. Die von der Len-Funktion berechnete Größe ist also nicht korrekt! – Du musst die LenB-Funktion verwenden, um die Gesamtgröße des Typs im Speicher zu bestimmen.

Hier ist ein kleines Beispiel, um das Problem zu veranschaulichen:

Unter 32-Bit ist der Integer zwei Byte groß, belegt jedoch 4 Byte im Speicher, da der Long in den nächsten Speicherblock abgelegt wird. Die verbleibenden zwei Bytes im ersten Speicherblock werden nicht verwendet. Die Größe der Elemente summiert ergibt 10 Bytes, aber der gesamte Typ belegt 12 Bytes im Speicher.

Unter 64-Bit sind Integer und Long insgesamt 6 Byte groß und passen zusammen in den ersten Block. Der LongPtr (jetzt 8 Byte groß) wird in den nächsten Speicherblock eingefügt, und die verbleibenden zwei Bytes im ersten Speicherblock werden nicht verwendet. Die Größe der Elemente summiert ergibt 14 Bytes, aber der gesamte Typ belegt 16 Bytes im Speicher.

Wenn der zugrunde liegende Mechanismus auf beiden Plattformen vorhanden ist, warum ist dies dann kein Problem bei API-Aufrufen auf 32-Bit? - Es ist dort genauso ein Problem, aber einfach durch Zufall ist es unwahrscheinlich, dass du von dem Problem betroffen bist. Es gibt relativ wenige benutzerdefinierte Typen, die ein Element mit einem Datentyp kleiner als ein DWORD (Long) haben, und ich kenne keinen, der dann zusätzlich auch die Größe / Länge der UDT-Struktur verwendet.

Ressourcen zur API-Konvertierung

Die hilfreichste Ressource beim Schreiben oder Überarbeiten von API-Deklarationen für 64-Bit ist die Textdatei Win32API_PtrSafe.txt. Sie wird von Microsoft bereitgestellt und enthält viele Windows-API-Deklarationen für VBA mit 64-Bit-Unterstützung.

Diese Textdatei deckt die meisten APIs ab, die du benötigst. Es fehlen jedoch einige API-Funktionen, und es wurden keine neuen Funktionen ergänzt, die in Windows 8 oder später hinzugefügt wurden. Außerdem enthalten die Dateien nur die Deklarationen der ANSI-Funktionen, nicht jedoch der entsprechenden Unicode-Funktionen.

Ich habe noch eine weitere Ressource für dich erstellt. Hier ist ein VBA-Datentyp-Spickzettel für Windows-API-Deklarationen in 32-Bit und 64-Bit. Wenn du eine Funktionsdeklaration migrieren möchtest und nicht sicher bist, welche Datentypen verwendet werden sollen, kannst du sie in diesem Spickzettel nachschlagen. - Ich habe nicht alle Datentypen angegeben, aber wenn du keine exotische Funktion verwendest, sollte diese abgedeckt werden.

Schlusswort

Mit dem Inhalt in diesem Artikel solltest du in der Lage sein, die meisten Ihrer API-Deklarationen an 64-Bit anzupassen.

Viele Beispiele und Artikel, die heute im Internet zu diesem Thema verfügbar sind, sind nicht ausführlich genug, um alle wichtigen Punkte zu behandeln. Ich hoffe, ich konnte hier die wichtigsten Fakten für eine erfolgreiche Migration aufzeigen.

Denk immer daran, es ist eigentlich nicht so schwierig, API-Code zu schreiben, der für 64-Bit bereit ist. - Viel Glück!

Ergänzung - Präsentation auf der Access DevCon 2018

Ich wurde eingeladen, auf der Access DevCon 2018 in Wien einen Vortrag über die Windows-API in 64-Bit-VBA zu halten. Das hat mir viel Spaß gemacht und der Vortrag wurde vom Publikum sehr positiv bewertet. Ich habe den Vortrag auf Video aufgezeichnet und die freundliche Erlaubnis des Veranstalters erhalten, diese Aufzeichnung zu veröffentlichen. Du kannst das Video auf meinem YouTube-Kanal sehen.

Vielen Dank an Karl Donaubauer, der diese großartige Konferenz organisiert.

Share this article: