Cloudpaging can be used to migrate legacy 32-bit applications and often even 16-bit applications onto newer Windows platforms, such as Windows 7 or 10. Cloudpaging helps by removing the installation process, abstracting file paths and registry hives, templatizing shortcuts, supporting Windows compatibility mode, and providing configurable actions.


Background


Windows was originally a 16-bit environment and ran 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 (http://support.microsoft.com/kb/896458). 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 appears 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 application have hardcoded paths and shortcuts that are now incompatible with newer 64-bit Windows versions.



How It Works


Cloudpaging is not a platform emulator, meaning that if an application developed to run on Window XP, or earlier, calls a function that has become unavailable or depreciated on a later Windows version (e.g. Windows 7 or 10), our technology cannot help without an emulator. 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 and templatization, that enables Cloudpaing to migrate many applications that would otherwise not function on newer Windows OS’s. Cloudpaging depends on the operating system to execute the application, if the application doesn't natively run on the system, then virtual applications will run into the same error. This means that understanding how the Windows operating system has evolved is important to packaging legacy applications.



Microsoft puts up the following barriers in Windows 7 and later versions that may be unexpected for applications that are developed only for Win XP or earlier:


  • UAC - Win XP allows lower elevation processes to control higher-elevation processes through Message passing. This is illegal in Win 7 and later versions unless UAC is turned off.
  • Service-hardening - Win XP allows user processes to mingle with service processes in the first user session (session 0). This allows the service processes to interacts with user processes (and vice versa) using intra-session function calls. With Win 7 and later, these processes must be reprogrammed with inter-session calls.
  • Kernel-hardening - Win XP allows kernel drivers to replace functions in the kernel syscall table with their own functions. Win 7 and later Win versions make the syscall table read-only. Any prior kernel driver that relies on the ability to write the syscall table should therefore fail in Win 7 and later Win versions.
  • Kernel-anti-tampering - Win 8 and later versions require that kernel drivers are digitally signed in such a way that is approved by Microsoft and can be verified by Windows kernel. Drivers that do not meet this requirement are expect to fail to load.
  • Deprecated functions - There are functions that are deprecated but still available in Win 7. The farther going past Win 7, the higher the chance that these functions are dropped completely. This is not a blocker, but is a risk to be reckoned with.
  • 32-bit incompatibility - For 32-bit applications that contain a 32-bit kernel driver, this driver will not be compatible with 64-bit systems. These tend to be more hardware related but can affect some applications as well.
  • 16-bit incompatibility - Windows allows 16-bit applications to run on 32-bit Win versions but not on 64-bit ones.


While the above barriers cannot all be overcome, there are many scenarios where Cloudpaging can successful package legacy 16-bit and 32-bit applications.


  1. 32-bit legacy applications that hard-coded file paths or registry hive locations
  2. 32-bit legacy application that need Windows Compatibility mode
  3. 32-bit legacy application that uses a 16-bit installer
  4. 16-bit legacy application that need an emulator for 64-bit systems



How to Package


By default, Cloudpaging will automatically perform many steps towards making migration simpler when packaging, such as file path abstraction. The following steps are a list of best practices for attempting to package legacy 16-bit and 32-bit applications that do not work with just the default settings alone:



Package on an Older Version of Windows

It is recommended to always package on the earliest OS version possible. For example, if the application works on Windows XP and intended for Windows 10 64-bit, then it is best to package on Windows XP. Packaging on the earliest OS typically has the best chance of working because that OS will have less dependencies as opposed to later OS versions. In addition, the legacy application should install and function on this OS.


  • If the application does not install on this earlier OS, then attempt to capture using the Windows Compatibility settings
  • If the application installs but does not run on this earlier OS, then attempt to run using the Windows Compatibility settings




Package in Isolation Layers

For many legacy applications, either the application itself or it's dependencies are not typically compatible with more modern applications or operating system versions. For these types of applications it can be best to package them as fully isolated. This can be accomplished by changing the default disposition layers to Virtual-isolated (layer 4) on all the assets (e.g. files, folders, registry keys, fonts, and shortcuts).


  • Dependencies - First attempt to capture the application dependencies, such as Java run-time, and change the disposition layer to isolated.
  • Application - Next capture the application and test with it at layer-3. If the dependencies are not enough, then re-package with the entire appset and isolated.




Package 16-bit DOS Applications with an Emulator

If the application is not 32-bit but truly a 16-bit dos application, then an emulator will be required to execute the application. The following type of error dialog typically indicates a 16-bit applications:



The best solution to package a 16-bit DOS application is to use DOSBOX and package this emulator along with the 16-bit application. DOSBOX is a free, open-source product that can be used to emulate 16-bit DOS applications on a 32-bit or 64-bit operating system. It only support DOS application and will not work with Windows 16-bit applications.


http://www.dosbox.com/



Package with Virtual Machine

If the application cannot work using an emulator, then Cloudpaging can be used to package a Virtual Machine to host an operating system compatible with the legacy application. This may be necessary if the legacy application has 16-bit or 32-bit driver that are incompatible with emulators. A valid copy of the operating system will be required and possibly a copy of the hyper visor software used to run the virtual machine.




Cloudpaging enables the ability to migrate legacy application to new Windows platforms. For additional questions, please contact Numecent support.




ARTICLE APPLIES TO VERSION 8.6 AND ABOVE