Windows on Windows: Difference between revisions

Revision as of 10:09, 26 January 2024

Latest revision as of 06:00, 24 July 2025

(12 intermediate revisions by 8 users not shown)

Line 1:

{{Short description |SubsystemDiscontinued subsystem for 32-bit Windows for running 16-bit Windows programs}}

{{multiple|

{{primary sources|date=October 2018}}

Line 19 ⟶ 20:

| license = [[Proprietary software|Proprietary]] [[commercial software]]

}}

In [[computing]], '''Windows on Windows''' (commonly referred to as '''WOW''')<ref>{{cite web|url=http://support.microsoft.com/kb/181333|title=WOW Environment Remains in Memory After Quitting 16-Bit Program|website=Support|publisher=[[Microsoft]]|access-date=February 7, 2017|date=February 22, 2007|url-status=dead|archive-url=https://web.archive.org/web/20071023060218/http://support.microsoft.com/kb/181333|archive-date=October 23, 2007}}</ref><ref>{{cite web|url=http://support.microsoft.com/kb/153544|title=Starting 16-Bit WOW Subsystem on Windows NT Server|date=November 1, 2016|access-date=February 7, 2017|website=Support|publisher=[[Microsoft]]|url-status=dead|archive-url=https://web.archive.org/web/20070509051612/http://support.microsoft.com/kb/153544|archive-date=May 9, 2007}}</ref><ref>{{cite web|url=https://support.microsoft.com/kb/220159|title=Disabling the MSDOS and WOWEXEC Subsystems on Terminal Server|date=November 1, 2006|website=Support|publisher=[[Microsoft]]|access-date=February 7, 2017|url-status=live|archive-url=https://web.archive.org/web/20080113000651/http://support.microsoft.com/kb/220159|archive-date=January 13, 2008}}</ref> wasis a discontinued [[compatibility layer]] of [[32-bit computing|32-bit]] versions of the [[Windows NT]] family of [[operating system]]s. sinceSince 1993, with the release of [[Windows NT 3.1]], whichWoW extends [[Virtual DOS machine#Windows NTVDM|NTVDM]] to provide limited support for running [[legacy codesystem|legacy]] [[16-bit computing|16-bit]] programs written for [[Windows 3.x]] or earlier. There is a similar subsystem, known as [[WoW64]], on [[64-bit computing|64-bit]] Windows versions that runs 32-bit programs.

This subsystem haswill sincebe beenretired discontinuedwith the [[Product lifecycle#Phase 4: Service|end of support]] of [[Windows 10]] in October 14, 2025. The last version of Windows to include this subsystem is Windows 10, as [[Windows 11]] (and [[Windows Server 2008 R2]] and later) are only availablerun inthe 64[[x86-bit64]] editionsprocessor in [[long mode]] and therefore cannot run 16-bit software without third-party emulation software (e.g. [[DOSBox]]). [[Windows 10]] is the final version of Windows to include this subsystem.

==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.1x1]] 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,{{citation needed |reason=What is the source of this assertion? The fact that you could boot to DOS? |date=January 2017}} 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 [[Execution_(computing)#Runtime|runtime]] limitations). They are called [[thunk]]ing and [[Shim (computing)|shimming]].

===Thunking===

Line 32 ⟶ 33:

The WOW subsystem of the operating system {{Clarify|text=thunks legacy 16-bit APIs to their newer 32-bit equivalents|date=July 2020}} in order to provide support for 16-bit [[pointer (computer programming)|pointer]]s, 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.

The {{mono|WOWEXEC.EXE}} process on a [[Windows NT]] system facilitates Windows-on-Windows.<ref>{{cite web|url=http://support.microsoft.com/kb/105992|title=Windows NT Subsystems and Associated Files|date=October 31, 2006|access-date=February 7, 2017|website=Support|publisher=[[Microsoft]]|url-status=dead|archive-url=https://web.archive.org/web/20070316022744/http://support.microsoft.com/kb/105992|archive-date=March 16, 2007}}</ref><ref>{{cite web|url=http://support.microsoft.com/kb/199671|title=PRB: Relocation of Ntvdm.exe Fails on Multiprocessor Computers|website=Support|publisher=[[Microsoft]]|access-date=February 7, 2017|date=November 21, 2006|url-status=dead|archive-url=https://web.archive.org/web/20090222173939/http://support.microsoft.com/kb/199671|archive-date=February 22, 2009}}</ref> In addition to Windows-on-Windows emulating the [[Windows 95]] and [[Windows 98]] [[kernel (operating system)|kernels]], the {{mono|WIN.COM}} file emulates a [[Windows 3.x]] kernel for [[Virtual DOS machine#Windows NTVDM|NTVDM]], which runs the 16-bit DOS-based Windows applications on Windows NT.

===Shimming===

{{Main article|Shim (computing)}}

Application compatibility issues, notably around [[long filename]]s, multiple users and the concept of [[Principle of least privilege|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 filename]]s 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 [[Design_of_the_FAT_file_system#Directory_entry|directory entry]].

Furthermore, legacy applications that attempt to access hardware directly cannot do so in [[Protection ring|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 {{mono|[[AUTOEXEC.BAT]]}} and {{mono|[[CONFIG.SYS]]}} having to be carried forward on operating systems that do not use them.

A considerable number of shims are present in the [[compatibility layer|application compatibility layer]] of later versions of Windows to intercept and modify [[Application programming interface|API]] calls made by legacy applications that were written with a different set of assumptions and operating system best practices in mind.<ref>{{cite web|website=TechNet|publisher=[[Microsoft]]|url=https://technet.microsoft.com/en-us/library/ee461265(v=ws.10).aspx|title=Application Compatibility|access-date=February 7, 2017}}</ref> These fixes are updated from time-to-time as issues are discovered in popular legacy applications that are still in use.<ref>{{cite web|url=http://support.microsoft.com/kb/2272691|title=Application Compatibility Update for Windows 7 and Windows Server 2008 R2: August 2010|website=Support|publisher=[[Microsoft]]|access-date=February 7, 2017|date=August 24, 2010}}</ref>

Line 64 ⟶ 65:

[[Category:Discontinued Windows components]]

[[Category:1993 software]]

[[Category:Compatibility layers]]