Weitere Überlegungen

Berücksichtigen Sie beim Portieren des Codes die folgenden Punkte:

• Die folgende Annahme ist nicht mehr gültig:

  #ifdef _WIN32 // Win32 code
      ...
  #else         // Win16 code
      ...
  #endif
  

  Der 64-Bit-Compiler definiert jedoch _WIN32 aus Gründen der Abwärtskompatibilität.

• Die folgende Annahme ist nicht mehr gültig:

  #ifdef _WIN16 // Win16 code
      ...
  #else         // Win32 code
      ...
  #endif
  

  In diesem Fall kann die else-Klausel _WIN32 oder _WIN64 darstellen.

• Achten Sie bei der Datentypausrichtung darauf. Das TYPE_ALIGNMENT Makro gibt die Ausrichtungsanforderungen eines Datentyps zurück. Beispiel: TYPE_ALIGNMENT( KFLOATING_SAVE ) == 4 auf x86, 8 auf Intel Itanium ProzessorTYPE_ALIGNMENT( UCHAR ) == 1 überall

  Beispiel: Kernelcode, der derzeit wie folgt aussieht:

  ProbeForRead( UserBuffer, UserBufferLength, sizeof(ULONG) );
  

  sollte wahrscheinlich geändert werden in:

  ProbeForRead( UserBuffer, UserBufferLength, TYPE_ALIGNMENT(IOCTL_STRUC) );
  

  Automatische Korrekturen von Kernelmodusausrichtungsausnahmen sind für Intel Itanium-Systeme deaktiviert.

• Achten Sie bei NOT-Vorgängen darauf. Beachten Sie Folgendes:

  UINT_PTR a; 
  ULONG b;
  a = a & ~(b - 1);
  

  Das Problem besteht darin, dass ~(b–1) "0x0000 0000 xxxx xxxx" erzeugt und nicht "0xFFFF FFFF xxxx xxxx". Der Compiler erkennt dies nicht. Um dies zu beheben, ändern Sie den Code wie folgt:

  a = a & ~((UINT_PTR)b - 1);
  

• Achten Sie darauf, nicht signierte und signierte Vorgänge auszuführen. Beachten Sie Folgendes:

  LONG a;
  ULONG b;
  LONG c;
  
  a = -10;
  b = 2;
  c = a / b;
  

  Das Ergebnis ist unerwartet groß. Die Regel ist, dass, wenn ein Operand nicht signiert ist, das Ergebnis nicht signiert ist. Im vorangehenden Beispiel wird a in einen nicht signierten Wert konvertiert, dividiert durch b und das in c gespeicherte Ergebnis. Die Konvertierung umfasst keine numerische Manipulation.

  Betrachten Sie als weiteres Beispiel Folgendes:

  ULONG x;
  LONG y;
  LONG *pVar1;
  LONG *pVar2;
  
  pVar2 = pVar1 + y * (x - 1);
  

  Das Problem tritt auf, da x nicht signiert ist, wodurch der gesamte Ausdruck nicht signiert wird. Dies funktioniert einwandfrei, es sei denn, y ist negativ. In diesem Fall wird y in einen nicht signierten Wert konvertiert, der Ausdruck wird mit 32-Bit-Genauigkeit, skaliert und zu pVar1 hinzugefügt. Eine 32-Bit-nicht signierte negative Zahl wird zu einer großen 64-Bit-positiven Zahl, die das falsche Ergebnis liefert. Um dieses Problem zu beheben, deklarieren Sie x als signierten Wert, oder geben Sie ihn explizit in LONG- im Ausdruck ein.

• Achten Sie beim Erstellen von Stückgrößenzuordnungen darauf. Zum Beispiel:

  struct xx {
     DWORD NumberOfPointers;
     PVOID Pointers[100];
  };
  

  Der folgende Code ist falsch, da der Compiler die Struktur mit einer zusätzlichen 4 Bytes auffüllt, um die 8-Byte-Ausrichtung zu erzielen:

  malloc(sizeof(DWORD) + 100*sizeof(PVOID));
  

  Der folgende Code ist richtig:

  malloc(offsetof(struct xx, Pointers) + 100*sizeof(PVOID));
  

• Übergeben Sie (HANDLE)0xFFFFFFFF nicht an Funktionen wie CreateFileMapping. Verwenden Sie stattdessen INVALID_HANDLE_VALUE.

• Verwenden Sie beim Drucken einer Zeichenfolge die richtigen Formatbezeichner. Verwenden Sie %p zum Drucken von Zeigern in hexadezimaler Zahl. Dies ist die beste Wahl für das Drucken von Zeigern. Microsoft Visual C++ unterstützt %I zum Drucken polymorpher Daten. Visual C++ unterstützt auch %I64 zum Drucken von Werten mit 64 Bit.