64-Bit Windows (X64)

Only a few days ago I attended PubForum in Frankfurt - a weekend well spent! I had an altogether good time and very much enjoyed meeting so many great people. I also presented on the topic of migrating to 64-bit Windows Server 2008 R2 and XenApp 6, a task not to be taken lightly. For anyone interested, here is the slide deck I used.

When migrating to 64-bit Windows, traditional “unmanaged” applications can pose challenges. That is because unmanaged binaries contain hardware-dependent CPU instructions - and the view on the hardware differs between 32- and 64-bit mode. But .NET? It should be unaffected of a system’s bitness since “managed” binaries contain instructions in a so-called intermediate language that is executed in a virtual machine at run-time and only then translated to machine language. But is it really? This article is about .NET programs that are dependent on OS bitness.

At the verge of the transition from 32-bit to 64-bit Windows it is interesting to observe how people interpret and misuse acronyms for the definition of “their” platform. Looking at the acronyms in use out there one might consider oneself back in the eighties, with dozens of different incompatible computer systems. Unfortunately it is more boring than that. Let’s have a look.

[A German translation of this article is available at faq-o-matic.net.] The subtle differences between 32-bit and 64-bit Windows present so many intricacies and pitfalls that even Microsoft employees seem to have trouble getting it right. I just stumbled upon a KB article that describes how to reset the hosts file to its original state. The topic alone is funny enough - it is not as if the default hosts file contained great amounts of data. An entry for localhost (IPv4 and IPv6) is all you need, and on Windows 7 / Server 2008 R2 not even that. But anyhow, there seem to be enough people asking MS support for this or they would not have troubled with creating a package (ResetHOSTSFileBackToDefaults.MSI) that basically empties the hosts file.

Although the architecture of Windows x64 is still relatively young, Microsoft already changes it in Windows 7 by removing registry reflection. Just in case you wonder what I might be talking about: read up on 64-bit Windows in my detailed 7-part series whose last article explains registry reflection.

A recent discussion with a colleague brought this topic to my attention which I have not discussed in detail in my series on Windows x64: Memory scalability of 32-bit Terminal Servers

This is the seventh part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that mixed 32-/64-bit processes are not allowed and how that rule affects both administrators and script-writers. In this context I mentioned the strangely named directory SysWOW64. Today I am going to explain what it is used for by starting with redirection.

This is the sixth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I discussed how 32-bit applications are wrapped up in the WoW64 subsystem. Today we will take a deeper look at some limitations of 64-bit Windows and what they mean in practice.

This is the fifth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that the 64-bit OS can only load 64-bit drivers. Today we will turn our attention to user-mode code and analyze how the move to x64 affects downlevel applications.

This is the fourth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I wrote about the changes to the x86 processor architecture that make x64 possible. But there is of course more to a new platform than just updated hardware.

This is the third part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the first two articles (here and here) I explained key concepts and limitations of the x86 platform: every 32-bit process can use 2 GB of address space, which is by far enough for most applications. However, the kernel is also limited to 2 GB of RAM, which can lead to bottlenecks on systems that need to keep track of large amounts of resources, which is typically the case on terminal servers.

This is the second part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the first article I explained key concepts of the x86 platform, namely that user-mode processes each get 4 GB of virtual address space, but can use only half of it, because 2 GB are used for the operating system kernel.

I will start the new year with a small series on Windows x64 in which I will explain why 64-bit computing is not only necessary but inevitable. I will then go on to explain in detail where Windows x64 differs from the 32-bit versions and what that means for all those who are responsible for the design, operation, and support of 64-bit systems. All the while I will be focusing on terminal servers, but most facts and conclusions are valid for other system types, too.