BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally related to the design of device drivers utilized in computer operating systems to define and establish an interface between the core operating system and typically hardware devices and, in particular, to a modular device driver architecture providing a virtualized, context switchable interface environment within which to operate typically hardware devices in support of operating system functions, specifically including information display functions.

2. Description of the Related Art

In conventional computer systems, software operating systems provide generalized system services to application programs, including utility and daemon programs. These system services conventionally include access to whatever individual hardware peripheral devices, each generally presenting a well defined hardware interface to the computer system, may be attached directly or indirectly to the computer system. Device drivers, implemented as software modules or components that can be integrated into an operating system, are typically used to provide well defined software application program interfaces (APIs) to the operating system and application programs for each of the hardware interfaces. Device drivers often provide a degree of device independence or virtualizing that may simplify the interaction of an application program or operating system with the specifics of a particular class of hardware interface, such as a video controller. Conventionally, for each implementation underlying a particular hardware interface, a specific device driver is used to implement an otherwise common API that is presented to the application programs and operating system.

A number of problems are inherent in conventional device driver designs. First, conventional device drivers are specific to a particular hardware interface and the function of the underlying device or controller system. Thus, whenever a new or different version of a hardware controller is produced, a new device driver equally specific to the new or different hardware must also be developed. Where there are many different versions of a hardware device, a generally like number of device drivers must be developed. Alternately, single combination device drivers may be constructed to support multiple versions or types of devices. Such device drivers typically incorporate multiple device specific drivers that are otherwise substantially independent of one another into single binary file.

The effective number of device drivers needed to support a particular piece of hardware is also dependant on the number and differences in the operating system environments within which the hardware is to be used. In all but the most closely related operating systems, a substantial redevelopment of the device driver is required to both provide for the proper ability to incorporate the device driver into a particular operating system and, perhaps more significantly, to provide a logically similar though often entirely different API to the operating system and applications. Usually, the detailed definition of the API of the device driver governs the detailed design of the device driver itself. Consequently, device drivers for the same hardware but for different operating systems are often almost completely independently developed.

Another consideration that affects the number of device drivers that are required to support a particular hardware controller arises from the nature of other hardware and systems that are connected to a particular controller. Again, to provide flexibility in the detailed construction of computer systems, a hardware controller may be capable of supporting a number of distinctly different modes of operation. For example, a video controller may be able to support a significant range of video display resolutions and color depths. However, the range may be constrained by direct limitations such as the amount of video RAM actually implemented on a particular video controller and indirectly by the maximum vertical and horizontal frequencies of an attached video display. The requirements of particular applications may also drive the selection of a particular mode of operation that must be supported by a device driver. Conventionally, a number of device drivers are provided with the hardware controller, each supporting a different set of one or more modes of operation. One of the provided device drivers must therefore be selected for operating system incorporation based directly on the configuration of the particular computer system. Aside from the difficulties of picking a device driver that supports the desired set of operating modes, a substantial difficulty exists in preemptively determining the variety of modes that different individual device drivers are to support. Although the individual drivers may differ only by some modest amount, their number may be significant in terms of development.

A second problem, in part a consequence of the first, is that each device driver must be thoroughly tested in the full variety of environments that the device driver may be used in to ensure commercially acceptable operation. Conventionally, device drivers are essentially monolithic software modules that are incorporated bodily into the operating system. As such, testing of even minor variants of a device driver for a particular operating system requires that the full suite of operational function and application compatibility tests be run to verify correct operation of the device driver. Selective functional testing is generally inappropriate due to the real possibility of collateral operational errors arising from any modification of a monolithically coded device driver. Given the substantial number of effectively different device drivers conventionally supported for a reasonably complex hardware controller and the size and substantial extent of corresponding test suites, the testing of device drivers represents a substantial expense and a very significant delay in bringing new or improved versions of a product to market.

A third problem with conventional device driver designs is that they provide for a substantially static type of hardware controller management. In general, device drivers establish a single set of operating parameters for the hardware controller being managed by the device driver. The operating system and the application programs executing on the computer system all must accept the parameters of this static mode or essentially fail to operate correctly.

