As is well known to most of us, the mainstream server shipments today contain 64-bit processors. The 64-bit Windows Server 2008 R2 offers direct access to more virtual and physical memory than 32-bit systems and processes more data per clock cycle, enabling more scalable, higher performing computing solutions. While Windows Server has supported 64-bit platforms for the past several versions, Windows Server 2008 R2 ships with a 64-bit SKU only; no 32-bit SKU is available for the server version of the operating system.
There are two 64-bit Windows platforms: x64-based and Itanium-based.
The x64 processors are compatible with the x86 processors at a hardware level and x86 instructions are executed natively by the micro-architecture. Therefore, execution speed under WOW64 on x64 is similar to its speed under 32-bit Windows. On the Intel Itanium processor, more software is involved in the emulation, and performance suffers as a result.
On the Intel Itanium processor, WOW64 adds significant overhead if two or more instances of the same 32-bit application are running concurrently. This is due to the native 8 KB pages on the Intel Itanium, which complicates the emulation of the native 4 KB pages on the x86 architecture (more pages are marked as writable; all writable pages are private to the process). This is not the case for the x64 processor.
Overall, for 32-bit applications the x64 offers a more compatible and better performing platform.
As far as Remote Desktop Services (RDS) is concerned, only the x64 platform is supported. So the question really boils down to: “How does moving from x86 to x64 RDS platform affect me?”
Some of the most common FUD around this is regarding application compatibility.
In this post, we will look at a high-level overview of 32-bit application support in Windows Server 2008 R2 and point you to various resources that should help answer most of your questions related to the same. Please note that 16-bit DOS, Windows, or OS/2 applications are not supported on 64-bit Windows.
The first thing to understand is that most 32-bit applications should work fine on 64-bit Windows. To enable this, Windows provides Windows 32-bit On Windows 64-bit (WOW64 – See WOW64 Implementation Details), an emulation layer that enables 32-bit Windows-based applications to run seamlessly on 64-bit Windows. Windows automatically detects an application as 32-bit and runs it using WOW64, and most of your applications should run transparently.
WOW64 is provided with the operating system and does not have to be explicitly enabled. The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. The system provides interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution. This restriction does not apply to DLLs loaded as data files or image resource files. For more information, see LoadLibraryEx.
At the same time there are some known limitations of WOW64 that might cause incompatibilities with some classes of applications. These issues are discussed at length in the “Best Practices for WOW64” whitepaper which is a recommended read. Some of these are listed below –
· The address space is limited to 2 GB by default, and 4 GB if /LARGEADDRESSAWARE is used
· A 32-bit process cannot load a 64-bit DLL (except for certain system DLLs) and vice-versa
· Running 16-bit processes is not supported
· DOS (Command.com)/ NTVDM is not available
· The Virtual DOS Machine (VDM) API is disabled
X64 Windows supports several application installers that use a 16-bit stub by recognizing specific 16-bit installer programs and replacing them with ported 32-bit versions. There is built-in support for several installer engines, including InstallShield 5.x installers. See Application Installation for further details.
Apart from these, there are some portability issues that 32-bit applications can run into. For example, a 32-bit driver cannot run on the 64-bit Windows kernel so it must be ported.
In short, if your application is not affected by the above-listed issues, it should work fine on a 64-bit platform.
To learn more or for further details, see the following documents/articles –
Running 32-bit Applications
64-bit System Design page
Porting Your Driver to 64-Bit Windows
Pity there is no way to host a 64-bit guest on Windows 7 using Microsoft tools :-(
The ITPros and Devs use lots of VM's and I love x64 but it poses a really issue for us all and moving to pure x64 means we need VMWare or other hosting solutions.
Are you specifically looking at Windows 7 client sku? If you are open to using Windows Server 2008 R2, then you might use Hyper-V to host 64-bit guests.
You missed the biggest change: printers. There are many printers that do not have 64 bit drivers, or where the names do not match the 32 bit version. This makes point and print painful from an x64 remote desktop server to a 32 bit print server
Hi Paul, the software Virtual Box is compatible with Windows 7 x-64 and able to perform 64-bit virtual machines: http://www. virtualbox. org/.