DE69903737T2 - Integriertes anwendungsprogrammverwaltungssystem - Google Patents

Description

Technisches Gebiet
• Die vorliegende Erfindung bezieht sich auf Anwendungsprogramm-Interoperabilität und im Besonderen auf ein durch einen Benutzer konfigurierbares Programm, das gleichzeitig ablaufende Anwendungsprogramme verwaltet. Im Spezifischen bezieht sich die Erfindung auf ein Verfahren zum Koordinieren von Computerprogrammen gemäß dem Oberbegriff des Anspruchs 1, auf ein Computersystem gemäß Anspruch 13 und auf ein computerlesbares Medium, das in Anspruch 22 definiert ist.
Hintergrund der Erfindung
• Der Personalcomputer ("PC") hat sich während des letzten Jahrzehnts in ein nützliches und relativ benutzbares, elektronisches Heimgerät weiterentwickelt. Die steigende Nützlichkeit von PCs im Heim entstand sowohl durch die Entwicklung von leistungsfähigen Anwendungsprogrammen wie z. B. graphisch orientierten Textverarbeitungsanwendungen und Internetbrowsern, als auch durch die gestiegene Anschlussfähigkeit an andere übliche elektronische Haushaltsgeräte einschließlich Telefonen, Anrufbeantwortern, Faxgeräten, CD- Wiedergabegeräten und Fernsehgeräten, und Kompatibilität mit diesen. Der PC entwickelt sich folglich zu einer zentralen Verwaltungseinrichtung zum Verwalten eines Betriebs von vielen Typen von elektronischen Gebrauchsgeräten sowie zum Bereitstellen einer leistungsfähigen, computerorientierten Plattform, auf welcher fortgeschrittene, Konsumenten-orientierte Anwendungsprogramme ausgeführt werden können, weiter. Die steigende Benutzbarkeit von PCs entstand mit der Einführung sowohl von Betriebssystemen als auch von Anwendungsprogrammen, die benutzerfreundliche, graphische Benutzeroberflächen bereitstellen. Benutzer sind jetzt in der Lage, fortgeschrittene Programme mittels Maus und minimalen Tastatureingaben in einfache und einheitlich präsentierte graphische Anzeigen, die graphischen Schaltflächen, Pull-down- Menüs und ändere einfach zu benutzende graphische Steuerflächen aufweisen, zu starten und zu steuern.
• Zahlreiche separate Anwendungsprogramme, die eine Schnittstelle zu externen peripheren Geräten bilden und diese kontrollieren, sind allgemein verfügbar geworden. Diese Anwendungen schließen beispielsweise Anwendungsprogramme, die eine graphische Benutzeroberfläche für einen Telefonanrufbeantworter bereitstellen, ein. CD-ROM-Geräte, die jetzt als Grundausstattung von PC-Systemen bereitgestellt werden, können bespielte Musik-CDs über an das PC-System angeschlossene Lautsprecher wiedergeben und es wurden Anwendungsprogramme entwickelt um ein Wiedergeben von bespielten Musik- CDs zu vereinfachen. Es wurden Fernsehanwendungsprogramme entwickelt, die es dem Benutzer gestatten, Fernsehübertragungen in einem Multimediafenster, das auf dem an den PC angeschlossenen Monitor dargestellt wird, live zu verfolgen. Es wurden Telefonkontrollanwendungen entwickelt, um auf einem PC ausgeführt zu werden, die es einem Benutzer erlauben, Telefonanrufe mittels des Mikrofons und der Lautsprecher, die mit modernen PCs standardmäßig mitgeliefert werden, anzunehmen und zu führen.
• Obwohl große Schritte unternommen wurden, den Nutzen von Heim-PCs zu erhöhen, bleiben gewisse Benutzbarkeitsprobleme bestehen. Ein signifikantes Benutzbarkeitsproblem ist das des Koordinierens von gleichzeitig ablaufenden Anwendungsprogrammen, so dass der PC und die Anwendungen, die auf dem PC ausgeführt werden, ein nahtloses, intern koordiniertes System darstellen, das sich verhält, wie es ein Benutzer von einem integrierten System verlangt und erwartet.
• Ein Aspekt dieses Benutzbarkeitsproblems ist das der Implementierung von Anwendungsprogrammen zum Steuern von externen Geräten und zum Bilden einer Schnittstelle mit diesen derart, dass die Anwendungsprogramme während der gleichzeitigen Ausführung intelligent zusammenarbeiten können. Als ein Beispiel für die Notwendigkeit, gleichzeitig ablaufende Anwendungsprogramme zu koordinieren, bedenke man ein Szenario, bei welchem ein PC-Benutzer eine Telefonanwendung gestartet hat, die die Telefonleitung des Benutzers nach eingehenden Anrufen überwacht, und gleichzeitig entweder ein Fernsehprogramm auf dem PC verfolgt oder eine bespielte Musik-CD, die auf dem PC wiedergegeben wird, anhört. Ein eingehender Telefonanruf kann das Telefonanwendungsprogramm veranlassen, den eingehenden Anruf dem PC- Benutzer entweder durch einen simulierten Klingelton oder durch eine Art von graphisch dargestelltem Hinweis oder durch beides zu signalisieren. Diese akustischen oder visuellen Signale der Telefonanwendung können das Verfolgen des Fernsehprogramms durch den Benutzer unterbrechen oder dieses stören. Beispielsweise kann die Telefonanwendung ein Informationsfenster hervorbringen, das die Auswahlmöglichkeiten für die Reaktion des Benutzers auf den eingehenden Telefonanruf anzeigt, welche den Anruf direkt zu beantworten, den Anruf zu ignorieren oder den Anruf an den Anrufbeantworter weiterzuleiten einschliessen. Falls dieses Anzeigefenster das Fenster, durch welches das Fernsehprogramm angezeigt wird, überlappt oder verdeckt, kann der Benutzer einen Teil der Sendung versäumen und kann gefordert sein, die Maus oder die Tastatur zu handhaben, um auf das Telefonanwendungsprogramm zu reagieren oder um das Fernsehfenster wieder zurück in den Vordergrund des Anzeige-Bildschirms zu bringen. In ähnlicher Weise kann ein Beliebiges der vielen möglichen, gleichzeitig ablaufenden Anwendungsprogramme auf Ereignisse von außen oder auf durch einen Benutzer oder durch ein Programm erzeugte Ereignisse in einer derartigen Weise reagieren, dass es andere gleichzeitig ablaufende Anwendungen stört.
• Es ist theoretisch möglich, integrierte Anwendungen zu erstellen, die ihre gegenseitigen Laufzeitaktivitäten auf dem PC erkennen und versuchen, diese Aktivitäten zu koordinieren. Praktisch jedoch, ist das Aufbauen solcher integrierter Anwendungen nahezu unmöglich. Anwendungen können von unterschiedlichen Einheiten entwickelt sein, wie Einzelpersonen oder Firmen. Im Allgemeinen haben diese unterschiedlichen Entwicklungseinheiten keine Möglichkeit zu wissen, welche Art von Aktivitäten von Anwendungsprogrammen, die von anderen Einheiten entwickelt wurden, zu erwarten sind, und die Entwicklungseinheiten haben im Allgemeinen keine Mittel, eine Kommunikation zwischen den verschiedenen Anwendungsprogrammen zur Laufzeit herzustellen. Deshalb wurde eine Notwendigkeit für eine Technologie erkannt, die angewendet werden kann, um Aktivitäten von gleichzeitig ablaufenden Anwendungsprogrammen zu koordinieren, so dass sie sich während der Ausführung nicht gegenseitig stören und so dass die gleichzeitig ablaufenden Programme miteinander kooperieren, um ein vereinheitlichtes und leicht zu verwaltendes System von kooperierenden Anwendungsprogrammen dem PC-Benutzer bereitzustellen.
• In Übereinstimmung mit dem Oberbegriff eines jeden der Ansprüche 1 und 13 offenbart "CUSTOMIZING THE LAN NETVIEW FIX ACTION TABLE" IBM TECHNICAL DISCLOSURE BULLETIN, Vol. 37, Nr. 4B, 1. April 1994, Seiten 115/116 XP000451194 ein Verfahren zum Koordinieren von Computerprogrammen, die gleichzeitig auf einem Computersystem ausgeführt werden, und ein Computersystem zum Koordinieren von Computerprogrammen, wobei ein Überwachungsprogramm Ereignisse detektiert, die auf einem LAN (Local Area Network) auftreten, und dann Befehle an das überwachte System in Reaktion auf diese Schlüsselereignisse sendet, wo die Befehle in begrenzter Weise durch den Benutzer konfigurierbar sind. Die Druckschrift offenbart Identifikation und Ausführung von Befehlen, die in einer "fix action table" spezifiziert sind und welche von einem "fix program" kontrolliert werden. Die Druckschrift veröffentlicht nicht die Koordination der gleichzeitig ablaufenden Programme.
• Die vorliegende Erfindung stellt ein Verfahren und ein System, wie sie in Anspruch 1 bzw. Anspruch 13 definiert sind, bereit. Zusätzlich schafft die vorliegende Erfindung ein computerlesbares Medium, welches Computerbefehle enthält, die derart ausgestaltet sind, gleichzeitig ablaufende Computerprogramme auf einem Computersystem zu koordinieren, wie es in dem Anspruch 13 definiert ist.
Zusammenfassung der Erfindung
• Ausführungsformen der vorliegenden Erfindung schaffen ein Verfahren und ein System zum Koordinieren der gleichzeitigen Ausführung von Computerprogrammen auf einem Computersystem. In einer Ausführungsform wird ein Satz von Schlüsselereignissen, die gewisse Zustände und Bedingungen beschreiben, die während der Ausführung des Computerprogramms erzeugt werden können, zusammen mit einem Satz von Befehlen für jedes Computerprogramm, welche von diesem Computerprogramm akzeptiert und in Reaktion auf das jeweilige Schlüsselereignis ausgeführt werden, in einer Datenbank gespeichert. Wenn ein Computerprogramm während der Ausführung einen Zustand oder eine Bedingung generiert, die mit einem Schlüsselereignis korrespondiert, sendet das Computerprogramm eine Benachrichtigung über das Auftreten des Schlüsselereignisses an ein Koordinationsmodul. Das Koordinationsmodul ruft dann aus einer Datenbank die durch jedes der Computerprogramme auszuführenden Befehle ab und sendet die abgerufenen Befehle zur Ausführung an die Computerprogramme. Ein Computerbenutzer kann mit einer graphischen Benutzeroberfläche interagieren, um das System von gleichzeitig ablaufenden Computerprogrammen, durch Auswahl eines oder mehrerer Befehle, die von jedem Computerprogramm bei Auftreten eines Schlüsselereignisses ausgeführt werden, zu konfigurieren.
Kurzbeschreibung der Zeichnungen
• Fig. 1 zeigt eine schematische Übersicht einer Ausführungsform des integrierten Anwendungsmanagementsystems.
• Fig. 2-6 zeigen Beispiele der Bestandteile der obersten Hierarchie von Menüs der graphischen Benutzeroberfläche des integrierten Anwendungsmanagementsystems.
• Fig. 7 zeigt ein Flußdiagramm für die Hauptbenutzeroberfläche.
• Fig. 8-13 zeigen Beispiele einer Einricht-Benutzeroberfläche.
• Fig. 14 zeigt ein Auswählen eines Befehls aus einem Befehlsformular.
• Fig. 15 zeigt ein Flußdiagramm für das Einrichtprogramm, das in Reaktion auf die Benutzerauswahl der Einrichtoption im Hauptmenü aufgerufen wird.
• Fig. 16 ist ein schematisches Diagramm des Anwendungskontrollmoduls und der unterstützenden Betriebssystemeinrichtungen, die von dem Anwendungskontrollmodul verwendet werden.
• Fig. 17 zeigt ein Flußdiagramm für den Empfänger-Thread des Anwendungskontrollmoduls.
• Fig. 18 zeigt ein Flußdiagramm für den Zusteller-Thread.
• Fig. 19 zeigt ein Flußdiagramm für das Startprogramm, das in Reaktion auf Benutzereingaben in der Hauptbenutzeroberfläche aufgerufen wird.
Detaillierte Beschreibung der Erfindung
• Ausführungsformen der vorliegenden Erfindung schaffen ein Verfahren und ein System zum Integrieren und Verwalten von Anwendungsprogrammen, die auf einem Computersystem ausgeführt werden und die einfache Schnittstellenstandards erfüllen, die von dem Integrations- und Verwaltungssystem erwartet werden. Diese Ausführungsformen verschaffen einem Computersystembenutzer die Fähigkeit, Interaktionen zwischen zwischen konformen Anwendungsprogrammen zu konfigurieren, so dass diese in einer Weise zusammenarbeiten, die vom Benutzer gewünscht wird. Diese Ausführungsformen erlauben es einem Computersystembenutzer, eine Liste von konformen Anwendungsprogrammen, die auf dem Computersystem installiert sind, durchzusehen. Die Liste weist für jedes Anwendungsprogramm eine Unteraufzählung der Schlüsselereignisse, die während der Ausführung des Anwendungsprogramms auftreten können, und eine Unteraufzählung von verschiedenen Aufgaben oder Befehlen auf, die die Anwendung auf das Anfordern durch das unten beschriebenen integrierte Anwendungsmanagementsystems (Integrated Application Management System, "IAMS") ausführen kann, das eine Ausführungsform der vorliegenden Erfindung darstellt.
• Diese Listen von konformen Anwendungsprogrammen, einschließlich der Befehle, die jedes Anwendungsprogramm ausführen kann, und der Schlüsselereignisse, die während der Ausführung eines jeden Anwendungsprogramms auftreten können, können dem Benutzer durch eine graphische Benutzeroberfläche angezeigt werden, die es dem Benutzer erlaubt, die Befehle zu spezifizieren, die jedes Anwendungsprogramm in Reaktion auf das Auftreten eines jeden Schlüsselereignisses ausführen soll. Beispielsweise, falls ein Telefonanwendungsprogramm eingehende Telefonanrufe empfangen kann, kann das Auftreten eines eingehenden Telefonanrufs als ein Schlüsselereignis, das dem Telefonanwendungsprogramm zugeordnet ist, erscheinen. Der Benutzer kann spezifizieren, dass das Telefonanwendungsprogramm einen Antwortbefehl in Reaktion auf das Schlüsselereignis über den eingehenden Telefonanruf ausführt. Der Benutzer kann auch spezifizieren, dass eine MPEG-Filmdarstellungsanwendung einen Stopp- oder Pause-Befehl in Reaktion auf das Schlüsselereignis über den eingehenden Telefonanrufs ausführt. Wenn der Benutzer später einen Film, der auf einem Computersystem dargestellt wird, verfolgt und gleichzeitig ein Telefonanruf von dem Computersystem empfangen wird, erteilt das IAMS einen Antwortbefehl an die Telefonanwendung und einen Stopp- oder Pause-Befehl an die MPEG-Filmdarstellungsanwendung. Als Folge reagiert das System auf den eingehenden Telefonanruf in der benutzerfreundlichen Weise, die der Benutzer zuvor durch die graphische Benutzeroberfläche spezifiziert hat, nämlich der MPEG-Film hält an, um es dem Benutzer zu erlauben, den eingehenden Telefonanruf anzunehmen. Folglich läuft das IAMS im Hintergrund, um die Zusammenarbeit von mehreren konformen Anwendungen, die gleichzeitig auf einem Computersystem ablaufen, zu koordinieren.
• Das IAMS kann im Computercode fest codiert sein, zum Umfassen einer Liste von konformen Anwendungsprogrammen zusammen mit Unteraufzählungen, die mit jedem Eintrag in der Liste von konformen Anwendungsprogrammen korrespondieren, welche die von jedem Anwendungsprogramm generierten Schlüsselereignisse und implementierten Befehle enthält. Alternativ kann das IAMS jedes konforme Anwendungsprogramm und die von jedem der konformen Anwendungsprogramme erzeugten Schlüsselereignisse und die von jedem der konformen Anwendungsprogramme implementierten Befehle zur Laufzeit identifizieren. Diese zur Laufzeit erhaltene Information kann von dem IAMS direkt von konformen Anwendungsprogrammen durch Standard-Laufzeitschnittstellen abgerufen werden, die von jedem der konformen Anwendungsprogrammen unterstützt werden. Als eine dritte Alternative kann statt dessen diese Information durch die konformen Anwendungsprogramme in der Windows-Registrierdatenbank abgelegt werden und danach vom IAMS aus der Windows-Registrierdatenbank abgerufen werden. Die Windows-Registrierdatenbank wird vom Windows-Betriebssystem der Microsoft Corporation bereitgestellt. Die letzten zwei Alternativen verschaffen dem Benutzer große Flexibilität, indem sie es dem Benutzer erlauben, neue konforme Anwendungsprogramme in das koordinierte System von Anwendungsprogrammen einzubeziehen, das vom IAMS verwaltet wird, ohne vom Benutzer zu verlangen, ein neues IAMS zu beziehen oder eine komplizierte Rekonfiguration des IAMS vorzunehmen.
• Das IAMS weist eine Hauptbenutzeroberfläche (Main User Interface; "MUI"), eine Benutzerpräferenzanwendung (User Preference Application; "UPA"), ein Anwendungskontrollmodul (Application Control Module; "ACM") und eine Anzahl von kooperierenden Anwendungen auf, die eine minimale Menge von Logik und Interprozesskommunikations-Unterstützung zum Bilden einer Schnittstelle zum ACM aufweisen. Das MUI erlaubt es dem Benutzer, eines oder mehrere der konformen Anwendungsprogramme und das UPA zu starten. Unter Benutzung des UPA ist ein Benutzer in der Lage, ein kooperierendes Anwendungsprogramm zu konfigurieren, um in bestimmter, wohldefinierter Weise auf interne Schlüsselereignisse, die von dem Anwendungsprogramm erzeugt werden sowie auf externe Schlüsselereignisse, die von anderen konformen Anwendungsprogrammen erzeugt werden, zu reagieren. Während die Anwendungsprogramme ablaufen, exportieren sie intern erzeugte Schlüsselereignisse an das ACM und empfangen im Gegenzug von dem ACM Befehle, die den Anwendungsprogrammen anzeigen, wie sie auf die Ereignisse reagieren sollen.
• Folglich verschafft das IAMS einen Benutzer die Fähigkeit, die verschiedenen konformen Anwendungsprogramme zu konfigurieren, um in bestimmter, wohlbekannter Weise auf jeden unterschiedlichen Typ von Schlüsselereignis, der von diesem Anwendungsprogramm oder irgendeiner anderen konformen Anwendung erzeugt werden kann, zu reagieren, und das ACM stellt einen Mechanismus bereit durch welchen jedes Anwendungsprogramm über die Reaktionen auf Schlüsselereignisse, welche von dieser Anwendung während ihrer Ausführung erwartet werden, benachrichtigt wird.
• Die unten beschriebene Ausführungsform ist implementiert, um auf Personalcomputern unter dem Windows-Betriebssystem abzulaufen und benützt das Microsoft Component Object Model ("COM") ("Inside OLE", 2. Auflage, Kraig Brockschmidt, 1995), um zwischen den Anwendungsprogrammen und dem ACM zu kommunizieren. Ein integriertes Anwendungsmanagementsystem (Integrated Application Management System; "IAMS") kann jedoch auf vielen unterschiedlichen Typen von Multitasking-Betriebssystemen und Hardware- Plattformen implementiert werden.
• Fig. 1 zeigt einen schematischen Überblick über das IAMS. Das IAMS läuft auf einem Personalcomputer 101 mit einer LCD-Frontplattenanzeige 102, die Informationen bezüglich des Status von angeschlossenen peripheren Geräten, wie Telefonanrufbeantworter und CD-Wiedergabegerät anzeigt, mit einer angeschlossenen Tastatur 103, mit einem Anzeigebildschirm 104, mit einer Telefonleitung 105 und mit einem DVD-Gerät 106. Man beachte, dass die Telefonleitung 105 im Allgemeinen entweder ein externes oder ein internes Modem einschließt, welches in Fig. 1 nicht dargestellt ist. Die verschiedenen Eingabe- und Ausgabegeräte, die die Tastatur, den Anzeigebildschirm, die Frontplattenanzeige, die Telefonleitung und das DVD-Gerät umfassen, sind elektronisch mit dem PC über Hardwarecontroller, die durch Doppelpfeile 107-111 dargestellt sind, mit hierarchischen gerätetreibenden Komponenten und Datenaustausch-Komponenten des Betriebssystems des Personalcomputer 112 gekoppelt. Das Multitasking-Betriebssystem 112 unterstützt die gleichzeitige Ausführung einer CD-Wiedergabeanwendung 113, einer Fernsehanwendung 114, eines Web-Browsers 115, einer Audiowiedergabeeinrichtung 116, einer MPEG-Filmwiedergabeeinrichtung 117 und einer Telefonanwendung 118. Diese gleichzeitig ablaufenden Anwendungsprogramme haben Schnittstellen zu noch einem weiteren, anderen ablaufenden Prozess, dem ACM 118, durch welchen die Anwendungsprogramme ihre Aktivitäten koordinieren. Jedes der Anwendungsprogramme, wie auch das ACM, kommuniziert direkt mit dem Betriebssystem und tauscht Daten direkt mit diesem aus, was in Fig. 1 durch eine Schar von verbundenen Pfeilen mit einer Spitze 119 gezeigt ist. Jedes Anwendungsprogramm kommuniziert direkt mit dem ACM unter Benutzung von COM, was in Fig. 1 durch Pfeile mit zwei Spitzen, inklusive einem Pfeil 120 mit zwei Spitzen angezeigt ist. Ein Benutzer des Personalcomputers kann direkt mit dem ACM und mit jedem der Anwendungsprogramme mittels graphischer Benutzeroberflächen interagieren, die auf dem Anzeigebildschirm 104 dargestellt sind. Anwendungen erzeugen Darstellungen von graphische Benutzeroberflächen durch Betriebssystemaufrufe und erhalten Benutzereingaben in diese graphischen Benutzeroberflächen in der Form von Ereignisnachrichten, die durch das Betriebssystem erzeugt werden.
• Das ACM fungiert als zentraler Angelpunkt innerhalb des Personalcomputers, durch welches Anwendungsprogramme miteinander kommunizieren und durch welches ein Benutzer das Verhalten der Anwendungsprogramme konfiguriert und steuert. Ein Benutzer ist folglich in der Lage, das gesamte System von kommunizierten Anwendungen hauptsächlich durch eine einzige graphische Benutzeroberfläche, die durch das IAMS angezeigt wird, zu konfigurieren und zu steuern, In einer Computerumgebung ohne IAMS ist der Benutzer angehalten, jedes Anwendungsprogramm durch graphische Benutzeroberflächen, die an jedes Anwendungsprogramm speziell angebunden sind, zu steuern und zu konfigurieren, und Anwendungsprogramme haben im Allgemeinen keine Möglichkeit ihre eigenen Aktivitäten mit denen anderer Anwendungsprogramme zu koordinieren. In solchen Umgebungen kann der Benutzer nicht ein koordiniertes, systemweites Anwendungsprogrammverhalten spezifizieren.
• Das MUI stellt eine einzige Benutzeroberfläche bereit, durch welche der Benutzer die konformen Anwendungen starten kann und die Benutzerpräferenzanwendung ("UPA") startet. Fig. 2-6 zeigen Bestandteile der Menüs oder Oberflächen der obersten Hierarchie. Das Menü der obersten Hierarchie oder die dem Benutzer durch das MUI präsentierte Bildschirmanzeige ist in Fig. 2 dargestellt. Das Menü der obersten Hierarchie enthält Titel für die vier Hauptanwendungsprogrammbereiche, die "Audio" 201, "Telefon" 202, "TV/Video" 203 und "Internet" 204 einschließen. Zusätzlich weist das Menü der obersten Hierarchie Optionen auf, um das Einrichtprogramm 205 und ein Hilfeprogramm 206 zu starten. Wenn ein Benutzer die Maus 50 handhabt, so dass der Cursor auf einem der vier Anwendungsbereiche auf dem Menü der obersten Hierarchie aufliegt, verändert die Schaltfläche oder die Abbildung, die diesem Anwendungsbereich zugeordnet ist die Farbe, und ein großes Symbol, das den Anwendungsbereich repräsentiert, wird im Zentrum des Menüs dargestellt. Zum Beispiel liegt in Fig. 3 der Cursor auf dem "Audio"-Anwendungsbereich auf, wodurch sich ergibt, dass die Anzeige 301, die dem "Audio"-Anwendungsbereich zugeordnet ist, die Farbe verändert und ein großes CD-Symbol 302 angezeigt wird. Fig. 4-6 zeigen das Erscheinungsbild des Menüs der obersten Hierarchie, wenn der Cursor über die "Telefon"-", TV/Video"- bzw. "Internet"-Anwendungsbereiche gebracht wird.
• Fig. 7 zeigt das Flußdiagramm des MUI. Das MUl greift auf eine zentrale Registrierdatenbank zu, um die konformen Anwendungsprogramme zu identifizieren, und erlaubt es dem Benutzer auszuwählen, welche konformen Anwendungsprogramme gestartet werden. In Schritt 701 zeigt das MUI das Hauptmenü an, wie in Fig. 2 dargestellt ist. Das MUI wartet dann auf Benutzereingaben in dieses Hauptmenü und reagiert auf die Benutzereingaben gemäß der verbleibenden Schritte 702-711. Sobald der Benutzer die Maus oder ein anderes Eingabegerät handhabt um Eingaben in das Hauptmenü auszuführen, wird das MUI aktiviert und der Kontrollfluss geht zu Schritt 702 über. In Schritt 702 bestimmt das MUI, ob der Benutzer den Cursor über eine der vier Anwendungsbereich-Titel oder -Schaltflächen plaziert hat. Falls dem so ist, dann zeigt das MUI in Schritt 703 das korrespondierende große Symbol für den Anwendungsbereich an und verändert die Farbe der Anzeige, die dem Anwendungsbereich zugeordnet ist, wie es in Fig. 3-6 dargestellt ist. Falls der Cursor nicht über eine Anwendungsbereich-Schaltfläche plaziert wurde, dann bestimmt das MUI in Schritt 704, ob der Benutzer die Hilfeauswahl des Hauptmenüs angeklickt hat. Falls dem so ist, ruft das MUI in Schritt 705 das Hilfeprogramm auf. Falls der Benutzer nicht auf die Hilfeauswahl geklickt hat, dann bestimmt das MUI in Schritt 706, ob der Benutzer die Einrichtoption in dem Hauptmenü ausgewählt hat. Falls dem so ist, dann startet das MUI im Schritt 706a das UPA, das im Folgenden diskutiert wird, welches es dem Benutzer erlaubt, das Verhalten der Anwendungsprogramme zu konfigurieren. Falls der Benutzer nicht die Einrichtoption ausgewählt hat dann bestimmt das MUI in Schritt 707, ob der Benutzer einen der Anwendungsbereiche ausgewählt hat. Falls nicht, kehrt der Kontrollfluss in den Wartezustand zurück, der Schritt 701 folgt, wo das MUI auf weitere Benutzereingaben wartet. Andererseits, falls der Benutzer einen der Anwendungsbereiche im Hauptmenü ausgewählt hat, zeigt das MUS in Schritt 708 ein Untermenü oder ein anwendungsbereichspezifisches Menü an, das diesem Anwendungsbereich zugeordnet ist, und wartet dann auf zusätzliche Benutzereingaben. Falls ein Benutzer auf eines der Anwendungssymbole oder Auswahlmöglichkeiten klickt, die innerhalb des anwendungsbereichspezifischen Menüs angezeigt werden, dann erkennt das MUI in Schritt 709 diese Auswahl und das MUI startet in Schritt 711 dieses spezifische Anwendungsprogramm. Andererseits, falls der Benutzer die "Schliessen"-Auswahl des anwendungsbereichspezifischen Menüs ausgewählt, was in Schritt 710 festgestellt wird, dann kehrt der Kontrollfluss in den Wartezustand zurück, der Schritt 701 folgt, wo das MUI auf weitere Benutzereingaben wartet.
• Die Konfigurationsinformation für die verschiedenen Anwendungsprogramme innerhalb des IAMS ist in einer Datenbank gespeichert. In einer Ausführungsform des IAMS ist die Konfigurationsinformation in der Windows-Registrierdatenbank, eine hierarchische Datenbank, die in dem Windows-Betriebssystems implementiert ist gespeichert. Die Konfigurationsinformation besteht im Wesentlichen aus Paaren von Schlüsselereignissen und Befehlen. Ein Schlüsselereignis ist durch den Namen des Anwendungsprogramms, das das Schlüsselereignis empfängt, welcher an den Namen des Schlüsselereignisses angehängt wird, spezifiziert. Diese Anwendungsprogramm/Schlüsselereigniskennzeichnung ist in der Windows-Registrierdatenbank dem Namen des Befehls zugeordnet, der für das empfangende Anwendungsprogramm konfiguriert ist um in Reaktion auf das Schlüsselereignis ausgeführt zu werden.
• Folglich wird in der Registrierdatenbank der Name eines Befehls für jedes Schlüsselereignis gespeichert, das vom jeweiligen Anwendungsprogramm empfangen wird. Beispielsweise kann die Telefonanwendung ein "eingehenden Sprachtelefonieanruf"-Schlüsselereignis erzeugen, das dem Erkennen eines eingehenden Telefonanrufs entspricht. Jedes Anwendungsprogramm, das unter dem IAMS ablaufen wird, wird dann in der Registrierdatenbank einen Wert für das "eingehenden Sprachtelefonieanruf"-Ereignis haben, der aus einem Befehl besteht den diese Anwendung auf die Benachrichtigung durch das ACM über das Auftreten eines "eingehenden Sprachtelefonieanrufs"-Schlüsselereignisses, ausführen soll. Die CD-Wiedergabeanwendung kann beispielsweise instruiert werden, einen "Pause"-Befehl in Reaktion auf das "eingehenden Sprachtelefonieanruf"-Schlüsselereignis auszuführen. In diesem Fall wird die Registrierdatenbank folgendes Name-Wert-Paar haben: CD-Wiedergabeeinrichtung/eingehenden Sprachtelefonieanruf - Pause. Andererseits kann die Telefonanwendung konfiguriert sein, eingehende Anrufe zu beantworten. In diesem Fall wird die Regstrierdatenbank ferner folgendes Name-Wert-Paar aufweisen: Telefon/eingehender Sprachtelefonieanruf - Anruf beantworten.
• Die aktuelle Konfiguration für die Anwendungsprogramme wird in der Regstrierdatenbank in einer bezeichneten Hierarchieebene gespeichert, z. B. "aktuelle Konfiguration". Zusätzliche Konfigurationen können in separaten Dateien oder in separat bezeichneten Hierarchieebenen innerhalb der Registrierdatenbank als bezeichnete, alternative Konfigurationen gespeichert werden, die später durch den Benutzer zur aktuellen Konfiguration bestimmt werden können.
• Die oben beschriebene Konfigurationsinformation wird durch den Benutzer über die Benutzerpräferenzanwendung (User Preference Application; "UPA") spezifiziert, die durch die Auswahl der Einrichtoption im Hauptmenü gestartet wird. Fig. 8-13 zeigen Beispiele von Tätigkeiten an der graphischen Einricht-Benutzeroberfläche des UPA. Fig. 8 zeigt das Einrichtfenster, welches über dem Hauptmenü überlagert erscheint, wenn ein Benutzer die Einrichtoption des Hauptmenüs auswählt. Das Einrichtfenster weist eine Dropdown-Liste 801 und Schaltflächen 802 bis 805 zum Aktualisieren der aktuellen Konfiguration, zum Abbrechen des Einrichtprogramms, zum Laden einer zuvor gespeicherte Konfiguration bzw. zum Speichern einer Konfiguration auf. Im Zentrum des Einrichtmenüs sind neun Registerkarten, die neun unterschiedlichen, unterstützten Anwendungsprogrammen 806-814 entsprechen. In Fig. 8 wurde die Registerkarte, die dem Audio-Anwendungsprogramm entspricht, zum Anzeigen ausgewählt und diese überlagert die anderen acht Registerkarten. Das dargestellte Audio-Befehlsformular weist Radioknöpfe für die vier möglichen, akzeptierten Befehle des Audioanwendungsprogramms auf: Wiedergeben 815, Pause 816, Stopp 817 und keinen Befehl 818.
• Durch Klicken auf einen der Titel der Registerkarten kann der Benutzer die Befehle, die dem korrespondierenden Anwendungsprogramm zugeordnet sind, anzeigen. In Fig. 9 beispielsweise hat der Benutzer die CD-Registerkarte ausgewählt und in Fig. 10 hat der Benutzer die DVD-Registerkarte ausgewählt.
• Wenn der Benutzer ein Ereignis aus der Dropdown-Liste 801 auf der graphischen Einricht-Benutzeroberfläche auswählt, wird eine Liste 1101 von möglichen Schlüsselereignissen, die von allen Anwendungsprogrammen generiert werden können, die das IAMS umfasst, über dem Einrichtfenster überlagert, wie es in Abb. 11 dargestellt ist. Wie zuvor beschrieben, können diese Schlüsselereignisse in dem Computercode des IAMS fest codiert sein oder können von dem IAMS entweder zur Laufzeit direkt von dem Anwendungsprogramm oder von der Windows-Registrierdatenbank abgerufen werden. Der Benutzer kann ein beliebiges dieser Schlüsselereignisse per Mausklick, wie es in Fig. 12 gezeigt ist, auswählen, wo der Benutzer das Schlüsselereignis "eingehender Sprachtelefonieanruf" ausgewählt hat. Wenn der Benutzer ein Schlüsselereignis ausgewählt hat, wird die Liste von Schlüsselereignissen entfernt und das ausgewählte Schlüsselereignis 1301 erscheint in der Ereignisfensterleiste, wie in Fig. 13 gezeigt ist.
• Ein Benutzer kann die Maus benutzen, um auf einen Beliebigen der Befehle zu klicken, die auf der Registerkarte für eine bestimmte Anwendung angezeigt werden. Ein ausgewählter Befehl wird durch einen kleinen schwarzen Punkt gekennzeichnet, der auf der Radioschaltfläche erscheint, die dem Befehl zugeordnet ist, wie beispielsweise in Fig. 14, wo der "leite Anruf zum Anrufbeantworter weiter"-Befehl 1401 auf der Registerkarte für die Videotelefon-Anwendung ausgewählt wurde. Durch sukzessive Auswahl jedes verschieden Schlüsselereignisses und wobei für jedes Schlüsselereignis ein Befehl aus jeder Registerkarte ausgewählt wird, kann ein Benutzer die gesamte Konfiguration für ein Anwendungszusammenspiel unter dem IAMS-System spezifizieren. Wenn der Benutzer die "OK"-Schaltfläche 1402 drückt, wird die gesamte von dem Benutzer seit dem letzten Aufruf des Einrichtfensters erstellte Auswahl von Befehlen, die Anwendungen und Schlüsselereignissen korrespondieren, in der Registrierdatenbank gespeichert, so wie es zuvor beschrieben wurde. Wenn der Benutzer die "Abbrechen"-Schaltfläche 1403 auswählt, beendet sich das Einrichtprogramm, ohne die Registrierdatenbank zu verändern. Wenn der Benutzer die "Laden"-Schaltfläche auswählt, wird ein zusätzliches Fenster angezeigt, das es einem Benutzer erlaubt, eine gespeicherte Konfigurationsdatei zu spezifizieren, welche dann in den Speicher und durch das Einrichtprogramm vom Speicher in die Registrierdatenbank eingelesen wird. Wenn der Benutzer die "Speichern"-Schaltfläche 1405 auswählt, zeigt das Einrichtprogramm ein zusätzliches Fenster an, das es einem Benutzer erlaubt, den Namen für die Konfiguration, die durch den letzten Aufruf des Einrichtfensters spezifiziert ist, zu spezifizieren, und diese Konfiguration wird dann unter dem angegebenen Namen entweder in einer Datei oder in der Registrierdatenbank zum nachfolgendem Abruf mittels der "Laden"-Schaltfläche 1404 gespeichert.
• Fig. 15 zeigt ein Flußdiagramm für das UPA (das ist "das Einrichtprogramm"), das in Reaktion auf die Benutzerauswahl der Einrichtoption des Hauptmenüs aufgerufen wird. In Schritt 1501 zeigt das Einrichtprogramm das Einrichtfenster, das in Fig. 8 dargestellt ist. Das Einrichtprogramm wartet dann auf Benutzereingaben. Schritte 1502-1504 repräsentieren einen "case"-(falls) oder "switch"-(wechsle zu) Befehl, mit welchen das Einrichtprogramm die Benutzereingaben untersucht und auf jede Benutzereingabe reagiert. Wenn der Benutzer mittels der graphischen Einricht-Benutzeroberfläche Eingaben zum Einrichtprogramm durchführt, verläßt das Einrichtprogramm den Wartezustand 1501 und beginnt die Ausführung bei Schritt 1502. In Schritt 1502 untersucht das Einrichtprogramm, ob der Benutzer die Ereignis-Bildlaufleiste ausgewählt hat. Falls das der Fall ist, zeigt das Einrichtprogramm in Schritt 1503 alle möglichen Schlüsselereignisse in der Bildlaufleiste an und erlaubt es dem Benutzer eines der Schlüsselereignisse auszuwählen, um es in der Ereignis-Bildlaufleiste anzuzeigen. Das Einrichtprogramm kann dabei auf eine im Computercode fest codierte Liste von Schlüsselereignissen zugreifen oder kann auf eine Liste von- Schlüsselereignissen, die von dem IAMS zur Laufzeit mittels von jedem Anwendungsprogramm unterstützten Standardschnittstellen erzeugt wurde, zugreifen oder indem die Schlüsselereignisse aus der Windows-Registrierdatenbank abgerufen werden. Falls der Benutzer die Ereignis-Bildlaufleiste nicht ausgewählt hat, dann bestimmt das Einrichtprogramm in Schritt 1504, ob der Benutzer einen der Kartenreiter einer Registerkarte ausgewählt hat. Falls das der Fall ist, zeigt das Einrichtprogramm in Schritt 1505 die Registerkarte an, die dem durch den Benutzer ausgewählten Kartenreiter zugeordnet ist. Falls der Benutzer nicht einen Kartenreiter ausgewählt hat, dann bestimmt das Einrichtprogramm in Schritt 1506, ob der Benutzer auf eine der Radioschaltflächen, die einem bestimmten Befehl zugeordnet sind, geklickt hat. Falls das der Fall ist, dann wählt das Einrichtprogramm in Schritt 1507 diesen Befehl aus und speichert die Auswahl für diesen Zustand entweder im Speicher oder in einer lokalen Datenbank, so dass die Registrierdatenbank später aktualisiert werden kann, falls der Benutzer auswählt das zu tun. Falls der Benutzer nicht auf eine Befehls-Radioschaltfläche geklickt hat, dann bestimmt das Einrichtprogramm in Schritt 1507, ob der Benutzer auf die "OK"-Schaltfläche geklickt hat. Falls dem so ist, dann übergibt das Einrichtprogramm in Schritt 1508 alle Einstellungen, die durch den Benutzer während des aktuellen Aufrufs des Einrichtprogramms durchgeführt wurden, vom Speicher oder einer lokalen Datenbank an die Registrierdatenbank. Falls der Benutzer nicht auf die "OK"-Schaltfläche gedrückt hat, dann bestimmt das Einrichtprogramm in Schritt 1509, ob ein Benutzer auf die "Laden"-Schaltfläche geklickt hat. Falls das der Fallist, dann bittet das Einrichtprogramm in Schritt 1510 den Benutzer um einen Namen für eine gespeicherte Konfiguration und lädt diese gespeicherte Konfiguration entweder in den Speicher oder in eine lokale. Datenbank, wie wenn der Benutzer diese Auswahl durch das Einrichtmenü während des aktuellen Aufrufs des Einrichtfensters gemacht hätte. Falls der Benutzer nicht die "Laden"-Schaltfläche ausgewählt hat, dann untersucht das Einrichtprogramm in Schritt 1511, ob der Benutzer auf die "Speichern"-Schaltfläche geklickt hat. Falls das der Fall ist, dann bittet das Einrichtprogramm in Schritt 1512 den Benutzer um einen Namen für eine gespeicherte Konfiguration und speichert die gesamte Auswahl, die sich derzeit im Speicher oder in einer lokalen Datenbank befindet in diese gespeicherte Konfiguration, entweder in eine separate Datei oder unter einer unterschiedlichen hierarchischen Einteilung in der Registrierdatenbank. Die gespeicherte Konfiguration kann nachfolgend durch den Benutzer durch Auswahl der "Laden"-Schaltfläche in dem Einrichtmenü abgerufen werden, wie es zuvor beschrieben ist, indem bei Schritt 1509 begonnen wird. Falls der Benutzer nicht auf die "Speichern"-Schaltfläche gedrückt hat, dann untersucht das Einrichtprogramm in Schritt 1513, ob der Benutzer die "Abbrechen"-Schaltfläche ausgewählt hat. Falls das der Fall ist, dann kehrt das Einrichtprogramm in Schritt 1514 zurück. Falls nicht, kehrt der Kontrollfluss in den Wartezustand, der Schritt 1501 folgt, zurück, wo das Einrichtprogramm auf weitere Benutzereingaben wartet.
• Untenstehende Tabelle 1 zeigt Beispiele von den verschiedenen unterschiedlichen Anwendungsprogrammen wie in dem IAMS enthalten sein können.
Tabelle 1
• DVD-Wiedergabeeinrichtung Gibt DVDs über die Lautsprecher und den Monitor eines PCs wieder
• Audio-Wiedergabeeinrichtung Gibt ".WAV"-Dateien und andere gespeicherte Audiodaten über die Lautsprecher des PCs wieder
• CD-Wiedergabeeinrichtung Gibt bespielte Musik-CDs über die an einem PC angeschlossenen Lautsprecher wieder
• MPEG-Film-Wiedergabeeinrichtung Stellt eine Anzeigeeinrichtung für mit dem MPEG-Verfahren aufgenommene Filme bereit
• Video-Aufnahme Stellt eine Aufnahmemöglichkeit für Videodaten für Datenspeichervorrichtungen des PCs bereit
• Fernseh-Anwendung Stellt Fernsehempfang und dessen Anzeige auf dem PC bereit
• Elektronische Programminformation (EPG) Stellt einen Fernsehprogramm-Zeitplan bereit
• Telefonie Stellt Audio-Telefonanrufe über PC und angeschlossene periphere Einrichtungen bereit
• Video-Telefon Stellt sowohl visuellen Datenaustausch als auch Audio- Datenaustausch in dem Context von Telefonkommunikation bereit
• Web Browser Stellt Navigation zu graphischen Internetseiten und deren Darstellung bereit
• In untenstehender Tabelle 2 sind die verschiedenen Schlüsselereignisse gezeigt, die von jedem der Anwendungsprogramme erzeugt werden, die in Tabelle 1 beschrieben sind, sowie die Befehle, die von jedem der Anwendungsprogramme unterstützt werden. Jedes Anwendungsprogramm kann auch ein "Status"-Schlüsselereignis erzeugen, so dass das ACM seine Anzeige mit den Anwendungsprogrammen synchronisieren kann. Tabelle 2
• Unten gezeigte Tabelle 3 enthält eine Beispielkonfiguration, die von einem Benutzer spezifiziert sein kann. Tabelle 3
• Fig. 16 ist ein schematisches Diagramm des ACM und der unterstützenden Betriebssystemeinrichtungen, die von dem ACM benützt werden. In Fig. 16 sind vier kooperierende Anwendungen 1601-1604 dargestellt, die Schnittstellen zu dem ACM 1605 haben. Informationen bezüglich der Konfiguration des kooperativen Verhaltens dieser Anwendungsprogramme sind in der Registrierdatenbank gespeichert, die von dem Betriebssystem 1606 unterstützt wird, wie es oben beschrieben ist. Die miteinander verbundenen Linien mit einer Pfeilspitze zeigen ein Speichern und ein Abrufen von Konfigurationsinformationen durch interne Komponenten des ACM in bzw. von der Registrierdatenbank an.
• Die Kommunikation zwischen den Anwendungsprogrammen und den verschiedenen internen Komponenten des ACM wird durch Pfeile mit zwei Pfeilspitzen angezeigt wie z. B. Pfeil 1606. Diese Kommunikation ist unter Benützung des Microsoft COM (Component Object Model) implementiert. Im Wesentlichen erlaubt COM Programmen, eine oder mehrere Schnittstellen zu anderen Programmen zu exportieren. Eine Schnittstelle weist einen oder mehrere Funktionszeiger auf, durch welche ein Prozess eine Funktion, die von einem anderen Prozess unterstützt wird und von diesem ausgeführt wird, aufrufen kann. COM stellt auch allgemeine Funktionsaufrufe (das ist QueryInterface; Schnittstellenabfrage) bereit, durch welche ein Prozess die Schnittstellen, die von anderen Prozessen unterstützt werden, abfragen kann und die Eigenschaften jeder Funktion innerhalb jeder Schnittstelle bestimmen kann. Folglich erlaubt es COM einem Prozess zur Laufzeit die von einem anderen Prozess bereit gestellten, exportierten Funktionen zu bestimmen und diese Funktionen aufzurufen. COM erlaubt den Prozessen ebenfalls andere Prozesse aufzurufen, die auf sich entfernt befindenden Maschinen ablaufen. Obwohl die gerade beschriebene Ausführungsform COM verwendet, könnten andere Objekt-Modelle benützt werden, die von anderen Herstellern auf anderen Plattformen unterstützt werden, um das ACM zu implementieren.
• Das ACM weist eine Anzahl von unterschiedlichen, gleichzeitig ablaufenden Threads, ein Synchronisationsobjekt, eine Logik zum Empfangen von Befehlen und eine Kommunikationslogik, welche sich in jeder der kooperierenden Anwendungen befindet, auf. Der Teil des ACM, der sich in einem kooperierenden Anwendungsprogramm befindet wird als das Client-ACM 1608-1611 bezeichnet. Das Client-ACM ist für das Versenden von Benachrichtigungen über das Auftreten von Schlüsselereignissen von einem Anwendungsprogramm zu internen ACM-Komponenten verantwortlich. Zusätzlich empfängt das Client- ACM Befehle von anderen internen ACM-Komponenten und gibt diese Befehle an die Hauptlogik des Anwendungsprogramms zur Ausführung weiter. Das Client-ACM kann durch eine oder mehrere COM-Schnittstellen implementiert werden. Beispielsweise könnte die Schnittstelle, die auf die internen ACM- Komponenten gerichtet ist aus einer einfachen "receive_command" (empfarige_befehl) -Funktion bestehen, die ein einzelnes Integer-Argument annimmt, das einen spezifischen Befehl aus dem Satz von Befehlen, der von der zugeordneten Anwendung unterstützt wird, anzeigt. Das Client-ACM könnte eine zusätzliche Schnittstelle haben, die aus einer Funktion "send_event" (sende_ ereignis) besteht, die ein einzelnes Integer-Argument annimmt, und eine Schnittstellenfunktion aufruft, die von einer internen ACM-Komponente zum Empfangen eines Schlüsselereignisses von einer Client-ACM exportiert wurde. Bei einer solchen Implementierung ist jedes Schlüsselereignis und jeder Befehl eindeutig durch eine Integer-Zahl identifiziert.
• Die internen Komponenten des ACM weisen ein Ereignisobjekt 1612, einen Registrator 1614 und einen Empfänger 1615 auf, die innerhalb eines Haupt- Thread 1613, welcher ein Apartment-Thread ist, ablaufen. Apartment-Threads sind einer Windows-Nachrichtenschlange zugeordnet und sind gezwungen Windows-Nachrichten zu bearbeiten. Demgegenüber ist ein freier Thread nicht der Nachrichtenschlange zugeordnet und verarbeitet keine Windows-Nachrichten. Für jedes Anwendungsprogramm gibt es einen separaten freien Thread, der innerhalb des ACM-Hauptprozesses abläuft und Zusteller genannt wird 1616-1619. Die Zusteller sind auf einer Ereignis-Warteschlange, die dem Ereignisobjekt 1612 zugeordnet ist aneinandergereiht. Zusätzlich weist das ACM, wie oben beschrieben, das Einrichtprogramm und das Hilfeprogramm auf das einen Benutzer durch Anweisungen, wie das MUI zu bedienen ist, führt. Das Einricht- und das Hilfeprogramm können alternativ als getrennte Programme, getrennt von dem ACM betrachtet werden oder können als Komponenten des MUI betrachtet werden.
• Der Registrator-Thread innerhalb des Haupt-Thread ist für ein Empfangen der Hochlauf-Benachrichtigung von einer Anwendung, für ein Verfolgen, dass diese Anwendung momentan abläuft, und für ein Erzeugen eines freien Zusteller-Thread und für ein Zuordnen dessen mit dieser Anwendung verantwortlich. Folglich exportiert der Registrator eine COM-Schnittstelle zu Anwendungsprogrammen, welche zwei Funktionen enthält, die es dem Anwendungsprogramm erlauben, sich während des Hochlaufs zu registrieren und es diesem erlauben sich beim Beenden zu deregistrieren.
• Der Empfänger-Thread, der innerhalb des Haupt-Thread abläuft, ist für ein Empfangen von Benachrichtigungen über Schlüsselereignisse von den ablaufenden Anwendungsprogrammen verantwortlich. Der Empfänger-Thread exportiert zu den Anwendungsprogrammen eine Schnittstelle, welche eine einzige Funktion zum Empfangen von Schlüsselereignissen aufweist. Alternativ können die zwei Funktionen des Registrators und die einzelne Funktion des Empfängers zu einer einzigen COM-Schnittstelle mit drei Funktionen kombiniert werden.
• Das Ereignisobjekt 1612 ist ein von Microsoft unterstütztes Semaphor-ähnliches Objekt durch welches freie Threads in einer Warteschlage aufgereiht werden können, um auf das Auftreten eines Schlüsselereignisses zu warten, und welche durch den Empfänger-Thread signalisiert werden können, wenn der Empfänger-Thread ein Ereignis von einem Anwendungsprogramm empfängt. Wenn das Ereignis-Objekt signalisiert ist, gibt das Ereignis-Objekt jeden freien Zusteller-Thread sequentiell zur Ausführung frei. Jeder freie Zusteller- Thread ruft die einzelne Funktion auf, die von dem Client-ACM zum Empfangen eines Befehls exportiert wurde, wobei jedem Client-ACM das Schlüsselereignis übergeben wird, das den Empfänger-Thread veranlaßte, das Ereignis-Objekt zu signalisieren. Folglich arbeitet das ACM im Allgemeinen als ein Kommunikationszentrum, zu welchem jedes Anwendungsprogramm eine Benachrichtigung über das Auftreten eines Schlüsselereignisses leiten kann. Als Reaktion auf dieses Schlüsselereignis empfängt jedes Programm in dem System, einschließlich der Anwendungen, die eine Benachrichtigung über das Auftreten eines Schlüsselereignisses einreichen, einen Befehl von dem ACM, der die erwartete Reaktion dieser Anwendung auf das Schlüsselereignis anzeigt.
• Fig. 17 zeigt ein Flußdiagramm für den Empfänger-Thread des ACM. In Schritt 1701 wartet der Empfänger auf ein Schlüsselereignis von einer Anwendung. Wenn der Empfänger aktiviert wird, bestimmt der Empfänger in Schritt 1702, ob ein Schlüsselereignis empfangen wurde. Falls nicht, dann untersucht der Empfänger in Schritt 1703, ob ein Ende-Befehl empfangen wurde. Falls dem so ist, dann kehrt der Empfänger-Thread zurück und beendet sich. Falls nicht, dann kehrt der Kontrollfluss in den Wartezustand zurück, der durch Schritt 1701 repräsentiert wird. Falls andererseits ein Schlüsselereignis empfangen wurde, dann identifiziert der Empfänger in Schritt 1704 die Anwendung, die das Schlüsselereignis gesendet hat, und sucht in Schritt 1705 in der Registrierdatenbank den Befehl, der diesem Schlüsselereignis für die identifizierte Anwendung entspricht. In Schritt 1706 sendet der Empfänger den Befehl, der von der Registrierdatenbank erhalten wurde, zu der Anwendung, von welcher das Schlüsselereignis empfangen wurde. In Schritt 1707 stößt der Empfänger das Ereignisobjekt an, um alle in der Warteschlange wartenden freie Zusteller- Threads zu aktivieren, so dass diese Befehle zu den anderen Anwendungen schicken können. Man beachte, dass in der zuvor beschriebenen Implementierung der Zusteller-Thread, der der Anwendung zugeordnet ist, die das Schlüsselereignis zu dem Empfänger gesendet hat, nicht aktiviert wird, oder alternativ aktiviert wird, aber keinen redundanten Befehl zu der zugeordneten Anwendung sendet. Eine andere mögliche Implementierung für den Empfänger-Thread ist, keinen Befehl an die Anwendung, die das Schlüsselereignis gesendet hat, zu senden, aber sich stattdessen auf den Zusteller-Thread, der dieser Anwendung zugeordnet ist, zu verlassen, dass dieser den Befehl sendet.
• Fig. 18 zeigt ein Flußdiagramm für den Zusteller-Thread. Der Zusteller-Thread empfängt in Schritt 1801 von dem Registratorprozeß, der den Zusteller-Thread startet, die Kennung der Anwendung, welcher er zugeordnet werden wird. In Schritt 1802 tritt der Zusteller in einen Wartezustand ein, wo er auf das Ereignis-Objekt wartet, um von dem Empfänger-Thread in Reaktion auf das Empfangen eines Schlüsselereignisses aktiviert zu werden. Einmal aktiviert, bestimmt der Zusteller in Schritt 1803, ob ein Schlüsselereignis das Ereignis-Objekt aktiviert hat. Falls nicht, untersucht der Zusteller-Thread, ob das Ereignis- Objekt aktiviert wurde, um den Zusteller-Thread zu beenden. Falls dem so ist, beendet der Zusteller-Thread in Schritt 1805 seine Ausführung. Falls andererseits das Ereignis-Objekt durch ein Schlüsselereignis aktiviert wurde, dann untersucht der Zusteller in Schritt 1806, ob das Ereignis-Objekt durch ein Schlüsselereignis, das von dem Anwendungsprogramm gesendet wurde, welches dem Zusteller zugeordnet ist, aktiviert wurde. Falls dem so ist, dann kehrt der Kontrollfluss zu dem Wartezustand zurück, der durch Schritt 1802 repräsentiert wird, da bereits ein Befehl an das Anwendungsprogramm durch den Empfänger-Thread gesendet wurde. Falls das Ereignis-Objekt durch ein Anderes als das Anwendungsprogramm, das dem Zusteller zugeordnet ist, aktiviert wurde, dann sucht der Zusteller in Schritt 1807 den Befehl, der dem Schlüsselereignis entspricht, das das Ereignisobjekt für die dem Zusteller- Thread zugeordnete Anwendung aktiviert hat und sendet in Schritt 1707 diesen Befehl an das Anwendungsprogramm, das dem Zusteller-Thread zugeordnet ist.
• Fig. 19 zeigt ein Flußdiagramm für das Start-Programm, das in Reaktion auf Benutzereingaben in dem MUI aufgerufen wird, wie es in Schritt 710 von Fig. 7 beschrieben ist. Das Start-Programm kann als eine COM-Funktion implementiert sein, die durch den Registrator-Thread exportiert wird. In Schritt 1901 nimmt der Registrator-Thread einen Hinweis in die Registrierdatenbank auf, dass die Anwendung abläuft. In Schritt 1902 weist der Registrator der Anwendung eine Identifikation zu und startet das Anwendungsprogramm mittels Betriebssystem-Aufrufe. In Schritt 1903 erzeugt der Registrator einen Zusteller, ordnet den neu erzeugten Zusteller der Anwendung zu und reiht den Zusteller in die Warteschlange für das Ereignis-Objekt ein. Alternativ startet das MUI die Anwendungsprogramme. Jedes gestartete Anwendungsprogramm registriert sich bei dem ACM und empfängt eine Anwendungskennung. Das Anwendungsprogramm benützt die Anwendungskennung, wenn es mit dem ACM kommuniziert. Das Anwendungsprogramm deregistriert sich dann bei dem ACM, bevor es sich beendet.
• Obwohl die vorliegende Erfindung in Form einer Ausführungsform beschrieben wurde, ist nicht beabsichtigt, dass die Erfindung auf diese Ausführungsform beschränkt wird. Modifikationen innerhalb des Bereichs der Erfindung, wie sie in den anhängenden Ansprüchen definiert ist, werden für Fachleute offensichtlich sein. Beispielsweise können das ACM und das IAMS auf vielen verschiedenen Hardware-Plattformen und Betriebssystemen implementiert sein, können eine Vielzahl von verschiedenen Entfernter-Funktionsaufruf ("remote procedure call")-Einrichtungen für Interprozess-Kommunikation verwenden und können eine Vielzahl von verschiedenen Datenbanken oder Dateisystemobjekten zum Speichern von Konfigurationsinformation verwenden. Die von dem ACM unterstützten Aufgaben können zwischen internen ACM-Komponenten in einer unterschiedlichen Weise aufgeteilt werden, und es könnte eine unterschiedliche Anzahl von internen ACM-Komponenten und es könnten unterschiedliche Typen von internen ACM-Komponenten benützt werden. Das MUI kann unterschiedlich implementiert sein und einen unterschiedlichen Stil zum Darstellen der Auswahl und Information für den Benutzer aufweisen. Der Fachmann wird anerkennen, dass ein konformes Anwendungsprogramm vorzugsweise in normalen Weise ablaufen kann, wenn das IAMS nicht abläuft. In einer Ausführungsform kann das ACM eine Benutzeroberfläche bereitstellen, die den gegenwärtigen Zustand der Anwendungsprogramme darstellt, wie z. B. welche Anwendungsprogramme gerade ablaufen. Die Benutzeroberfläche des ACM kann dem Benutzer ebenso erlauben, Anwendungsprogramme zu starten und Befehle zu den Anwendungsprogrammen zu schicken. Der Bereich der vorliegenden Erfindung wird durch die nachfolgenden Ansprüche definiert.

