First posted to MSDN on Apr, 14 2009
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.
