In den letzten Tagen habe ich mich damit beschäftigt, die Packer-Bibliotheken auf 64 Bit anzupassen. Das Kompilieren unter x64 geschah recht problemlos, allerdings stürzten einige der Bibliotheken (insbesondere die LZ77-Abkömmlinge) beim Komprimieren bzw. beim Entpacken ab.

Die Hauptursache war hier der Umgang mit Zeigern. Das Zeigermanagement kann sich unter x64 zu einer kniffligen Sache entwickeln, wenn man Zeigerarithmetik mit vorzeichenlosen Zahlen betreibt. Unter x32 gibt es hiermit keine Probleme, da es bei einem eventuellen Überlauf automatisch zu einer negativen Zahl kommt. Bei einer Erweiterung der Zeiger auf 64 Bit gibt es aber bei Operationen mit 32 Bit-Datentypen keinen Überlauf mehr, stattdessen wird das niedrigste Bit in den oberen 32 Bit gesetzt.

An einem Beispiel lässt sich das sehr gut demonstrieren. Der Ausgangspunkt ist ein kleines Stück C++-Code, der ein dynamisches Array erstellt und innerhalb dieses Arrays mit Zeigern arbeitet.

BYTE* pMem1 = NULL; BYTE* pMem2 = NULL;
pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x01814a28

for (int iTemp = 0; iTemp < 10; iTemp++)
{
    pMem1[iTemp] = (BYTE) iTemp;
}

pMem2 = pMem1 + 5; 		// pMem2 ist danach 0x01814a2d
pMem2 = pMem2 + nTest; 	// pMem2 ist danach 0x01814a2c

In den Kommentaren habe ich die Werte für die Zeiger angegeben, die beim Durchlauf auf meinem System entstanden sind. In Zeile 9 wird pMem2 auf den 6. Index (der Index ist 0-basiert) innerhalb des Arrays gesetzt. In Zeile 10 wird pMem2 um 0xFFFFFFFF verschoben, durch den entstehenden Überlauf ist das mit einer Subtraktion von -1 vergleichbar. pMem2 zeigt nun auf das 5. Element im Array.

Unter x64 lässt sich der Code problemlos kompilieren, auch eine explizite Prüfung auf 64bit-Probleme (Schalter /Wp64) meldet keine Probleme. Spätestens aber beim Versuch, mit pMem2 auf das 5. Element im Array zuzugreifen, funkt Windows mit einer Speicherschutzverletzung dazwischen. Wenn man sich den Inhalt von pMem2 genauer anschaut, dann ist der Grund dafür auch ersichtlich. Anstatt wie erhofft auf 0x00000000:00373d84 zeigt pMem2 plötzlich auf 0x00000001:00373d84, was definitiv nicht zum Speicher des Arrays gehört.

BYTE* pMem1 = NULL; BYTE* pMem2 = NULL;
pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x00000000:00373d80

for (int iTemp = 0; iTemp < 10; iTemp++)
{
    pMem1[iTemp] = (BYTE) iTemp;
}

pMem2 = pMem1 + 5; 		// pMem2 ist danach 0x00000000:00373d85
pMem2 = pMem2 + nTest; 	// pMem2 ist danach 0x00000001:00373d84

Genau wie unter x32 wird auch unter x64 pMem2 um 0xFFFFFFFF verschoben. Da der Wertebereich der 64bit-Zeiger aber nicht bei 0xFFFFFFFF endet, findet hier kein Überlauf statt und pMem2 zeigt auf eine ungültige Adresse.

Ein kleiner Typecast bei Zeigeroperationen hilft hier weiter. Der einzige Unterschied im folgenden Code zum vorherigen liegt in der letzten Zeile. Wird nTest explizit zu einem vorzeichenbehafteten Typ gecastet, dann zeigt pMem2 nach der Zeigerarithmetik auch auf die gewünschte Stelle.