Claims (25)

1. Verfahren zum Koordinieren von Computerprogrammen, die gleichzeitig auf einem Computer ausgeführt werden, wobei das Verfahren folgendes aufweist:

es werden Schlüsselereignisse zur Verfügung gestellt, die während der Ausführung der Computerprogramme erzeugt werden können;

es werden Befehle, die in Antwort auf jedes der Schlüsselereignisse auszuführen sind, zur Verfügung gestellt; und

in einem Koordinationsmodul werden Benachrichtigungen über ein Auftreten von Schlüsselereignissen empfangen, und in Antwort darauf werden die Befehle, die den Schlüsselereignissen zugeordnet sind, ausgeführt, dadurch gekennzeichnet,

- dass jedes aus einer Mehrzahl von gleichzeitig laufenden Computerprogrammen, welches ein Schlüsselereignis erzeugt, eine Benachrichtigung über ein Auftreten des Schlüsselereignisses an das Koordinationsmodul sendet, welches gleichzeitig mit den Computerprogrammen läuft;

- dass das Koordinationsmodul für jedes gleichzeitig laufende Computerprogramm untersucht, ob dem erzeugten Schlüsselereignis ein Befehl für das gleichzeitig laufende Computerprogramm zugeordnet ist; und

- dass, falls dem generierten Schlüsselereignis ein Befehl zugeordnet ist, das gleichzeitig laufende Computerprogramm den Befehl von dem Koordinationsmodul empfängt und den Befehl ausführt.

