I hope you've started working on getting your drivers to run on Windows on the AMD64, like most of the world.  The DDK has had an AMD64 cross-compiler (runs on x86, targets AMD64) for quite a while.  If you're not already working on porting your drivers, you're missing an imortant opportunity: The AMD64 running 64-bit Windows will be the hottest desktop in town.

While it's very obviously the future, I'll let the other boys here write the articles extolling the virtues of the AMD64 and 64-bit Windows.  I want to warn you about a more subtle issue: Embedded assembler code.

The use of any embedded assembler language (using _asm) is not supported by the MS C compiler for the AMD64.  Yup, straight up, it refuses to compile it and gives you an error.

You could move your assembler code to a subroutine, but the calling conventions for 64-bit code are all fastcall on Windows on the AMD64.  Not to mention that exception handling is done very differently.  And there's no support for x87 floating point, MMX, or 3dNow! instructions (for 64-bit code, like drivers).  So straight-out moving your code isn't a completely trivial exercise.

The good news is that SSE/SSE2 instructions are natively supported and always context-switched.  So, a few SSE/SSE2 intrinsics can be substituted for any floating point code you might have (with better speed and accuracy, usually, too).

(Hey... Before you tell your app weenie friends and get them all upset and whiny: Be sure you understand that the Windows-64 on the AMD64 supports all the above including _asm, x86, MMX, etc for 32-bit code compiled with the standard x86 32-bit compiler, even when running on a 64-bit operating system.  But drivers must be native 64-bit and that's the difference.)

There'll be more articles about the AMD64 coming soon.  In the mean time, get rid of that embedded assembler.  And get to work on supporting Windows-64 on the AMD64.  Comprendes?