Edit

Additional Considerations

  • Article

When porting your code, consider the following points:

  • The following assumption is no longer valid:

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

    However, the 64-bit compiler defines _WIN32 for backward compatibility.

  • The following assumption is no longer valid:

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

    In this case, the else clause can represent _WIN32 or _WIN64.

  • Be careful with data-type alignment. The TYPE_ALIGNMENT macro returns the alignment requirements of a data type. For example: TYPE_ALIGNMENT( KFLOATING_SAVE ) == 4 on x86, 8 on Intel Itanium processorTYPE_ALIGNMENT( UCHAR ) == 1 everywhere

    As an example, kernel code that currently looks like this:

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

    should probably be changed to:

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

    Automatic fixes of kernel-mode alignment exceptions are disabled for Intel Itanium systems.

  • Be careful with NOT operations. Consider the following:

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

    The problem is that ~(b–1) produces "0x0000 0000 xxxx xxxx" and not "0xFFFF FFFF xxxx xxxx". The compiler will not detect this. To fix this, change the code as follows:

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

  • Be careful performing unsigned and signed operations. Consider the following:

    LONG a;
ULONG b;
LONG c;

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

    The result is unexpectedly large. The rule is that if either operand is unsigned, the result is unsigned. In the preceding example, a is converted to an unsigned value, divided by b, and the result stored in c. The conversion involves no numeric manipulation.

    As another example, consider the following:

    ULONG x;
LONG y;
LONG *pVar1;
LONG *pVar2;

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

    The problem arises because x is unsigned, which makes the entire expression unsigned. This works fine unless y is negative. In this case, y is converted to an unsigned value, the expression is evaluated using 32-bit precision, scaled, and added to pVar1. A 32-bit unsigned negative number becomes a large 64-bit positive number, which gives the wrong result. To fix this problem, declare x as a signed value or explicitly typecast it to LONG in the expression.

  • Be careful when making piecemeal size allocations. For example:

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

    The following code is wrong because the compiler will pad the structure with an additional 4 bytes to make the 8-byte alignment:

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

    The following code is correct:

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

  • Do not pass (HANDLE)0xFFFFFFFF to functions such as CreateFileMapping. Instead, use INVALID_HANDLE_VALUE.

  • Use the proper format specifiers when printing a string. Use %p to print pointers in hexadecimal. This is the best choice for printing pointers. Microsoft Visual C++ supports %I to print polymorphic data. Visual C++ also supports %I64 to print values that are 64 bits.