In limited instances, a conventional device driver may make some modes available or visible to application programs. To make use of these modes, the device driver therefore relies on application programs to have essentially compiled-in hardware dependencies. In such cases, the application programs may invoke a mode change, though with potential detrimental effects on the other executing programs that, even if capable of invoking a mode switch, are effectively unaware of any such switch.

Some typically multi-tasking operating systems can perform limited dynamic hardware controller mode switching, though only through an operating system supported state change. In these cases, the operating system essentially reloads the state of the device driver and hardware controller consistent with the state of a new mode of operation. However, there is no direct relation between the applications executing and the state of the device driver and hardware controller. Again, any executing applications are largely if not completely unaware of any mode switch. Consequently, the selected mode may be optimal for some executing application, but not necessarily the application with current execution focus.

SUMMARY OF THE INVENTION

Thus, a general purpose of the present invention is to provide a flexible, modular device driver architecture that can provide independent hardware configuration options on a dynamic reconfiguration basis.

This is achieved in the present invention by providing a device driver architecture that operates to couple an operating system, provided in the memory of a computer system having a processor, to a computer interface of a controller device that includes a plurality of functional sub-elements. The device driver includes a plurality of operating system interface objects each presenting an operating system interface (OSI) to the operating system, a plurality of computer interface objects each providing for the generation of programming values to be applied to the computer interface to establish the operating mode of a respective predetermined sub-element of the controller device, and a device driver library of processing routines callable by each of the plurality of operating system interface objects to process data and generate calls to the plurality of computer interface objects in predetermined combinations. The device driver library enables the selection of execution contexts within which to define the generation and application of the programming values to the computer interface.

An advantage of the present invention is that the state of the hardware interface and, correspondingly, the state of the controller that presents the hardware interface, is virtualized and maintained in discrete contexts. Operational features or modes of a controller that must otherwise be handled or managed by individual application programs can be virtualized by operation of the present invention. The present invention provides for application specific, dynamic alteration of the state of the hardware interface through essentially private context switching implemented by operation of the device driver. Selected operating system events are modified or trapped to initiate the creation of new contexts and the dynamic switching between contexts by the device driver.

Another advantage of the present invention is that the device driver provides for a comprehensive optimization of the functions supported through the device driver by the controller. The device driver provides for the virtualization of the API call interfaces supported by the device driver. Virtualization of the call interfaces through the use of operating system interface objects provides specific support for independently defined APIs and the translation of functionally equivalent calls to be supported by substantially common execution streams.

A further advantage of the present invention is that virtualization of the call interfaces of the device driver architecturally establishes a common evaluation of API calls and their parameters, essentially eliminating any requirement for subsequent parameter checking within the common execution streams. The resultant substantially linear execution streams, coupled with pointer referencing of context data structures ensures efficient execution performance while enabling substantially greater functionality than achievable in conventional monolithic device drivers.

Yet another advantage of the present invention is that the device driver provides for context dependant alteration of the substantially linear execution streams. Conversion functions required to enable or support switching between contexts are supported by linking the functions directly into the execution streams so as to minimize repetitive testing to determine whether a conversion function need be performed.

A still further advantage of the present invention is that the device driver incorporates dynamic loading and configuration of essential functional objects necessary or optimal to support the particular controller configuration accessible through the hardware interface. The device driver responds to encoded configuration data obtained through the hardware interface or otherwise from the controller to identify the independent functional sub-elements constituting the controller, determines a corresponding set of hardware interface objects appropriate to support the sub-elements and dynamically loads and links in the object set as part of the initialization of the device driver.

Still another advantage of the present invention is that the device driver supports a variety of hardware interface objects that are programmable with respect to certain functional or operational aspects. Based on the encoded configuration data obtained through the hardware interface or otherwise from the controller, the device driver identifies and loads configuration data from system memory to program the hardware interface objects with operational configuration data defining details of how the hardware interface objects will support their corresponding sub-elements.

