DE3855289T2

DE3855289T2 - Maus-Zeiger mit umschaltbarem Emulations-Betriebsmodus

Info

Publication number: DE3855289T2
Application number: DE3855289T
Authority: DE
Inventors: Ronald D Hansen; Abdo George Kadifa; Clayton Wai Mock
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1987-06-30
Filing date: 1988-06-22
Publication date: 1996-11-28
Anticipated expiration: 2008-06-23
Also published as: JPH06100956B2; DE3855289D1; JPS6426923A; EP0297772A2; US4859995A; EP0297772B1; EP0297772A3

Description

Die vorliegende Erfindung betrifft ein System für einen interaktiven Computer, der eine Anzeige mit einem durch ein Zeigersteuer-Eingabegerät wie einer Maus gesteuerten Zeiger besitzt. Insbesondere betrifft die Erfindung ein System zum Steuern des Zeigers, um einen Zeiger in einem System zu emulieren, das gerade emuliert wird.
Die Xerox 6085-Workstation ergibt eine Emulation eines IBM-PC in einem Fenster, wie in den anhängigen US-Patentanmeldungen SN 856 525 und 856 526 (hier später "die Workstation-Anmeldungen" genannt) beschrieben ist. (Eine Kopie dieser beiden US-Patentanmeldungen wurde dem EPA am Einreichungstag der vorliegenden Anmeldung zugeleitet und steht in der Anmeldungsakte zur öffentlichen Einsicht zur Verfügung. SW 856 525 wurde am 6.2.1990 als US-A-4 899 136 veröffentlicht. SW 856 526 wurde als Prioritätsunterlage für die am 31.12.1991 veröffentlichte CA-A-1 293 817 verwendet.) Mit anderen Worten, der Benutzer kann eine Anzeige erhalten, die ein PC-Emulationsfenster enthält, das ein Bild zeigt, wie es an dem Bildschirm eines PC erscheinen würde. Dieses Bild ist begründet auf Betätigungen eines Emulations-Koprozessors, der seine Ausgangssignale dem Host-System zuleitet und seine Eingangssignale von diesem erhält. Der Benutzer kann mit der Workstation in Wechselwirkung eintreten, als ob sie ein PC wäre, und die Anzeige im Emulations-Fenster wird entsprechend durch den Emulator aktualisiert. Daten vom Benutzer und von anderen Quellen werden dem Emulator durch eine Datenstruktur in einem für den Emulator zugriffsfähigen und dem Grund-Eingabe/Ausgabe-System (Basic input/Output System (BIOS)) des PBM-PC zugeordneten Speicherraum zugeführt. Die in den Workstation-Anmeldungen beschriebene Workstation enthält eine Maus zum Steuern eines Zeigers oder Cursors in der Anzeige und, wie bemerkt, kann die Maus benutzt werden, um eine bei einem IBM-PC benutzte Maus zu emulieren.
In der von B.A. Myers und W. Buxton in Computer Graphics: SIGGRAPH '86 Conference Proceedings, Dallas, TX, 18.-22. August 1986, Seiten 249-257 mit dem Titel "Creating Highly-Interactive and Graphical User Interfaces by Demonstration" veröffentlichten Arbeit wird ein System zum Schaffen einer Benutzer-Schnittstelle beschrieben, bei dem eine in Fig. 3f und 5 gezeigte simulierte Maus benutzt wird, um einen durch die geschaffene Schnittstelle angezeigten Zeiger darzustellen. Der Ausleger einer geschaffenen Schnittstelle besitzt auch einen Zeiger, der unter Beeinflussung durch die tatsächliche Maus in dem System steht. Die simulierte Maus ist einem Icon gleich und kann dadurch bewegt werden, daß man mit der tatsächlichen Maus auf ihre Nase zeigt. Die simulierte Maus besitzt auch Knöpfe, die durch Anzeigen und Anklicken eines Knopfes an der aktuellen Maus geschaltet werden können.
R. Krishnamurty und T. Mothersole beschreiben in einem Aufsatz "Coprocessor Software Support" in IBM RT Personal Computer Technologie. IBM Corporation Form Nr. SA12- 057, 1986, Seiten 142-146, ein System, bei dem ein Koprozessor benutzt wird, um einen IBM AT PC zu emulieren. Fig. 3 zeigt, daß eine als ROMP bezeichnete Systemmaus enthalten sein kann, die jedoch nur für den Host-Prozessor verfügbar ist.
US-A-4 586 035 beschreibt ein interaktives Anzeigeterminal mit mehreren überlappenden Fenstern. Einige Fenster besitzen zugeordnete virtuell verteilte Menüs, die normalerweise nicht angezeigt werden. Wenn der Benutzer einen durch eine Maus gesteuerten Cursor über einen ausgewählten Bereich einer Fensterperiphene bewegt, wird ein diesem Bereich zugeordnetes ausgewähltes Menu angezeigt.
US-A-4 101 879 beschreibt ein Cursorbewegungs-Steuergerät für eine segmentierte Bildschirm-Anzeigevorrichtung. Der Cursor wird Zeile um Zeile in jedem Abschnitt durch ein von dem Datenanzeigeprogramm unabhängiges Gerät an einem externen Computer bewegt. Das Cursorbewegungs-Steuergerät enthält Register zum Speichern der Adressen der ersten und letzten Position jedes durch Cursor angezeigten Abschnitts des segmentierten Schirms. Die Register werden so gesteuert, daß die der Position des Cursors entsprechenden Daten in den Registern mit den Adressen der ersten und der letzten Position verglichen werden, um den Cursor Zeile um Zeile in dem Abschnitt zu bewegen.
US-A-4 625 202 beschreibt eine Technik zum Erzeugen mehrerer Cursoren in einem mehrdimensionalen Graphikanzeigesystem. Jede Dimension hat einen Bereich von Adressen, die Orten in dieser Dimension entsprechen. Der Cursor wird durch Schaffen von Definitionssignalen präsentiert, die jeweils Orte längs einer Dimension darstellen, in der der Cursor auftritt. In Reaktion auf eine einen Ort in der anderen Dimension darstellende Adresse wird ein dieser Adresse entsprechendes Definitionssignal gewählt und ein Cursorsignal erzeugt, wenn eine Adresse in der ersten Dimension einem Ort entspricht, wo, wie durch die Definitionssignale dargestellt, ein Cursor auftritt.
Es wäre vorteilhaft, ein bequemeres Verfahren zum Benutzen der Maus eines Emulationssystems zum Emulieren einer Maus in dem emulierten System zu besitzen.
Die vorliegende Erfindung schafft eine Emulation der Eigenschaften der Maus in einem Zielsystem, das gerade emuliert wird, ohne Opfern der Merkmale der Maus in dem die Emulation ausführenden Host-System. Insbesondere ist eine erfindungsgemäße Maus-Emulation dann geeignet, wenn die Emulation in einem Fenster oder einem anderen Teil der Anzeige des Host- Systems ausgeführt wird, was hier einfach als "Emulation in einem Fenster" bezeichnet wird. Die Maus kann einen Zeiger innerhalb des Emulationsfensters so steuern, als ob es ein Zielsystemzeiger wäre, und kann auch den Zeiger durch die gesamte Anzeige steuern, als ob es der Host-System-Zeiger wäre. Eine derartige Maussteuerung wird in den Ansprüchen 1, 8 und 9 definiert.
Ein Aspekt der vorliegenden Erfindung ist auf der Erkenntnis eines speziellen Problems begründet, das die Emulation in einem Fenster und andere Techniken beeinflußt, bei dem ein erstes Mittel wie ein Emulator eine erste Anzeige und ein zweites Mittel wie ein Host-System eine zweite Anzeige schafft, welche die erste Anzeige enthält. Das Problem ist, daß Signale von der Maus oder einem anderen Zeigersteuerungs-Eingabegerät mehrdeutig sind. Sie können so gedeutet werden, wie das Host-System sie deutete, wenn der Emulator nicht vorhanden wäre, oder sie können so gedeutet werden, wie der Emulator sie deutet. Da der Emulator Zeigersteuerung in der ersten Anzeige unterschiedlich von der Zeigersteuerung ausführen kann, die das Host-System in der zweiten Anzeige ausführt, muß diese Mehrdeutigkeit aufgelöst werden, um die zweite Anzeige zu schaffen.
Dieser Aspekt der Erfindung ist begründet durch die weitere Erkenntnis, daß diese Mehrdeutigkeit gelöst werden kann, indem man dem Benutzer die Möglichkeit gibt, zwischen zwei Betriebsarten (Modi) hin- und zurückzuschalten. In einem Modus, dem Host-Modus, führt das Host-System die Zeigersteuerung aus, so daß der Zeiger sich wie ein Host-System-Zeiger benimmt. In dem anderen Modus, dem Emulationsmodus, führt der Emulator Zeigersteuerung aus, so daß der Zeiger sich wie ein Zeiger des Zielsystems verhält und innerhalb des Emulationsfensters bleibt. Das die Zeigersteuerung ausführende Mittel empfängt Zeigersteuersignale und reagiert entsprechend.
Ein eng damit in Beziehung stehender Aspekt der Erfindung ist auf der Erkenntnis begründet, daß der Benutzer fähig sein muß, eine Modusumschaltung in beiden Richtungen aufzurufen. Obwohl diese Fähigkeit auf verschiedene Weise geschaffen werden kann, gründet dieser Aspekt der Erfindung auf der Erkenntnis, daß der Benutzer ein Umschalten vom Host-Modus zum Emulations-Modus aufrufen kann durch Herstellen einer Mausselektion innerhalb des Emulationsfensters. Dies ist ein angemessene Schaltsignal nicht nur deshalb, weil es mit dem intuitiven Verhalten der meisten Benutzer verträglich ist, sondern auch deshalb, weil eine Auswahl innerhalb des Emulationsfensters dieses zum Eingabebrennpunkt (-fokus) macht, was bedeutet, daß die Signale vom Benutzer die Inhalte des Emulationsfensters beeinflussen, wie in der vorher erwähnten US-Patentanmeldung 856 525 beschrieben. Deshalb kann dieses Signal auch benutzt werden, um den Emulations-Modus zu schalten, bei dem die Maussignale den Inhalt des Emulationsfensters beeinflussen. Das Schaltsignal zum Zurückkehren zu dem Host-Modus kann irgendein entsprechendes Signal von dem Benutzer sein, jedoch keines der Maussignale, welche das Zielsystem für einen anderen Zweck benutzt.
Das erste Mittel kann einen Emulator zum Ausführen einer Instruktionsfolge (Befehlsfolge) enthalten, die durch den Zentralprozessor eines Zielsystems, wie eines IBM-PC, ausführbar ist. Der Emulator enthält einen Prozessor, der entweder diese Instruktionen direkt ausführt oder durch mit Hilfe anderer Software, welche sie in Maschinenpegel-Instruktionen wandelt, die er direkt ausführt. Beispielsweise kann dieser Prozessor ein Koprozessor sein, wie bei Workstation-Anwendungen. Der Prozessor kann auch ein Hochgeschwindigkeits-Mikroprozessor wie ein Intel 80386 oder ein Motorola 68020 oder 68030 sein, die durch Multitasking- oder gleichartige Timesharing-Techniken zum gleichzeitigen Ausführen von Emulator- und Host-System-Betätigungen fähig sind. Wie auch immer die Emulationstechnik sei, es müssen Daten zwischen den Host- System-Betriebsvorgängen und Emulations-Betriebsvorgängen übertragen werden.
Ein anderer Aspekt der Erfindung ist gegründet auf die Erkenntnis eines Problems bei der Übertragung von Mausbezogenen Daten zu den Emulations-Betriebsvorgängen. Eine solche Übertragung ist schwierig mit dem die Target- oder Zielsystem-Instruktionen ausführenden Prozessor zu synchronisieren, wenn die Daten diesem Prozessor durch Eingabe/Ausgabe-Vorgänge direkt zugeführt werden müssen. Eine der vorher erwähnten Workstation- Anmeldungen, US-Patentanmeldung 856 526, beschreibt verschiedene Techniken zum Übertragen von Daten zu dem Emulator durch Eingabe/Ausgabe-Vorgänge. Diese Techniken erfordern allgemein das Synchronisieren der Datenübertragung mit Emulations-Betriebsvorgängen durch Schaffen der Daten unmittelbar auf Anforderung oder durch Anhalten und Neustarten des Emulations- Prozessors in einer angemessenen Weise. In der Praxis bedeutet das, daß der Emulator Hardware-I/O-Anschlüsse enthalten muß, wie solche, die durch den Zielsystemprozessor benutzt werden, oder spezielle Software ausführen muß, um derartige Anschlüsse zu emulieren oder zu umgehen.
Eine beispielsweise in jener Anmeldung beschriebene Technik besteht darin, Daten durch eine zugreifbare Datenstruktur innerhalb des Speicherraums des Emulators zu übertragen. Diese Datenstruktur, Magicdatastructure, liegt innerhalb des Teiles des Emulator-Speicherraums, der dem BIOS eines emulierten IBM- PC zugeordnet ist. Da dieser BIOS-Speicherraum reserviert ist, schreiben weder das DOS (disc operating System) noch die durch DOS gestützten Anwendungen höheren Niveaus darauf. Das bringt Vorteile, da ein solcher Wert wie eine Adresse zum Zugreifen auf einen vorbestimmten festen Ort im BIOS-Speicherraum in der Host-System- und Emulator-Software angegeben werden kann mit der Sicherheit, daß keine Anwendung die Daten an diesem Ort verdirbt. Wenn Magicdatastructure mit Daten beladen worden ist, wird der Emulator neu gestartet mit einer speziellen, NMI correction routine genannten Routine, welche die Daten abruft und sie in entsprechende Register des Emulators lädt, als ob sie als Eingangssigale von einem I/O-Gerät erhalten worden wären. Diese spezielle Routine umgeht wirksam die Hardware- Anschlüsse, erzeugt jedoch das gleiche Ergebnis, wie wenn die Anschlüsse selbst vorhanden wären.
Dieser Aspekt der Erfindung ist auf die weitere Erkenntnis begründet, daß die Notwendigkeit von Hardware-Anschlüssen oder spezieller Software zum Emulieren oder Umgehen von Anschlüssen vermieden werden kann, falls das Zielsystem emuliert wird durch Emulieren der Art und Weise, mit der es auf Dienstleistungs- Anforderungen von Anwendungen höherer Niveaus reagiert. Die Software, welche diese Dienstleistungs-Anforderungen behandelt, kann in irgendeiner Weise ausgeführt werden, welche für die entsprechende Reaktion auf die jeweilige Dienstleistungs- Anforderung sorgt. Es ist deshalb möglich, diese Software dazu zu benutzen, Daten zu den Emulationsvorgängen direkt zu übertragen, vorausgesetzt, daß die Anwendungen höheren Niveaus sich "anständig verhalten", was bedeutet, daß sie für die Standard- Dienstleistungsanfragen sorgen und die Standard-Reaktionen erwarten.
Die meisten IBM-PC-Anwendungen höheren Niveaus, die Dienstleistungs-Anforderungen für die Maus schaffen, "verhalten sich anständig", so daß diese Technik besonders für Maus-Emulation geeignet ist. Der populäre Mikrosoft-Maustreiber nimmt eine Reihe von Standardbefehlen von Software höheren Niveaus an und reagiert standardmäßig auf diese Befehle, so daß die meisten Anwendungen höheren Niveaus, welche die Maus benutzen, nun für diese Reihe von Befehlen sorgen und entsprechende Reaktionen erwarten. Diese Befehle und Reaktionen sind beschrieben in Microsoft Mouse User's Guide von Microsoft Corporation, Bellevue, Wash. (1985), Seiten 175-194, auf die hier zur Referenz verwiesen wird. Der Microsoft-Maustreiber behandelt Dienstleistungs-Anforderungen von dem gleichen allgemeinen Typ wie das BIOS des IBM-PC, obwohl er nicht ein Teil des BIOS ist.
Dieser Aspekt der Erfindung beruht so auf der Erkenntnis, daß eine Datenstruktur an einer vorbestimmten Stelle im BIOS- Speicherraum oder das Äquivalent dazu benutzt werden kann, um MausDaten zu dem Emulator zu übertragen. Das Host-System kann diese Datenstruktur unter Benutzung ihrer vorgegebenen Adresse zu Zeitpunkten laden, wo die Emulationsbetätigungen nicht ausgeführt werden. In Reaktion auf ein Interrupt von dem Host kann ein entsprechender Maustreiber die Daten unter Benutzung der gleichen Adresse abrufen und die Mausbetätigungen können aufgrund der abgerufen Daten voranschreiten, ohne daß spezielle Software zum Emulieren oder Umgehen der Hardwareanschlüsse des emulierten Systems nötig ist.
Eine Ausführung der Erfindung wird nun beispielsweise mit Bezug auf die beigefügten Zeichnungen beschrieben, in welchen:
Fig. 1 ein Funktions-Blockschaltbild eines eine Maus- Emulation erfindungsgemäßer Art ausführenden Systems ist,
Fig. 2 eine schematische Darstellung einer Anzeige ist, die eine Abfolge von durch das System der Fig. 1 dargebotenen Zeigern zeigt,
Fig. 3 ein Flußdiagramm ist, das die sich aus der Abfolge der Fig. 2 ergebenden Schritte zeigt,
Fig. 4 ein Funktions-Blockschaltbild ist, das den Fluß von Benutzereingabedaten innerhalb des Systems der Fig. 1 zeigt,
Fig. 5 ein Flußdiagramm ist, das die Schritte einer Prozedur zeigt, die durch das Host-Mittel der Fig. 1 als Teil der Funktion der Eingabe-Durchleitung ausgeführt wird.
Fig. 6 ein Flußdiagramm ist, das die Schritte zeigt, die durch das Host-Mittel der Fig. 1 als Teil der Funktion der Schnittstellen-Emulation ausgeführt werden.
Fig. 7 ein Flußdiagramm ist, das die Schritte zeigt, die durch das Host-Mittel der Fig. 1 als Teil der Funktion der Eingabe-Durchleitung ausgeführten werden.

