Jump to content


  • 0
anyweb

Making Applications Compatible with Windows 7 in a Virtualized Environment

Question

Making Applications Compatible with Windows 7 in a Virtualized Environment

by Chris Jackson

 

Microsoft Application Virtualization (App-V) 4.6, boasting full support for Windows 7, is right around the corner; many customers who are planning a Windows 7 deployment are including App-V among the components of their desktop transformation project. (An OS deployment is frequently combined with an overhaul of both applications and infrastructure in a “modern desktop” or “next-generation desktop” initiative.)

 

When IT professionals think about pairing investments in App-V and Windows 7, the following questions almost always come up as part of the conversation:

 

* I heard that App-V is an application-compatibility solution. Does that mean it will help make my applications compatible with Windows 7?

* Will I need to re-sequence the App-V packages I have already created for my current Windows XP desktops?

* What do I need to do to remediate incompatible applications when I use App-V as my deployment solution?

 

Let’s explore each of these questions.

Is Microsoft App-V an Application-Compatibility Solution?

 

Microsoft App-V is, first and foremost, an application management and deployment solution that can convey significant benefit to the enterprise—reducing packaging costs, increasing system stability, and supporting today’s highly mobile workforce with dynamic access to software assets. But as part of the marketing messaging, the overloaded term application compatibility grew to be misinterpreted over time: that App-V could help with compatibility problems between the application and the OS. For the most part, it can’t. (The exceptions today exist mostly for historical reasons, and are not something to depend on, so I won’t go into the details here.)

 

The resulting customer confusion has led to some clarification in the messaging; we now forego use of the term “application compatibility” and instead speak directly to the underlying benefits: that you reduce application-to-application conflicts (note the strategic omission of the word compatibility), and that, as a result, you significantly reduce regression testing.

 

The official stance of the product team on application-to-OS compatibility is this:

 

As noted in prior discussions, App-V is not a general purpose application-to-OS compatibility solution; however, if an application compatibility shim allows an app to work on a given Windows version natively (non-virtualized), it will in most cases, and for most shims, work with App-V when the shimmed app is virtualized. Thus, as a general rule, App-V will support app use with shims that are provided as part of Microsoft’s App Compat tools as long as the shimmed application can run natively on the targeted OS version.

 

So, it’s pretty clear that App-V isn’t intended to be an application-to-OS compatibility solution. (We will discuss combining shims with App-V later in this article.) Let’s look at the other impacts that application virtualization has on OS compatibility.

Is Microsoft App-V a Package-Compatibility Solution?

 

When we talk about application compatibility, it’s fair to separate package compatibility from runtime compatibility. In fact, our recommended process for application-compatibility testing (shown in Figure 3 of my June 2009 article on Planning Your Application Compatibility Project) separates install testing from runtime testing. Let’s start with the official product team guidance:

 

It is often possible to sequence on one OS and run the virtualized app on a different OS; however, this scenario is both app- and OS-dependent and is not guaranteed to work for all app/OS combinations because App-V is not a general purpose OS compatibility solution. If problems are encountered, the customer may be required to sequence on the same OS environment as the App-V client is running in order to resolve those problems.

 

OK, so this doesn’t sound so promising—the official stance is, basically, “it depends.” But when you’re thinking about measuring risk, compare the three primary setup technologies in use today:

 

Setup.exe: This runs arbitrary code, and thus the arbitrary code is subject to the same potential runtime problems that the arbitrary code of the application itself is, so it will have to be thoroughly tested.

 

Windows Installer: This also runs code to execute an install, but much of this code is structured, declarative code. Only the imperative code of custom actions is arbitrary, so outside of quantifiable changes in rules that affect the processing of code running against the database and the arbitrary code in custom actions, you expect better (though still not perfect) compatibility and less testing.

 

Microsoft App-V: This doesn’t have to run code at all. It just copies over a blob of data that is the virtual file system, and then says “OK, your virtual file system is here.” So, your primary concern isn’t whether the application will install (copying one blob of data is, after all, really easy), it’s the runtime compatibility of the application. So, you expect install testing to be shortest of all three technologies. That’s goodness!

 

So, while nobody is officially going to say that packages will all work, it seems the primary reason for the messaging is that many people conflate install issues and runtime issues. In general, you can look to reduce your projected costs of application installation testing significantly if you have already invested in Microsoft App-V.

How Do I Fix Runtime Compatibility Issues When my Application Is Packaged with Microsoft App-V?

 

Remember the tantalizing bit from the support statement? “App-V will support app use with shims that are provided as part of Microsoft’s App Compat tools….” How do you actually implement that? Are the two fundamentally compatible?

 

The answer is, fortunately, yes. In fact, you have a couple of different options for doing so.

A Brief Primer on Shims

 

For those of you who are unfamiliar with shims, a shim is one of the very few four-letter words in use by Microsoft that isn’t an acronym of some sort. It’s a metaphor based on the English language word shim, which is an engineering term used to describe a piece of wood or metal that is inserted between two objects to make them fit together better. In this particular case, the two objects are the application program and Windows, and the shim material is additional code that causes the two to behave better together, as shown in Figures 1 and 2.

 

read the rest > http://technet.microsoft.com/en-us/magazine/ff458340.aspx

Share this post


Link to post
Share on other sites

0 answers to this question

Recommended Posts

There have been no answers to this question yet

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.