AU2000256911A1 - Multi-user computer - Google Patents

Description

MULTI-USER COMPUTER

This invention relates to computers and in particular to home and office computers such as PCs. It is particularly concerned with PC s running Microsoft Windows 98 (RTM) operating system. The invention is applicable to other operating systems and to stand alone or networked computers . Existing computers such as stand alone PC s are intended to be used by a single person at a given time and are supplied from retail outlets with a single set of I/O devices (display, keyboard, mouse, etc.) Typically, software applications are initiated and interacted with by the user through graphics user interface (GUI) such as Windows '95 (RTM) or Windows ^Λ98 (RTM) . Methods to support multiple screens on a single PC are well known and additional software and hardware is required to reproduce the main display, or parts of the main display, on extra displays connected to the PC. It is well known that may P s can be placed on a network to run applications from a server computer . Modern PC s are sufficiently powerful to be able to run more that one application at the same time. However, at present, two separate computers are required if two users want to work at the same time.

We have appreciated that it would be desirable for a computer to have a number of I/O Devices which allow two or more users to run the same or different applications at the same time. For example, one user may, via a first keyboard, mouse and display, use a word processing application while a second surfs the Internet. It is therefore an aim of the present invention to provide a computer system which enables two or more users to run two or more applications as a computer at the same time.

It is a further aim of the invention to provide a computer operating system which allows two or more applications to be run concurrently with input and outputs to two or more sets of I/O devices.

In its broadest form the invention provides a personal computer or the like having at least two input devices and two displays and which can run two applications simultaneously, one on each of the displays with each of the displays being associated with an input device.

More specifically there is provided a personal computer comprising a processor under the control of an operating system and configurable to run a plurality of application programs, at least two input devices and at least two displays, each input device having an associated display, wherein the operating system includes means for two or more application programs at the same time, each application program being associated with one of the input devices and associated displays, and including means for identifying the input device from which data is input and directing that data to the associated application.

The invention also resides in a computer operating system for a personal computer having a processor configurable to run a plurality of application programs, at least two input devices and at least two displays, each input device having an associated display, the operating system comprising means for running at least two application programs at the same time, each of the application programs being associated with one of the input devices and associated displays, and means for identifying the input device from which data is input and directing that data to the associated application. Furthermore, the invention provides a computer program product stored on computer usable medium, comprising computer readable program means for causing of personal computer having a processor configurable to run a plurality of application programs, at least two input devices and at least two displays, each input device having an associated display to run at least two application programs at the same time on two displays, each of the application programs being associated with one of the input devices and associated displays to identify the input device from which data is input, and to direct that data to the associated application. The invention further resides in a method of operating a computer having a central processor under the control of an operating system and configurable to run a plurality of application programs, at least two input devices and at least two displays, each input device having an associated display, the method comprising running at least two application programs at the same time on different displays, associating each of the at least two application programs with one of the input devices and associated displays, identifying the input device from which data is input and directing that data to the associated application.

Preferably, the operating system includes a shell program including means for identifying the application to be launched, means for identifying the displays from which the application was launched and means for creating a handle for that application which includes an identification of the displays on which it is running.

This preferred embodiment of the invention has the advantage that in a Windows operating system the custom shell may be set as the shell in the system.ini file allowing a separate desktop per display.

Preferably the operating system includes a dynamic link library including a user link for communicating calls between the input devices and the applications, the user link being embedded in a dynamic link program for filtering data input from the input device to maintain focus to a given application running on a given display when data is input to a different application running on a different display from a different input device.

This embodiment of the invention has the advantage that all input from the keyboard and access to the graphical user interface by changing the user= and Gdi= settings in the system.ini file to custom versions which filter the required functions before passing them onto the user. exe and Gdi . exe files. This enables data to be sent to an application running on a second screen without the application running on the first screen to which data was previously sent, losing focus.

Preferably, the system further includes a graphical user interface (GUI), and the dynamic link library further includes a graphical display interface link Gdi, for communicating between the displays and the applications, the Gdi being embedded in a dynamic link program for filtering access to the GUI to maintain focus to a given application running on a given display when data is input to a different display running a different application.

This embodiment of the invention has the advantage that information about the desktop can be filtered when an application makes queries about it so avoiding the problem of dragging application windows overlapping one another on a second screen.

Preferably, the computer further comprises a plurality of buses and the least two input devices are coupled to different ones of said buses .