A. Allgemeine Beschreibung

Die allgemeinen Merkmale der Erfindung können aus Fig. 1 - 3 verstanden werden. Fig. 1 zeigt die funktionellen Bestandteile eines Systems, das eine Maus-Emulation nach der Erfindung ausführt. Fig. 2 zeigt eine Folge von Zeigern an einer Anzeige, die sich aus dem Betrieb dieses Systems ergeben können, während Fig. 3 die Schritte zeigt, die diese Folge ergeben.
System 10 in Fig. 1 enthält ein Host-Mittel 20 und einen Emulator 30. Das Host-Mittel 20 empfängt Benutzersignale von der Maus/dem Tastatur 22 und schafft Signale zu dem Benutzer durch die Anzeige 24. Die Maus/die Tastatur 22 und die Anzeige 24 bilden zusammen die Benutzer-Schnittstelle 26. Das Host- Mittel 20 besitzt auch Zugriff zu mindestens einem Teil des Speichers 28, von dem auch ein Teil für den Emulator 30 zugreifbar ist. Der Emulator 30 ist befähigt, eine Befehlsfolge eines Zielsystems, wie des IBM-PC, auszuführen. Zu diesem Zweck kann der Emulator 30 auf den DOS-Bereich 32 im Speicher 28 zugreifen, dessen Inhalte durch ein Betriebssystem, wie ein disc operating System, (DOS) gemanagt werden. Das DOS managt den DOS-Bereich 32 nach seinen eigenen Vorgangsweisen und kann beispielsweise eine Datei aufteilen in Teile, die an unterschiedlichen Orten im DOS-Bereich 32 gespeichert werden, so daß die im DOS-Bereich 32 gezeigten Posten in jeder geeigneten Weise gespeichert sein können. Der DOS-Bereich 32 kann eine Anzahl von für den IBM-PC geschriebenen Programmen enthalten, einschließlich Programme, die eine Maus benutzen, von denen eines als Mausanwendung 42 gezeigt ist.
Während des Ausführens einer Befehisfolge in der Mausanwendung 42 oder einem anderen Programm kann der Emulator 30 auch auf den BIOS-Bereich 34 zugreifen, einen Speicherraum, der dem grundsätzlichen Eingabe/Ausgabe-Systeins BIOS (basic input/output system) des IBM-PC zugeordnet ist und der davor bewahrt wird, durch das DOS oder durch irgendeine der im DOS-Bereich 32 gespeicherten Befehle überschrieben zu werden. Bei dem IBM-PC ist das BIOS im ROM gespeichert, was sicherstellt, daß es nur gelesen und nicht überschrieben werden kann. Andere übliche Hardware oder Software-Techniken können benutzt werden, den BIOS-Bereich 34 insgesamt oder teilweise gegen Überschreiben zu schützen. Im allgemeinen kann eine Anwendung im DOS-Bereich 32 jede Anforderung einer Anzahl von Standard-Dienstanforderungen schaffen, die durch ein innerhalb des BIOS-Bereiches 34 gespeichertes BIOS 44 behandelt werden. Auch wenn BIOS 44 im BIOS-Bereich 34 in Zuordnung zu dem IBM-PC gespeichert ist, braucht das BIOS 44 nicht identisch mit dem Standard-IBM-PC- BIOS zu sein, vorausgesetzt, daß es Dienstanforderungen von Anwendungen höheren Niveaus mit den gleichen Reaktionen behandelt, wie das Standard-IBM-PC-BIOS.
Die Mausanwendung 42 unterscheidet sich darin von den meisten DOS-Anwendungen, daß einige von ihr geschaffene Dienstanforderungen durch das Standard-IBM-PC-BIOS nicht behandelt werden können. Die Standard-Dienstanforderungen, die das IBM-PC-BIOS mit Standard-Reaktionen behandelt, enthalten nicht die auf die Maus bezogenen Dienstanforderungen, da ein Standard-IBM-PC keine Maus enthält. Eine Anzahl von in jüngster Zeit entstandenen Produkten stützen Mausanwendungen an dem IBM-PC oder an äquivalenten Geräten durch Schaffen zusätzlicher Software zur Behandlung von Maus-bezogenen Dienstanforderungen von diesen Anwendungen. Beispielsweise wurde der Mikrosoft-Maustreiber ausreichend populär, so daß die meisten populären Mausanwendungen höheren Niveaus seine Standard-Dienstanforderungen schaffen und seine Standard-Reaktionen auf diese Anforderungen erwarten. Der Mikrosoft-Maustreiber beruht auf Hardware-Anschlüssen zum Erhalt von auf die Maus bezogenen Daten, so daß ein Betreiben desselben an dem Emulator 30 die gleichen Hardware-Anschlüsse erfordert oder eine spezielle Software, welche diese Anschlüsse emuliert oder umgeht.
Statt diesen Vorgehensweisen enthält das Emulationsmittel des Systems 10 BIOS MausDaten 44a, eine Datenstruktur innerhalb des BIOS-Bereiches 34, wodurch das Host-Mittel 20 maus-bezogene Daten zu dem Emulator 30 überträgt, wie im einzelnen später besprochen wird. BIOS MausDaten 44a können an jedem entsprechenden nicht durch BIOS 44 oder andere Software besetzten Platz angeordnet werden, z.B. in einem Raum zwischen den BIOS- Routinen. Statt des Mikrosoft-Maustreibers enthält das System 10 einen Maustreiber 46 als Software im DOS-Bereich 32, der die Standard-Reaktionen zu den Standard-Anforderungen schafft und auf BIOS MausDaten 44 zugreifen kann unter Benutzung einer vorgegebenen MausDatenadresse, die darin enthalten oder eingebettet ist. Der Maustreiber 46 greift auch auf MausDaten 48 zu, einer Datenstruktur im DOS-Bereich 32, um verschiedene Posten von Daten zeitweilig während seiner Ausführung zu speichern.
Der Emulator 30 dient zusammen mit dem Inhalt des DOS-Bereiches 32 und des BIOS-Bereiches 34 als Emulationsmittel zum Ausführen von IBM-PC-Software, einschließlich DOS-Anwendungen wie der Mausanwendung 42. Während der Emulation führt der Emulator 30 eine der DOS-Anwendungen im DOS-Bereich 32 aus und greift auch auf den BIOS-Bereich 34 zu, um auf Instruktionen zum Umgang mit Dienstanforderungen von dieser DOS-Anwendung zuzugreifen und zum Behandeln von Interrupts von anderen Quellen. Bei diesem Vorgang sorgt der Emulator 30 auch für Ausgangssignale und empfängt Eingangssignale, und das Hostinittel 20 empfängt die Ausgangssignale und schafft die Eingangssignale, die Interrupts enthalten können, wodurch eine Umgebung für den Emulator 30 so geschaffen wird, daß die Emulation anhält.
Das Hostmittel 20 und der Emulator 30 können mit jeder einer Anzahl von Architekturen ausgeführt werden. Im allgemeinen fallen diese Architekturen in zwei Kategorien, eine, bei der der Emulator 30 einen der Emulation gewidmeten Koprozessor enthält, und die andere, bei der der Emulator 30 eine einer Anzahl von Aufgaben oder Betriebsweisen eines Prozessors ist, dessen Zeit zwischen Emulations- und Hostvorgängen aufgeteilt wird. Die Workstation-Anwendungen schaffen ein Beispiel einer Koprozessor-Architektur, wobei das Hostmittel einen Host- Prozessor und einen Eingabe/Ausgabe-Prozessor enthält. Mit einem mächtigeren Mikroprozessor wäre es jedoch angemessen, die Funktionen aller dieser drei Prozessoren mit einem einzigen Prozessor durch irgendeine Art von Zeitaufteilung auszuführen, wie Multitasking oder Mehrfachmodi. Auf jeden Fall werden die Ausgangssignale vom Emulator 30 zum Hostmittel 20 übertragen, was für eine solche Umgebung für den Emulator 30 sorgt, daß die Emulation fortgesetzt wird. Diese Eingabe- und Ausgabesignale können durch eine Datenstruktur im Speicher 28 ausgetauscht werden, welche einen Hardwareanschluß emuliert oder umgeht, wie beispielsweise durch die vorher besprochene MagicDataStructure.
Die vorliegende Erfindung schafft eine Technik zur Datenübertragung während Maus-Emulation, die auf die BIOS MausDaten 44a zurückgreift. Diese Technik ist geeignet zum Übertragen von Zeigereingabesteuersignalen wie Signalen, die auf Manipulation einer Maus durch den Benutzer beruhen, vom Hostmittel 20 zum Emulator 30, da der Standard-IBM-PC, wie vorher bemerkt, keine Maus enthält und deswegen nicht von einem Standard-Hardware- Anschluß zum Übertragen von mausbezogenen Daten abhängt. Stattdessen empfängt der einen Mikrosoft-Maustreiber stützende IBM-PC mausbezogene Daten durch eine zusätzliche Maus-Schnittstellenplatine, welche zusätzliche Hardwareanschlüsse schafft, die durch den Mikrosoft-Maustreiber festgesetzt sind.
Da der Maustreiber 46 nicht der gleiche wie der Mikrosoft- Maustreiber ist, hängt er nicht von diesen zusätzlichen Hardwareanschlüssen ab, so daß eine spezielle Software zum Emulieren oder Umgehen von Hardwareanschlüssen unnötig ist. Stattdessen greift der Maustreiber 46 direkt auf die MausDatenstruktur 44a zu unter Benutzung der MausDatenadresse, einer vorgegebenen Adresse im BIOS-Bereich 34. Diese Adresse kann vorgegeben sein, weil das bei der Emulation benutzte BIOS 44 etwas kleiner als das IBM-PC-BIOS ist, so daß der BIOS-Bereich 34 einige unbenutzte Adressen enthält, die beispielsweise zwischen Routinen liegen können. Obwohl es nicht notwendigerweise Festwertdaten sind, werden die unbenutzten Adressen durch DOS oder durch irgendeine "gutartige" Anwendung im DOS-Bereich 32 nicht überschrieben, wie vorher bemerkt. Diese vorbestimmte Adresse, eine der nicht benutzten Adressen im BIOS-Bereich 34, ist auch in der Software für Hostmittel 20 enthalten, so daß es BIOS MausDaten 44a laden kann, und kann auch im BIOS 44 enthalten sein, wenn es für andere Zwecke angemessen ist. Während Zeiträumen, in denen der Emulator 30 keine Ausführung hat, kann das Hostmittel 20 diese Adresse benutzen, um BIOS MausDaten 44a zu laden, und wenn der Emulator 30 seinen Betrieb wieder aufnimmt, kann der Maustreiber 46 zu BIOS MausDaten 44 Zugriff nehmen, ohne zu unterbrechen oder mit der Emulation in Konflikt zu kommen.
System 10 ergibt eine Maus-Emulation, wie oben beschrieben, aber es ist auch notwendig, die Maus/die Tastatur 22 zu benutzen, um Eingang zu dem Hostmittel 20 in Bezug auf die Hostanzeige zu schaffen. Fig. 2 und 3 zeigen eine Technik erfindungsgemäßer Art, die die Benutzung von Maus/Tastatur 22 sowohl in der Hostanzeige wie in der emulierten Anzeige zuläßt.
Fig. 2 zeigt das Schirmbild 50, das insgesamt eine Anzeige ist, die durch das Hostmittel 20 geschaffen wird,, von dem jedoch ein Teil, der Inhalt des Emulatorfensters 52, die durch den Emulator 30 geschaffene Anzeige ist. Ebenfalls innerhalb des Anzeigeschirms 50 befinden sich das Hostfenster 54, ein Beispiel für ein Fenster, dessen Inhalt durch das Hostmittel 20 geschaffen wird, und das Host-Ikon 56, ein durch das Hostmittel 20 verwaltetes Ikon.
Das Schirmbild 50 enthält auch dargestellende Zeiger 62, 64, 66 und 68, von denen nicht alle gleichzeitig angezeigt werden. Die Zeiger 62 und 64 sind Beispiele eines Hostzeigers, der in Reaktion auf eine Bewegung der Maus durch den Benutzer sich von der Zeigerposition 62 außerhalb des Emulatorfensters 52 zu der Position des Zeigers 64 innerhalb des Emulatorfensters 62 bewegt. Von dieser Position könnte er zurück zur Position des Zeigers 62 bewegt werden. Kurz gesagt, der Benutzer kann den Hostzeiger zu irgendeiner Position innerhalb des Schinnbildes 50 bewegen, da das Hostmittel 20 für das gesamte Bild sorgt.
Die Zeiger 66 und 68 sind andererseits Beispiele für einen emulierten Zeiger, der so dargestellt ist, als ob er die gleiche Größe wie der Hostzeiger hat, obwohl diese beiden nicht die gleichen zu sein brauchen und irgendwelche relative Größen und willkürliche Formen besitzen können. Der emulierte Zeiger bewegt sich in Reaktion auf die Mausbewegungen von der Zeigerposition 66 zu der Zeigerposition 68, die sich beide innerhalb des Emulatorfensters 52 befinden. Der emulierte Zeiger kann jedoch seine Bewegung nicht außerhalb des Emulatorfensters 52 fortsetzen, da er durch den Emulator 30 gesteuert und aus diesem Grunde auf den durch den Emulator 30 geschaffenen Teil des Schirmbildes 50, also das Emulatorfenster 52, begrenzt ist.
Fig. 3 zeigt, wie die Erfindung es dem Benutzer erlaubt, zwischen dem Hostzeiger und dem emulierten Zeiger hin- und herzuschalten. Das Hostmittel 20 besitzt zwei Zeiger-Betriebsarten oder -Modi, einen links in Fig. 3 gezeigten Host-Modus und einen rechts gezeigten Emulations-Modus. Fig. 3 zeigt die allgemeinen Funktionsschritte, die durch das Hostmittel 20 in jedem Modus unternommen werden.
Wenn das Hostmittel 20 in den Host-Modus eintritt, Kasten 70, wartet es daraufhin, Kasten 72, auf einen Interrupt. Dieser Interrupt kann von einer Bewegung der Maus oder von einem Klicken einer Taste an der Maus oder von einem getasteten Tastenfeld ergeben, könnte aber auch von anderen Komponenten des Systems kommen. Solange kein Interrupt auftritt, fährt das Hostmittel 20 mit seinem Warten fort, kann jedoch andere Betätigungen ausführen, wie das Auffrischen der Anzeige und des Speichers während des Wartens. Statt auf einen Interrupt zu warten, kann das Hostmittel 20 selbstverständlich auch in einer Anzahl unterschiedlicher Arten in Betrieb sein, einschließlich des Abfragens aller Systemkomponenten oder irgendeine Kombination des Abfragens einiger Systemkomponenten und Wartens auf Interrupts von anderen. Im allgemeinen wird jedoch, da der Benutzer im Vergleich zum System langsam ist, das Hostmittel 20 auf Signale vom Benutzer warten.
Wenn ein Interrupt auftritt, prüft das Hostmittel 20 im Kasten 74, ob der Interrupt ein Schalten vom Host-Modus zum Emulations-Modus bezeichnet. Beispielsweise kann der Benutzer einen solchen Schaltvorgang durch Klicken einer der Tasten an der Maus signalisieren, wenn der Hostzeiger sich in der Zeigerposition 64 oder einer anderen Position befindet, die an einen Ort im Emulatorfenster 52 zeigt. Wenn der Interrupt kein Schaltsignal ist, führt das Hostmittel 20 seine angemessene Reaktion auf den Interrupt aus, Kasten 76, bevor es zum Warten auf den nächsten Interrupt zurückkehrt Wenn sich der Interrupt auf Mausbetrieb bezieht, wird deshalb das Hostmittel 20 entsprechend die Hostmaus steuern. Wenn jedoch der Interrupt ein Schalten zum Emulations-Modus anzeigt, verläßt das Hostmittel 20 den Host-Modus im Kasten 78 und tritt im Kasten 80 in den Emulations-Modus ein.
Im Emulations-Modus wartet das Hostmittel in gleicher Weise in Kasten 82 auf einen Interrupt, wobei es während des Wartens Anzeige- und Speicherauffrischung und andere Betriebsvorgänge ausführt. Wenn ein Interrupt auftritt, bestimmt die Prüfung im Kasten 84, ob der Interrupt ein Schalten vom Emulations-Modus zum Host-Modus bezeichnet. Beispielsweise könnte ein Klicken auf eine "Stop"-Tasten am Tastenfeld als Schaltsignal dienen. Wenn der Interrupt kein Schaltsignal ist, schafft das Hostmittel die entsprechenden Daten aufgrund des empfangenen Interrupts zum Emulator 30, Kasten 86, und kehrt zum Warten auf den nächsten Interrupt in den Kasten 82 zurück. Wenn der Interrupt sich auf Mausbetriebsvorgänge bezieht, wird der Emulator 30 Daten empfangen, die ihm das entsprechende Steuern der emulierten Maus ermöglichen. Wenn der Interrupt ein Umschalten zum Host-Modus bezeichnet, verläßt das Hostmittel 20 den Emulations-Modus im Kasten 88 und betritt im Kasten 70 des Host-Modus.
Wir wenden uns nun der mehr ins Detail gehenden Betrachtung zu, wie das Modusumschalten ausgeführt werden kann. Dann werden wir die Merkmale der BIOS- und DOS-Anwendungen in Betracht ziehen, welche während des Emulations-Modus die Maus-Emulation schaffen.

