Windows on Windows: Difference between revisions

Revision as of 15:55, 6 July 2020

Latest revision as of 06:00, 24 July 2025

(45 intermediate revisions by 25 users not shown)

Line 1:

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

{{multiple|

{{primary sources|date=October 2018}}

Line 11 ⟶ 13:

| other_names = WOW

| developer = [[Microsoft]]

| released = {{Start date and age|1993|07|27}}

| replaces =

| operating system = [[Microsoft Windows]]

| platform = [[IA-32]]

| genre = [[Compatibility layer]]

| 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]]|accessdateaccess-date=February 7, 2017|date=February 22, 2007|url-status=dead|archiveurlarchive-url=https://web.archive.org/web/20071023060218/http://support.microsoft.com/kb/181333|archivedatearchive-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|accessdateaccess-date=February 7, 2017|website=Support|publisher=[[Microsoft]]|url-status=dead|archiveurlarchive-url=https://web.archive.org/web/20070509051612/http://support.microsoft.com/kb/153544|archivedatearchive-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]]|accessdateaccess-date=February 7, 2017|url-status=live|archiveurlarchive-url=https://web.archive.org/web/20080113000651/http://support.microsoft.com/kb/220159|archivedatearchive-date=NovemberJanuary 3013, 2008}}</ref>) is a discontinued [[compatibility layer]] of [[32-bit computing|32-bit]] versions of the Microsoft [[Windows NT]] family of [[operating system]]s. Since 1993, with the release of [[Windows NT 3.1]], thatWoW 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 will be retired with 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) only run the [[x86-64]] processor in [[long mode]] and therefore cannot run 16-bit software without emulation software.

==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,{{Citationcitation 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===

{{Main article|Thunk#Interoperability}}

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.

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 {{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|accessdateaccess-date=February 7, 2017|website=Support|publisher=[[Microsoft]]|url-status=dead|archiveurlarchive-url=https://web.archive.org/web/20070316022744/http://support.microsoft.com/kb/105992|archivedatearchive-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]]|accessdateaccess-date=February 7, 2017|date=November 21, 2006|url-status=dead|archiveurlarchive-url=https://web.archive.org/web/20090222173939/http://support.microsoft.com/kb/199671|archivedatearchive-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 [[File AllocationDesign_of_the_FAT_file_system#Directory_entry|directory Tableentry]].

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|accessdateaccess-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]]|accessdateaccess-date=February 7, 2017|date=August 24, 2010}}</ref>

==See also==

* [[Wine (software)]]

* [[Virtual DOS machine#WineVDM|OTVDM]], a third-party project based on code from Wine which runs 16-bit Windows programs on 64-bit versions of Windows.

==References==

Line 53 ⟶ 57:

* [http://www.microsoft.com/technet/archive/winntas/training/ntarchitectoview/ntarc_5.mspx?mfr=true Windows NT subsystems]

* [http://kb.iu.edu/data/acxn.html What are NTVDM and WOW?]

* {{cite web |url = http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/preb_mon_ewvl.mspx |title= Monitoring 16-bit Windows applications |series= TechNet |publisher= Microsoft |url-status= dead |archive-date= DecDecember 25, 2007 |archive-url= https://web.archive.org/web/20071225171241/https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/preb_mon_ewvl.mspx }}

* [https://technet.microsoft.com/en-us/magazine/ff756590.aspx Optimize How Windows 7 Runs 16-Bit and MS-DOS-Based Programs]

Line 59 ⟶ 63:

{{DEFAULTSORT:Windows On Windows}}

[[Category:Discontinued Windows components]]

[[Category:1993 software]]

[[Category:Compatibility layers]]