Cloudpaging can be used to migrate legacy 32-bit applications and even some 16-bit applications onto newer Windows platforms, such as Windows 7 or 10. Cloudpaging resolves many of these issues through techniques by changing the behavior of the runtime environment. Cloudpaging implements a container, similar to Docker. The container and the Cloudpaging Studio tool then works to convert the application to execute in the container. Some of that process involves changing the installation process, abstracting file paths and registry hives, templatizing shortcuts, supporting Windows compatibility mode, and providing configurable actions. To understand how Cloudpaging deals with packaging legacy applications, it is important to understanding how the Windows operating system has evolved, which I explained in a previous essay.
Background
As the Windows Operating System evolved and modernized, more barriers to legacy applications emerged. Windows was originally a 16-bit environment running only 16-bit software. With time the Windows operating system went to 32-bit and then 64-bit. The 32-bit version of Windows could run both 16-bit and 32-bit applications. However, with Windows 64-bit OS versions, they can run 32-bit and 64-bit programs, but not 16-bit applications. Some applications installers do include both 16-bit and 32-bit versions and these applications can work on 64-bit operating systems. But if the application installer is 16-bit or the application is 16-bit, then these applications can no longer work 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.
Cloudpaging implements a true file system driver, or FSD, at the Windows Kernel level. It is this Numecent file system that remains consistent from Windows platform to platform, along with abstraction, templatization, and a writable sandbox, that enables Cloudpaging to migrate many applications that would otherwise not function on newer Windows OS’s. The writable sandbox is especially handy in allowing the legacy applications to write in legacy locations where modifications are normally not allowed under the newer Windows versions. Note that Cloudpaging does not fully emulate the platform, meaning that not all of the calls to Window XP, or earlier, may be unavailable or depreciated on a later Windows version (e.g. Windows 7 or 10). However, for the most difficult applications, Cloudpaging can also page those dependencies through paging the OS or emulator. While not all barriers can be overcome, there are many scenarios where Cloudpaging can successfully package legacy applications. Here are 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 (Reference). This mechanism does not automatically turns on for the applications but instead has to 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
- 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 abiliy to provision these software containers easily and effciently onto other machines can help to extend the lifespan of those legacy applications.
- Cloudpaging enables the ability to migrate legacy applications to new Windows platforms, including Windows 10– With many legacy applications, the toughest of those two phases on a newer Windows platforms is not being able to install. With Cloudpaging, the install phase no longer exists. Speaking figuratively, the application is paged directly into the machine without installation. Because this barrier is removed, legacy applications have a much better chance to work on the newer Windows platform. There are also other helps from Cloudpaging (as mentioned above) that further increases legacy application compatibility with the newer platform.