Tim Long

Forever in Electric Dreams
The life and times of a Small Business Server MVP and all-round technology enthusiast. Tim is founder of TiGra Networks, a company based in South Wales UK specialising in small business IT. This blog is aimed at Microsoft Small Business Specialists, IT professionals, Astronomers and anyone interested in science and technology.

Recent Posts

Tags

News

Community

Email Notifications

TiGra Networks

My Family

Photo Galleries

SBS Groupies

Archives

How 64-bit Development is Being Stifled at Birth

image I've been dabbling with various different development projects recently and I've uncovered what I think is an important failing in Microsoft's support for 64-bit software.

In Visual Studio, the default setting is to generate code for "Any CPU". This sounds great because it means your product should run on any processor, be it 32-bit or 64-bit and for simple programs that works well. Where this all goes horribly wrong is when you make use of an API that only has support for 32-bit processors. Some important Microsoft APIs (CRM SDK, Office Accounting SDK to name just two that I've discovered recently) fall into this category. Under those circumstances, what happens is that everything works fine on a 32-bit processor, but as soon as the code is run on a 64-bit architecture, it falls flat.

The reason for this is that 64-bit processes are not allowed to make calls into 32-bit COM objects. Remember, by default Visual Studio generates both 64-bit and 32-bit code. When run on a 32-bit processor, the 32-bit code runs and can make calls into the 32-bit API objects. When the same code is run on a 64-bit system, however, the 64-bit code will run and will fail when it tries to call into the 32-bit API objects.

image Fortunately there is a workaround, and that is to set your target architecture to 32-bit to prevent Visual Studio from generating 64-bit code. So you can see how this is going to affect the development of 64-bit software in the coming months and years. Essentially, it is not going to happen until Microsoft upgrades all of its SDKs and APIs to support 64-bit architectures.

I suspect Microsoft has fallen victim to this situation itself, which might explain why Groove 2007 still can't support file sharing workspaces on 64-bit systems. Why not? Because the required shell extension class is only available in 32-bit . Why? My educated guess is because it relies on a lot of 32-bit COM objects that would need some major development effort to update to 64-bit.

So while 64-bit development is possible and support for it is improving, in practice many developers are still constrained to use 32-bit because their underlying API or SDK has not been updated. With 64-bit processors now becoming the norm, this situation is starting to hurt. I think Microsoft has a lot of work to do in this area.

Comments

Tim Long said:

Update: In my original article I mentioned that Microsoft Dynamics CRM SDK did not support 64-bit architecture. In May 2008, Microsoft released an updated version of the SDK that adds 64-bit support.

# August 19, 2008 8:41 PM