Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-05-04
2004-01-27
Follansbee, John A. (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C345S215000
Reexamination Certificate
active
06684260
ABSTRACT:
FIELD OF THE INVENTION
Embodiments of the present invention relate to a user interface provided by a device driver and to data structures and methods of maintaining consistency of settings accessible via such a user interface.
BACKGROUND OF THE INVENTION
Computer systems output data to a variety of output devices, such as, printers, plotters, and video displays. These systems also accept input data from a variety of input devices, such as, scanners, network devices, and speech recognition interfaces. Each device typically has a manufacturer-defined device-specific protocol for communicating with the device. A computer system, under the control of an operating system, uses the protocol to communicate with each device. An operating system must, therefore, be programmed to cooperate with the protocol of each device to which it is connected. It would be impractical for an operating system developer to provide an interface to every available peripheral device. Moreover, frequent revisions to an operating system to permit it to cooperate with new peripheral devices may add unnecessary cost to the provision and support of an operating system on multiple computers. To overcome these difficulties, operating systems interface with peripheral devices indirectly through device drivers. The operating system developer defines a device driver interface between the operating system and the device driver. Each manufacturer of a device then provides a device driver, which implements the device driver interface and further, implements the protocol for communicating with the peripheral device. The operating system or application program loads the device driver and invokes the functions of the device driver interface to communicate with the device.
An operating system also provides support for application programs. To this end, the operating system developer defines an application program interface over which an application program may communicate to obtain the services of peripheral devices. Such an application program interface is commonly called a Graphics Device Interface (GDI) and is typically part of the operating system. The GDI effects the output of data by invoking functions implemented by the device driver in accordance with the device driver interface. The GDI and device drivers insulate the application program from the different characteristics of peripheral devices. The GDI provides a variety of functions for accessing devices in a device-independent manner. An example of a GDI is described in Programming Windows 3.1 by Charles Petzold, published by Microsoft Press, incorporated herein by reference. The GDI also specifies behavior of each function that a device driver must implement. For example, one GDI for a printer specifies six categories of functions implemented by a device driver: (1) initialization, (2) information, (3) output, (4) attribute, (5) mode, and (6) escape as described in Table 1.
TABLE 1
Function
Description
(1) Initialization
Control
Performs device-dependent operations such as
starting an output job, aborting an output job, and
processing a new band of bitmap data;
Disable
Deallocates memory used by the device drivers data
structures and unloads the device driver from
memory;
Enable
Allocates and initializes memory for a data structure
containing device dependent and device state
information;
WEP
Signals the device driver that the operating system is
shutting down;
(2) Information
ColorInfo
Translates physical colors to logical colors and vice
versa;
EnumDFonts
Enumerates the fonts available on the device;
EnumObj
Enumerates the pens and brushes that are available
on the device;
DevGetCharWidth
Returns width values for characters in a specified
printer font;
(3) Output
DevBitBlt
Sets pixels on the output device;
DevExtTextOut
Renders text on the output device;
Output
Renders s shape on the output device;
Pixel
Sets a single pixel on the output device;
ScanLR
Sets pixels in a single row of the output device;
StretchBlt
Renders scaled bitmaps on the output device;
(4) Attributes
RealizeObject
Converts a logical pen, brush, font, etc. data
structure to a physical pen, brush, font, etc. data
structure;
(5) Modes
DeviceMode
Displays a dialog box that allows a user to select
device options, such as, paper size, paper orientation
and output quality;
(6) Escape
QueryEscSupport
Specifies whether the output device supports a
specified escape sequence;
SetAbortDoc
Invokes the abort procedure of any application
program;
StartDoc
Signals the beginning of an output job;
NextBand
Outputs a band of bitmap data;
EndDoc
Signals the end of an output job;
AbortDoc
Signals the abnormal termination of an output job;
As an example of the operation of the GDI described above, an application program outputs data to a particular device by first requesting the GDI to create a device context. The device context identifies the particular peripheral device and contains the current state of the peripheral device. For example, the device context may contain the current font and brush information. The GDI provides the application program with a handle to the created device context. The application program passes the handle to the device context whenever the application program outputs data to the particular device. The GDI functions use the passed handle to access the device context.
Each of the functions provided by a device driver may be uniquely programmed by the manufacturer of the peripheral device. This approach leads to several areas of difficulty which add to the cost of providing peripheral devices for mass marketing distribution. For example, when a manufacturer provides several lines of peripheral devices, it is desirable to provide device drivers implemented from reusable software components. In this approach, each new peripheral can be supported with a device driver having consistent behaviors shared with device drivers built for prior peripheral device products. In addition, it is desirable to design device drivers that are portable (i.e., common code reused for different operating systems), flexible (i.e., new features may be added with minimal redevelopment and testing), and consistent (i.e., the structural organization of the device driver software is similar among device drivers for different products and/or different product lines).
A device driver may provide a user interface for permitting the user of an application program to modify selected attributes of the device context. The operating system cooperates with the device driver to provide the user interface. In a conventional user interface, dialog boxes are shown on the screen with controls that respond to user input for the specification of new values for attributes. Because the dialog box provides the user with the flexibility of modifying attributes in an ad hoc manner, conventional device drivers assure that user input will not result in an inconsistent group of attributes.
An attribute is referred to herein as a device setting. A plurality of attributes may be collectively referred to as a device setting or as a plurality of device settings. Therefore, a device setting may include one or more attributes. Each attribute may be referred to as a parameter. Each attribute has an identity and one or more values.
Typically, consistency checks are made prior to modifying the value of a device setting. That portion of the device driver program responsible for accepting a modified device setting for one of the controls of the dialog necessarily is programmed with knowledge of the behavior of one or more other controls. This interaction between controls complicates software development of the device driver user interface. Further, by accounting for consistency checking in the programming of each control, the resulting device driver user interface is less amenable to reuse for the development of future device drivers. Development of device drivers using this approach, therefore, cannot obtain the desirable features discussed above.
In view of the problems described above and related problems that consequently become apparent in
Daly John P.
Fordemwalt Jim F.
Foster Ward S.
Griebe Nicola R.
Bullock, Jr. Lewis A.
Follansbee John A.
Hewlett--Packard Development Company, L.P.
LandOfFree
Maintaining consistency of device driver settings does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Maintaining consistency of device driver settings, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Maintaining consistency of device driver settings will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3205794