Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-01-20
2003-11-04
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C717S100000, C717S120000, C709S241000, C707S793000
Reexamination Certificate
active
06643712
ABSTRACT:
BACKGROUND OF THE INVENTION
1. The Field of the Invention
The field of the present invention is computer software driver development. The present invention relates to tools, software frameworks, conventions, etc. to simplify code generation of drivers and provide standardized access points. More specifically, the present invention relates to standardized methods, computer program products, and data structures to create hierarchal relationships between file objects.
2. Present State of the Art
A given software driver executable code implementation may have multiple entry points to different portions of functionality. Once loaded and controlled by an operating system such as Microsoft® Windows NT™, specific system objects are created representing the driver (driver objects), the “devices” or specific functional definitions accessible by other components supported by the driver (device objects), and instances of the driver functionality actually used by a component (typically in the form of file objects).
Most operating systems, including Windows NT, implicitly assume that a driver performs a single type of function and that all device objects created in connection with the driver will perform the function in the same manner. Furthermore, created file objects, whether created under the device objects or under other file objects, are assumed to be serviced in the same way. Because of the above mentioned assumptions, the Windows NT operating system and other like operating systems use a single driver object to share all entry points with all sibling device objects created using the same driver object.
As a result of such assumptions, each driver developer must write specific code to validate initial file object requests in systems where hierarchically related file objects may be created according to a specific set of rules. One example of a such a file object hierarchy is the driver connection system described in detail hereafter. This driver connection system is shown by way of example and not by limitation and any other system that makes use of the present invention as hereafter explained will be considered within the scope of the present invention as claimed.
This problem is exacerbated when a standardized system of writing device drivers is used as is found in the driver connection system. Since all driver developers are writing to the same set of rules, not only is specific code required to handle the file object creation but it is developed many times over by each developer writing drivers according to the standardized convention.
Another problem resulting from the basic assumption that all file objects are serviced in the same manner is ensuring that a processing request is routed to the correct handler for a particular file object. Since different functionality can be imparted to a driver, and such functionality is accessed by opening a “file” on the particular device that creates an underlying file object in the system for managing the state of that file and provides a file handle as an access mechanism for directing I/O requests, different processing request handlers are used depending on the file (and file object) designated to receive the request. Special code must normally be written to perform such routing to overcome the assumption of homogenous operation. Again, in a standardized system where multiple different manufacturers may be writing drivers with hierarchically related functionality, the impact is magnified since the special code must be written from scratch multiple times.
What is needed is a standardized mechanism for validating creation requests of file objects in a hierarchically related system of file objects and a way to route processing requests to the correct handler for a given file object.
SUMMARY AND OBJECTS OF THE INVENTION
It is an object of the present invention to provide a standardized mechanism for validating file object create requests based on context information accessible by reference in system device objects and file objects that can be used by multiple third party software driver developers.
It is another object of the present invention to route processing requests to the appropriate handler for a given file object in a standardized fashion to facilitate interoperating device driver development by multiple third party developers.
It is yet another object of the present invention to provide a framework for third party driver developers that reduces the amount of coding effort to develop software drivers and assist in developing drivers that may handle processing requests in a standardized fashion.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein a method, computer program product, and data structure for validating creation of and routing messages to file objects are provided. There is established a system level convention that all third party software driver developers follow, along with standardized data structures and code that allow easy development of software drivers. These aspects of the invention efficiently provide different types of functionality within the same driver, hierarchically related functionality through validated file object creation, and correct routing of processing messages to the correct handler routines.
The invention extends to a plurality of request handling multiplexing functions, each referenced from the driver object depending on the type of message received (create, I/O control, close, etc.). These multiplexing functions are not developed by the third party developers but rather are provided as part of the system by the system developer or some other entity. The driver developers reap benefits from the standard multiplexing functions by writing software drivers that conform to the established convention and utilize predefined data structures.
According to the present invention, a private storage area in the device objects and the file objects is used to reference predefined data structures that are written by the third party driver developer. The driver developer creates and “fills” the data structures, including writing the specific message handlers that are needed for a particular file object type and message type, without writing any of the code to validate the file object creation or route incoming messages to the correct message handler function. The validation and routing functionality are found in the multiplexing dispatch functions already provided.
For example, a device object private data area references, through a pointer or other means, a validation table data structure containing a table of valid file object types and pointers to appropriate create handlers for creating file objects of the corresponding type. When a create message is received by the create multiplexing dispatch function, the validation table data structure is accessed to determine the validity of the request and, if valid, access the correct create handler.
Should the message indicate that a “parent” file object exists, the create multiplexing dispatch function accesses the parent file object's private data area for a reference to another data structure. The file object data structure contains pointers to all the appropriate message handlers for that particular file object.
With respect to the create message handler, reference is made through a pointer or other means to a validation table data structure containing valid file object types and pointers to appropriate create handlers for creating file objects of the corresponding type. When a create message is received by the create multiplexing dispatch function, the validation table data structure is accessed from the file object data structure to
Shaw George H. J.
Woodruff Bryan A.
Courtenay III St. John
Microsoft Corporation
Workman Nydegger
LandOfFree
Validating the creation of and routing of messages to file... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Validating the creation of and routing of messages to file..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Validating the creation of and routing of messages to file... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3123403