Yet still another advantage of the present invention is that the device driver provides an established architecture within which new hardware interface objects can be developed in substantial isolation from other hardware interface objects and other architectural components of the device driver. The architectural design of the hardware interface objects themselves also allows substantial configuration revision and enhancement to be performed through redefinition of the operational configuration data used to program the corresponding hardware interface objects. Modification of a device driver to support a revised or new controller sub-element may be limited to simply editing a configuration data file as opposed to preparing source code modifications to the sub-element corresponding hardware interface object. In any case, compatibility testing can be appropriately limited to testing the particular hardware interface object that supports a revised or new sub-element of a controller.

A yet still further advantage of the present invention is that the device driver provides for modification of the operating system to enforce a consistent reporting of the color depth currently supported by a video display controller. Different color depth contexts are established for the set of executing application with each context corresponding to the maximum acceptable color depth of one or more executing applications. As context is changed and where the maximum color depth of an application exceeds the color depth capabilities of the video display controller, color depth conversion functions linked into appropriate linear execution streams provide for display data color depth conversion.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other advantages and features of the present invention will become better understood upon consideration of the following detailed description of the invention when considered in connection of the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof, and wherein:

FIG. 1

is a schematic block diagram of a computer system constructed in accordance with the present invention;

FIG. 2

provides a schematic block diagram of the architectural configuration of the present invention during initialization of the device driver of the present invention;

FIG. 3

provides a flow diagram detailing the initialization of the present invention;

FIG. 4

provides a schematic block diagram of the architectural configuration of the present invention during a run time execution of the device driver of the present invention;

FIG. 5

a

provides a general illustration of the relationship between plural shell objects defining device driver context, the Shell Library, and the physical device structure of the operating system consistent with the preferred embodiment of the present invention;

FIG. 5

b

provides a generalized illustration of the relationship between plural instantiations of a hardware interface object consistent with a preferred embodiment of the present invention;

FIG. 6

a

provides a flow diagram describing the performance of steps in preparing for a context switch in accordance with the preferred embodiment of the present invention;

FIG. 6

b

provides a flow diagram describing the steps utilized in realizing a new context in accordance with a preferred embodiment of the present invention;

FIG. 7

provides a software flow diagram of the steps utilized in terminating the operation of a device driver constructed in accordance with the present invention;

FIG. 8

provides a block diagram of illustrating the use of both real and virtual architectural configurations of the present invention in support of multiple virtual machines executing within an operating system consistent with the present invention; and

FIG. 9

provides a schematic block diagram of the architectural configuration of a virtual device driver constructed in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

I. Hardware System Overview

A computer system

10

, suitable for utilization of the present invention, is shown in FIG.

1

. The computer system

10

preferably includes a central processing unit (CPU)

12

coupled through a system data bus

14

to a main memory

16

and a mass storage peripheral

18

, preferably including a disk drive controller and hard disk drive unit. For purposes of the present invention, the operation of the mass storage peripheral

18

is sufficient if the supported function permits the reading of a certain executable, data and configuration files from a non-volatile resource. Thus, the mass storage peripheral

18

may be a communications controller providing access to a external or remote device or system that provides for the storage of data readable by the computer system

10

typically in a file oriented organization.

A video display controller

19

is also provided as a peripheral device coupled to the system bus

14

. The hardware implementation of the video display controller

19

is generally conventional in nature for purposes of the present invention. However, in the context of the present invention, the video controller

19

is uniquely described as a collection of logically independent sub-elements that together comprise the controller

19

. The sub-elements are logically distinguished by their functional identity particularly with regard to generally independent operational programmability. That is, the functional divisions of the hardware implementation of the controller

19

largely define the separate sub-elements of the controller

19

for purposes of the present invention.

Another basis for distinguishing the sub-elements is the grouping of functions based upon a commonality in the manner of programming the corresponding sub-element as a consequence ultimately by the programmed execution of the CPU

12

. Thus, as generally indicated in

FIG. 1

, the sub-elements of the video controller

19