B. Modusumschalten

Fig. 2 und 3 stellen allgemeine Merkmale des Umschaltens dar zwischen einem Modus, in dem der Host den Zeiger steuert, und einem Modus, in dem der Emulator den Zeiger steuert. Jeder Modus kann als ein Zustand des Systems 10 angesehen werden, wobei die Übergänge zwischen den Zuständen sich nach Schaltsignalen vom Benutzer ergeben. Obwohl das Modusumschalten von der Ausführung der Emulation abhängt, wird der Datenfluß, der das Modusumschalten zuläßt, typischerweise dem gleichen Allgemeinmuster folgen.

1. Datenfluß

Fig. 4 zeigt einen allgemeinen Datenstrom, der das Modusumschalten in einer mit Fig. 2 und 3 konsistenten Weise zuläßt. Jeder Block in Fig. 4 stellt eine allgemeine Funktionskomponente innerhalb des Systems 10 dar, und einige entsprechen Komponenten in Fig. 1.
Wie vorstehend beschrieben, schafft Maus/Tastenfeld 22 Signale vom Benutzer. Der Eingangssignal-Durchleiter 92, eine Funktionskomponente innerhalb des Hostmittels 20, empfängt jedes Signal und leitet es zu einer anderen Funktionskomponente innerhalb des Hostmittels 20 durch. Fig. 4 zeigt zwei Komponenten, die Signale von dem Eingangssignal-Durchleiter 92 empfangen können, die Emulat.ions-Schnittstelle 92 und die Host- Betriebsvorgänge 96. Während das Hostmittel 20 sich im Emulations-Modus befindet, leitet der Eingangssignal-Durchleiter 92 die Benutzersignale zur Emulations-Schnittstelle 94, welche entsprechende Signale für den Emulator 30 schafft. Während das Hostmittel 20 sich jedoch im Host-Modus befindet, leitet der Eingangssignal-Durchleiter 92 die Benutzersignale zu den Host- Betriebsvorgängen 96, einer funktionellen Komponente, die verschiedene Betätigungen des Hostmittels 20 zusammenfaßt. Wie gezeigt, können die Emulations-Schnittstelle 94 und die Host-Betriebsvorgänge 96 einander Signale zusenden als ein Teil der Reaktion auf ein Signal von dem Eingangssignal-Durchleiter 92, und der Emulator 30 kann auch Signale zurück zur Emulations-Schnittstelle 94 senden. Der Emulator 30 und die Host- Betriebsvorgänge 96 können auch jeweils Signale zur Anzeigesteuerung 98 schaffen, welche eine Änderung bei der entsprechenden Anzeige bezeichnen. Die Anzeigesteuerung 98, eine andere funktionelle Komponente des Hostmittels 20, reagiert durch Aktualisieren des durch die Anzeige dargestellten Bildes. Wenn dann die Reaktion auf die Signale vom Benutzer abgeschlossen ist, kann das nächste Signale von dem Benutzer behandelt werden.
Der in Fig. 4 gezeigte Datenstrom kann in verschiedenen Architekturen realisiert werden. Wenn auch Maus/Tastenfeld 22 und Anzeige 24 entsprechende Hardware enthalten, können die restlichen Komponenten alle als durch einen Zentralprozessor ausgeführte Software realisiert werden, wobei der Zentraiprozessor Signale mit Maus/Tastenfeld 22 und Anzeige 24 austauscht. Jede gezeigte Funktionskomponente kann einem oder mehreren Software- Modulen entsprechen, welche die entsprechende Funktion ausführen. Die Erfindung wurde jedoch anfangs mit einem in den Workstation-Anmeldungen beschriebenen System ausgeführt, bei dem der Emulator 30 ein zum Ausführen von IBM-PC-Software fähiger dazu bestimmter Koprozessor ist und seine Anzeige in einem Fenster innerhalb der Hostanzeige dargestellt wird.