2. Verfahren nach Anspruch 1, bei welchem das Koordinationsmodul einen Befehl zur Ausführung an alle gleichzeitig laufenden Computerprogramme weiterleitet.

3. Verfahren nach Anspruch 1, bei welchem Schlüsselereignisse und Befehle zum nachfolgenden Abrufen in einer Datenbank gespeichert sind.

4. Verfahren nach Anspruch 2, bei welchem ein Computerbenutzer einen oder mehrere Befehle, die von jedem Computerprogramm bei dem Auftreten eines Schlüsselereignisses auszuführen sind, aus einem Satz von Befehlen, die von jedem der Computerprogramme akzeptiert und ausgeführt werden, auswählt.

5. Verfahren nach Anspruch 4, bei welchem der Computerbenutzer mit einer graphischen Hauptbenutzeroberfläche interagiert, um einen oder mehrere Befehle auszuwählen, die von jedem Computerprogramm bei dem Auftreten eines Schlüsselereignisses auszuführen sind, und um die Ausführung der Computerprogramme zu starten.

6. Verfahren nach Anspruch 5, bei welchem das Koordinationsmodul Benachrichtigung von einem Computerprogramm empfängt, wenn das Computerprogramm zu laufen beginnt, und in Antwort auf die empfangene Benachrichtigung einen Hinweis speichert, dass das Computerprogramm läuft, und eine Verbindung zwischen dem Computerprogramm und dem Koordinationsmodul aufbaut, um Benachrichtigungen über das Auftreten von Schlüsselereignissen von dem Computerprogramm und an das Koordinationsmodul weiterzugeben und um Befehle von dem Koordinationsmodul an das Computerprogramm weiterzugeben.