It is preferred that one of these buses includes a Universal Series bus. A keyboard plugged into the Universal Series bus will provide untranslated keyboard data to the application and it is preferred that data detected as having been supplied from an input device connected to the USB is first passed through the keyboard dynamic link for translation.

Embodiments of the invention will now be described, will reference to the accompanying drawings in which:

Figure 1 is a schematic view of portions of a known personal computer running the Windows ^λ 98 operating system;

Figure 2 is a similar schematic view to figure 1 showing an embodiment of the invention^'; Figure 3 is a schematic view of the hardware configuration of the embodiment of the invention; Figure 4 is a block diagram showing how data from a keyboard is handled;

Figure 5 is a flow diagram showing how a custom shell program launches an application program; Figure 6 is a schematic view similar to figure 1 of a second embodiment of the invention; and

Figures 7a and 7b are flow diagrams illustrating operation of the second embodiment.

Referring to figure 1 a conventional personal computer comprises a main processor, random access memory, a read only memory such as a hard disc, input devices including a keyboard and a mouse and other pointer, an output device such as a display and a printer. Applications to be run reside on the hard disk and are loaded into the RAM as required under the control of a disc operating system such as MS-DOS sold by Microsoft Corporation. Typically, a graphical user interface such as Microsoft Windows 98 is interposed above the disc operating system to enable the user to send commands to the processor by manipulating at a pointing device across the display rather than having to type in complex commands .

In figure 1, the keyboard is shown as PS/2 compliant

'keyboard 12 and the pointer as PS/2 compliant mouse 14.

These two physical devices are managed by virtual device drivers of which VKD 16 is a keyboard driver and VMD 18 is a mouse driver. The purpose of the device driver is to handle communications between the device and the processor.

The disk operating system is shown as DOS boxes 20, 22 and the Windows ^x98 GUI generally shown as box 24. The GUI includes drives for each of the I/O devices including keyboard. drv. driver 26, mouse. drv 28 and display, drv 30.

These drivers interact with the virtual device drivers 16,

18.

The GUI contains a suite of execution programs Explorer.exe 32. This suite contains execution programs which cause the computer to run a selected application. In figure 1 a sample three execution programs are shown as Appl.exe 34, App2.exe 36 and App3.exe 38. Logically interposed between the application execution programs are the user. exe 40 and Gdi . exe 42 programs. These are execution programs from the dynamic link library. User. exe receives keyboard and mouse commands from the keyboard and mouse drivers and assigns these, as appropriate. Gdi. exe handles data to be displayed communicating with display. drv.

It will be appreciated that figure 1 only shows the elements of the operating system and GUI necessary to launch an application. All other features of the operating system and the GUI are well known to those skilled in the art and do not need further explanation.

The procedure to launch an application will now be described. When a user double clicks on an icon on the display, or starts a program from the menu, the Explorer.exe shell 32 launches the application through the appropriate app.exe program. When the application has started, the Explorer.exe shell 32 makes calls to Gdi . exe 42 to determine the display screen size and resolution. The shell then creates the appropriately sized windows. The application then looks for inputs from the keyboard and mouse input devices by making GetMessage calls to user. exe 40. GetMessage simply asks user. exe whether there has been any keyboard/mouse input and, if so, retrieves that input. The GetMessage call will be blocked unless two conditions have been met. First, the current application must have focus. Although Windows ^λ 98 allows a number of applications to run at the same time, the processor will only attend to one of these at any given time. This is the application that has focus and all incoming messages from the input devices are treated as intended for that application. The application with focus appears as the active window to the user. The second condition is whether there is any data in the input queue. If both these criteria are true, the GetMessage routine returns with the keyboard data. That data flows from the keyboard, through the virtual keyboard driver VKD 16 and through the keyboard. drv in Windows ^Λ 98, at which point the keyboard codes are translated. The translated codes are then passed to user. exe and then to the application.

All mouse events are sent to user. exe via the virtual mouse driver VMD 18 and the mouse driver in Windows '98. Mouse events are then passed to the window which the mouse is entering, leaving or moving over. If there are two users, the applications see mouse enters and leaves instead of mouse enter, mouse move, mouse move etc.

Figure 2 shows how the model of figure 1 may be modified to provide two users running two applications simultaneously under a singe version of the DOS and Windows '98 operating system. In order to understand figure 2 it is helpful to consider why the model of figure 1 cannot be made to support two independent users running two separate applications.