preferably include, but are not limited to, a video display buffer

20

, a digital-to-analog converter (DAC)

22

, a video graphics accelerator

24

, a video controller

26

, a programmable clock generator

28

, a hardware cursor controller, and a coder-decoder unit (CODEC). Each of these sub-elements of the controller

19

are relatively independently programmable through a hardware register interface

30

that is appropriately coupled to the system bus

14

. Thus, the CPU

12

may program and obtain information from the sub-elements

20

,

22

,

24

,

26

,

28

. The register interface

30

and one or more of the sub-elements may, as a practical matter, be physically resident on a single integrated circuit. Co-residency of sub-elements on a single integrated circuit or the possibility that sub-elements are accessible through other sub-elements does not affect functionally distinguishing sub-elements from one another.

By the programming of the sub-elements

20

-

28

, a video display

32

is supported for the presentation of textual and graphical information. In a preferred embodiment of the present invention, multiple display windows

34

,

36

are supported in combination with a pointer

38

that can be used to select the current active or “focus” display window visible on the display

32

. A display window

34

,

36

can obtain the current focus through a number of discrete events. These events include the launching of a new application program for execution by the computer system

10

. By default, the main window of a newly launched application obtains the current focus of the display

32

. The pointer

38

can also be utilized to select a window

34

,

36

that is to receive a focus on the occurrence of a mouse click, for example. Finally, the display window

34

,

36

may receive focus upon termination of another application. In each of these circumstances a focus event is produced upon which the CPU

12

, through the execution of the operating system, can act.

Other peripherals

40

may also exist as components of the computer system

10

. These other peripherals

40

may include complex controllers supporting audio, real-time video, and other complex multi-function operations alone or in combination with one another. Such complex controllers may be effectively supported by the present invention provided that the functional operation and organization of the controller is reasonably sub-divided as a multiplicity of functional elements that are programmable directly or indirectly by the CPU

12

. For example, a high-performance audio subsystem presenting wavetable synthesis, FM synthesis, an equalization controller, a reverberation controller and multichannel amplifier sub-elements all directly or indirectly represented though a register interface presented to the system bus

14

can be optimally supported by the present invention.

II. Software System Overview

While the present invention may readily support any peripheral controller that has any number of sub-elements, the present invention may be best understood as applied in the preferred embodiment to the support and control of the video display controller

19

. Referring now to

FIG. 2

, a preferred device driver embodiment of the present invention

50

is shown positioned between the hardware interface, representing the logical connection of the device driver to the register interface

30

of the video display controller

19

, and an operating system layer

54

. The operating system layer

54

typically includes an operating system kernel

56

and potentially one or more operating system extensions

58

that add some basic operating system level functionality. Finally, the operating system layer

54

may in turn support one or more application programs

60

.

In operation, the application programs

60

obtain operating system layer

54

support services through an application program interface (API) that is presented effectively as a set of execution entry points that can be called by the application

60

. In accordance with an embodiment of the present invention, a small sub-set

62

of the operating system kernel API call points are modified during the initialization of the device driver

50

. These modified call points include the entry point routine that reports a window focus change event to an application

60

and the entry point routine that reports the current color depth of the display

32

back to the application

60

. The focus change event is preferably modified to include a API call to an operating system extension

58

that provides for additional event processing in response to a focus change event. This additional event processing includes performing a configuration retrieval to obtain data quantifying the execution environment of an application that is to be launched generally as a consequence of the focus event. The data retrieved preferably includes the screen resolution and color depth configuration desired for the application being launched.

The modifications of the color depth reporting routine are made specifically to ensure that the maximum color depth requested by any application

60

is reported to the application

60

as being the current color depth of the display

32

. Thus, in accordance with the preferred embodiment of the present invention, all applications

60

execute against a completely virtualized representation of the display

32

particularly with respect to color depth. That is, the device driver

50

provides full support for whatever color depth is requested by an application

60

, regardless of whether the requested color depth exceeds the maximum color depth that can be handled by another application

60

or, indeed, the maximum color depth of the display

