Legacy Applications Still Serve Business-Critical Functions
There are organizations out there who have never found a solid solution for migrating their legacy applications when upgrading desktops to Windows 10. For example, it is common for IT teams to maintain applications where the developer or vendor is no longer available to update the application for newer Operating Systems. The application may depend on OS-specific components that do not exist in newer versions of Windows. Something as simple as a Windows Dialog UI change could render an application defunct. Perhaps an application uses 16-bit code or a 16-bit installer. In the case of heavily customized applications, it can be very difficult or impossible to find a suitable alternative application, so the only option is to somehow keep the existing application functioning.
For this reason and more, some organizations have continued to provide remote access to a subset of Windows 7 machines with hardened network rules to allow the business to keep functioning with these applications in hopes that it was a stop gap solution, but it became permanent. There are even cases where 32-bit Operating Systems were maintained upon moving to Windows 10, making it difficult to standardize on 64-bit desktop OS. More enterprises found that their legacy applications worked well enough on Windows Server 2012 R2 and decided to kick the can down the road for a few more years by publishing the applications running on the Server OS. Unfortunately, Server 2012 R2’s end of life is set for 2023. For these reasons (and many more), now is the time to find a solution to modernize your application delivery.
You could try application shims to provide specific compatibility fixes or even a broad compatibility mode to run the applications in. If you are reading this article with applications still running on Windows XP or Windows 7, you have likely exhausted these options. Compatibility mode was a quick fix during initial migrations but was not ideal as the level of virtualization and redirection used can be very resource intensive. Microsoft had a product called MED-V that would provide a virtual machine running an XP virtual machine on your desktop in the background to host applications that would not work on Windows 7, but the product was not brought forward and is now End of Life. The method of a large base image to emulate and run these applications locally can be difficult to manage through traditional tooling and can take a lot of disk space. For this reason, it is best to use this type of solution sparingly.
Key Considerations When Packaging Legacy Applications
There are several different aspects of application compatibility to consider on your journey to a new Windows Operating System. These include:
Standardizing on 64-bit
As the Windows operating system continues to evolve, more barriers to maintaining legacy applications emerge. Windows was originally a 16-bit environment running 16-bit software. As it transformed into 32-bit, 16-bit applications were still supported. However, Windows 64-bit OS versions only support 32-bit and 64-bit programs, leaving 16-bit applications behind. Some application installers do include both 16-bit and 32-bit versions, enabling them to work on 64-bit operating systems. Unfortunately, if application installers are 16-bit or applications themselves are 16-bit, then these applications are unable to run on 64-bit systems. In addition, applications may appear to be 32-bit with a Win32 GUI and all the window dressing of a 32-bit Windows application, but some 32-bit applications call 16-bit components. Finally, many 32-bit legacy applications have hardcoded paths and shortcuts that are now incompatible with newer 64-bit Windows versions.
Living in a Multi-Session World
Customers have been implementing Azure Virtual Desktop with the Windows 10 Enterprise multi-session (EVD) images which provide a shared multi-session desktop. This ensures the lowest cost AVD environment, reducing DaaS run costs more than 6X by optimizing OS resource utilization and making other resource costs one-to-many. A challenge being faced, however, is the fact some applications were developed for traditional 1:1 desktops and do not work in multi-user session desktops.
A lot of legacy applications and their dependencies are notorious for conflicting with other apps and their dependencies. Those apps are likely to have been siloed, increasing costs, meaning a new machine or group of machines are setup with one of the conflicting applications installed on it and the other conflicting application is running on a separate set of machines. This increases the number of machines required to support applications, it requires more time and effort for maintaining all these extra machines and it leads to complex image sprawl. Cloudpaging can be used to isolate those troublesome legacy apps and/or dependencies.
Our Cloudpaging Containers can help you get your applications running successfully on your multi-session Windows 10 and Windows 11 desktops, avoiding siloes and the image sprawl that it creates. To learn more about that, check out our blog How to Simplify Virtual Desktop Image Management with Cloudpager.
Evergreen Solutions
If you are reading this and are in the fortunate position to not have legacy apps running on older Operating Systems, you could still benefit by having a go-to solution for broken apps. Microsoft have been doing some security hardening through the life of Windows 10 and it is likely they will continue these efforts on Windows 11. Other vendors are also constantly updating their applications to harden security too, increasing demand for an evergreen application solution. Something you can rely on not just to bring legacy apps forward but can also be used in a pinch when a current application is inadvertently broken by an OS update. While security hardening net benefit to all, it can break applications. Which we have seen multiple times in the past such as Google Chrome’s update mechanism getting broke by a Windows update. A move from VREG to CREG for App-V resulted in major problems when trying to use App-V packages, legacy applications that used SMBv1 no longer being able to work when an update disabled the protocol, and more. Using a container technology for app delivery, can enable you to provide the resources the app needs to run inside the container whilst isolating this from the local system and other users on your machines.
Cloudpaging Enables Legacy Applications to Run on the Latest Windows Operating Systems
Numecent Cloudpaging provides a container with the highest rate of application compatibility for all apps, enabling legacy applications to seamlessly run on newer Operating Systems. It achieves this by implementing a true file system driver (FSD) at the Windows Kernel level. This file system remains consistent across Windows platforms – along with abstraction, templatization, and a writable sandbox – enabling Cloudpaged applications to seamlessly run on newer Windows operating systems without the need to be repackaged. The writable sandbox effectively allows legacy applications to write to locations that newer versions of Windows do not allow to be modified, such as the applications’ install directory.
Note that Cloudpaging does not fully emulate the platform, meaning some calls to Window XP (or earlier) may be unavailable or deprecated on a later Windows version (e.g. Windows 7 or 10).
However, in these cases Cloudpaging can address those dependencies by paging them through an emulator. While not all barriers can be overcome, there are many scenarios where Cloudpaging can successfully package legacy applications. Here are just a few reasons as to why:
Legacy applications that hardcode file paths or registry hive locations
For a trivial example, when Microsoft Office is installed on a 32-bit machine, it stores a file under “C:\Program Files” and records this path in Windows Registry. This is a hard-coded path that works well when the application remains on the machine. However, when this application is used on another machine that is 64-bit, the path becomes wrong because the correct path on the new machine should be “C:\Program Files (x86)”.Cloudpaging overcomes this problem by encoding the path as “?programfilesx86?” in the application package. Cloudpaging then resolves this encoded path to the correct value on any other machine basing on each machine’s specific configuration. Legacy applications do far more than this (of course). Since we implement the FSD, we can completely alter the behavior of the filesystem for many other common legacy “misbehaviors”.
Legacy applications that need Windows Compatibility mode or Isolation
Windows provides a mechanism for older applications to run with newer versions of Windows.[1] This mechanism does not automatically turn on for applications, but instead must be activated manually. With Cloudpaging, the need for an application to use this mechanism can be encoded into the application packaged and activated on the target machine.
Legacy applications that use a 16-bit installer or cannot install on newer Windows versions
At the time of development many vendors restrict the installation of software to Operating Systems it has been tested on. When attempting to install on an unsupported operating system, installation fails. Cloudpaging Studio provides a mechanism to seamlessly package your applications and prepare them for deployment to any modern Windows desktop environment without being repackaged for different devices or operating systems, regardless of their original OS.
16-bit legacy applications that need an emulator (such as DOSBox with the virtualized application) for 64-bit systems
Legacy 16-bit applications need either an emulator or a virtual machine to run. Cloudpaging’s ability to provision software containers these emulators easily and efficiently onto other machines can instantly extend the lifespan of those legacy applications.
Cloudpaging enables legacy applications to migrate to new Windows platforms, including Windows 10 and Windows 11
With many legacy applications, the biggest obstacle is just getting the app to install on a newer Windows platform. With Cloudpaging, the install phase no longer exists. Speaking figuratively, the application is paged directly into the machine without installation. By removing this barrier, Cloudpaging drastically increases legacy application deployment success on newer Windows platforms.
Conclusion
Our Cloudpaging container technology is optimal for packaging and deploying legacy applications. The flexibility of the solution greatly helps in the event an application is inadvertently broken by an OS update by enabling you to apply a fix to your container and re-deploy it into production. Unlike other products which specialize in handling legacy apps you will not need gigabytes of dedicated disk space on each machine. Your users’ performance will not suffer due to intense resource utilization and the containers can be managed from Cloudpager making deployment and support as easy as can be.
With the highest rate of application compatibility, Cloudpaging containers are an asset to your organization whether you are trying to get legacy applications to run on new operating systems or enhancing an ongoing evergreen solution.
[1] https://support.microsoft.com/en-us/help/15078/windows-make-older-programs-compatible