Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1995-04-24
2002-03-26
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
06363409
ABSTRACT:
FIELD OF INVENTION
The present invention relates to computer operating systems, and more specifically relates to a method and apparatus for client/server translation and execution of non-native applications.
BACKGROUND AND SUMMARY OF THE INVENTION
It is important, given the investment most users have in their applications software, that an application be usable with several different operating systems. However, this is difficult to achieve in practice due to the myriad of differences between the different operating systems (e.g. different internal design architectures, different process structures, different memory management, different exception and error handling, different resource protection mechanisms, etc.).
To help address this problem, operating system vendors provide support in a number of ways for different operating system environments. For example, IBM OS/2 version 2.0 (hereinafter simply “OS/2”) runs applications written for Windows 3.1 (a “non-native application”) by providing an environment for the application that mimics the Windows 3.1 environment.
In more detail, when OS/2 receives a request to run a Windows 3.1 application, it creates a process called a virtual machine (VM). The VM contains the Windows 3.1 application program and all the Windows 3.1 operating system components needed to support execution of Windows 3.1 applications. This process is repeated for each non-native application run under OS/2 (i.e. a separate VM containing a complete copy of all the operating system components needed to support the non-native application is spawned for each).
There are several problems associated with this replicate-a-non-native-OS-in-a-VM approach. One is its ineffective and wasteful use of resources. Windows 3.1 is a relatively old (in computer terms) 16-bit operating system. OS/2 is a newer 32-bit operating system that includes all of the functionality of older 16-bit operating systems, and provides additional capabilities as well. The provision of components from the older
16
bit Windows 3.1 operating system inside each VM spawned by the more modern 32-bit OS/2 operating system for a Windows 3.1 application is an unartful way to provide compatibility; the resources of the 32-bit operating system are essentially wasted.
A further drawback of this approach is that non-native applications running in separate VMs can't readily “see” each other (e.g. communicate or exchange data). For example, dynamic data exchange (DDE) and object linking and embedding (OLE) between applications executing in separate VMs is difficult, if possible at all. (Such data exchange between applications is important in order to achieve seamless integration between applications. An illustrative case is a user who wants to link a chart from a spreadsheet program into a word processing document, where each time the chart is updated in the spreadsheet program, the chart in the word processing document is likewise updated.) Under OS/2, such seamless integration cannot be achieved.
Yet another problem is that, when a non-native application executes, the non-native video driver in its VM takes control of the computer's video display hardware (and sometimes other hardware) from the OS/2 operating system. This results in “blacking out” of the existing OS/2 native user interface, and, a moment later, the presentation of a different user interface associated with the non-native application. Some users find the total loss of the familiar OS/2 interface to be a considerable inconvenience.
Alternatively, the OS/2 video device driver can be modified to present the OS/2 user interface over most of the screen, but surrender control of a rectangular window (a “black hole”) to a non-native video device driver associated with a VM. These two concurrently executing video device drivers must cooperate so that neither interferes with regions of the display allocated to the other driver. This cooperation between 16-bit and 32-bit video device drivers is difficult at best, and becomes extremely complicated when several VMs are overlapped on the display screen. The modifications to the OS/2 device drivers sometimes lead to unexpected behavior since they interfere with the device driver's original design.
In accordance with a preferred embodiment of the present invention, problems associated with this replicate-a-non-native-OS-in-a-VM approach are overcome. An operating system with a client/server architecture including a set of specially modified server processes called modified virtual machines (MVMs) is provided. In client/server operating systems, such as Windows-NT by Microsoft, “clients” are processes that request services, e.g. file service, memory management, etc. (Clients are often, but are not necessarily, applications programs.) “Servers” are processes that provide services. Communications between client and server processes are handled by an operating system “kernel.”
When an individual server process MVM is created, only the essential “kernel” components of the non-native operating system are copied into the MVM (i.e. essential, non-replaceable device drivers, interrupts, etc.). Other operating system support required by the non-native (16-bit) application is provided from the native (32-bit) operating system through a translation procedure (“thunking”). For example, if the non-native (16-bit) application requests services such as user interface (UI), graphics device interface (GDI), DDE, OLE, etc., the service request is automatically thunked into the corresponding native (32-bit) service request and passed to the native (32-bit Windows-NT) operating system. The native operating system services the request and passes any return data through the thunking process and back to the originating non-native application. By this arrangement, all MVMs make shared use of a common set of native operating system functions, gaining the enhanced functionality of the native (32-bit) services, and facilitating communication and data sharing between applications.
This arrangement also allows the native operating system to maintain exclusive control over the video display and other hardware. The prior art “blacking out” and “black hole” phenomena are eliminated.
The foregoing and other features and advantages of the preferred embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
REFERENCES:
patent: 5305461 (1994-04-01), Feigenbaum et al.
patent: 5487158 (1996-01-01), Amelina
patent: 5490256 (1996-02-01), Mooney et al.
patent: 5517193 (1996-05-01), Allison et al.
patent: 5734904 (1998-03-01), Kanamori et al.
Randall Kennedy, “Make Windows say WOW”, Window Sources v2, n2, p305(2) 2/94.*
Adrian King, “Windows, the next generation: an advance look at the architecture of Chicago”, Microsoft System Journal v9,n1, p15(8), 1/94.*
Andrew Schulman, “At last—write bona fide 32 bit programs that run on Windows 3.1 using Win32s”, Miscrosoft Systems, Journal, v8,n4, p15(16), 4/93.*
Matt Pietrek, “Stepping up to 32 bits; Chicago's process, thread, and memory management”, Microsoft Systems Journal, v9, n8, p27(13), 8/94.*
Vendito et al, “A step ahead of the next generation”, windows Sources, v2,n6,p110(13), 6/94.*
Pietrek, Matt,; “intercepting API functions in Win32”, PC Magazine, v13, #19, p307(6), Nov. 8, 1994.*
Richter, Jeffrey; “Load your 32-bit DLL into another process space using INJLIB”, Microsoft Systems Journal, v9, #5, p13(22), May 1994.*
Peitrek, Matt, “Intercepting API Functions in Win32”,PC Magazine,Nov. 8, 1994, v 13, #19, p. 307 (6).*
Richter, Jeffrey, Load Your 32-bit DLL into another Process Space Using INJLIB, Microsoft Systems Journal, May 94 v9, #5, p. 13 (22).*
Kennedy, “Make Windows Say WOW,”Windows Sources,Feb. 1994, pp. 305-306.
Oney, “Mix 16-bit and 32-bit Code in Your Applications with the Win32s™ Universal Thunk,”Microsoft Systems Journal,Nov. 1993, pp. 39-45, 48, 50, 52, 54-59 (advertising pages omitted).
Penrod, “How Today's Apps Will Run Tomorrow 16 In
Hart David L.
Ramakrishna Nanduri R. V.
Courtenay III St. John
Klarquist & Sparkman, LLP
Microsoft Corporation
LandOfFree
Automatic client/server translation and execution 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 Automatic client/server translation and execution of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automatic client/server translation and execution of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2835887