Windows ^λ98 has the capacity to display all applications over several display screens. However, if two different applications were to be displayed there is no way of knowing on which display it was first started. Thus, the prior art model does not provide for the association of an application with a display.

In any of the Windows operating systems such as Windows 3.x, Windows ^λ 95 and Windows ^λ 98 the user can open several applications at the same time but only one application can have focus at any one time. The user can switch between applications, for example by clicking on the relevant icon on the taskbar in Windows 98 and that application will gain the focus. The keyboard focus transfers from the current application to the new application. This causes problems on the second screen as the user at a second screen will take the focus from the first screen when selecting an item running in their desktop area. This prevents the user on the first screen from inputting further data.

With the present arrangement, dragging an application window will overlap onto the other screen. A user can select an application and drag it across to the other screen affecting the user of the other screen. This happens as the two or more screens are treated by the operating system as displaying portions of the same desktop. Thus, as an application window is dragged around the desktop it can be crossed over from one display to the next. The Windows ^λ98 system only has the idea of a single mouse. This is incompatible with two applications running simultaneously each of which may try to- get the position of the mouse. Of course in some applications a mouse is no-t essential or required, for example where the displays are touch screens.

Some applications only allow one instance of the application to be run. If a second instance is run, for example when the two users both want to run the same application independently of each other, the second version of the application will see that the first already exists and sets the focus to the first application.

Existing PCs and the like only have provision for a single keyboard and pointer device.

In figure 2, items already referred to in relation to figure 1 are given the same reference number. In short, the embodiment of the invention adds a further set of input devices. In the preferred embodiment shown these comprise a USB keyboard 40 and a USB mouse 42. An additional Virtual device driver is included. In this case VUSBD 44 which provides a virtual device driver from the USB keyboard and the USB mouse. In Windows 98 the user. exe is surrounded by a custom shell shown as XNUSER.EXE 46 and Gdi . exe is surrounded by a custom shell shown as XNGDI.exe 48. The purpose of these two shells will be explained. Finally, the explorer.exe shell is replaced by a new shell XNSHELL.exe 50 which is a version of explorer.exe modified in view of XNUSER.exe and XNGDI.exe.

Before discussing the software in further detail it is useful to consider the hardware necessary to run different applications as different screens. Although Windows '98 can support two displays, existing hardware architecture cannot.

Our co-pending application PCT/GB99/02854 discloses how multiple screens may run from a conventional PC running under, for example, Windows ^Λ98. Figure 3 shows the hardware configuration required to provide a separate display, keyboard and mouse for each independent user. In essence, PCT/GB99/02854 contemplates providing second and further displays by connecting one or more display controllers to a dedicated graphics bus such as the AGP (accelerated graphics port) bus. Referring to figure 3 the processor 60, which may for example be a Pentium II (TM) processor manufactured by Intel Corporation is connected to the system or CPU bus 64. The CPU bus may operate at, for example, 66, 75, 83 or 100 MHz and at I/O voltages of 3.3V, 2.5V or 1.9V. A second level cache memory and the system chipset 62 are also connected to the CPU bus 64. The system chipset comprises a pair of chip sets forming a north south bridge. One example of a suitable chipset is the VIA Apollo MVP3 chipset available from Via Corporation. This is a high performance and energy efficient chipset intended for implementation of AGP, PCI and ISA buses in PC systems from 66 MHz to 100 MHz based on the 64 bit Socket-7 Super-Scalar processors. Both the north and south bridges act as routers routing data from one bus to another. The north bridge takes the heavy traffic and the south bridge routes in to a lot of different lighter traffic. As can be seen from figure 4, the north bridge, comprising chip VT82C598, identified by numeral 63, is connected via memory bus 66 to the dynamic random access memory DRAM 68 and also to the AGP bus 70. The PCI (peripheral component interconnect) bus 72 is connected between the north and south bridges and the south bridge, implemented here as chip VT82C58CB identified by reference numeral 65, is connected to the keyboard and mouse, the USB (Universal Serial Bus) bus, the DPID, IDE and ISA (Industry Standard Architecture) buses. It will be seen that the south bridge also acts as a PCI to ISA bridge. The PCI bus is one example of a general purpose bus which routes data to and from the processor and peripherals on the system. The AGP bus relieves the PCI bus of graphics data to enable it to concentrate on duties such as transfer of data from disc drives. Thus, the AGP bus is a graphics bus which is intended to perform a dedicated graphics function and is connected to a 3D graphics controller (not shown) . On a conventional PC, a device on a single card can be attached to the AGP bus whereas up to four expansion slots can be attached to the PCI bus. The addressing for these additional devices is controlled by the systems BIOS (Basis Input/Output Software) which is held in ROM and once set cannot be changed.