2. Koprozessor-Auslegung

Die in den Workstation-Anmeldungen beschriebene Koprozessor- Architektur enthält tatsächlich drei Prozessoren, die bei der Emulation eine Rolle spielen. Das Hostmittel 20 enthält eine Host-CPU, welche andere Hostsystembefehle außer den Zielsystembefehlen ausführt. Ein Eingabe/Ausgabe-Prozessor (IOP) behandelt Eingabe/Ausgabe-Geräte (I/O) und überträgt Daten zwischen den I/O-Geräten und der Host-CPU. Der Emulationsprozessor (PCE) benutzt mit dem IOP gemeinsam einen Bus. Im allgemeinen schaffen die Host-CPU und der IOP zusammen die vorstehend mit Bezug auf Fig. 2 und 3 beschriebenen funktionellen Komponenten des Hostmittels 20. Wie nachstehend beschrieben, schafft die Host- CPU die Funktionen des Eingabesignal-Durchleiters 92 und der Host-Betriebsvorgänge 96, während die Host-CPU und der IOP zusammen die Emulations-Schnittstelle 94 ergeben. Die Art und Weise, mit der die Host-CPU und andere Bestandteile die Funktionen der Anzeigesteuerung 98 schaffen, sind im wesentlichen die gleichen, wie sie in den Workstation-Anmeldungen beschrieben sind.
Die in den Workstation-Anmeldungen beschriebene Host-CPU führt Mesa-Kode einschließlich grundsätzlicher Workstation- Software (BWS) aus, welche die an der Anzeige 24 präsentierten Daten verwaltet. Wenn der Benutzer Signale durch Maus/Tastenfeld 22 schafft, dient der IOP als ein Teil des Eingabesignal-Durchleiters 92, indem er Signale zu der Host-CPU durchleitet, wie es in der vorher erwähnten (als US-A-4 899 136 veröffentlichten) US-Anmeldung SW 856 525 beschrieben ist. Die dort beschriebene Technik reagiert vollständig auf jedes Signal von dem Benutzer vor dem Empfang des nächsten Benutzersignals durch zwei Software-Vorgänge, welche als "Stimulus" bzw. "Notifier" benannt sind. Stimulus dient, wie mit Bezug auf Fig. 29 der US- Anmeldung gezeigt und beschrieben, auch als Teil des Eingabesignal-Durchleiters 92 durch Empfangen der Benutzersignale und Einladen derselben in einen Puffer, von wo sie durch Notifier abgeholt werden können. Stimulus ist mit den Schritten in den Kästen 72 und 82 der Fig. 3 konsistent, da es auf einen Interrupt vom Tastenfeld-Prozessor wartet. Notifier, wie mit Bzeug auf Fig. 30 der genannten US-Anmeldung gezeigt und beschrieben, dient in gleicher Weise als Teil des Eingabesignal-Durchleiters 92 durch Aufruf von Vorgängen, welche den Zeiger- oder Cursor- Ort aktualisieren, oder durch Schaffen von Tastenfeld-Eingangssignalen zu dem entsprechenden Fenster. Obwohl Notifier nicht tatsächlich überprüft, ob der Benutzer nach einer Modusumschaltung signalisiert hat, wie in den Kästen 74 und 84 der Fig. 3 bezeichnet, führt seine Betätigung zu einem Modusumschaltvorgang, wie aus der nachfolgenden Diskussion zu verstehen ist.

a. Umschaltung Host-Modus zu Emulations-Modus

