Skip to main content

Discovering 16-Bit Applications Before Migrating to 64-Bit Versions of Windows 7

Back in 2009, I wrote an article on my blog about how to detect 16-bit applications present in your existing ACT inventory. Andreas Stenhall, one of our Windows Expert IT Pro MVPs, brought this to the forefront again in last month's edition of the Windows for IT Pros Insider, taking my SQL query and writing some new text around it, reminding people of their ability to leverage existing data for new uses, even if this data isn't surfaced through the ACT user interface. But, the benefit of a couple of extra years with customers has led me to believe that this isn't the end of the line for this problem—it's still not perfectly solved.

When you think of the business questions you are trying to answer with this data, they are:

  • How many of my applications contain 16-bit code?
  • Which modules are 16-bit?
  • What do I do about that?

As for which of the applications contain 16-bit code, there's an immediate optimization, which Andreas notices but I think we should fix: it includes plain text files (such as .bat or .cmd files). Since those aren't 16-bit, then we should just go ahead and pull those out. They may be interesting, but not for this problem domain. I also think we could generate two different result sets—one which just includes the apps, and another that includes the details:

USE ACT56
GO


SELECT Applications.appName, COUNT(Static_App_Properties.fileName) AS numberOfFiles


FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash


WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND fileModuleType<>'UNKNOWN' AND propertyType='File'

GROUP BY Applications.appName


ORDER BY appName
GO


SELECT DISTINCT Applications.appName, Static_App_Properties.fileName, fileModuleType


FROM Static_App_Properties
INNER JOIN Application_Instance_Files
ON Static_App_Properties.identity_hash = Application_Instance_Files.filePropertyID
INNER JOIN Applications
ON Application_Instance_Files.appID = Applications.identity_hash


WHERE fileModuleType<>'32BIT' AND fileModuleType<>'64BIT' AND fileModuleType<>'UNKNOWN' AND propertyType='File'

ORDER BY appName
GO



The first result set makes is much easier to determine how many of your applications contain some 16-bit code; you merely have to count them (and, as an added bonus, it counts the number of 16-bit modules found). In my database, I found that I had 34 out of 1175 applications which contained some 16-bit code. So, I was better able to answer my first question: I have 16-bit code in 2.8% of my application portfolio.

Note, however, that I wouldn't necessarily just want to use this base query. You see, I have found 16-bit applications in my entire portfolio with this query—it does not include any rationalization work which I may have done! I could choose either to extend the query to include links to categories, and exclude my rationalization categories (which is how I personally implement rationalization), or I can just go and manually add these to the applications which I've chosen to keep in Application Compatibility Manager. Given that my SQL skills are somewhat atrophied, and there were only 34, to me it was fastest to do it manually. (Automation only pays off if you can amortize the effort to create the automation over enough instances of applications!) So, with a bit of automation and a bit of manual effort, I've been able to determine where I have 16-bit code. The second result set answers the second question - which modules should I look at? Now, on to the third question...

Now that I know where I have 16-bit code, what do I do with this data?

If you answered "go and remediate the app," you're probably going to end up spending more money than you need to. You don't know that it's broken! Once again, the general principle that automation tends to do better at answering technology questions than business questions comes into play. We also find ourselves victim to one of the shortcomings of static analysis: it can only tell you that the binary is there; it won't tell you if the application ever needs to execute the 16-bit component it chose to install. (You shouldn't interpret this as me not liking static analysis just because it isn't perfect. I also love bacon, despite its excessive caloric load.) For example, Adobe Reader 8 turns up a single 16-bit binary (SC_Reader.exe). I have run Adobe Reader 8 on many 64-bit systems. Clearly, that component wasn't invoked. Skype 4.0 also appears on my list, but it appears to package an icon into an exe (SkypeIcon.exe) and I doubt that executable code is ever called from this binary. In fact, many of the exes I found look as if they won't be a problem at all; the trained eye can spot those quickly.

So, once again, we find that application compatibility is best done with a triumvirate: good people, good tools, and a good process. The tools alone can lead to significant waste. Here, we optimize the use of our tools, and then apply our minds to come up with the fastest way to our ultimate goal: deployment.

Given that this is my second take on the problem, I'll just point out that I still think this could be better! I consider application compatibility to be an awful lot like academia. You can teach ideas, or you can take existing ideas and extend them in new and interesting ways. For we all stand on the shoulders of giants - and application compatibility is somewhat unique in that we don't have to keep our knowledge proprietary in order to make a living; there are more than enough broken apps to go around! So, how could you make this better still?

Top Tasks

About the Author

Chris Jackson photoChris Jackson, aka " The App Compat Guy," is a Principal Consultant and the Technical Lead of the Windows Application Experience SWAT Team. A widely recognized expert in the field of Windows application compatibility, Chris has created technical documentation, training, and service offerings used inside and outside of Microsoft based on years of real-world experience with enterprise customers and independent software vendors.

Chris is the author or co-author of numerous technical papers and articles on the subject of application compatibility, and a contributor to TechNet Magazine. He is also a featured speaker at major industry conferences around the world, including Tech•Ed, IT Forum, and the Microsoft Management Summit.

Related Resources

Stay Informed

Want to receive early access to Windows tips and tricks, as well as insight into exclusive events and upcoming technical resources?

Sign up for the Windows for IT Pros Insider newsletter.