The north bridge chip supports standard fast pulse mode (FPM) , extended data output (EDO), SDIM and DDR SDRAM. The system controller also complies with Accelerated Graphics Port specification 1:0 and supports 66/75/83/100 MHz CPU frequencies and 66 MHz AGP bus frequency. The PCI integrated peripheral controller forms a part of the chipset and supports Intel and non-Intel based processors to PCI bus bridge functionality to make a complete Microsoft PC97 compliant PCI/ISA system. The peripheral controller provides ISA extension bus functionality and includes a number of intelligent peripheral controllers including a master code IDE (Illustrated Drive Electronics) controlled with dual channel DMA (Direct Memory Access) engine and interlaced dual channel commands. High performance transfers between devices connected to the PCI and IDE buses can be achieved through a dedicated FIFO coupled with scatter and gather master mode operation. Further intelligent peripheral controllers includes a USB controller; a keyboard controller with PS2 mouse support; a real time clock with 256 extended bite cmos; power management functionality which is compliant with ACPI (Advanced Configuration and Power Interface) and legacy APM (Advanced Power Management) requirements; distributed DMA capacity for support of ISA legacy DMA over the PCI bus; plug and play control allowing steerability of all interrupts on the PCI bus to any interrupts channels; three additional screenable interrupt channels are provided to allow plug and play and reconfigurability of on-board peripherals for Windows compliance and external IOAPIC support is provided for link-compliant symmetrical mount processor systems. In figure 3 the bios ROM 74, is shown attached to the south chip 65 and a first display controller 76 is attached to the PCI bus. An MPEG 2 decoder is also attached to that bus and a second display controller 80 is attached to the AGP bus. The AGP display controller 80 is also attached to the MPEG 2 decoder and to an external memory 82.

Although not shown, the hardware includes a hard disc drive and input devices such as a floppy disc drive, a CD- Rom drive and a DVD drive .

In order to provide an additional keyboard and mouse for a second user without affecting the existing PS/2 mouse and keyboard that is currently installed, a USB keyboard and mouse is attached to the USB bus, 84. By using the USB port on a conventional PC and plugging into a hub to give four ports to the USB both a USB and mouse and keyboard can easily be accommodated. In figure 3 the USB is identified by reference numeral 84, the USB hub by 86, the USB keyboard by numeral 88 and the USB mouse by numeral 90.

Referring back to figure 2, applications are launched by xnshell.exe which is configured to be able to determine which screen/user has initiated the application launch. Xnshell.exe then communicates with xnuser.exe and xngdi.exe to monitor all events that the application makes. When the application makes calls to xngdi.exe to determine screen size and origin, it returns restricted information that ties that application to the single screen on which it is running. When calls are then made to xnuser.exe, GetMessage calls xnuser to check the associated keyboard for data. If the associated keyboard is the default keyboard, processing will continue as usual. If the associated keyboard is the second keyboard, data from the USB keyboard will be used. Data received from the USB keyboard is reflected back into the standard keyboard driver for international translation before being passed back to the application.

Mouse notifications to xnuser.exe from the two mice will be capped to the relevant screen dimensions and passed on to the Gdi . exe for screen processing of mouse pointers.

Messages sent by user. exe to the application are handled by xnuser . exe .

To avoid the problem of focus being lost at one application when the second user clicks on an application, xnuser.exe filters out SetFocus messages which otherwise change which application has the keyboard focus. However, xnuser.exe allows a set focus call between applications in the same screen desktop area.

To an application, xnuser.exe looks the same as user. exe. In other words, the xnuser.exe shell is transparent to the application. Most calls will go straight through xnuser.exe but when focus changes, key data is obtained from the second keyboard device.

The user. exe and Gdi. exe are both examples of dynamic links from the dynamic link library (DLL) within Windows 98. The additional shells xnuser.exe and xnGdi.exe are also DLL programs which form an outer layer for user. exe and Gdi . exe respectively forming two layers of programming. User. exe and Gdi . exe may be viewed as embedded in xnuser.exe and xnGdi.exe respectively.

