DIR command in XP does not display Chinese correctly in English Windows

This is a very annoy issue I have just come across mistakenly believing XP being a Unicode OS and that its DIR command will display any characters you can create mirroring that in the Windows Explorer.

Such is not the case. While this post discusses issues with the DIR command in XP in handling Chinese characters, the problem applies equally to other languages.

I have a test file like this shown in Windows Explorer:

In CMD the DIR command returns this:

Which is not what I want or expect. So what is the reason behind this? I thought PowerShell being a .Net implementation of a shell can surely handling this. Despite following these advices, it produces the same result as above.

It turns out that the DIR/CMD uses non-Unicode API to display the file name as a result one has to change the "Language for non-unicode programs" in "Regional and Language Options" via the Control Panel to the Chinese code page as follows:

With this setting, the DIR command displays the file name correctly:

Just to prove the point, I then use the chcp command to change the code page to 1252 and this produces the following result:

Which is what we have got before.

While the DIR displays the file name incorrectly, if you starts CMD with the /U switch and you redirect the DIR output to a text file, the content of the text file is in full Unicode and the Chinese file name is displayed in say Notepad correctly.

So the moral of the story is that you must set the "Language for non-Unicode Programs" to the correct code page in order to produce visually correct file name in the DIR. This has no effect on batch file or redirection if you launches the CMD with the /U.

Instructions to set up Limited User Account in Windows 7

This contains an excellent step-by-step instructions on how to:

• Disable the built-in administrator account and why it is best to leave it disabled.
• Set up an account purely to do system administrative work, such as installation
• Set up a limited user account for normal usage.

If you prefer offline reading you can download a copy from here.

This sentiment is perfectly correct and explains precisely why so many people dislike Vista and I suspect grudgingly by now Windows 7:

But even with the more modern Windows NT systems, Windows 2000, and Windows XP, it was so painful to really get your work done as a non-administrative user that most people simply gave up and ran with an Admin account. This was almost entirely due to poor habits by software developers: they themselves ran as Admins, and they simply wrote sloppy code that assumed everybody was one too.

I have been operating XP in LUA for years doing all sorts of development without difficulties. Initially yes, there is a learning curve but that actually is very beneficial because it teaches you the security model and let you feel the presence of the security envelop. You also experience the security side of a particular technology. In the end producing a more secure program.

I think Vista and Windows 7 are on the right track. I would love to see the file and registry virtualization removed to force developers to be more careful and not to be misled.

Copying Or Moving Subversion Repositories

Recently, I had to replace the hard drive on which my collection of repositories live. Rather than using the subversion recommended way, I used XCopy to transfer the collection from my old drive to the new in Windows XP, after making sure no one is using the FSFS. I have nearly lost the lot.

The result was corrupted repositories and when I tried to commit files to one, it reported the path to ...\db\transactions\74-24.txn not found and refused to commit. ...\db\transactions was definitely missing.

This is the command with the switches I used:

XCOPY <source> <destination> /h /o /c /v /k /s

It is the last switch /s that was the culprit. It only copies non-empty directories and files. In svn, you can have empty directories (such as db\transactions) and files with zero bytes. As a result, they were not transferred across.

The correct switch is the /e that will copy empty directories and zero-byte files. So to copy them correctly use the following switches:

XCOPY <source> <destination> /h /o /c /v /k /e

There are two methods that I have found to be more reliable and easier to use.
1) Use Windows XP's NTBackup tool
This is the most reliable way of backing up the entire repository and restoring them. It should be used as a matter of course. I am wondering how well the Win7 replacement of this tools works? Vista's one is totally useless.

2) Use 7za.exe
Make sure Windows users use * to specify all files instead of the Windows' *.* convention for all other commands and to include the -r switch.

XP Control Panel Applet does not launch - a solution

I was playing with a Virtual Machine containing a copy of XP SP3 and no matter which user account I was in, I could not launch the applet from the Control Panel. However, I could launch the CPL from command line, for example AppWiz.cpl.

AppWiz.cpl is also an interesting one as one can also supply additional commandline options to support other facility, such as add/remove Windows components. A complete command line looks something like this:

"C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\shell32.dll,Control_RunDLLAsUser "C:\WINDOWS\system32\appwiz.cpl",Add or Remove Programs

Obviously the cpl files were not corrupted. So I was intrigued and determine to find out why.

I decided to use ProcMon to monitor the operations on the faulty machine, in particular, on the launch operation of Rundll32.exe by Explorer.exe. At the same time, I used the same program to monitor the operations on a machine that was working properly. Then I could find out the reason by patiently comparing the two log file entries.

In the captured log file, I jumped to the "Process Create" entry of Explorer which was responsible for launching the Rundll32.exe process as my starting point. The properties, in particular the command line for Rundll32.exe, immediately gave me the clue. On the faulty machine, there was no command line argument to Rundll32.exe and that explained why double-clicking on a control panel applet did nothing except launching Rundll32.exe and then it immediately terminated itself as nothing to do.

Looking back up the operations sequence, the next clue to look for was the exefile's open command as this was the operation that composed the command line argument to launch an executable such as Rundll32.exe.

This is specified in:

HKCR\exefile\shell\open\command\(Default)

On the working machine, the value was:

"%1" %*

But on the faulty one, it had this:

"%1"

The absence of %*, which meant to append the rest of the command line arguments, explained why the faulty machine did not launch the correct control panel applet as it failed to include any command line argument after the first one, which was Rundll32.exe.

Appending the %* to the exefile's open command fixed the problem.