Method for providing protected mode services for device drivers and other resident software

Abstract

A method and system for allowing protected mode device drivers and resident programs to load and execute from an MS/PC-DOS environment. A further method enabling such protected mode programs in an Intel x86 environment to transition between host environments is provided. In a preferred embodiment, a method for allowing for protected mode programs running in a DOS environment which can then transition and continue to function in a Windows environment. An improved method of mode switching for such drivers is also provided.

Description

TECHNICAL FIELD

This invention relates to personal computer systems. More particularly, the present invention relates to personal computers utilizing Intel architecture operating in a mixed mode environment.

BACKGROUND ART

Because of the peculiar evolution of Intel architecture personal computers, there has been a continuous need for the operating system to support what is now known as a "Real Mode" environment. The first 8088 series microprocessors were designed to utilize operating or random memory of up to 1024 Kilobytes. While this constraint was not originally seen as a significant limitation, subsequent increases in computing power of subsequent generation processors have increased the need for greater memory. Since the development of the 8088 architecture, a variety of methods have evolved to provide access to such extra memory. With the advent of the 286 series microprocessor, "protected mode" became available as part of the central processing unit (CPU)'s architecture, and a method for switching back and forth between real and protected modes was provided in the basic input/output system (BIOS) provided with the system. Vendors used this mode switching capability to create "DOS Extender" programs that allowed an application to run in protected mode and then switched back to real mode to perform system related operations such as I/O and file management. When operating in the Protected Mode, a series 286 processor was able to increase the amount of memory available to 16 megabytes. Such additional memory was called extended memory.

The advent of the 386 series microprocessor architecture with paging capabilities and "Virtual 8086" (V86) Mode, saw the advent of "memory management" programs that provided the paging capability to real mode programs. These programs, part of a class called V86 Mode Monitors or Virtual Mode Monitors (VMMs), operate the system in protected mode and provide certain services to one or more V86 mode environments. These services typically consist of memory management services, but VMMs exist for multi-tasking (Microfsoft's Windows), providing debugging capabilities (Nu-Mega Technologies' Soft-ICE) and various other uses.

Since Intel architecture provides for only a single protected mode environment or VMM to be active at any one time, the VMMs and DOS Extenders were thus unable to co-exist, and a group of vendors of the two technologies united and provided the Virtual Control Program Interface (VCPI). This Application Program Interface (hereinafter "API") provides DOS Extenders the ability to switch the protected mode environment to and from the VMMs, allowing the DOS extenders to function much as they did in the 286, BIOS switched environment, but with the VMM switching in and out of the DOS Extender's environment rather than the BIOS.

The pressure on the real mode address space was not fully relieved, however. Neither the paging capability provided by memory manager VMMs, nor the application relief provided by DOS Extenders, was sufficient to meet users needs for real mode address space, and in late 1989 Helix Software Company of New York developed Netroom, a product that used the paging capability of the 386 to multi-task certain layers of the operating system in a manner similar to overlay technology found in more sophisticated operating environments, such as expounded in U.S. Pat. No. 3,618,045 to Campbell. In July of 1991 Quarterdeck Office Systems of California used a similar technology to overlay the BIOS with Real Mode addressable RAM. These techniques are limited in that by using paging and overlay techniques they can place a substantial drain on performance. They also limit the address space of the drivers and other resident software that they manage to the size of the overlay region which, of course, is at most, limited to the 1 Mb V86 address space, and in practice is substantially smaller.

With the advent of Microsoft Windows, Microsoft needed a method that would allow DOS Extenders to coexist with Windows, and thus developed the DOS Protected Mode Interface (DPMI), Intel Corporation document 240977-001, which is actually the API for the DOS Extender that is built into Microsoft Windows. Thus, existing DOS Extender programs could perform simple translations on behalf of the applications, allowing them to operate in a Windows controlled environment.

DOS Extender companies have also provided Protected Mode capabilities to operating system level software such as device drivers and resident software (collectively "drivers"). This technology has the advantage of not limiting the address space of the drivers. However, DOS Extender methodology has significant drawbacks when used in a driver environment. First, each driver must have its own DOS Extender, creating multiple environments that must be supported. Second, since DOS Extenders run in their own protected mode environment, several useful capabilities such as having universal and immediate access to interrupts, are not available. In addition, DOS Extender technology is based upon switching from one protected mode environment to another. This switching has inherent CPU overhead which makes it substantially slower than desired for operating system level software that may be required to respond very quickly, in "real time".

