X64

I was given the Aventail VPN client software to install on a customer’s Windows 7 x64 computer. That failed miserably. Here is what I did to find the root cause of the problem.

This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles. More and more people are upgrading to a 64-bit version of Windows. Many of them would probably like to keep their existing configuration. The question is: can you use the 32-bit profile on Windows x64? Is there even such a thing as a 32-bit or a 64-bit user profile? Or are profiles independent of the system’s bitness?

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.

As before this is mainly a condensed and beautified version of my twitter postings. You can get them unfiltered and without delay by following me. Office 2010 Here is a nice overview of the new Office suite by Mark Wilson. By the way: Although available as 32-bit and 64-bit versions, the 32-bit version is the default and recommended by Microsoft for the time being.

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.

Windows General Good info for troubleshooting DFS-Namespaces in the MS KB: Storage locations, inconsistencies and how to deal with them. Complex passwords and security guidelines for end users? No, thank you, says MS researcher. I agree.

After neglecting my good old Canon EOS 350D for some time, I took some pictures with it yesterday, which I wanted to transfer to my laptop, of course. And there the trouble started.

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.

Even with the most meticulous design, the day will come when your farm’s capacity is not sufficient any more. User numbers increase, applications become more resource-hungry and the amount of data to be handled increases steadily. So what do you do? Simply more of the same, i.e. buy more servers and add them to the farm? That is one way of increasing capacity, but it is not the only one and therefore may not be the best.

Do you like what you read in this blog but have questions I did not answer (yet)? Or do you prefer listening and talking to live human beings instead of sitting alone in front of your screen? Well, come hear me speak and tell me what you think! This summer I will be speaking at the following conferences (all in Germany and in German, I am afraid):

[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.

Back in the old days, when 64-bit computing was still a novel concept and RISC vs. CISC wars were still fought, HP and Intel joined forces to develop the next-generation CPU. It would be 64-bit only and it would have a new type of architecture called EPIC. That was in 1994.

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.

Recently I got into a very interesting discussion with my colleague Nicholas Dille on various aspects of Windows x64. One question he brought up was especially intriguing: knowing about registry redirection, it is not astonishing to find that the 32-bit version of the registry key HKLM\Software\Classes (aka HKCR) gets to be HKLM\Software\Classes\Wow6432Node. But there is also HKLM\Software\Wow6432Node\Classes!? How can there be two different Wow6432Node 32-bit keys for one 64-bit key?

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.