Monday, September 25, 2006
XEmacs ate my chcp command
Sometimes, but not always, I got the following error message when I tried to change code page in the Windows console (cmd.exe) on my new Windows XP Professional x64 Edition machine:
Microsoft Windows [Version 5.2.3790](C) Copyright 1985-2003 Microsoft Corp.
C:\>chcp
'chcp' is not recognized as an internal or external command, operable program or batch file.
Further investigation established the pattern that chcp was missing when I ran cmd.exe from within XEmacs but chcp was available when I started cmd.exe from the Start-menu. Some googling turned up a few hits, all involving corrupt PATH variables which was not my problem.
Instead it turns out that, thanks to the behind-the-scenes magic of the File System Redirector, on Windows XP x64 Edition there are two cmd.exe. The default one, e.g. the one you get if you start it with "Run..." from the Start-menu, is a 64bit executable (in C:\WINDOWS\system32). It has no problem running chcp. However, there is also a 32bit version. The 32bit version will not look up commands in C:\WINDOWS\system32 but instead will look in C:\WINDOWS\SysWOW64.
There is a C:\WINDOWS\system32\chcp.exe but no C:\WINDOWS\SysWOW64\chcp.exe. This explains why chcp sometimes worked (when I happened to start the 64bit cmd.exe) and sometimes did not appear to exist at all (when I happened to start the 32bit cmd.exe).
XEmacs, a 32bit program, starts the 32bit version of cmd.exe and this explains why I did not have a chcp command when running from within XEmacs. The workaround was to copy chcp.exe from C:\WINDOWS\system32 to C:\WINDOWS\SysWOW64.
Microsoft Windows [Version 5.2.3790](C) Copyright 1985-2003 Microsoft Corp.
C:\>chcp
'chcp' is not recognized as an internal or external command, operable program or batch file.
Further investigation established the pattern that chcp was missing when I ran cmd.exe from within XEmacs but chcp was available when I started cmd.exe from the Start-menu. Some googling turned up a few hits, all involving corrupt PATH variables which was not my problem.
Instead it turns out that, thanks to the behind-the-scenes magic of the File System Redirector, on Windows XP x64 Edition there are two cmd.exe. The default one, e.g. the one you get if you start it with "Run..." from the Start-menu, is a 64bit executable (in C:\WINDOWS\system32). It has no problem running chcp. However, there is also a 32bit version. The 32bit version will not look up commands in C:\WINDOWS\system32 but instead will look in C:\WINDOWS\SysWOW64.
There is a C:\WINDOWS\system32\chcp.exe but no C:\WINDOWS\SysWOW64\chcp.exe. This explains why chcp sometimes worked (when I happened to start the 64bit cmd.exe) and sometimes did not appear to exist at all (when I happened to start the 32bit cmd.exe).
XEmacs, a 32bit program, starts the 32bit version of cmd.exe and this explains why I did not have a chcp command when running from within XEmacs. The workaround was to copy chcp.exe from C:\WINDOWS\system32 to C:\WINDOWS\SysWOW64.
Friday, September 22, 2006
Windows reparse points. Not so transparent after all.
We use NDOC to build some of the documentation for our Windows product. I recently moved to a new machine with Windows XP x64 Edition and this was the first time I tried to build the docs after the move. I got the following strange error:
Error: Could not find file "C:\SOMEDIR\JavaDoc\JavaDoc.css"
Turns out that C:\SOMEDIR is in fact a junction point, i.e. a reparse point, and is really C:\OTHERDIR. Apparently this somehow confused NDOC (or whatever .NET functionality NDOC is using). Running from the real folder C:\OTHERDIR made the problem go away.
Of course I knew that C:\SOMEDIR is a junction point but this never caused a problem before. I got the clue as to the cause of the problem by running Filemon from
Sysinternals. Selecting "Log Errors" showed a lot of operations as failing with REPARSE in the Result-column. These failures may actually be normal when traversing a reparse point but it was the hint I needed to try running from a real folder.
Error: Could not find file "C:\SOMEDIR\JavaDoc\JavaDoc.css"
Turns out that C:\SOMEDIR is in fact a junction point, i.e. a reparse point, and is really C:\OTHERDIR. Apparently this somehow confused NDOC (or whatever .NET functionality NDOC is using). Running from the real folder C:\OTHERDIR made the problem go away.
Of course I knew that C:\SOMEDIR is a junction point but this never caused a problem before. I got the clue as to the cause of the problem by running Filemon from
Sysinternals. Selecting "Log Errors" showed a lot of operations as failing with REPARSE in the Result-column. These failures may actually be normal when traversing a reparse point but it was the hint I needed to try running from a real folder.
