64-Bit and Windows 2003/Windows XP
To clarify here, there are two different 64-bit hardware architectures so when explaining Microsoft’s support for them it helps to try and summarize this a bit before jumping straight in. I’ll be fairly brief in this introduction as I’ve included a phenomenal summary of the 64-bit architectures which my colleague Craig McMurtry put together at the bottom of this post.
When referring to “64-bit” you have to be a bit more specific than that as there’s two main 64-bit hardware architectures. The first 64-bit architecture was released by Intel with their “Itanium” processor. This processor is 64-bit but the key here is that it uses a new (i.e. not an extension to X86 and therefore not directly backwards compatible with X86) instruction set called “EPIC”. Microsoft supported the Itanium with a 64-bit version of Windows XP and when Windows 2003 launched, Windows 2003 also supported the 64-bit Itanium (“IA64”). In addition, you can also develop right now for 64-bit Itanium using the Platform SDK which includes 64-bit versions of MFC, ATL, C Runtime Libraries, compiler, linker etc. So in summary, right now if you wanted to develop (and/or run a 64-bit Itanium version of XP or Windows 2003) to the 64-bit Itanium based architecture you can absolutely do that as Microsoft has support for Itanium in both Windows XP and Windows 2003, as well as a 64-bit version of the platform SDK. Now, onto what’s coming out very shortly which is support in our operating systems for the second 64-bit architecture called X64…
AMD also supports 64-bit, however; they chose a different approach to supporting 64-bit and devised a clever architecture called “AMD64” (commonly referred to now as “X64”) which, unlike Intel’s Itanium processor, is backwards compatible with X86 as the X64 architecture uses 64-bit extensions to the x86 instruction set. AMD’s Operton and Athlon 64 processors include support for X64. Microsoft is releasing a version of Windows 2003, as well as Windows XP in the first half of 2005 which support X64. Also note that Intel supports X64 as well so from an Intel perspective you could go with the “Itanium” IA64 architecture, or with an Intel processor that has EMT64 support. Extended Memory 64 Technology (EM64T) is a feature of the Intel Xeon Processor that allows 32-bit platforms to access larger amounts of memory supported by 64-bit platforms. More info at the bottom of this post, and there’s a good (and recent) article here with more info as well:
Additional Windows 2003 64-bit information
The Windows Server 2003 family supports two different 64-bit architectures. The first is based on Explicitly Parallel Instruction Computing (EPIC), and supports the Intel Itanium processor family. The second is based on 64-bit extensions to the x86 instruction set, and supports both AMD64 and Intel Xeon with Intel Extended Memory 64 Technology (EM64T).
Windows Server 2003 for 64-Bit Itanium-based Systems delivers the highest levels of scalability for native 64-bit workloads such as databases and business applications.
With high-performance support for both 32-bit and 64-bit applications, Windows Server 2003 x64 Editions provide great versatility and broad application support.
Trial software is available for customers and developers to evaluate 64-bit versions of the operating system.
64-Bit and the .NET Framework 2.0/Visual Studio 2005
Also note that in addition to operating system support for X64 and IA-64 versions of XP/Windows 2003, the upcoming version of the .NET Framework (2.0) also includes support for 64-bit. For more information you can check out the 64-bit .NET
A particular interesting feature of the .NET Framework (2.0) for 64-bit is that the developer is isolated from the hardware architectures described above. Meaning, no recompilation required. Your typical .NET Application (i.e. if you’re doing Win32 API calls, COM 32 calls you need to be more careful) will simply just work whether the target environment ends up being IA64, X64, or X86. This actually makes a lot of sense when you think about how compilation in the .NET Framework works. Remember you start out with code in whatever language you happen to have developed in, you then compile that code using the compiler for your language (ie. csc.exe/vbc.exe/cl.exe…) and rather than ending up with a processor specific native compilation, you end up with what’s called Microsoft Intermediate Language (MSIL) which is a CPU-independent set of instructions that can be efficiently converted to native code. The .NET Framework just-in-time (JIT) compiler is what will compile the MSIL into native code specific to the CPU on the target environment. Therefore, you as a developer are abstracted from the CPU specific compilation (X86/X64/IA64).
It’s also important to note that there are some interesting changes in Visual Studio 2005 itself with regards to 64-bit. Visual Studio 2005 runs not only on X86, but will also run on IA64 and X64. In addition, Visual Studio 2005 includes support for remote debugging across architectures (e.g. x85 -> IA64).
Incredible 64-bit Training
This is an unbelievable opportunity if you’re interested in developing a strategy for 64-bit. I’ll paste some of the details below but in summary it’s a hard-core 3 day hands on workshop for only $299!! In addition you have access to the lab to test your application on 64-bit, the labs open late with technical support, an opportunity to get up to 40 hours of Premier Technical Support, deep discounts on HP hardware, lots of collateral material and so on… An incredible opportunity to say the least!! Here’s the link to the Route64 training:
Route64 is a 3 day hands-on workshop on Windows 64-bit technologies. The training includes how to ensure 32-bit application compatibility on Windows 64-bit and how to migrate an application to Windows 64-bit. Several classes are focused on how to take the most advantage of the 64-bit architecture.
64-bit Roadmap (Microsoft, Intel & HP)
Architecture & Tools Overview
Migrating C/C++ Applications to Windows 64-bit (Part I/II)
Running 32-bit applications on Windows 64-bit
Preserving 32-bit dependencies
.NET managed Code in 64-bit
COM Components in 64-bit
Migrating and Optimizing to SQL Server 2000 64-bit Edition
Using Performance Analysis Tools
Optimizations using Intel Compiler for 64-bit
You can select to attend the entire 4 day workshop or only the Windows 64-bit Compatibility workshop (day4).
What Is Included in the 64-bit Workshop?
Locations (Check here for latest http://www.route64.net/locationdates.aspx )
Feb 14 –
Mar 14 –
Apr 4 –
Apr 11 –
May 2 –
May 9 –
May 16 – New-York
May 31 –
Mar 30 –
Apr 4 –
Apr 11 –
Apr 18 –
Apr 25 – Barneveld (NL)
SQL Server 2000 64-bit info
SQL Server 64-bit home
SQL Server 2005 support for X64
SQL Server 2000 (64-bit) Books Online
Get easy access to the complete SQL Server 2000 (64-bit) documentation. Available as HTML Help files that you can download to your computer or on the Microsoft MSDN® website.
SQL Server 2000 (64-bit) Analysis Services: Why Migrate, and What to Expect
Find out about key technical differences between the 32-bit and 64-bit versions of Analysis Services, and whether these advantages make migrating to SQL Server 2000 (64-bit) right for you.
Advantages of 64-bit to SQL Server 2000 Enterprise Edition BI Customers
Discover the advantages of using SQL Server 2000 (64-bit) for your larger and more complex business intelligence (BI) applications.
SQL Server 2000 (64-bit): Intel Itanium Processor Touchstone
Learn how SQL Server 2000 (64-bit) demonstrates the capabilities and higher performance of Itanium architecture.
MSDN Webcasts on 64-bit
Craig McMurtry’s excellent 64-bit blogs
I’ve gathered Craig’s many posts on 64-bit together here so you can read it all at once. You can access his blog here:
64-bit computing is here today.
Quite literally: this is a 64-bit laptop, running a 64-bit operating system. And if you want to buy a 64-bit system, well, it’s dead easy: go to www.AlienWare.com , and order yourself a rig for home or for the office, and choose from among various 64-bit processors you can have installed in them.
So, 64-bit computing is not off in the future: it is here now. And in a few months, 64-bit hardware is going to be the norm. Here’s a quote from Phil Brace, a marketing director in Intel’s server group: “By the middle of , virtually all our server products will be 64-bit capable.” AMD doesn’t need to make statements of that nature because virtually its entire product line is already 64-bit, and, by virtue of that they now own more than 50% of U.S. retail store sales for desktop PC’s . . . so almost 1 in every 2 desktop PC’s sold in a retail store today has an AMD 64-bit processor inside.
What’s the consequence of this trend among the hardware manufacturers? Well, it means that in about a year, your customers are going to have 64-bit hardware in their data centers, if they don’t have some already. And you have to keep in mind that when they buy that hardware, the sales reps are telling them all about how the 64-bit hardware will give them power to exploit for years to come. Consequently, your customers turn around to you, their software vendors, and ask, “what are you doing to help me optimize the value of my investment in 64-bit hardware?” And at that point, you need to have a 64-bit strategy to present to them. Let me emphasize that this is not a hypothetical scenario. It was one of the very first issues that I was helping Microsoft’s software partners to deal with when I joined Microsoft a little over a year ago. Customers were saying, “we’ve got 64-bit hardware now . . . tell us what you’re going to do about that!” So, today, you’ve just got to have a 64-bit strategy, and my objective in this series of posts will to help you develop one.
My plan is quite straightforward. We are going to talk about the quite different kinds of 64-bit hardware on the market, what Microsoft is doing about them, and what you can do about them as software vendors.
What is a 64-bit processor, exactly?
Well, when an instruction is sent to a processor, it will often refer to one or more locations in memory that contain data that the processor is to manipulate. Those locations are expressed as binary numbers. On a 32-bit processor, the numbers can be up to 32-bits long, which means that the biggest possible number is 232, so there are between 0 and 232 memory locations that can be referenced. 232 memory locations is 4GB of memory. So, a 32-bit processor can only work on data in chunks of up to 4GB, which sets one boundary on its performance.
On a 64-bit processor, the numbers used to refer to memory locations can be up to 64-bits long, which means that the biggest possible number is 264, which amounts to more than 16 terabytes of data that the processor can manipulate as a single chunk. So, the amount of data that a 64-bit processor can manipulate as a single chunk is not only mind-bogglingly large, it is also mind-bogglingly larger than the chunks of data 32-bit processors are able to manipulate. Consequently, 64-processors can vastly outperform 32-bit processors. I’ll tell you about a very interesting real-world example of that a bit later.
There are two quite different species of 64-bit PC: the Itanium and the x64. The Itanium species first appeared in 2001, whereas the x64 species first appeared in April of last year.
What is the difference between the two species? Well, to understand that, we need to start with the concept of the instruction set.
An instruction set is the set of low-level, machine language statements that a processor can respond to. The 32-bit, x86 processors that we have been familiar with since the Intel386 chip was introduced way back in 1985, all have the same basic instruction set, and processor innovations since then have been about having that same instruction set execute more efficiently. In fact, the instruction set for the 80386 processor included the entire 80286 instruction set, so any software that would run on an 80286 processor would also run on an 80386 processor.
The x86 instruction set is described as a complex instruction set to distinguish it from the sorts of instruction sets that were supported by a new species of computers that was emerging at the time, which used reduced instruction sets. The idea behind reduced instruction sets was that if a processor was to support only a smaller, less elaborate set of instructions, then you could build the processor in such a way that the average time it would take to process each instruction would be lower.
So, at the end of the 20th century, there were x86-compatible complex instruction set processors in a great many machines, and reduced instruction set processors of various kinds in the remainder. Then, in 2001, Intel debuted its Itanium processor.
The Itanium processor has a different instruction set from its x86 predecessors; in fact, it had a new kind of instruction set altogether, a kind which it called EPIC, which stands for, Explicitly Parallel Instruction Computing. An EPIC instruction contains, in addition, to the operation to be executed, information about how to execute that operation in parallel with others. Then, based on that information about how to execute the operation in parallel with others, each EPIC instruction is bundled together with others, and the bundle is submitted to the processor all at once. The only proviso is that the instructions bundled together should not affect the data that the other instructions in the bundle are using.
There had been similar forays beyond complex instruction sets and reduced instructions into what are known as very long instructions. But a key differentiator between the Itanium with its EPIC instruction set and those other types of processors is a feature called predication.
Predication has to do with those if-statements that anyone who has done any programming will be familiar with. Branching statements in code, of which if-statements are just one example, generally say, if a condition exists, then do something, otherwise, do something else. And if you think about a machine executing those kinds of instructions, then you realize that everything that the execution of everything that comes after the condition would have to wait on the step of figuring out whether the if-condition exists. You envisage the machine saying, “well, let me first go and figure out if this condition the code specifies exists, and then based on that, I’ll know what to do next.” Well, Intel figures that having subsequent instructions wait on earlier ones is expensive, so why not execute the whole if-statement at once? Have the processor figure out whether the if-condition exists at the same time as it does what needs to be done if the condition does exist, and at the same time as it does what needs to be done if the condition doesn’t exist! Their theory is that by making the processor wide enough to do all of that work in parallel, and the compiler smart enough to be able to take the branching statements out of the code and rework them into instructions to be executed in parallel, that you get not only a more efficient processor, but the foundation for tacking processor technology forward, that is, by making the processor progressively wider, and the compiler progressively smarter at reworking branches into parallel instructions.
So, Itanium processors have this new instruction set called an EPIC instruction set that is all about bigger instructions with information about how they can be bundled together to be executed in parallel. And if you are going to have the processor execute bundles of big instructions all at once, then you would want to have a bigger pool of memory for the instructions to draw upon. There is no point in having a whole bunch of instructions going through in parallel if the data that all the instructions refer to cannot be in memory at once. So, EPIC processors are 64-bit processors, capable of processing data in those massive 16TB+ chunks.
By putting a new instruction set into the Itanium processor, Intel broke with its fifteen-year tradition of only ever adding to the x86 instruction set with each new processor that it introduced, for the EPIC instruction set is not merely a superset of the x86 instruction set. So, x86 software cannot run on the Itanium processor as-is. The processor incorporates a decoder that translates x86 instructions into EPIC instructions, then assembles them into bundles. That decoding process takes time, and, as a result, x86 applications perform relatively poorly on Itanium processors: they run at the speed they typically would on a 1.5 GHz Xeon processor. Crucially, a machine with an Itanium processor cannot boot an x86 operating system.
One other characteristic of the Itanium processor that is essential to mention is that it has no less than 6 built-in floating point calculators, 2 of which are tuned for 3D applications. Together, those 6 calculators yield theoretical maximum of 6.4 gigaflops of single-precision floating point processing power.
The first x64 processor was the AMD Opteron. The Opteron x64 processor has at least three very important features.
First, it is a 64-bit processor. Remember that we said that instructions to a 64-bit processor can refer to memory addresses using 64-bit binary numbers? Well, those addresses are entered into memory locations on the processor that are called registers. The Opteron processor has all of the same registers that an x86 processor has, but on the Opteron processor, those registers are 64-bits in size, rather than 32-bits in size, so that the processor can function as a 64-bit processor.
The second important feature of the Opteron has to do with how the processor accesses memory and other resources.
The typical x86 processor prior to the Opteron accessed memory via a memory controller located on a separate chip called the North Bridge, which also served as the connection to the Level 2 cache, the AGP slot, and some of the PCI devices. So, a lot of traffic was traveling over the connection between the processor and the
An Opteron processor has a memory controller built right in, so data in memory does not have to travel to the processor via the
Opteron’s have proven to be tremendously efficient processors. AnandTech published the results of some benchmark tests pitting Opterons against 32-bit Xeon processors at the end of 2003. Serving a Web application, the Opteron outpaced the Xeon by a whopping 45%. Serving a database, the Xeon and the Opteron were comparable in performance in a single-processor scenario, but the Opteron was 8.5% faster in a four-way multi-processor configuration, proving the superior scalability of AMD’s design eliminating the Front-Side Bus as a scarce resource that the processors must contend for to access memory and to do I/O.
At Microsoft, I’m told that we’ve switched to using x64 machines to compile our Windows operating systems, and the effects have been stunning. Windows Server 2003 Service Pack 1 took 9 hours to compile on x86 machines, but just 3 hours on x64s. Longhorn took 18 hours to build on x86 machines, but just 6 hours on x64s!
So, we find that the Itanium processor and the x64 Opteron processor are very different. They both incorporate ingenious ideas for drastically increasing the performance of the processor that go far beyond just making them 64-bit capable. Compared purely as 64-bit processors, the Itanium’s massive floating point processing capability is impressive. But in implementing its Itanium innovations, Intel created a new instruction set, the EPIC instruction set, which is not backwardly compatible with the established x86 instruction set. To support x86 software, Intel had to build an x86 decoder into the Itanium processor. By contrast, AMD’s design of its Opteron x64 processor yielded a 64-bit processor that is fully backwardly-compatible with x86 software. Consequently, the x64 species of processor is not only compatible with x86 operating systems, but also does not compromise the performance of x86 applications.
What does the 64-bit hardware landscape look like today, 18 months after AMD introduced the first x86 processor? On September 8th, at the Intel Developer Forum, Abhi Talkwalkar, general manager of Intel’s Enterprise Platform Group acknowledged that Itanium sales are not meeting the “aggressive” levels that Intel had set. By contrast, the Opteron market has exploded: AMD shipped 2,700 of them in the second quarter of 2003, and 60,000 in the same quarter of this year. They announced a new production facility in
Intel announced this past February that it would be providing processors compatible with the x64 standard that AMD had devised, and you can already buy those processors in either the Pentium or Xeon brands in systems from Dell, and HP and IBM also ship units with Intel x64 processors. Yet, there is still an important difference between the Intel x64 processors and the AMD Opterons and Athlon 64’s. Remember me writing about how the Opteron optimizes access to memory by having the memory controllers built right into the processor? Well, the AMD 64-bit processors are the only ones to have that feature. Intel has chosen to retain the memory controllers on the
In summary, we have Itaniums steadily dominating the top 11% of the market, with the x64 phenomenon quickly taking over the rest.
Folks who read my posts, and I am always very surprised to find that there are some, will know that unlike the majority of people who maintain blogs mostly devoted to technical topics, I never presume that anyone is interested in my personal life. Other readers of William Gibson’s writings may be inclined to concur that having a life that is interesting to others is an art form and one that is best left to those who devote themselves to it fulltime, namely celebrities. Yet, in this case, I’m going to deviate from that principle because I think something going on in my life this week is pertinent to the topic of 64-bit personal computing.
Just a little more than two years ago, I bought a Dell Dimension system. I sunk a good bit of money into it and was mightly pleased with it. It has been the best system I have had since my 386, and I have had a lot: I tend to buy a new one every 48 months or so. I used to buy my machines from local clone dealers in
Of course, I was well aware that Dell only ships machines with Intel inside, and honestly, before the Opteron, I had never even dreamed of buying a personal computer with any other brand of processor. However, I loved that last Dell so much that as far as I was concerned, the Dell brand was more important than the particular type of 64-bit processor that would be inside the new machine, so off I went to www.Dell.ca. After confirming the type of Pentium processor that had the x64-technology, I called Dell to confirm that the Pentium option I had my eye on did indeed have that feature. The Dell sales representative confirmed that the processor I was selecting had what Intel calls the “EM64T extension technology,” that it was indeed an x64 processor. So, I placed the order. Yet, something was nagging at me. The next morning, I called Intel, then Dell again, and this time got the sad truth: no, none of the Dell machines have the Pentium processors with the EM64T feature yet, and there was no timeline for those coming into Dell’s lineup. So, I cancelled my order, and, after considerable wrestling with my loyalty to Dell, placed a bigger order with Alienware for a system with the AMD Athlon FX chip. I’m super-happy with the specs on that system now.
At this point, we have established that the 64-bit PC computing world is really very different from 32-bit PC computing. It’s not just a matter of the processors being faster. Whereas with 32-bit PCs, you could count on having an x86 instruction set at the bottom, that’s not the case with 64-bit PCs, where you can have either an Itanium EPIC processor underneath, or an x64 processor. So, what is Microsoft doing about 64-bit computing? Let’s consider operating systems, developer tools, and applications . . .
Concerning operating systems, it is crucial to remember that Itaniums can only run operating systems compiled for the EPIC instruction set, whereas x64 processors will run operating systems compiled for them or for x86 processors.
For Itaniums, Microsoft has had Itanium versions of Windows XP Professional and Windows Server 2003 available to its customers for some time. The Itanium version of Windows XP Professional for the Itanium shipped with the 32-bit version of XP in August 2000, whereas the Itanium version of Windows Server 2003 shipped with its 32-bit counterpart in March 2003.
For x64s, if you have an x64 processor, then any 32-bit Windows operating system will boot on that system today. 64-bit versions of Windows XP Professional and Windows Server 2003 for the x64 will be released as part of the Windows Server 2003 Service Pack One release sometime in the first half of 2005. With the exception of Media Player, almost every feature will be implemented as a native 64-bit application.
My laptop is set up to dual-boot the 32-bit version of Windows XP Professional, and the 64-bit version of Windows Server 2003 Service Pack 1. If you have an x64 system too, and you are an MSDN Universal Subscriber, then you can download the beta versions of the x64 operating systems from the subscriber downloads site. You can find them under Windows Server 2003 in the content tree.
It is important to know, however, that all drivers have to be 64-bit when you are running a 64-bit operating system, so if you are using drivers other than those included in the operating system for any devices, then those devices will not work.
The operating systems for each processor family are compiled from the same code base, one for Windows XP and one for Windows Server 2003. However, not all of the features available in one version of the operating system are available on the others.
None of the 64-bit operating systems support these features that are available in the 32-bit versions:
· Microsoft DOS
· 16-bit applications
· The OS/2 subsystem
· The POSIX subsystem
· Certain effectively-obsolete transport protocols, like AppleTalk
There are a vast number of features that will be available in the x64 versions that are not available in the Itanium versions.
· Windows Firewall
· DVD video playback
· Movie Maker
· Windows Messenger
· MSN Internet Access
· ZIP Folders
· Home Networking
· Fast user switching
· Remote Assistance
· File and Settings Transfer Wizard
· Search Companion
· Power Management
· System Restore
So, compared to the Windows operating systems for the Itanium, which are somewhat bare-boned, the Windows operating systems for the x64 will be fully-featured.
A comment from Christopher reminded me to mention this: today, the 64-bit version of Windows are not sold retail, and that will continue to be the case for the 64-bit versions that ship as part of the Windows Server 2003 SP1 release. It will be sold to hardware manufacturers, and available via MSDN Professional and Universal.
Christopher’s comment also led me to this must-read article concerning differences between the Intel and AMD x64’s beyond those that I had already mentioned: http://www.TheInquirer.NET/?article=16879. Thanks, Christopher.
64-Bit Windows Part 11: Windows On Windows 64
We saw that both Itanium and x64 processors have a way of making their differences from 32-bit x86 processors invisible to 32-bit x86 code, although we noted that x64’s do so in a way that is a lot more efficient than Itaniums. However, when the 32-bit x86 code is running on a 64-bit operating system, with 64-bit data structures, how does the operating system hide its differences from a 32-bit x86 operating system away from the 32-bit x86 application?
The answer is that, on a 64-bit operating system, 32-bit applications run on top of an emulation of a 32-bit operating system that is called Windows on Windows 64, or WOW64 for short. WoW64 intercepts system calls to the operating system made by a 32-bit application.
It formulates native 64-bit system calls, converting 32-bit data structures into 64-bit aligned structures.
Then it issues the native 64-bit system call, and translates any output data from the 64-bit system call into 32-bit data structures.
Now, for non-technical folk in the audience, software applications quite typically use the facilities provided by other software components, called libraries, and they usually do so in the most efficient manner possible, which is by having the operating system load libraries into memory, and then accessing the facilities that they need by referring directly to the locations of those facilities in memory. Later, when we talk about developing applications for 64-bit Windows, we are going to emphasize that 32-bit applications cannot directly access the facilities of 64-bit libraries, and vice-versa. So, it would be quite disastrous for a 32-bit application running on a 64-bit operating system to attempt to directly access the facilities of a familiar library if that library were to turn out to be 64-bit. So, for 32-bit applications to work properly on 64-bit operating systems, they need to have 32-bit versions of their libraries available, while 64-bit applications need to have 64-bit versions of their libraries. So, in many cases, 32-bit and 64-bit versions of the same library need to exist side-by-side. Furthermore, if a 32-bit version of an application is installed, it should not overwrite a 64-bit version and vice-versa, so 32-bit and 64-bit versions of applications need to co-exist side-by-side, too.
On 32-bit Windows operating systems, programs are installed by default into a system folder called Program Files, while operating system components and shared libraries are installed into the System32 folder. On a 64-bit Windows operating system, there are separate versions of those folders for 32-bit and 64-bit software components.
So, in addition to the Program Files folder, there is a Program Files (x86) folder for 32-bit applications. Also, in addition to the System32 folder, there is a SysWOW64 folder. Contrary to what the names may suggest, 64-bit operating system components and shared libraries go into the System32 folder, while 32-bit operating system components and shared libraries go into the SysWOW64 folder. (There are no typographical errors in this paragraph: 64-bit entities go into the System32 folder, and 32-bit entities go into the SysWOW64 folder.)
Registry keys specific to 32-bit applications are stored in a branch under HKEY_LOCAL_MACHINE\Software\WOW6432Node.
All of this is done transparently to the application by WOW64, which, in intercepting calls to the operating system, detects references to file paths and registry keys and maps them accordingly.
This system allows 32-bit and 64-bit versions of the same applications to be installed side-by-side on the 64-bit operating system without risk of overwriting one another’s files or inadvertently accessing the wrong versions of the same library.
On the x64 versions of Windows Server 2003, there are both 32-bit and 64-bit versions of Internet Explorer installed by default. Why? Because many sites on the Internet incorporate 32-bit libraries called ActiveX controls, and for Internet Explorer to access those controls, it needs to be 32-bit. If you open up the Task Manager with both version running, and go to the Processes pane, you’ll see that 32-bit processes are denoted by *32.
There are some limitations to 64-bit Windows’ support for 32-bit applications.
1. You may remember reading here that 64-bit Windows operating systems do not support 16-bit applications? Well, many 32-bit applications have 16-bit installers. Windows detects many 16-bit installers and transparently instantiates an equivalent 32-bit version if one is available. Microsoft is working with vendors of 16-bit installers to obtain compatible 32-bit versions.
2. You may also remember reading that 64-bit Windows operating systems require all drivers to be 64-bit. Well, many 32-bit applications depend on 32-bit drivers, and those applications will not run on 64-bit Windows.