Electrical computers and digital processing systems: interprogra – Application program interface
Reexamination Certificate
1999-06-16
2004-11-30
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Application program interface
C718S104000
Reexamination Certificate
active
06826760
ABSTRACT:
TECHNICAL FIELD
This invention relates to methods of factoring operating system functions, to methods of converting operating systems from non-object-oriented formats into object-oriented formats, and to related apparatus.
BACKGROUND OF THE INVENTION
Operating systems typically include large numbers of callable functions that are structured to support operation on a single host machine. When an application executes on the single host machine, it interacts with the operating system by making one or more calls to the operating system's functions.
Although this method of communicating with an operating system has been adequate, it has certain shortcomings. One such shortcoming relates to the increasing use of distributed computing, in which different computers are programmed to work in concert on a particular task. Specifically, operating system function libraries can severely limit the ability to perform distributed computing.
FIG. 1
illustrates the use of functions in prior art operating systems.
FIG. 1
a shows a system
20
that includes an operating system
22
and an application
24
executing in conjunction with the operating system
22
. In operation, the application
24
makes calls directly into the operating system when, for example, it wants to create or use an operating system resource. As an example, if an application wants to create a file, it might call a “CreateFile” function at
26
to create the file. Responsive to this call, the operating system returns a “handle”
28
. A “handle” is an arbitrary identifier, coined by the operating system to identify a resource that is controlled by the operating system. In this example, the application uses handle
28
to identify the newly created file resource any time it makes subsequent calls to the operating system to manipulate the file resource. For example, if the application wants to read the file associated with handle
28
, it uses the handle when it makes a “ReadFile” call, e.g. “ReadFile (handle)”. Similarly, if the application wants to write to the file resource it uses handle
28
when it makes a “WriteFile” call, e.g. “WriteFile (handle)”.
One problem associated with using a handle as specified above is that the particular handle that is returned to an application by the operating system is only valid for the process in which it is being used. That is, without special processing the handle has no meaning outside of its current process, e.g. in another process on a common or different machine. Hence, the handle cannot be used across process or machine boundaries. This makes computing in a distributed computing system impossible because, by definition, distributed computing takes place across process and machine boundaries. Thus, current operating systems lack the ability to name and manipulate operating system resources on remote machines.
Another problem with traditional operating system function libraries is that individual functions cannot generally be modified without jeopardizing the operation of older versions of applications that might depend on the particular characteristics of the individual functions. Thus, when an operating system is upgraded it typically maintains all of the older functions so that older applications can still use the operating system.
In prior art operating systems, a function library essentially defines a protocol for communicating with an operating system. When operating systems are upgraded, the list of functions that it provides typically changes. Specifically, functions can be added, removed, or changed. This changes the protocol that is used between an application and an operating system. As soon as the protocol is changed, the chances that an application will attempt to use a protocol that is not understood by the operating system, and vice versa increase.
Prior art operating systems attempt to deal with new versions of operating systems by using so-called version numbers. Version numbers are assigned to each operating system. Applications can make specific calls to the operating system to ascertain the version number of the operating system that is presently in use. For example, when queried by an application, Windows NT 4 returns a “4” and Windows NT 5 returns a “5”. The application must then know what specific protocol to use when communicating with the operating system. In addition, in order for an operating system to know what operating system version the application was designed for, a value is included in the application's binary. The operating system can then attempt to accommodate the application's protocol.
The version number system has a couple of problems that can adversely affect functionality. Specifically, a typical operating system may have thousands of functions that can be called by an application. For example, Win32, a Microsoft operating system application programming interface, has some 8000 functions. The version number that is assigned to an operating system then, by definition, represents all of the possibly thousands of functions that an operating system supports. This level of description is undesirable because it does not provide an adequate degree of resolution. Additionally, some operating systems can return the same version number. Thus, if the operating systems are different (which they usually are), then returning the same version number can lead to operating errors. What is needed is the ability to identify different versions of operating systems at a level that is lower than the operating system level itself. Ideally, this level should be at or near the function level so that a change in just one or a few functions does not trigger a new version number for the entire operating system.
The present invention arose out of concerns associated with providing improved flexibility to operating systems. Specifically, the invention arose out of concerns associated with providing operating systems that are configured for use in distributed computing environments, and that can easily support legacy applications and versioning.
SUMMARY OF THE INVENTION
Operating system functions are defined as objects that are collections of data and methods. The objects represent operating system resources. The resource objects can be instantiated and used across process and machine boundaries. Each object has an associated handle that is stored in its private state. When an application requests a resource, it is given a second handle or pseudo handle that corresponds with the handle in the object's private state. The second handle is valid across process and machine boundaries and all access to the object takes place through the second handle. This greatly facilitates remote computing. In preferred embodiments, the objects are COM objects and remote computing is facilitated through the use of Distributed COM (DCOM) techniques.
Other embodiments of the invention provide legacy and versioning support by identifying each resource, rather than the overall operating system, with a unique identifier that can specified by an application. Different versions of the same resource have different identifiers. This ensures that applications that need a specific version of a resource can receive that version. This also ensures that an application can specifically request a particular version of a resource by using its unique identifier, and be assured of receiving that resource.
Other embodiments of the invention provide legacy support by intercepting calls for operating system functions and transforming those calls into object calls that can be understood by the resource objects. This is accomplished in preferred embodiments by injecting a level of indirection between an unmodified application and an operating system.
REFERENCES:
patent: 4768150 (1988-08-01), Chang et al.
patent: 5097533 (1992-03-01), Burger et al.
patent: 5379432 (1995-01-01), Orton et al.
patent: 5752027 (1998-05-01), Familiar
patent: 6081807 (2000-06-01), Story et al.
patent: 6144377 (2000-11-01), Oppermann et al.
patent: 6317773 (2001-11-01), Cobb et al.
patent: 6334157 (2001-12-01), O
Cermak Gerald
Hunt Galen C.
Stets, Jr. Robert J.
An Meng-Al T.
Anya Charles
Lee & Hayes PLLC
Microsoft Corporation
LandOfFree
Methods of factoring operating system functions, methods of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods of factoring operating system functions, methods of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods of factoring operating system functions, methods of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3334189