Jump to content

Windows on Windows

From Wikipedia, the free encyclopedia
Windows on Windows
Other namesWOW
Developer(s)Microsoft
Initial releaseJuly 27, 1993;30 years ago(1993-07-27)
Operating systemMicrosoft Windows
PlatformIA-32
TypeCompatibility layer
LicenseProprietarycommercial software

Incomputing,Windows on Windows(commonly referred to asWOW)[1][2][3]was acompatibility layerof32-bitversions of theWindows NTfamily ofoperating systemssince 1993 with the release ofWindows NT 3.1,which extendsNTVDMto provide limited support for runninglegacy16-bitprograms written forWindows 3.xor earlier. There is a similar subsystem, known asWoW64,on 64-bit Windows versions that runs 32-bit programs.

This subsystem has since been discontinued, asWindows 11(andWindows Server 2008 R2and later) are only available in 64-bit editions and therefore cannot run 16-bit software without third-party emulation software (e.g.DOSBox).Windows 10is the final version of Windows to include this subsystem.

Background[edit]

Many 16-bit Windows legacy programs can run without changes on newer32-biteditions of Windows. The reason designers made this possible was to allow software developers time to remedy their software during the industry transition fromWindows 3.1xtoWindows 95and later, without restricting the ability for the operating system to be upgraded to a current version beforeallprograms used by a customer had been taken care of.

TheWindows 9xseries of operating systems, reflecting their roots inDOS,functioned as hybrid 16- and 32-bit systems in the sense that the underlying operating system was not truly 32-bit,[citation needed]and therefore could run 16-bit software natively without requiring any special emulation;Windows NToperating 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 calledthunkingandshimming.

Thunking[edit]

The WOW subsystem of the operating systemthunks legacy 16-bit APIs to their newer 32-bit equivalents[clarification needed]in order to provide support for 16-bitpointers,memory models andaddress space.

All 16-bit programs run by default in a singlevirtual DOS machinewith 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-bitinter-process communicationand increased memory utilization.

The WOWEXEC.EXE process on aWindows NTsystem facilitates Windows-on-Windows.[4][5]In addition to Windows-on-Windows emulating theWindows 95andWindows 98kernels, the WIN.COM file emulates aWindows 3.xkernel forNTVDM,which runs the 16-bit DOS-based Windows applications on Windows NT.

Shimming[edit]

Application compatibility issues, notably aroundlong filenames,multiple users and the concept ofleast privilege,may prevent some applications from working. For example, they may incorrectly assume full write access to the whole file system whereasNTFSsecurity 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 with8.3 filenamesto 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 thedirectory entry.

Furthermore, legacy applications that attempt to access hardware directly cannot do so inuser 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 likeAUTOEXEC.BATandCONFIG.SYShaving to be carried forward on operating systems that do not use them.

A considerable number of shims are present in theapplication compatibility layerof later versions of Windows to intercept and modifyAPIcalls 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]

See also[edit]

  • Wine (software)
  • OTVDM,a third-party project based on code from Wine which runs 16-bit Windows programs on 64-bit versions of Windows.

References[edit]

  1. ^"WOW Environment Remains in Memory After Quitting 16-Bit Program".Support.Microsoft.February 22, 2007. Archived fromthe originalon October 23, 2007.RetrievedFebruary 7,2017.
  2. ^"Starting 16-Bit WOW Subsystem on Windows NT Server".Support.Microsoft.November 1, 2016. Archived fromthe originalon May 9, 2007.RetrievedFebruary 7,2017.
  3. ^"Disabling the MSDOS and WOWEXEC Subsystems on Terminal Server".Support.Microsoft.November 1, 2006.Archivedfrom the original on January 13, 2008.RetrievedFebruary 7,2017.
  4. ^"Windows NT Subsystems and Associated Files".Support.Microsoft.October 31, 2006. Archived fromthe originalon March 16, 2007.RetrievedFebruary 7,2017.
  5. ^"PRB: Relocation of Ntvdm.exe Fails on Multiprocessor Computers".Support.Microsoft.November 21, 2006. Archived fromthe originalon February 22, 2009.RetrievedFebruary 7,2017.
  6. ^"Application Compatibility".TechNet.Microsoft.RetrievedFebruary 7,2017.
  7. ^"Application Compatibility Update for Windows 7 and Windows Server 2008 R2: August 2010".Support.Microsoft.August 24, 2010.RetrievedFebruary 7,2017.

External links[edit]