U.S. Pat. No. 4,974,159 to Hargrove, et al. describes a method for transferring control to protected mode from Virtual 8086 mode using a faulting mechanism. This method is convenient in that it requires only one byte of code in the V86 instruction space, and can be used to transfer control to a dispatcher that can then call protected mode routines, simulate some V86 function or return from a call to a V86 routine. However, this mechanism has several drawbacks when considered for use in an environment in which drivers or resident software is running in protected mode. First, the faulting mechanism involved is slow, requiring a CPU fault (error condition) to switch modes. Second, the processing of the fault is inherently slow because the instruction causing the fault must be examined to determine the cause of the fault. Also, the mechanism for dispatching from the fault handler requires data structures which associate a particular fault location with a particular protected mode routine. This causes either a fixed limit to the number of such faults that can be handled (as is the case in Microsoft Windows), or requires a complex allocation scheme to allow for the dynamic creation of such structures.

Finally, in order for any protected mode drivers to be truly useful they must be able to operate with Microsoft's Windows (hereinafter simply "Windows") and other multi-mode operating environments. The obvious approach to this problem, which has been taken by DOS Extender vendors, is to maintain a separate environment as they do in the DOS Extender/VMM arena, and since Windows does not contain a VCPI-like interface of its own when Windows starts up its environment, write a Windows device driver that transfers control over from the Windows Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT) to the protected mode GDT/IDT that the DOS-Extended software operates on, much like VCPI provides.

This approach is similar to VCPI and has many of the same drawbacks as VCPI itself, namely, it is slow, does not allow for some particularly useful capabilities as discussed earlier, and is difficult to implement. It has the additional drawback in a Windows environment of conflicting with Window's internal faulting mechanism, requiring several VCPI-like switches for each event causing a fault.

SUMMARY OF THE INVENTION

It is the object of the present invention to provide an improved system and method for providing protected mode capabilities for drivers.

It is a further object of the present invention to provide complete access to all capabilities of protected mode operation to protected mode drivers.

It is a further object of the present invention to provide a mode switching technology that is optimized for drivers and resident software to provide maximum throughput capabilities.

It is a further object of the present invention to provide a method whereby all protected mode capabilities can be available in a multiplicity of environments and, in particular are available in a Microsoft Windows environment.

These and other objectives, which will become apparent as the invention is described in greater detail are obtained by providing an improved method and system for managing protected mode in an Intel architecture environment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a representation of the relationship between the various elements of an operating environment of the present invention;

FIG. 2 is a representation of the start-up of a driver in accordance with the present invention;

FIG. 3 is a flowchart depicting interrupt processing by the present invention;

FIGS. 4A and 4B are flowcharts depicting the development of a passalong address and the processing of such address during control transfer; and

FIG. 5 is a representation of the control transfer methodology in a Windows or other similar environment.

DETAILED DESCRIPTION OF THE INVENTION

In a preferred embodiment, the present invention is used in place of the basic low-level software that provides the protected mode environment of the operating system, the VMM. The implementing software must be in itself a full featured VMM 10 that provides the basic protected mode service provided by standard memory management software, including available extended and expanded memory (EMS, XMS), and VCPI services. However, a preferred embodiment must also provide a built-in interface 12 that contains and provides to other programs the following capabilities as shown in FIG. 1:

a. Detection of the presence of the capabilities; b. Allocation and de-allocation of selectors from the GDT 14; c. Setting of various selector parameters, such as base and limit; d. Trapping or hooking of the IDT 16; e. Obtaining and setting the passalong address; f. Switching of V86 mode code to protected mode code at initialization. This function allows a protected mode program to run on the same GDT and IDT as the memory manager. More specifically, a program 18 running in V86 mode must be allowed to allocate memory outside the V86 mode address range (extended or XMS memory 20), and to load this memory with program code. The XMS interface is ideally suited for this, allowing extended memory to be allocated and loaded. However, the VMM must then be capable of allocating selectors on its own GDT and providing an interface which allows a V86 mode program to start up the protected mode code that was loaded into the extended memory. The present invention automatically creates, or allows the creation of, selectors that can address the extended memory, and transfers control to some known or specified location within said memory; g. Return of the protected mode program to the V86 mode to allow DOS programs to continue to operate. In a preferred embodiment, after initialization, the program should return directly to the V86 mode code that initiated the protected mode execution. h. Switching to and controlling the protected mode program at run-time.

