What's he talking about? It is not at all that bad. I found already quite a few comments on other websites and in blogs referring to this misleading article. Don’t know what Mr. McMillan had for breakfast and why he tries to tell us we have to wait another year with platform adoption. If you are a developer and have not started building for 64-bit – apps and devices – you are already late. In some cases, you are too late because your competitors are already there.
Brian did a great job explaining the main caveat in migrating to the 64-bit platform.

Source code of components that run in kernel mode, like device drivers and others, must be compiled to platform compatible native code. Device drivers on 64-bit must be 64-bit native. But in most cases there’s no need to rewrite the stuff!


A few things for clarification:

Not all kernel mode components have to be rewritten. Most, if not all of the algorithms work and still apply for 64-bit. The interaction with the hardware component the driver needs careful evaluation and may require changes due to the 64-bit nature of the environment (compared to 32-bit).

With all Microsoft products – and this includes the OS – we follow the one source code model. There is only one source code for the OS. From the beginning of our 64-bit support, we maintain only one source code base for all Windows OS’ses. This code, of course also containing sections specific to only one architecture, is compiled for the various supported architectures. Windows server or client running on AMD64 or EM64T or Itanium has been compiled and built from the same source code as its 32-bit siblings.

With the introduction of support for 64-bit in the Windows world, every possible step was taken to make the migration and development experience for developers as easy as possible and the transition from 32-bit to 64-bit painless. 32-bit applications are supported as is. In labs with our ISV’s we found that the migration of source code to be compiled for 32-bit AND 64-bit is in 8 out of 10 cases possible without any changes to the source code. Some applications require modifications in source code due to issues caused by pointer arithmetic or due to assumptions in code about the “bitness” of the environment. Optimization and performance tuning are way more important on 64-bit platforms than on 32-bit. But the vast majority of apps just work.

When it comes to drivers and other kernel mode components, the world of migration looks similar. Key goal of the platform development team was to not break the existing driver model. In many cases a simple recompile is enough to just make a driver work on 64-bit. But obviously things in kernel mode are slightly different and more complex; especially if the migrated driver has to support access from 64-bit and 32-bit code. New devices of course require new drivers. If a device is only available for the 64-bit platform you will have to write a new driver. In kernel mode, like in user mode, the biggest challenge is related to pointer issues. Pointers are 64-bit in 64-bit Windows. This is why all your code that does some sort of pointer casting or arithmetic involving 32-bit data types breaks your code. But even here you find some extremely good help: The C/C++ compiler has some new switches like /Wp64 supporting developer efforts in finding these issues and solving above outlines problem areas.
Virus checking software, having kernel mode and user mode components, requires special attention due to its importance. Over the last 3+ years Microsoft has worked very close with all major anti-virus software companies not only to help them understanding the migration process and tools but also migrating their application to the 64-bit platforms.
BTW, if you are looking for anti-virus software for 64-bit Windows I suggest checking out these fine tools and companies (to name some of the available): Symantec, MacAfee, Avast, NOD32 64-bit, NIS2005.

Conclusion: Yes, if you want to run 64-bit native code you must code-clean your source code but there’s absolutely no need to develop from scratch! This is true for user- and kernel mode. All necessary tools from Microsoft and partners are available. There are plenty anti-virus solutions for the 64-bit Windows platform available. Some 64-bit processors even offer enhanced protection against malicious code.

If you wait until Windows Vista to build 64-bit native code, you’re out of business soon. If you wait to deploy 64-bit solution until Windows Vista: Hasta La Vista, Baby. The world probably won’t even remember you when Vista ships next year.