Watch out for some programming issues in Vista.

Now that I have Windows Vista installed and running, albeit only as a test platform, I have discovered some programming pitfalls that are not among the major issues reported. So, as a service to my readers, here are two unexpected issues that my affect the operation of some programs under Vista.

First, the standard C function, tmpfile(), does not function correctly in the more restrictive LUA (Limited User Account) of Vista, nor probably of XP. The tmpfile() function is (supposed to be) a portable routine for creating a temporary file. Unfortunately, the Visual C++ 6 implementation (at least) attempts to create the file in the program directory, to which a program no longer has write access, as opposed to a temporary directory elsewhere. The result is, simply, that the function fails. Honestly, this is not a very common function in most code, but this problem does affect some cross-platform libraries, such as certain builds of the (commonly used) JPEG library from the Independent JPEG Group, rendering some (but not all) JPEG files unreadable.

The other undocumented issue is with the Win32 API function, ShellExecute(), which is commonly used (and the recommended way) to launch document and executable files, including external web pages, from within another program. The behavior of the Vista implementation of ShellExecute() does not match that of Windows XP or earlier versions of Windows, in that it no longer recognizes a slash (/) as a directory separator. In other words, attempting to launch a file named “game/setup.exe” will work in XP and fail in Vista, whereas “game\setup.exe” (or, rather, “game\\setup.exe”, as a C string constant) will function correctly in both situations. Of course, the obvious workaround is to simply replace slashes with backslashes, but that does not help the applications that are already shipped and installed, and now broken by Vista.

I will acknowledge that this sort of problem creeps in with any operating system change by pointing out that I recently found a nice crash bug in Windows 98. If you create a dialog box with no controls, intended as a container, and then explicitly create a control with the dialog box as a parent (i.e., add a control), the program will crash in USER32 as soon the dialog box is displayed. The workaround is simply to add a hidden control to the container dialog box template, but trying to figure out why a simple call to ShowWindow() would crash a program is more than a little frustrating.

Now you all know how I spent the last couple of weeks.