When talking about application compatibility and mitigations, virtualization is almost always mentioned as part of the discussions. This could be machine virtualization or application virtualization. And, to tell you the truth, the application virtualization part is one that I, and many others, are really trying to sort out. For me, the challenge is that it appears to depend on having an entire infrastructure set up. While I would like to just set up an application bubble and just poke at it to see how it is implemented, setting up that infrastructure to do so has simply exceeded the amount of free time I have in a day (even if I put my phone on mute and work during conference calls ... oops, did I say that out loud?). So, I really rely on others for this information.

One question that came up along the way: can you shim a SoftGrid application?

The others (who I was depending on) poked around a bit, and they ended up saying no.

However, just the other day, yet another other said yes. This person indicates that the trick is to run sdbinst.exe with each SoftGrid package that you pull down, reapplying the fix each time within the SoftGrid bubble.

So, I've now had to replace my "I have no idea if you can shim SoftGrid virtualized apps, but from what I've heard you can't" with "I have no idea if you can shim SoftGrid virtualized apps, but from what I've heard you can." It's still hearsay, but at least I got some directions for you to try. For those of you already working on things, though, since I had a set of directions, I figured I'd share what I've heard, rather than saying "you need to wait until I try it before I report on it" - which is normally what I try to do, but in this case, it could still be a while...

Updated 01-May-2008

I've been pointed to this KB article for an example of how to script something into a Softgrid virtualized app: http://support.microsoft.com/kb/939896.

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:\windows\system32\advapi32.dll. It's going to match c:\program files\my app\source 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.

The other day, I had somebody send me an email from the contact form here which was asking about a Windows API I almost never see, but nonetheless could come in handy in some scenarios.

Let's talk about these scenarios.

With Windows Vista, more people than ever are running as a standard user. For the IT Pro, we have a number of shims available to take applications that have dependencies on administrator rights and remove some of these dependencies. For developers, we have guidance for updating an application to run correctly as a standard user.

But ... what if you are a developer writing your own code, but you are also using third party code as part of your product - and it's the third party code that has the problem? And what if you don't have the source code? While we don't prevent developers from shipping shims with their application, we do really discourage it. But, in this scenario, what do we encourage as the alternative?

And, for one specific scenario, it turns out that there is an API that can really come in handy if your problem is in the registry. That API? RegOverridePredefKey (in advapi32).

Say, for example, that the third party code you are leveraging in your application is doing runtime registration of a COM object into HKEY_CLASSES_ROOT. As a non-admin, that doesn't work so well. An IT Pro could shim that with VirtualizeHKCRLite, but developers don't generally like to take that approach. Instead, you could use this API to remap this predefined key.

Here's an example:

HKEY hKey;
DWORD dDisposition;
// Comment this section out to turn off registry redirection and hit HKCR
HKEY hNewKey;
RegCreateKeyEx(HKEY_CURRENT_USER, L"Software\\RegOverridePredefKey", NULL, NULL, REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hNewKey, &dDisposition);
RegOverridePredefKey(HKEY_CLASSES_ROOT, hNewKey);
// End override section
LONG fCreateKey = RegCreateKeyEx(HKEY_CLASSES_ROOT, L"LUA Bug Registry Key", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_WRITE, NULL, &hKey, &dDisposition);
if (fCreateKey == ERROR_SUCCESS) {
    MessageBox(0, L"Registry key created.", L"LUA - Registry", MB_OK | MB_ICONINFORMATION);
} else {
    MessageBox(0, L"Could not create registry key.", L"LUA - Registry", MB_OK | MB_ICONERROR);
}
RegCloseKey(hKey);
RegCloseKey(hNewKey);

If you call this API a second time, passing NULL as the second parameter, you can reset the key mapping back to the default. This can be a handy trick if you are trying to fix up third party code that is the final LUA bug on your way to making an application work as a standard user and your third party control seems to be struggling to get a version that doesn't depend on admin rights.