32

itself.

A. Device Driver Software Architecture—Upper Level

The kernel layer

54

connects to the device driver

50

through an operating system API (O/S API) that provides the operating system kernel

56

and any extensions

58

with entry points into the device driver

50

. Within the device driver

50

, the O/S API is supported primarily by a number of operating system interface modules including a Graphics Display Interface (GDI) module

64

, a Direct Draw (DD) module

66

, any number of other modules

68

, each representing a present or future defined APIs, such as Direct 3D (D3D). Additional API entry points are provided by an operating system (O/S) module

70

, a graphics interface (GRX) module

71

, and a shell module

72

. These modules together present essentially all of the callable entry points that make up the O/S API of the device driver

50

.

The shell module

72

is the initial component of the device driver

50

loaded into the memory

16

as part of the initialization of the operating system kernel

56

during system startup. In a conventional operating system such as Microsoft MS-Windows '95™, the operating system kernel

56

will load the shell module

72

into memory

16

as a consequence of a reference in a standard initialization configuration file or data base, such as the MS-Windows '95 registry services.

An initialization entry point provided by the shell module

72

permits the operating system kernel

56

to initiate the device driver specific initialization of the device driver

50

. As part of this initialization, the shell module

72

determines a Board driver, set of hardware interface modules, and compliment of operating system interface modules that are required to complete the implementation device driver

50

to support the O/S API that will be presented by the device driver

50

to the operating system layer

54

. In a preferred embodiment, these determined additional modules, if not statically linked to the shell module

72

, are dynamically loaded and then logically linked into the device driver

50

.

In order to establish a call interface to the O/S API as needed to obtain support services for initialization of the device driver

50

, at least the operating system module

70

loads as an integral portion or component of the shell module

72

. Preferably, the GRX module

71

is also loaded with the shell module

72

. As a matter of practical convenience, other commonly used and default operating system interface modules may also be statically linked to the operating system module

70

.

Particularly as demonstrated by the GDI

64

, DD

66

, and D3D

68

modules, the device driver

50

of the present invention preferably implements the O/S API of the device driver

50

in segregated units that are specific to particular portions of the operating system kernel

56

and/or operating system extensions

58

. Thus, in the preferred embodiment, the GDI module

64

preferably supports the flat model DIBEngine driver interface predefined by Microsoft for the MS-Windows '95™ product. Similarly, the Direct Draw module

66

supports the hardware independent interface for the standard direct draw API. The D3D module

68

will support the announced Microsoft Direct 3D API for Windows '95™. Documentation for each of these APIs is available as part of the Microsoft Software Development Kit (SDK) and the Microsoft Device Drivers Kit (DDK), available as commercial products of Microsoft, Inc., Redmond, Wash. The dynamic loading capability of the present invention thus allows the comprehensive API support presented by the device driver

50

to be readily tailored and extended through the dynamic loading of additional operating system interface modules.

The shell module

72

, including the O/S and GRX modules

70

,

71

, presents both conventional and proprietary API interface parts to the operating system layer

54

as needed to support both conventional and proprietary support functions through the operation of the device driver

50

. The conventional API part includes an initialization entry point that allows the operating system layer

54

to initiate the initialization of the shell module

72

upon loading into the memory

16

. A generally standard termination call entry point is also provided. This entry point allows the operating system layer

54

to signal the device driver

50

that shutdown of the operating system layer

54

is imminent and that an orderly termination of the device driver is required.

The proprietary API entry points presented by the shell module

72

include entry points providing for the reading and writing of data defining the current desktop presented on the display

32

, the current viewport and certain data defining the operation of the device driver

50

. This latter information may include setting the current physical color depth of the display

32

, the current color and pattern of the display pointer

38

, and a number of largely video hardware specific aspects such as the interlace, video sync type, video fast scroll, and color enable options of the device driver

50

.

Finally, the operating system module

72

provides the device driver support routines that call the operating system layer

54