Fig. 5 zeigt Schritte, die dann unternommen werden, wenn der Benutzer eine Modus-Umschaltung von dem Host-Modus zum Emulations-Modus signalisiert. Wenn die Modus-Umschaltung durch irgendein willkürliches Eingangssignal signalisiert würde, das auf den gegenwärtigen Eingabefokus gerichtet wurde, werden gleichartige Schritte als Ergebnis des Zugriffs zur TIP-Tabelle für das gegenwärtige Eingabefokusfenster ausgeführt, wie in den Workstation-Anmeldungen beschrieben. Ein Aspekt der Erfindung besteht jedoch darin, daß der Benutzer eine Modus-Umschaltung signalisieren kann durch Schaffen eines Signals, welches den Eingabefokus zu einem Emulationsfenster ändert zu einem Zeitpunkt, in dem der Benutzer eine Emulationskonfiguration gewählt hat, die eine Maus enthält. Dies ergibt ein einfaches und intuitives Modus-Schaltsignal, welches normalen Erwartungen entspricht. Der Benutzer signalisiert typischerweise eine solche Änderung des Eingabefokus durch Klicken der linken Maustaste, wenn der Host-Pomter auf eine Position in einem Emulationsfenster zeigt. Der Benutzer erwartet wahrscheinlich, daß die Maus danach als eine emulierte Maus arbeitet.
Notifier verfolgt den gegenwärtigen Eingabefokus und auch, welches Fenster gegenwärtig den Zeiger enthält. Nach Empfang eines eine Änderung des Eingabefokus bezeichnenden Signais in Kasten 110 in Fig. 5 unterrichtet Notifier das gegenwärtig den Zeiger enthaltende Fenster. Das Flußdiagramm nach Fig. 5 verzweigt sich im Kasten 112 je nachdem, ob Notifier im Kasten 114 eines der Hostfenster unterrichtet oder im Kasten 116 ein Emulationsfenster. Notifier braucht nicht zu untersuchen, ob das unterrichtete Fenster ein Hostfenster oder ein Emulationsfenster ist, da ein auf die Unterrichtung reagierender Vorgang in einer dem unterrichteten Fenster angemessenen Weise reagiert.
Der Vorgang, der reagiert, wenn ein Emulationsfenster von einer Tastenbetätigung unterrichtet wird, ob sie nun eine Änderung des Eingabefokus oder andere Daten bezeichnet, wird MainNotifyProc genannt. MainNotifyProc reagiert auf eine Unterrichtung mit einer Änderung des Eingabefokus durch Annehmen des Eingabefokus im Kasten 118. Zusätzlich führt, wie nachfolgend diskutiert, MainNotifyProc einen Modus-Schaltvorgang aus.
Wenn andererseits ein Hostfenster von einer Änderung des Eingabefokus im Kasten 114 unterrichtet wird, übernimmt es in gleicher Weise den Eingabefokus und führt irgendwelche andere angemessene Hostbetätigungen aus, wie in Kasten 76 der Fig. 3. Hostvorgänge 96 nach Fig. 4 werden so durch die Host-CPU geschaffen und können irgendwelche Betätigungen enthalten, die sich auf den Teil deüanzeige beziehen, der nicht durch das Emulationsfenster besetzt wird, wie auch auf Vorgänge zum Übertragen von Daten zwischen dem Emulationsfenster und anderen Fenstern, wie in den Workstation-Anmeldungen beschrieben.
MainNotifyProc fährt mit seiner Reaktion zum Ändern des Eingabefokus fort durch Überprüfen, in Kasten 120, ob die gegenwärtige Emulationskonfiguration eine emulierte Maus enthält. Wenn dies der Fall ist, wird eine Modus-Umschaltung durchgeführt. Die Verzweigung im Kasten 112 und die Prüfung im Kasten 120 sind so äquivalent zu der Überprüfung im Kasten 74 der Fig. 3, weil sie zusammen bestimmen, ob vom Hostmodus zum Emulations-Modus umzuschalten ist.
Die Host-CPU führt einen Mauskonfigurationsvorgang durch PCE- Konfiguration aus, bei dem sie Werte in Datenstrukturen im I/O- Bereich lädt, welche anzeigen, ob der Benutzer eine Konfiguration ausgewählt hat, die eine Maus enthält, und, wenn das der Fall ist, welchen Interrupt der Benutzer als Maus-Interrupt gewählt hat. Deswegen kann durch Abrufen dieser Daten vom I/O- Bereich die Überprüfung im Kasten 120 bestimmen, ob die Emulationskonfiguration eine Maus enthält. Der I/O-Bereich, wie er in den Workstation-Anmeldungen beschrieben wird, ist ein Speicherbereich, der auch zum Übertragen von Daten zwischen der Host-CPU und dem IOP benutzt wird. Die Auswahl des Maus-Interrupts emuliert ein Merkmal des Mikrosoftbus-Maus-I/O-Systems, eines populären Maussystems für den IBM-PC; dieses Merkmal läßt zu, daß der Benutzer den Maus-Interrupt aus den Interrupts auswählt, die nicht anderen Geräten zugeordnet sind.
Die Modus-Umschaltung enthält das Anhalten der Prozedur, welche den Hostzeiger zur Anzeige bringt, Kasten 122, so daß der Hostzeiger verschwindet. Als Teil dieses Schrittes wird die Position des Hostzeigers bei seinem Verschwinden so gespeichert, daß er später wieder an der gleichen Stelle erscheinen kann. Dieser Schritt ist äquivalent zu dem im Kasten 78 der Fig. 3 enthaltenen Schritt, da das Anhalten der Anzeige des Hostzeigers wirksam den Host-Modus verläßt. Der Hostzeiger kann alternativ auch an seiner gegenwärtigen Position eingefroren werden, jedoch kann dies eine Konfusion mit dem emulierten Zeiger ergeben.
Nach Verlassen des Host-Modus beginnt der Schritt im Kasten 124 einen Emulations-Vorgang an der Host-CPU, PCEMouseNotify, der periodisch überprüft, ob eine ein Signal bezeichnende Mausbewegung empfangen wurde. PCEMouseNotify ist einer von verschiedenen NotifyProc-Vorgängen für das Emulationsfenster einschließlich MainNotifyProc. Zusätzlich zur Reaktion auf eine Eingangssignal-Fokusänderung wird MainNotifyProc immer dann unterrichtet, wenn ein Tastenklick für das Emulationsfenster empfangen wird als Ergebnis dessen, daß es der Eingabefokus ist. Ein anderes NotifyProc behandelt Tastenbetätigungen, wenn das Emulationsfenster angehalten wird, um Datenübertragung zuzulassen. Diese anderen NotifyProc sind unabhängig davon, ob das System sich in seinem Maus-Emulationsmodus befindet, jedoch ist das Starten von PCEMouseNotify im Kasten 124 äquivalent zum Eintritt in den Emulations-Modus im Kasten 80 in Fig. 3. Dann kehrt MainNotifyProc zurück zum Warten auf weitere Unterrichtungen im Kasten 126.
Fig. 6 stellt den Emulations-Modusbetrieb von PCEMouseNotify und MainNotifyProc und einen dritten Vorgang dar, den jedes von diesen aufruft, MouseAction. PCEMouseNotify und MainNotifyProc beginnen gleichartig, und warten jeweils auf Unterrichtungen. Im Kasten 130 wartet PCEMouseNotify auf eine periodische Unterrichtung, die beispielsweise je nach 40 ms geschaffen werden kann. Diese Unterrichtung wird von der darunterliegenden Mesa-Software empfangen, welche PCEMouseNotify und andere Mesa- Abläufe verwaltet. In gleicher Weise wartet in Kasten 132 MainNotifyProc auf einen normalen Unterrichtung von der unterliegenden Software, die sich beispielsweise durch einen Tastenklick an der Maus oder dem Tastenfeld ergibt. Dies ist der Schritt, zu dem MainNotifyProc vom Kasten 126 in Fig. 5 zurückkehrt.
Nach Erhalten eines Hinweises in Kasten 134 oder 136 führt jeder Vorgang eine jeweilige Überprüfung aus, um zu bestimmen, ob die Unterrichtung sich aus einem mausbezogenen Ereignis ergibt. Wenn PCEMouseNotify eine Unterrichtung erhält, prüft es im Kasten 138, um zu bestimmen, ob eine Mausbewegung stattgefunden hat. Die Mausbewegung kann aus den Cursorlagen-Werten erfaßt werden, die durch vom Notifier in der vorstehend angemerkten Art aufgerufene Vorgänge gespeichert wurden. Daten über Mausbewegung können auch in einer Anzahl von anderen Wegen erreicht werden, jedoch können die durch Notifier aufgerufenen vorher vorhandenen Prozeduren bequemerweise benutzt werden, um eine fiktive Hostzeigerposition aufrecht zu erhalten, von welcher x/y-Versätze erhalten werden können. Wenn der Benutzer die Maus bewegt, empfängt Notifier Mausbewegungsereignisse und ruft einen Vorgang auf, der diese Ereignisse zum Bestimmen von x/y-Versätzen benutzt, als ob der Hostzeiger weiterhin angezeigt würde. Da der Hostzeiger jedoch nicht angezeigt wird, können diese Versatzwerte benutzt werden, um eine fiktive Zeigerposition in Form von x/y-Koordinaten zu bestimmen. Der Vorgang schafft die neuen x/y- Koordinaten für Notifier, welches diese mit den Positionen des angezeigten Fensters vergleicht. Falls Notifier findet, daß die Zeigerposition, ob nun fiktiv oder tatsächlich, sich aus einem angezeigten Fenster herausbewegt, behandelt sie dies als ein Tastenfeldereignis und ruft ein NotifyProc von diesem Fenster auf mit einem Signal, das ein Auswandern des Zeigers aus diesem Fenster bezeichnet.
MainNotifyProc eines Emulationsfensters reagiert auf ein Zeigerauswanderungssignal durch Überprüfen, ob das System sich im Hostmodus oder im Emulations-Modus befindet. Falls im Hostmodus, erlaubt MainNotifyProc dem tatsächlichen Hostzeiger, das Emulationsfenster zu verlassen. Im Emulations-Modus reagiert MainNotifyProc jedoch durch einen Sprung der fiktiven Zeigerposition zurück in den Zentralbereich des Emulationsfensters, in einen Bereich, der nicht durch ein überlappendes Fenster überdeckt ist. MainNotifyProc beseitigt jede darauffolgende Mausbewegung oder jedes darauffolgende Tastenfeldereignis, das durch den Stimulus-Pegel in den Eingabepuffer geladen wurde. MainNotifyProc schafft jedoch nicht Signale zu dem PCE, welche dem Springen des fiktiven Zeigers oder den erfaßten Ereignissen entsprechen, so daß der durch den PCE geschaffene emulierte Zeiger nicht durch diese Vorgänge beeinflußt wird.
Der Benutzer ist so in der Lage, fortzusetzen, um jederzeit während des Emulations-Modus Mausbewegungssignale in irgendeiner Richtung zu schaffen, da die fiktive Zeigerposition immer innerhalb des Emulationsfensters bleibt, auch wenn die fiktive Zeigerposition nicht dem emulierten Zeiger folgt. Das Begrenzen der fiktiven Zeigerposition auf das Emulationsfenster stellt auch sicher, daß der Benutzer kein Mausklick- oder anderes Signal außerhalb des Emulationsfensters schaffen kann, das eine unerwünschte Änderung des Eingabefokus während der Maus-Emulation ergäbe. Wie nachstehend diskutiert, wird die fiktive Zeigerposition, wenn der Modus zum Hostmodus zurückgeschaltet wird, durch die Hostzeigerposition ersetzt, da der Hostzeiger wieder erscheint.
Wenn MainNotifyProc eine Unterrichtung erhält, prüft es im Kasten 140, um zu bestimmen, ob ein Maustastenklick aufgetreten ist. Tastenklicke können erfaßt werden durch Vergleichen gegen-Tastenklick im Emulationsfenster einen NotifyProc ergibt, der einen dieser Werte ändert.
Falls PCEMouseNotify oder MainNotifyProc im Kasten 138 oder Kasten 140 bestimmt, daß ein Maus-Ereignis aufgetreten ist, unternimmt der jeweilige Vorgang angemessene Schritte, um das Maus-Ereignis zu behandeln und dadurch die Funktion der Emulations-Schnittstelle 94 in Fig. 4 einzuleiten. Jeder Vorgang bewirkt die Übertragung von Daten, die ein Maus-Ereignis zu dem I/O-Bereich bestimmen, so daß der IOP wiederum diese Daten zu dem PCE übertragen kann.
Wenn die Mausbewegung aufgetreten ist, bestimmt PCEMouseNotify die x/y-Versatzwerte des emulierten Zeigers von seiner vorherigen Position auf Maßstabsbildung der fiktiven Zeigerpositions-Versätze im Kasten 142. Die Versatzwerte werden in einer MausDaten genannten Datenstruktur im I/O-Bereich im Kasten 144 gespeichert und ein die Änderung der Zeigerposition bezeichnendes Lausebit (dirty bit) wird in Kasten 146 gesetzt. Pcemouse- Notify ruft dann einen anderen Vorgang, MouseAction, im Kasten 148 auf. Wenn keine Mausbewegung aufgetreten ist, kehrt PCEMouseNotify zum Kasten 130 zurück, um auf die nächste periodische Unterrichtung zu warten. Falls Mausbewegung aufgetreten ist, kehrt PCEMouseNotify zum Kasten 130 zurück, um nur bis nach dem Aufruf der MouseAction im Kasten 148 zu warten.
Wenn MainNotify im Kasten 140 bestimmt, daß das Ereignis, das zu einer Unterrichtung für es führte, kein Mausklick in dem Emulationsmodus war, behandelt es das andere Ereignis in angemessener Weise, im Kasten 150. Wenn das Ereignis beispielsweise eine Änderung des Eingabefokus zu dem Emulationsfenster ist, führt MainNotifyProc die Schritte in den Kästen 118, 120, 122 und 124 in Fig. 5 aus. Oder, wenn das Ereignis ein Verlassen des Emulationsfensters durch den Zeiger ist, reagiert MainNotifyProc, wie vorher beschrieben, wodurch es den Host- Zeiger austreten läßt, jedoch die fiktive Zeigerposition verschiebt, um sicherzustellen, daß der emulierte Zeiger im Emulations fenster verbleibt.
Wenn MainNotifyProc andererseits bestimmt, daß das Ereignis ein Maustastenklick in dem Emulationsmodus war, erzielt MainNotifyProc im Kasten 154 eine Identifizierung der geklickten Taste, und lädt die Identifizierung im Kasten 156 in MausDaten. Dann setzt MainNotifyProc im Kasten 158 ein Lausebit für einen Tastenklick und ruft gleichfalls im Kasten 148 MouseAction auf. Nachdem dieser Aufruf gemacht ist, kehrt MainNotifyProc zum Warten in Kasten 132 zurück.
MouseAction überträgt den Inhalt von MausDaten in den I/O- Bereich, Kasten 160. Das kann in der nachfolgenden Reihenfolge erledigt werden: Lausebits; x-Versatz, y-Versatz; und Maustaste. Wenn die Datenstruktur im I/O-Bereich vervollständigt wurde, schafft MouseAction eine Abwärtsunterrichtung zu dem IOP im Kasten 162, in der in den Workstation-Anmeldungen beschriebenen Weise. Inzwischen sind PCEMouseNotify oder MainNotifyProc zurückgekehrt, um im Kasten 130 bzw. 132 zu warten. An dieser Stelle reagiert der bp auf die Abwärtsunterrichtung und führt weitere Funktionen der Emulations-Schnittstelle 94 nach Fig. 4 aus, wie mit mehr Einzelheiten nachfolgend mit Bezug auf BIOS MausDaten 44a beschrieben wird.