7. Verfahren nach Anspruch 6, bei welchem innerhalb des Hauptprozesses des Koordinationsmoduls ein Registrator, ein Empfänger und eine Anzahl von Zustellern laufen, und zwar ein Zusteller für jedes Computerprogramm, das auf dem Computersystem läuft.

8. Verfahren nach Anspruch 7, bei welchem der Registrator Benachrichtigungen von Computerprogrammen über den Start der Ausführung und über die Beendigung der Ausführung akzeptiert und Verbindungen zwischen den Computerprogrammen und dem Koordinationsmodul aufbaut, bei welchem der Empfänger Benachrichtigungen über das Auftreten von Schlüsselereignissen von den Computerprogrammen empfängt und bei welchem die Zusteller Befehle an die Computerprogramme senden.

9. Verfahren nach Anspruch 1, bei welchem das zur Verfügung Stellen einer Zuordnung von einem Schlüsselereignis zu einem Befehl aufweist:

es wird eine Liste von möglichen Schlüsselereignissen, die von jedem Computerprogramm erzeugt werden, erhalten;

es wird eine Liste von Befehlen, die von jedem Computerprogramm ausgeführt werden können, erhalten; und

es wird eine Benutzeroberfläche zur Verfügung gestellt, durch welche ein Benutzer ein Schlüsselereignis, das von einem Computerprogramm erzeugt wird, auswählen kann und einen Befehl, der von einem Computerprogramm ausgeführt werden kann, auswählen kann, und durch welche der Benutzer das ausgewählte Schlüsselereignis dem ausgewählten Befehl zuordnen kann.