BYTE* pMem1 = NULL; BYTE* pMem2 = NULL;
pMem1 = new BYTE[10]; UINT nTest = (UINT) -1; // pMem zeigt auf 0x00000000:00373d80

for (int iTemp = 0; iTemp < 10; iTemp++)
{
    pMem1[iTemp] = (BYTE) iTemp;
}

pMem2 = pMem1 + 5; 		// pMem2 ist danach 0x00000000:00373d85
pMem2 = pMem2 + (int) nTest; 	// pMem2 ist danach 0x00000000:00373d84

Alternativ kann man natürlich auch alle vorzeichenlosen Datentypen, die im Zusammenhang mit der Zeigerarithmetik verwendet werden, zu vorzeichenbehafteten umdefinieren. Das ist aber leider auch eine Menge Arbeit und es besteht die Gefahr, dass sich ohne große Not Fehler in bereits getesteten Code einschleichen.

Interessierten Lesern kann ich auch noch ein MSDN-Video von Kang Su Gatlin empfehlen. Hier wird nochmals auf einige Sachen in Bezug auf mögliche Probleme bei der Portierung auf 64bit eingegangen.

Ab und zu kommt man mal in die Verlegenheit und braucht schnell eine GUID. Für diese Fälle hat Uwe Keim eine neue Website zur Generierung von GUIDs programmiert.

Wenig bekannt ist aber leider, dass Microsoft mit Windows 2000 eine kleine Änderung bei der Generierung einer GUID durch die Funktion UuidCreate vorgenommen hat. Bis Windows 2000 war eine mit UuidCreate erstellte GUID garantiert immer eindeutig in Raum und Zeit, sofern der Rechner, auf dem sie erstellt wurde, eine Netzwerkkarte besaß. Da man durch die in der GUID enthaltene MAC-Adresse aber Rückschlüsse auf die Netzwerkkennungen in einer Firma schließen kann, hat Microsoft diese Funktion aus Sicherheitsgründen geändert. Der große Nachteil ist nun, dass die generierten GUIDs nicht mehr zwingend eindeutig sind.

Ab Windows 2000 muss man zur Generierung einer globalen eindeutigen GUID daher die Funktion UuidCreateSequential verwenden, andernfalls kann lediglich garantiert werden, dass die GUID nur auf dem Rechner eindeutig ist, auf dem sie erstellt wurde. Gerade für COM-Komponenten ist es aber wichtig, dass die verwendeten GUIDs auch wirklich einzigartig sind. Im schlechtesten Fall kann es sonst passieren, dass zwei verschiedene Komponenten von verschiedenen Entwicklern zufällig eine gleiche GUID benutzen und sich so ziemlich in die Quere kommen.

Dass die bei Uwe generierten GUIDs nicht global eindeutig sind, erkennt man am letzten Block. Dieser stellt die MAC-Adresse dar, global eindeutige GUIDs von einem Rechner haben hier immer den gleichen Wert.

Bei Uwe erzeugte GUIDs:

• 1ab9096f-2101-4d6a-9a77-4b0be04d6b0a
• 2e27197f-4c53-45f1-8f83-0f9f89456962
• cc09efd4-967c-4eb1-8c4b-3023d9c85c1c
• e0297aad-cee3-4005-a4db-172af5fa8295
• ea0bc131-97fd-4c15-8007-2d79995c39e2

Mit uuidgen.exe erzeugte global eindeutige GUIDs (uuidgen.exe -x -n5):

• f225f880-a5a2-11d9-8512-000c6e33eb97
• f225f881-a5a2-11d9-8512-000c6e33eb97
• f225f882-a5a2-11d9-8512-000c6e33eb97
• f225f883-a5a2-11d9-8512-000c6e33eb97
• f225f884-a5a2-11d9-8512-000c6e33eb97

So wie ich Uwe kenne, wird er seine Seite aber ziemlich bald aktualisieren, so dass man bei Bedarf auch global eindeutige GUIDs erhält. 🙂