Most new computers have the capability of running 64-bit operating systems and so we are starting to see a lot more of them.
The principal difference between a 32-bit system and a 64-bit system is what is called the “word size”. A “word” is the standard size for integers on a computer. When a computer performs a mathematical operation, it is processing numbers of this size. So on a 16-bit machine, the standard integer size was 216, or 65536. Even if you were to perform a mathematical operation with numbers larger than 65535 (or on signed numbers greater in magnitude than 32767), internally the computer was performing it in smaller chunks (similar to how we add or subtract large numbers by hand). On a 32-bit machine, the word size is 232 or, approximately 4 billion (or from -2 billion to positive 2 billion). This makes for some natural limitations. For example, the theoretical maximum amount of memory a single process can address on a 32-bit system is 4 gigabytes (GB), though in Windows this limit is 2GB. (A 32-bit computer can have more than 4 GB of RAM total through “paging”, where the memory is split up into segments smaller than 4GB, although certain operating systems, such as the non-server editions of Windows, have a limit that is their own limit, not a hardware limitation. See also Microsoft’s table of memory limits for Windows.)
64-bit computers (and operating systems that take advantage of them) expand the word size to 264, or 18,446,744,073,709,551,616 (18 quintillion and change, or, approximately 1.3 million times the US national debt). This allows computers to more-rapidly compute extremely large numbers.
64-bit editions of programs are starting to trickle out. Interestingly, Microsoft recommends NOT upgrading to their own 64-bit edition of Office 2010 unless you are in the rare situation of needing to open a spreadsheet larger than 2 GB, so at least there is some recognition that 64-bit programs aren’t completely ready for primetime.
For programmers, 64-bit support represents several challenges. First and foremost, it is not possible to mix and match 32-bit and 64-bit modules within a single application. This makes sense when you think about it – as we said above, 32-bit programs can only address a theoretical maximum of 4GB of RAM, but for 64-bit programs that limit is 17 billion gigabytes. (In reality, Windows currently has an 8-terabyte limit for 64-bit operating systems.) Passing a 64-bit pointer to a DLL that only knows about 32-bit pointers isn’t going to work too well. So to create a 64-bit version of an application, it is necessary not only to convert the application itself, but any components that it may use. As a special case of this limitation, it is not possible to use a 64-bit control in Visual Studio’s designer because Visual Studio itself is 32-bit.
In Visual Studio, Microsoft offers a compile option called “AnyCPU” that purports to allow an application to function transparently on either 32-bit or 64-bit operating systems. Equally as interesting as Microsoft’s above recommendation not to use the 64-bit Office 2010, they have doubts about AnyCPU as well. It’s also worth noting that if your application uses any C++ code, it is always platform-specific, regardless of this setting, unless compiled with /clr:safe (which defeats the purpose of using C++). This can cause problems for testing when your program may appear to function correctly on a 32-bit computer, but fail on the other or vice versa.
There will eventually come a time when 32-bit programs are as antiquated as 16-bit ones are now. But for now, 64-bit support is still in the very early stages.
We love talking tech. We love researching new technologies. We would also love to be your go-to team for all things tech. Let’s get together and start a tech partnership that would only benefit your growing company.
Photo credit: Blake Patterson
|Enjoy Your 30-day Free Trial!|
|Learn how Inbound Marketing Software can help your business grow!|