to obtain basic operating system services. In the preferred embodiment of the present invention, these system services include memory allocation, freeing of previously allocated memory, the loading and unloading of dynamic link libraries, memory management functions such as enabling a memory object to be executable or to lock a memory object in real memory, to disable the executable or lock status of memory objects, to read and write data to defined I/O addresses, and to open, read and close named data files typically as stored by the mass storage peripheral

18

.

B. Device Driver Software Architecture—Lower Level

The shell module

72

also provides for a dynamic configuration of the device driver

50

with respect to the particular instance of the video display controller

19

. While any of a number of functionally similar video display controllers

19

may be utilized in the computer system

10

, the device driver

50

of the present invention provides for the dynamic selection and inclusion of a board driver

74

into the device driver

50

to optimally support the hardware specifics of the particular video display controller

19

. The shell module

72

selects a particular board driver

74

, from among any number of variants, that corresponds to the major aspects of the particular video display controller

19

. In practical terms, the major aspect of a particular video display controller

19

is the specific architecture of the integrated circuit graphics accelerator chip or chip set used in the implementation of the controller

19

. Thus, a single board driver

74

may correspond to a well defined family of specific variants of the display controller

19

. Other board drivers can be constructed to correspond to other families of controllers of different definition.

The board driver

74

provides for an additional layer of dynamic configuration of the device driver

50

by the selective support of a set of hardware interface modules. These hardware interface modules are dynamically loadable as component elements of the device driver

50

and correspond substantially to the individual sub-elements of a particular implementation of the video display controller

19

. In a preferred embodiment of the present invention, the set of hardware interface modules include a Clock Module

76

, DAC Module

78

, CODEC Module

80

, Hardware Cursor Support Module

82

, Video Module

84

, Two Dimensional Graphics Control Module

86

, and Three Dimensional Graphics Control (3D) Module

88

. The particular set of hardware interface modules dynamically loaded in to the device driver

50

is determined by the board driver

74

in correspondence to the specific sub-elements present in the implementation of the video display controller

19

. That is, dependant upon the specific implementation of the Clock sub-element

28

, a particular and corresponding clock module

76

is identified by the board driver

74

and dynamically loaded into the device driver

50

. Consequently, for example, inclusion of a new version of a DAC sub-element

22

into the otherwise generally existing design of the video display controller

19

can be immediately accommodated by a corresponding revision in the functionality of essentially only the DAC module

78

of the device driver

50

. Thus, the partitioning of sub-element specific aspects of the device driver

50

into dynamically loadable modules allows significant revisions in the ultimate configuration performance and operation of the device driver

50

to be made in isolation from the rest of the device driver

50

. Such hardware specific changes are also effectively isolated from the other hardware interface modules and from the higher layers of the device driver

50

. Testing of a device driver

50

configuration for a new version of the display controller

19

can therefore be made with confidence against only the particular new or revised hardware interface module or modules.

As a practical matter, some of the hardware interface modules may be statically linked to the board driver

74

. Where a basic compliment of modules will always or almost always be used with a particular board driver

74

, an optimization is gained by loading the modules together with the board driver

74

. Subsequent use of a statically linked module can also be effectively overridden by providing a dynamically linkable module for supporting the corresponding sub-element. Dynamically loaded modules are preferably used over corresponding statically linked modules.

III. Device Driver Initialization

The process of initializing the device driver

50

of the present invention is generally illustrated in FIG.

3

. This initialization process will be described with regard to the preferred embodiment which operates with the MS-Windows '95™ operating system.

A. Initial Upper Level Initialization

In connection with the conventional execution of the operating system initializations, the shell module

72

is loaded

90

into memory

16

as a consequence of a conventional system driver reference in the registry services database file. Once resident in memory, a call is made to the initialization entry point of the shell module

72

to initiate the device driver dependent initializations. The initialization routine of the shell module

72

provides for the creation

92

of and a shell object

126

(SHELLOBJ) and then an operating system object

128

(OSOBJ) at

93

.

The shell object is used as a top level data structure that logically links together the structure of the device driver

50

. The significant elements of the shell object are identified in Table I.