The memory manager must also have the following specific characteristics:

The ability to operate with protected mode interrupts resulting from any protection level and any selector. More specifically, the VMM should behave as follows when processing an interrupt: If the interrupt occurred from protected mode it should be immediately reflected or passed to V86 mode. If the interrupt occurred in V86 mode it should be examined for possible use by the VMM, and if no use is found, it should be reflected directly back.

In order to accomplish this, the VMM must not depend on the stack pointer pointing at a particular location upon entry to the VMM from an interrupt event. Accordingly, the present invention provides for a reference back to the EFLAGs register located on the stack at interrupt time to determine whether the interrupt occurred in V86 mode or protected mode as shown in FIG. 3. In particular, when reflecting the interrupt from protected mode, the VMM must be designed in such a way that it can either save its own internal state and return to the saved state smoothly, or to be designed so that it is completely re-entrant.

Furthermore, the handling of interrupts must specifically be designed so as to protect high order registers of protected mode code. Specifically, when reflecting interrupts to V86 mode, the VMM should not allow changes made to the high-order (top 16 bits) of the 32 bit registers to be changed by the V86 mode code. It has been found that several V86 mode programs feel free to destroy the contents of the high order registers during interrupt handling, and this can interfere with the execution of protected mode software. The routine set forth in FIG. 3 maintains such registers at 22 and eliminates this problem.

The memory manager must also allow protected mode programs to manipulate the registers of the V86 mode execution stream. This can be accomplished by saving the registers in an area accessible to protected mode drivers, and providing that any change to this area shall be passed to V86 mode 26. This is illustrated in FIG. 4, which routine is entered after an interrupt is processed in accordance with the routine of FIG. 3.

In addition, the ability to allocate selectors from an indeterminate, user settable starting point, generally somewhere roughly the middle of the range of valid selector values, should be provided. This ability should also provide for allocating selectors in a top-down fashion if needed. This complicates implementation substantially, but is particularly important as it facilitates the transfer into other environments.

This particular combination of capabilities and characteristics provides particular benefits which enhance the operation of drivers in a way not possible with, for instance, DOS Extender style protected mode device driver capabilities which use VCPI. It also makes possible the transitioning of the drivers in a Microsoft Windows-like multi-mode operating environment as discussed below.

This particular combination allows for the following sequence to commence upon the loading of drivers, allowing the drivers to run on in the same protected mode environment as the VMM.

According to an aspect of the invention as presented in FIG. 2, drivers 22 proceed by detecting the presence of the VMMs 10 implemented in the fashion according to the invention. Then, the drivers allocate memory outside the usual V86 address range using the function defined in (e) above. The protected mode code then initializes its own operation, performing as needed. When the initialization is complete, the code transfers control back to the V86 code that launched it, preferably by simply issuing a Far Return instruction.

As shown in FIG. 4A, during initialization the protected mode code can issue a call to the VMM to get the current value of a pointer, called the passalong address 24. This value is stored by the protected mode program which then uses another call to set this address. The new value is a pointer to a routine within the protected mode code called a passalong handler 26.

Following initialization control transfer issues become critical and timing sensitive. To provide for optimal switching speed a preferred embodiment of the present invention uses one of the Intel Architecture's INT xx instructions 28 to transfer control to protected mode from V86 mode. This instruction causes the processor to transfer control to an instruction whose address is specified in the IDT 16. This should point at a routine in the VMM that does only two things, as shown in FIG. 4B. In step (1), the interrupt is distinguished as coming from V86 mode. If it is, then the VMM simply issues a PUSHAD instruction or an equivalent sequence to set up a memory address that contains all the V86 mode registers. The VMM then loads the stack pointer into one of the general registers and issues a Far Call to the passalong address.