10. Verfahren nach Anspruch 9, bei welchem die Listen von Schlüsselereignissen und von Befehlen fest in einem Computercode codiert sind.

11. Verfahren nach Anspruch 9, bei welchem die Listen von Schlüsselereignissen und von Befehlen zur Laufzeit erzeugt werden, indem mittels von jedem Computerprogramm unterstützten Standardschnittstellen Anfragen an jedes Computerprogramm gestellt werden.

12. Verfahren nach Anspruch 9, bei welchem die Listen von Schlüsselereignissen, die von einem Computerprogramm generiert werden und Befehle, die von einem Computerprogramm ausgeführt werden von dem Computerprogramm in einer Registrierdatenbank gespeichert und von der Benutzeroberfläche aus der Registrierdatenbank abgerufen werden.

13. Computersystem zum Koordinieren von Computerprogrammen, wobei das System folgendes aufweist:

eine Anzahl von Computerprogrammen, die auf dem Computer laufen;

einen Satz von Schlüsselereignissen, die das Auftreten eines bestimmten Zustandes innerhalb eines Computerprogramms oder einer Bedingung innerhalb eines Computerprogramms repräsentieren und die während der Ausführung der Computerprogramme erzeugt werden können;

einen Satz von Befehlen, die in Antwort auf die Schlüsselereignisse ausgeführt werden können; und