b. Umschaltung Emulations-Modus zu Host-Modus

Die Modusumschaltung von dem Emulations-Modus zum Host-Modus wird auch durch die Host-CPU ausgeführt. Während des Emulations-Modus kann der fiktive Zeiger nicht aus dem Emulationsfenster herausbewegt werden, so daß das Benutzersignal zum Anzeigen dieses Modusumschaltvorganges nicht dadurch erfolgen kann, daß der Eingabefokus mit einem Mausklick auf ein anderes Fenster geändert wird. Weiter sorgen während der Emulation die Host-CPU und der IOP für den größten Teil der Benutzersignale von Maus/Tastatur 22 zum Emulator 30. Dadurch muß das Benutzersignal für diese Modusumschaltung nicht notwendigerweise eines der Signale sein, die sonst für den Emulator 30 geschaffen werden. Eine Anzahl anderer Signale an dem System, wie in den Workstation-Anmeldungen beschrieben, kann benutzt werden, aber die nachfolgende Diskussion geschieht aufgrund der Benutzung der Stop-Taste an der Tastatur als Signal für diese Modusumschaltung.
Fig. 7 zeigt Schritte innerhalb Notifier und MainNotifyProc des Emulationsfensters, die zu einer Modusumschaltung von dem Emulations-Modus zum Host-Modus führen, und die deshalb Funktionen des Eingabesignal-Durchleiters 94 in Fig. 4 schaffen. Notifier empfängt einen Stop-Abtastkode, ein Signal, das der Benutzer die STOP-Taste betätigt hat, Kasten 170. Da die STOP- Taste keine Änderung des Eingabefokus bezeichnet, schließt Notifier, daß die zum Zugriff bestimmte angemessene TIP-Tabelle die des gegenwärtigen Eingabefokus ist, welcher während des Emulations-Modus das Emulationsfenster ist. Im Kasten 172 wird auf die TIP-Tabelle des Emulationsfensters zugegriffen, wobei eine Bedeutung für jedes Signal vom Benutzer abgerufen wird. Diese Bedeutung wird im Kasten 174 zum MainNotifyProc des Emulationsfensters geschafft. Die TIP-Tabelle ist so äquivalent zu einem Teil des Modusschaltens im Kasten 84 der Fig. 3, da die Bedeutung irgendeiner Taste außer der STOP-Taste nicht zu einer Modusumschaltung führt und entsprechende Daten entsprechend der jeweiligen Taste dem Emulator 30 zugeführt werden, wie im Kasten 86 in Fig. 3. MainNotifyProc des Emulationsfensters gibt diese Daten in den Vorgang der Behandlung einer Unterrichtung in Kasten 150 in Fig. 6.
Falls MainNotifyProc eine Unterrichtung empfängt mit einem Signal, das eine Modusumschaltung zum Host-Modus bedeutet, wird dieses Ereignis in Kasten 150 durch Aufrufen angemessener Behandlungsroutinen im Kasten 176 behandelt. Einer der Behandlungstests im Kasten 180 besteht darin, zu bestimmen, ob die Maus während der laufenden Emulationssitzung konfiguriert ist. Dieser Test ist äquivalent dem Teil des Modusumschalttests im Kasten 84 der Fig. 3, da er hilft, zu bestimmen, ob der Benutzer eine Modusumschaltung von dem Emulations-Modus zum Host- Modus signalisiert hat. Falls nein, tritt die Behandlung im Kasten 182 aus, da die Modusumschaltung nur dann auftreten kann, wenn die Maus während der Emulation konfiguriert ist. Wenn jedoch die Maus konfiguriert ist, bricht die Behandlung die periodische Unterrichtung von PCEMouseNotify ab, wie vorstehend besprochen, im Kasten 184, was die Auswirkung hat, daß aus dem Emulations-Modus gemäß Kasten 88 in Fig. 3 ausgetreten wird. Dann beginnt die Behandlung wieder mit der Anzeige des Hostzeigers im Kasten 186, was die Auswirkung des Eintritts in den Host-Modus besitzt, gemäß Kasten 70 in Fig. 3. An dieser Stelle tritt die Behandlung aus im Kasten 188 und der Host- Modus hält in der vorstehend beschriebenen Weise an, bis eine weitere Modusumschaltung zum Emulations-Modus zurück erfolgt. Der Hostzeiger kann an der gleichen Position, die er beim letzten Verlassen des Host-Modus gehabt hatte, zum Erscheinen gebracht werden, weil dieser Wert, wie vorstehend bemerkt, gespeichert wurde.
Wie vorstehend bemerkt, schafft der IOP während des Emulations- Modus Daten von dem I/O-Bereich durch BIOS MausDaten 44 im BIOS-Bereich 34 zu dem PCE, wodurch ein Teil der Funktion der Emulations-Schnittstelle 94 ausgeführt wird. Wir wenden uns nun mit mehr Einzelheiten der Prüfung dieser Datenstruktur zu.

C. Struktur von MausDaten

