Windows on Windows
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
No issues specified. Please specify issues, or remove this template. |
 | This which refers to components that may no longer be in current Windows products. is about an event or subject that may not be current but does not specify the time period. |
In computing, Windows on Windows - commonly referred to by its acronym WOW or WoW - is a software component of 32-bit versions of the Microsoft Windows NT family of operating systems that provides limited support for running legacy Win16 applications - applications written for Windows 3.x. Alternatively "WOW" may also refer to support for running 32-bit applications on 64-bit versions of Windows - known as WOW64.
Background
Many 16-bit Windows (Win16) legacy applications can run without changes on newer 32-bit editions of Windows. The reason designers made this possible was to allow application developers time to remediate their applications during the industry transition from Windows 3.1x to Windows 95 and later, without restricting the ability for the operating system to be upgraded to a current version before all the applications used by a customer had been taken care of.
The Windows 9x series of operating systems, reflecting their roots in DOS, functioned as hybrid 16/32-bit systems in the sense that the underlying operating system was not truly 32-bit, and therefore could run Win16 applications natively without requiring any special emulation; Windows NT based operating systems differ signicantly from Windows 9x in their architecture, and therefore require a more complex solution. Two technologies make it possible for 16-bit applications to run unmodifed and with some runtime limitations on 32-bit Windows NT-based versions of Windows—thunking and shimming.
Thunking
The operating system thunks 16-bit APIs to their underlying 32-bit equivalents in order to provide support for 16-bit pointers, memory models and address space.
The Win16 subsystem is available in 32-bit editions of Windows NT, 2000, XP, Server 2003, Vista, Server 2008, 7, and 8. The 64-bit editions of Windows versions that have them, however, do not include the WoW Win16-support subsystem and therefore cannot run Win16 applications, nor do they provide the NTVDM emulator. DOS and 16-bit Windows applications, therefore cannot run in 64-bit versions of Windows without third-party emulation software (e.g. DOSBox) or a virtual machine with either a 32-bit version of Windows, Windows XP Mode, or DOS itself. A few DOS programs engineered to run on a 32-bit OS can usually run on 64-bit Windows using WoW64.
The WIN.COM file in a Windows NT System32 folder facilitates Windows-on-Windows. In addition to Windows-on-Windows emulating the Windows 95, Windows NT 4.0, and Windows 98 kernels, the WIN.COM file emulates a Windows 3.x kernel for NTVDM, which runs the 16-bit DOS-based Windows applications on Windows NT. In Windows Vista, Server 2008, 7 and 8, Microsoft has removed both NTVDM and the emulated Windows 3.x kernel; thus Windows Vista, Server, 7 and 8 only emulates the kernels of Windows 95, Windows NT 4.0, Windows 98, and later (where the emulated kernel of Windows Vista and later were only 32-bit).
Shimming
Application-compatibility issues, notably around long filenames, multiple users and the concept of least privilege, may prevent some applications that incorrectly assume write access to the whole file system from working on newer platforms.
When the Windows NT line of operating systems was designed, a key requirement was for the NTFS file system to keep backward compatbility with 8.3 filenames to allow legacy applications to continue to work on the platform. NTFS therefore supports a compatblity mode whereby both a long filename and a short filename is stored in its File Allocation Table.
Furthermore, legacy applications that attempt to access hardware directly cannot do so in user mode. Legacy application may also fail if system configuration files from the DOS and Windows 9.x era are not present, hence the reason for zero-length versions of files like AUTOEXEC.BAT and CONFIG.SYS having to be carried forward on operating systems that do not use them.
A considerable number of shims are present in the application compatibility layer of later versions of Windows to intercept and modify API calls made by legacy applications that were written with a different set of assumptions and operating system best practices in mind.[1] These fixes are updated from time-to-time as issues are discovered in popular legacy applications that are still in use.[2]
See also
External links
 | This Microsoft Windows article is a stub. You can help Wikipedia by expanding it. |
- ^ "Application Compatibility". Microsoft. Retrieved 11 Feb 2014.
{{cite web}}: Cite has empty unknown parameter:|1=(help) - ^ "Application Compatibility Update for Windows 7 and Windows Server 2008 R2: August 2010". Microsoft. Retrieved 11 Feb 2013.