Xnshell monitors all calls that the applications make and communicates with the xnuser.exe and xnGdi.exe shells. Xnshell.exe assigns a handle to all application communication calls, the handle containing a code identifying the application making the call. The call including the handle is passed to the appropriate DLL shell, xnuser.exe or xnGdi.exe. The outer layer shell strips off the handle and retains it but passes the call to the inner DLL such as user. exe or Gdi . exe . The call is then processed in the same way as in the prior art. In this manner, xnshell is wholly transparent to the call itself but the handle enables xnshell to determine to which application a call relates thus enabling xnshell to determine which of the input devices it should look for data.

Calls returning from applications or input devices are transferred from the inner layer DLL programs to the outer layer DLL shells such as xnuser.exe. The outer layer reattaches the handle to the call and then passes it to xnshell.exe. Xnshell.exe reads the code in the handle and then determines to which of the applications the call is to be forwarded. Windows ^λ 98 has a pre-emptive multi-tasking doctrine allowing several applications to make use of a single DLL program at the same time. This means that the same DLL program may be called by different applications while still communicating with another application. Each call is prioritised and/or allocated a time slice of the DLL program' s run time .

The addition input devices, USB keyboard and USB mouse are provided with separate virtual device drivers. In figure 2 these are shown as the VUSBD but it will be understood that they comprises separate keyboard and mouse drivers. This ensures that the additional keyboard and mouse do not affect other devices. It is preferred that the additional input devices use the USB bus as USB drivers and ports are now common and compliant peripheral devices are inexpensive. Furthermore, the USB currently allows for up to 128 devices to be attached to it without additional hardware or software. However, the additional input devices could be attached in other ways.

The user keyboards and mice are configured to be linked to their associated display. The custom shell xnshell.exe and DLL programs use a register entry to determine which keyboard is assigned to which display. All new keyboards will present their keyboard number to xnuser.exe so that it can identify which keyboard is sending data. Xnshell.exe communicates to xnuser.exe to which handle the data belongs. This information is provided to xnshell.exe by the register. Thus, when a first user starts an application by double clicking an icon on its screen or with a keyboard command, xnshell.exe can determine that the application is initiated on that given screen, xnshell.exe knows which keyboard is associated with that screen from the register data and informs xnuser that that application has started and is using that keyboard. As a result, data from that keyboard will be transferred to that application whilst that application has focus on that screen. Data from a standard PS/2 keyboard will be translated into international key codes when it arrives at xnuser. Data from the additional USB keyboard/keyboards attached to the system will arrive via direct communications from the keyboard itself. This data will need to be translated at the xnuser stage before it is passed on to the application. This is achieved by xnuser.exe passing the data from USB keyboards through the keyboard DLL for translation before it is passed on to the application.

Figure 4 is useful in understanding how xnuser.exe handles keyboard inputs. At step 100, xnuser.exe receives a key press notification. Xnuser at step 102 decides whether the keyboard is a standard PS/2 compliant keyboard. If it is, the screen handler for the keyboard is obtained at step 104. The keystroke data is then passed at step 106 to the application within the screen which has focus. If xnuser identifies the keyboard as being standard it passes the key data at step 108 to the keyboard DLL for translation and then at step 110 obtains the screen handler for that keyboard and passes the key to the application within the screen which has focus at step 106.

Figure 5 shows how xnshell.exe handles launch of a program. In the prior art, program launch is handled by explorer.exe which needs a double click on an icon on the screen and selects the application which is associated with that icon. At step 120 in figure 5 the user double clicks the desktop icon. At step 122 xnshell.exe works out from which screen the icon has been double clicked. At step 124 xnshell.exe notifies the two upper level DLL programs xnuser.exe and xnGdi.exe of the application handle and the screen on which it is running. At step 126 xnshell.exe then allows the application to run in the same way as under explorer.exe. In the system described, each screen has a separate desktop. Windows ^λ 98 is a 32 bit system but at the driver level is a 16 bit operating system and uses the features in system.ini of previous versions of Windows such as Windows ^x 95 and Windows 3.1. The default shell run at startup comes from this file in the form of a setting "shell equals". In Windows ^Λ98 this setting is set to explorer. By changing this setting to "custom", that is the xnshell it is possible to generate a separate desktop for each screen.

The system.ini program also contains the settings for user=user . exe and Gdi=Gdi.exe. Again, by changing the setting to xnuser.exe and xnGdi.exe, the custom DLL's, xnuser.exe and xnGdi.exe can be set up to filter all inputs from the keyboard and the mouse as well as access to the GUI before passing them on to user. exe and Gdi. exe respectively. Thus, the problem of a user losing focus when an input is received from a second user is avoided as xnuser.exe identifies that second input as relating to a second screen. However, xnuser.exe does not interfere with user. exe changing focus when there is an input to a different application being run by the same user.