Die Verwendung der Datenstruktur im BIOS-Bereich 34, dem BIOS zugeordneten Speicherraum, zum Übertragen von Daten zu dem PCE ist mit dem in den Workstation-Anmeldungen beschriebenen System durchführbar, da dieses System ein BIOS benutzen kann, das nicht im ROM gespeichert ist. Deshalb können Daten in diesen Speicherbereich eingeschrieben und aus ihm durch den PCE abgerufen werden.
Die Daten innerhalb BIOS MausDaten 44a können auf verschiedene Weise organisiert sein, vorausgesetzt, daß sowohl der IOP als auch die PCE die notwendige Information zum richtigen Zugriff zu der Datenstruktur besitzen. Beispielsweise können zusätzlich zu den durch die Host-CPU in den I/O-Bereich geladenen und durch den IOP übertragenen Daten, wie vorstehend beschrieben, die BIOS MausDaten 44a Daten enthalten, die durch die PCE selbst beim Ausführen von BIOS geschaffen und durch den Maustreiber 46 bei der Bestimmung benutzt werden, ob die Maschine, an der BIOS läuft, zu einer Maus-Emulation fähig ist.
Beim Einladen der BIOS MausDaten 44a führt der IOP eine Aufgabe aus, die den in einer der Workstation-Anmeldungen, US-PA SN 856 526, beschriebenen Emulationsbehandlungs-Aufgaben ähnelt. Wie mit Bezug auf Fig. 33-34 dieser Anmeldung gezeigt und beschrieben, kann ein spezialisiertes Betriebssystem an dem IOP laufen, das eine Mehraufgaben-Schlange stützt, innerhalb der die Aufgaben verwaltet werden. Die Aufgaben werden mit entsprechenden Vorgängen initialisiert, bevor sie für die Schlange verfügbar sind. Die Aufgaben können in einer Anzahl von Zuständen sein, wenn sie nicht in der Schlange sind, zu denen ein Stauzustand, ein Zeitabwarte-Zustand, ein Bedingungsabwarte- Zustand und ein Interrupt-Abwartezustand sind. Wie mit Bezug auf Fig. 35 und 36 gezeigt und beschrieben, reagiert der IOP auf eine Abwärtsunterrichtung von der Host-CPU mit Aufruf zur Konfiguration, mit Booten oder mit Austreten mit entsprechenden Vorgängen.
Durch Analogie mit den anderen bei der Emulation benutzten IOP- Prozeduren werden die das Laden der BIOS MausDaten 44a betreffenden Prozeduren insgesamt als Mausbehandlungsaufgaben bezeichnet. Die Mausbehandlungsaufgaben enthalten einen Initialisierungsvorgang zum Einrichten verschiedener Variablen, die durch andere Mausbehandlungsprozeduren benutzt werden. Wenn beispielsweise andere Prozeduren im Hauptspeicher statt im Lokal-RAM des IOP gespeichert sind, können die Adressen dieser Vorgänge für nachfolgende Verwendung im I/O-Bereich gespeichert sein. Der Initialisierungsvorgang bringt die Mausbehandlungsaufgaben zum Stau. Obwohl die Maus betreffende Daten während der Konfiguration in den I/O-Bereich geladen wurden, wie vorher beschrieben, ändert der IOP den Zustand der Mausbehandlungsaufgaben zum Konfigurationszeitpunkt nicht. Während des Bootens startet ein Mausbehandlungs-Bootvorgang die Mausbehandlungsaufgabe neu, so daß sie in den Wartezustand für Systemstatus eintritt und bereit ist, zum Laufen in die Multiaufgaben- Schlange gesetzt zu werden. Schließlich staut während des Austritts aus der Emulation ein Mausbehandlungs-Austrittsvorgang wiederum die Mausbehandlungsaufgabe und beendet ihre Aktivität.
Während sie aktiv ist, wird die Mausbehandlungs-Hauptaufgabe immer dann zum Ablauf gebracht, wenn sie an der Schlange aufkommt. Diese Hauptaufgabe enthält zwei Teile. Der erste Teil bewegt den Wert, der anzeigt, ob die Maus-Emulation konfiguriert ist, von dem I/O-Bereich zu den BIOS MausDaten 44a und bewegt auch den Wert, der den ausgewählten Maus-Interrupt anzeigt, zu den BIOS-MausDaten 44a. Er benutzt auch den ausgewählten Maus-Interrupt-Wert, um zu bestimmen, an welchem Anschluß ein Maus-Interrupt für die PCE geschaffen werden soll, und speichert diesen Anschluß zum späteren Gebrauch in dem I/O- Bereich. Der erste Teil der Hauptaufgbe endet dann durch Eintreten in das Warten zum Bedingungsstatus mit Warten auf eine Abwärtsunterrichtung von der Host-CPU.
Der zweite Teil der Hauptaufgabe reagiert auf eine Abwärtsunterrichtung mit Einladen der x- und y-Versatzwerte, der Maustasten-Daten und der Lausebits vom I/O-Bereich in BIOS MausDaten 44a. Beim Laden dieser und anderer Daten in BIOS MausDaten 44a lädt die Hauptaufgabe diese in vorgegebene Positionen, so daß der Maustreiber sie finden kann. Das kann beispielsweise dadurch erreicht werden, daß eine Basisadresse für BIOS Mosedata 44a vorgegeben ist, von der jeder Datenposten um eine vorgegebene Größe versetzt ist. Wenn die Daten eingeladen sind, sendet der zweite Teil der Hauptaufgabe einen Interrupt an den PCE an den im I/O-Bereich gespeicherten Anschluß durch Schaffen willkürlicher Daten an diesen Anschluß. Der PCE bedient dann diesen Interrupt, wenn der IOP ihm daraufhin einen Lauf gestattet. Inzwischen ist der zweite Teil der Hauptaufgabe fertig mit Rückkehr zum Warten auf den Bedingungszustand in Erwartung einer weiteren Abwärtsunterrichtung von der Host-CPU.
Zusätzlich zu den durch den IOP geladenen Werten können die BIOS MausDaten 44a andere durch die PCE während der Maus-Emulation benutzte Daten enthalten, wie das System 10 definierende Daten. Derartige Daten können nachfolgend durch den Maustreiber 46 z.B. bei der Bestimmung benutzt werden, ob das System zu einer Maus-Emulation fähig ist.
Im allgemeinen dient der Maustreiber zwei grundsätzlichen Funktionen: er behandelt Interrupts vom Hostmittel 20 oder anderen Quellen, und er behandelt Dienstleistungs-Anforderungen von der Mausanwendung 42 oder anderen Anwendungen höheren Niveaus, welche mausbezogene Dienstleistungs-Anforderungen schaffen. Diese Funktionen sind darauf bezogen, weil der Maustreiber 46 die Daten, die er durch Behandlungs-Interrupt vom Hostmittel 20 erhält, bei der Behandlung der Dienstleistungs-Anforderungen von Anwendung höheren Niveaus benutzt. Eine Definition der Standardreaktionen auf die Standard-Dienstleistungsanforderungen vorausgesetzt, und auch die den von dem Hostmittel 20 verfügbaren Daten vorausgesetzt, ist es eine geradlinige Weiterführung, einen Maustreiber zu schaffen, der entsprechende Daten vom Hostmittel 20 enthält und daraufhin diese Daten benutzt, um die Standardreaktionen auf Standard- Dienstleistungsanforderungen zu schaffen.
Die in BIOS MausDaten 44a enthaltenen Daten hängen von dem System ab, an dem die Erfindung verwirklicht ist. Wenn sie in dem in den Workstation-Anmeldungen beschriebenen System verwirklicht ist, können Bios MausDaten 44a alle durch den I/O- Bereich von der Host-CPU zum IOP übertragenen mausbezogenen Daten enthalten. Wie vorstehend beschrieben, enthalten die Daten auch solche, die anzeigen, ob die Maus konfiguriert ist; Daten, die anzeigen, welcher Interrupt der Maus-Interrupt ist; Daten, die die x- und y-Versätze anzeigen; Daten, die anzeigen, welche Maustaste geklickt wurde; und Lausedaten, die anzeigen, ob die Mauspositions- oder Tastendaten aktualisiert worden sind. Diese Daten sind für den Maustreiber 46 ausreichend, um die Standardreaktionen auf die Standard-Dienstleistungsanforderungen für den Mikrosoft-Maustreiber zu schaffen.
Der Interruptbehandler im Maustreiber 46 reagiert auf einen Interrupt vom Hostmittel 20 durch Benutzen der MausDatenadresse zum Zugriff auf BIOS MausDaten 44a, und untersucht dann die Lausebitdaten. Wenn keine Änderung gemacht wurde, besteht keine Notwendigkeit, weitere Daten von BIOS MausDaten 44a abzurufen, so daß die Interrupt-Behandlung austritt. Wenn die Lausebitdaten eine Änderung bei den Versätzen anzeigen, kann der Interrupt-Behandler einen Merker oder einen anderen Wert setzen, der neue Daten bezeichnet, und die x- und y-Versatzdaten aus BIOS MausDaten 44a abholen. Wenn die Lausebitdaten eine Änderung bei der Maustaste bezeichnen, kann der Behandler in gleicher Weise einen Merker oder einen Wert setzen, der neue Daten bezeichnet und die geklickte Taste identifizierende Daten von den BIOS MausDaten 44a abholen. Wenn dann neue Daten empfangen wurden, kann der Interrupt-Behandler jedes angemessene weitere Behandeln durchführen, um die neuen Daten in eine Form zu bringen, die wirksam zum Behandeln von Dienstleistungsanforderungen zu benutzen ist. Das kann beispielsweise dadurch getan werden, daß durch die Dienstleistungs-Anforderungsbehandlung benutzte Variable aktualisiert werden. Schließlich tritt die Interrupt-Behandlung aus, und führt den PCE zu den ablaufenden Vorgängen zurück, wenn der Interrupt empfangen wurde, oder zum nächsten Interrupt.
Der Mikrosoft-Maustreiber reagiert auf Dienstleistungs-Anforderungen von Anmeldungen höheren Niveaus, welche die Form von BIOS-Interrupts 10h und 33h annehmen. Interrupt 10h ist eine Video-Dienstleistungsanforderung und Interrupt 33h eine Maus- Dienstleistungsanforderung. Zusätzlich können Anwendungen höheren Niveaus den Mikrosoft-Maustreiber unter Benutzung des Dateinamens Mouse.com aufrufen. Deshalb sollte der Maustreiber 46 den Dateinamen Mouse.com besitzen, so daß er läuft, wenn eine Anwendung hohen Niveaus Mouse.com aufruft. Zusätzlich sollte der Maustreiber 46 angemessen auf BIOS-Interrupts 10h und 33h reagieren, um die Standardreaktionen auf die durch den Mikrosoft-Maustreiber behandelten Standard-Dienstleistungsanforderungen zu schaffen. Zusätzlich reagiert, wie vorher bemerkt, der Maustreiber 46 auf Interrupts vom Hostmittel 20.
Damit er arbeiten kann muß der Maustreiber 46 installiert werden. Das kann beim ersten Mal dadurch erledigt werden, daß der Benutzer den Befehl "mouse" in Reaktion auf die DOS-Abfrage schafft. Der Installationsvorgang kann das Überprüfen eines Wertes aus BIOS MausDaten 44a oder von anderswo enthalten, welcher den Maschinentyp bezeichnet. Wenn der Maschinentyp nicht angemessen oder wenn die Maus-Emulation nicht konfiguriert ist, wie in BIOS MausDaten 44a bezeichnet, kann der Installationsvorgang ohne Installieren abgehen, wodurch entsprechende Nachrichten geschaffen werden. Sonst kann der Installationsvorgang die Empfindlichkeit der Maus festsetzen und die vorstehend beschriebenen Interrupts ansetzen, so daß die angemessenen Abläufe beim Maustreiber 46 in Reaktion auf jeden Interrupt aufgerufen werden. Das Einsetzen der Interrupts enthält das Abholen des durch den Benutzer aus BIOS MausDaten 44a ausgewählten Maus-Interrupts und Installieren des entsprechenden Interrupt-Vektors zum Aufrufen der Interrupt- Behandlung, wenn der Interrupt empfangen wird. Das Festsetzen der Interrupts enthält auch das Festsetzen der BIOS-Interrupts mit jeweiligen Vektoren zum Aufrufen der entsprechenden Dienstleistungsanforderungs-Behandler im Maustreiber 46. Der Installationsvorgang kann sich auch selbst beseitigen, wenn er aus dem freien Speicherraum austritt.
Während der Ausführung der Anwendung höheren Niveaus wird der Emulator 30 Ausgangssignale zum Aktualisieren seiner Anzeige schaffen. Das kann, wie in den Workstation-Anmeldungen beschrieben, so erfolgen, daß die Anzeigesteuerung 98 die Komponenten des Hostmittels 20 enthält, welche Anzeige-Aktualisierungen durch den Emulator 30 erfassen und welche zu seinem Anzeigebereich im Speicher Zugriff nehmen, um die aktualisierte Information abzuholen.