The passalong address is set up such that it initially points at a Far Return instruction. When a protected mode program gets and sets the address to its own routine, it effectively inserts itself into a chain of program routines that are called whenever the INT instruction to transfer control to protected mode executes. Each of the routines can examine the V86 mode registers to determine where the INT instruction was issued or to find some value that has a particular meaning to the protected mode code. If the particular instruction occurred at an address known on a pre-defined basis by the protected mode code (such as if it occurred within the V86 mode code that launched it), or in any event if the protected mode passalong handler decides that it needs to on any basis, the passalong routine can perform some function it desires. If the INT instruction is of no meaning or use to the passalong it simply issues a jump to the address it got of the previous passalong handler or the original Return instruction.

This effectively creates a jump chain of protected mode programs with each examining a value and jumping to the next, ending in a return. If all have finished processing the VMM reflects the interrupt, otherwise the passalong handler handling the call signals that the interrupt has been handled and returns, as presented in FIG. 4B.

Contrary to what may seem to be a slower approach than in Hargrove, this is actually far faster. The speed is achieved in the minimizing of the instructions needed to get to the first entry on the passalong chain, and by defining the chain as a simple check-and-jump series. Also in newer implementations of the Intel architecture, such as those found on the I486 and Pentium family, the mode switch caused by an INT instruction is optimized over the faulting mechanism and achieves further gains.

The INT instruction is also inherently distinguishable as one of a family of 255 INT xx instructions, and thus several such passalong chains can be established, each with direct, CPU-controlled access. Lastly, this approach is not limited in that there is no address table needed, and each passalong handler has its own effective and internal dispatch table and is thus limited only by available memory.

Once the above is set up it is possible to transfer control, and maintain operational functionality in other protected mode environments using the following method, as shown in FIG. 5: A device driver native to the other protected mode environment 30, which is Microsoft Windows in a preferred embodiment (we will refer to Windows although the procedure applies to other environments such as OS/2), must be written to comply with the environment's known specification. This Windows device driver or VXD 32 must, upon start up, be able to identify the location 34 in physical memory of the VMMs GDT, and of the passalong address 24. This is accomplished by establishing a protocol in which these physical addresses are stored in a known location, or passed directly to the VXD at startup.

The VXD then reserves selectors on the Windows GDT 36 to match those on the VMM GDT 14 that contain the protected mode device driver selectors, those allocated in the middle of the GDT or in a top-down fashion. This is accomplished by allocating GDT selectors using known methods (see, e.g., Microsoft document number PC29133-0592) until the selector region used by the VMM is reached. The allocation of selectors continues until all selectors previously available through the VMM have been allocated. The Windows device driver (VXD) then releases selectors not in the VMM's allocatable range back to Windows. Note that the selectors were specifically defined as starting in the middle of the GDT to facilitate this, and that the starting point for selectors in the VMM may need to vary from one environment to another.

Once the selectors have been reserved, the active selectors from the VMM environment have their base limit and kind copies to the corresponding entry on the Windows GDT. This is accomplished by the VXD reading the values directly from the VMM's GDT, the address of which is known as defined above. The VXD then copies values read from the VMM GDT for each selector's base, limit and type into Windows' GDT, translating the base value as needed and using the Windows API.

The VXD must then establish itself in a position to provide the same API as the VMM by trapping the appropriate entry points. This is accomplished by having the entry point accessible through one of the "global" selectors copied from the VMM, or by providing an API which is interrupt based, in which case the VXD must trap the corresponding interrupt in Windows during the Windows start-up. In the preferred embodiment, both methods are used for the convenience of driver developers. Once so established, the VXD can either perform, in the new VMM environment, the equivalent functions as available in the old environment, or translate the function into the equivalent function as available in the new environment.

The VXD must further establish itself to trap, within Windows, the INT/passalong mode switches defined previously. This is accomplished either by hooking the Windows IDT, or by hooking the Windows internal interrupt dispatcher using known techniques. As part of this process, the VXD must provide a passalong dispatcher that operates in a manner similar to the dispatcher described for the VMM. In the preferred embodiment the VXD hooks the Windows internal interrupt dispatcher, allowing Windows to operate in a more normal fashion.

