Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-03-29
2001-06-12
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06247067
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to interfacing between an application program and a device driver in a computing system. More particularly, the invention relates to adapting an application program to communicate, without source code modification, with a device driver in a different operating system environment.
2. Description of Prion Art
Device drivers control devices in a computer operating system. Many contemporary computer architectures utilize levels or rings which are associated with access privileges relative to the operating system of the computer. At the lowest level, device drivers have unique relationships with the operating system in that they can typically have unrestricted access to all devices of the operating system, can freely examine data structures of the operating system, and can access memory locations. Furthermore, device drivers can also trap or intercept software and hardware interrupts which are detected by the operating system. Device drivers are typically maintained separately outside of application software so that the device drivers can be shared by different application programs which need to interface with devices of the operating system.
Application programs are generally one level removed from the device drivers. In order to utilize the function performed by the device driver, the application program typically makes calls to the device driver by passing parameters to and from the device driver through a software interface. In this manner, an application program can be written without the need of repeating the code contained in the device driver.
For example, the architecture employed by Microsoft's Windows
1
utilizes different levels for device drivers and application programs.
FIG. 1
shows levels
20
and
22
, respectively known as Ring
0
and Ring
3
, in a Windows architecture. The virtual device driver
24
, commonly referred to as a V×D, is a driver in the operating system in a Windows environment. Since the V×D communicates with the operating system and associated computer hardware (i.e., a microprocessor capable of 32 bit operations), the V×D is a 32 bit program. Application program
26
, such as a graphical user interface (GUI), exists in Ring
3
of the Windows architecture. Because application program
26
exists at a different level than the device driver
24
, there must be some means for communications between the application program and the device driver so that the application program can utilize the
1
Windows, Windows 3.1, Windows 3.11, Windows 3.X, and Windows 95 are trademarks of Microsoft Corporation. operating system functions performed by the device driver.
As shown in
FIG. 2A
, in Windows 3.1 and 3.11, collectively known as Windows 3.X, application program
28
communicates with the V×D device driver
32
through the interface
30
, provided by software interface INT 2F. Windows 3.X generally supports 16 bit applications through the interface
30
to the V×D. In Windows 95, a new interface between application programs and device drivers has been developed by Microsoft. As shown in
FIG. 2B
, the interface
38
, known as DeviceIOControl(), supports 32 bit application program
36
communicating with the V×D device driver
40
.
As interfaces between application programs and device drivers, INT 2F and DeviceIOControl() operate differently. For instance, INT 2F is a software interrupt which utilizes the AX and BX registers of the operating system. When an application program seeks to communicate with a V×D of Windows 3.X, the application program must manipulate the AX and BX registers appropriately and then generate the software interrupt to pass the values stored in the AX and BX registers to the V×D driver. Inherently, the INT 2F interface requires that the application program utilize assembly language in its calls to the V×D.
In contrast, the DeviceIOControl() interface of Windows 95 is a high level callable function which has a variety of arguments associated with it. Because DeviceIoControl() is a callable function, a Windows 95 application program can communicate with the V×D without having to utilize assembly level software interrupts or manipulate registers of the operating system.
Since application programs are written to interact with the respective interface to the device driver, the interchangeability of these application programs between Windows 3.X and Windows 95 can be problematic. While Windows 95 supports applications written using the INT 2F interface of Windows 3.X, as shown in
FIG. 2B
, there presently is no interface between an application written for Windows 95 using the DeviceIOControl() interface to gracefully operate in a Windows 3.X environment. In other words, Windows 3.X only supports application programs which are written to use the INT 2F interface. An application program written for Windows 95 would not operate under Windows 3.X if the application program made calls to DeviceIOControl(). Hence, software developers writing programs for Windows 95 would have to substantially modify their programs to operate under a Windows 3.X environment. This incompatibility between the interfaces to the V×Ds of Windows 95 and Windows 3.X results in inefficient production of software.
SUMMARY OF THE INVENTION
In accordance with this invention, the above problems have been solved by transparently converting program calls to a first device driver through a first interface in a first operating system, to program calls to a second device driver through a second interface in a second operating system. A conversion interface is maintained in the second operating system having identical calling characteristics, such as the interface name and the calling parameters, as the first interface. The conversion interface is initialized in response to a call from the program operating in the second operating system. A data stream is built based on information contained in the calling parameters, and is transferred through the second interface to the second device driver.
In this manner, a program written with program calls to the first interface in the first operating system can be used in the second operating system.
The above computer implemented steps in another implementation of the invention are provided as an article of manufacture, i.e., a computer storage medium containing a computer program of instructions for performing the above described steps.
In a machine implementation of the invention, an apparatus for transparently converting program calls to a first device driver through a first interface in a first operating system, to program calls to a second device driver through a second interface in a second operating system, has a conversion interface in the second operating system having identical calling characteristics as the first interface, including the identical interface name and calling parameters. An initializing module initializes the conversion interface responsive to a call from the program operating in the second operating system. A build/send module builds a data stream based on information contained in the calling parameters and transfers the data stream through the second interface to the second device driver.
In particular, the conversion interface, which is designed to look like the device driving interface of Windows 95, is created to operate in a Windows 3.X operating system. The conversion interface is capable of supporting calls from the application program to DeviceIOControl() by translating these calls into a format compatible with the INT 2F device driver interface of Windows 3.X.
All application programs can therefore be written utilizing high level calls to DeviceIOControl() irrespective of whether these application programs will be operating in a Windows 95 or Windows 3.X environment. The same source code can be compiled into either 32 bit format for use in Windows 95, or into 16 bit format for use in Windows 3.X.
Still another utility of the present invention is
Berliner Brian
Kayes Kevin W.
Courtenay III St. John
Hogan & Hartson LLP
Sun Microsystems Inc.
LandOfFree
Transparently converting program calls between interfaces does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transparently converting program calls between interfaces, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transparently converting program calls between interfaces will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2506169