D. Vermischtes

Die vorliegende Erfindung kann auf viele Arten verwirklicht werden. Die Mausmodus-Schaltsignale können irgendwelche angemessenen Signale sein, und es kann mehr als ein Schaltsignal zum Umschalten zwischen Host- und Emulations-Modus verfügbar sein. Der beim Umschalten zwischen den Modi befolgte Vorgang hängt in sehr hohem Maße von dem System ab, an welchem die Erfindung ausgeführt wird. Beispielsweise braucht, wie vorher bemerkt, der Emulator 30 kein Koprozessor zu sein, sondern könnte eine aus einer Anzahl von Aufgaben oder Modi bei einem Prozessor sein, der auch Software ausführt, um das Hostmittel 20 zu schaffen. In gleicher Weise können in Verbindung mit der Verwendung von BIOS MausDaten 44a zur Datenübertragung zum Emulator 30 die bestimmten übertragenen Daten jeder beliebige Datensatz sein, der für den jeweils an dem System laufenden Maustreiber geeignet ist. Weiter kann eine Datenstruktur wie BIOS MausDaten 44a zum Übertragen anderer Daten zwischen dem Hostmittel 20 und dem Emulator 30 benutzt werden, vorausgesetzt, daß die am Emulator 30 laufenden Anwendungen keine Direktaufrufe an Anschlüsse in dem emulierten Zielsystem richten.
Die Erfindung ist allgemein aufinteraktive Schnittstellen anwendbar und der Ausdruck "Anzeige", wie er hier benutzt wird, soll jede Darstellung von Daten für einen Benutzer einschließen, in welchen ein Zeiger zum Anzeigen einer Position benutzt werden kann. Eine Anzeige kann so geschaffen werden durch Erzeugen seiner Bitaufzeichnung oder durch jede andere Technik, welche Daten zum Angeben der Inhalte der Anzeige kombiniert. Der Ausdruck "Zeiger" ist nicht aufirgendeine bestimmte Form, Größe oder einen anderen Kennwert begrenzt, sondern kann jedes erfaßbare Anzeichen einer Position innerhalb einer Anzeige sein. Zeigersteuerung enthält deshalb alle Stufen, welche einen Zeiger innerhalb einer Anzeige positionieren, seine Kennwerte bestimmen oder sonst die Art und Weise bestimmen, in der er in einer Anzeige enthalten ist.
Obwohl die Erfindung mit Bezug auf verschiedene Verwirklichungen, zusammen mit Abwandlungen, Variationen und Erweiterungen derselben beschrieben wurde, können andere Verwirklichungen, Abwandlungen, Variationen und Erweiterungen innerhalb des Erfindungsbereichs fallen, wie er durch die Ansprüche definiert wird.

Claims

1. Zeiger-Steuersystem für einen interaktiven Computer, das umfaßt:

erstes Mittel zum Schaffen eines ersten Abbildes zur Anzeige, welches erste Mittel zum Ausführen von Zeiger-Anzeige in dem ersten Abbild betätigbar ist;

zweites Mittel zum Schaffen eines zweiten Abbildes zur Anzeige, welches zweite Mittel zum Ausführen von Zeigersteuerung innerhalb des zweiten Abbildes betätigbar ist; wobei das zweite Mittel auf das erste Mittel reagiert, um das erste Abbild als ein Teil des zweiten Abbildes einzuschließen; und

Eingabemittel zum Empfangen von Signalen von einem Benutzer, welche Signale von dem Benutzer ein Umschaltanforderungssignal enthalten, wobei das Eingabemittel die Umschaltanforderungssignale für das zweite Mittel schafft;

wobei das zweite Mittel weiter in Reaktion auf das Umschaltanforderungssignal zum Umschalten zwischen einem ersten Modus, in dem das erste Mittel Zeigersteuerung ausführt, und einem zweiten Modus, in dem das zweite Mittel Zeigersteuerung ausführt, bestimmt ist.

2. System nach Anspruch 1, bei dem das erste Mittel einen Emulator umfaßt, der eine Abfolge von Instruktionen einschließlich Zielsystem-Instruktionen ausführt, die durch den Zentralprozessor eines Zielsystems, das emuliert wird, ausführbar sind.

3. System nach Anspruch 2, dem das Schaltmittel auf ein Umschaltsignal von einer Maus reagiert, wobei die Abfolge von Zielsystem-Instruktionen eine durch den Zentraiprozessor des Zielsystems ausführbare Mausanwendung enthält.

4. System nach Anspruch 2, bei dem der Emulator während der Ausführung der Zielsystem-Instruktionen Ausgangssignale schafft und Eingangssignale empfängt; wobei das zweite Mittel ein Host-System umfaßt zum Empfangen von Ausgangssignalen von dem Emulator und zum Schaffen von Eingangssignalen in der Weise, daß der Emulator die Ausführung der Abfolge von Zielsystem-Instruktionen fortsetzt.

5. System nach Anspruch 1, bei dem das zweite Mittel die erste Anzeige innerhalb eines Fensters in der zweiten Anzeige enthält; wobei das erste Mittel Zeigersteuerung ausführt durch Einschließen eines Zeigers, der eine Position innerhalb der ersten Anzeige im Fenster bezeichnet.

6. System nach Anspruch 5, das weiter umfaßt Eingabemittel zum Empfangen von Eingangssignalen von einem Benutzer, welche Eingangssignale Zeigerbewegung bezeichnende Zeigerbewegungssignale enthalten, und das zweite Mittel weiter, während das erste Mittel Zeigersteuerung ausführt, betätigbar ist, die Zeigerbewegungssignale zu empfangen und skalierte Zeigerbewegungssignale für das erste Mittel aufgrund der Zeigerbewegungssignale zu schaffen.

7. System nach Anspruch 1, das weiter umfaßt Konfigurierungsmittel zum Empfangen einer Benutzerauswahl, die bezeichnet, ob das erste Mittel Zeigersteuerung ausführt, wobei das Schaltmittel weiter bestimmt, ob die Zeigersteuerung aufgrund der Benutzerauswahl von dem Konfigurierungsmittel umzuschalten ist.

8. Vorrichtung zum Ausführen von Zeigersteuerung, welche Zeigersteuerung den Zeiger positioniert oder eine Kenneigenschaft eines in einem Abbild enthaltenen Zeigers bestimmt; welche Vorrichtung umfaßt:

Eingabeschaltung zum Empfang von Signalen von einem Benutzer; welche Signale von dem Benutzer ein Umschaltanforderungssignal zum Umschalten des Modus der Zeigersteuerung enthalten;

Bearbeitungsschaltung, die zum Empfang von Signalen von dem Benutzer durch die Eingangsschaltung angeschlossen ist; und

Anzeigeschaltung zum Darbieten von Abbildern; welche Abbilder Zeiger enthalten;

und die Bearbeitungsschaltung betätigbar ist, um:

eine Abfolge von Emulationsinstruktionen einschließlich Zielsystem-Instruktionen auszuführen, die durch einen Zentralprozessor eines emulierten Zielsystems ausgeführt werden können; wobei die Bearbeitungsschaltung beim Ausführen der Abfolge von Emulationsinstruktionen:

ein erstes Abbild zur Anzeige schafft; und

in einem ersten Zeigersteuermodus Zeigersteuerung innerhalb des ersten Bildes ausführt;

eine Abfolge von Host-Instruktionen ausführt zum Durchführen von Host-Betätigungen, die eine Umgebung so schaffen, daß die Bearbeitungsschaltung fortfährt, die Abfolge von Emulationsinstruktionen auszuführen; die Bearbeitungsschaltung beim Ausführen der Host-Instruktionsfolge:

ein zweites Anzeigeabbild durch die Anzeigeschaltung schafft, welches zweite Abbild das erste Abbild enthält;

in einem zweiten Zeigersteuermodus Zeigersteuerung mit dem zweiten Abbild ausführt; und

in Reaktion auf das Umschaltanforderungssignal den Zeigersteuermodus zwischen dem ersten und dem zweiten Modus umschaltet.

9. Vorrichtung zum Durchführen von Zeigersteuerung, Zeigersteuerpositionierung oder Definieren einer Kenngröße eines in einem Abbild enthaltenen Zeigers; welche Vorrichtung umfaßt:

Anzeigeschaltung zum Darbieten von Abbildern; welche Abbilder Zeiger enthalten;

wobei die Bearbeitungsschaltung umfaßt:

einen Emulationsprozessor zum Ausführen einer Abfolge von Emulationsinstruktionen einschließlich Zielsystem-Instruktionen, die ausgeführt werden können durch einen Zentralprozessor eines Zielsystems, das emuliert wird; wobei der Emulationsprozessor beim Ausführen der Folge von Emulationsinstruktionen:

ein erstes Abbild zur Anzeige schafft; und

in einem ersten Zeigersteuermodus Zeigersteuerung innerhalb der ersten Abbildes ausführt;

Host-Schaltung zum:

Schaffen von Ausgangssignalen für den Emulationsprozessor und Empfangen von Eingangssignalen von dem Emulationsprozessor während der Ausführung von Zielsystem-Instruktionen, so daß der Emulationsprozessor das Ausführen der Abfolge von Emulationsinstruktionen fortsetzt;

Schaffen eines zweiten Abbildes zur Anzeige durch die Anzeigeschaltung, wobei das zweite Abbild das erste Abbild enthält;

in einem zweiten Zeigersteuermodus Ausführen von Zeigersteuerung innerhalb des zweiten Abbildes; und

in Abhängigkeit von dem Umschaltanforderungssignal, Umschalten des Zeigersteuermodus zwischen dem ersten Modus und dem zweiten Modus.