Finally, the VXD must issue a broadcast along the passalong chain, the handlers of which are now active (because their selectors are pre-defined). This broadcast must be distinguishable as unique by all programs with handlers on the passalong chain, and can be accomplished by providing an invalid or unique set of values in the client register set. The passalong handlers can then modify their own behavior to suit the new environment and establish any Windows specific operations.

Once this is done, the drivers can continue to operate as before, but with Windows providing the primary VMM services.

Routines by which the present invention can be implemented are annexed hereto and presented in the following program listings. ##SPC1##

Claims

1. A virtual memory monitor (VMM) having a GDT and IDT and which operates in V86 and protected modes for operating protected mode device drivers under a non-protected mode operating system in a computer system, comprising:

interface means coupled to the computer system for detecting the presence of the virtual memory monitor by the device drivers;

means for allocating and de-allocating selectors from the GDT wherein selectors are allocated at a chosen distance from the start of the GDT or in a top-down order from an end of the GDT;

means for setting a base, a limit, a type and an access type parameters for said selectors;

means for trapping the IDT;

means for allowing a V86 mode driver to switch from V86 mode code to protected mode code previously loaded by the driver into extended memory of a V86 mode program whereby said protected mode code is initialized and executed on the same GDT and IDT as the VMM;

means for allowing said protected mode code to return to the V86 mode for continuation of operation of DOS programs;

means for allowing protected mode programs to manipulate registers of the V86 mode execution shown by providing access to a memory location having said registers;

means for allowing interrupts from or in protected mode operations to be reflected in a nested manner to V86 mode;

means for protecting high order registers of said protected mode code by maintaining values of said high order registers in memory and restoring said registers at a completion of an interrupt procedure; and

means for allocating selectors from a user selectable starting point.

2. A method for transferring control between a first protected mode environment and another protected mode environment in a personal computer system including system memory, consisting of the steps of:

a) creating a first VMM comprising a control program having a GDT in which protected mode client programs are able to execute with their protected mode selectors defined on the GDT of the VMM and offset from the start of the GDT by a user definable or fixed value, or in a top-down fashion;

b) designating a fixed or known location in the computer system memory through which the location of the GDT for said first VMM environment can be determined;

c) creating in said second VMM environment a driver in accordance with the requirements of said second environment to allocate available selectors in said second environment whereby all selectors defined in environment 1 are allocated to said driver;

d) reading the values of the selectors from memory areas of said first environment by said device driver;

e) translating the values of said selectors into corresponding values that address the same physical memory in said second environment by said device driver;

f) establishing said translated values into selectors of a corresponding offset in the GDT of said second environment by said device driver;

g) having said device driver allocate to itself resources to provide the same API services available in said first environment to said second environment; and

h) notifying client programs by said device driver that an environment transition has taken place, and providing the client programs an opportunity to adjust their execution as needed,

3. An improved method for transferring control between Virtual 8086 mode code executing under a VMM and protected mode code in the same environment, consisting of:

a) creating a routine in the VMM that intercepts the execution of an INT instruction in a client program by placing the address of the routine in a IDT;

b) determining whether the execution of said routine was initiated from V86 mode by examining the status of a VM bit in a EFLAGS on a received stack frame;

c) transferring said routine to V86 execution if said bit indicates the INT instruction originated in V86 mode, otherwise performing a subroutine of the following steps if the status of said bit indicates the INT instruction originated in V86 mode;

d) saving all registers by said routine in a memory location;

e) loading by said routine a specified general register with an address of a save area of V86 mode general registers; and

f) transferring control by said routine from VMM to an address identified by a memory pointer.

4. The method of claim 3 whereby another routine may intercept the execution of a V86 mode execution code, comprising the following additional steps:

a) obtaining by said another routine the value of the pointer defined in step fusing a provided API;

b) setting by said another routine the value of the pointer so that the pointer contains the address of said another routine;

c) examining by said another routine the value of the V86 mode general registers pointed to by the general register defined in order to determine if any action is needed; and

d) completing execution by said another routine by transferring control to the address gotten in step a, or by returning control back to a calling routine.