TABLE I

SHELLOBJ

{

/* global state flags */

InitFlags

ModeSetFlags

/* public data */

ViewportXext

ViewportYext

ViewportLeft

ViewportTop

ViewportRight

ViewportBottom

DesktopXext

DesktopYext

PixelDepth

ColorType

HorzFreq

VertFreq

Interlace

SyncTypes

CursorColor

PanlockOn

FastScrollRate

ColorEnableOn

VideoMemoryOffset

VideoMemoryPool

OffscreenBitmapCache

/* pointers to list of operating system and hardware

interface objects with head and tail pointers to

facilitate pointer list management and pointers

to Board and GRX objects */

FirstObj

BoardObj

GrxApiObj

LastObj

/* storage for the board identifier */

BoardData

/* shell library routine entry points */

ShellModeSet

ShellSetDPMSState

ShellModeDump

ShellGetDesktop

ShellValidateDesktop

ShellGetViewport

ShellValidateViewport

ShellSetViewportPos

ShellStrlen

ShellStrtok

ShellStrncmpi

ShellStrcpy

ShellStrcat

ShellPrintStr

ShellScanStr

ShellDebugOut

ShellStringOrdinal

ShellSkipWhitespace

ShellSkipToAfterNull

ShellSkipToAfterCrLf

ShellReadFileIntoBuffer

ShellGetBufferedSection

ShellReplaceCrLfWithNull

ShellParseSection

ShellLoadObject

ShellUnloadObject

ShellGetModeFileName

ShellRegisterBoardObject

ShellUnregisterBoardObject

ShellOffscreenBitmapInit

ShellOffscreenBitmapRegisterMove

ShellOffscreenBitmapUninit

ShellOffscreenBitmapCreate

ShellOffscreenBitmapDestroy

ShellOffscreenBitmapCache

ShellOffscreenBitmapFlush

ShellOffscreenBitmapFlushAll

ShellOffscreenBitmapCleanBand

ShellOffscreenBitmapCleanAll

ShellMemoryPoolCreate

ShellMemoryPoolDestroy

ShellMemoryPoolSetInform

ShellMemoryPoolAlloc

ShellMemoryPoolAllocMoveable

ShellMemoryPoolAllocFixed

ShellMemoryPoolFree

ShellMemoryPoolCompact

ShellMemoryPoolEnumerate

ShellMemoryPoolGetData

ShellBandListCreate

ShellBandListDestroy

ShellBandListFindByHeight

ShellBandListEnumerate

ShellBandListAlloc

ShellBandListFree

ShellRectPoolCreate

ShellRectPoolDestroy

ShellRectPoolAlloc

ShellRectPoolFree

ShellRectPoolGetData

}

As indicated, the shell object includes some global flag data, API call entry points, pointers to the high-level software objects that represent components of the device driver

50

, and a number of shell library routines or functions used to support the internal operation of the device driver

50

.

The operating system object provides API call access to operating system layer

54

support functions. The elements of the operating system object are identified in Table II.

TABLE II

OSOBJ

{

/* General Purpose Operating system API calls

supported */

OsMemoryAlloc

OsMemoryFree

OsLoadDLL

OsUnIoadDLL

OsGetModuleHandle

OsGetProcAddress

OsGetModuleProcAddress

OsMapPhysicalAddr

OsMakeSelectorUse32

OsCopyAddrMpping

OsMakeExecutable

OsMakeReadWrite

OsMakeSelectorAlias

OsFreeSelectorAlias

OsOutputDebugString

OsUnmapPhysicalAddr

OsGetSystemDesktop

OsGetSystemViewport

OsGetSystemTickCount

OsFileFind

OsFileOpen

OsFileClose

OsFileRead

OsFileWrite

OsFileSeek

/* platform specific utility functions */

OsReadWord

OsWriteWord

OsReadString

OsWriteString

OsReadIOByte

OsReadIOWord

OsReadIODword

OsReadIndexedIOBytes

OsWriteIOByte

OsWriteIOWord

OsWriteIODword

OsWriteIndexedIOBytes

OsWriteFixedIOBytes

OsWriteMemDWord

OsWriteMemDWordVerify

OsWriteMemWord

OsWriteMemWordVerify

OsWriteMemByte

OsWriteMemByteVerify

OsReadMemDWord

OsReadMemWord

OsReadMemByte

OsMemCopy

/* Low level operating system and Bios call

functions */

Os4To3

OsInt10

OsFindPCIId

OsGetPCICfgRegB

OsGetPCICfgRegW

OsGetPCICfgRegDW

OsSetPCICfgRegB

OsSetPCICfgRegW

OsSetPCICfgRegDW

OsGetBoardData

}

