Demand Paging MS-DOS-Based Applications (47125)
The information in this article applies to:
- Microsoft Windows Software Development Kit (SDK) 3.0
- Microsoft Windows Software Development Kit (SDK) 3.1
This article was previously published under Q47125 SUMMARY
The following article has two parts. The first part applies to Windows
version 3.0, and to Windows version 3.1 without 32-bit disk access. The
second part applies to Windows version 3.1 with 32-bit disk access.
MORE INFORMATIONPart 1: Windows 3.0, and Windows 3.1 Without 32-Bit Disk Access
Under enhanced mode Windows version 3.0, it is not possible to allow
MS-DOS-Based applications to use virtual (demand paged) memory (VM) when
they are active (they are the foreground application, or have the
background execution option set). This is because the paging
mechanisms of the system use either:
- MS-DOS plus an MS-DOS device plus INT13
- Just INT13
In other words, to access the paging file (virtual memory that is
currently demand-paged out) Windows must call code that resides in
the VM along with the application (BIOS, MS-DOS, and so on).
The problem this causes is best illustrated by an example:
- Run an MS-DOS-based application that hooks INT 13h.
- Arrange to "page out" the page that has part of the application's
INT 13h hook in it.
- Touch a "not present" page.
- This generates a page fault.
- The system calls "page this page in."
- This calls INT 13h.
- This page faults because the INT 13h hook of the application is
currently paged out.
- The system calls "page this page in."
- This calls INT 13h.
- This page faults because the INT 13h hook of the application is
currently paged out.
This continues forever, causing a deadlock situation, and the system
halts.
To prevent this problem, make sure every page of an MS-DOS-based
application is always present when the application's VM is active. Thus,
MS-DOS-based application VMs are always present, and therefore, do not use
demand-paged memory except when they are not active.
Given the way that system paging works, there is no way to work around
this limitation, partly because the installed MS-DOS-based application base
is so diverse. Note also that this problem with INT 13 is only part of
the picture. Almost all hardware interrupts can cause exactly the same
problem.
Part 2: Windows version 3.1 with 32-Bit Disk Assess
One solution is to change the way system paging works so that to
access the paging file, the system paging does not have to use any
code that resides in the VM with the application. 32-bit disk access
for Windows version 3.1 performs this type of functionality.
32-bit disk access addresses the problem that prevents the demand
paging of MS-DOS-based application VMs. 32-bit disk access allows the
paging component of the system to access the paging file without having to
access anything that resides in the VM (the application, MS-DOS, the
BIOS, and so on). This prevents the paging deadlock problem discussed
above because all of the code and data needed to access the paging
file is inside enhanced mode Windows and is designed such that access
to the paging file will never cause a page fault to occur.
As a side benefit, this is also much faster than calling MS-DOS or
some other component in the VM because calling VM code requires that
the 80386 CPU change modes between protected mode and virtual mode.
The transitions between CPU modes are quite expensive in terms of CPU
cycles. Therefore, the other benefit of 32-bit disk access is that
there is an improvement in "paging throughput" because the "CPU mode
transitions" required by access to the paging file through MS-DOS or
INT 13h are eliminated.
Modification Type: | Major | Last Reviewed: | 10/30/2003 |
---|
Keywords: | kb16bitonly KB47125 |
---|
|