Most organizations around the world were
heavily invested in Windows XP for many years by the time Windows Vista
was released. Application developers were producing products just for
Windows XP. Driver developers often only considered Windows XP. When
organizations tried to deploy Windows Vista, they started having issues.
Many of the driver issues were resolved over time. But one major issue
prevented many organizations from deploying Windows Vista: LOB and other
critical applications just would not work on Vista. Vista did change
how Windows worked quite a bit. Those compatibility issues did not go
away with Windows 7. In fact, it's likely that Windows 7 will behave
almost identically as Windows Vista with legacy applications. It seems
that many of the causes for application failure weren't due to these
changes. Here are some examples:
Despite a huge public testing program prior to the release, many application developers chose not to get involved.
These developers either believed that
Vista would not be successful enough or they bought into the myth that
the subsequent release of Windows would be a return to the XP-style
operating system.
Many developers or application publishers either moved on or went out of business.
This prevented willing customers from being able to upgrade or repair incompatible applications.
Many customers who used applications chose not to upgrade their applications to Vista-supported versions.
Customers cited reasons such as compatibility issues with other systems or lack of available funding.
Many legacy applications require you to have administrative rights.
Users tried unsuccessfully to update things like
the Windows folder or secure locations in the Registry or the file
system. Windows Vista introduced User Account Control (UAC). When you
log in as an administrative user, you are given two tokens. The first
gives you administrative rights. The second is a standard user token.
UAC tries to protect your computer by logging you in with that standard
user token. This can cause issues with those applications requiring
administrative rights if users do not know how to interact with UAC.
Some developers didn't heed the best practice advice from Microsoft when developing their software.
A very basic example of this is when an application checks the operating system version. The check might be something like if OperatingSystemVersion not = 5.1 then fail.
That meant the application would only work on XP, even though every
other feature of the application would be fine on Vista. Sometimes
developers tried to "fix" bugs they found in XP through their
application. Microsoft fixed those bugs in Vista, and this caused the
application to behave in an unexpected manner.
Microsoft released ACT with Windows Vista to aid in
detecting known incompatible applications, testing others, tracking your
process, and developing workarounds for issues. ACT aided in resolving
many of the issues but not all of them. There were two problems with
this solution:
Despite Microsoft's efforts, not many people know about ACT. You cannot use what you do not know about.
Sometimes an application just cannot be made to work on anything but Windows XP.
Over time Microsoft stepped up its efforts. As the
release of Windows 7 approached, those efforts increased. Version 5.6 of
ACT was released in conjunction with Windows 7. It increased your
ability to resolve issues using workarounds referred to as mitigations, or shims.
But you still had those few occasions when ACT wasn't able to help or
perhaps wasn't appropriate when you needed a quick fix. Microsoft took
its desktop virtualization product, Virtual PC, and redeveloped it as an
application compatibility solution. Windows Virtual PC for Windows 7
allows you to run a free (on the business editions) copy of Windows XP
Service Pack (SP) 3 Professional as a virtual machine (VM). You can
install your XP applications in XP Mode and access them through seamless
windows on your Windows 7 installation using shortcuts on the Windows 7
Start menu.
|
The two words are interchangeable. When you talk to
an application compatibility person, they use the word "shim." The ACT
applications use the more formal "mitigation."
|
It appears now that for almost every application out
there, you should have a way to get it working on a Windows 7 PC.
When you set out working on the application
compatibility issue, you will need to have a process. Every organization
will have a different process. Figure 1 shows you a sample process that you can use.
The process starts with identifying the applications
found in the organization. From there you need to work out whether each
application found is compatible with Windows 7. If the application is
compatible, then no further work is required. If it isn't, then you try
to fix it by either upgrading or rewriting the application so that it
does support Windows 7. If neither approach works, you will have to
create a mitigation or shim to "trick" the application into thinking
that it is working on Windows 7.
If that doesn't work, you then move on to using
virtualization. You attempt to install the application in a VM that's
running a legacy operating system such as Windows XP. Microsoft's XP
Mode is a free (to those who have a Business, Ultimate, or Enterprise
edition of Windows 7) and pretty clever solution. It provides a Windows
XP VM that runs on the Windows 7 computer. The end user might not even
notice that it's running on their PC because their Start menu icons for
the XP Mode applications appear on the Windows 7 Start menu and the
applications run in seamless windows, hiding the XP VM in the
background. This strategy can increase administrative workloads because
there is another operating system to install, manage, and secure.
A similar solution is Microsoft Enterprise Desktop
Virtualization (MED-V), which is a part of the Microsoft Desktop
Optimization Pack (MDOP), a suite that is available to customers (for a
fee) if they have acquired Software Assurance as a part of their
licensing. MED-V provides a centrally managed VM that is distributed to
user computers. The VM can run a legacy operating system, such as
Windows XP, and can be installed with legacy applications that will not
work on Windows 7.
Another solution is to use Remote Desktop Services
(previously called Terminal Services). You can run centralized machines
with a legacy operating system such as Windows Server 2003, install the
applications there, and provide Remote Desktop access for your users.
These virtualization solutions come at some
cost, be it licensing or additional management, but they allow you to
provide access to functional legacy applications until you find a
version or alternative that will work correctly on Windows 7.
