TECHNOLOGY INSIGHTS

7 Common Barriers to Legacy App Compat in Windows 10

There are many older applications that are critical to enterprises’ operations and bottom lines. They are often simple to install on older Windows versions, but they will have conflicts and ultimately fail to run on Windows 10. This article identifies the properties of many legacy apps which lead to their incompatibility within a new operating system.

One of the key reasons organizations stay with a particular operating system (OS) over time is so they can continue running their existing applications as new versions of the OS are released.

Microsoft® has generally attempted to make every newer OS compatible with its predecessor, including the transition from Windows 7 to Windows 10. Most apps will install and continue to run on Windows 10, yet there are many business-critical applications that were simple to install on older Windows versions. However, they will have conflicts and ultimately fail to run on Windows 10.

Windows Background

Windows was originally a 16-bit environment and ran only on 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 software installers 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. What changes caused these incompatibilities?

This article explains the seven most common barriers in Windows 7 and later versions that may cause difficulties for many enterprise applications that were developed for Windows XP or earlier versions.

7 Common Legacy Application Barriers on Windows 10

#1 UAC

Windows XP allows lower elevation processes to control higher elevation processes through Message passing. This is illegal in Windows Vista, Windows 7 and later versions unless UAC is turned off. “User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.” 1

#2 Service Hardening

Windows XP allows user processes to mingle with service processes in the first user session (session 0). This allows the service-processes to interact with user processes (and vice versa) using intra-session function calls. With Windows Vista, Windows 7, and later, these processes must be reprogrammed with inter-session calls. “Windows Vista restricts malicious applications from hijacking highly privileged services using message-based attacks since they no longer run in the same session.” 2

#3 Kernal-Hardening

Windows XP allows kernel drivers to replace functions in the kernel syscall table with their own functions. Windows Vista, Windows 7, and later Windows 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 Windows Vista, Windows 7, and later Windows versions. “Kernel Patch Protection monitors if key resources used by the kernel or kernel code itself has been modified. If the operating system detects an unauthorized patch of certain data structures or code it will initiate a shutdown of the system.” 3

#4 Kernal-Anti-Tampering

Windows 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 expected to fail to load. “The kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.” 4

#5 Depracated Functions

There are functions that have been deprecated but are still available in Windows 7. The farther out that versions are introduced beyond Windows 7, the higher the chance that these functions are dropped completely. This is not a blocker but is a risk to be reckoned with. Examples include SHCreateProcessAsUserW, SHExtractIconsW, PathIsExe, etc. 5

#6 16-Bit Incompatibility

Windows allows 16-bit applications to run on 32-bit Windows versions but not on 64-bit ones. “64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.” 6

#7 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. “32-bit drivers cannot run on 64-bit Windows and must be ported.” 7

Conclusion

Seven fundamental barriers have been created in recent versions of the Windows operating system architecture which make migrating legacy applications difficult.

Numecent addresses application compatibility for enterprises migrating their workstations to the Windows 10 operating system using its Cloudpaging™ technology. 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 work to convert the application to execute in the container.

Cloudpaging implements a true file system driver at the Windows kernel level. It is this file system that remains consistent from Windows platform to platform, along with abstraction, templatization, and a writable sandbox, enabling Cloudpaging to migrate many applications that would otherwise not function on newer Windows operating systems. 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. For the most difficult applications, Cloudpaging can page dependencies through the OS or emulator.

Contact Numecent to learn how Cloudpaging can successfully package enterprise legacy applications for deployment on Windows 10.

1 User Account Control: Allow UI Access applications to prompt for elevation without using the secure desktop2 Security Watch Services Hardening in Windows Vista

3 An Introduction to Kernel Patch Protection

4 Driver Signing

5 Deprecated Shell APIs

6 Running 32-bit Applications

7 Drivers

See Cloudpaging in Action!

From challenges with application compatibility to enterprise-scale virtual desktop adoption, we would love to talk about how we can help.