ein Koordinationsmodul, das Benachrichtigungen über Schlüsselereignisse empfängt, und in Antwort darauf werden die Befehle, die den Schlüsselereignissen zugeordnet sind, ausgeführt,

dadurch gekennzeichnet,

- dass jedes aus einer Mehrzahl von gleichzeitig laufenden Computerprogrammen, welches ein Schlüsselereignis erzeugt, eine Benachrichtigung über ein Auftreten des Schlüsselereignis an das Koordinationsmodul sendet, welches gleichzeitig mit den Computerprogrammen läuft;

- dass das Koordinationsmodul für jedes gleichzeitig laufende Computerprogramm ermittelt ob dem erzeugten Schlüsselereignis ein Befehl für das gleichzeitig laufende Computerprogramm zugeordnet ist; und

- dass, falls dem generierten Schlüsselereignis ein Befehl zugeordnet ist, das gleichzeitig laufende Computerprogramm den Befehl von dem Koordinationsmodul empfängt und den Befehl ausführt.

14. System nach Anspruch 13, bei welchem das System ein Personal Computer einschließlich dem Windows-Betriebssystem ist.

15. System nach Anspruch 13, bei welchem die Schlüsselereignisse in einer Daten-Aufbewahrungseinrichtung eines Betriebssystems gespeichert werden und diese Daten-Aufbewahrungseinrichtung die Windows-Registrierdatenbank des Windows-Betriebssystems ist.

