A while back, I write about the Correct File Paths shim. Since that time, I've heard from a number of folks who are using the shim, helping them to configure the command line to fix applications (with the most common explanation being to "quote the pairs" - enclose each redirection pair in quotes, not each individual path, and then space-delimit the pairs you want to redirect).
But there is one specific scenario that seems to be cropping up from time to time - the lack of wildcard support. And where this really makes things complicated is in the root of C.
Say, for example, that you have an application that drops c:myapplog_20080405_152438.log as the log created today, at this time. This happens quite a bit. Some people go down the path of using the command line "c:;%userappdata%" and notice that this leads to the application being even worse off than before. That's because loading up anything off the disk - data files, program files, etc. is a file operation, and gets this shim. (You can configure somewhat the APIs that are intercepted for this particular shim.) Then, keep in mind that c: is going to match absolutely everything on the drive. Yes, it's going to match c:myapplog_20080405_152438.log. It's also going to match c:windowssystem32advapi32.dll. It's going to match c:program filesmy appsource data.mdb. You get the point. The application you shim with this command line is pretty much guaranteed to just crash and burn, because suddenly it can't find any files at all.
In this particular case, you have a workaround. You could use the command line "c:myapplog_;%userappdata%myapplog_ and we'll fix that right up. But what if it's truly completely random? What if sometimes it's c:a1b2c3.log and another time it's c:u3c8e5.log. What do you do then? Unfortunately, the lack of wildcard support means you can't just use "c:*.log;%userappdata%*.log" - and, in fact, you really can't use this shim. Which means you really can't fix this application using shims.
I've seen this enough times to open a bug, and I can get that looked into for a future full version of Windows. But with Windows Sustained Engineering, we don't like to change Windows between releases without justification of business impact. So, if the lack of wildcard support in this shim means you can't fix an application and you're going to end up delaying your deployment of Windows Vista, feel free to use the link on this blog to contact me, and send me (with your work email address) the name of your organization, the application (if it's commercial - otherwise you can just state the nature, you don't need to share anything proprietary with me), and the number of users who can't go to Windows Vista because you can't fix it. Or just post a comment here that expresses the value you'd see in having wildcard support. Whatever you feel comfortable doing - I just want to give you an opportunity to have a voice.