Similarly, the problem with dragging application windows overlapping onto the other screen is avoided by use of the xnGdi.exe DLL making it possible to filter information about the desktop when an application makes queries about it.

The problem with a single mouse in Windows ^x98 is also overcome by the use of xnuser.exe routine as all mouse notifications within Windows ^λ98 are passed to user. exe. Thus, all mouse notifications will be received by xnuser.exe which can filter/change the information which is reported to the application as necessary. Figure 6 illustrates a second embodiment of the invention which is intended to be more simple that the embodiment described. Whereas the previous embodiment allowed control of the desktop by two or more users, the figure 6 embodiment permits control of applications rather than the desktop. In the embodiment to be described, commands may be entered either from a second keyboard or from a second touch screen.

In the previous embodiment, use was made of the Explorer Shell which was replaced by an XNshell. In the figure 6 embodiment the Explorer shell is retained and a separate program, XNPUMP.exe used to launch the application to be controlled by the second user. XNPUMP.exe then behaves as a shell within the Explorer shell and, once launched, can control the running of the application or other program.

In the previous embodiment, XNUser.exe and XnGdi.exe were dll routines. In the figure 6 embodiment XNPUMP.exe is used to redirect keyboard input from the second keyboard, as touch screen input to edit controls within the application program to be controlled from the second input device. XNPUMP achieves this by searching the window tree of the controlled program for all edit controls and the redirecting the second keyboard or touch screen input to the edit window which last had the focus . In the previous embodiment, new keys were forced through the default keyboard driver to obtain keyboard mapping. In the figure 6 embodiment, a look up table is employed by XNPUMP. The look up table contains translation codes from keyboard scan codes to windows keyboard codes . Turning now to figure 6, features common to figures 1 or 2 and 6 have the same reference numerals. The additional USB keyboard 40, USB mouse 42 and VSB drivers USBD 44 are provided but instead of explorer.exe being replaced by XNShell.exe, and user. exe and Gdi. exe being enclosed within XNUser.exe and xnGdi.exe respectively, the application to be launched is simply enclosed within XNPUMP.exe. Thus, figure 6 shows application Appl.exe as being launched. Application 2 has not been launched and is therefore not enveloped by XNPUMP.exe. By placing a wrapper around the program running on the second screen one can control what is sent to it and the ability to send the second keyboard data. For a second user to launch an application from the second scree, XNPUMP.exe is first launched within that second screen. The user then uses XNPUMP.exe to launch Explorer.exe (not shown in figure 6) . XNPUMP.exe then makes explorer one of its children using the windows SetParent call so that Explorer is running within XNPUMP. XNPUMP can then look for edit controls within explorer and subclasses those edit controls 82 so that it has control over those edit controls. When a user selects the control with the mouse, XNPUMP will note which control has gained focus and then returns focus to the control that has just lost it.

XNPUMP can then force keyboard input using the WM_CHAR, WM_KEYDOWN and WM_KEYUP messages into the edit control with data that is read from the second keyboard device.

Figures 7a and 7b illustrates, in flow diagram form, the operation of the second embodiment. A separate thread is created for each keyboard. At step 200 in figure 7a, a thread is created for a given keyboard, keyboard n. At step 202, the system waits for the user, from that keyboard, to select a new program for launch. At step 204, with a new program selected, the applications message queue is hooked and at step 206 the system waits for the application to make a request to the GetMessage routine. In a conventional system an application will call the operating system for instructions. In the method described the applications message queue is hooked so tht calls to the operating systems are diverted to the wrapper XNPUMOP. The calls to the operating system may then be examined and passed onto the system as usual or, if there is keyboard data from the n keyboard thread that data can be forced to the application. Thus, figure 7b shows how data input from a given keyboard is handled. At steps 214 the relevant keyboard thread opens the keyboard, there being a keyboard thread for each keyboard. At step 216, the program looks for input from that keyboard. If there is no input, the routine simply loops around until keyboard input is detected. If there is keyboard input, that input is translated at step 218, using the look up table referred to previously such that the input key codes, which may for example be ASCII codes, are translated into MS Windows ® codes. Finally, at step 330 the translated key data is stored in the keyboard queue. Although this embodiment has been described with reference to input from a second keyboard, it is to be understood that the second user may input data from a second touch screen with the first device either being a touch screen or a physical keyboard. The manner of operation is the same whichever us used.

