One of the key reasons to stay with a particular operating system (OS) over time is so that you can continue to run your existing applications on new versions of the OS. After all, content is what makes a platform, and supporting content from your old platforms makes it easier to support the new one. For this reason, Microsoft attempts to make every newer OS compatible with the old, including going from Windows 7 to Windows 10. Most will install and continue to run, yet there are many applications which are important to you that may be simple to install on older Windows versions, but will have conflicts and ultimately fail to run on Windows 10. The reasons are not straightforward, and unfortunately not so easy to overcome.
Windows Background
Like many technologies over time, OSes evolve. 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 (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 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?.
Changes to the Windows Operating System
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 Vista/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.” (Reference). - 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 interact with user processes (and vice versa) using intra-session function calls. With Win Vista/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.” (Reference)
- Kernel-hardening (Kernel Patch Protection)– Win XP allows kernel drivers to replace functions in the kernel syscall table with their own functions. Win Vista/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 Vista/7 and later Win 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.”(Reference)
- 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 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.” (Reference)
- 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.Examples: SHCreateProcessAsUserW, SHExtractIconsW, PathIsExe, etc. (Reference).
- 16-bit incompatibility– Windows allows 16-bit applications to run on 32-bit Win 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.” (Reference)
- 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” (Reference).
These are some of the fundamental changes to the Windows operating system architecture which make migrating Legacy applications difficult. To explore how Cloudpaging can overcome these and other migration issues, read “How Cloudpaging Improves the Migration of Legacy Apps to Windows 10.”
