The rocky transition to 64-bit

Red Stapler Software recently purchased a new 64-bit server, and I began the exciting endeavor of installing Windows Server 2003 x64 Edition for the first time. I'm very happy with the outcome but there were a lot of hiccups along the way.

First, the decision to buy 64-bit hardware was a very easy one. It's almost impossible to get 32-bit server hardware nowadays, and for good reason. The x64 architecture is faster and fully backwards compatible. No brainer. The same can't be said for the operating system and software.

Microsoft support for 64-bit is almost perfect. The huge gaping hole in their support of it is the lack of any 64-bit edition of Windows Server 2003 Small Business Edition. Fortunately, I was interested in installing Windows Server 2003 Standard and SQL Server 2005, both of which have x64 editions (and Itanium, for those who are interested).

While installing the operating system (just after discovering that my USB keyboard worked in the BIOS - impressive), the only problem I ran into was acquiring 64-bit RAID drivers. Actually, they were easy to acquire, but since Windows had no native support for my RAID controller at all, I had to download them from the internet and put them on a FLOPPY DISK. Windows Setup will not explore the wonders of compact discs when looking for drivers. Since the server we ordered had no floppy drive, I had to dangle one outside the case until Windows was installed and happy with its new driver.

Since we write all of our web sites, tools, and other software in .NET (1.1 and 2.0), 64-bit compatibility for our software was a breeze. It isn't even necessary to recompile. All of our 1.1 applications run fine on the 2.0 framework, but we do have the option to have .NET 1.1 installed side by side and run older applications on that platform instead. Things become slightly more complex when running ASP.NET web applications in IIS.

IIS is capable of hosting ASP.NET web applications in a 32-bit or 64-bit process (but not both). There is also the option to host on the 1.1 or the 2.0 platform (or both), but since we had no compatibility issues, we chose to use 2.0.

At first, I tried hosting all of our web sites on ASP 2.0 64-bit. This worked for almost every web site. The web site that did not work referenced two third-party utilities: Aspose.Word v2.5 and ActivePdf Toolkit v3.5.2 SP6. It turns out that both of these utilities use COM, and making an in-process reference to a 32-bit COM component in a 64-bit process is a no-no. This was a deal-breaker.

My first response was setting IIS up to host the web sites in ASP 2.0 32-bit mode. This worked. The problem web site and its associated Word and PDF automation tools worked perfectly. Unfortunately, it broke SQL Server 2005 Reporting Services. Reporting Services for the 64-bit version of SQL Server 2005 uses IIS and requires that it be hosted in ASP 2.0 64-bit mode. Since it's impossible to host it in 64-bit mode while also hosting our problem web site in 32-bit mode, we were stuck.

I turned my attention to the tools. I contacted Aspose's support (which was fantastic - I received an answer over instant messager immediately) and was told to upgrade (free) to version 3.x of their product. This fixed the problem immediately and required no code changes. One down, one to go.

I contacted ActivePdf's support, and during the week it took them to get back to me I tried downloading the new version of their Toolkit (4.0). After modifying the source code to conform to the new API (which had undergone meaningful changes like BinaryImage becoming a method instead of a property, forcing me to add parenthesis), I encountered the same problem as I did with our existing version. Eventually they admitted that they don't officially support 64-bit platforms and they had no solution for me.

Since I had such a great experience with Aspose, I downloaded a trial of their Pdf form filling tool (Aspose.Pdf.Kit). I had it up and running in 10 minutes, and had our code totally converted in half an hour (and it was much cleaner). This tool worked in our 64-bit environment without flaw just as Aspose.Word did, and all of our 64-bit migration barriers were gone.

Standalone 32-bit applications such as WinZip run without incident on a 64-bit server (note that 32-bit applications get installed, by default, in C:\Program Files (x86)\ rather than C:\Program Files). In-process COM is what you have to watch out for.

The switch to 64-bit was well worth making for us, but the more third-party (well, non-Microsoft, really) tools you reference from web applications, the harder it will be. Of course, the biggest winner in the move to 64-bit is SQL Server, so a very reasonable option is to have a 64-bit server that serves just the database and have the web server run a 32-bit operating system.