As the enterprise adoption rate of Windows® 10 strengthens, organizational heads and IT administrators are realizing the pain points associated with operating system migration, including the incompatibility of older, legacy application installers built to be used on earlier versions of the Windows OS.
Windows Background
Microsoft has undoubtedly grown its computer operating system (OS) market share since releasing Windows 10 to both personal and enterprise users in 2015. As the enterprise adoption rate of Windows 10 closes in on the 50% mark1, many organizational heads and IT administrators are realizing the pain points associated with OS migration, especially as they pertain to the incompatibility of older, legacy applications built to run on earlier versions of the Windows OS. These days, it seems like almost every large organization has at least some number of legacy applications lying around, sometimes dating as far back as the early 1990s. While some of these applications may function on Windows 10 or Windows Server 2019, there is not a reliable method to migrate the software from previous Windows environments. As we near the Windows 7 end-of-support deadline of January 2020, more and more enterprises are seeking solutions to salvage their existing legacy software as they seek out the resources to rebuild or replace their business-critical apps.
During a typical software installation process, applications are deployed to the target operating system using installers. While myriad software programs exist specifically for the creation of “installer packages”2, they are all designed to achieve three basic goals:
- check requirements
- deploy assets
- deploy configurations3
Although most installer packages are theoretically designed to ease the hurdle of deploying and configuring applications on the target OS, they are frequently the culprit of OS migration difficulties.
Where Limitations of Installers Commonly Occur Checking Requirements
Most application installers have strict minimum requirements which must be met by the operating system in order to successfully install the software. An installer will verify that the target operating system meets the application’s minimum requirements such as memory, available disk space, and OS version compatibility. This verification process, or “requirements check,” is necessary for the application to function correctly as designed. Occasionally, these checks cause unintended incompatibilities on newer hardware or OS versions, as the requirements originally built for the check could not have anticipated for compatibility requirements for future versions of hardware or operating systems.
For example, an application installer written in the early 2000s may set Windows XP as the requirement. This might have been valid at the time the application installer was written since the application really needed the latest features of the latest OS. Today, while Windows 10 is mostly compatible with applications written for Windows XP, the installer may fail to run since Windows 10 is not the same version as Windows XP. It isn’t fair to blame the developer of the application for this issue as there was no foresight on future Windows versions. Also, it might have been a limitation on the software used to create the installer packages.
In lieu of traditionally built installer packages, some of the installer packages were created as a 16-bit executable, even after the 32-bit OS became widely available, primarily to ensure backward compatibility. The 16-bit installer package did not pose any issue on 32-bit operating systems since they were able to run 16-bit executables. This capability mirrors today’s 64-bit OS ability to run 32-bit executables. However, issues arise these days, given that a 64-bit OS cannot run 16-bit executables4.
Needless to say, there is a perceived need for maintaining legacy Windows OS versions such as Windows XP in order to allow 16-bit applications to continue running in a production environment. However, the act of doing so can pose serious threats to corporate security.
Deploying Assets
The bulk of operations in software installation occurs in deploying the software asset. The asset deployment process can be as simple as copying a single executable to a predefined location on the target operating system, but typically it involves copying multiple files to various locations on the system. The application installer usually checks the target system’s environment before it either, copies specific files to the required locations, or installs additional software.
Similar as to the requirements check, everything should function properly during the asset deployment process, provided that the installer is run on the same version of OS available at the time the application was released. However, when the installer is run on a newer OS version, many things can go wrong.
For example, beginning with Windows Vista, the “Documents and Settings” folder was eliminated from the Windows OS5. Also beginning with the introduction of Windows Vista, Microsoft added User Access Control (UAC), requiring additional privileges to install certain software such as drivers6. These differences in OS versions, commonly known by developers and system administrators as “breaking changes,” can cause some installers to fail during installation, even if the application itself is fully capable of running on the latest OS.
Configuration of Deployments
Application installers typically write configuration data in Windows registry, in order for applications to function7. While the Windows registry structure has not changed much in the recent versions of Windows OS, configuration data stored inside the registry has the potential to become obsolete with the latest OS.
For example, a legacy application may have stored a hardcoded path to an application file in its registry. If such a path changed, such as “Documents and Settings” being eliminated in Windows Vista, the application may not function properly on Windows 10. Even if the path did not become obsolete, such data may interfere with migration tools designed to move application files and registry from one system to another.
How Cloudpaging Can Help Overcome Troublesome Installers
Cloudpaging technology enables legacy applications with troublesome installers to migrate to the latest Windows OS. This unique technology allows applications to be packaged into a proprietary container that is upwardly compatible. This means that containers created in older versions of Windows will always be supported in later versions of Windows. By leveraging Cloudpaging technology, IT administrators can complete their migration to Windows 10, including moving applications that had previously been troublesome with their original or customized installers.
Packaging on Windows XP
When Microsoft released Windows 7, an XP Mode virtualization package was created to mitigate the pain of application migration8. This feature was dropped beginning in Windows 8, so there is no longer an easy way to run legacy applications requiring Windows XP without jeopardizing security. Using Cloudpaging Studio, an application containerization tool, an IT administrator can create the application container on a virtual machine running Windows XP and transfer the container “upwardly” to Windows 7, 8, or Windows 10. This simple process enables an installer’s OS requirement checks to run correctly as the installer is running on the intended OS.
Similarly, by using 32-bit OS versions of Windows, 32-bit applications packaged for use with 16-bit installers will run successfully. Since the application itself is a 32-bit, the generated application container can easily be used in Windows 10.
Template Paths
Once an application is containerized using the Cloudpaging Studio, system paths are automatically detected and converted into proprietary template paths. When the application is deployed to Cloudpaging Player, the template paths are resolved to valid system paths within the operating system on which the Player is installed and running. This unique feature allows files originally intended to be installed under “Documents and Settings” in a Windows Vista OS, for example, to properly deploy under “Users” on Windows 10. The template path conversion works on registry paths in a similar fashion. If a registry value is hardcoded to “Documents and Settings\All Users,” the value will properly translate to “ProgramData” on Windows 10.
Capture-based Packaging
When creating application containers, Cloudpaging utilizes a patented technique of monitoring and capturing only changes made by specified application installers. Unlike other technologies which compare all system images captured both before and after application installation9, the Cloudpaging technique has the advantage of capturing less noise and unwanted artifacts. This is because the OS is rarely in an idle state where no process is running in the background. System services such as anti-virus, firewall, Windows updater, and other applications running in the background often make changes to the system while an application installer is running.
Even with advanced heuristics-based comparison algorithms, it is difficult to remove all noises from the before and after comparisons. By monitoring application installers and related processes, Cloudpaging Studio captures all the changes made to the system by the installer without capturing changes made by unrelated processes. Cloudpaging Studio can also capture installers running in Windows Compatibility mode10 allowing application containers to be created for pre-NT Windows operating systems including Windows 95.
Conclusion
Migrating business-critical legacy applications to the latest operating system can be a daunting task. Enterprises are routinely faced with difficult decisions involving spending millions on updating applications, changing entire business workflows, or maintaining security-vulnerable operating systems running in a production environment. Cloudpaging eliminates the need for businesses to make such risky decisions by supporting the migration of troublesome applications, as well as those with troublesome installers, to the latest, most secure version of Windows OS.
Contact Numecent to learn how Cloudpaging can successfully package enterprise legacy applications for deployment on Windows 10.
ABOUT THE AUTHOR
Dan Kobayashi is a Lead Software Engineer for Numecent. He has worked with various iterations of Numecent’s technology for over 10 years. Dan has extensive experience with agile software development and reusable software design as well as cloud app hosting, management, and deployment. Dan graduated from University of California, Irvine and received a B.S. Magna Cum Laude in Information and Computer Science.
2 “List of installation software,” 19 09 2018.
3 “Installation (computer programs),” 3 10 2018.
4 R. Dube, “Why Can’t 64-Bit Operating Systems Run 16-Bit Apps,” 21 2 2018.
5 M. Pietroforte, “Documents and Settings in Vista and Windows 7,” 8 2 2007.
6 C. Adrian, “What is UAC (User Account Control) and why you should never turn it off,” 11 7 2017.
7 “What Is the Windows Registry?” 6 9 2018.
8 T. Bradley, “Windows 7: What You Should Know About XP Mode,” 3 11 2009.
9 “What Matrix – Application Virtualization,” WhatMatrix.com, 2018.
10 “Make older programs compatible with this version of Windows,” Microsoft, 30 4 2018.