A question came up via comments. (I was going to say that it came up recently, but another glance reveals that it came up in, oh, June. I don’t think I can fairly call that recent…)
“…the fix seems only to work if the directory structure exists…”
This is true, and worth noting. If you point the fix to a directory which doesn’t exist, the shim won’t create the directory, it will just fail, in much the same way the application would fail if it were trying to create an application in a directory which didn’t exist (which, to Windows, appears to be exactly what happened). So, if you’re planning to shim an application and want to create a directory to store things, you should consider creating this directory at install time.
When you come across issues debugging applications, there are typically several ways to solve them. Today, I'm going to pick on our own stuff and throw a few different shims at it. Interestingly enough, what I'm going to be shimming up will be the tool I use to create shims: Compatibility Administrator. That's right - I'm going to shim up my shim tool.
What's the bug?
--------------------------- Compatibility Administrator --------------------------- You do not have administrative rights. Some features might be disabled. --------------------------- OK ---------------------------
Yeah - I don't enjoy warnings like that, and I certainly don't need them every time.
Solution #1: shim up CompatAdmin.exe with RunAsAdmin. That makes the MessageBox go away because it actually is an admin.
What else could we do? Well, we could figure out which functionality need admin rights. Sitting there using the product non-elevated, I counted two broken features. First, I can't right click and disable a shim. Second, I can't install a shim database.
I don't really need to disable things often, and it seemed to me that installing is something that could be factored out. In fact, a quick glance at Process Monitor tells me that installing a shim database already is factored out! CompatAdmin.exe just calls sdbinst.exe. Is it calling it using CreateProcess (which would require ElevateCreateProcess) or ShellExecute(Ex)? ShellExecute. Nice. So, in theory the think I need to do actually should work just fine, except the software is stopping me from doing it!
--------------------------- Compatibility Administrator --------------------------- You need administrative rights to perform this operation. --------------------------- OK ---------------------------
A big fat LUA Bug in our own stuff. It stops me from doing something that works because it doesn't believe it does. Nice work. Let's lie to it.
Solution #2: shim up CompatAdmin.exe with ForceAdminAccess. The dialogs go away, and I can still do what I actually want to do - right click install works just fine, and prompts me when I do that. I then end up running less code elevated, and being more secure. I can read existing databases without elevations. What a huge win! (Well, except not being able to turn shims off, which may be interesting from time to time, but for the vast majority of what I do, this is a great solution.)
Are we done yet, or is there another way to skin this problem?
Well, these are messageboxes. We can suppress them one last way.
Solution #3: shim up CompatAdmin.exe with IgnoreMessageBox (parameter You do not have administrative rights. Some features might be disabled.,Compatibility Administrator). We'll get that to stop annoying me! It still shows the MessageBox when I try to install a database (which is not helpful) but if I suppress that one also, then it just does nothing and says nothing, which is arguably not a very good outcome. But at least it's a touch less chatty. I'll chalk this up as the worst solution.
Personally, I've been using ForceAdminAccess lately. But I thought this was a fun app to show the options available, particularly since you need to shim CompatAdmin somehow to make it useful. (Yeah, I know - that's kind of ridiculous and we should fix it. The bug has been open for over a year - I just poked the team again.)
I haven't seen these pop up yet - if you're looking for a quick demo of several of the tools available to assist in a Windows Vista deployment, you may enjoy the following 10 minute demos:
http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Application_Compatibility_Demo.wmv
http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Assessing_Hardware_Readiness.wmv
http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/MDT_Install_and_Image_Creation.wmv
http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/Migrating_User State.wmv
http://download.microsoft.com/download/D/6/9/D6943262-EF5A-4733-8247-9BF7A6FEF299/System_Center _Essentials.wmv
It's been a couple of months since we released the Windows Vista Compatibility Center, and while I meant to discuss it at the time, it's still worth a little chat.
I talk quite a bit about the tools to test for application compatibility, sharing debugging tips, and shedding some light onto the secrets of shimming up misbehaving apps. The fact remains, however, that although you can fix a huge number of things (and hopefully I can help you figure out how), the fact that you can fix things up may not be relevant. If you need the vendor to support it, the fact that it's shimmed means, almost by definition, that it doesn't truly work on Windows Vista without a little help. And the fact that it doesn't truly work almost always means that it's unsupported. And the fact that it's unsupported almost always means that some people simply won't run that version.
Now, the original idea we had for Windows Vista was to introduce a new level of certification. One that was so easy, and so inexpensive, that everyone would want to collaborate to indicate compatibility. We called it the Works With Windows Vista logo. You don't have to pass any tests, and you don't have to enlist the help of a 3rd party tester to verify those tests. It's so easy, who wouldn't do it?
And, as it turned out, most everybody wouldn't do it. The original plan was to wire things up to ACT to pass this logo information through, automate the application matches, and help accelerate the process of determining support. As you have probably figured out, that didn't work out so well.
So, we had to scramble to create a Plan B. If developers weren't coming to us, but the enterprise still needed help, fine. We'd come to them. We hired some folks to start scouring ISV web sites to find support statements, and we published links on a site we stood up called appreadiness.com. It kind of looked cobbled together, because it was, but it was better to have something.
While we filled that up, we were working on a more eloquent looking solution - something we called the Windows Vista Compatibility Center. This is the new site.
Are we done helping you with this data yet? Absolutely not! First of all, you may have noticed that ACT is still looking at the sparse certification data, and not this new source of information. So, clearly we have to wire that up. We also need to better support automating the matching for people who don't want to submit what apps they have (which ACT does to fetch the compat data for those apps), so we need to figure out how to make the data available offline. And wouldn't it be interesting to have this as a web service to feed other tools?
So, while there's clearly more work to come to make this easier and to work better with our partners and the software ecosystem, I thought it was worthwhile to reflect on where we are, how we got here, and where we're going.
It seems like just yesterday I was posting about ACT 5.0.2 being released, but we just released ACT 5.0.3.
Now, I've had a couple of people confused about the version numbers we talk about, and what they actually see. For, rather unfortunately, you didn't see 5.0.2 anywhere in the last one, nor will you see 5.0.3 in the new one. Why don't we do you the honor of showing that in the help - about? As it turns out, we branched way back when at RTW, so the Main branch lived on, while the RTW branch was where we finished things up. As it turns out, the 5.0.1, 5.0.2, and 5.0.3 updates where all released off of the RTW branch, so 5.0.5428.x has remained the naming convention, and we have just kept incrementing the build number.
ACT 5.0.2 == 5.0.5428.1056
ACT 5.0.3 == 5.0.5428.1080
So, that being said, what's new in the 1080 release?
Major Bug Fixes:
SUA:
ACM:
It does require you to uninstall the old toolkit first, and then install the new one. The schema changed, so you'll have to upgrade your database also (warning if you've got apps or scripts crawling around in there). Hopefully it's helpful!