As indicated by the supported entry points, the O/S object provides a call interface to the operating system layer

54

, a call interface to low level and bios functions, and a call interface to platform specific functions. This platform specific call interface represents a number of utility or library routines that serve to hide platform portability details. Although not essentially associated with the other functions of the O/S object, these routines are concentrated here to collect all platform specific calls and functions in one module, thereby limiting platform portability changes substantially to this one module. Furthermore, these routines are generally best implemented using assembler coding, as is the rest of the module.

B. Lower Level Initialization

The shell module

72

next initiates the dynamic loading of the remainder of the device driver

50

. In order to identify the correct board driver

74

, the shell module

72

performs an initial assessment

94

of the video display controller

19

to identify a particular board type. A board identifier is preferably read from the controller

19

from a data structure physically resident on the controller

19

and stored in a “BoardData” field of the shell object. In a preferred embodiment, the board identifier is initially stored in a conventional on-board ROM

29

located on the video display controller

19

that is accessible through the register interface

30

. Table III provides the preferred structure of the board identifier data structure.

TABLE IlI

Board_Identifier:

ID

DW

“DM”

Revision

DB

“1”

StructureSize

DB

“16”

BoardFamily

DB

“0”

BoardModel

DB

“0”

ControllerFamily

DB

“0”

Controller

DB

“0”

DacType

DB

“0”

PixelClockType

DB

“0”

MemoryClockType

DB

“0”

MemoryType

DB

“0”

VideoType

DB

“0”

Oem

DB

“0”

BoardDependantInfo

DW

“0”

The “ID” field provides a static data value that confirms the board identifier structure as compliant with the device driver

50

. The “Revision” field is used to define the particular structure of the board identifier structure, should alternate structures be implemented at some future date. The “StructureSize” field defines the size of the structure. The “BoardFamily” field stores a value that can be used to principally identify the board driver

74

that needs to be loaded as part of the device driver

50

required to support this particular instance of the video display controller

19

. The values of the board identifier structure, including at least the “BoardFamily” value, are used as a key to perform a key name look-up in a board.dat file. Preferably, the key is formed as a simple concatenation of the significant board identifier field values. The board.dat file is preferably a flat file correlating keys to corresponding file names of specific instances of board drivers

74

.

Once a particular board driver

74

is identified

94

, the shell module

72

issues a call through the operating system module

70

to load the board driver

74

corresponding to the key value. In response, the operating system layer

54

loads

96

the requested board driver

74

in to the memory

16

and returns a memory pointer to the shell module

72

. The initialization entry point of the board driver

74

is then called.

As part of the initialization of the board driver

74

, a board object

98

is created. While strictly representing neither an operating system or hardware interface module, the board object establishes a basic data structure form that is used for convenience by the objects that represent the operating system or hardware interface modules. The structure of the board object is provided in Table IV.

TABLE IV

BOARDOBJ

{

OBJHDR

/* public data */

ScreenBaseAddress

MmioBaseAdddress

VideoMemorySize

ScreenWidthBytes

BytesPerPxel

/* actual modes.dmm file name */

ModeFileName[128]

/* pointers to a list of the hardware interface objects -

also head and tail pointers to facilitate pointer

list management and to support dynamically

loaded objects*/

FirstObj

MemoryClockObj

PixelClockObj

CursorObj

DacObj

DrawengObj