It will be seen that the embodiment of figures 6 and 7 is much more simple than that of the previous embodiment and does not change the core configuration of the machine. As a result, there are less side-effects with the rest of the operating system.

Embodiments of the invention have the advantage that two or more users can run their own applications on the PC at the same time. This is ideal for a family or office environment and can greatly reduce the overheads of computer hardware systems. Embodiments of the invention allow two web browsers to be run at the same time whilst using a single phone line, in countries where Internet access calls are charged this can save considerable call charges.

Claims (41)

1. A personal computer comprising a processor under the control of an operating system and configurable to run a plurality of application programs, at least two input

5 devices for inputting data and commands to the processor and at least two displays, each input device having an associated display, wherein the operating system includes means for running two or more application programs at the same time, each application program being associated with 10 one of the input devices and associated displays, and including means for identifying the input device from which data and commands is input and directing that data to the associated application.

2. A personal computer according to claim 1, wherein 15 the input device associated with each display includes a keyboard.

3. A personal computer according to claim 2, wherein the input device associated with each display further includes a mouse.

20 4. A personal computer according to claims 1, 2 or 3, wherein the input device associated with at least one display comprises a touch screen.

5. A personal computer according to any of claims 1 to 4, wherein the operating system includes a shell program including means for identifying the application to be launched, means for identifying the display from which the application was launched and means for creating a handle for that application which includes an identification of the displays on which it is running.

