64-bit Windows anti-virus not yet mainstream (come on!)


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.

Comments (4)

  1. PatriotB says:

    One caveat of building for 64-bit (specifically, x64) is that it’s only supported with Visual Studio 2005 *Professsional* or higher. Visual Studio 2005 Standard doesn’t come with support for building x64 apps.

    Of course, most software companies will be getting Pro for their work. However, many small or one-person hobbyist-types will not spend $500 for Pro just to get x64 support. Some of the stuff that I’ve developed, for example shell extensions, needs to be 64-bit to work in Windows x64, but I don’t see myself paying for the Pro edition just for that ability.

    I will probably have to build my projects for x64 manually using the x64 compiler that comes with the Platform SDK. But is really unfortunate that they won’t spread x64 support to "lower" editions of VS. Having x64 in Standard would really help promote its use by a wider range of developers.

    It wouldn’t be so bad, but for whatever reason, they’ve included support for mobile development in the standard edition. If you could choose between writing apps for Windows Mobile vs writing apps for x64, which one should we be trying to promote?

  2. Edge says:

    Sadly while it’s true that for developers who use Microsoft tools the path to 64-bit is simple, the path for people using other tools (notably Borland) is terribly difficult. For example: Borland has no intentions it seems of releasing a native x64 compiler for Delphi. The only alternative from them is to go to Delphi for .NET, but older code will have difficulties when ported (certainly more difficulties than if you were porting from native x86 to native x64). The only alternative it seems is to use Visual Studio 2005 and port our code to C/C++ (so we can target x64 natively).

    It’d be great if Microsoft (and AMD/Intel) could get some of these alternate development tool providers to get in line behind x64 development.

  3. Tomas says:

    I can build x64-apps using VS2005 standard edition beta 2 july CTP, by just adding the x64 target, so it seems to be supported.

    I have no problems using VS6 with the PSDK either, so companies can hardly blame the tools for their own slow adoption of x64.