16. System nach Anspruch 13, bei welchem das Koordinationsmodul einen Registrator, einen Empfänger, eine Anzahl von Zustellern und ein Ereignissobjekt aufweist.

17. System nach Anspruch 16, bei welchem sowohl der Registrator als auch der Empfänger Apartment-Threads sind, die innerhalb des Contexts eines Haupt-Koordinationsmodul-Prozesses laufen, und die Zusteller freie Threads sind, die innerhalb des Contexts eines Haupt-Koordinationsmodul-Prozesses laufen.

18. System nach Anspruch 6, bei welchem der Registrator Benachrichtigungen von einem Computerprogramm empfängt, sobald es zu Laufen beginnt, einen Hinweis speichert, dass das Computerprogramm läuft, und einen Zusteller erzeugt, der mit dem Computerprogramm verbunden ist.

19. System nach Anspruch 18, bei welchem der Empfänger eine Benachrichtigung über ein Schlüsselereignis von einem Computerprogramm empfängt und das Ereignisobjekt signalisiert.

20. System nach Anspruch 19, bei welchem jeder Zusteller das Ereignisobjekt bedient, und bei welchem dann, wenn das Ereignisobjekt signalisiert ist, jeder Zusteller die Identität des Schlüsselereignisses, das den Empfänger veranlasste das Ereignisobjekt zu signalisieren, erhält, aus der Daten-Aufbewahrungseinrichtung den an das mit dem Zusteller verbundenen Computerprogramm zu sendenden Befehl abruft, und den abgerufenen Befehl an das verbundene Computerprogramm sendet.

