Since we now have 64-bit desktop machines at affordable prices, So too have 64-bit operating systems made the migration from something that would be server-oriented to a OS aimed more at the consumer.

However, as with the migration from 16-bit to 32-bit, this new “revolution” towards 64-bit is attracting a number of detractors. common arguments range from “lack of manufacturer support” to “not enough 64-bit applications”.

First, manufacturer support is excellent. Drivers, being “closer to the hardware” (that is, running in Ring 0) are more sensitive to changes in the bit width of the processor architecture and pointers. While it is true that your unlikely to get that old serial Dot Matrix Printer working perfectly, there are a number of generic drivers included with windows that can often suite the task quite well. (for example, the Generic/Text Only printer driver). Lack of support is more or less the problem with companies with released products that they deem “legacy” hardware. For example, the aforementioned Dot matrix Printer.

The second issue hits closer to home. You see, it assumes that there are vast differences hat require many man-hours of work restructuring or rewriting code. However, this is only the case if the code is poorly written to begin with. Properly written code following the SDK documentation and proper coding practices (you have to code for forward compatibility, not assume newer operating systems will be built with backward compatibility in mind) can be switched to the x64 architecture by simply flipping a compiler flag.

So what is this about? The problem is, the software firms developing these applications that are having difficulty and/or need to dedicate extra work to releasing a 64-bit version of their programs either did not learn their lesson from the 16-bit to 32-bit switch or weren’t around at the time. The main question then, is how exactly these  types of bad coding practices occur.

What exactly does it mean when an application is “16-bit” or “32-bit” or x bits? How is it that an application can even have a concept, or even have it’s execution directly affected, by the particulars of the processor it runs on? Desktop applications have been compiled to Machine code, or at least have had a machine code interpreter of some form of “bytecode” for ages. This machine code, by it’s very nature, is dependent on the particulars of the PC it runs on. The “bit-ness” of a application really only has a single effect on most applications, but it is a far-reaching one. It changes the size of a pointer- a memory address. Application programs access memory to do their work. They allocate, deallocate, reallocate, copy to, copy from, etc memory all the time to perform their operations. So it’s not surprising that something so integral to their operations might affect them.

However- speaking of the windows environment, in particular- the Windows SDK itself has been designed to preclude any such source-level problems- such as bit-width issues. take the ubiquitous “handle” value in the SDK. Window Handles; Device Context handles, File handles, etc. Handles are used everywhere, and, internally, a “handle” is really just a pointer to some chunk of kernel-owned memory, likely containing some persistent information about said object, but nobody really knows- nobody needs to know. In the windows 3.1 SDK, the HANDLE type is typedeffed as such:

Or something to that effect, effectively making a “HANDLE” a 16-bit Integer value. HANDLE was typedeffed to HWND, HDC, and all other handle types, as well. The idea was, that the programmer would simply use HANDLE types- for example:

It’s been a while since I wrote C or say the header for FindWindow, but the idea there is to return the window handle of a certain window. Notable is the fact that the return value of the function is a HWND.

The problem? Clever programmers this typedeffing was getting in the way- so they would declare their return types as short. When 32-bit windows rolled around and the updated SDK changed HANDLE to be a 32-bit int, these programs broke, and many vendors had to take many months updating their applications to work properly. (although, they had to change stuff a tad anyway, since there were also common controls and other goodies that often fit the bill or replaced- or even improved- upon the various implementations of similar controls in different applications and by different vendors.).

This very same hard lesson is being learned once again by another generation of young programmers who think saving a cycle or two during compilation was worth using a primitive type for these pointers.

Finally, 64-bit Systems support >4GB of RAM, something that has been common in servers for many years, and is just now becoming available to consumers. As our systems outgrow the 32-bit Operating Systems we insist on remaining attached to, there really has to be a point where we ask ourselves what it is that we are actually hanging on to. Do we really believe that “32-bit applications have trouble in 64-bit windows”? Did we ever experience it? Personally, I haven’t had a single problem with a game, or application ,32-bit or 64-bit, or a hardware device not working or not having a driver. Sure- For some of my more esoteric devices I wanted to use, I had to do some googling to find a working driver, and I doubt there are x64 Vista drivers for, say, my 16-bit ISA IBM token ring card.

Another common “grievance” for people commited to running 32-bit operating systems, even when their system is capable of running a 64-bit OS (this, I might add, is who I mean- those running a 32-bit Operating System on a 32-bit system are fine- I am not saying that 64-bit, as a whole, is something that should be preferred, but rather that using a 32-bit operating System on a 64-bit able PC is like running windows 3.1 on a Pentium 4.) Is that there aren’t a lot of 64-bit applications. This irrelevant, really. it would obviously be important if the 64-bit operating system could only run 64-bit applications, but as it is, all 64-bit versions of windows, at least, can run 32-bit windows applications without issue.

To revisit decisions between a 32-bit and 64-bit System, as opposed ot merely an operating System- 64-bit should be a no brainer, especially at today’s price differences. a 64-bit processor has twice the bandwidth of a 32-bit processor. The fact that people overlook this fact and claim it’s “over-hyped” need to relearn basic arithmetic. Behind their arguments  of incompatible programs, hardware, and other equally fallacious claims is something that we are all familar with. Somebody scared of change.

Have something to say about this post? Comment!