Skip to main content

Discover 16-bit applications before migrating to 64-bit versions of Windows 7

Applies to: 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?

Additional resources

About the author

Chris Jackson photoChris "The App Compat Guy" Jackson is a Principal Consultant and the worldwide lead for application compatibility at Microsoft, specializing in Windows, Internet Explorer, and Office internals. Jackson is a widely recognized expert in the field of application compatibility, creating technical documentation, training, and service offerings used inside and outside of Microsoft and based on years of real-world experience with enterprise customers and independent software vendors. Author or co-author of numerous technical papers and articles, he is also a featured speaker at major industry conferences around the world and publishes a popular blog.


Downloads

Windows 8.1 Enterprise Evaluation

Microsoft Deployment Toolkit

Windows Assessment and Deployment Kit

Training

Demos and tutorials

Microsoft Virtual Academy

TechNet Virtual Labs

Support

Top support solutions

Windows IT Pro forums

Microsoft Knowledge Base

Events & Errors

Stay informed

Windows IT Pro Insider

Windows for IT Pros blog

Windows for IT Pros on Twitter

 

Related sites

Internet Explorer TechCenter

Windows Developer Center

Windows Server

Windows Enterprise