Published
Jun 26 2019 11:14 PM
2,466
Views
First published on TechNet on May 07, 2005
Last week I got an HP xw9300 workstation equipped with two 2GHz Opteron processors, the same type of system most of the Windows kernel team uses. The system came with 32-bit Windows XP preinstalled, but I decided to buy into all the 64-bit hype coming out of Microsoft’s Winhec conference and so I scratched the HP image, reformatted the disk, and installed Windows XP 64-bit Edition. Is Windows ready for 64-bit full-time? After a week of development, writing, and experimenting I’m ready for a preliminary report.
The first issue I ran into was lack of built-in driver support for the network adapter and video card. This was easily remedied, though, with a quick trip to Nvidia's web site to download their 64-bit motherboard and video drivers.
After getting Windows running I spent the first few hours with the system installing applications and tools. The installations went smoothly for just about everything except for one application that I’ve come to rely on: MSN Desktop Search (MDS). It’s especially ironic that MDS won’t run on 64-bit Windows given that it’s a high-profile application from the company that’s trumpeting the official arrival of 64-bit computing and telling device manufacturers that if they don’t have 64-bit drivers they’re already behind the times. What’s even more ironic about MDS’ lack of 64-bit support is the way that its installation fails:
The installer doesn’t even know its running on 64-bit Windows. The operating system version number reported on 32-bit Windows XP is 5.1, but since 64-bit Windows XP shares the same kernel as 64-bit Windows Server 2003 SP1 it reports a version number of 5.2 as this Msinfo32 screenshot shows:
I suspect that the MDS installer believes itself to be running on Windows Server 2003 and therefore refuses to install.
I used the application compatibility tab on the installer’s properties to trick the installer into thinking it was running on 32-bit Windows XP, which resulted in the installation getting further, but it failed with the same error a little later. The second time the error message comes from the Windows Installer Service while it’s processing the MDS MSI (Microsoft System Installer) file that the first installer extracts. The installer service is likely checking the operating system version again because of instructions in the MDS MSI.
Even if I had tricked MDS into installing I would have gotten only partial functionality. On 64-bit Windows there’s no cross-interoperability between 64-bit processes like Windows Explorer and 32-bit COM DLLs like those that make up MDS desktop extensions. The taskbar search window wouldn’t have worked, for instance.
The next issue I ran into was with the Emacs editor I’ve been using for at least five years. It requires no installation, but when I ran it on 64-bit windows nothing happened – no application startup cursor, no error dialog, and no Emacs. I ran it inside Windbg to see what was going on, but it provided little help. Here’s the stack trace at process termination:
The only thing I can get from this is that for some reason the Wow64 image loader, which is responsible for kicking off 32-bit application launches, is unhappy with the image. I’d at least expect an error dialog so this looks to me like a bug in the loader. I went to the web and downloaded a more recent version of Emacs for Windows that runs without problem.
Since I came originally from the UNIX world I’m used to keyboards that have a control key in place of the caps-lock key on PC keyboards. The very first tool I wrote for Windows NT back in mid-1996 addresses this problem. Ctrl2cap is a simple keyboard filter driver that converts the caps lock key into a left control. Since 64-bit Windows doesn’t run 32-bit drivers my typing was initially crippled, making a port of Ctrl2cap to 64-bits a top priority. The driver port only took a couple of minutes because there was just one variable cast that the 64-bit compiler didn’t like. Porting the Ctrl2cap installer utility that configures Ctrl2cap’s driver for activation was a different story.
My original goal was to have one installer that would work on both 32-bit and 64-bit versions of Windows. The executable would therefore have to be 32-bit and so I thought I might get away with no work at all. However, I ran into a mechanism called folder redirection: when a 32-bit image accesses the \Windows\System32 directory the Wow64 subsystem redirects it to \Windows\Syswow64 (think about that for a second: 64-bit binaries are in System32 while 32-bit binaries are in Syswow64). Here’s a Filemon trace of the 32-bit command-prompt performing a directory list of “\Windows\System32”:
This prevents 32-bit applications from overwriting the 64-bit system files and configuration stored in \Windows\System32. I wrote the Ctrl2cap installer to copy the Ctrl2cap driver to \Windows\System32\Drivers, which meant that when I ran it on 64-bit Windows the driver was copied to the wrong place (this resulted in a system with a dead keyboard, which I resolved by using the Last Known Good boot option).
I really wanted to avoid having separate 32-bit and 64-bit installers, so I spent time digging through my April 2005 copy of MSDN Library in search of an API that would let the installer override the redirection. I also spent some time investigating the behavior of the folder redirector and discovered what I believe is a bug. If you launch the 32-bit Command Prompt (both 32-bit and 64-bit versions ship with 64-bit Windows) and “cd” into \Windows\System32 you are really in \Windows\Syswow64. Now if you execute “start cmd.exe” you launch another copy of the 32-bit Command Prompt. The system information APIs, which Process Explorer makes use of, report the new cmd.exe’s image as being \Windows\Syswow64\Cmd.exe, but if you execute “start c:\windows\system32\cmd.exe” you get a new 32-bit Command Prompt with the system information APIs reporting the image path as \Windows\System32\Cmd.exe! Now you can’t trust the system information APIs. In the end I gave up and posted the 64-bit Ctrl2cap update with both 32-bit and 64-bit installers.
The fact that I had to post two different executables, as I’ve had to do for the other Sysinternals tools that have required 64-bit ports and that I’ve ported to 64-bit, like Filemon, Regmon and Process Explorer, highlights what I believe is a deficiency in the 64-bit loader. It should be possible to simply concatenate 32-bit and a 64-bit images together in the same file. These multi-platform images would run without change on 32-bit Windows, which would simply view them as 32-bit executables with some stuff added on the end. The 64-bit loader would require a very minor change to support them where it could quickly determine that such an image has several executables within it and launch the 64-bit version. Microsoft implemented a similar approach during the transition from the DOS image format to the Windows image format (Portable Executable) where a DOS stub built into every 32-bit image reports “This program cannot be run in DOS mode.” when executed by the DOS image loader. No change was made to the DOS loader to support that. Other operating systems that support 32-bit and 64-bit hardware support multi-image files and there are many cases, like for my tools, where it would make life easier in Windows.
A few days after I posted the new 64-bit Ctrl2cap, David Solomon , who heard my Ctrl2cap installer griping, wrote to tell me that in the Windows Server 2003 SP1 Platform Software Development Kit (SDK) “what’s new” section he came across an API named Wow64DisableWow64FsRedirection . The API does what its name implies and I promptly posted (source code included) a new Ctrl2cap with a single 32-bit installer. However, this brought to my attention the way that Microsoft is handling the Platform SDK.
First, I’m an MSDN Universal subscriber, yet I never received a copy of the Windows Server 2003 SP1 Platform SDK. When I went on-line to look for it in MSDN subscriber downloads I first went to Tools, SDKs and DDKs->Platform Tools, SDKs, DDKs->Platform SDK. There are two “latest” versions posted there: the November 2002 Edition and the Windows XP SP2 Platform SDK. There’s no sign of the Windows Server 2003 SP1 Platform SDK, which is over in Tools, SDKs and DDKs->Platform Tools, SDKs, DDKs->Windows Server 2003.
So the first problem is that instead of one Platform SDK, there are now three different versions. Second, there’s no single place to go find them, and third, the April release of the MSDN Library, which is the one shipped to MSDN subscribers, doesn’t include the latest SDK documentation (the on-line version of the library does include it). Microsoft should have a single Platform SDK and keep the MSDN Library that’s shipped to subscribers in sync with the Web version. But I digress.
Another Microsoft application I installed is Microsoft Antispyware (MSAS). The install went without problems, though MSAS is not really 64-bit ready. It’s a 32-bit application and is therefore subject to Wow64 Registry redirection on parts of the Registry, including HKLM\Software, which redirects to HKLM\Software\Wow6432Node. While MSAS will detect 32-bit spyware and adware configured to autostart, it won’t detect 64-bit malware. Sysinternals Autoruns also currently suffers this limitation.
Throughout the week I ran into a small number of other issues. For example, if you launch a process under the Visual Studio 6 debugger and then stop debugging the process is left as a zombie. The Borland Delphi 2005 debugger has a more serious issue: when you launch a process under the debugger it believes that the process exits immediately when the process actually starts properly. A workaround is to attach the debugger to the process after its launched. Finally, there are no 64-bit drivers for the iPod and no 64-bit CD burning software that I know of. For synching my iPod and burning CDs I use my previous desktop, a 32-bit system.
All in all, the 64-bit everyday OS experience has been pretty painless, and with a few exceptions, totally seamless.
Originally by Mark Russinovich on 5/7/2005 1:05:00 PM
Migrated from original Sysinternals.com/Blog
# re: Running Everyday on 64-bit Windows
Mark,
This post here should help getting MSN DS installed, though like you said, it may still not function properly.
http://geekswithblogs.net/bpaddock/archive/2004/12/14/17500.aspx
Also, the 2003 DDK will be shipped as part of the June MSDN shipment as per http://msdn.microsoft.com/subscriptions/new/default.aspx
I hear you about the 3 disks, but to expect a shipped and online product to be synched is not a gripe a agre with. The downloads allows Microsoft to get the product out instantly, but it requires time and coordination t opress the thousands of MSDN CD's and get it out to subscribers. Usually a product is on CD 2 months after release (i.e. April web release = June CD release).
5/8/2005 11:00:00 AM by Karan Mavai
# re: Running Everyday on 64-bit Windows
Surely the APIs that appeared in the Server 20003 SDK have been planned for release for more than two or three months. There's no excuse for it not to have been in the April release of the library.
5/8/2005 11:03:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
FYI, there are a number of CD and DVD burning programs that support Windows x64, including Nero .
5/8/2005 12:41:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
The 32-bit cmd thing isn't a bug - by design. Why we didn't just have a system64 directory for 64-bit OS binaries is beyond my simple ability to understand. I suspect that the goal was to have customers compile all of their old code into 64-bit binaries and (as much as possible) have things "just work". People have been known to hard-code "system32" into their paths instead of programmatically discovering where the system directory is. If that was the case, then there would have to be a way to special-case for actual 32-bit binaries running under emulation and . . .
It all seems really counterintuitive. All I can do is shrug and accept it at this point.
There are SDK docs about the redirection for 32-bit apps on 64-bit Windows here:
http://msdn.microsoft.com/library/en-us/win64/win64/running_32_bit_applications.asp
Pretty much anything you want to know about this is available (for free - no MSDN sub needed) on the web at/near the above link.
-Drew
5/8/2005 10:03:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
I agree, after all, going from Win 3.x and the System subdirectory to Win95 and System32 worked fairly well, why shouldn't the same procedure work now (i.e. establishing System64 for 64-bits apps).
The feear of hardwired System32 paths in existing apps can be cured equally well by FSRedirecting the 64-bits app to System64, not the other way around as it is today.
/Henry
5/9/2005 12:02:00 PM by Henry
# re: Running Everyday on 64-bit Windows
To get pesky installers to work on Win2k3 you can use Orca from the Platform SDK to edit the MSI package. There's a rule in the database for version checking which usually just need a quick edit. I've never run into a problem Orca can't fix when straight AppCompat doesn't work. The 5.1 vs. 5.2 is going to bite MS for years to come...
5/9/2005 12:41:00 PM by cb
# re: Running Everyday on 64-bit Windows
I am wondering if people will run into a few issues to do with the version number being identical between the 32bit windows server 2003 sp1 and the 64bit windows xp release.
And slap me if I'm wrong, but since the version is being displayed as;
Version 5.2 (Build 3790.srv03_sp1_rtm.050324-1447 : Service Pack 1)
My guess was that the breakdown is;
srv03 is the notation for the OS and the rtm point was 2:47pm PDT ( GMT-8 ) on the 24th of march 2005, on build number 3790.
How could the kernal possibly be identical from XP 64 bit to Server 2003 32 bit?
If they're different, and my previous assumptions are correct, is that the luckiest build number and most productive minute ever in Microsofts history?
5/9/2005 5:14:00 PM by rivet
# re: Running Everyday on 64-bit Windows
Rivet -
Windows Server 2003 and Windows XP "x64 Edition" are both build on Windows NT 5.2 (build 3790), with Service Pack 1 (build 1830).
The 5.2.3790 number remains the same regardless of SP1's presence. Service Packs always have their own build numbers.
Both the 32-bit and 64-bit version of Windows Server 2003 (along with the "XP Professional" edition) come from a common codebase. They're simply compiled with different options.
5/9/2005 6:58:00 PM by Brandon Paddock
# re: Running Everyday on 64-bit Windows
Hi Mark,
Great post. I believe the function Wow64DisableWow64FsRedirection() would definately help you in your later developmental efforts.
5/9/2005 11:33:00 PM by Rafael Rivera
# re: Running Everyday on 64-bit Windows
Unfortunatly it's the same for microsoft Virtual PC, doesn't want to install on windows xp 64 bit, hope the service pack brings some help.
5/9/2005 11:55:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
You should upgrade to VMWare v5. It supports both 32-bit and 64-bit Windows as the host OS and it has other useful features such as snapshot trees, cloning and movies.
5/10/2005 9:27:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
I noticed you mentioned a debugging problem with Delphi 2005. We've tried to reproduce this problem here at Borland and have not had any success. Is there something that we are missing? What type of application are you debugging? Is this a Win32 or .NET application?
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/10/2005 4:58:00 PM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I'm actually debugging an MMC snapin DLL written in Delphi so I launch mmc.exe under the Delphi debugger. Mmc.exe launches successfully, but the debugger does not attach to it.
5/11/2005 9:27:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Thanks for the information, Mark. We're investigating this here.
Correct me if I'm wrong, but isn't mmc.exe a 64-bit application? (I don't have a 64bit system with me right now) If it is, then I can understand that our 32-bit debugger would have problems ;-)... In that case as well, wouldn't MMC snap-ins need to be 64-bit?
Although, you did mention that you're able to manually attach to the process. I suppose that would indicate that there is a 32-bit process around somewhere...
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 11:18:00 AM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I've investigated further and its a Windows problem, not Delphi's: when you launch the 32-bit mmc.exe it launches the 64-bit mmc.exe and exits. If you are loading a 32-bit snapin the 64-bit mmc.exe launches the 32-bit mmc.exe again and exits.
Thus, the process launched under Delphi has exited. If you set the option to debug child processes Delphi complains (some Ole error) when it tries to debug the 64-bit mmc.exe child process.
5/11/2005 11:26:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Aha.. That explains it. So, it would seem that there should be a way to directly launch the 32-bit mmc.exe so that your 32bit snap-in is loaded immediately. Possibly a command-line switch? I presume this is what the 64-bit mmc.exe is doing when it tries to load a 32bit snap-in.
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 11:52:00 AM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I am launching it directly, but it relaunches the 64-bit version anyway. Looks like Windows bug since there's no way to launch the 32-bit mmc.exe directly. The only way to launch it is to specify an .msc file that loads a 32-bit snapin and even then the load process goes mmc 32-bit->mmc 64-bit->mmc 32-bit.
5/11/2005 4:08:00 PM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Ah, I figured it out: you can launch the 32-bit mmc.exe directly if you specify its path (\windows\syswow64\mmc.exe) and include the /64 command-line option.
5/11/2005 4:10:00 PM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Thanks! That's some very good information to know, Mark. I've made an entry to my blog about this whole thing in the hopes that my readers can benefit from this information as well.
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 6:09:00 PM by Allen Bauer
# re: Running Everyday on 64-bit Windows
Totally unrelated to the topic at hand _BUT_
A number of the links at the main web site don't work as of 12 May
2005 (2pm UK time), eg for
the handle utility, debugview etc..
Mike Diack (mike_diack@hotmail.com)
5/12/2005 8:21:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Mark,
What you thing about features OS W2k and higher. like Keyboard remap? It is realize with only registry record...
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00.........
instead of Ctr2Cap?
hint: in google
site:www.microsoft.com "Keyboard Layout"
5/17/2005 2:37:00 PM by Sergey Dindikov
# re: Running Everyday on 64-bit Windows
Mark,
How did you make the combined 32/64 bit version of Process Explorer?
Chris
6/3/2005 8:59:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
Maybe someone here can help me. I'm running x64 XP and I've loaded the Windows 2003 sp1 adminpak. When I launch MMC, I don't have an option for adding the 'Distrubted File System' snap-in as well as some others. In fact, when I open the 'Computer Management' shortcut, I get a prompt which indicates that there are 16 of 21 snap-ins available for the 64-bit and 12 of 21 for 32-bit. Thoughts on how I can load the 'Distrubted File System' snap-in as well as some of the others I seem to be 'missing'? Also wanted to make the comment that Virtual Server 2005 sp1 (in beta) supports x64 host systems (both 2003 & XP). One other thing I noticed is that the 32-bit version of IE is the 'default browser' instead of the 64-bit one.
8/23/2005 10:54:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Delphi 7 seems to have the same problem with the debugger, that is, when exiting a program run from within the IDE, delphi hangs itself. (Not all on programs, and not event all the time.....)
Disabling the "integrated debugger" and all works fine....
9/10/2005 11:29:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Hi Mark,
respect to all work you did.
Do you have idea where are the unsigned driver files stored inside XPx64?
When i install some device, it all works but i cannot find the driver physical file at all :-)
9/22/2005 12:43:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Mmm, just wonder, if there is any sence in using 32bit Windows on 64bit platform? I mean, can 32bit Windows utilize any features, that only 64bit platform provides?
Thank you for interesting article and whole blog :)
Denis
11/8/2005 11:23:00 AM by Denis
# re: Running Everyday on 64-bit Windows
It is difficult to understand the problems everyone seems to be having with XP 64. I have been running XP 64 for several months. It is installed on a system with an A8V motherboard with an Athlon64 3500+. There is 1 GB of Kingston hyperx RAM and two Seagate 7200.8/120GB drives. XP 64 installed flawlessly and has been working without issue for about five months. I have been able to find almost all the drivers that I need and I have been able to find 64-bit versions of software with few exceptions. The exception is drivers for my HP all-in-one printer. This version of XP will work well with most newer hardware. It will probably not work well on older systems because of the driver issues. I suspect that there are some issues that have not run across yet. If you need some assistance don't hesitate to contact me. I will help if I can.
3/5/2006 11:56:00 AM by Millineumman
# re: Running Everyday on 64-bit Windows
for burn support under itunes you can download a beta x64 driver here:
http://www.gearsoftware.com/support/drivers.cfm
6/13/2006 5:08:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
Maybe it's a little too late to comment but the ISORecorder by Alex Feinman (http://isorecorder.alexfeinman.com/isorecorder.htm) and the standard XP recorder should solve most of the CD burning needs, unless you require something non-standard.
But you are no ordinary man, so, I don't know your needs.
I'm writing about the x64 platform too, nothing too technical, just everyday usage and problem solving. I'm studying to make progress on debugging and support.
8/5/2006 6:55:00 PM by Doca
# re: Running Everyday on 64-bit Windows
Thankfully Canon came out with drivers for x64 a few months ago, and they work perfectly. The big problem people are having is VIVO support from NVidia which should come as part of their WDM drivers, a seperate download from the usual GeForce drivers. But NVidia hasn't released a new WDM driver in over a year, clearly busy with things like thier XBox contract. Meanwhile, ATi has WDM drivers for x64. I just will not wait any longer even if I've been with NVidia exclusively for nearly a decade.
9/16/2006 11:39:00 PM by Anonymous
Last week I got an HP xw9300 workstation equipped with two 2GHz Opteron processors, the same type of system most of the Windows kernel team uses. The system came with 32-bit Windows XP preinstalled, but I decided to buy into all the 64-bit hype coming out of Microsoft’s Winhec conference and so I scratched the HP image, reformatted the disk, and installed Windows XP 64-bit Edition. Is Windows ready for 64-bit full-time? After a week of development, writing, and experimenting I’m ready for a preliminary report.
The first issue I ran into was lack of built-in driver support for the network adapter and video card. This was easily remedied, though, with a quick trip to Nvidia's web site to download their 64-bit motherboard and video drivers.
After getting Windows running I spent the first few hours with the system installing applications and tools. The installations went smoothly for just about everything except for one application that I’ve come to rely on: MSN Desktop Search (MDS). It’s especially ironic that MDS won’t run on 64-bit Windows given that it’s a high-profile application from the company that’s trumpeting the official arrival of 64-bit computing and telling device manufacturers that if they don’t have 64-bit drivers they’re already behind the times. What’s even more ironic about MDS’ lack of 64-bit support is the way that its installation fails:
The installer doesn’t even know its running on 64-bit Windows. The operating system version number reported on 32-bit Windows XP is 5.1, but since 64-bit Windows XP shares the same kernel as 64-bit Windows Server 2003 SP1 it reports a version number of 5.2 as this Msinfo32 screenshot shows:
I suspect that the MDS installer believes itself to be running on Windows Server 2003 and therefore refuses to install.
I used the application compatibility tab on the installer’s properties to trick the installer into thinking it was running on 32-bit Windows XP, which resulted in the installation getting further, but it failed with the same error a little later. The second time the error message comes from the Windows Installer Service while it’s processing the MDS MSI (Microsoft System Installer) file that the first installer extracts. The installer service is likely checking the operating system version again because of instructions in the MDS MSI.
Even if I had tricked MDS into installing I would have gotten only partial functionality. On 64-bit Windows there’s no cross-interoperability between 64-bit processes like Windows Explorer and 32-bit COM DLLs like those that make up MDS desktop extensions. The taskbar search window wouldn’t have worked, for instance.
The next issue I ran into was with the Emacs editor I’ve been using for at least five years. It requires no installation, but when I ran it on 64-bit windows nothing happened – no application startup cursor, no error dialog, and no Emacs. I ran it inside Windbg to see what was going on, but it provided little help. Here’s the stack trace at process termination:
The only thing I can get from this is that for some reason the Wow64 image loader, which is responsible for kicking off 32-bit application launches, is unhappy with the image. I’d at least expect an error dialog so this looks to me like a bug in the loader. I went to the web and downloaded a more recent version of Emacs for Windows that runs without problem.
Since I came originally from the UNIX world I’m used to keyboards that have a control key in place of the caps-lock key on PC keyboards. The very first tool I wrote for Windows NT back in mid-1996 addresses this problem. Ctrl2cap is a simple keyboard filter driver that converts the caps lock key into a left control. Since 64-bit Windows doesn’t run 32-bit drivers my typing was initially crippled, making a port of Ctrl2cap to 64-bits a top priority. The driver port only took a couple of minutes because there was just one variable cast that the 64-bit compiler didn’t like. Porting the Ctrl2cap installer utility that configures Ctrl2cap’s driver for activation was a different story.
My original goal was to have one installer that would work on both 32-bit and 64-bit versions of Windows. The executable would therefore have to be 32-bit and so I thought I might get away with no work at all. However, I ran into a mechanism called folder redirection: when a 32-bit image accesses the \Windows\System32 directory the Wow64 subsystem redirects it to \Windows\Syswow64 (think about that for a second: 64-bit binaries are in System32 while 32-bit binaries are in Syswow64). Here’s a Filemon trace of the 32-bit command-prompt performing a directory list of “\Windows\System32”:
This prevents 32-bit applications from overwriting the 64-bit system files and configuration stored in \Windows\System32. I wrote the Ctrl2cap installer to copy the Ctrl2cap driver to \Windows\System32\Drivers, which meant that when I ran it on 64-bit Windows the driver was copied to the wrong place (this resulted in a system with a dead keyboard, which I resolved by using the Last Known Good boot option).
I really wanted to avoid having separate 32-bit and 64-bit installers, so I spent time digging through my April 2005 copy of MSDN Library in search of an API that would let the installer override the redirection. I also spent some time investigating the behavior of the folder redirector and discovered what I believe is a bug. If you launch the 32-bit Command Prompt (both 32-bit and 64-bit versions ship with 64-bit Windows) and “cd” into \Windows\System32 you are really in \Windows\Syswow64. Now if you execute “start cmd.exe” you launch another copy of the 32-bit Command Prompt. The system information APIs, which Process Explorer makes use of, report the new cmd.exe’s image as being \Windows\Syswow64\Cmd.exe, but if you execute “start c:\windows\system32\cmd.exe” you get a new 32-bit Command Prompt with the system information APIs reporting the image path as \Windows\System32\Cmd.exe! Now you can’t trust the system information APIs. In the end I gave up and posted the 64-bit Ctrl2cap update with both 32-bit and 64-bit installers.
The fact that I had to post two different executables, as I’ve had to do for the other Sysinternals tools that have required 64-bit ports and that I’ve ported to 64-bit, like Filemon, Regmon and Process Explorer, highlights what I believe is a deficiency in the 64-bit loader. It should be possible to simply concatenate 32-bit and a 64-bit images together in the same file. These multi-platform images would run without change on 32-bit Windows, which would simply view them as 32-bit executables with some stuff added on the end. The 64-bit loader would require a very minor change to support them where it could quickly determine that such an image has several executables within it and launch the 64-bit version. Microsoft implemented a similar approach during the transition from the DOS image format to the Windows image format (Portable Executable) where a DOS stub built into every 32-bit image reports “This program cannot be run in DOS mode.” when executed by the DOS image loader. No change was made to the DOS loader to support that. Other operating systems that support 32-bit and 64-bit hardware support multi-image files and there are many cases, like for my tools, where it would make life easier in Windows.
A few days after I posted the new 64-bit Ctrl2cap, David Solomon , who heard my Ctrl2cap installer griping, wrote to tell me that in the Windows Server 2003 SP1 Platform Software Development Kit (SDK) “what’s new” section he came across an API named Wow64DisableWow64FsRedirection . The API does what its name implies and I promptly posted (source code included) a new Ctrl2cap with a single 32-bit installer. However, this brought to my attention the way that Microsoft is handling the Platform SDK.
First, I’m an MSDN Universal subscriber, yet I never received a copy of the Windows Server 2003 SP1 Platform SDK. When I went on-line to look for it in MSDN subscriber downloads I first went to Tools, SDKs and DDKs->Platform Tools, SDKs, DDKs->Platform SDK. There are two “latest” versions posted there: the November 2002 Edition and the Windows XP SP2 Platform SDK. There’s no sign of the Windows Server 2003 SP1 Platform SDK, which is over in Tools, SDKs and DDKs->Platform Tools, SDKs, DDKs->Windows Server 2003.
So the first problem is that instead of one Platform SDK, there are now three different versions. Second, there’s no single place to go find them, and third, the April release of the MSDN Library, which is the one shipped to MSDN subscribers, doesn’t include the latest SDK documentation (the on-line version of the library does include it). Microsoft should have a single Platform SDK and keep the MSDN Library that’s shipped to subscribers in sync with the Web version. But I digress.
Another Microsoft application I installed is Microsoft Antispyware (MSAS). The install went without problems, though MSAS is not really 64-bit ready. It’s a 32-bit application and is therefore subject to Wow64 Registry redirection on parts of the Registry, including HKLM\Software, which redirects to HKLM\Software\Wow6432Node. While MSAS will detect 32-bit spyware and adware configured to autostart, it won’t detect 64-bit malware. Sysinternals Autoruns also currently suffers this limitation.
Throughout the week I ran into a small number of other issues. For example, if you launch a process under the Visual Studio 6 debugger and then stop debugging the process is left as a zombie. The Borland Delphi 2005 debugger has a more serious issue: when you launch a process under the debugger it believes that the process exits immediately when the process actually starts properly. A workaround is to attach the debugger to the process after its launched. Finally, there are no 64-bit drivers for the iPod and no 64-bit CD burning software that I know of. For synching my iPod and burning CDs I use my previous desktop, a 32-bit system.
All in all, the 64-bit everyday OS experience has been pretty painless, and with a few exceptions, totally seamless.
Originally by Mark Russinovich on 5/7/2005 1:05:00 PM
Migrated from original Sysinternals.com/Blog
# re: Running Everyday on 64-bit Windows
Mark,
This post here should help getting MSN DS installed, though like you said, it may still not function properly.
http://geekswithblogs.net/bpaddock/archive/2004/12/14/17500.aspx
Also, the 2003 DDK will be shipped as part of the June MSDN shipment as per http://msdn.microsoft.com/subscriptions/new/default.aspx
I hear you about the 3 disks, but to expect a shipped and online product to be synched is not a gripe a agre with. The downloads allows Microsoft to get the product out instantly, but it requires time and coordination t opress the thousands of MSDN CD's and get it out to subscribers. Usually a product is on CD 2 months after release (i.e. April web release = June CD release).
5/8/2005 11:00:00 AM by Karan Mavai
# re: Running Everyday on 64-bit Windows
Surely the APIs that appeared in the Server 20003 SDK have been planned for release for more than two or three months. There's no excuse for it not to have been in the April release of the library.
5/8/2005 11:03:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
FYI, there are a number of CD and DVD burning programs that support Windows x64, including Nero .
5/8/2005 12:41:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
The 32-bit cmd thing isn't a bug - by design. Why we didn't just have a system64 directory for 64-bit OS binaries is beyond my simple ability to understand. I suspect that the goal was to have customers compile all of their old code into 64-bit binaries and (as much as possible) have things "just work". People have been known to hard-code "system32" into their paths instead of programmatically discovering where the system directory is. If that was the case, then there would have to be a way to special-case for actual 32-bit binaries running under emulation and . . .
It all seems really counterintuitive. All I can do is shrug and accept it at this point.
There are SDK docs about the redirection for 32-bit apps on 64-bit Windows here:
http://msdn.microsoft.com/library/en-us/win64/win64/running_32_bit_applications.asp
Pretty much anything you want to know about this is available (for free - no MSDN sub needed) on the web at/near the above link.
-Drew
5/8/2005 10:03:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
I agree, after all, going from Win 3.x and the System subdirectory to Win95 and System32 worked fairly well, why shouldn't the same procedure work now (i.e. establishing System64 for 64-bits apps).
The feear of hardwired System32 paths in existing apps can be cured equally well by FSRedirecting the 64-bits app to System64, not the other way around as it is today.
/Henry
5/9/2005 12:02:00 PM by Henry
# re: Running Everyday on 64-bit Windows
To get pesky installers to work on Win2k3 you can use Orca from the Platform SDK to edit the MSI package. There's a rule in the database for version checking which usually just need a quick edit. I've never run into a problem Orca can't fix when straight AppCompat doesn't work. The 5.1 vs. 5.2 is going to bite MS for years to come...
5/9/2005 12:41:00 PM by cb
# re: Running Everyday on 64-bit Windows
I am wondering if people will run into a few issues to do with the version number being identical between the 32bit windows server 2003 sp1 and the 64bit windows xp release.
And slap me if I'm wrong, but since the version is being displayed as;
Version 5.2 (Build 3790.srv03_sp1_rtm.050324-1447 : Service Pack 1)
My guess was that the breakdown is;
srv03 is the notation for the OS and the rtm point was 2:47pm PDT ( GMT-8 ) on the 24th of march 2005, on build number 3790.
How could the kernal possibly be identical from XP 64 bit to Server 2003 32 bit?
If they're different, and my previous assumptions are correct, is that the luckiest build number and most productive minute ever in Microsofts history?
5/9/2005 5:14:00 PM by rivet
# re: Running Everyday on 64-bit Windows
Rivet -
Windows Server 2003 and Windows XP "x64 Edition" are both build on Windows NT 5.2 (build 3790), with Service Pack 1 (build 1830).
The 5.2.3790 number remains the same regardless of SP1's presence. Service Packs always have their own build numbers.
Both the 32-bit and 64-bit version of Windows Server 2003 (along with the "XP Professional" edition) come from a common codebase. They're simply compiled with different options.
5/9/2005 6:58:00 PM by Brandon Paddock
# re: Running Everyday on 64-bit Windows
Hi Mark,
Great post. I believe the function Wow64DisableWow64FsRedirection() would definately help you in your later developmental efforts.
5/9/2005 11:33:00 PM by Rafael Rivera
# re: Running Everyday on 64-bit Windows
Unfortunatly it's the same for microsoft Virtual PC, doesn't want to install on windows xp 64 bit, hope the service pack brings some help.
5/9/2005 11:55:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
You should upgrade to VMWare v5. It supports both 32-bit and 64-bit Windows as the host OS and it has other useful features such as snapshot trees, cloning and movies.
5/10/2005 9:27:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
I noticed you mentioned a debugging problem with Delphi 2005. We've tried to reproduce this problem here at Borland and have not had any success. Is there something that we are missing? What type of application are you debugging? Is this a Win32 or .NET application?
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/10/2005 4:58:00 PM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I'm actually debugging an MMC snapin DLL written in Delphi so I launch mmc.exe under the Delphi debugger. Mmc.exe launches successfully, but the debugger does not attach to it.
5/11/2005 9:27:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Thanks for the information, Mark. We're investigating this here.
Correct me if I'm wrong, but isn't mmc.exe a 64-bit application? (I don't have a 64bit system with me right now) If it is, then I can understand that our 32-bit debugger would have problems ;-)... In that case as well, wouldn't MMC snap-ins need to be 64-bit?
Although, you did mention that you're able to manually attach to the process. I suppose that would indicate that there is a 32-bit process around somewhere...
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 11:18:00 AM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I've investigated further and its a Windows problem, not Delphi's: when you launch the 32-bit mmc.exe it launches the 64-bit mmc.exe and exits. If you are loading a 32-bit snapin the 64-bit mmc.exe launches the 32-bit mmc.exe again and exits.
Thus, the process launched under Delphi has exited. If you set the option to debug child processes Delphi complains (some Ole error) when it tries to debug the 64-bit mmc.exe child process.
5/11/2005 11:26:00 AM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Aha.. That explains it. So, it would seem that there should be a way to directly launch the 32-bit mmc.exe so that your 32bit snap-in is loaded immediately. Possibly a command-line switch? I presume this is what the 64-bit mmc.exe is doing when it tries to load a 32bit snap-in.
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 11:52:00 AM by Allen Bauer
# re: Running Everyday on 64-bit Windows
I am launching it directly, but it relaunches the 64-bit version anyway. Looks like Windows bug since there's no way to launch the 32-bit mmc.exe directly. The only way to launch it is to specify an .msc file that loads a 32-bit snapin and even then the load process goes mmc 32-bit->mmc 64-bit->mmc 32-bit.
5/11/2005 4:08:00 PM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Ah, I figured it out: you can launch the 32-bit mmc.exe directly if you specify its path (\windows\syswow64\mmc.exe) and include the /64 command-line option.
5/11/2005 4:10:00 PM by Mark Russinovich
# re: Running Everyday on 64-bit Windows
Thanks! That's some very good information to know, Mark. I've made an entry to my blog about this whole thing in the hopes that my readers can benefit from this information as well.
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corp.
http://blogs.borland.com/abauer
5/11/2005 6:09:00 PM by Allen Bauer
# re: Running Everyday on 64-bit Windows
Totally unrelated to the topic at hand _BUT_
A number of the links at the main web site don't work as of 12 May
2005 (2pm UK time), eg for
the handle utility, debugview etc..
Mike Diack (mike_diack@hotmail.com)
5/12/2005 8:21:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Mark,
What you thing about features OS W2k and higher. like Keyboard remap? It is realize with only registry record...
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00.........
instead of Ctr2Cap?
hint: in google
site:www.microsoft.com "Keyboard Layout"
5/17/2005 2:37:00 PM by Sergey Dindikov
# re: Running Everyday on 64-bit Windows
Mark,
How did you make the combined 32/64 bit version of Process Explorer?
Chris
6/3/2005 8:59:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
Maybe someone here can help me. I'm running x64 XP and I've loaded the Windows 2003 sp1 adminpak. When I launch MMC, I don't have an option for adding the 'Distrubted File System' snap-in as well as some others. In fact, when I open the 'Computer Management' shortcut, I get a prompt which indicates that there are 16 of 21 snap-ins available for the 64-bit and 12 of 21 for 32-bit. Thoughts on how I can load the 'Distrubted File System' snap-in as well as some of the others I seem to be 'missing'? Also wanted to make the comment that Virtual Server 2005 sp1 (in beta) supports x64 host systems (both 2003 & XP). One other thing I noticed is that the 32-bit version of IE is the 'default browser' instead of the 64-bit one.
8/23/2005 10:54:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Delphi 7 seems to have the same problem with the debugger, that is, when exiting a program run from within the IDE, delphi hangs itself. (Not all on programs, and not event all the time.....)
Disabling the "integrated debugger" and all works fine....
9/10/2005 11:29:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Hi Mark,
respect to all work you did.
Do you have idea where are the unsigned driver files stored inside XPx64?
When i install some device, it all works but i cannot find the driver physical file at all :-)
9/22/2005 12:43:00 AM by Anonymous
# re: Running Everyday on 64-bit Windows
Mmm, just wonder, if there is any sence in using 32bit Windows on 64bit platform? I mean, can 32bit Windows utilize any features, that only 64bit platform provides?
Thank you for interesting article and whole blog :)
Denis
11/8/2005 11:23:00 AM by Denis
# re: Running Everyday on 64-bit Windows
It is difficult to understand the problems everyone seems to be having with XP 64. I have been running XP 64 for several months. It is installed on a system with an A8V motherboard with an Athlon64 3500+. There is 1 GB of Kingston hyperx RAM and two Seagate 7200.8/120GB drives. XP 64 installed flawlessly and has been working without issue for about five months. I have been able to find almost all the drivers that I need and I have been able to find 64-bit versions of software with few exceptions. The exception is drivers for my HP all-in-one printer. This version of XP will work well with most newer hardware. It will probably not work well on older systems because of the driver issues. I suspect that there are some issues that have not run across yet. If you need some assistance don't hesitate to contact me. I will help if I can.
3/5/2006 11:56:00 AM by Millineumman
# re: Running Everyday on 64-bit Windows
for burn support under itunes you can download a beta x64 driver here:
http://www.gearsoftware.com/support/drivers.cfm
6/13/2006 5:08:00 PM by Anonymous
# re: Running Everyday on 64-bit Windows
Maybe it's a little too late to comment but the ISORecorder by Alex Feinman (http://isorecorder.alexfeinman.com/isorecorder.htm) and the standard XP recorder should solve most of the CD burning needs, unless you require something non-standard.
But you are no ordinary man, so, I don't know your needs.
I'm writing about the x64 platform too, nothing too technical, just everyday usage and problem solving. I'm studying to make progress on debugging and support.
8/5/2006 6:55:00 PM by Doca
# re: Running Everyday on 64-bit Windows
Thankfully Canon came out with drivers for x64 a few months ago, and they work perfectly. The big problem people are having is VIVO support from NVidia which should come as part of their WDM drivers, a seperate download from the usual GeForce drivers. But NVidia hasn't released a new WDM driver in over a year, clearly busy with things like thier XBox contract. Meanwhile, ATi has WDM drivers for x64. I just will not wait any longer even if I've been with NVidia exclusively for nearly a decade.
9/16/2006 11:39:00 PM by Anonymous