Joe's Random Ramblings

Some time back, I wrote about problems with the Windows ShellExecute/ShellExecuteEx functions if the filepath is longer than the predefined value of MAX_PATH.
The workaround I described was to use the short path name instead of the long path.
The Windows API has a function for that, GetShortPathName.
However, I recently found out that this function is broken, at least on Vista.
Apparently, the GetShortPathName function doesn't really get the short path by looking at the data on the disk. Instead, it seems to blindly truncate the full directory- and filenames, and appends ~1 at the end of each component. This works by accident on XP, but can result in problems on Vista.
To illustrate: Vista has directories C:\Program Files and C:\ProgramData. The short names of these directories are C:\PROGRA~1 and C:\PROGRA~2, respectively.
Using GetShortPathName on a path that starts with C:\ProgramData\..." results in "C:\PROGRA~1\...", though, as I found out during a debugging session.
This is of course completely unacceptable, and renders the GetShortPathName function unusable.
Typically, the MSDN documentation doesn't say anything about this...
And then MS wonders why they are hated by everybody...

Like a lot of people, we are using VMWare in development to test our programs.
For way too long now, I have been battling with VMWare Workstation 5.5 having a clock that's running way too fast in the guest OS.
VMWare nowadays has some knowledge base articles about it, e.g., here and here.
From these articles, I understand that the problem has to do with the power management on the host machine, which in my case is Windows XP.
There are also several threads in the VMWare forums about this problem, here and here.
I have done what was suggested in these threads, in particular, I have disabled the "Cool & Quiet" setting in the BIOS. Unfortunately, the BIOS for my Dell Dimension E521 doesn't have any way to change the HPET.
Despite all of this, the guest OS still runs too fast when the host machine has been idle for some time (e.g., over night). Since I am trying to run timing tests over night, that's pretty much a killer for me...
I am really wondering why VMWare hasn't fixed this yet.

Update: AMD has what they call a "Dual-Core Optimizer" utility. That finally seems to have solved the problem. I installed it, and kept the VM running over the weekend. And lo and behold, the clock in the VM still runs fine this Monday morning.

Working with the Windows ShellExecute and ShellExecuteEx APIs and the CreateProcess API I have come across a major annoyance:
The directory and filename passed into these APIs can not be longer than MAX_PATH (i.e., 260) characters.
This is particularly idiotic given that Microsoft nowadays uses fairly long directory names, e.g., C:\Documents and Settings\All Users\Application Data.
Furthermore, the ShellExecute(Ex) documentation does not even state this limit.

Anyway, I did find a way around it:
Microsoft maintains both long and short names for files and directories, even on NTFS.
So, the long path C:\Documents and Settings\All Users\Application Data is equivalent to the short path C:\Docume~1\alluse~1\applic~1
This way, the path to the batch file I was trying to execute was cut down from 261 characters to 106 characters.