Additional Considerations

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.

 

 

Community Additions

ADD
Show:
© 2014 Microsoft