It’s visible in the beta, but I haven’t heard a lot of people talking about this externally. Regardless, I wanted to shed some light on what happened, and add a bit of the human perspective behind the decision.
If you inspect the operating system layers (called Compatibility Modes in Compatibility Administrator), you’ll find that they contain an important new entry: AdditiveRunAsHighest. Let’s explore this a bit, because it’s pretty important what it does.
RunAsHighest
First and foremost, AdditiveRunAsHighest is RunAsHighest. (We’ll get to the Additive part in a bit.) It’s an incredibly confusing elevation flag for many folks. It basically means that, if you have the ability to elevate to a higher token, then please do. Otherwise, just stay where you are. That means, if you’re a member of the Administrators group with UAC turned on, and you’re not currently running elevated, you’ll see a prompt. If you are a standard user, you will not. If you have the SeLoadDriver privilege in your token but would otherwise be a standard user, we’ll still split your token, and if you provide the same credentials, we’ll elevate to a token that contains that privilege. (You can’t think too black and white about elevation – not everyone is cleanly either an admin or a standard user.)
I say that it’s confusing because most people don’t fully grok that. Most people, rather, believe that MMC.exe requires being an admin, and that’s why it prompts. It doesn’t require it, you just happen to have a more privileged token available so it’s going to try to use it. If you were running as a standard user, you wouldn’t see a prompt!
OK, so we’re off to a good start – the new shim is related to the most confusing elevation flag we’ve got. How have we made that more interesting?
AdditiveRunAsHighest
If you’re an IT Pro, you’ll like this: you always get to win. You see, a developer can specify, in the XML manifest for an application, the run level for that application. But you, as the IT Pro, get to overrule that. If you think the developer made a bad call with their specified run level, just specify what you think, and you’ll win.
But AdditiveRunAsHighest means that you only care to vote if the developer didn’t. So, if you find a manifest specifying run level, you’re voting to take what they asked for. If not, then you are asking for RunAsHighest.
(I guess I find that a little curious because, if you know enough about Windows Vista to add a runlevel to the manifest, it’s not entirely clear why you would need an XP or earlier shim, but so it goes.)
Putting it all together
What this basically means is that, if you were running as a standard user, and you didn’t work, the RunAsHighest will leave you as a standard user, and unless file/registry virt fixes you, you’re still broken. No regression. But, if you were previously a full admin, and now you’re a protected admin, you’ll prompt to get back to full admin, and away you go.
If only it were that simple. But, realistically, nobody is super happy with this outcome. This doesn’t represent what we wanted to do, it represents what we could do in the parameters we were given (which included, of course, the parameter of, “we have to ship an operating system”).
Elevation fixes ~20% of broken applications that used to work on XP
There are truths, half-truths, and statistics. This is a statistic. That’s the bright side. The down side is that the other 80% of applications aren’t fixed by elevation (actually it’s more like 50% when you incorporate this PLUS other fixes in the layer, so that’s a little unfair of me), yet they are prompting you anyway! But, in the absence of other alternatives, it was decided that people are more annoyed by apps not working than they are by prompts. Oh yeah, we know you’re still annoyed by prompts – we just think you’re more annoyed by broken apps.
And, when it came down to it, even if the number of apps fixed were 10%, it would have been a no-brainer for the team. Broken apps are a serious downer.
What does it mean for me?
Well, if you’ve built up a custom shim database that contains operating system emulation layers, their behavior is going to change. You may want to edit them. I typically recommend that you chose only the specific shims that you need, rather than taking a whole layer, and I’d just go that route.
If you’re fiddling with the compatibility tab, it means you’re going to get more prompts.
Several Program Compatibility Assistant scenarios lead to the XPSP2 layer, which will mean more prompts even if you don’t get geeky on us.
It also could mean that more apps work, if you are a consumer with little knowledge of elevation, tokens, administrators, or any of that garbage, and just want your apps to work. That’s who we’re really targeting with this. Someone advanced enough to find the compatibility tab (or lucky enough to have PCA suggest fixing something) but not advanced enough to be reading this and looking to become a shim ninja.
What we would rather do
Like I said, this was a trade-off. And, honestly, a few folks were pretty up in arms about this (and I count myself among them) until we finally got people to stop suggesting that this was a solution people actually were quite fond of and shouldn’t we just drink the kool-aid and believe that it truly was good for us, and instead fess up that they fought it themselves but just couldn’t get it done in the ideal way so had to find the best compromise for the non-ideal choices that lay before them.
We’d rather have a quick, automated way to put in a targeted fix that didn’t mean “keep running as admin” and instead did something less reckless. But that’s hard to do. (Aaron Margosis seems like he’s coming pretty darned close, though – just give him time.)
If we’re going to elevate, we’d like to have a way to kill the prompts somehow. (Aaron won’t be so fond of that one.)
In the end, it’s all a balancing act. Unlike milk, software doesn’t go bad. You shouldn’t have to go buy a new version of something until it offers features that make you happy (or, these days, until you can afford it). But how do we move the software ecosystem forward, without making you pay the price?
I keep saying this, I know, but it keeps being true: app compat is hard.
If you come to me for advice about how to become a debugger, chances are that I’m going to give you a couple of must-read reference books, an then tell you to start paying attention. Because, unless you’re drastically more lucky than I am, stuff is probably breaking on you all the time. While a lot of problems just go away, if you let it just go away, you’ve just squandered an opportunity to debug something.
The only way to become a master at debugging is to practice. A lot.
But there’s a level even above master debugger – being somebody able to get to the bottom of most every issue (eventually – hey, even for the best, it can take time, lots and lots of time). What’s that level? The Power Debugger. Somebody who dispenses with the need for time, and just fixes things quickly because there is no alternative.
How do you reach that level?
Simple.
Have a 4-year-old.
Four year olds don’t care about the challenges application compatibility. They just want their games to work, and they are quite vocal when they don’t. They look at you thinking, “why can’t you fix this? Aren’t you supposed to be able to do this? Can’t you see this is bothering me?” Oh, and then the cry. And yell. And cry. Great.
Fortunately, the solution for pre-school games is typically rather easy. For reasons that are completely beyond comprehension to me, it turns out that many developers of games for pre-schoolers assume that I want my 4-year-old to be an administrator on my computer.
RunAsAdmin, and we were on our way. Optimal solution? No. But you have to power debug with a 4-year-old.
So that leads me to this:
If you develop commercial games for pre-schoolers, I will help you debug your application so it works for standard users for free. But you have to promise to run your developer workstation either as a standard user, or as a protected administrator (that’s right, turn UAC back on) on Windows Vista or later.
Every application should run as a standard user. But games for children should have run for standard users even on XP.
The new ACT is here! The new ACT is here!
I’m always on the forefront of breaking news, eh? We shipped ACT 5.5, erm, 11 days ago. (What can I say, it’s been a busy 11 days.) I know a little while back I blogged about whether or not you can wait for it, but now you don’t have to. Nice.
So, I figured I’d talk about a few things that makes this a very worthwhile download. But before I do, I figured you should understand the size of the team that managed to pull this off. The dev team, if I am not mistaken, averaged just slightly over 1 person. The test team averaged less than 1 person. The PM team averaged over 1 person. The documentation team averaged a fraction of a person. Clearly, some trade-offs are required with this kind of a team, and hopefully we made the right ones. (My #1 request remains adding integration points so you can extend the product and/or integrate it with the rest of your infrastructure, but that’s big stuff that a tiny team isn’t likely to pull off. I keep hoping.) That being said, here’s what I like about what’s new:
DCP Tagging
This is one of the most requested features in ACT (other than integration points), and you can use this in a number of ways.
If you are planning to deploy Windows by role (in my experience the best way to do it), you can have your DCPs that you deploy to members of each role tagged. Now, when you want to see what software is used by people in each role, you simply pull up everything with this tag. You just can’t do that with 5.0. The closest you’d come is to collect the first role first, categorize them, then the second role, categorize the uncategorized ones, and so forth. But, if you change deployment order, you’re hosed; you depend on apps being fixed from earlier roles, because you can’t determine the overlap.
If you have multiple organizations that you serve, but you don’t want to manage separate databases (perhaps a loosely aligned collection of business units?) you can now consolidate but still pry things apart as you need to.
Identifying the remainder of scenarios is left as an exercise to the reader – this one is really something you can invent all kinds of uses for.
SUA Works with Application Verifier 4.0
Remember the post where I had to link to old versions of Application Verifier? No more! Now you can use the up-to-date version! And, of course, that also means you can use SUA on Windows 7 now (since AppVerifier 3.x doesn’t work so well on it).
SUA kinda-sorta works on Windows 7 x64
OK, 64-bit isn’t officially supported for ACT anywhere. But SUA flat out didn’t work. I don’t know about Windows Vista (I never tried it) but definitely not on Windows 7. The reason? AppVerifier had a little bug (they’re fixing it, but they weren’t going to be done in time for ACT 5.5 and we didn’t want to delay it) where the COM interfaces weren’t working correctly from 32-bit processes. And SUA happened to be calling them from 32-bit processes. So, we brainstormed some alternate solutions, but because you have to call 32-bit AppVerifier to get 32-bit logs, the avenue we finally pursued was using the command line interface to AppVerifier instead of the COM interface. So, things mostly work for testing 32-bit apps on x64 versions of Windows 7 (to my knowledge) – I have not tried it against 64-bit apps, because I’ve never needed that in real life. This is not a guarantee that ACT will work for you on 64-bit, that using it on x64 won’t cause permanent sterility, yada yada. But hey, there were some last-minute heroics on the part of the team to at least give best effort here, and they blew me away. The team may be small, but that doesn’t mean they’re not awesome.
CompatAdmin has more shim docs in the help, and it now shows you help … ALL the time!
This was my pet peeve bug. I guess that’s because the tiny contribution I make was affected by it. You see, I write up the shim documentation, and then hand it off to my favorite technical writer, Liz, who converts them into product-ese. And yes, we have more in ACT 5.5. (What can I say – I have the most boring hobby in the world. Writing documentation.)
But, if you use 5.0, you’ll notice a little something funny. Select a shim in the system shim database (which is where all the shims are). Notice that little sentence. Is it helpful? Maybe, but probably not. What do you do next? Well, hopefully you look it up in the help. Try it. Guess what? The help –> about functionality is disabled! This bug was open forever, so I used the oldest trick in the book. I debugged it myself. That gets stuff fixed WAY faster. Here’s what I found:
0:000> kP ChildEBP RetAddr 000be9d4 00134dac USER32!EnableMenuItem( struct HMENU__ * hMenu = 0x075b08ad, unsigned int uIDEnableItem = 0, unsigned int uEnable = 0x401)
Look that up in MSDN, and you’ll find that the code was disabling the first item of EVERY menu, when it intended to just disable the first item in the first menu. And help was unfortunate enough to be the first menu item. Fixed. Now, you can always get to the help!
Nice.
You don’t have to see reports for operating systems you aren’t migrating to.
When we supported one type of migration, piece of cake. It’s all we’d show. But we got to the point of having so many flavors, it was just confusing. So, now you can pick the ones you care about. Subtle, but a nice touch.
Those are the highlights. Have a look. Yes, we do support some additional deprecation detection (Windows Mail), but in my experience that’s an extremely low-impact deprecation for the enterprise. And there are a number of other bug fixes. Not a bad showing for a tool developed by 3.141592653589793238462 643383279502884197169399375105820974944592307816406286208998628 034825342117067982148086513282306647093844609550582231725359408 128481117450284102701938521105559644622948954930381964428810975 665933446128475648233786783165271201909145648566923460348610454 326648213393607260249141273724587006606315588174881520920962829 254091715364367892590360011330530548820466521384146951941511609 people.