(') 6. A personal computer according to any of claims 1 to 5, wherein the operating system includes a dynamic link library including a user link for communicating calls between the input devices and the applications, the user link being embedded in a dynamic link program for filtering data input from the input device to maintain focus to a given application running on a given display when data is input to a different application running on a different display from a different input device.

7. A personal computer according to claim 6, wherein the filtering link program filter data inputs from keyboard and mouse inputs.

8. A personal computer according to claim 6 or 7, wherein data from the input device to the user dynamic link passes transparently through the filtering dynamic link.

9. A personal computer according to any of claims

6, 7 or 8 wherein the system further includes -a graphical user interface (GUI), the dynamic link library further includes a graphical display interface link Gdi for communicating between the displays and the applications, the Gdi being embedded in a dynamic link program for filtering access to the GUI to maintain focus to a given application running on a given display when data is input to a different display running a different application.

10. A personal computer according to claim 9, wherein data from the applications to the Gdi dynamic link is passed transparency through the filtering dynamic link.

11. A personal computer according to any of claims 1 to 3, wherein the operating system includes a wrapper for an application to be launched form the second display, the wrapper including means for redirecting data and commands from the second input device to edit controls within the application launched from the second display.

12. A personal computer according to claim 11 wherein the wrapper includes means for searching the window tree of the controlled application to find edit controls and means for redirecting the second input device input to the edit window which last had focus.

13. A personal computer according to claim 11 or 12, comprising a plurality of displays each having an associated input device, wherein each display after the first has an associated wrapper for launch of applications from that wrapper.

14. A personal computer according to any preceding claim, wherein the computer further comprises a plurality of buses and the least two input devices are coupled to different ones of said buses.

15. A personal computer according to claim 14, wherein one of said plurality of buses comprises a universal series bus (USB) .

16. A personal computer according to claim 15, further comprising a USB port.

17. A personal computer according to claim 14 or 15 and 6 comprising translation means for translating data received at the user dynamic link from the input device connected to the USB.

18. A computer operating system for a personal computer having a processor configurable to run a plurality of application programs, at least two input devices and at least two displays, each input device having an associated display, r-he operating system comprising means for running at least two application programs at the same time, each of the application programs being associated with one of the input devices and associated displays, and means for identifying the input device from which data is input and directing that data to the associated application.

19. A computer operating system according to claim 18, wherein the input devices associated with each display comprises a keyboard, the system further comprising a shell program for launching a selected application, the shell program including means for identifying the display from which the application was launched, and means for creating a handle for that application which includes an identification of the display on which it is running.

20. A computer operating system according to claim 18 or 19, comprising a dynamic link library including a user link for communicating calls between the input devices and the applications, the user link being embedded in a dynamic link program for filtering data input from the input device to maintain focus to a given application running on a given display when data is input to a different display.

21. A computer operating system according to claim 20 wherein, the filtering link program filters data inputs form keyboard and mouse input devices.

22. A computer operating system according to claim 20 or 21, wherein the data from the input device to the user dynamic link passes transparently through the filtering dynamic link.

23. A computer operating system according to claim 20, 21 or 22 including a graphical user interface (GUI), wherein the dynamic link library further includes a graphical display interface link Gdi for communicating between the displays and the applications, the Gdi being embedded in a dynamic link program for filtering access to the GUI to maintain focus to a given application running on a given display when data is output to a different display running a different application.

24. A computer operating system according to claim 23 wherein data from the applications to the Gdi dynamic link

5 pass transparently through the filtering dynamic link.

25. A computer operating system according to any of claims 20 to 24 wherein the computer further includes a plurality of buses, and the at least two input devices are coupled to different buses, the operating system further

10 comprising translating means for translating data received at the user dynamic link from the input device connected to one of the buses.

26. A computer operating system according to claim 18, further comprising a wrapper for an application to be

15 launched from the second display, the wrapper including means for redirecting data and commands from the second input device to the edit controls within the application launched from the second display.

27. A computer operating system according to claim 20 26, wherein the wrapper includes means for searching the window tree of the controlled application to find edit controls and means for redirecting the second input device input to the edit window which last had focus .

28. A computer operating system according to claims 25 26 or 27 comprising a plurality of displays each having an associated input device, wherein each display after the first has an associated wrapper for launch of applications from that wrapper.

29. A computer operating system according to claim 25 "-o wherein the one bus is a Universal Serial Bus (USB)

30. A computer program product stored on computer usable medium, comprising computer readable program means for causing of personal computer having a processor configurable to run a plurality of application programs, at

5 least two input devices and at least two displays, each input device having an associated display to run at least two application programs at the same time on two displays, each of the application programs being associated with one of the input devices and associated displays to identify the 0 input device from which data is input, and to direct that data to the associated application.

31. A computer program, comprising computer readable program means for causing of personal computer having a processor configurable to run a plurality of 5 application programs, at least two input devices and at least two displays, each input device having an associated display to run at least two application programs at the same time on two displays, each of the application programs being associated with one of the input devices and associated 0 displays to identify the input device from which data is input, and to direct that data to the associated application .

32. A computer program product according to claim 30 or 31, further comprising a shell program for causing the 5 computer to launch a selected application, to identify the display from which the application was launched, and to create a handle for that application which includes an identification of the displays on which it is running.

33. A computer program product according to claim 32 υ further comprising a dynamic link program for causing data input from an input device to a user dynamic link in the computer operating system to be filtered to maintain focus to a given application running on a given display when data is input to a different display.

34. A method of operating a computer having a central processor under the control of an operating system and configurable to run a plurality of application programs, at least two input devices and at least two displays, each

5 input device having an associated display, the method comprising running at least two application programs at the same time on different displays, associating each of the at least two application programs with one of the input devices and associated displays, identifying the input device from 0 which data is input and directing that data to the associated application.

35. A method of operating a computer according to claim 34, comprising launching an application from a shell program including identifying the application to be 5 launched, identifying the display from which the application was launched and creating a handle for that application which includes an identification of the display on which it is running.

36. A method of operating a computer according to 0 claim 35, comprising providing a dynamic link surrounding the operating system user dynamic link communicating calls between the input devices and the applications, and filtering data input from the input devices to maintain focus to a given application running on a given display when 5 data is input to a different display, the data passing transparently through the filtering dynamic link to the user dynamic link.

37. A method of operating a computer according to claim 36, wherein the filtering dynamic link filters out i. SetFocus messages when data is input to a different display.

38. A method of operating a computer according to claim 36 or 37, comprising providing a dynamic link surrounding the operating system graphical display interface dynamic link Gdi communicating between the displays and the applications, and filtering access to the graphical user interface to maintain focus to a given application running on a given display when data is input to a different display, the data passing transparently through the filtering dynamic link to the Gdi dynamic link.

39. A method of operating a computer according to claim 38, wherein the filtering dynamic link filters out SetFocus messages when access is requested to a different .display.

40. .A method of operating a computer according to claim 34, comprising launching a wrapper within the second display for the application to be run within the second display, and launching the application to be run within the second display within the wrapper, the wrapper redirecting data and commands from the second input device to edit controls within the application launched within the second display.

41. A method of operating a computer according to claim 40, comprising launching an application shell from the wrapper, setting the application shell as the child of the wrapper, searching for edit controls within the application shell and gaining control over the edit controls found by the search.