21. System nach Anspruch 13, das zudem eine graphische Benutzeroberfläche enthält die es einem Computerbenutzer erlaubt, für jedes Schlüsselereignis einen Befehl zu spezifizieren, der an jedes Computerprogramm zu senden ist, und die es einem Computerbenutzer erlaubt, jedes der Computerprogramme zu starten.

22. Computerlesbares Medium, das Computerbefehle enthält, die ausgebildet sind, um auf einem Computersystem gleichzeitig laufende Computerprogramme zu koordinieren, wie definiert in Anspruch 13.

23. Computerlesbares Medium nach Anspruch 22, bei welchem definierte Schlüsselereignisse und Befehle für einen nachfolgenden Abruf in einer Datenbank gespeichert sind.

24. Computerlesbares Medium nach Anspruch 22, bei welchem einem Computerbenutzer die Möglichkeit zur Verfügung gestellt wird, einen oder mehrere Befehle, die von jedem Computerprogramm bei dem Auftreten eines Schlüsselereignisses auszuführen sind, aus einem Satz von Befehlen auszuwählen, die von jedem der Computerprogramme akzeptiert und ausgeführt werden.

25. Computerlesbares Medium nach Anspruch 24, bei welchem der Computerbenutzer mit einer graphischen Benutzeroberfläche interagiert, um einen oder mehrere Befehle auszuwählen, die von jedem Computerprogramm bei dem Auftreten eines Schlüsselereignisses auszuführen sind, und um die Ausführung der Computerprogramme zu starten.