CA2152007A1 - Method and system for dynamic translation between different graphical user interface systems - Google Patents
Method and system for dynamic translation between different graphical user interface systemsInfo
- Publication number
- CA2152007A1 CA2152007A1 CA002152007A CA2152007A CA2152007A1 CA 2152007 A1 CA2152007 A1 CA 2152007A1 CA 002152007 A CA002152007 A CA 002152007A CA 2152007 A CA2152007 A CA 2152007A CA 2152007 A1 CA2152007 A1 CA 2152007A1
- Authority
- CA
- Canada
- Prior art keywords
- operating system
- application program
- windows
- user interface
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
- G06F3/1454—Digital output to display device ; Cooperation and interconnection of the display device with other functional units involving copying of the display data of a local workstation or window to a remote workstation or window so that an actual copy of the data is displayed simultaneously on two or more displays, e.g. teledisplay
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
- G06F9/452—Remote windowing, e.g. X-Window System, desktop virtualisation
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2360/00—Aspects of the architecture of display systems
- G09G2360/04—Display device controller operating with a plurality of display units
Abstract
The present invention is directed towards a translation software that provides remote access to an application program that is executing on a host machine in its native operating system environment. The translation software monitors messages that are relayed from the application program to an application interface that is provided via the native operating system. Upon recognizing a message that affects a graphical user interface of the native operating system, the translation software converts the message into a protocol that is recognized by a remote graphical user interface. By monitoring and converting messages in this fashion, the translation software allows the application program to be displayed remotely.
Description
~- 21~20~7 .
I~escription A METHOD AND SYSTEM FOR DYNAMIC TRANSLATION BETWEEN
DIFFERENT GRAPHICAL USER INTERFACE SYSTEMS
Cross Reference to Related Apl~lication This application is a continuation-in-part of U.S. Applic~tion Serial No. 08/261,492 filed on June 17, 1994, now abandoned.
10 Technical Field The present invention relates to execution-time translation between dif~erent graphical user interface systems and in particular, includes a method and system that allows applications written for local-display systems to utilize the remote display capabilities of a different graphical user interface system.
Background of the Invention Currently, there are approximately 50 million computer users that utilize a graphical user interface known as "WINDOWS" by "MICROSOFT"
Corporation. Currently, "MICROSOFT's WINDOWS/NT" is rapidly emerging 20 as a preferred operating system. Consequently, a large number of application programs are written to be compatible with "WINDOWS/NT."
"WINDOWS/NT" provides a single graphical user interface in whicll all these application programs must adhere to. However, a client/server window system known as "X," initially developed at the Massacllusetts's Institute of Technology, 25 provides a protocol (X-Protocol) that allows application programs to be displayed remotely on one or more graphical user interfaces (e.g., Motif, Open-Look). Unfortunately, the application programs that are developed for the "WINDOWS/NT" operating system are not compatible with the X-Protocol.
Consequently, users of the X-ClientlServer window system do not have 30 conveniel1t access to these application programs. This is unforhlnate because many of the application programs developed for the "WINDOWS/NT" operating ~system are superior, in terms of cost and features, to those than developed for tlle X-Client/Server window system.
35 Summary of the Invention The present invention is directecl towards translation soflware that provides remote access to an application program. More specil;cally, the 21S20~7 -translation software provides remote access to an application program that is executing on a host machine in its native operating system environment. The translation software monitors messages that are relayed from the application program to an application interface that is provided via the native operating 5 system. Upon recogni7in~ a message that affects a graphical user interface of the native operating system, the translation software converts the message into a protocol that is recognized by a remote graphical user interface. The translation software also monitors and converts commands at the driver level. By monitoring and converting messages in this fashion, the translation software 10 allows the application program to be displayed remotely.
Brief Description of the Drawings Figure 1 illustrates a preferred embodiment of the present invention.
Figure 2 compares system design structures for a client/server window system and an operating system.
Figure 3 is a flow diagram of the processing steps of the preferred embodiment of the present invention.
Figure 4 illustrates a flow diagram of the processing steps of an 20 application program (prior art).
Figure 5 illustrates a flow diagram of the processing steps for the interaction between the application program and a native operating system (priorart).
Figure 6 illustrates a flow diagram of the processing steps for an 25 example according to a preferred embodiment of the present invention.
Detailed Description of tlle Tnvention The present invention is directed towards a translation software that allows an application program written for a particular graphical user 30 interface system (GUI) to be displayed on another graphical user interface system at execution time. The GUI upon which the application program is displayed is referred to as the target GUI. If the target GUI is capable of remote display over a network, the translation software allows the application program to be displayed and interacted with remotely while it executes within its native35 (non-remote) GUI.
In its preferred embodiment, the present invention provides for translation from Windows and "WINDOWSINT" to the X-Window System and -thus allows for the remote display of applications developed for "MICROSOFT
WINDOWS" and "WINDOWS/NT" on X-Terminals and X-Servers. More specifically, the preferred embodiment allows each such application to appear asa fully compatible X-Client program to remote X-Servers. The term "X-Client"
5 refers to an application program that utilizes the previously described X-Protocol. The term "X-Terminal" refers to any display component (e.g, stand-alone terminal or workstation) that is a display component of an X-Client/Serverwindowing system. The term "X-Server" refers to the software that controls the display hardware (e.g, a video display, a keyboard, or mouse) and is responsible10 for conducting the drawing and rendering of the video display. An attractive feature of an X-Client program is that it may be displayed and/or interacted with (e.g, via mouse, keyboard, etc.) on any X-Terminal provided there is a suitable communications link (typically, but not restricted to, the TCP/IP protocol described below) connecting the machine the X-Client is running on and the X-15 Terminal.
In the X-Client/Server window system an X-Client communicates with the underlying hardware (e.g, display, mouse, keyboard, etc.) via the X-Server. A separate X-Client, known as a window manager, coordinates with the X-Server to manage the display. More specifically, the window manager 20 keeps track of the state of all X-Windows. The term "X-Window" refers to any portion of an X-Terminal's display that contains its own data (e.g., a document or a message). A primary advantage of the X-Client/Server window system is that it does not constrain an X-Client to the use of any particular window manager.
Instead, a user may select the window manager that the user believes offers the 25 most attractive look and feel.
Figure 1 illustrates a preferred embodiment of the present invention. A host computer 110 executes application programs such as "MICROSOFT EXCEI," 120 and "WORD FOR WINDOWS" 130 under the "WINDOWS/NT" operating system 140. The "WINDOWS/NT" operating 30 system, as well as the application programs 120, 130, are contained within a main memory of the host computer. More specifically, a central processing unit contained within the host computer 110 e~ecutes the instructions of both the "WINDOWS/NT" operating system 140 and the application programs 120, 130.
The "WINDOWS/NT" operating system provides an application program 35 interface (API) that allows these application programs 120, 130 to communicate with the operating system 140. Additionally, the "WINDOWS/NT" operating system also provides a standard graphical user interface (GUI) that defines the 2,~
-look and feel for all applications running under "WINDOWS/NT." This standard graphical user interface is designed to receive commands from the application program. In brief, the application programs 120, 130 utilize the application interface to request the operating system to conduct a variety of 5 tasks. For example, representative tasks include the opening and closing of files, as well as making various adjustments to the graphical user interface. However, the "WINDOWS/NT" operating system does not provide for remote interaction with applications. In its preferred embodiment, the present invention overcomes this limitation of "WINDOWS/NT" by allowing application programs 120, 130 10 to be executed on the host computer while being displayed remotely on an X-Terminal 150. In this manner, the present invention allows users of the X-Client/Server window system to gain access to applications developed for the "WINDOWS/NT" operating system. Moreover, as the preferred embodiment of the present invention allows the application programs 120, 130 to be executed in15 their native operating system environments (e.g, the "WINDOWS/NT"
operating system 140), the present invention provides such access in a highly efficient manner.
As illustrated, the host computer 110 is connected to the X-Terminals 150 via a network connection such as the TCP/IP protocol used on the 20 Ethernet. In brief, this protocol consists of a series of layers. More specifically, the five lower-most layers in ascending order are; the wire, the Ethernet, the Internet protocol (IP layer), the transport control protocol (TCP layer) and the X-Protocol. This network connection is conceptually illustrated by reference 160.
As described above, the X-Client/Server window system utili7es 25 two components: an X-Server 170 and a window manager 180. The window manager 180 manages X-Windows by keeping track of how many X-Windows are currently displayed, where the X-Windows are currently displayed, etc. As the present invention converts the "WINDOWS/NT" application to a fully compatible X-Client, a user may select a particular window manager 180 (e.g., 30 Motif, Open-Look, Tom's Window Manager) for use with the present invention.
In brief, the window manager 180 receives commands that relate to the display -of the X-Terminals 150. As the window manager 180 may be contained within the X-Terminal itself or on the network, the window manager may receive commands over the network connection 160 or directly from the X-35 Terminals 150.
Figure 2 compares system design structures for a client/serverwindow system and an operating system. More specifically, Figure 2 compares 2~52007 -s the system design structure of the X-ClientlServer windowing system and the "WINDOWS/NT" operating system. A knowledge of these structures is helpful when discussing the processing steps described in Figures 3-6.
In "WINDOWS/NT" programs (e.g, application programs) are S provided with a standard interface to the hardware 205 (e.g, display, keyboard, mouse, etc.) via device drivers 210. The various components 215 of the "WINDOWS/NT" operating system are layered above the device driver. One such component is Graphics Device Interface 220 (GDI). The GDI allows applications programs to describe graphical information without reference to the 10 underlying hardware. The Application Program Interface 225 (API) exists above the "WINDOWS/NT" components layer. The API contains the notion of windows, icons, cursors, and other resources. "WINDOWS/NT" is an event driven, message based system. Various programs communicate with each other and with "WINDOWS/NT" by passing messages via the API. In regards to 15 graphically displayed information, the API utilizes high-level constructs such as windows or icons. In contrast, the video device driver utilizes lower-level representations of graphical data (e.g, bitmap data). One of the purposes of the video device driver is to relay this bitmap data to the display device. For example, when the user moves or resizes a window, a large number of BitBlts 20 (block transfers of bitmap data) are executed by the display driver.
The X-Server-Client windowing system is structured somewhat similarly to the "WrNDOWS/NT" operating system. An X-Server 230 provides a standard interface to the underlying hardware 235. A library, Xlib 240, provides a (lower level) programmers' interface for X. When the X-Client is run 25 locally, the X-Client issues commands from the Xlib library 240 to access the local haldw~e 235 through the X-Server 230. Similarly, when the X-Client is run remotely, the X-Client issues commands from the Xlib library 240 to access the remote hardware. In this case, network packets which represent elements of the X-Protocol are sent to the X-Server 230 that serves the remote hardware 235.
30 Like "WINDOWS/NT," X is an event driven system and an X-Client may request the X-Server 230 to send it X-Events of interest (such as the mouse entering or leaving a window, the user clicking in a window, etc.). As mentioned above, a special X-Client program, the window manager 245, allows the user to manage displayed windows, define menus, etc. Above the relatively low-level 35 Xlib interface, a X-Toolkits 250 provides a higher level programmers interface.
There are many such toolkits which are available commercially (e.g, the "XT,"
"ANDREW," and "MOTIF" toolkits). Each toolkit comes with a collection of 21520~7 -Widgets 255, which are useful collection of X objects (for example, a scrollabletext window Widget). Having provided a comparison of the structures of the X-Client/Windowing system and the "WINDOWS/NT" operating system, the processing steps of a preferred embodiment of the present invention will now be 5 described.
Figure 3 illustrates the processing steps of a prer~lled embodiment of the present invention. More specifically, Figure 3 illustrates an overview ofthe processing steps taken by the translation software to translate a natively executing application program into a fully compatible client of a non-native 10 windowing system. Initially, an application program is executed in its nativeenvironment (step 305). For example, in one preferred embodiment, this native environment is the "WINDOWS/NT" operating system. Once the application program is executing in its native environment, the translation software monitors system calls that the application relays to the native environment via the native 15 environment's application program interface (step310). For example, in a preferred embodiment, the translation software monitors the commands that are relayed from the application program to the application program interface provided by "WINDOWS/NT").
For each monitored system call, the translation software evaluates 20 whether the command represented by the API call is window management related (step315). A command is "window management related" when the results of the command alter the positioning of the application program's window(e.g, moving, resizing, stacking the application program's window). Thus, step 315 operates as a high-level intercept between the application program and the 25 native operating system.
When the API command is window management related, the translation software preferably suspends the native device driver's (e.g, the mouse driver, the keyboard driver, the display driver) ability to process the command (step 315, YES PATHWAY and step 320). In some instances, 30 suspending the native device driver's ability to process the command is advantageous as it greatly increases the system's response time. For example, by~suspending the native display driver while a window is being moved, the native display driver does not continuously redraw the window's image as the user drags the window across the display. As a result, the display driver does not 35 continuously send the BitBlts (blocks of bitmap data) that represent the window's image to the display hardware. Consequently, and especially in systems where a local display of the natively-executing application is not desired, system performance is greatly improved due to the reduction in unnecessary data transfer. After suspending the native device driver, the translation software converts the comm~n(1 into a format that is recognizable by the target GUI (step325). In a preferred embodiment, this target GUI adheres to a protocol known as 5 the X-Protocol. Consequently, the translation software converts the API
command to a command of the X-Protocol (e.g, a command from the Xlib library). Once the command has been converted, the translation software forwards the command to the target GUI system (step 330). For example, in a preferred embodiment this command is forwarded to a window manager. The 10 window manager then effectuates the converted command via the X-Server. As an optional step, the translation software can also pass the command to the native GUI system so that window management may be effectuated on a local native display (step 335). Whether or not the above optional step is performed, the translation software releases the native device driver from its suspended state 15 (step 335).
Referring back to step 315, when the monitored command is not window management related, the translation software passes the command to the application program's native operating system (step 315, NO PATHWAY, and step 340). Subsequently, the translation software intercepts each system call at20 the device driver level and determines when the system call will affect the internal state of the application program's window (steps 340 and 345). Thus, steps 340 and 345 operate as a low-level intercept between the application program and the native operating system. For the case where the system call willnot affect the internal state of the application program's window, the translation 25 software allows the application program to execute in its normal fashion (step 345, NO PATHWAY, and step 305). On the other hand, when the system call will affect the internal state of the application program's window, the translation software converts the system call to a target GUI call after suspending the native device driver (step 345, YES PATHWAY, steps 320 and 325). After translating 30 the system call, the translation software forwards the translated call to the target GUI system (step 330). The translation software then optionally passes the command to the native GUI display driver (step 335). Again, this optional step is only performed if local display of the natively-executing application programis desired. By repeating processing steps 305-345, the present invention allows 35 the application program to be executed in its native environment while simultaneously allowing the application to be interacted with remotely on a remote terminal or work station. Having described the processing steps of a -preferred embodiment of the present invention, the preferred embodiment will now be explained by way of example.
Figure 4 illustrates the processing steps of an application prograrn.
This program is designed to, in conjunction with an operating system, create a 5 window which displays the text "Hello." The program's processing begins by registering a window class with its intended native operating system (step 405).This window class describes a series of global attributes (e.g, an icon for the window that appears when the window is minimi7ed, the background color for the window, etc.) for a class of windows. Once a class of windows has been 10 registered with the operating system, the program creates a window for the class using a CreateWindow API call (step 410). The CreateWindow API call creates the desired window internally in the memory of the computer system. To display the window on the video display, the program issues a ShowWindow API call (step 420). A processing loop, collectively represented by blocks 430, 435, 440 15 and 450, then requests the painting of the text "Hello" on the video display. The message loop 430 refers to the code that retrieves messages from a message queue provided by the native operating system. More specifically, when the program receives a paint message (step 435, YES PATHWAY), the program requests the rendering of the character string "Hello" in the center of the 20 displayed window (step 440). On the other hand, when the received message is not a paint message (step 435, NO PATHWAY), the program determines whether or not the received message is a quit message (step 450). When the received message is not a quit message (step 450, NO PATHWAY), the program loops back to step 430 and waits for the next message. When the program 25 receives a quit message (step 450, YES PATHWAY), the program exits.
Figure 5 illustrates a flow diagram of the processing steps for the interaction between the application program of Figure 4 and a native operating system. The native operating system responds to the registering of the new window class by storing class data for the new data class (step 510). By storing30 this data, a window, or a number of windows, can be created based on the stored class data. Next, the native operating system responds to the CreateWindow API
call by creating a window structure (step 520). More specifically, the native operating system creates a window structure based on the passed parameters of the CreateWindow API call (e.g., the window style, the window caption, initial 35 positioning, etc.) and returns to the application program a handle to the created window structure. After the window structure is created, the native operating system displays the window on the computer system's video display in response 2l~2oo7 to the ShowWindow API call (step S30). In brief, the native operating system accomplishes this by receiving, as an input parameter from the application program, the handle that identifies the window that the application program desires to display. The native operating system also receives an input command 5 which indicates whether the window should be displayed in normal or minimi7ed format. After the native operating system displays the window, the application program begins inputting messages from the message queue via the previously described processing loop (steps 410-450 of Figure 4). The native operating system provides a Default Window Procedure (step 540 of Figure 5) that handles 10 all the messages that the application program itself does not process (ie., all messages other than paint and quit messages). As previously described, when the application program receives a paint message, the application program issuesa draw "Hello" command to the native operating system. The native operating system responds to this command by calling the video display driver (step 550).
15 In turn, the video display driver renders the text to the video display (step 560).
In the above-described manner, the native operating system interacts with the application program to display a local window.
Figure 6 illustrates a flow diagram of the processing steps for an example according to a preferred embodiment of the present invention. This 20 example illustrates how a preferred embodiment provides for remote interaction, in a non-native environment, with a natively executing application. As can be observed from the flow diagram, the preferred embodiment allows system calls that are not window management related (e.g, registering the window class) to be passed directly to the native operating system. However, when an API call is 25 window management related (e.g, creating windows, showing windows), the translation software intercepts the API call before passing the call to the native operating system (steps 610 and 620). For example, in the case of the API call CreateWindow, the preferred embodiment first calls either XGetGeometry or XGetWindow attributes to determine the dimensions of the remote server 30 display. Once the dimensions of the remote server display are known, the translation software calls the Xlib function XCreateWindow to create a remotely ~displayed window in an X-Environment. Similarly, when the application program issues a ShowWindow API call, the translation software displays a respective X-Window (step 620) prior to passing the ShowWindow API call to 35 the native operating system. Thus, in the example of Figure 6, steps 610 and 620 represent the high-level intercept discussed with relation to step 315 of Figure 3.
Analogously, steps 630 and 640 of Figure 6 represent the low-level intercepts 2l~2oo7 -discussed with reference to step 345 of Figure 3. More specifically, the translation software intercepts the application program's call to the video display driver (step 630). As mentioned above, the video display driver does not deal with high-level constructs such as windows. As a result, the translation software 5 must first determine the respective X-Window for which the call to the video display driver was made. This determination can be accomplished in a number of ways. For example, this determination can be made by m~in~ining and evaluating data structure that contains internal window state information for all the X-Windows that are currently in existence. In this scenario, the translation10 software determines the screen coordinates that are referenced by the displaydriver call. The translation software can then cross-reference these coordinatesto obtain a handle for the window structure that owns the coordinates. In turn, this handle can then be cross-referenced to determine the respective X-Window.
Having determined the desired X-Window, the translation software translates the 15 rendering request into X-Calls and sends these calls to the remote X-Server. In this manner, the remote display is quickly and efficiently updated. Finally, thetranslation software optionally passes the video display driver call to the local video driver if desired. This step is only necessary if local rendering is desired.
As explained in this preferred embodiment, the present invention 20 allows application programs that are executed under the "WINDOWS/NT"
operating system to be interacted with remotely via the X-Client/Server window system. One particularly advantageous use of the preferred embodiment relates to the field of medical technology. More specifically, a preferred embodiment ofthe present invention is in the Multi-Disclosure Review Station manufactured by 25 SpaceLabs, Incorporated utilizes a medical monitor as an X-Server. This specialized X-Server then renders the patient's critical data (e.g, a heart wave-form) on an accompanying X-Terminal. With the advent of the present invention, not only can the physician view a patient's heart wave-form on this termin~l, but the physician can also access application programs written for the30 "WINDOWS/NT" operating system. As a result, the physician's work is greatly simplified. For example, an application such as "MICROSOFT EXCEL" can be used to maintain a database of the patient's medical history. Thus, the present invention allows the physician to retrieve the patient's up-to-date medical history while simultaneously viewing the patient's heart wave-form. As the present 35 invention provides simultaneous access to current and past medical conditions, the physician can quicl~ly and easily obtain all the information that is necessary -to treat the patient via a single t-qrmin~l. In this manner, the physician can work more efficiently.
The detailed discussion provided above illustrates preferred embodiments of the present invention. This discussion will enable those skilled S in the art to make various modifications to this embodiment that do not depart from the spirit and the scope of the invention. For example, while a preferred embodiment was described with reference to the "WrNDOWS/NT" operating system, those skilled in the art will realize that the inventive concepts disclosed within are not limited to any particular operating system. Similarly, while the 10 preferred embodiment was described with reference to the X-Protocol, those skilled in the art will appreciate that the inventive concepts disclosed herein are not limited to the protocol of any particular remote graphical user interface.
Accordingly, the present invention contemplates all such modifications that read upon the appended claims and equivalents thereof.
I~escription A METHOD AND SYSTEM FOR DYNAMIC TRANSLATION BETWEEN
DIFFERENT GRAPHICAL USER INTERFACE SYSTEMS
Cross Reference to Related Apl~lication This application is a continuation-in-part of U.S. Applic~tion Serial No. 08/261,492 filed on June 17, 1994, now abandoned.
10 Technical Field The present invention relates to execution-time translation between dif~erent graphical user interface systems and in particular, includes a method and system that allows applications written for local-display systems to utilize the remote display capabilities of a different graphical user interface system.
Background of the Invention Currently, there are approximately 50 million computer users that utilize a graphical user interface known as "WINDOWS" by "MICROSOFT"
Corporation. Currently, "MICROSOFT's WINDOWS/NT" is rapidly emerging 20 as a preferred operating system. Consequently, a large number of application programs are written to be compatible with "WINDOWS/NT."
"WINDOWS/NT" provides a single graphical user interface in whicll all these application programs must adhere to. However, a client/server window system known as "X," initially developed at the Massacllusetts's Institute of Technology, 25 provides a protocol (X-Protocol) that allows application programs to be displayed remotely on one or more graphical user interfaces (e.g., Motif, Open-Look). Unfortunately, the application programs that are developed for the "WINDOWS/NT" operating system are not compatible with the X-Protocol.
Consequently, users of the X-ClientlServer window system do not have 30 conveniel1t access to these application programs. This is unforhlnate because many of the application programs developed for the "WINDOWS/NT" operating ~system are superior, in terms of cost and features, to those than developed for tlle X-Client/Server window system.
35 Summary of the Invention The present invention is directecl towards translation soflware that provides remote access to an application program. More specil;cally, the 21S20~7 -translation software provides remote access to an application program that is executing on a host machine in its native operating system environment. The translation software monitors messages that are relayed from the application program to an application interface that is provided via the native operating 5 system. Upon recogni7in~ a message that affects a graphical user interface of the native operating system, the translation software converts the message into a protocol that is recognized by a remote graphical user interface. The translation software also monitors and converts commands at the driver level. By monitoring and converting messages in this fashion, the translation software 10 allows the application program to be displayed remotely.
Brief Description of the Drawings Figure 1 illustrates a preferred embodiment of the present invention.
Figure 2 compares system design structures for a client/server window system and an operating system.
Figure 3 is a flow diagram of the processing steps of the preferred embodiment of the present invention.
Figure 4 illustrates a flow diagram of the processing steps of an 20 application program (prior art).
Figure 5 illustrates a flow diagram of the processing steps for the interaction between the application program and a native operating system (priorart).
Figure 6 illustrates a flow diagram of the processing steps for an 25 example according to a preferred embodiment of the present invention.
Detailed Description of tlle Tnvention The present invention is directed towards a translation software that allows an application program written for a particular graphical user 30 interface system (GUI) to be displayed on another graphical user interface system at execution time. The GUI upon which the application program is displayed is referred to as the target GUI. If the target GUI is capable of remote display over a network, the translation software allows the application program to be displayed and interacted with remotely while it executes within its native35 (non-remote) GUI.
In its preferred embodiment, the present invention provides for translation from Windows and "WINDOWSINT" to the X-Window System and -thus allows for the remote display of applications developed for "MICROSOFT
WINDOWS" and "WINDOWS/NT" on X-Terminals and X-Servers. More specifically, the preferred embodiment allows each such application to appear asa fully compatible X-Client program to remote X-Servers. The term "X-Client"
5 refers to an application program that utilizes the previously described X-Protocol. The term "X-Terminal" refers to any display component (e.g, stand-alone terminal or workstation) that is a display component of an X-Client/Serverwindowing system. The term "X-Server" refers to the software that controls the display hardware (e.g, a video display, a keyboard, or mouse) and is responsible10 for conducting the drawing and rendering of the video display. An attractive feature of an X-Client program is that it may be displayed and/or interacted with (e.g, via mouse, keyboard, etc.) on any X-Terminal provided there is a suitable communications link (typically, but not restricted to, the TCP/IP protocol described below) connecting the machine the X-Client is running on and the X-15 Terminal.
In the X-Client/Server window system an X-Client communicates with the underlying hardware (e.g, display, mouse, keyboard, etc.) via the X-Server. A separate X-Client, known as a window manager, coordinates with the X-Server to manage the display. More specifically, the window manager 20 keeps track of the state of all X-Windows. The term "X-Window" refers to any portion of an X-Terminal's display that contains its own data (e.g., a document or a message). A primary advantage of the X-Client/Server window system is that it does not constrain an X-Client to the use of any particular window manager.
Instead, a user may select the window manager that the user believes offers the 25 most attractive look and feel.
Figure 1 illustrates a preferred embodiment of the present invention. A host computer 110 executes application programs such as "MICROSOFT EXCEI," 120 and "WORD FOR WINDOWS" 130 under the "WINDOWS/NT" operating system 140. The "WINDOWS/NT" operating 30 system, as well as the application programs 120, 130, are contained within a main memory of the host computer. More specifically, a central processing unit contained within the host computer 110 e~ecutes the instructions of both the "WINDOWS/NT" operating system 140 and the application programs 120, 130.
The "WINDOWS/NT" operating system provides an application program 35 interface (API) that allows these application programs 120, 130 to communicate with the operating system 140. Additionally, the "WINDOWS/NT" operating system also provides a standard graphical user interface (GUI) that defines the 2,~
-look and feel for all applications running under "WINDOWS/NT." This standard graphical user interface is designed to receive commands from the application program. In brief, the application programs 120, 130 utilize the application interface to request the operating system to conduct a variety of 5 tasks. For example, representative tasks include the opening and closing of files, as well as making various adjustments to the graphical user interface. However, the "WINDOWS/NT" operating system does not provide for remote interaction with applications. In its preferred embodiment, the present invention overcomes this limitation of "WINDOWS/NT" by allowing application programs 120, 130 10 to be executed on the host computer while being displayed remotely on an X-Terminal 150. In this manner, the present invention allows users of the X-Client/Server window system to gain access to applications developed for the "WINDOWS/NT" operating system. Moreover, as the preferred embodiment of the present invention allows the application programs 120, 130 to be executed in15 their native operating system environments (e.g, the "WINDOWS/NT"
operating system 140), the present invention provides such access in a highly efficient manner.
As illustrated, the host computer 110 is connected to the X-Terminals 150 via a network connection such as the TCP/IP protocol used on the 20 Ethernet. In brief, this protocol consists of a series of layers. More specifically, the five lower-most layers in ascending order are; the wire, the Ethernet, the Internet protocol (IP layer), the transport control protocol (TCP layer) and the X-Protocol. This network connection is conceptually illustrated by reference 160.
As described above, the X-Client/Server window system utili7es 25 two components: an X-Server 170 and a window manager 180. The window manager 180 manages X-Windows by keeping track of how many X-Windows are currently displayed, where the X-Windows are currently displayed, etc. As the present invention converts the "WINDOWS/NT" application to a fully compatible X-Client, a user may select a particular window manager 180 (e.g., 30 Motif, Open-Look, Tom's Window Manager) for use with the present invention.
In brief, the window manager 180 receives commands that relate to the display -of the X-Terminals 150. As the window manager 180 may be contained within the X-Terminal itself or on the network, the window manager may receive commands over the network connection 160 or directly from the X-35 Terminals 150.
Figure 2 compares system design structures for a client/serverwindow system and an operating system. More specifically, Figure 2 compares 2~52007 -s the system design structure of the X-ClientlServer windowing system and the "WINDOWS/NT" operating system. A knowledge of these structures is helpful when discussing the processing steps described in Figures 3-6.
In "WINDOWS/NT" programs (e.g, application programs) are S provided with a standard interface to the hardware 205 (e.g, display, keyboard, mouse, etc.) via device drivers 210. The various components 215 of the "WINDOWS/NT" operating system are layered above the device driver. One such component is Graphics Device Interface 220 (GDI). The GDI allows applications programs to describe graphical information without reference to the 10 underlying hardware. The Application Program Interface 225 (API) exists above the "WINDOWS/NT" components layer. The API contains the notion of windows, icons, cursors, and other resources. "WINDOWS/NT" is an event driven, message based system. Various programs communicate with each other and with "WINDOWS/NT" by passing messages via the API. In regards to 15 graphically displayed information, the API utilizes high-level constructs such as windows or icons. In contrast, the video device driver utilizes lower-level representations of graphical data (e.g, bitmap data). One of the purposes of the video device driver is to relay this bitmap data to the display device. For example, when the user moves or resizes a window, a large number of BitBlts 20 (block transfers of bitmap data) are executed by the display driver.
The X-Server-Client windowing system is structured somewhat similarly to the "WrNDOWS/NT" operating system. An X-Server 230 provides a standard interface to the underlying hardware 235. A library, Xlib 240, provides a (lower level) programmers' interface for X. When the X-Client is run 25 locally, the X-Client issues commands from the Xlib library 240 to access the local haldw~e 235 through the X-Server 230. Similarly, when the X-Client is run remotely, the X-Client issues commands from the Xlib library 240 to access the remote hardware. In this case, network packets which represent elements of the X-Protocol are sent to the X-Server 230 that serves the remote hardware 235.
30 Like "WINDOWS/NT," X is an event driven system and an X-Client may request the X-Server 230 to send it X-Events of interest (such as the mouse entering or leaving a window, the user clicking in a window, etc.). As mentioned above, a special X-Client program, the window manager 245, allows the user to manage displayed windows, define menus, etc. Above the relatively low-level 35 Xlib interface, a X-Toolkits 250 provides a higher level programmers interface.
There are many such toolkits which are available commercially (e.g, the "XT,"
"ANDREW," and "MOTIF" toolkits). Each toolkit comes with a collection of 21520~7 -Widgets 255, which are useful collection of X objects (for example, a scrollabletext window Widget). Having provided a comparison of the structures of the X-Client/Windowing system and the "WINDOWS/NT" operating system, the processing steps of a preferred embodiment of the present invention will now be 5 described.
Figure 3 illustrates the processing steps of a prer~lled embodiment of the present invention. More specifically, Figure 3 illustrates an overview ofthe processing steps taken by the translation software to translate a natively executing application program into a fully compatible client of a non-native 10 windowing system. Initially, an application program is executed in its nativeenvironment (step 305). For example, in one preferred embodiment, this native environment is the "WINDOWS/NT" operating system. Once the application program is executing in its native environment, the translation software monitors system calls that the application relays to the native environment via the native 15 environment's application program interface (step310). For example, in a preferred embodiment, the translation software monitors the commands that are relayed from the application program to the application program interface provided by "WINDOWS/NT").
For each monitored system call, the translation software evaluates 20 whether the command represented by the API call is window management related (step315). A command is "window management related" when the results of the command alter the positioning of the application program's window(e.g, moving, resizing, stacking the application program's window). Thus, step 315 operates as a high-level intercept between the application program and the 25 native operating system.
When the API command is window management related, the translation software preferably suspends the native device driver's (e.g, the mouse driver, the keyboard driver, the display driver) ability to process the command (step 315, YES PATHWAY and step 320). In some instances, 30 suspending the native device driver's ability to process the command is advantageous as it greatly increases the system's response time. For example, by~suspending the native display driver while a window is being moved, the native display driver does not continuously redraw the window's image as the user drags the window across the display. As a result, the display driver does not 35 continuously send the BitBlts (blocks of bitmap data) that represent the window's image to the display hardware. Consequently, and especially in systems where a local display of the natively-executing application is not desired, system performance is greatly improved due to the reduction in unnecessary data transfer. After suspending the native device driver, the translation software converts the comm~n(1 into a format that is recognizable by the target GUI (step325). In a preferred embodiment, this target GUI adheres to a protocol known as 5 the X-Protocol. Consequently, the translation software converts the API
command to a command of the X-Protocol (e.g, a command from the Xlib library). Once the command has been converted, the translation software forwards the command to the target GUI system (step 330). For example, in a preferred embodiment this command is forwarded to a window manager. The 10 window manager then effectuates the converted command via the X-Server. As an optional step, the translation software can also pass the command to the native GUI system so that window management may be effectuated on a local native display (step 335). Whether or not the above optional step is performed, the translation software releases the native device driver from its suspended state 15 (step 335).
Referring back to step 315, when the monitored command is not window management related, the translation software passes the command to the application program's native operating system (step 315, NO PATHWAY, and step 340). Subsequently, the translation software intercepts each system call at20 the device driver level and determines when the system call will affect the internal state of the application program's window (steps 340 and 345). Thus, steps 340 and 345 operate as a low-level intercept between the application program and the native operating system. For the case where the system call willnot affect the internal state of the application program's window, the translation 25 software allows the application program to execute in its normal fashion (step 345, NO PATHWAY, and step 305). On the other hand, when the system call will affect the internal state of the application program's window, the translation software converts the system call to a target GUI call after suspending the native device driver (step 345, YES PATHWAY, steps 320 and 325). After translating 30 the system call, the translation software forwards the translated call to the target GUI system (step 330). The translation software then optionally passes the command to the native GUI display driver (step 335). Again, this optional step is only performed if local display of the natively-executing application programis desired. By repeating processing steps 305-345, the present invention allows 35 the application program to be executed in its native environment while simultaneously allowing the application to be interacted with remotely on a remote terminal or work station. Having described the processing steps of a -preferred embodiment of the present invention, the preferred embodiment will now be explained by way of example.
Figure 4 illustrates the processing steps of an application prograrn.
This program is designed to, in conjunction with an operating system, create a 5 window which displays the text "Hello." The program's processing begins by registering a window class with its intended native operating system (step 405).This window class describes a series of global attributes (e.g, an icon for the window that appears when the window is minimi7ed, the background color for the window, etc.) for a class of windows. Once a class of windows has been 10 registered with the operating system, the program creates a window for the class using a CreateWindow API call (step 410). The CreateWindow API call creates the desired window internally in the memory of the computer system. To display the window on the video display, the program issues a ShowWindow API call (step 420). A processing loop, collectively represented by blocks 430, 435, 440 15 and 450, then requests the painting of the text "Hello" on the video display. The message loop 430 refers to the code that retrieves messages from a message queue provided by the native operating system. More specifically, when the program receives a paint message (step 435, YES PATHWAY), the program requests the rendering of the character string "Hello" in the center of the 20 displayed window (step 440). On the other hand, when the received message is not a paint message (step 435, NO PATHWAY), the program determines whether or not the received message is a quit message (step 450). When the received message is not a quit message (step 450, NO PATHWAY), the program loops back to step 430 and waits for the next message. When the program 25 receives a quit message (step 450, YES PATHWAY), the program exits.
Figure 5 illustrates a flow diagram of the processing steps for the interaction between the application program of Figure 4 and a native operating system. The native operating system responds to the registering of the new window class by storing class data for the new data class (step 510). By storing30 this data, a window, or a number of windows, can be created based on the stored class data. Next, the native operating system responds to the CreateWindow API
call by creating a window structure (step 520). More specifically, the native operating system creates a window structure based on the passed parameters of the CreateWindow API call (e.g., the window style, the window caption, initial 35 positioning, etc.) and returns to the application program a handle to the created window structure. After the window structure is created, the native operating system displays the window on the computer system's video display in response 2l~2oo7 to the ShowWindow API call (step S30). In brief, the native operating system accomplishes this by receiving, as an input parameter from the application program, the handle that identifies the window that the application program desires to display. The native operating system also receives an input command 5 which indicates whether the window should be displayed in normal or minimi7ed format. After the native operating system displays the window, the application program begins inputting messages from the message queue via the previously described processing loop (steps 410-450 of Figure 4). The native operating system provides a Default Window Procedure (step 540 of Figure 5) that handles 10 all the messages that the application program itself does not process (ie., all messages other than paint and quit messages). As previously described, when the application program receives a paint message, the application program issuesa draw "Hello" command to the native operating system. The native operating system responds to this command by calling the video display driver (step 550).
15 In turn, the video display driver renders the text to the video display (step 560).
In the above-described manner, the native operating system interacts with the application program to display a local window.
Figure 6 illustrates a flow diagram of the processing steps for an example according to a preferred embodiment of the present invention. This 20 example illustrates how a preferred embodiment provides for remote interaction, in a non-native environment, with a natively executing application. As can be observed from the flow diagram, the preferred embodiment allows system calls that are not window management related (e.g, registering the window class) to be passed directly to the native operating system. However, when an API call is 25 window management related (e.g, creating windows, showing windows), the translation software intercepts the API call before passing the call to the native operating system (steps 610 and 620). For example, in the case of the API call CreateWindow, the preferred embodiment first calls either XGetGeometry or XGetWindow attributes to determine the dimensions of the remote server 30 display. Once the dimensions of the remote server display are known, the translation software calls the Xlib function XCreateWindow to create a remotely ~displayed window in an X-Environment. Similarly, when the application program issues a ShowWindow API call, the translation software displays a respective X-Window (step 620) prior to passing the ShowWindow API call to 35 the native operating system. Thus, in the example of Figure 6, steps 610 and 620 represent the high-level intercept discussed with relation to step 315 of Figure 3.
Analogously, steps 630 and 640 of Figure 6 represent the low-level intercepts 2l~2oo7 -discussed with reference to step 345 of Figure 3. More specifically, the translation software intercepts the application program's call to the video display driver (step 630). As mentioned above, the video display driver does not deal with high-level constructs such as windows. As a result, the translation software 5 must first determine the respective X-Window for which the call to the video display driver was made. This determination can be accomplished in a number of ways. For example, this determination can be made by m~in~ining and evaluating data structure that contains internal window state information for all the X-Windows that are currently in existence. In this scenario, the translation10 software determines the screen coordinates that are referenced by the displaydriver call. The translation software can then cross-reference these coordinatesto obtain a handle for the window structure that owns the coordinates. In turn, this handle can then be cross-referenced to determine the respective X-Window.
Having determined the desired X-Window, the translation software translates the 15 rendering request into X-Calls and sends these calls to the remote X-Server. In this manner, the remote display is quickly and efficiently updated. Finally, thetranslation software optionally passes the video display driver call to the local video driver if desired. This step is only necessary if local rendering is desired.
As explained in this preferred embodiment, the present invention 20 allows application programs that are executed under the "WINDOWS/NT"
operating system to be interacted with remotely via the X-Client/Server window system. One particularly advantageous use of the preferred embodiment relates to the field of medical technology. More specifically, a preferred embodiment ofthe present invention is in the Multi-Disclosure Review Station manufactured by 25 SpaceLabs, Incorporated utilizes a medical monitor as an X-Server. This specialized X-Server then renders the patient's critical data (e.g, a heart wave-form) on an accompanying X-Terminal. With the advent of the present invention, not only can the physician view a patient's heart wave-form on this termin~l, but the physician can also access application programs written for the30 "WINDOWS/NT" operating system. As a result, the physician's work is greatly simplified. For example, an application such as "MICROSOFT EXCEL" can be used to maintain a database of the patient's medical history. Thus, the present invention allows the physician to retrieve the patient's up-to-date medical history while simultaneously viewing the patient's heart wave-form. As the present 35 invention provides simultaneous access to current and past medical conditions, the physician can quicl~ly and easily obtain all the information that is necessary -to treat the patient via a single t-qrmin~l. In this manner, the physician can work more efficiently.
The detailed discussion provided above illustrates preferred embodiments of the present invention. This discussion will enable those skilled S in the art to make various modifications to this embodiment that do not depart from the spirit and the scope of the invention. For example, while a preferred embodiment was described with reference to the "WrNDOWS/NT" operating system, those skilled in the art will realize that the inventive concepts disclosed within are not limited to any particular operating system. Similarly, while the 10 preferred embodiment was described with reference to the X-Protocol, those skilled in the art will appreciate that the inventive concepts disclosed herein are not limited to the protocol of any particular remote graphical user interface.
Accordingly, the present invention contemplates all such modifications that read upon the appended claims and equivalents thereof.
Claims (10)
1. A method for running an application as an X-Client so as to enable the application to be displayed with an X-Windows manager, the method comprising the steps of:
launching a "WINDOWS/NT" session;
invoking an application from within the "WINDOWS/NT" session;
monitoring output messages that are sent from the application;
determining when one of the monitored output messages is a graphical user interface command; and when the monitored output message is a graphical user interface command, suspending a "WINDOWS/NT" device driver from acting on the command, allowing an X-Windows manager program to act on the command, and informing the "WINDOWS/NT" device driver of results of the command that was acted on by the X-Windows manager program.
launching a "WINDOWS/NT" session;
invoking an application from within the "WINDOWS/NT" session;
monitoring output messages that are sent from the application;
determining when one of the monitored output messages is a graphical user interface command; and when the monitored output message is a graphical user interface command, suspending a "WINDOWS/NT" device driver from acting on the command, allowing an X-Windows manager program to act on the command, and informing the "WINDOWS/NT" device driver of results of the command that was acted on by the X-Windows manager program.
2. The method of claim 1, further comprising the step of:
converting the command from a "WINDOWS/NT" format into a format that is interpretable by an X-Server to allow the X-Server to act on the command.
converting the command from a "WINDOWS/NT" format into a format that is interpretable by an X-Server to allow the X-Server to act on the command.
3. A method for providing remote access to an application program that is executing in a native operating system, wherein the native operating system provides an application interface to receive commands from the application program, and wherein the operating system provides a native graphical user interface, themethod comprising the steps of:
monitoring a message that is output from the application program to the application interface;
intercepting the monitored message when the message is an operation that affects the native graphical user interface; and redirecting the intercepted message to a non-native graphical user interface manager to enable the non-native graphical user interface manager to conduct the operation of the monitored message.
monitoring a message that is output from the application program to the application interface;
intercepting the monitored message when the message is an operation that affects the native graphical user interface; and redirecting the intercepted message to a non-native graphical user interface manager to enable the non-native graphical user interface manager to conduct the operation of the monitored message.
4. The method of claim 3, further comprising the step of:
informing the native operating system of results of the intercepted message.
informing the native operating system of results of the intercepted message.
5. A method for providing remote display and interaction with an application program that is executing on a local machine, the local machine executing the application in an environment of a native operating system, wherein the native operating system provides a local application interface to receive commands from the application program, and a local graphical user interface, the method comprising the steps of:
detecting a command that is output from the application program to the application interface; and converting the detected message from a local graphical user interface format to a remote graphical user interface format so that the detected message can be interpreted by a remote graphical user interface.
detecting a command that is output from the application program to the application interface; and converting the detected message from a local graphical user interface format to a remote graphical user interface format so that the detected message can be interpreted by a remote graphical user interface.
6. A method for providing remote user interaction with an application program that is being run in its native environment on a host machine, the native environment providing a local graphical user interface for allowing local user interaction with the application program, the method comprising the steps of:
determining when the application program has sent a command to the local graphical user interface;
suspending the native environment's ability to process the determined command; and converting the determined command to a protocol that is recognizable by a remote graphical interface.
determining when the application program has sent a command to the local graphical user interface;
suspending the native environment's ability to process the determined command; and converting the determined command to a protocol that is recognizable by a remote graphical interface.
7. An apparatus that allows an application program to be treated as a remote X-Client while the application program is running in a non-Unix environment, the apparatus comprising:
a monitoring device that determines when the application program has sent a command to a local graphical user interface, the local graphical user interface being provided by the non-Unix environment;
a disabling device that suspends the non-Unix environment's ability to process the determined command; and a modifier that converts the determined command to a protocol that is recognizable by a remote graphical interface.
a monitoring device that determines when the application program has sent a command to a local graphical user interface, the local graphical user interface being provided by the non-Unix environment;
a disabling device that suspends the non-Unix environment's ability to process the determined command; and a modifier that converts the determined command to a protocol that is recognizable by a remote graphical interface.
8. A method for allowing a Windows or "WINDOWS/NT"
application to run in its native environment in addition to running as an X-Client so as to enable the application to be displayed on a remote X-Terminal, the method comprising the steps of:
remotely launching a Windows or "WINDOWS/NT" application;
monitoring system calls and display-driver calls that are made by the Windows or "WINDOWS/NT" application;
determining when one of the monitored system calls is a graphical user interface related command;
determining when screen rendering is for a window owned by the Windows or "WINDOWS/NT" application; and whenever monitored system calls are graphical user interface commands and whenever display-driver rendering is targeted for the window owned by the Windows or "WINDOWS/NT" application program, making appropriate X-System calls in order to accomplish the intended effect on the remote X-Terminal and then allowing an operating system of the native environment to process the call.
application to run in its native environment in addition to running as an X-Client so as to enable the application to be displayed on a remote X-Terminal, the method comprising the steps of:
remotely launching a Windows or "WINDOWS/NT" application;
monitoring system calls and display-driver calls that are made by the Windows or "WINDOWS/NT" application;
determining when one of the monitored system calls is a graphical user interface related command;
determining when screen rendering is for a window owned by the Windows or "WINDOWS/NT" application; and whenever monitored system calls are graphical user interface commands and whenever display-driver rendering is targeted for the window owned by the Windows or "WINDOWS/NT" application program, making appropriate X-System calls in order to accomplish the intended effect on the remote X-Terminal and then allowing an operating system of the native environment to process the call.
9. A method for execution-time translation from a first graphical operating system to a second graphical operating system wherein the first graphical operating system does not provide for remotely displaying application programs, and wherein the second graphical operating system does provide for remotely displaying application programs, the method comprising the steps of:
monitoring system calls and display-driver calls that are made by an application program that is executing in the first graphical operating system;
determining when one of the monitored system calls is a graphical user interface related command;
determining when screen rendering is targeted for a window that is owned by the application program that is executing in the first graphical operating system, and whenever monitored system calls are graphical user interface commands and whenever display-driver rendering is targeted for the window that is owned by the application program that is executing in the first graphical operating system making appropriate commands in the second graphical operating system in order to accomplish the intended effect on a remote display that is controlled by the second graphical operating system and then allowing the first graphical operating system to process the call.
monitoring system calls and display-driver calls that are made by an application program that is executing in the first graphical operating system;
determining when one of the monitored system calls is a graphical user interface related command;
determining when screen rendering is targeted for a window that is owned by the application program that is executing in the first graphical operating system, and whenever monitored system calls are graphical user interface commands and whenever display-driver rendering is targeted for the window that is owned by the application program that is executing in the first graphical operating system making appropriate commands in the second graphical operating system in order to accomplish the intended effect on a remote display that is controlled by the second graphical operating system and then allowing the first graphical operating system to process the call.
10. A method for translating, from a first graphical operating system to a second graphical operating system, commands of an application program that is executing in the first graphical environment wherein the first graphical operating system does not provide for a remote display of the application program, and wherein the second graphical operating system does provide for the remote display of theapplication program, the method comprising the steps of:
monitoring device driver calls that are made by the application program;
determining when one of the monitored device driver calls is targeted for a window that is owned by the application program; and whenever one of the monitored device driver calls is targeted for the window that is owned by the application program, issuing appropriate commands inthe second graphical operating system in order to accomplish the intended effect on a remote display that is controlled by the second graphical operating system.
monitoring device driver calls that are made by the application program;
determining when one of the monitored device driver calls is targeted for a window that is owned by the application program; and whenever one of the monitored device driver calls is targeted for the window that is owned by the application program, issuing appropriate commands inthe second graphical operating system in order to accomplish the intended effect on a remote display that is controlled by the second graphical operating system.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US26149294A | 1994-06-17 | 1994-06-17 | |
| US08/261,492 | 1994-06-17 | ||
| US08/472,935 US5831609A (en) | 1994-06-17 | 1995-06-06 | Method and system for dynamic translation between different graphical user interface systems |
| US08/472,935 | 1995-06-06 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2152007A1 true CA2152007A1 (en) | 1995-12-18 |
Family
ID=26948641
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002152007A Abandoned CA2152007A1 (en) | 1994-06-17 | 1995-06-16 | Method and system for dynamic translation between different graphical user interface systems |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5831609A (en) |
| CA (1) | CA2152007A1 (en) |
| DE (1) | DE19522185A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7720672B1 (en) | 1995-12-29 | 2010-05-18 | Wyse Technology Inc. | Method and apparatus for display of windowing application programs on a terminal |
| EP1956492A3 (en) * | 1999-09-21 | 2010-10-13 | Wyse Technology | Displaying windowing application programs on a terminal |
Families Citing this family (85)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2168087A1 (en) * | 1995-02-13 | 1996-08-14 | James S. Coman | Operating system based remote communication system |
| DE19655400B4 (en) * | 1995-12-29 | 2011-03-17 | Wyse Technology, Inc., San Jose | Terminal for communicating with a server |
| US5918039A (en) * | 1995-12-29 | 1999-06-29 | Wyse Technology, Inc. | Method and apparatus for display of windowing application programs on a terminal |
| US6429402B1 (en) | 1997-01-24 | 2002-08-06 | The Regents Of The University Of California | Controlled laser production of elongated articles from particulates |
| DE19812308A1 (en) * | 1998-03-20 | 1999-09-23 | Siemens Ag | Application execution method for computer network |
| US6473100B1 (en) * | 1998-05-20 | 2002-10-29 | Microsoft Corporation | Hosting controls in a window via an interface for controlling the window |
| US6522343B2 (en) * | 1998-07-15 | 2003-02-18 | Microsoft Corporation | Hosting objects in a windowed environment |
| US8555194B2 (en) * | 1998-07-17 | 2013-10-08 | D. David Nason | Secondary user interface |
| US6348933B1 (en) * | 1998-07-20 | 2002-02-19 | Hewlett-Packard Company | Single logical screen display using multiple remote computer systems |
| US6484309B2 (en) * | 1998-10-08 | 2002-11-19 | Intel Corporation | Enabling software designed for one operating system to operate on another operating system |
| DE19900895C2 (en) * | 1999-01-13 | 2001-03-15 | Tobias Kramer | Device and method for remote access to a target computer |
| US6630943B1 (en) * | 1999-09-21 | 2003-10-07 | Xsides Corporation | Method and system for controlling a complementary user interface on a display surface |
| JP4395223B2 (en) * | 1999-09-24 | 2010-01-06 | 株式会社日立製作所 | Display device, display method, and navigation device |
| US6545690B1 (en) * | 1999-09-29 | 2003-04-08 | Lucent Technologies Inc. | Liaison interface |
| DE10028842A1 (en) * | 2000-06-15 | 2002-01-03 | Ralf Mimoun | Operation surface generating method involves converting position and function of individual components on operation surface into standard code so that browser will return inputs of user in demanded format |
| US6829654B1 (en) * | 2000-06-23 | 2004-12-07 | Cloudshield Technologies, Inc. | Apparatus and method for virtual edge placement of web sites |
| US20020049867A1 (en) * | 2000-08-29 | 2002-04-25 | Yoshitomo Kumagai | Application transfer method, application transfer system and storage medium therefore |
| US6801224B1 (en) * | 2000-09-14 | 2004-10-05 | International Business Machines Corporation | Method, system, and program for generating a graphical user interface window for an application program |
| US6961945B2 (en) * | 2000-10-30 | 2005-11-01 | Microsoft Corporation | Method and apparatus for adapting and hosting legacy user interface controls |
| US6954933B2 (en) * | 2000-10-30 | 2005-10-11 | Microsoft Corporation | Method and apparatus for providing and integrating high-performance message queues in a user interface environment |
| US20020138512A1 (en) * | 2000-11-17 | 2002-09-26 | William Buresh | Flexible form and window arrangement for the display of medical data |
| AU2002235232B2 (en) | 2000-12-18 | 2006-01-12 | Ack Ventures Holdings, Llc | A system and method for delivering content to mobile devices |
| GB0031206D0 (en) * | 2000-12-21 | 2001-01-31 | Ibm | Multi-platform command line interpretation |
| TW539951B (en) * | 2001-01-17 | 2003-07-01 | Duan-Huei Wu | A method transferring resources among operating systems |
| US20020138821A1 (en) * | 2001-01-23 | 2002-09-26 | Vadim Furman | Method and apparatus for seamless porting of object code between operating system environments |
| US7051288B2 (en) | 2001-02-15 | 2006-05-23 | International Business Machines Corporation | Method, system, and product for a java-based desktop to provide window manager services on UNIX |
| US20030023639A1 (en) * | 2001-04-03 | 2003-01-30 | Openpath Software Corp. | Application generator for creating web pages |
| US20020157088A1 (en) * | 2001-04-20 | 2002-10-24 | Orchid Systems, Inc. | System for and method of automating the execution of a data stream transformation project |
| KR100676697B1 (en) * | 2001-06-13 | 2007-01-31 | 삼성전자주식회사 | Language displaying method and system of software for computer, recording media of computer program therefor |
| US6980997B1 (en) * | 2001-06-28 | 2005-12-27 | Microsoft Corporation | System and method providing inlined stub |
| US20030212605A1 (en) * | 2002-05-08 | 2003-11-13 | Amikai, Inc. | Subscription-fee-based automated machine translation system |
| US20040024843A1 (en) * | 2002-07-31 | 2004-02-05 | Smith Christopher T. | Method for provisioning distributed web applications |
| JP3938343B2 (en) * | 2002-08-09 | 2007-06-27 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Task management system, program, and control method |
| US7899879B2 (en) | 2002-09-06 | 2011-03-01 | Oracle International Corporation | Method and apparatus for a report cache in a near real-time business intelligence system |
| US7912899B2 (en) | 2002-09-06 | 2011-03-22 | Oracle International Corporation | Method for selectively sending a notification to an instant messaging device |
| US7945846B2 (en) | 2002-09-06 | 2011-05-17 | Oracle International Corporation | Application-specific personalization for data display |
| US7454423B2 (en) | 2002-09-06 | 2008-11-18 | Oracle International Corporation | Enterprise link for a software database |
| US8165993B2 (en) | 2002-09-06 | 2012-04-24 | Oracle International Corporation | Business intelligence system with interface that provides for immediate user action |
| US7941542B2 (en) | 2002-09-06 | 2011-05-10 | Oracle International Corporation | Methods and apparatus for maintaining application execution over an intermittent network connection |
| US7412481B2 (en) | 2002-09-16 | 2008-08-12 | Oracle International Corporation | Method and apparatus for distributed rule evaluation in a near real-time business intelligence system |
| US8255454B2 (en) * | 2002-09-06 | 2012-08-28 | Oracle International Corporation | Method and apparatus for a multiplexed active data window in a near real-time business intelligence system |
| US7668917B2 (en) | 2002-09-16 | 2010-02-23 | Oracle International Corporation | Method and apparatus for ensuring accountability in the examination of a set of data elements by a user |
| US7426059B2 (en) | 2002-09-16 | 2008-09-16 | Oracle International Corporation | Data presentation methods and apparatus to facilitate printing and reviewing |
| US7401158B2 (en) | 2002-09-16 | 2008-07-15 | Oracle International Corporation | Apparatus and method for instant messaging collaboration |
| US8046682B2 (en) * | 2002-12-02 | 2011-10-25 | Siebel Systems, Inc. | Method and system for accessing business applications via a standard interface |
| US7904823B2 (en) | 2003-03-17 | 2011-03-08 | Oracle International Corporation | Transparent windows methods and apparatus therefor |
| US8302111B2 (en) | 2003-11-24 | 2012-10-30 | Time Warner Cable Inc. | Methods and apparatus for hardware registration in a network device |
| US7266726B1 (en) | 2003-11-24 | 2007-09-04 | Time Warner Cable Inc. | Methods and apparatus for event logging in an information network |
| US9213538B1 (en) | 2004-02-06 | 2015-12-15 | Time Warner Cable Enterprises Llc | Methods and apparatus for display element management in an information network |
| US7623933B2 (en) * | 2005-06-10 | 2009-11-24 | Time Warner Cable Inc. | Methods and apparatus for controlling display in a networked device |
| US7917856B2 (en) * | 2005-10-24 | 2011-03-29 | Sap Ag | Converting between user interface technologies |
| US20090089453A1 (en) * | 2007-09-27 | 2009-04-02 | International Business Machines Corporation | Remote visualization of a graphics application |
| US8433812B2 (en) * | 2008-04-01 | 2013-04-30 | Microsoft Corporation | Systems and methods for managing multimedia operations in remote sessions |
| US9444894B2 (en) * | 2009-04-15 | 2016-09-13 | Wyse Technology Llc | System and method for communicating events at a server to a remote device |
| US8863232B1 (en) | 2011-02-04 | 2014-10-14 | hopTo Inc. | System for and methods of controlling user access to applications and/or programs of a computer |
| US8769110B2 (en) * | 2011-05-27 | 2014-07-01 | Sony Corporation | Transferring RUI from one device to another |
| KR101801577B1 (en) * | 2011-06-28 | 2017-11-27 | 엘지전자 주식회사 | Mobile terminal and Method for controlling display thereof |
| US9367931B1 (en) | 2011-12-30 | 2016-06-14 | hopTo Inc. | Motion vectors for cross-platform display |
| US9218107B1 (en) | 2011-12-30 | 2015-12-22 | hopTo Inc. | Cloud-based text management for cross-platform display |
| US9454617B1 (en) | 2011-12-30 | 2016-09-27 | hopTo Inc. | Client rendering |
| US9223534B1 (en) | 2011-12-30 | 2015-12-29 | hopTo Inc. | Client side detection of motion vectors for cross-platform display |
| US8856262B1 (en) | 2011-12-30 | 2014-10-07 | hopTo Inc. | Cloud-based image hosting |
| US8775545B1 (en) | 2011-12-30 | 2014-07-08 | hop To Inc. | Image hosting for cross-platform display over a communication network |
| US9064292B1 (en) * | 2011-12-30 | 2015-06-23 | hopTo, Inc. | System for and method of classifying and translating graphics commands in client-server computing systems |
| US8922569B1 (en) * | 2011-12-30 | 2014-12-30 | hopTo Inc. | Cloud based system for and method of translating between disparate 3D graphics languages in client-server computing environments |
| US9183663B1 (en) * | 2011-12-30 | 2015-11-10 | Graphon Corporation | System for and method of classifying and translating graphics commands in client-server computing systems |
| US9124562B1 (en) | 2012-05-18 | 2015-09-01 | hopTo Inc. | Cloud-based decomposition and recomposition for cross-platform display |
| US9106612B1 (en) * | 2012-05-18 | 2015-08-11 | hopTo Inc. | Decomposition and recomposition for cross-platform display |
| US8990363B1 (en) * | 2012-05-18 | 2015-03-24 | hopTo, Inc. | Decomposition and recomposition for cross-platform display |
| US9419848B1 (en) | 2012-05-25 | 2016-08-16 | hopTo Inc. | System for and method of providing a document sharing service in combination with remote access to document applications |
| US8713658B1 (en) | 2012-05-25 | 2014-04-29 | Graphon Corporation | System for and method of providing single sign-on (SSO) capability in an application publishing environment |
| US9239812B1 (en) | 2012-08-08 | 2016-01-19 | hopTo Inc. | System for and method of providing a universal I/O command translation framework in an application publishing environment |
| US8763054B1 (en) | 2012-11-02 | 2014-06-24 | hopTo Inc. | Cross-platform video display |
| US8776152B1 (en) | 2012-11-02 | 2014-07-08 | hopTo Inc. | Cloud-based cross-platform video display |
| US8725645B1 (en) | 2013-01-04 | 2014-05-13 | Cetrus LLC | Non-invasive metering system for software licenses |
| US9430134B1 (en) | 2013-03-15 | 2016-08-30 | hopTo Inc. | Using split windows for cross-platform document views |
| US9292157B1 (en) | 2013-03-15 | 2016-03-22 | hopTo Inc. | Cloud-based usage of split windows for cross-platform document views |
| US10565026B2 (en) * | 2015-07-29 | 2020-02-18 | Microsoft Technology Licensing, Llc | Containing an application in an immersive non-windowed environment |
| US10735557B2 (en) * | 2016-01-08 | 2020-08-04 | Elo Touch Solutions, Inc. | Device controller and viewer |
| US11716558B2 (en) | 2018-04-16 | 2023-08-01 | Charter Communications Operating, Llc | Apparatus and methods for integrated high-capacity data and wireless network services |
| US10983811B2 (en) | 2018-06-03 | 2021-04-20 | Apple Inc. | Multi-process model for cross-platform applications |
| US11129213B2 (en) | 2018-10-12 | 2021-09-21 | Charter Communications Operating, Llc | Apparatus and methods for cell identification in wireless networks |
| US11129171B2 (en) | 2019-02-27 | 2021-09-21 | Charter Communications Operating, Llc | Methods and apparatus for wireless signal maximization and management in a quasi-licensed wireless system |
| US11026205B2 (en) | 2019-10-23 | 2021-06-01 | Charter Communications Operating, Llc | Methods and apparatus for device registration in a quasi-licensed wireless system |
| KR20230084722A (en) * | 2021-12-06 | 2023-06-13 | 엘지전자 주식회사 | Display device and operating method thereof |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2039027C (en) * | 1990-05-22 | 1998-07-07 | Stephen Troy Eagen | Method and apparatus for assisting in the presentation and removal of windows |
| US5327529A (en) * | 1990-09-24 | 1994-07-05 | Geoworks | Process of designing user's interfaces for application programs |
| US5450600A (en) * | 1991-11-08 | 1995-09-12 | Mitsubishi Denki Kabushiki Kaisha | Integrated command recognition apparatus and method for selecting an optimal command among numerous commands |
| US5475421A (en) * | 1992-06-03 | 1995-12-12 | Digital Equipment Corporation | Video data scaling for video teleconferencing workstations communicating by digital data network |
| US5375068A (en) * | 1992-06-03 | 1994-12-20 | Digital Equipment Corporation | Video teleconferencing for networked workstations |
| US5459860A (en) * | 1992-10-05 | 1995-10-17 | International Business Machines Corporation | Computerized system and process for managing a distributed database system |
| US5412772A (en) * | 1992-10-13 | 1995-05-02 | Novell, Inc. | System for permitting a view of an object or a user interface to be exchanged between operating system environments |
| WO1994014115A2 (en) * | 1992-12-01 | 1994-06-23 | Microsoft Corporation | A method and system for in-place interaction with embedded objects |
| US5361344A (en) * | 1993-01-29 | 1994-11-01 | Unisys Corporation | Method of operating, via a block mode terminal, UNIX programs for a character mode terminal |
| US5498003A (en) * | 1993-10-07 | 1996-03-12 | Gechter; Jerry | Interactive electronic games and screen savers with multiple characters |
| US5627979A (en) * | 1994-07-18 | 1997-05-06 | International Business Machines Corporation | System and method for providing a graphical user interface for mapping and accessing objects in data stores |
-
1995
- 1995-06-06 US US08/472,935 patent/US5831609A/en not_active Expired - Lifetime
- 1995-06-16 CA CA002152007A patent/CA2152007A1/en not_active Abandoned
- 1995-06-19 DE DE19522185A patent/DE19522185A1/en not_active Withdrawn
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7720672B1 (en) | 1995-12-29 | 2010-05-18 | Wyse Technology Inc. | Method and apparatus for display of windowing application programs on a terminal |
| US8079021B2 (en) | 1995-12-29 | 2011-12-13 | Wyse Technology Inc. | Method and apparatus for display of windowing application programs on a terminal |
| US8904362B2 (en) | 1995-12-29 | 2014-12-02 | Wyse Technology L.L.C. | Method and apparatus for display of windowing application programs on a terminal |
| EP1956492A3 (en) * | 1999-09-21 | 2010-10-13 | Wyse Technology | Displaying windowing application programs on a terminal |
Also Published As
| Publication number | Publication date |
|---|---|
| US5831609A (en) | 1998-11-03 |
| DE19522185A1 (en) | 1996-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5831609A (en) | Method and system for dynamic translation between different graphical user interface systems | |
| AU775740B2 (en) | A system and method for providing immediate visual response to user input at a client system | |
| CA2578094C (en) | Method and system for communicating and exchanging data between browser frames | |
| EP1214667B1 (en) | Methods and apparatus for efficiently transmitting interactive application data between a client and server using markup language | |
| CA2177801C (en) | A window management system having a class of always-visible windows | |
| US5758110A (en) | Apparatus and method for application sharing in a graphic user interface | |
| EP0597395B1 (en) | Multiple graphical user interface on a single display | |
| US7657837B2 (en) | Seamless windows functionality to remote desktop sessions regarding z-order | |
| US6587125B1 (en) | Remote control system | |
| US6268855B1 (en) | Method and system for sharing applications between computer systems | |
| US5982392A (en) | Replicating and refreshing graphic images on a remote workstation | |
| KR20040089600A (en) | Interacting with software applications displayed in a web page | |
| AU4312899A (en) | System and method for combining local and remote windows into a single desktop environment | |
| US20040049530A1 (en) | Distributed computer system using a graphical user interface toolkit | |
| US20030182469A1 (en) | Distributed computer system using a graphical user interface toolkit | |
| US20040260806A1 (en) | System supporting communication between a web enabled application and another application | |
| US20020080171A1 (en) | Method and apparatus for coordinating screen views in a collaborative computing environment | |
| KR100422679B1 (en) | Mixed contents server-client system | |
| WO2001061484A2 (en) | Method and system for controlling a complementary user interface on a display surface | |
| Katz et al. | Ulllted States Patent [19][11] Patent Number: 5,831,609 | |
| KR100555392B1 (en) | System and method for terminal control of application execution between client and server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |