Windows on Windows
With computers, Windows on Windows (often shortened to WOW,[1][2][3]) is a compatibility layer of x86 versions of the Microsoft Windows NT family of operating systems that allows many legacy 16-bit programs run that were made for Windows 3.x or before to run.
Background
WOW allows many 16-bit Windows programs to run without changes on newer 32-bit versions of Windows. This was made to give software developers time to make their software 32-bit while people moved from Windows 3.1x to Windows 95, so the OS can be upgraded to a newer version while running most, or all of, a customer's 16-bit programs.
Windows 9x operating systems, which were made on top of DOS, had both 16 and 32-bit systems, so if it kept those 16-bit parts, the OS could run 16-bit software without emulation. NT-based versions are very different in how they run, so they need a more sophisticated solution. There are two main techniques to let 16-bit programs run on 32-bit versions of Windows (with some limitations) called thunking and shimming.
Thunking
WOW "thunks" 16-bit instructions into 32-bit equivalents to permit 16-bit pointers, memory spaces, and address spaces.
16-bit programs usually run in a single virtual DOS machine, sharing memory between them. However, they can be changed to run in a private, separate memory space, where every 16-bit process has a separate process. This can reduce system crashes by not letting programs interfere with others, but it can cause reduced 16-bit inter-process communication and can use more of your computer's memory.
WOW is a part of 32-bit editions of Windows NT. 64-bit versions of Windows (including Windows Server 2008 R2 and later where they only have 64-bit versions) can not run 16-bit software without using different emulation software (for example, DOSBox).
WOWEXEC.EXE on Windows NT allows WoW to work.[4][5] Windows-on-Windows can, using the WIN.COM file, emulate the Windows 3.x (for NTVDM), Windows 95 and Windows 98 kernels, which can run 16-bit DOS-powered Windows applications on Windows NT.
Shimming
Problems with applications running on newer operating systems, especially with long filenames, multiple user accounts, and least privilege, may prohibit some applications from working correctly. For example, they might incorrectly think that they can write files to any part of the file system, but NTFS file permissions exist and does not allow this in many system folders. When Microsoft was building Windows 95, they had to ensure old programs still worked with 8.3 filenames to allow old applications to keep working properly. Since Windows 95, there was a feature where both a long and short file name are kept, so older applications could still use the 8.3 filenames.
Programs that try to access hardware directly can't do so. Old programs may also not work if they expect certain system configuration files from DOS and Windows 9x that are not used in Windows NT operating systems, so empty versions of files like AUTOEXEC.BAT and CONFIG.SYS exist even though Windows NT does not use them.
Many shims exist in the application compatibility layer of later versions of Windows to capture and change API calls from old applications made with different assumptions about the operating system in mind.[6][7]
Related pages
References
- ↑ "WOW Environment Remains in Memory After Quitting 16-Bit Program". Support. Microsoft. February 22, 2007. Archived from the original on October 23, 2007. Retrieved February 7, 2017.
- ↑ "Starting 16-Bit WOW Subsystem on Windows NT Server". Support. Microsoft. November 1, 2016. Archived from the original on May 9, 2007. Retrieved February 7, 2017.
- ↑ "Disabling the MSDOS and WOWEXEC Subsystems on Terminal Server". Support. Microsoft. November 1, 2006. Archived from the original on November 30, 2008. Retrieved February 7, 2017.
- ↑ "Windows NT Subsystems and Associated Files". Support. Microsoft. October 31, 2006. Archived from the original on March 16, 2007. Retrieved February 7, 2017.
- ↑ "PRB: Relocation of Ntvdm.exe Fails on Multiprocessor Computers". Support. Microsoft. November 21, 2006. Archived from the original on February 22, 2009. Retrieved February 7, 2017.
- ↑ "Application Compatibility". TechNet. Microsoft. Retrieved February 7, 2017.
- ↑ "Application Compatibility Update for Windows 7 and Windows Server 2008 R2: August 2010". Support. Microsoft. August 24, 2010. Retrieved February 7, 2017.