Windows on Windows

Windows on Windows
Other names	WOW
Developer(s)	Microsoft
Operating system	Microsoft Windows
Type	Compatibility layer
License	Proprietary commercial software

In computing, Windows on Windows (commonly referred to as WOW,[1][2][3]) is a compatibility layer of 32-bit versions of the Microsoft Windows NT family of operating systems that extends NTVDM to provide limited support for running legacy 16-bit programs written for Windows 3.x or earlier. There is a similar subsystem, known as WoW64, on 64-bit Windows versions that runs 32-bit programs.

Background

Many 16-bit Windows legacy programs can run without changes on newer 32-bit editions of Windows. The reason designers made this possible was to allow software developers time to remedy their software 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 programs 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- and 32-bit systems in the sense that the underlying operating system was not truly 32-bit, and therefore could run 16-bit software natively without requiring any special emulation; Windows NT operating systems differ significantly from Windows 9x in their architecture, and therefore require a more complex solution. Two separate strategies are used in order to let 16-bit programs run on 32-bit versions of Windows (with some runtime limitations). They are called thunking and shimming.

Thunking

The WOW subsystem of the operating system thunks legacy 16-bit APIs to their newer 32-bit equivalents in order to provide support for 16-bit pointers, memory models and address space.

All 16-bit programs run by default in a single virtual DOS machine with shared memory space. However, they can be configured to run in their own separate memory space, in which case each 16-bit process has its own dedicated virtual machine. The separate memory space increases system stability by preventing buggy 16-bit programs from interfering with one another, at the expense of reduced 16-bit inter-process communication and increased memory utilization.

This subsystem is available in 32-bit editions of Windows NT only. The 64-bit editions (including Windows Server 2008 R2 and later which only have 64-bit editions) cannot run 16-bit software without third-party emulation software (e.g. DOSBox).

The WOWEXEC.EXE process on a Windows NT system facilitates Windows-on-Windows.[4][5] In addition to Windows-on-Windows emulating the Windows 95 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.

Shimming

Application compatibility issues, notably around long filenames, multiple users and the concept of least privilege, may prevent some applications from working. For example, they may incorrectly assume full write access to the whole file system whereas NTFS security is in place.

When the Windows 95 line of operating systems was designed, a key requirement was for the file system to keep backward compatibility with 8.3 filenames to allow legacy applications to continue to work on the platform. Windows 95 and later operating systems therefore support a compatibility mode whereby both a long filename and a short filename are stored in the File Allocation Table.

Furthermore, legacy applications that attempt to access hardware directly cannot do so in user mode. Legacy applications may also fail if system configuration files from the DOS and Windows 9x era are not present in Windows NT based kernels, 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.[6] These fixes are updated from time-to-time as issues are discovered in popular legacy applications that are still in use.[7]

gollark: It would probably be better to just not buy their cards to give them an actual incentive to change, but eh.

gollark: I think Nvidia deliberately don't make the drivers for consumer cards work in VMs, because Nvidia loves their petty Nvidiaing.

gollark: Maybe. Or SR-IOV or something.

gollark: I thought it needed specific support by the GPU, I mean, though I may be being confused.

gollark: Is VFIO or whatever actually commonly supported™™?

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.

External links

Windows NT subsystems
What are NTVDM and WOW?
"Monitoring 16-bit Windows applications". TechNet. Microsoft. Archived from the original on Dec 25, 2007.
Optimize How Windows 7 Runs 16-Bit and MS-DOS-Based Programs

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.

[1] "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.

[2] "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.

[3] "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.

[4] "Windows NT Subsystems and Associated Files". Support. Microsoft. October 31, 2006. Archived from the original on March 16, 2007. Retrieved February 7, 2017.

[5] "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.

[6] "Application Compatibility". TechNet. Microsoft. Retrieved February 7, 2017.

[7] "Application Compatibility Update for Windows 7 and Windows Server 2008 R2: August 2010". Support. Microsoft. August 24, 2010. Retrieved February 7, 2017.