DE69636855T2

DE69636855T2 - Architektur für einen dynamisch programmierbaren zustandswechsel-gerätetreiber

Info

Publication number: DE69636855T2
Application number: DE69636855T
Authority: DE
Inventors: James A. Santa Clara KELLER; J. Kevin Patterson FLORY
Original assignee: Diamond Multimedia Systems Inc
Current assignee: Diamond Multimedia Systems Inc
Priority date: 1995-11-21
Filing date: 1996-11-21
Publication date: 2007-10-11
Anticipated expiration: 2016-11-22
Also published as: EP0862759A1; EP0862759A4; KR100421228B1; WO1997019402A1; JP4442732B2; EP0862759B1; ATE352067T1; JP2000500601A; DE69636855D1; KR19990071479A; JP2010033607A; US6289396B1

Description

Hintergrund der Erfindung
Gebiet der Erfindung:
Die vorliegende Erfindung bezieht sich allgemein auf die Entwicklung von Gerätetreibern, die in Computerbetriebssystemen verwendet werden, um eine Schnittstelle zwischen dem Kernbetriebssystem und typischen Hardwaregeräten zu definieren und einzurichten, und insbesondere auf eine modulare Gerätetreiberarchitektur, die eine virtualisierte kontextumschaltbare Schnittstellenumgebung bereitstellt, innerhalb der typische Hardware-Treiber zur Unterstützung von Betriebssystemfunktionen arbeiten, die insbesondere Informationsanzeigefunktionen enthalten.
Beschreibung des Standes der Technik:
In herkömmlichen Computersystemen stellen Software-Betriebssysteme verallgemeinerte Systemdienste den Anwendungsprogrammen zur Verfügung, einschließlich Dienstprogrammen und Daemon-Programmen. Diese Systemdienste enthalten herkömmlicherweise den Zugriff auf irgendwelche individuellen Hardware-Peripheriegeräte, die jeweils im Allgemeinen eine wohldefinierte Hardware-Schnittstelle zum Computersystem präsentieren, und die direkt oder indirekt mit dem Computersystem verbunden sein können. Gerätetreiber, die als Software-Module oder Komponenten implementiert sind, die in ein Betriebssystem integriert werden können, werden typischerweise verwendet, um wohldefinierte Software-Anwendungsprogrammschnittstellen (APIs) dem Betriebssystem und den Anwendungspro grammen für jede der Hardware-Schnittstellen zur Verfügung zu stellen. Gerätetreiber bieten häufig einen Grad an Geräteunabhängigkeit oder Virtualisierung, der die Wechselwirkung eines Anwendungsprogramms oder des Betriebssystems mit den Besonderheiten einer bestimmten Klasse von Hardware-Schnittstelle, wie z. B. einer Videosteuervorrichtung, vereinfachen kann. Herkömmlicherweise wird für jede Implementierung, die einer bestimmten Hardware-Schnittstelle zugrunde liegt, ein spezifischer Gerätetreiber verwendet, um eine ansonsten allgemeine API zu implementieren, die den Anwendungsprogrammen und dem Betriebssystem präsentiert wird.
Den herkömmlichen Gerätetreiberentwürfen sind eine Reihe von Problemen eigen. Erstens, herkömmliche Gerätetreiber sind für eine bestimmte Hardware-Schnittstelle und die Funktion des zugrunde liegenden Gerätes oder des Steuervorrichtungssystems spezifisch. Immer wenn somit eine neue oder andere Version einer Hardware-Steuervorrichtung hergestellt wird, muss auch ein neuer Gerätetreiber entwickelt werden, der gleichermaßen für die neue oder andere Hardware spezifisch ist. Wenn viele unterschiedliche Versionen eines Hardware-Gerätes vorhanden sind, muss im Allgemeinen eine ähnliche Anzahl von Gerätetreibern entwickelt werden. Alternativ können einzelne Kombinationsgerätetreiber konstruiert werden, die mehrere Versionen oder Typen von Geräten unterstützen. Solche Gerätetreiber enthalten typischerweise mehrere gerätespezifische Treiber, die ansonsten im Wesentlichen voneinander unabhängig sind, in einer einzigen Binärdatei.
Die effektive Anzahl von Gerätetreibern, die zum Unterstützen eines bestimmten Elements an Hardware erforderlich ist, ist ebenfalls abhängig von der Anzahl und den Unterschieden der Betriebssystemumgebungen, in denen die Hardware verwendet werden soll. Bis auf sehr eng verwandte Betriebssysteme ist ansonsten eine wesentliche Neuentwicklung des Gerätetreibers erforderlich, um sowohl eine angemessene Fähigkeit zum Eingliedern des Gerätetreibers in ein bestimmtes Betriebssystem zu bewerkstelligen, als auch, vielleicht noch bedeutender, eine logisch ähnliche, obgleich häufig vollständig verschiedene API dem Betriebssystem und den Anwendungen zur Verfügung zu stellen. Gewöhnlich bestimmt die genaue Definition der API des Gerätetreibers die genaue Gestaltung des Gerätetreibers selbst. Folglich werden Gerätetreiber für die gleiche Hardware, jedoch für unterschiedliche Betriebssysteme, häufig fast vollständig unabhängig entwickelt.
Eine weitere Überlegung, die die Anzahl der Gerätetreiber beeinflusst, die benötigt wird, um eine bestimmte Hardware-Steuervorrichtung zu unterstützen, entstammt aus der Eigenart anderer Hardware und Systeme, die mit einer bestimmten Steuervorrichtung verbunden sind. Um wiederum Flexibilität in der genauen Konstruktion von Computersystemen zur Verfügung zu stellen, kann eine Hardware-Steuervorrichtung fähig sein, eine Anzahl merklich unterschiedlicher Betriebsmodi zu unterstützen. Zum Beispiel kann eine Videosteuervorrichtung fähig sein, einen signifikanten Bereich von Videoanzeigeauflösungen und Farbtiefen zu unterstützen. Der Bereich kann jedoch durch direkte Beschränkungen eingeschränkt sein, wie z. B. die Menge an Video-RAM, der derzeit auf einer bestimmten Videosteuervorrichtung implementiert ist, und direkt durch die maximalen vertikalen und horizontalen Frequenzen einer angeschlossenen Videoanzeigevorrichtung. Die Anforderungen bestimmter Anwendungen können ebenfalls die Auswahl eines bestimmten Betriebsmodus vorgeben, der von einem Gerätetreiber unterstützt werden muss. Herkömmlicherweise werden mit der Hardware-Steuervorrichtung mehrere Gerätetreiber zur Verfügung gestellt, die jeweils einen unterschiedlichen Satz von einem oder mehreren Betriebsmodi unterstützen. Einer der bereitgestellten Gerätetreiber muss daher für die Betriebssystemeinbindung direkt auf der Grundlage der Konfiguration des bestimmten Computersystems ausgewählt werden. Neben den Schwierigkeiten der Auswahl eines Gerätetreibers, der den gewünschten Satz an Betriebsmodi unterstützt, besteht eine wesentliche Schwierigkeit in der vorsorglichen Bestimmung der Vielfalt von Modi, die unterschiedliche individuelle Gerätetreiber zu unterstützen haben. Obwohl sich die individuellen Treiber nur bis zu einem gewissen geringen Maß unterscheiden brauchen, kann ihre Anzahl hinsichtlich der Entwicklung bedeutend sein.
Ein zweites Problem, zum Teil infolge des ersten, besteht darin, dass jeder Gerätetreiber in der ganzen Vielfalt von Umgebungen, in denen der Gerätetreiber verwendet werden kann, gründlich getestet werden muss, um eine handelsüblich akzeptable Funktion sicherzustellen. Herkömmlicherweise sind Gerätetreiber im Wesentlichen monolithische Software-Module, die körperlich in das Betriebssystem eingebunden werden. Daher erfordert das Testen selbst weniger Varianten eines Gerätetreibers für ein bestimmtes Betriebssystem, dass die gesamte Folge von Betriebsfunktions- und Anwendungskompatibilitätstests durchlaufen werden, um die korrekte Funktion des Gerätetreibers zu überprüfen. Eine selektive Funktionsprüfung ist im Allgemeinen ungeeignet, aufgrund der realen Möglichkeit von mittelbaren Operationsfehlern, die aus irgendeiner Modifikation eines monolithisch codierten Gerätetreibers entstehen. Aufgrund der bedeutenden Anzahl von effektiv unterschiedlichen Gerätetreibern, die gewöhnlich für eine angemessen komplexe Hardware-Steuervorrichtung unterstützt werden, und die Größe und das bedeutende Ausmaß entsprechender Testfolgen stellt das Testen von Gerätetreibern einen bedeutenden Aufwand und eine sehr signifikante Verzögerung bei der Markteinführung neuer oder verbesserter Versionen eines Produkts dar.
Ein drittes Problem bei herkömmlichen Gerätetreiberentwürfen ist, dass diese für einen im Wesentlichen statischen Typ von Hardware-Steuervorrichtungsmanagement sorgen. Im Allgemeinen richten Gerätetreiber einen einzelnen Satz von Betriebsparametern für die Hardware-Steuervorrichtung ein, die von dem Gerätetreiber gemanagt werden. Das Betriebssystem und die Anwendungsprogramme, die auf dem Computersystem laufen, müssen alle die Parameter dieses statischen Modus akzeptieren, oder können im Wesentlichen nicht korrekt arbeiten.
In beschränkten Fällen kann ein herkömmlicher Gerätetreiber einige Modi den Anwendungsprogrammen verfügbar oder sichtbar machen. Um diese Modi zu nutzen, verlässt sich der Gerätetreiber daher darauf, dass Anwendungsprogramme im Wesentlichen hineinkompilierte Hardware-Abhängigkeiten aufweisen. In solchen Fällen können die Anwendungsprogramme eine Modusänderung bewirken, obgleich mit möglichen nachteiligen Auswirkungen auf andere ausgeführte Programme, die selbst dann, wenn sie zum Bewirken einer Modusumschaltung fähig sind, effektiv keine Kenntnis über irgendeine solche Umschaltung haben.
Einige typische Mehrprogrammbetrieb-Betriebssysteme können eine begrenzte dynamische Hardware-Steuervorrichtungs-Modusumschaltung durchführen, wenn auch nur durch eine vom Betriebssystem unterstützte Zustandsänderung. In diesen Fällen lädt das Betriebssystem im Wesentlichen den Zustand des Gerätetreibers und der Hardware-Steuervorrichtung nach, der konsistent mit dem Zustand eines neues Betriebsmodus ist. Es gibt jedoch keine direkte Beziehung zwischen den ausgeführten Anwendungen und dem Zustand des Gerätetreibers und der Hardware-Steuervorrichtung. Die laufenden Anwendungen haben wiederum größten Teils, wenn nicht vollständig, keine Kenntnis von irgendeiner Modusumschaltung. Folglich kann der ausgewählte Modus für einige ausgeführte Anwendungen optimal sein, jedoch nicht unbedingt für die Anwendung mit dem aktuellen Ausführungsschwerpunkt.
Überblick über die Erfindung
Ein allgemeiner Zweck der vorliegenden Erfindung ist somit, eine flexible, modulare Gerätetreiberarchitektur zu schaffen, die unabhängige Hardware-Konfigurationsoptionen auf einer dynamischen Rekonfigurationsbasis bereitstellen kann.
Dies wird in der vorliegenden Erfindung erreicht durch Bereitstellen einer Gerätetreiberarchitektur, die so arbeitet, dass sie ein Betriebssystem, das im Speicher eines Computersystems mit einem Prozessor vorgesehen ist, mit einer Computer-Schnittstelle einer Steuervorrichtung verbindet, die mehrere funktionale Unterelemente enthält. Der Gerätetreiber enthält mehrere Betriebssystem-Schnittstellenobjekte, die jeweils eine Betriebssystemschnittstelle (OSI) dem Betriebssystem präsentieren, mehrere Computerschnittstellenobjekte, die jeweils für die Erzeugung von Programmierwerten sorgen, die auf die Computerschnittstelle anzuwenden sind, um den Betriebsmodus eines jeweiligen vorgegebenen Unterelements der Steuervorrichtung einzurichten, und eine Gerätetreiberbibliothek von Verarbeitungsroutinen, die von jedem der mehreren Betriebssystemschnittstellenobjekte aufrufbar sind, um Daten zu verarbeiten und Aufrufe zu den mehreren Computerschnittstellenobjekten in vorgegebenen Kombinationen zu erzeugen. Die Gerätetreiberbibliothek ermöglicht die Auswahl von Ausführungskontexten, innerhalb derer die Erzeugung und Anwendung der Programmierwerte auf die Computerschnittstelle zu definieren sind.
Ein Vorteil der vorliegenden Erfindung besteht darin, dass der Zustand der Hardware-Schnittstelle, und entsprechend der Zustand der Steuervorrichtung, die die Hardware-Schnittstelle präsentiert, in diskreten Kontexten virtualisiert und gehalten wird. Operationsmerkmale oder Modi einer Steuervorrichtung, die ansonsten mittels individueller Anwendungsprogramme gehandhabt oder gemanagt werden müssen, können durch die Operation der vorliegenden Erfindung virtualisiert werden. Die vorliegende Erfindung sorgt für eine anwendungsspezifische, dynamische Änderung des Zustands der Hardware-Schnittstelle durch im Wesentlichen private Kontextumschaltung, die durch die Operation des Gerätetreibers implementiert ist. Ausgewählte Betriebssystemereignisse werden modifiziert oder abgefangen, um die Erzeugung neuer Kontexte und das dynamische Umschalten zwischen Kontexten durch den Gerätetreiber zu initiieren.
Ein weiterer Vorteil der vorliegenden Erfindung ist, dass der Gerätetreiber für eine umfangreiche Optimierung der durch den Gerätetreiber unterstützten Funktionen mittels der Steuervorrichtung sorgt. Der Gerätetreiber sorgt für die Virtualisierung der API-Aufrufschnittstellen, die vom Gerätetreiber unterstützt werden. Virtualisierung der Aufrufschnittstellen durch die Verwendung von Betriebssystemschnittstellenobjekten bietet eine spezifische Unterstützung für unabhängig definierte APIs und die Übersetzung von funktional äquivalenten Aufrufen, die durch im Wesentlichen allgemeine Ausführungsströme zu unterstützen sind.
Ein weiterer Vorteil der vorliegenden Erfindung ist, dass die Virtualisierung der Aufrufschnittstellen des Gerätetreibers in der Architektur eine allgemeine Bewertung von API-Aufrufen und ihrer Parameter einrichtet, wobei notwendigerweise jede Notwendigkeit für eine anschließende Parameterprüfung innerhalb der allgemeinen Ausführungsströme eliminiert wird. Die resultierenden, im Wesentlichen linearen Ausführungsströme in Verbindung mit einer Zeigerreferenz von Kontextdatenstrukturen stellt eine effiziente Ausführungsleistung sicher, während eine im Wesentlichen größere Funktionalität ermöglicht wird, als in herkömmlichen monolithischen Gerätetreibern erzielbar ist.
Ein weiterer Vorteil der vorliegenden Erfindung ist, dass der Gerätetreiber für eine kontextabhängige Änderung der im Wesentlichen linearen Ausführungsströme sorgt. Konversionsfunktionen, die erforderlich sind, um ein Umschalten zwischen Kontexten zu ermöglichen oder zu unterstützen, werden durch Einbinden der Funktionen direkt in die Ausführungsströme unterstützt, um somit ein wiederholtes Testen, um zu bestimmen, ob eine Konversionsfunktion durchzuführen ist, zu minimieren.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass der Gerätetreiber das dynamische Laden und die Konfiguration von wesentlichen funktionalen Objekten enthält, die notwendig oder optimal sind, um die bestimmte Steuervorrichtungskonfiguration zu unterstützen, die durch die Hardware-Schnittstelle zugänglich ist. Der Gerätetreiber antwortet auf codierte Konfigurationsdaten, die er über die Hardware-Schnittstelle oder auf anderem Wege von der Steuervorrichtung erhalten hat, um die unabhängigen funktionalen Unterelemente zu identifizieren, die die Steuervorrichtung bilden, bestimmt einen entsprechenden Satz von Hardware-Schnittstellenobjekten, die zum Unterstützen der Unterelemente geeignet sind, und lädt dynamisch den Objektsatz und bindet ihn als Teil der Initialisierung des Gerätetreibers ein.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass der Gerätetreiber eine Vielfalt von Hardware-Schnittstellenobjekten unterstützt, die bezüglich bestimmter funktionaler oder operationaler Aspekte programmierbar sind. Auf der Grundlage der codierten Konfigurationsdaten, die über die Hardware-Schnittstelle oder auf anderem Wege von der Steuervorrichtung erhalten werden, identifiziert der Gerätetreiber Konfigurationsdaten und lädt diese aus dem Systemspeicher, um die Hardware-Schnittstellenobjekte mit operationalen Konfigurationsdaten zu programmieren, die Einzelheiten darüber definieren, wie die Hardware-Schnittstellenobjekte ihre entsprechenden Unterelemente unterstützen.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass der Gerätetreiber eine bewährte Architektur bereitstellt, innerhalb der neue Hardware-Schnittstellenobjekte in weitgehender Isolation von anderen Hardware-Schnittstellenobjekten und anderen Architekturkomponenten des Gerätetreibers entwickelt werden können. Die architektonische Gestaltung der Hardware-Schnittstellenobjekte selbst erlaubt ferner eine wesentliche Konfigurationsüberarbeitung und Verbesserung durchzuführen durch Neudefinition der operationalen Konfigurationsdaten, die zum Programmieren der entsprechenden Hardware-Schnittstellenobjekte verwendet werden. Eine Modifikation eines Gerätetreibers, um ein überarbeitetes oder neues Steuervorrichtungs-Unterelement zu unterstützen, kann darauf beschränkt werden, einfach eine Konfigurationsdatendatei zu editieren, im Gegensatz zu der Bewerkstelligung von Quellcodemodifikationen an dem dem Hardware-Schnittstellenobjekt entsprechenden Unterelement. In jedem Fall kann die Kompatibilitätsprüfung in geeigneter Weise auf das Testen des besonderen Hardware-Schnittstellenobjekts begrenzt werden, das ein überarbeitetes oder neues Unterelement einer Steuervorrichtung unterstützt.
Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass der Gerätetreiber für die Modifikation des Betriebssystems sorgt, um eine konsistente Meldung der derzeit von einer Videoanzeigesteuervorrichtung unterstützten Farbtiefe zu erzwingen. Unterschiedliche Farbtiefekontexte werden für den Satz von ausgeführten Anwendungen eingerichtet, wobei jeder Kontext der maximal annehmbaren Farbtiefe von einer oder mehreren ausgeführten Anwendungen entspricht. Wenn der Kontext geändert wird und wenn die maximale Farbtiefe einer Anwendung die Farbtiefefähigkeiten der Videoanzeigesteuervorrichtung überschreitet, sorgen die Farbtiefekonversionsfunktionen, die in geeignete lineare Ausführungsströme eingebunden sind, für eine Anzeigedaten-Farbtiefekonversion.
Kurzbeschreibung der Zeichnungen
Diese und andere Vorteile und Merkmale der vorliegenden Erfindung werden bei Betrachtung der folgenden genauen Beschreibung der Erfindung und in Verbindung mit den beigefügten Zeichnungen besser verstanden, in welchen über alle Figuren hinweg ähnliche Bezugszeichen ähnliche Teile bezeichnen, und in welchen:
1 ein schematisches Blockdiagramm eines gemäß der vorliegenden Erfindung konstruierten Computersystems ist;
2 ein schematisches Blockdiagramm der architektonischen Konfiguration der vorliegenden Erfindung während der Initialisierung des Gerätetreibers der vorliegenden Erfindung zeigt;
3 ein Flussdiagramm zeigt, dass die Initialisierung der vorliegenden Erfindung genauer zeigt;
4 ein schematisches Blockdiagramm der architektonischen Konfiguration der vorliegenden Erfindung während einer Laufzeitausführung des Gerätetreibers der vorliegenden Erfindung zeigt;
5a eine allgemeine Darstellung der Beziehung zwischen mehreren Shell-Objekten, die den Gerätetreiberkontext definieren, der Shell-Bibliothek und der physikalischen Gerätestruktur des Betriebssystems konsistent mit der bevorzugten Ausführungsform der vorliegenden Erfindung zeigt;
5b eine verallgemeinerte Darstellung der Beziehung zwischen mehreren Umschreibungen eines Hardware-Schnittstellenobjekts konsistent mit einer bevorzugten Ausführungsform der vorliegenden Erfindung zeigt;
6a ein Flussdiagramm zeigt, das die Ausführung der Schritte bei der Vorbereitung eines Kontextumschaltens gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung beschreibt;
6b ein Flussdiagramm zeigt, das die Schritte beschreibt, die bei der Verwirklichung eines neuen Kontextes gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden;
7 eine Software-Flussdiagramm der Schritte zeigt, die bei der Beendigung der Operation eines Gerätetreibers, der gemäß der vorliegenden Erfindung konstruiert ist, verwendet werden;
8 ein Blockdiagramm zur Erläuterung der Verwendung sowohl realer als auch virtueller architektonischer Konfigurationen der vorliegenden Erfindung bei der Unterstützung mehrerer virtueller Maschinen, die innerhalb eines Betriebssystems ausgeführt werden, konsistent mit der vorliegenden Erfindung zeigt; und
9 ein schematisches Blockdiagramm der architektonischen Konfiguration eines virtuellen Gerätetreibers zeigt, der gemäß der vorliegenden Erfindung konstruiert ist.
Genaue Beschreibung der Erfindung
I. Hardware-Systemübersicht:
Ein Computersystem 10, das für die Nutzung der vorliegenden Erfindung geeignet ist, ist in 1 gezeigt. Das Computersystem 10 enthält vorzugsweise eine Zentralverarbeitungseinheit (CPU) 12, die über einen Systemdatenbus 14 mit einem Hauptspeicher 16 und einem Massenspeicherperipheriegerät 18, das vorzugsweise eine Plattenlaufwerkssteuervorrichtung und eine Festplattenlaufwerkseinheit enthält, verbunden ist. Für die Zwecke der vorliegenden Erfindung ist die Funktion des Massenspeicherperipheriegerätes 18 ausreichend, wenn die unterstützte Funktion das Lesen bestimmter ausführbarer Daten und Konfigurationsdateien von einem nichtflüchtigen Betriebsmittel erlaubt. Somit kann das Massenspeicherperipheriegerät 18 eine Kommunikationssteuervorrichtung sein, die Zugriff auf eine externe oder entfernte Vorrichtung oder ein System zur Verfügung stellt, die für die Speicherung von Daten, die vom Computersystem 10 lesbar sind, typischerweise in einer dateiorientierten Organisation sorgen.
Eine Videoanzeigesteuervorrichtung 19 ist ebenfalls als ein mit dem Systembus 14 verbundenes Peripheriegerät vorgesehen. Die Hardware-Implementierung der Videoanzeigesteuervorrichtung 19 ist im Allgemeinen von gewöhnlicher Natur für die Zwecke der vorliegenden Erfindung. Im Kontext der vorliegenden Erfindung ist jedoch die Videosteuervorrichtung 19 eindeutig als eine Sammlung von logisch unabhängigen Unterelementen beschrieben, die gemeinsam die Steuervorrichtung 19 bilden. Die Unterelemente werden anhand ihrer funktionalen Identität insbesondere mit Bezug auf die im Allgemeinen unabhängige Operationsprogrammierbarkeit logisch unterschieden. Das heißt, die funktionalen Unterteilungen der Hardware- Implementierung der Steuervorrichtung 19 definieren weitgehend die separaten Unterelemente der Steuervorrichtung 19 für die Zwecke der vorliegenden Erfindung.
Eine weitere Grundlage für die Unterscheidung der Unterelemente ist die Gruppierung von Funktionen auf der Grundlage einer Gemeinsamkeit in der Art der Programmierung des entsprechenden Unterelements als eine Konsequenz letztlich durch die programmierte Ausführung der CPU 12. Wie in 1 allgemein gezeigt ist, enthalten daher die Unterelemente der Videosteuervorrichtung 19 vorzugsweise, jedoch nicht hierauf beschränkt, einen Videoanzeigepuffer 20, einen Digital-zu-Analog-Wandler (DAC) 22, einen Videographikbeschleuniger 24, eine Videosteuervorrichtung 26, einen programmierbaren Taktgenerator 28, eine Hardware-Cursor-Steuervorrichtung und eine Codierer/Decodierer-Einheit (CODEC). Jedes dieser Unterelemente der Steuervorrichtung 19 ist relativ unabhängig programmierbar über eine Hardware-Registerschnittstelle 30, die in geeigneter Weise mit dem Systembus 14 verbunden ist. Die CPU 12 kann somit Informationen programmieren und von den Unterelementen 20, 22, 24, 26, 28 erhalten. Die Registerschnittstelle 30 und ein oder mehrere der Unterelemente können in der Praxis physikalisch auf einer einzigen integrierten Schaltung angesiedelt sein. Die gemeinsame Ansiedlung von Unterelementen auf einer einzigen integrierten Schaltung oder die Möglichkeit, dass Unterelemente über andere Unterelemente zugänglich sind, beeinflusst funktional nicht die Unterscheidung der Unterelemente voneinander.
Durch das Programmieren der Unterelemente 20–28 wird eine Videoanzeige 32 für die Darstellung von Text- und Graphikinformationen unterstützt. In einer bevorzugten Ausführungsform der vorliegenden Erfindung werden mehrere Anzeigefenster 34, 36 in Kombination mit einem Zeiger 38 unterstützt, der verwendet werden kann, um das derzeit aktive oder "Schwerpunkt"-Anzeigefenster, das auf der Anzeigevorrichtung 32 sichtbar ist, auszuwählen. Ein Anzeigefenster 34, 36 kann durch eine Anzahl diskreter Ereignisse den aktuellen Schwerpunkt erlangen. Diese Ereignisse umfassen das Starten eines neuen Anwendungsprogramms für die Ausführung durch das Computersystem 10. Als Vorgabe erlangt das Hauptfenster einer neu gestarteten Anwendung den aktuellen Schwerpunkt der Anzeige 32. Der Zeiger 38 kann ebenfalls verwendet werden, um ein Fenster 34, 36 auszuwählen, das z. B. bei Auftreten eines Mausklicks den Schwerpunkt erhalten soll. Schließlich kann das Anzeigefenster 34, 36 bei Beenden einer weiteren Anwendung den Schwerpunkt erhalten. Unter allen diesen Umständen wird ein Schwerpunktereignis erzeugt, bei dem die CPU 12 durch die Ausführung des Betriebssystems agieren kann.
Andere Peripheriegeräte 40 können ebenfalls als Komponenten des Computersystems 10 vorhanden sein. Diese anderen Peripheriegeräte 40 können komplexe Steuervorrichtungen umfassen, die Ton, Echtzeit-Video und andere komplexe Multifunktionsoperationen allein oder in Kombination miteinander unterstützen. Solche komplexen Steuervorrichtungen können durch die vorliegende Erfindung effektiv unterstützt werden, vorausgesetzt, die funktionale Operation und die Organisation der Steuervorrichtung sind vernünftig in eine Vielfalt von funktionalen Elementen unterteilt, die direkt oder indirekt durch die CPU 12 programmierbar sind. Zum Beispiel kann ein Hochleistungs-Audiountersystem, das Wellentabellensynthese, FM-Synthese, eine Entzerrersteuervorrichtung, eine Nachhallsteuervorrichtung und Mehrkanalverstärker-Unterelemente bereitstellt, die alle direkt oder indirekt durch eine dem Systembus 14 präsentierte Registerschnittstelle repräsentiert werden, optimal durch die vorliegende Erfindung unterstützt werden.
II. Software-Systemüberblick:
Obwohl die vorliegende Erfindung leicht irgendeine Peripheriesteuervorrichtung unterstützen kann, die irgendeine Anzahl von Unterelementen aufweist, kann die vorliegende Erfindung am besten so verstanden werden, wie sie in der bevorzugten Ausführungsform angewendet wird, um die Videoanzeigesteuervorrichtung 19 zu unterstützen und zu steuern. Wie in 2 gezeigt ist, ist eine bevorzugte Gerätetreiberausführungsform der vorliegenden Erfindung 50 zwischen der Hardware-Schnittstelle, die die logische Verbindung des Gerätetreibers zur Registerschnittstelle 30 der Videoanzeigesteuervorrichtung 19 repräsentiert, und einer Betriebssystemschicht 54 positioniert. Die Betriebssystemschicht 54 enthält typischerweise einen Betriebssystemkern 56 und möglicherweise eine oder mehrere Betriebssystemerweite rungen 58, die eine gewisse Basis-Betriebssystemebene-Funktionalität ergänzen. Schließlich kann die Betriebssystemschicht 54 ihrerseits ein oder mehrere Anwendungsprogramme 60 unterstützen.
Im Betrieb erhalten die Anwendungsprogramme 60 Unterstützungsdienste der Betriebssystemschicht 54 über eine Anwendungsprogrammschnittstelle (API), die effektiv als ein Satz von Ausführungseinsprungpunkten präsentiert wird, die von der Anwendung 60 aufgerufen werden können. Gemäß einer Ausführungsform der vorliegenden Erfindung wird eine kleine Teilmenge 62 der API-Aufrufpunkte des Betriebssystemkerns während der Initialisierung des Gerätestreibers 50 modifiziert. Diese modifizierten Aufrufpunkte enthalten die Einsprungpunktroutine, die ein Fensterschwerpunktänderungsereignis einer Anwendung 60 meldet, und die Einsprungpunktroutine, die die aktuelle Farbtiefe der Anzeige 32 an die Anwendung 60 zurückmeldet. Das Schwerpunktänderungsereignis wird vorzugsweise modifiziert, so dass es einen API-Aufruf an eine Betriebssystemerweiterung 58 enthält, die für eine zusätzliche Ereignisverarbeitung in Reaktion auf ein Schwerpunktänderungsereignis bereitstellt. Diese zusätzliche Ereignisverarbeitung umfasst das Durchführen einer Konfigurationswiederherstellung, um Daten zu erlangen, die die Ausführungsumgebung einer Anwendung quantifizieren, die gestartet werden soll, im Allgemeinen als eine Folge des Schwerpunktereignisses. Die wiedergewonnenen Daten enthalten vorzugsweise die Bildschirmauflösung und die Farbtiefekonfiguration, die für die gestartete Anwendung wünschenswert sind.
Die Modifikationen der Farbtiefemelderoutine werden spezifisch gemacht, um sicherzustellen, dass die von irgendeiner Anwendung 60 angeforderte maximale Farbtiefe der Anwendung 60 als die aktuelle Farbtiefe der Anzeige 32 gemeldet wird. Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung werden somit alle Anwendungen 60 mit einer vollständig virtualisierten Darstellung der Anzeige 32 insbesondere bezüglich der Farbtiefe ausgeführt. Das heißt, der Gerätetreiber 50 bietet volle Unterstützung für jegliche von einer Anwendung 60 angeforderte Farbtiefe, unabhängig davon, ob die angeforderte Farbtiefe die maximale Farbtiefe, die von einer weiterer Anwendung 60 gehandhabt werden kann, oder die maximale Farbtiefe der Anzeige 32 selbst überschreitet.
A. Gerätetreiber-Software-Architektur – obere Ebene:
Die Kernschicht 54 verbindet sich mit dem Gerätetreiber 50 über eine Betriebssystem-API (O/S-API), die den Betriebssystemkern 56 und irgendwelche Erweiterungen 58 mit Einsprungpunkten in dem Gerätetreiber 50 bereitstellt. Innerhalb des Gerätetreibers 50 wird die O/S-API hauptsächlich durch eine Anzahl von Betriebssystemschnittstellenmodulen unterstützt, die ein Graphikanzeigeschnittstelle-(GDI)-Modul 64, ein Direktzeichnungs-(DD)-Modul 66 und irgendeine Anzahl anderer Module 68 enthalten, die jeweils aktuelle oder zukünftig definierte APIs repräsentieren, wie z. B. Direkt-3D (D3D). Zusätzliche API-Einsprungpunkte werden von einem Betriebssystem(O/S)-Modul 70, einem Graphikschnittstellen-(GRX)-Modul 71 und einem Shell-Modul 72 bereitgestellt. Diese Module präsentieren gemeinsam im Wesentlichen alle aufrufbaren Einsprungpunkte, die die O/S-API des Gerätetreibers 50 bilden.
Das Shell-Modul 72 ist eine Anfangskomponente des Gerätetreibers 50, die in den Speicher 16 als Teil der Initialisierung des Betriebssystemkerns 56 während des Systemstarts geladen wird. In einem herkömmlichen Betriebssystem, wie z. B. Microsoft MS-Windows'95^TM lädt der Betriebssystemkern 56 das Shell-Modul 72 in den Speicher 16 infolge einer Referenz in einer Standardinitialisierungskonfigurationsdatei oder einer Datenbank, wie z. B. den Registrierungsdiensten von MS-Windows'95.
Ein Initialisierungseinsprungpunkt, der vom Shell-Modul 72 bereitgestellt wird, erlaubt dem Betriebssystemkern 56, die gerätetreiberspezifische Initialisierung des Gerätetreibers 50 einzuleiten. Als Teil dieser Initialisierung bestimmt das Shell-Modul 72 einen Platinentreiber, einen Satz von Hardware-Schnittstellenmodulen und eine Ergänzung von Betriebssystemschnittstellenmodulen, die erforderlich sind, um die Implementierung des Gerätetreibers 50 abzuschließen, um die O/S-API zu unterstützen, die vom Gerätetreiber 50 der Betriebssystemschicht 54 präsentiert wird. In einer bevorzugten Ausführungsform werden diese bestimmten zusätzlichen Module, falls nicht statisch mit dem Shell-Modul 72 verknüpft, dynamisch geladen und anschließend logisch in den Gerätetreiber 50 eingebunden.
Um eine Aufrufschnittstelle zur O/S-API bei Bedarf einzurichten, um Unterstützungsdienste für die Initialisierung des Gerätetreibers 50 zu erhalten, wird wenigstens das Betriebssystemmodul 70 als ein integraler Abschnitt oder eine Komponente des Shell-Moduls 72 geladen. Das GRX-Modul 71 wird vorzugsweise ebenfalls mit dem Shell-Modul 72 geladen. Aufgrund der praktischen Bequemlichkeit können auch andere gewöhnlich verwendete und vorgegebene Betriebssystemschnittstellenmodule statisch mit dem Betriebssystemmodul 70 verknüpft sein.
Genauer, wie durch die Module GDI 64, DD 66 und D3D 68 gezeigt ist, implementiert der Gerätetreiber 50 der vorliegenden Erfindung vorzugsweise die O/S-API des Gerätetreibers 50 in getrennten Einheiten, die für bestimmte Abschnitte des Betriebssystemkerns 56 und/oder der Betriebssystemerweiterungen 58 spezifisch sind. In der bevorzugten Ausführungsform unterstützt somit das GDI-Modul 64 vorzugsweise die Flachmodel-DIBEngine-Treiberschnittstelle, die von Microsoft für das Produkt MS-Windows'95^TM vordefiniert worden ist. In ähnlicher Weise unterstützt das Direktzeichenmodul 66 die hardwareunabhängige Schnittstelle für die Standard-Direktzeichnungs-API. Das D3D-Modul 68 unterstützt die angekündigte Direkt-3D-API von Microsoft für Windows'95^TM. Eine Dokumentation für jede dieser APIs ist als Teil des Microsoft-Softwareentwicklungsbaukastens (SDK) und des Microsoft-Gerätetreiberbaukastens (DDK) erhältlich, die als Handelsprodukte von Microsoft, Inc., Redmond, Washington, erhältlich sind. Die dynamische Ladefähigkeit der vorliegenden Erfindung erlaubt somit die umfassende API-Unterstützung, die vom Gerätetreiber 50 bereitgestellt wird, durch das dynamische Laden von zusätzlichen Betriebssystemschnittstellenmodulen leicht zuzuschneiden und zu erweitern.
Das Shell-Modul 72, das die Module O/S und GRX 70, 71 enthält, präsentiert sowohl herkömmliche als auch proprietäre API-Schnittstellenteile der Betriebssystemschicht 54 bei Bedarf, um sowohl herkömmliche als auch proprietäre Unterstützungsfunktionen durch die Operation des Gerätetreibers 50 zu unterstützen. Der herkömmliche API-Teil enthält einen Initialisierungseinsprungpunkt, der der Betriebssystemschicht 54 erlaubt, die Initialisierung des Shell-Moduls 72 beim Laden in den Speicher 16 einzuleiten. Ein allge meiner Standardbeendigungsaufrufeinsprungpunkt wird ebenfalls bereitgestellt. Dieser Einsprungpunkt erlaubt der Betriebssystemschicht 54, dem Gerätetreiber 50 zu signalisieren, dass ein Herunterfahren der Betriebssystemschicht 54 bevorsteht und dass eine geordnete Beendigung des Gerätetreibers erforderlich ist.
Die Proprietären API-Einsprungpunkte, die vom Shell-Modul 72 präsentiert werden, enthalten Einsprungpunkte, die für das Lesen und Schreiben von Daten sorgen, die die aktuelle auf der Anzeige 32 präsentierte Benutzeroberfläche definieren, das aktuelle Darstellungsfeld und bestimmte Daten, die die Operation des Gerätetreibers 50 definieren. Diese letzteren Informationen können die Einstellung der aktuellen physikalischen Farbtiefe der Anzeige 32, die aktuelle Farbe und das Muster des Anzeigezeigers 38, und eine Anzahl von weitgehenden video-hardwarespezifischen Aspekten enthalten, wie z. B. die Verschachtelung, den Videosynchronisationstyp, das Videoschnellrollen, und Farbfreigabeoptionen des Gerätetreibers 50.
Schließlich stellt das Betriebssystemmodul 72 die Gerätetreiberunterstützungsroutinen zur Verfügung, die die Betriebssystemschicht 54 aufrufen, um Basis-Betriebssystemdienste zu erlangen. In der bevorzugten Ausführungsform der vorliegenden Erfindung umfassen diese Systemdienste die Speicherzuweisung, die Freigabe von vorher zugewiesenen Speicher, das Laden und Entladen von dynamischen Verknüpfungsbibliotheken, Speichermanagementfunktionen, wie z. B. einem Speicherobjekt zu ermöglichen, ausführbar zu sein, oder ein Speicherobjekt im realen Speicher zu sperren, um den ausführbaren oder gesperrten Status der Speicherobjekte zu deaktivieren, um Daten an definierten I/O-Adressen zu lesen und zu schreiben, und um genannte Datendateien, die typischerweise mittels des Massenspeicherperipheriegerätes 18 gespeichert werden, zu öffnen, zu lesen und zu schließen.
B. Gerätetreiber-Software-Architektur – untere Ebene:
Das Shell-Modul 72 sorgt ferner für eine dynamische Konfiguration des Gerätetreibers 50 bezüglich der besonderen Instanz der Videoanzeigesteuervorrichtung 19. Obwohl irgendeine von einer Anzahl funktional ähnlicher Videoanzeigesteuervorrichtungen 19 im Computersystem 10 verwendet werden kann, sorgt der Gerätetreiber 50 der vorliegenden Erfindung für die dynamische Auswahl und das Einbinden eines Leiterplattentreibers 74 in den Gerätetreiber 50, um die Hardware-Besonderheiten der bestimmten Videoanzeigesteuervorrichtung 19 optimal zu unterstützen. Das Shell-Modul 72 wählt einen bestimmten Leiterplattentreiber 74 aus irgendeiner Anzahl von Varianten aus, der den Hauptaspekten der bestimmten Videoanzeigesteuervorrichtung 19 entspricht. In der Praxis ist der Hauptaspekt einer bestimmten Videoanzeigesteuervorrichtung 19 die spezifische Architektur des IC-Graphikbeschleuniger-Chips oder des Chipsatzes, der bei der Implementierung der Steuervorrichtung 19 verwendet wird. Ein einzelner Leiterplattentreiber 74 kann somit einer wohldefinierten Familie von spezifischen Varianten der Anzeigesteuervorrichtung 19 entsprechen. Andere Leiterplattentreiber können konstruiert werden, um anderen Familien von Steuervorrichtungen mit anderer Definition zu entsprechen.
Der Leiterplattentreiber 74 sorgt für eine zusätzliche Schicht von dynamischer Konfiguration des Gerätetreibers 50 durch die selektive Unterstützung eines Satzes von Hardware-Schnittstellenmodulen. Diese Hardware-Schnittstellenmodule sind dynamisch ladbar als Komponentenelemente des Gerätetreibers 50 und entsprechen im Wesentlichen den individuellen Unterelementen einer bestimmten Implementierung der Videoanzeigesteuervorrichtung 19. In einer bevorzugten Ausführungsform der vorliegenden Erfindung enthält der Satz von Hardware-Schnittstellenmodulen ein Taktmodul 76, ein DAC-Modul 78, ein CODEC-Modul 80, ein Hardware-Cursor-Unterstützungsmodul 82, ein Videomodul 84, ein zweidimensionales Graphiksteuermodul 86 und ein dreidimensionales Graphiksteuer-(3D)-Modul 88. Der bestimmte Satz von Hardware-Schnittstellenmodulen, die dynamisch in den Gerätetreiber 50 geladen werden, wird bestimmt durch den Leiterplattentreiber 74 in Übereinstimmung mit spezifischen Unterelementen, die in der Implementierung der Videoanzeigesteuervorrichtung 19 vorhanden sind. Das heißt, in Abhängigkeit von der spezifischen Implementierung des Takt-Unterelements 28 wird vom Leiterplattentreiber 74 ein bestimmtes und entsprechendes Taktmodul 76 identifiziert und dynamisch in den Gerätetreiber 50 geladen. Folglich kann z. B. das Einbinden einer neuen Version eines DAC-Unterelements 22 in den ansonsten im Wesentlichen bestehenden Entwurf der Videoanzeigesteuervorrichtung 19 unmittelbar durch eine entsprechende Überarbeitung der Funktionalität von im Wesentlichen nur dem DAC-Modul 78 des Gerätetreibers 50 aufgenommen werden. Die Unterteilung der unterelementspezifischen Aspekte des Gerätetreibers 50 in dynamisch ladbare Module erlaubt somit, dass signifikante Überarbeitungen der endgültigen Konfigurationsleistungsfähigkeit und der Operation des Gerätetreibers 50 isoliert vom Rest des Gerätetreibers 50 durchzuführen. Solche hardwarespezifischen Änderungen sind auch effektiv isoliert von anderen Hardware-Schnittstellenmodulen und von den höheren Schichten des Gerätetreibers 50. Die Prüfung der Konfiguration eines Gerätetreibers 50 für eine neue Version der Anzeigesteuervorrichtung 19 kann somit zuverlässig nur mit den bestimmten neuen oder überarbeiteten Hardwareschnittstellenmodulen durchgeführt werden.
In der Praxis können einige der Hardware-Schnittstellenmodule statisch mit dem Leiterplattentreiber 74 verknüpft sein. Wenn eine Basisergänzung von Modulen immer oder nahezu immer mit einem bestimmten Leiterplattentreiber 74 verwendet wird, wird eine Optimierung erzielt durch Laden der Module zusammen mit dem Leiterplattentreiber 74. Die anschließende Verwendung eines statisch verknüpften Moduls kann ebenfalls effektiv überschrieben werden durch Vorsehen eines dynamisch verknüpfbaren Moduls zum Unterstützen des entsprechenden Unterelements. Dynamisch ladbare Module werden bevorzugt gegenüber entsprechenden statisch verknüpften Modulen verwendet.
III. Gerätetreiberinitialisierung:
Der Prozess der Initialisierung des Gerätetreibers 50 der vorliegenden Erfindung ist in 3 allgemein dargestellt. Diese Initialisierungsprozess wird mit Bezug auf die bevorzugte Ausführungsform beschrieben, die mit dem Betriebssystem MS-Windows'95^TM arbeitet.
A. Anfängliche Obere-Ebene-Initialisierung:
In Verbindung mit der herkömmlichen Ausführung der Betriebssysteminitialisierungen wird das Shell-Modul 72 in den Speicher 16 geladen 90, infolge einer herkömmlichen Systemtreiberreferenz in der Registrierungsdienste- Datenbankdatei. Sobald es sich im Speicher befindet, wird der Initialisierungseinsprungpunkt des Shell-Moduls 72 aufgerufen, um die gerätetreiberabhängigen Initialisierungen einzuleiten. Die Initialisierungsroutine des Shell-Moduls 72 sorgt für die Erzeugung 92 eines Shell-Objekts 126 (SHELLOBJ), und anschließend eines Betriebssystemobjekts 128 (OSOBJ) bei 93.
Das Shell-Objekt wird als Obere-Ebene-Datenstruktur verwendet, die mit der Struktur des Gerätetreibers 50 logisch verknüpft ist. Die signifikanten Elemente des Shell-Objekts sind in Tabelle 1 angegeben.
Wie gezeigt ist, enthält das Shell-Objekt einige Globalkennzeichendaten, API-Aufrufeinsprungpunkte, Zeiger auf Hoch-Ebene-Softwareobjekte, die Komponenten des Gerätetreibers 50 repräsentieren, und eine Anzahl von Shell-Bibliotheksroutinen oder Funktionen, die verwendet werden, um die interne Operation des Gerätetreibers 50 zu unterstützen.
Das Betriebssystemobjekt bietet API-Aufrufzugriff auf Unterstützungsfunktionen der Betriebssystemschicht 54. Die Elemente des Betriebssystemobjekts sind in Tabelle II angegeben.
Wie durch die unterstützten Einsprungpunkte gezeigt ist, stellt das O/S-Objekt eine Aufrufschnittstelle zur Betriebssystemschicht 54, eine Aufrufschnittstelle zu Niedrig-Ebene- und BIOS-Funktionen, sowie eine Aufrufschnittstelle zu plattformspezifischen Funktionen zur Verfügung. Diese plattformspezifische Aufrufschnittstelle repräsentiert eine Anzahl von Hilfsprogramm- oder Bibliotheksroutinen, die dazu dienen, Plattformportabilitätseinzelheiten zu verstecken. Obwohl diese Routinen nicht unbedingt den anderen Funktionen des O/S-Objekts zugeordnet sind, sind sie hier zusammengefasst, um alle plattformspezifischen Aufrufe und Funktionen in einem Modul zu sammeln, wodurch Plattformportabilitätsänderungen im Wesentlichen auf dieses eine Modul beschränkt werden. Ferner werden diese Routinen im Allgemeinen am besten unter Verwendung von Assembler-Codierung implementiert, ebenso wie der Rest des Moduls.
B. Niedrig-Ebene-Initialisierung:
Das Shell-Modul 72 leitet als Nächstes das dynamische Laden des Rests des Gerätetreibers 50 ein. Um den korrekten Leiterplattentreiber 74 zu identifizieren, führt das Shell-Modul 72 eine anfängliche Bewertung 94 der Videoanzeigesteuervorrichtung 19 durch, um einen bestimmten Leiterplattentyp zu identifizieren. Ein Leiterplattenidentifizierer wird vorzugsweise von der Steuervorrichtung 19 aus einer Datenstruktur gelesen, die auf der Steuervorrichtung 19 physikalisch angesiedelt ist und in einem "BoardData"-Feld (Leiterplattendatenfeld) des Shell-Objekts gespeichert ist. In einer bevorzugten Ausführungsform wird der Leiterplattenidentifizierer anfänglich in einem herkömmlichen ROM 29 auf der Leiterplatte gespeichert, der sich auf der Videoanzeigesteuervorrichtung 19 befindet und über die Registerschnittstelle 30 zugänglich ist. Tabelle III zeigt die bevorzugte Struktur der Leiterplattenidentifizierer-Datenstruktur.
Das Feld "ID" stellt einen statischen Datenwert zur Verfügung, der die Leiterplattenidentifiziererstruktur als mit dem Gerätetreiber 50 konform bestätigt. Das Feld "Revision" wird verwendet, um die genaue Struktur der Leiterplattenidentifiziererstruktur zu definieren, sollten andere Strukturen zu einem bestimmten zukünftigen Zeitpunkt implementiert werden. Das Feld "StructureSize" definiert die Größe der Struktur. Das Feld "BoardFamily" speichert einen Wert, der verwendet werden kann, um hauptsächlich den Leiterplattentreiber 74 zu identifizieren, der als Teil des Gerätetreibers 50 zu laden ist und benötigt wird, um diese bestimmte Instanz der Videoanzeigesteuervorrichtung 19 zu unterstützen. Die Werte der Leiterplattenidentifiziererstruktur, die wenigstens den Wert "BoardFamily" enthält, werden als Schlüssel verwendet, um ein Schlüsselname-Nachschlagen in einer Datei board.dat durchzuführen. Der Schlüssel ist vorzugsweise als eine einfache Verkettung der signifikanten Leiterplattenidentifiziererfeldnamen ausgeführt. Die Datei board.dat ist vorzugsweise eine flache Datei, die Schlüssel mit entsprechenden Dateinamen der spezifischen Instanzen der Leiterplattentreiber 74 korreliert.
Sobald ein bestimmter Leiterplattentreiber 74 identifiziert ist 94, startet das Shell-Modul 72 einen Aufruf über das Betriebssystemmodul 70, um den Gerätetreiber 74 zu laden, der dem Schlüsselwert entspricht. Daraufhin lädt 96 die Betriebssystemschicht 54 den angeforderten Leiterplattentreiber 74 in den Speicher 16 und gibt einen Speicherzeiger an das Shell-Modul 72 zurück. Der Initialisierungseinsprungpunkt des Leiterplattentreibers 74 wird anschließend aufgerufen.
Als Teil der Initialisierung des Leiterplattentreibers 74 wird ein Leiterplattenobjekt 98 erzeugt. Obwohl das Leiterplattenobjekt streng genommen weder ein Betriebssystem- noch ein Hardwareschnittstellen-Modul repräsentiert, richtet es eine Basisdatenstrukturform ein, die zur Bequemlichkeit von den Objekten verwendet wird, die die Betriebssystem- oder Hardwareschnittstellen-Module repräsentieren. Die Struktur des Leiterplattenobjekts ist in Tabelle IV gezeigt.
Als Teil der Leiterplattenobjektinitialisierung wird ein Zeiger auf die Leiterplattenidentifiziererstruktur "BoardData" von der Shell 72 erhalten 100. Die weiteren Felder in der Leiterplattenidentifiziererstruktur werden anschließend untersucht, um die genauen Typen aller Unterelemente zu identifizieren, die in der Videoanzeigesteuervorrichtung 19 vorhanden sind. Voreingestellte codierte Werte werden verwendet, um die genaue Instanz eines Unterelements zu identifizieren. Die Felder des Leiterplattenidentifizierers entsprechen im Allgemeinen vorzugsweise den festen Aspekten der Unterelemente der Steuervorrichtung 19. Zum Beispiel kann durch die Leiterplattenidentifiziererstruktur der Typ eines DAC oder der Typ eines Videospeichers, VRAM oder DRAM, bereitgestellt werden.
Wo ein Aspekt eines Unterelements nicht fixiert ist, da es vielleicht im Gebiet aufrüstbar ist, muss der genaue Aspekt durch ein herkömmliches Verfahren bestimmt werden. Zum Beispiel kann die Menge an Anzeige-RAM (Videospeichergröße), die auf der Videoanzeigesteuervorrichtung 19 verfügbar ist, geändert werden, sobald die Steuervorrichtung in Betrieb gesetzt worden ist. Der Leiterplattenidentifizierer ist jedoch statisch und wird zum Zeitpunkt der Herstellung der Steuervorrichtung 19 eingerichtet. Dementsprechend kann eine herkömmliche Speicherabtastroutine verwendet werden, um die Gesamtmenge an auf der Videoanzeigesteuervorrichtung 19 vorhandenen Videospeicher unter solchen Umständen genau zu bestimmen. Die Anzeigesteuervorrichtung 19 braucht ferner keinen Leiterplattenidentifizierer 29 aufweisen, weil sie vielleicht eine Altimplementierung der Steuervorrichtung 19 ist. Eine vernünftige Identifikation der auf der Steuervorrichtung 19 vorhandenen Unterelemente kann anschließend aus Informationen hergeleitet werden, die über einen herkömmlichen Int10-BIOS-Aufruf erhalten werden.
Das letzte Feld in der Leiterplattenidentifiziererstruktur ist ein Feld "BoardDependentInfo". Dieses Feld bietet einen wortbreiten Bitfelddatenbereich, der vorzugsweise verwendet wird, um zusätzliche Betriebseigenschaften eines bestimmten Leiterplattentyps und Modells zu kennzeichnen. Diese Kennzeichen werden implementierungsabhängig und eindeutig vom Leiterplattentreiber 74 decodiert. Genauer können diese Kennzeichenbits verwendet werden, um genaue Konfigurationsoptionen zu identifizieren, die ansonsten durch die anderen Felder des Leiterplattenidentifizierers nicht abgedeckt sind. Zum Beispiel kann ein Kennzeichenbit verwendet werden, um die Anwesenheit einer kleineren Unterelementoption zu identifizieren, die mit späteren Versionen des Gerätetreibers 50 verwendet werden kann.
Aus der Leiterplattenidentifiziererstruktur bestimmt der Leiterplattentreiber 74 somit 102 einen bestimmten Satz von Hardware-Schnittstellenmodulen, die benötigt werden, um die Videoanzeigesteuervorrichtung 19 optimal zu unterstützen. Der Leiterplattentreiber 74 fordert anschließend das sequentielle Laden 104 des identifizierten Satzes von Hardware-Schnittstellenmodulen, die nicht bereits statisch mit dem Leiterplattenmodul verknüpft sind, über das Betriebssystemmodul 70 an. Wenn jedes Hardware-Schnittstellenmodul 76–88 in den Speicher 16 geladen worden ist, wird die Initialisierungsroutine jedes Moduls aufgerufen 106, um ein entsprechendes Softwareobjekt einzurichten. Im bevorzugten Gerätetreiber 50 ist jedes Hardware-Schnittstellenobjekt als eine Datenstruktur konstruiert, die einen gewöhnlichen Kopfabschnitt und einen hardwareabhängigen Abschnitt enthält. Der gewöhnliche Kopfabschnitt ist vorzugsweise eine Objektkopfdatenstruktur (OBJHDR), die die in Tabelle V identifizierten Felder enthält.
Das Feld "ObjectVer" stellt einen eindeutigen Identifizierer zur Verfügung, der die genaue Implementierung des vom kapselnden Hardware-Schnittstellen- Objekt unterstützten Hardware-Unterelements spezifiziert. Das Feld "Module" enthält den Speicherzeiger, der von dem Betriebssystem zurückgegeben wird und auf den Speicherort des gekapselten Hardware-Schnittstellenmoduls zeigt. Das Feld "ObjectDataInstance" stellt einen Zeiger auf den privaten Datenbereich zur Verfügung, der für diese Instantiierung des Hardware-Schnittstellenobjekts reserviert ist. Das Feld "RegClassHandler" definiert, ob das zugehörige Hardware-Unterelement Schnittstellenregister aufweist, die als Teil des Aufrufs einer Modussetzoperation programmiert werden müssen. Wenn der Wert des Feldes gleich Null ist, dann ist irgendeine erforderliche Modussetzprogrammierung fest in das Modul codiert, das vom Hardware-Schnittstellenobjekt gekapselt wird. Wenn das Feld nicht gleich 0 ist, dann ist der Wert des Feldes der Zeiger auf eine Struktur, die Definitionen der Registernamen und Schnittstellenprozeduren enthält, die beim Unterstützen einer Modusänderung verwendet werden können. Die Struktur des Registerklassenhantierers ist in Tabelle VI gezeigt:
Die Felder "ObjectInit" und "ObjUnInit" des Objektkopfes stellen Aufrufadressen für die Initialisierung und Freigabe des Hardware-Schnittstellenmoduls zur Verfügung, das vom vorliegenden Hardware-Schnittstellenobjekt gekapselt wird. Das Feld "ModeSet" eines Objektkopfes richtet den Hardware-Schnittstellenmodul-Einsprungpunkt ein, der verwendet wird, um eine Modusänderung dem Hardware-Schnittstellenobjekt zu signalisieren. In der bevorzugten Ausführungsform können drei unterschiedliche Aufrufe für diesen Einsprungpunkt durchgeführt werden. Jeder Aufruf wird anhand des Operanden des Aufrufes unterschieden, um zu spezifizieren, dass ein Modussetzen stattfinden soll, um ein Modussetzen aufzurufen, und dass ein Modussetzen abgeschlossen worden ist.
Schließlich stellt das Feld "SetDPMSState" einen Einsprungpunkt für Dienstleistungsänderungen im Energiemanagementzustand des Systems 10 zur Verfügung, die für ein bestimmtes Modul spezifisch sind.
Somit sorgen die Hardware-Schnittstellenmodul-Initialisierungsroutinen für die Erzeugung einer Instanz eines kapselnden Hardware-Schnittstellenobjekts, das Speicher für den hardware-schnittstellenabhängigen Abschnitt des Hardware-Schnittstellenobjekts enthält, Initialisieren der objektspezifischen Felder in dieser Instanz des Objekts, und für eine Zuweisung irgendwelcher Instanzdaten, die für diese Instantiierung des Hardware-Schnittstellenobjekts privat zu halten sind. Der Zeiger auf die Instanzdaten ist im Feld "ObjectDataInstance" im Objektkopf gespeichert. Die Initialisierungsroutine gibt anschließend einen Zeiger auf das Hardware-Schnittstellenobjekt zurück. Dieser Zeiger wird in einem Elementfeld der Leiterplattenobjekt-Unterstruktur gespeichert 108.
Ein Basis-Hardware-Schnittstellenobjekt, genauer ein Taktobjekt, ist in Tabelle VII definiert.
Wie gezeigt ist, sind einem Takt-Unterelement keine hardwarespezifischen Funktionen zugeordnet. Die Taktfrequenz ist jedoch ein typischer programmierbarer Aspekt eines Takt-Unterelements, und ist ferner eng mit einer Modussetzoperation verknüpft. Folglich enthält das Feld RegClassHandler der Objektkopfstruktur einen Zeiger auf eine Registerklassenhantierer-Struktur, die die notwendigen Registerdefinitionen enthält, um den Zugriff auf die Schnittstellenregister des Takt-Unterelements zu unterstützen, die letztendlich die auf der Platine der Steuervorrichtung 19 erzeugten Taktfre quenzen steuern.
Tabelle VIII zeigt eine etwas komplexere Objektdefinition, z. B. das Hardware-Cursor-Objekt.
Wie vorher ist ein Objektkopf als ein Element des Cursor-Objekts enthalten. Das Feld CursorEnable stellt einen Zeiger auf einen Einsprungpunkt des Hardware-Cursor-Schnittstellenmoduls zur Verfügung, um die Sichtbarkeit des Hardware-Cursors in Abhängigkeit vom Zustand eines Aufrufparameters einzuschalten oder auszuschalten. Das Feld CursorSet stellt einen Zeiger auf einen Einsprungspunkt 15 zur Verfügung, der für das Setzen des Cursor-Musters auf das durch den Operanden des Aufrufs spezifizierte Muster einzustellen. Das Feld CursorMove identifiziert den Einsprungpunkt in eine Routine zum Spezifizieren des Brennpunkts des Cursors auf der Anzeige 32 durch X- und Y-Operanden, die mit dem Aufruf bereitgestellt werden. Das Feld CursorSetColor identifiziert die Routine, die verwendet wird, um einen auf der Anzeige 32 präsentierten zweifarbigen Cursor in der Farbe zu erweitern.
Andere Hardware-Schnittstellenobjekte umfassen das DAC-Objekt 130 (DACOBJ; Tabelle IX), das Videoobjekt 136, das Graphikobjekt 138 (DRAWENGOBJ; Tabelle X) und das 3D-Graphikobjekt 140.
Eine Unterstruktur, auf die von DrawEngObj verwiesen wird, enthält eine Anzahl von Basiszeichenfunktionen. Diese Unterstruktur ist innerhalb des Zeichenmaschinenobjekts eingerichtet, mit einer Kopie der Funktionszeiger begin, die im Coderaum des GDI-Objekts gehalten werden, um einen direkten Zugriff auf die Funktionen innerhalb der linearen Ausführung der Aufrufe vom GDI-Objekt in Reaktion auf API-Aufrufe zu erlauben. Die Unterstruktur ist in Tabelle XI definiert.
Wie mit diesem Objektdefinitionen gezeigt worden ist, initialisiert jedes der Hardware-Schnittstellenmodule 76–88, um ein entsprechendes Hardware-Schnittstellenobjekt einzurichten, das einen standardisierten Abschnitt enthält, der das einfache Management der Objekte erlaubt, sowie eine hardwarespezifische Erweiterung enthält, die einen festen Satz von objektspezifischen Einsprungpunkten bereitstellt. Diese objektspezifischen Einsprünge werden von der Initialisierungsroutine des gekapselten Hardware-Schnittstellenmoduls mit Zeigerreferenzen gefüllt. Die Zeigerreferenzen dienen Funktionen innerhalb des gekapselten Moduls, die die logische referenzierte Funktion bereitstellen. Wo eine spezifische Implementierung der logischen Funktion auf der Grundlage der aktuellen Farbtiefe, der Bildschirmauflösung oder einer anderen von der Steuervorrichtung bezeichneten Eigenschaft abweicht, werden die gekapselten Module vorzugsweise mit entsprechenden spezifischen Einsprungpunkten implementiert. Eine geeignete Teilmenge von Einsprungpunkten wird durch die Zeigerreferenzen identifiziert, die zu Objekteinsprungspunkten initialisiert werden, um somit implizit eine charakteristische geeignete Operation während der fortlaufenden Operation des Gerätetreibers 50 einzurichten, ohne wiederholte Laufzeittests des aktuellen charakteristischen Zustands der Steuervorrichtung 19.
Folglich können die individuellen Objekte auf der Grundlage der gewöhnlichen OBJHDR-Aspekte der Objektstrukturen umfassend gemanagt werden, während sie gleichzeitig verwendet werden, um wohldefinierte Einsprungpunktschnittstellen für jeden bestimmten Typ von Hardware-Schnittstellenobjekt unabhängig von zugrunde liegenden funktionalen und die Implementierung betreffenden Einzelheiten einzurichten, insbesondere einschließlich abweichender Implementierungen von Funktionen auf der Grundlage von Eigenschaften, wie z. B. der aktuellen Farbtiefe und der Bildschirmauflösung.
In der bevorzugten Ausführungsform der vorliegenden Erfindung, wo eine Datei board.dmm, die von einem Leiterplattenidentifizierer identifiziert wird, nicht explizit das Vorhandensein eines Taktgebers, eines DAC oder eines Hardware-Cursors als auf der Videoanzeigesteuervorrichtung 19 vorhanden spezifiziert, werden entsprechende Vorgabemodule verwendet, die mit dem Leiterplattentreiber 74 als Vorgabemodule statisch verknüpft sind. Nachdem der Satz der Hardware-Schnittstellenmodule identifiziert worden ist, geladen und initialisiert worden ist, werden Null-Zeiger im Leiterplattenobjekt vom Leiterplattentreiber 74 erfasst. Wenn z. B. ein Hardware-Cursor-Objekt dann nicht existiert, erzeugt der Leiterplattentreiber 74 das Objekt und initialisiert die hardware-abhängigen Einsprungpunkte auf entsprechende Vorgaberoutinen innerhalb des Gerätetreibers 74. Die Funktionalität eines Hardware-Cursors kann somit durch Software-Emulation unterstützt werden, oder, was typischer ist, als eine inhärente Komponente eines weiteren der Hardware-Schnittstellenobjekte. In jedem Fall wird das Vorgabeobjekt mit dem Leiterplattenobjekt verknüpft und stellt anschließend die gleiche inhärente Funktionalität zur Verfügung wie ein dynamisch geladenes und verknüpftes Hardware-Cursor-Objekt.
C. Ober-Ebene-Initialisierungsabschluss:
Sobald die Hardware-Schnittstellenobjekte initialisiert worden sind, kehrt die Initialisierungsroutine des Leiterplattentreibers 74 zum Shell-Modul 72 zurück. Das Shell-Modul 72 rückt anschließend vor, um das GRX-API-Objekt 71 zu erzeugen 109. Das GRX-Objekt dient als eine interne universale oder virtualisierende Schnittstelle zu dem Betriebssystemschnittstellenobjekte 64, 66, 68. Das GRX-Objekt 71 präsentiert eine relativ einfache Schnittstelle, wie in Tabelle XII dargelegt ist.
Der Aufrufeinsprungpunkt GrxApiFastCopy stellt einen gemeinsamen Zugangspunkt zur Verfügung, der von allen Betriebssystem-API-Ebene-Modulen nutzbar ist, insbesondere einschließlich des Shell-Moduls, um Bitfelder zu manipulieren, die im Auf-Bildschirm- und im Neben-Bildschirm-Videospeicher angeordnet sind. Die Einrichtung eines gemeinsamen Zugangspunktes vereinfacht das Videospeichermanagement. Der Aufrufeinsprungpunkt GryApiColorMatch stellt ebenfalls einen gemeinsamen Zugangspunkt zur Verfügung, der von allen Betriebssystem-API-Ebene-Modulen nutzbar ist, um eine logische oder physikalische Farbübersetzung bei der aktuellen Farbtiefe des Bildschirms 32 durchzuführen.
Der Initialisierungseinsprungpunkt innerhalb des OBJHDR des GRX-Objekts 71 wird vom Shell-Modul 72 aufgerufen, um die Einrichtung der Betriebssystem-Schnittstellenobjekte 64, 66, 68 einzuleiten 110. In der bevorzugten Ausführungsform der vorliegenden Erfindung werden die GDI und DD-Objekte 64, 66 innerhalb der GRX-Objektinitialisierungsroutine statisch identifiziert. Alternativ, oder zusätzlich, können Betriebssystem-Schnittstellenobjekte durch das Shellmodul 72 mittels Referenz auf eine Konfigurationsdatei interface.dat identifiziert werden. Die identifizierten Betriebssystemschnittstellenmodule werden sequenziell in den Speicher 16 geladen 112, wenn sie nicht statisch mit dem Shell-Modul 72 verknüpft sind.
Wenn jedes Betriebssystemmodul geladen wird 112, wird eine Modulinitialisierungsroutine 114 aufgerufen. Die Initialisierung jedes Betriebssystemschnittstellenmoduls führt zur Erzeugung eines entsprechenden Betriebssystemschnittstellenobjekts. Wie bei den Hardware-Schnittstellenobjekten enthalten die Betriebssystemschnittstellenobjekte vorzugsweise jeweils eine Objektkopf-Unterstruktur (OBJHDR), die eine gemeinsame Basis für die Manipulation der Betriebssystemschnittstellenobjekte einrichtet. Die Verwendung des Objektkopfes bietet ferner Unterstützung für einen Aufruf, um eine Modusänderung durch den Gerätetreiber 50 zu signalisieren. Die Betriebssystemobjekte unterstützen ihrerseits bei Bedarf private Datenräume für jede Instantiierung der Objekte.
Das GDI-Objekt 120 wird mit der in Tabelle XIII gegebenen Definition erzeugt.
Das GDI-Objekt 120 enthält oder bietet eine verknüpfte Referenz auf eine Unterstruktur-Schnittstelle (DibengObj) der Standard-Dib-Maschine. Die Unterstruktur ist in Tabelle XIV definiert.
Die weiteren Standard-Unterstrukturen des DibengObj sind in den Tabellen XV und XVI definiert.
Die Tabellen XV und XVI zeigen die Objekte, die das Direktzeichnungsobjekt 124 definieren.
Um den Gebrauch sowohl in 16- als auch 32-Bit-Umgebungen zu unterstützen, wird eine zusätzliche Unterstruktur ObjInstData verwendet, um sowohl 16- als auch 32-Bit-Zeiger auf die Komponenten des Gerätetreibers 50 bei der Unterstützung sowohl 16- als auch 32-Bit-API-Aufrufen zur Verfügung zu stellen.
Wenn schließlich die Initialisierung jedes der Betriebssystem-Schnittstellenobjekte abgeschlossen ist, wird eine Verknüpfung 116 zwischen dem GRX-Objekt 71 und den GDI- und DD-Objekten 120, 122 eingerichtet. Die GRX-Initialisierungsroutine kehrt anschließend zur Shell zurück. Ferner werden anschließend alle Betriebssystemschnittstellenobjekte mit dem Shell-Objekt verknüpft. Die Initialisierungsroute des Shell-Moduls 72 springt anschließend zurück.
IV. Operationszustandkonfiguration:
4 zeigt die logische Konfiguration des Gerätetreibers 50 während des Betriebs in einem einzelnen Kontextzustand und mit allen Betriebssystem- und Hardware-Schnittstellenobjekten, die logisch ein entsprechendes ausführbares Modul kapseln. Ein logisch ungekapselter Abschnitt des Shell-Treibers 74 bleibt als eine verallgemeinerte Shell-Bibliothek 72' resident. In ähnlicher Weise bleibt ein logisch ungekapselter Abschnitt des Leiterplattentreibers 74 als Leiterplattenbibliothek 74' resident. Beiden Bibliotheken 72', 74' dienen als gemeinsame Betriebsmittel, die die interne Funktion des Gerätetreibers 50 unterstützen. Aus der Perspektive der Treibersoftware ist somit der initialisierte Gerätetreiber 50 durch die Betriebssystemschnittstellenobjekte, die die durch den Gerätetreiber 50 präsentierte Betriebssystem-API bindend einrichten, und die Hardware-Schnittstellenobjekte definiert, die die hardwarespezifische Schnittstellen zwischen dem Gerätetreiber 50 und den Hardware-Schnittstellenregistern 30 einrichten.
A. Obere-Ebene-Beziehungen:
Die Betriebssystem-Schnittstellenobjekte, einschließlich eines GDI-Objekts 120, eines Direktzeichnungsobjekts 122, eines Direkt-3D-Objekts 124 und eines Shell-Objekts 126, repräsentieren einen Satz von Objekten, die logisch voneinander durch die Definition der partialen APIs getrennt sind, die sie der Betriebssystemschicht 54 präsentieren. Die Überarbeitung einer bestehenden API-Aufruf-Unterstützung und das Hinzufügen neuer API-Aufrufe zu irgendeinem bestimmten Betriebssystemschnittstellenobjekt hat, durch Gestaltung, im Wesentlichen keinen Einfluss auf die Implementierung oder die Operation anderer Betriebssystemschnittstellenobjekte. Ferner kann die Unterstützung für eine neue partiale API, entweder als durch die Betriebssystemschicht 54 neu definiert oder zum Unterstützen von direkt von einer Anwendung 60 ausgehenden Aufrufen, leicht durch Definition eines entsprechenden Betriebssystemschnittstellenobjekts und eines gekapselten Betriebssystemschnittstellenmoduls bereitgestellt werden. Wenn jedoch ein neuer oder überarbeiteter API-Aufruf eine Funktion verwendet oder erfordert, die von irgendwelchen anderen API-Aufrufen signifikant verschieden ist, die durch die bestehenden Betriebssystemschnittstellenobjekte unterstützt werden, können zusätzliche Bibliotheksroutinen verwendet werden, um sie der Shell-Bibliothek 72' hinzuzufügen.
Die Shell-Bibliothek 72' ist logisch von den Betriebssystemschnittstellenmodulen getrennt, um eine Bibliothek von Routinen bereitzustellen, die zum Einrichten eines Satzes gemeinsamer oder virtualisierter Unterstützungsfunktionen dienen, welche von dem vollen Satz der Betriebssystemschnittstellenobjekte nutzbar ist. Jedes der Betriebssystemschnittstellenobjekte ist vorzugsweise funktional beschränkt auf (1) Unterstützen eines wohl definierten API-Aufruf-Satzes, (2) Bereitstellen einer Parameterüberprüfung für jeden unterstützen API-Aufruf, (3) potentielles Managen eines privaten Datenraums für Datenobjekte, die über Kontextänderungen hinweg in Betrieb des Gerätetreibers 50 bestehen bleiben sollen, (4) Ausgeben einer Folge von ein oder mehr virtualisierten Aufrufen an die Shell-Bibliothek 72', um jeden der API-Aufrufe, die von dem Objekt unterstützt werden, funktional zu implementieren, und schließlich (5) Formatieren und Zurückgeben von Daten an die Betriebssystemschicht 54 in einer Weise, die für jeden vom Objekt unterstützen API-Aufruf angemessen ist.
Wie mittels der vorliegenden Erfindung erkannt wird, werden Varianten von vielen Aufrufen an den Gerätetreiber 50 zu unterschiedlichen spezifischen APIs geleitet. Diese Varianten unterscheiden sich in spezifischen Aspekten, wie z. B. der besonderen Form und Folge der Operandendaten, die mit dem Aufrufen bereitgestellt werden. Ebenso ist die Überprüfung der bestimmten Operandendaten für jeden API-Aufruf spezifisch. Jedes Objekt führt daher vorzugsweise eine API-Aufruf-spezifische Operandenüberprüfung durch, und möglicherweise eine Konversion der Operandendaten in ein Format, das einheitlich ist, im Vergleich zu anderen funktionalen ähnlichen API-Aufrufen, die durch diese oder andere Betriebssystemschnittstellenobjekte unterstützt werden. Die Sätze von einem oder mehreren API-Aufrufen werden somit intern für den Gerätetreiber 50 virtualisiert.
Jedes Betriebssystemschnittstellenobjekt managt einen kontextspezifischen Datenraum, falls erforderlich, um diesbezügliche Datenobjekte zu bewahren, die von Operanden der API-Aufrufe abgeleitet oder als diese bereitgestellt werden, welche von den Betriebssystemschnittstellenobjekt unterstützt werden. Zum Beispiel kann das GDI-Objekt 120 ein Datenobjekt halten, dass das auflösungsabhängige Bitabbildungsmuster oder Farben definiert, die einer Instanz des Anzeigezeigers 38 in einem gegebenen Kontext zugeordnet sind. Folglich kann bei Wiederaufnahme eines bestehenden Kontextes das Datenobjekt verwendet werden, um die Instanz des Anzeigezeigers 38 in diesem Kontext effizient wieder herzustellen. Besonders zu beachten ist, dass die Wiederherstellung vollständig ohne irgendwelche benötigte Teilnahme oder auch Notiz durch irgendein Anwendungsprogramm 60 oder die Betriebssystemschicht 54 unterstützt wird. Das Datenobjekt wird in diesem Beispiel aus einem ursprünglichen Datenobjekt hergeleitet, das als ein Operand eines API-Aufrufs bereitgestellt wurde, der anfangs das Muster oder die Farbe des Anzeigezeigers 38 festgelegt hat. Wenn ein neuer Kontext, der z. B. eine neue Farbtiefe verwendet, erzeugt wird, wird ein neues Datenobjekt mittels einer Farbtiefeübersetzung aus dem Datenobjekt des vorherigen Kontextes abgeleitet. Bei einer Kontextumschaltung auf einen vorher bestehenden Kontext wird die vorher bestehende Instanz des Datenobjekts wiederverwendet, mit dem Ergebnis, dass keine Informationen bei der Wiederherstellung einer Instanz des Anzeigezeigers 38 verloren gehen.
In ähnlicher Weise hält eine Instanz des GDI-Objekts 120 vorzugsweise nicht nur eine Farbpalette in einem Kontext mit palettierter Farbe, sondern auch die Vorwärts- und Rückwärts-Palettenübersetzungstabellen als Teil der für den palettierten Kontext spezifischen Struktur PDevice. Im Betriebssystem Windows'95^TM unterstützt die Betriebssystemschicht 54 einen einzelnen Zeiger auf eine physikalische Vorrichtungsstruktur (PDevice), die verwendet wird, um bestimmte Informationen zu halten, die wenigstens bei ausgewählten Aufrufen von der Betriebssystemschicht 54 an die Anzeigetyp-Gerätetreiber weitergegeben werden. Das Ziel der Struktur PDevice ist, eine vergrößerungsfähige Datenstruktur bereitzustellen, die vom Gerätetreiber 50 verwendet werden kann, um Hardware-spezifische Konfigurationsdaten allgemein zu speichern. Die vorliegende Erfindung nutzt nicht nur die Struktur PDevice, um für einen palettierten Kontext spezifische Farbübersetzungstabellen zu speichern, sondern bildet im allgemeinen eine neue Struktur PDevice für jeden Kontext nach und vergrößert die Struktur konsistent mit der Farbtiefe des entsprechenden Kontextes. Die bevorzugte Struktur der Struktur PDevice ist in Tabelle XVII gezeigt.
Die Unterhaltung von Farbpalettenübersetzungstabellen effektiv als ein kontextspezifisches beständiges Datenobjekt erlaubt eine schnelle Wiederherstellung der Farbpalette und der Übersetzungstabellen bei einem Kontextumschalten zum palettierten Kontext. Die Unterhaltung der Farbpalettenübersetzungstabellen als Teil der Struktur PDevice unterstützt ferner das Fortführen einer Palette auf der Grundlage von Zeichenoperationen insbesondere während nicht palettierten Kontexten, und möglicherweise während anderer palettierter Kontexte, die eine unabhängige Struktur PDevice mit unabhängiger Farbpalette und Übersetzungstabellendefinitionen verwenden. In jedem Fall können weitergehende Zeichenoperationen, die von Anwendungen gesteuert werden, die logisch gegenüber einem palettierten Kontext ausgeführt werden, korrekt in die Farbtiefe oder die Farbpalette des aktuell aktiven Kontextes übersetzt werden, indem die Zeichenbefehle gegenüber den Farbpalettendaten und der Übersetzungstabelle des entsprechenden Kontextes übersetzt und aufgelöst werden. Das heißt, die Zeichenbefehle der Anwendungen 60, die logisch gegenüber einem derzeit nicht aktiven Kontext ausgeführt werden, werden effektiv bei Bedarf wiederhergestellt durch Referenz auf die Datenobjekte eines nicht aktuellen Kontextes, um die Zeichenbefehle mit der Farbtiefe des aktuellen Kontextes auszuführen. Die Datenobjekte eines nicht aktuellen Kontextes können lokalisiert werden durch Durchsuchen der Datenstrukturen, genauer der Shell-Objekte, die zum Definieren jedes Kontextes verwendet werden.
In der bevorzugten Ausführungsform der vorliegenden Erfindung repräsentie ren die Betriebssystemschnittstellenobjekte eine eher dünne Schicht. API-Aufrufe werden vorzugsweise auf einer hohen Ebene in im Wesentlichen lineare Aufrufsequenzen an die Shell-Bibliothek 72' und Hardware-Objekte 130–140, falls geeignet, virtualisiert, um Ausführungsstränge für jeden der spezifischen API-Aufrufe zu definieren, die von den Schnittstellenobjekten unterstützt werden. Im allgemeinen ist eine Maximierung der Verwendung gewöhnlicher Aufrufe der Routinen in der Shell-Bibliothek 72' erwünscht. Im Gegensatz hierzu ist die Beschränkung der Funktion der Betriebssystemschnittstellenobjekte auf im Wesentlichen die Datenüberprüfung, die Basisdatentransformationen und die Spezifikation des linearen Ausführungsstrangs für jeden unterstützten API-Aufruf erwünscht.
In der Implementierung mit Windows'95^TM gibt die Betriebssystemschicht 54 ziemlich atomare API-Aufrufe an den Gerätetreiber 50 aus. Folglich machen nahezu alle Betriebssystemschnittstellenobjekte nur wenige Aufrufe an die Shell-Bibliothek 72' und Hardware-Schnittstellenobjekte, um den zur Durchführung eines API-Aufrufs benötigten Ausführungsstrang funktional zu implementieren. Wofür die Leistungsfähigkeit sinnvoll, oder wo die Nutzung im Wesentlichen auf einen bestimmten API-Aufruf beschränkt ist, können einige Ausführungsfunktionen vom Betriebssystemschnittstellenobjekt durchgeführt werden. Genauer kann ein anfängliches Begrenzen und Übersetzen von Koordinaten von einem Betriebssystemschnittstellenobjekt in Zusammenarbeit mit der Operandenüberprüfung in Reaktion auf einen API-Aufruf zum Zeichnen eines Objekts durchgeführt werden. Wesentlichere Routinen oder Routinen, die wahrscheinlicher von mehreren API-Aufrufen benötigt werden, wie z. B. die Routinen, die zum Einrichten des Speichers eines neuen beständigen Datenobjekts verwendet werden, um eine Farbtiefeübersetzung zum Herleiten des Inhalts eines neuen Datenobjekts aus einem weiteren durchzuführen, und um anschließend eine Zeichenoperation auf dem Bildschirm 32 zu verwirklichen, werden vorzugsweise als angemessen in der Shell-Bibliothek 72' und den Hardware-Schnittstellenobjekten implementiert.
Somit wird z. B. ein erster API-Aufruf vom Betriebssystem 54 an ein entsprechendes Betriebssystemschnittstellenobjekt gemacht, um die Erzeugung eines gewünschten neuen Datenobjekts anzufordern, und um schließlich einen Zeiger auf das Objekt zurückzuerhalten. Der virtualisierte lineare Strang von Aufrufen beginnt mit einem Aufruf an die Shell-Bibliothek 72', die ihrerseits die Zuweisung anfordert, den Speicher belegt und einen Zeiger auf das resultierende Objekt zurückgibt. Die Shell-Bibliothek 72' ruft bei der Durchführung dieser Anforderungen sequenziell das Betriebssystemschnittstellenobjekt 128 bei Bedarf auf, um benötigte Betriebssystem-API-Aufrufe an die Betriebssystemschicht 54 weiterzuleiten. Diese Linearisierung der individuellen Funktionen, die von der Shell-Bibliothek 72' unterstützt werden, wird möglich gemacht durch die präventive Operandenüberprüfung und Virtualisierung, die von den Betriebssystemschnittstellenobjekte durchgeführt werden. Die Operandendaten werden eingerichtet, bevor die Shell-Bibliothek 72' oder irgendwelche Hardware-Schnittstellenobjekte aufgerufen werden, in einer Form und einem Format, die jeden Verarbeitungsschritt geeignet sind, der aus einem bestimmten API-Aufruf folgt. Folglich werden die meisten, wenn nicht weitgehend alle, bedingten Verzweigungen zum Handhaben von Ausnahmebedingungen oder zum Bestimmen, ob Daten verfügbar sind oder in einem für die Verarbeitung annehmbaren Format vorliegen, unterhalb der Ebene der Betriebssystemschnittstellenobjekte vermieden; ohne weitergehende bedingte Verzweigung zum Prüfen auf Existenz, Form und Format von Operandendaten wird die Implementierung von virtualisierten API-Aufrufen weitgehend linearisiert. Ferner eliminiert die Initialisierung der Hardware-Schnittstellenobjekte mit Funktionszeigern auf Funktionen, die für die aktuelle Farbtiefe und Auflösung geeignet sind, eine weitergehende bedingte Verzweigung zum Prüfen und Anpassen des aktuellen Betriebszustands der Anzeige 32.
Ein nächster API-Aufruf an ein Betriebssystemobjekt kann anschließend die Umwandlung eines identifizierten Datenobjekts in das neu erzeugte Datenobjekt anweisen. Anschließende API-Aufrufe durch ein Betriebssystemschnittstellenobjekt können die Leistungsfähigkeit spezifischer Zeichenoperationen unter Verwendung des vorher erzeugten und konvertierten und vom API-Aufruf identifizierten Datenobjekts spezifizieren. Jeder API-Zeichnungsaufruf wird vom empfangenden Betriebssystemschnittstellenobjekt ausgeführt, indem erneut eine im Wesentlichen lineare Folge von einem oder mehreren Aufrufen an die Shell-Bibliothek 72' und die Hardware-Schnittstellenobjekte, falls geeignet, ausgegeben wird, um die bestimmte Zeichenoperation zu verwirklichen.
Somit wird jedes der Betriebssystemschnittstellenobjekte definiert, um die Virtualisierung der Aufrufe zu maximieren, in dem die Operandenüberprüfung und die Formatumwandlung durchgeführt werden, während ein Minimum an duplizierten Code enthalten ist. Die Verwendung der Shell-Bibliothek 72 wird somit maximiert, jedoch ohne einen Nachteil in der Ausführungsleistung aufgrund irgendeiner wiederholten Überprüfung, Umwandlung oder Reformatierung der ursprünglichen Operandendaten. Ferner sind die Betriebssystemschnittstellenobjekte mit einem direkten Funktionsaufrufzugang auf die Hardware-Schnittstellenobjekte über die unmittelbar verfügbaren Funktionszeiger und ohne die Notwendigkeit, kontinuierlich die Betriebseigenschaften der Steuervorrichtung 19 zu bewerten und anzupassen, ausgestattet.
Die Shell-Bibliothek 72' kann ebenfalls für die effektive Erweiterung und Implementierung gemeinsamer virtualisierter Aufrufe sorgen, die von den Betriebssystemschnittstellenobjekten empfangen werden. Solche Aufrufe an die Shell-Bibliothek 72' werden vorzugsweise in typische kurze, im Wesentlichen lineare Aufrufsequenzen expandiert, die den Hardware-Schnittstellenobjekten zugeführt werden, um wiederum hardwarespezifische Funktionen aufzurufen. Die genaue Menge oder Teilmenge der Hardware-Schnittstellenobjekte, die von der Shell-Bibliothek 72' aufgerufen werden, ist stark abhängig von dem genauen Aufruf, der von einem Betriebssystemschnittstellenobjektempfangen wird. Jeder der von der Shell-Bibliothek 72' gemachten Aufrufe hält jedoch eine effektive virtuelle Beziehung zu der Menge der Hardware-Schnittstellenobjekte als Folge der virtualisierten Definition der Hardware-Schnittstellenobjekt-Datenstrukturen. Das heißt, die Strukturdefinition der Hardware-Schnittstellenobjekte ist im Wesentlichen für jeden Objekttyp fixiert, unabhängig von der Implementierung des spezifischen Hardware-Schnittstellenmoduls, das vom Objekt gekapselt wird. Folglich werden Aufrufe von den Betriebssystemschnittstellenobjekten sowie der Shell-Bibliothek 72' an die Hardware-Schnittstellenobjekte von der wirklichen Implementierung der Hardware-Schnittstellenmodule abstrahiert. Durch die Verwendung der kurzen, im Wesentlichen linearen Aufrufsequenzen, die zum Implementieren der API-Aufrufe verwendet werden, wird die Ausführungsgeschwindigkeit der virtualisierten API-Aufrufe maximiert.
B. Untere-Ebene-Konfigurationsbeziehungen:
Die Hardware-Schnittstellenobjekte sind den Betriebssystemschnittstellenobjekten insofern ähnlich, als sie vorzugsweise als eine dünne Schicht verwirklicht sind, die die hardware-spezifischen Operationen definiert, die für den Austausch mit den Schnittstellenregistern 30 der Steuervorrichtung 19 erforderlich sind. Die Hardware-Schnittstellenobjekte sind vorzugsweise funktional beschränkt auf (1) Unterstützen eines wohldefinierten Satzes von Operationen, die für einen bestimmten Typ von Hardware-Unterelement spezifisch sind, (2) Bereitstellen wenigstens der logischen Programmierung der relevanten Hardware-Schnittstellenregister, um die Funktion jeder unterstützten Operation zu implementieren, (3) potenzielles Managen eines privaten Datenraums für Datenobjekte, die über Kontextänderungen hinweg beständig sein sollen, im Betrieb des Gerätetreibers 50, und schließlich (4) Zurückgeben bestimmter Daten, die direkt oder indirekt aus den Schnittstellenregistern 30 gelesen worden sind.
Die Operationen, die von einem bestimmten Typ von Hardware-Schnittstellenobjekt unterstützt werden, sind als Teil der Objektstruktur definiert. Im Allgemeinen resultiert ein Aufruf an ein Hardware-Schnittstellenobjekt in der Erzeugung einer Referenz auf ein oder mehrere Register der Schnittstellenregister 30 und eine Kette von Datenwerten, die in die referenzierten Register zu programmieren ist. Die wirkliche Programmierung der Register wird vorzugsweise in Reaktion auf einen Aufruf an die Leiterplattenbibliothek 74' durchgeführt. Wie bei der Shell-Bibliothek 72' konzentriert die Leiterplattenbibliothek 74' die verallgemeinerten oder gemeinsamen Routinen, die von den Hardware-Schnittstellenobjekten verwendet werden. Somit wird die Verdopplung von Code allgemein reduziert und die genauen Registerschnittstellenroutinen, die die Routinen zum Lokalisieren, Definieren und Managen des Anzeigepuffers 20 innerhalb des Adressraums des Speichers 16 enthalten, sind größtenteils in einem wohldefinierten Ort im Wesentlichen isoliert von allen anderen Aspekten des Gerätetreibers 50 angeordnet. Die eine signifikante Ausnahme hierzu betrifft vorzugsweise das Graphik-Hardware-Schnittstellenobjekt 138. Zu Leistungszwecken arbeitet dieses Objekt vorzugsweise direkt mit der Registerschnittstelle 30 und dem Anzeigepuffer 20. Dementsprechend stellt die Leiterplattenbibliothek 74' vorzugsweise eine Routine bereit, die den aktuellen Ort und die Definition des Anzeigepuffers 20 zurückgibt. Es ist abzusehen, dass die Video- und 3D-Hardware-Schnittstellenobjekte 136, 140 ebenfalls durch einen direkten Zugriff auf Hardware-Schnittstellen der entsprechenden Unterelemente der Steuervorrichtung 19 profitieren.
Folglich wird von der vorliegenden Erfindung eine effiziente, geschichtete und virtualisierte Beziehung zwischen den Betriebssystemschnittstellenobjekten bis zu den Hardware-Schnittstellenobjekten eingerichtet. Diese virtualisierte Beziehung wird leicht demonstriert durch Verfolgen des Ausführungsablaufs von zwei unterschiedlichen API-Aufrufen an den Gerätetreiber 50.
V. Betriebszustand-Kontext- und Modusumschaltung:
In den bevorzugten Ausführungsformen der vorliegenden Erfindung ist die Videoanzeigesteuervorrichtung 19 mit vielen unterschiedlichen horizontalen und vertikalen, oder räumlichen Auflösungen und vielen unterschiedlichen Farbtiefen betreibbar. Herkömmliche Computersysteme 10 führen häufig eine Vielfalt von Anwendungen 60 aus, die mit unterschiedlichen räumlichen Auflösungen und Farbtiefen optimal arbeiten. Tatsächlich können die räumlichen Anforderungen und Farbtiefeanforderungen sowie die Operationseinschränkungen von Anwendungen 60, die versuchen, gemeinsam auf dem Computersystem 10 zu laufen, die gemeinsame Ausführung auf räumliche Auflösungen und Farbtiefen beschränken, die, falls nicht gegenseitig ausschließend, häufig für die fortgesetzte Ausführung der Anwendungen 60 nicht optimal sind.
Die Architektur des Gerätetreibers 50 entsprechend der vorliegenden Erfindung sorgt für die Leistungsfähigkeit von Modusumschaltungen allein und in Kombination mit Kontextumschaltungen im Betriebszustand des Gerätetreibers 50. Sowohl Modusumschaltungen als auch Kontextumschaltungen werden durchgeführt und insbesondere im Wesentlichen unabhängig vom Kontextzustand der Anwendungen 60 und der Betriebssystemschicht 54 gemanagt. Modusumschaltungen allein können durchgeführt werden, wenn die für einen bestimmten Aspekt eines bestehenden Modus spezifischen Daten über die Modusumschaltung hinweg beständig sein müssen. Eine Kontextumschaltung wird vom Gerätetreiber 50 in Kombination mit einer Modusumschaltung durchgeführt, um für eine beständige Speicherung von Modusdaten in einem unabhängigen Kontext zu sorgen. Somit können Gerätetreiber-Kontextumschaltungen verwendet werden, um zustandsbetonte Steuervorrichtungs-Modusänderungen zu unterstützen durch Speichern des Zustands und von modusspezifischen Daten in beständigen Datenobjekten, die spezifischen Kontexten zugeordnet sind. Das Management von Kontexten und die Leistungsfähigkeit von Kontextumschaltungen durch den Gerätetreiber 50 erlaubt ein Kontextumschalten ohne Änderung von Anwendungsprogrammen 60 und ohne neue spezifische Modifikationen am Betriebssystemkern 56.
A. Konstantkontext-Modusumschaltung:
Um Modusumschaltungen zu unterstützen, ist der Betriebssystemkern 56 modifiziert durch Installation eines Korrekturprogramms 62 am Kern 56, das einen API-Aufruf ausgibt, der den Gerätetreiber 50 anweist, die Videoanzeigesteuervorrichtung 19 auf eine im Voraus ausgewählte räumliche Auflösung für die Anwendung 60 umzuschalten, deren Fenster den aktuellen Zeigerschwerpunkt aufweist. Fortschrittlichere Betriebssysteme 54 können inhärent für die Erzeugung eines Ereignisses sorgen, das verwendet werden kann, ohne die Notwendigkeit ein Betriebssystemkorrekturprogramm zu installieren. Der korrigierte In-Modus-Satz-API-Aufruf wird an das Shell-Objekt gehängt und bietet die gewünschte neue räumliche Auflösung der physikalischen Anzeige 32. Der API-Aufruf spezifiziert ferner eine Farbtiefe in Kombination mit der gewünschten räumlichen Auflösung. Wenn sowohl die gewünschte Farbtiefe als auch die räumliche Auflösung die Gleichen sind wie die aktuelle Farbtiefe und die räumliche Auflösung, springt der API-Aufruf einfach zurück. Wenn nur die räumliche Auflösung verschieden ist, dann muss nur eine Modusumschaltung durchgeführt werden. Die Steuervorrichtungsmoduseinstelländerung, die erforderlich ist, um die Modusumschaltung durchzuführen, wird in dem dann aktuellen Kontext des Gerätetreibers 50 durchgeführt.
Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung wird eine Moduseinstelländerung innerhalb eines einzelnen Kontextes größtenteils unter der Steuerung des Shell-Objekts 126 und der Shell-Bibliothek 72' durchgeführt. Der API-Aufruf an das Shell-Objekt 126 spezifiziert, dass eine Moduseinstellung durchzuführen ist. Das Shell-Objekt 126 ruft über das O/S-Objekt 128 die Betriebssystemschicht 54 auf, um die gewünschte Farbtiefe und die räumliche Auflösung zu erhalten. Das Shell-Objekt 126 überprüft zuerst die zurückgegebenen Operanden, die die gewünschte räumliche Auflösung spezifizieren. Die Einstellmodusroutine der Shell-Bibliothek 72' wird anschließend vom Shell-Objekt 126 aufgehoben, um sequentiell jedes der Betriebssystem- und Hardware-Schnittstellenobjekte aufzurufen, zuerst mit einem Operanden "Modus wechselt bald", anschließend mit einem Operanden "Moduswechsel", und schließlich mit einem Operanden "Modus hat gewechselt".
Der erste Aufruf mit dem Operanden "Modus wechselt bald" leitet die Sequenz von Ereignissen innerhalb des Gerätetreibers 50 ein, die notwendig ist, um den Zustand des Treibers 50 bezüglich der Steuervorrichtung 19 stillzulegen. Genauer arbeitet die Moduseinstellroutine der Shell-Bibliothek 72' so, dass sie jedes der Betriebssystem- und Hardware-Schnittstellenobjekte innerhalb des aktuellen Kontextes identifiziert, die an der Moduseinstellung teilnehmen müssen. Diese Schnittstellenobjekte werden als diejenigen mit einem gültigen oder Nicht-Null-Zeiger auf eine objektspezifische Struktur RegClassHandler identifiziert. Moduseinstellaufrufe werden anschließend in Folge zu jedem der teilnehmenden Objekte platziert. In Reaktion hierauf wird jedes Objekt in der Sequenz ausgeführt, um aktuelle Zustandsdaten zu Systemdatenstrukturen zu sichern, wie z. B. die Strukturen PDevice und GDI_Infotable, oder zu dem privaten Datenraum des Objekts selbst, falls geeignet, um einen wohldefinierten Ausführungszustand innerhalb des aktuellen Kontextes einzurichten. Wenn das letzte teilnehmende Objekt zurückgesprungen ist, wurde die Operation des Gerätetreibers 50 im Wesentlichen stillgelegt. Die Shell-Bibliothek 72' kehrt anschließend zum Shell-Objekt 126 zurück.
Der zweite Moduseinstellaufruf, der "Moduswechsel" spezifiziert, wird anschließend vom Shell-Objekt 126 an die Shell-Bibliothek 72' ausgegeben. Die Leiterplattenbibliothek 74' konstruiert bei Aufruf durch die Shell-Bibliothek 72' mit dem Operanden "Moduswechsel" einen "SectionName", der der gewünschten Kombination der räumlichen Auflösung und der Farbtiefe entspricht. O/S-API-Aufrufe werden anschließend über das Betriebssystemschnittstellenobjekt 128 durchgeführt, um eine Konfigurationsdatei modes.dmm abzutasten, die vorzugsweise eine Struktursyntax im Allgemeinen gleich derjenigen der Datei system.imi aufweist, um eine durch den gegebenen "SectionName" identifizierte Sektion zu lokalisieren. In einer Implementierung mit Windows'95^TM ist der SectionHeader, der eine räumliche Auflösung von 1024×768 mit einer Farbtiefe von 8 Bit pro Pixel definiert, spezifiziert als "[1024,768,8]".
Der Text, der dem gegebenen Sektionskopf folgt, wird von der Shell-Bibliothek 72' eingelesen und analysiert. Dieser Text repräsentiert eine strukturierte Spezifikation der genauen Moduseinstellbefehle, die gegenüber jedem teilnehmenden Unterelement der Steuervorrichtung 19 ausgeführt werden müssen, um einen neuen Steuervorrichtungsbetriebsmodus einzustellen. Die Moduseinstellbefehle sind in der bevorzugten Ausführungsform zeilenorientierte Anweisungen, die in durch Kommata abgegrenzten Ausdrücken strukturiert sind, wie REGISTERCLASS, BEFEHL, und Argumenten. In der bevorzugten Ausführungsform wird das Feld "Klassenname" der Struktur RegClassHandler mit dem Ausdruck REGISTERCLASS eines Befehls korreliert, um schließlich zu bestimmen, welches Unterelement der Steuervorrichtung 19 in Reaktion auf einen bestimmten Befehl zu programmieren ist.
Es gibt derzeit vier direkt ausgeführte Befehle: Ausführen (RUN), Lesen/Maskieren/Schreiben (RMW), Verzögern (DLY) und Int10 (I10). Ein fünfter Befehl, der in der bevorzugten Ausführungsform der vorliegenden Erfindung unterstützt wird, ist ein Schließe-Richtlinie-Ein-Pseudobefehl, der die Analyseroutine der Shell-Bibliothek 72' anweist, Befehle logisch einzuschließen und somit zu analysieren, die unter einem in der Einschließe-Richtlinie spezifizierten Sektionsnamen in der Datei modes.dmm zu finden sind. Der Ausführbefehl weist das folgende Anweisungsformat auf:
REGISTERCLASS,RUN,REGISTERNAME,wert1,wert2,wert3 ...
Der Ausdruck REGISTERNAME stellt einen logischen Namen zur Verfügung, der unter Verwendung der Assoziation REGISTERCLASS durch eine Struktur RegClassHandler bis zu einer Struktur RegClassMap verfolgt werden kann. Der logische Name REGISTERNAME ist in RegClassMap gegenüber einer logischen Anschlussadresse definiert, die letztendlich zu einem spezifischen Register innerhalb der Registerschnittstelle 30 aufgelöst werden kann. Beim Ausführen des Befehls schreibt die Analyseroutine der Shell-Bibliothek 72' die Anschlussadresse von REGISTERNAME mit dem ersten Wert "wert1". Die nächste sequentielle Anschlussadresse, die in RegClassMap identifiziert ist, wird anschließend mit dem zweiten Wert wert2 beschrieben. Somit werden die logisch sequentiellen Anschlussadressen mit aufeinanderfolgenden Werten beschrieben, bis alle mit dem besonderen Ausführungsbefehl bereitgestellten Werte geschrieben worden sind.
Der Befehl Lese/Maskiere/Schreibe hat folgendes Anweisungsformat:
REGISTERCLASS,RMW,REGISTERNAME,ANDMask,XORMask
Beim Ausführen dieses Befehls liest die Analyseroutine der Shell-Bibliothek 72' zuerst den Wert von der Anschlussadresse entsprechend REGISTERNAME ein, führt eine binäre UND-Operation des Wertes mit ANDMask durch, und führt eine binäre XOR-Operation des Ergebnisses mit XORMask durch. Das Ergebnis wird anschließend in die Anschlussadresse REGISTERNAME zurückgeschrieben.
Der Verzögerungsbefehl hat folgendes Anweisungsformat:
SHELL,DLY,DelayValue
Die Registerklasse dieses Befehls ist immer "SHELL", da kein Hardware-Schnittstellenobjekt direkt von der Ausführung des Befehls betroffen ist. Beim Ausführen dieses Befehls implementiert die Analyseroutine der Shell-Bibliothek 72' entweder ein software-basiertes oder hardware-basiertes Warten für eine Zeitspanne, die durch DelayValue spezifiziert ist, vorzugsweise als ein Vielfaches von 50 Millisekunden. Der Verzögerungsbefehl ist nützlich, wenn Hardware-Programmierungseinrichtzeiten respektiert werden müssen, jedoch ein Register-Lesbar-Bereitschaftssignal von der Hardware nicht zur Verfügung gestellt wird. Die Analyseroutine fährt einfach nach Verstreichen der Verzögerungszeitperiode fort.
Der Int10-Befehl hat folgendes Anweisungsformat:
SHELL,110,EAX,EPX,ECX,EDX
Die Registerklasse dieses Befehls ist wiederum immer "SHELL", da kein Hardware-Schnittstellenobjekt direkt von der Ausführung des Befehls betroffen ist. Die Analyseroutine der Shell-Bibliothek 72' implementiert diesen Befehl durch Aufrufen des O/S-Objekts 128, um eine Software-Unterbrechung 10 auszuführen, und stellt die Argumente des Befehls in entsprechenden CPU-Registern zum Zeitpunkt der Unterbrechung bereit.
Schließlich hat der Befehl Einschließen das folgende spezifische Befehlsformat:
SHL,INC,SectionName
Der Einschließen-Befehl weist die Analyseroutine der Shell-Bibliothek 72' an, das Analysieren des aktuellen Abschnitts der Datei modes.dmm effektiv zurückzustellen und den Abschnitt zu analysieren, der mit "SectionName" identifiziert ist. Das Analysieren des zurückgestellten Abschnitts wird wieder aufgenommen, nachdem der eingeschlossene Abschnitt von der Shell-Bibliothek 72' analysiert worden ist.
Bei dem Ausführen der von der Datei modes.dmm bereitgestellten Befehle nutzt die Shell-Bibliothek 72' den Ausdruck REGISTERCLASS, um einen bestimmten Befehl einem entsprechenden Hardware-Schnittstellenobjekt zuzuordnen. Da die Befehle zur letztendlichen Programmierung des Betriebsmodus der Steuervorrichtung 19 geleitet werden, wird auf die Betriebssystemschnittstellenobjekte in der bevorzugten Ausführungsform der vorliegenden Erfindung durch keinen Ausdruck REGISTERCLASS der Befehle Bezug genommen.
Wenn ein Befehl ausgeführt wird, werden die Einträge Read_reg und Write_reg in der entsprechenden Struktur RegClassHandler durch die Analyseroutine aufgerufen, um die Lese/Schreib-Operationen durchzuführen, die in der Ausführung des Befehls erforderlich sind. Da die Struktur RegClassHandler objektspezifisch ist, sind auch die Funktionen Read_reg und Write_reg spezifisch für das bestimmte Objekt, das durch den Ausdruck REGISTERNAME identifiziert wird.
In der bevorzugten Ausführungsform der vorliegenden Erfindung sorgt die Funktion Write_reg jedes Objekts für die effektive Übersetzung eines Register/Argument-Paares, wie in der Ausführung eines Befehls erhalten, zu einer hardware-spezifischen Darstellung der Register, die wirklich zu schreiben sind. Die Register/Argument-Paare werden effektiv durch die Ausführung der Befehle zu einem flachen, sequentiellen logischen Registermodell geschrieben. Die Funktionen Write_reg konvertieren die Paare zu einem unterelement-hardware-spezifischen Modell. Zum Beispiel wird unter den spezifischen Umständen des DAC-Schnittstellenobjekts 130 in ein multiplexiertes Registermodell konvertiert, das ein physikalisches Basisregister, das mit einem logischen Registerindexwert zu programmieren ist, und ein nächstes sequentielles Basisregister erfordert, das mit dem im indexierten logischen Register zu speichernden Wert programmiert wird. Während somit sequentielle Register in den Aufrufen der Funktion Write_reg des DAC-Schnittstellenobjekts 130 herangezogen werden, wird eine einzige Paarung von physikalischen Basisregistern durch die Funktion geschrieben.
Die Funktion Read_reg jedes Objekts führt eine ähnliche Umwandlung durch. Das herangezogene logische Register wird in eine Referenz auf ein entsprechendes physikalisches Basisregister umgewandelt. Im Fall des DAC-Schnittstellenobjekts 130 enthält die Umwandlung die Programmierung des physikalischen Basisregisters mit dem Index, der das logische Register definiert, so dass der korrekte Wert ausgelesen werden kann.
Andere Schnittstellenobjekte können für die Umwandlung des flachen sequentiellen Registermodells der Befehle in ein serielles oder bitsequentielles Modell sorgen, wie es für das Programmieren eines weiteren Unterelements der Steuervorrichtung 19 geeignet ist. Somit werden die sequentiellen Register/Argument-Paarungen in einen logischen Registerindexwert konvertiert, gefolgt von einer bit-seriellen Sequenz von Programmwerten, die zum Programmieren eines spezifischen Unterelements der Steuervorrichtung 19 geeignet sind.
Als ein Beispiel kann eine Videosteuervorrichtung Diamond Stealth 64 Video DRAM, die einen Graphikbeschleuniger-Chip S3-Vision868 verwendet, selektiv programmiert werden, um einen Graphikmodus freizugeben:
Einen Graphikmodus zu sperren:
und auf einen 1024×768×8-Modus umzuschalten:
In der bevorzugten Ausführungsform nutzen die Funktionen Write_reg und Read_reg der Hardware-Schnittstellenobjekte eine Anzahl von Funktionen in der Leiterplattenbibliothek 74', um Hardware-Lese- und Schreib-Operationen gegenüber der Registerschnittstelle 30 wirklich durchzuführen. Diese zusätzliche Ebene der Indirektheit erlaubt, dass verschiedene Hardware-Unterelemente der Steuervorrichtung 19 an unterschiedlichen physikalischen Adressen existieren, in Abhängigkeit von dem bestimmten Modell der Steuervorrichtung 19. Während somit ein bestimmtes Hardware-Schnittstellenobjekt die besondere Programmierung eines Unterelements der Steuervorrichtung 19 vollständig repräsentiert, ordnet die Leiterplattenbibliothek 74' implizit das Unterelement innerhalb des physikalischen Adressraums des Computersystems 10 an. Folglich ist das physikalische Basisregister, das vom DAC-Schnittstellenobjekt durch einen Funktionsaufruf Write_reg identifiziert wird, logisch bezogen auf das DAC-Unterelement selbst. Die Leiterplattenbibliothek 74' liefert einen physikalischen Adressierungsversatz für die physikalischen DAC-Basisregister, um die Register innerhalb des physikalischen Systemadressraums der Registerschnittstelle 30 anzuordnen.
Um physikalische Adressversätze einzurichten, stellt die Leiterplattenbibliothek 74' eine Anzahl von Lese- und Schreibroutinen zur Verfügung, die ihrerseits für die Haupttypen der Unterelemente der Steuervorrichtung spezifisch sind. Zum Beispiel nimmt das Taktschnittstellenobjekt, obwohl es ein spezifisches und wohldefiniertes Unterelement der Steuervorrichtung 19 steuert, typischerweise auf einen programmierbaren Taktgenerator Bezug, der innerhalb der Register angeordnet oder durch diese zugänglich ist, die dem DAC-Unterelement zugeordnet sind. Somit werden der physikalische Adressversatz, der von der Leiterplattenbibliothek 74' sowohl für die DAC- als auch Taktschnittstellenobjekte bereitgestellt wird, gleich sein.
Die Leiterplattenbibliothek 74' unterstützt vorzugsweise Funktionen BoardRead_reg und BoardWrite_reg für Hardware-Schnittstellenobjekte, die einen flachen, sequentiellen, physikalischen Registersatz adressieren. Die Funktionen BoardRead_DAC, BoardWrite_DAC und BoardWrite_DAC_Array werden von der Leiterplattenbibliothek 74' bereitgestellt, um das Lesen und Schreiben der multiplexierten Register zu unterstützen und die innerhalb des physikalischen Registeradressraums des DAC-Unterelements angeordnete Farbpalettenanordnung zu schreiben, wie von der Steuervorrichtung 19 eingerichtet.
Schließlich werden die Funktionen BoardWrite_SerialDevice_start und BoardWrite_SerialDevice_end bereitgestellt, um serielle Schreiboperationen zu seriell programmierten Unterelementen der Steuervorrichtung 19 zu unterstützen.
Sobald die abgetasteten Anweisungen aus der Datei modes.dmm ausgeführt worden sind, hat der Betriebsmodus der Steuervorrichtung 19 gewechselt, so dass er der gewünschten räumlichen Auflösung und der Farbtiefe entspricht. Die Shell-Bibliothek 72' ruft anschließend jede der Moduseinstellfunktionen des teilnehmenden Satzes von Schnittstellenobjekten mit "wechsle Modus" als ein Operand für den Aufruf auf. Die Schnittstellenobjekte nutzen diesen Aufruf, um irgendwelche unterelementspezifischen Routinen auszuführen, die notwendig sind, um den neuen Betriebsmodus der Steuervorrichtung 19 einzurichten. Irgendeine benötigte Programmierung der Register in der Registerschnittstelle 30 oder eine direkte Manipulation des Anzeigepuffers 20 kann zu diesem Zeitpunkt durchgeführt werden. Wenn das letzte der Schnittstellenobjekte von diesem Moduseinstellaufruf zurückspringt, springt die Shell-Bibliothek 72' zum Shell-Objekt 126 zurück.
Der dritte und letzte Aufruf mit einem Operanden "Modus hat gewechselt" wird anschließend von der Shell-Bibliothek 72' an jedes der an der Moduseinstellung teilnehmenden Schnittstellenobjekte durchgeführt. Die teilnehmenden Hardware-Schnittstellenobjekte werden vorzugsweise vor den Betriebssystemschnittstellenobjekten aufgerufen. Wenn jedes Schnittstellenobjekt aufgerufen wird, führt das Objekt irgendeine hardwarespezifische Operation durch, die zum Unterstützen der Operation des entsprechenden Unterelements der Steuervorrichtung 19 im neuen Betriebsmodus der Steuervorrichtung 19 notwendig ist. Im Allgemeinen springen die Hardware-Schnittstellenobjekte in Reaktion auf diesen Aufruf einfach zurück. Eine Ausnahme besteht dann, wenn ein bestimmtes Objekt Implementierungsabhängigkeiten auf der Grundlage der räumlichen Auflösung, der Farbtiefe oder anderer Geräteeigenschaften aufweist. Wenn ein Modul, das von einem Hardware-Schnittstellenobjekt wie z. B. dem Graphikobjekt 138 gekapselt ist, mehrere Routinen präsentiert, die die gleiche logische Funktion unterstützen, unterschieden durch z. B. die Farbtiefe, werden Funktionszeiger in die Aufrufeinsprungpunkte der Objektstruktur aktualisiert, so dass sie auf die für die neue Farbtiefe geeigneten Routinen zeigen.
Die Betriebssystemschnittstellenobjekte nutzen vorzugsweise diesen Aufruf "wechsle Modus", um Datenobjekte wiederherzustellen, die im aktuellen Kontext existieren, so dass sie der Anzeigeauflösung, der Farbtiefe oder anderen Geräteeigenschaften des neuen Betriebsmodus der Steuervorrichtung 19 entsprechen. Genauer können Betriebssystemschnittstellenobjekte, wie z. B. das GDI-Objekt, Bitfelddatenobjekte verwalten, die auf der Anzeige 32 sichtbare Merkmale repräsentieren. Somit kann ein bestimmtes Betriebssystemobjekt vorzugsweise zuerst irgendwelche geänderten Hardware-Schnittstellenobjektfunktionszeiger, die vom Betriebssystemschnittstellenobjekt häufig verwendet werden, in den lokalen Coderaum des Betriebssystemschnittstellenobjekts bei der Unterstützung der passenden Aufrufausführung kopieren. Eine lineare Interpolation der Bitfelder wird anschließend vorzugsweise durchgeführt, um das aktuelle Bitfeldauflösungsdatenobjekt anzupassen, so dass es zur neuen räumlichen Auflösung der Anzeige 32 passt.
Die Betriebssystemschnittstellenobjekte antworten schließlich auf den Moduseinstellungsaufruf "Modus hat gewechselt" durch Anweisen entsprechender Aktualisierungsoperationen bei Bedarf, um die Anzeige 32 effektiv zu aktualisieren. Solche Aktualisierungen werden spezifisch für irgendein Betriebssystemschnittstellenobjekt durchgeführt, das ein Datenobjekt wiederhergestellt hat, das auf der Anzeige 32 im neuen Betriebsmodus der Steuervorrichtung 19 sichtbar ist. Sobald die Bildschirmaktualisierung abgeschlossen ist, springt die Shell-Bibliotheks-Moduseinstellroutine zum Shell-Objekt zurück, das seinerseits vom Moduseinstell-API-Aufruf zurückspringt. Der Prozess der Änderung des Modus innerhalb eines aktuellen Kontextes ist somit abgeschlossen.
A. Kombinierte Kontext- und Modusumschaltung:
Eine Kontextumschaltung wird in Kombination mit einer Modusumschaltung durchgeführt, um in einer bevorzugten Ausführungsform die Moduseinstellung der Steuervorrichtung 19 auf eine neue Farbtiefe zu unterstützen. API-Aufrufe auf Geheiß von Anwendungen 60, die in Erwartung einer bestimmten Farbtiefe ausgeführt werden, die sich von derjenigen des aktuellen Betriebs modus der Steuervorrichtung 19 unterscheidet, müssen an die aktuelle Farbtiefe angepasst werden. Insbesondere wenn solche API-Aufrufe an den Gerätetreiber 50 im Vertrauen auf die Existenz einer beständigen Palette oder eines Farbfeldes gemacht werden, ist die Unterstützung von Kontexten wünschenswert, wenn nicht notwendig. Eine Alternative kann durch das Betriebssystem unterstützt werden. Ein aufrufbarer Einsprungpunkt in den Betriebssystemkern 56 kann für eine Farbtiefeübersetzung aller residenten Bitfelder auf oder oberhalb der O/S-API-Aufrufschnittstelle in eine Soll-Farbtiefe sorgen. Es können jedoch Probleme bestehen, wie die Effizienz und die Umkehrbarkeit solcher Übersetzungen und die potentielle Inkompatibilität von Anwendungen und Gerätetreibern, die mit der Betriebssystemschicht 54 auf der Grundlage beständiger Annahmen über die konstante Form und das Format von Bitfeldern, die in Wirklichkeit veränderlich sind, wechselwirken. Folglich wird eine Kontextumschaltung, die innerhalb des Gerätetreibers selbst isoliert ist, wahrscheinlich robuster sein und zwischen unterschiedlichen Betriebssystemimplementierungen portierbar sein.
Paletten und andere beständige Daten werden durch den jeweiligen Kontext gepflegt und stehen daher für die Referenz selbst dann zur Verfügung, wenn solche Kontexte derzeit nicht aktiv sind. Ein Kontext wird durch Vorgabe während der Initialisierung des Gerätetreibers 50 erzeugt. Zusätzliche Kontexte werden bei Bedarf in Reaktion auf API-Aufrufe erzeugt, die an den Gerätetreiber 50 gerichtet sind, um Modusänderungen zu neuen Farbtiefen durchzuführen.
Wie in 5a gezeigt ist, managt die Shell-Bibliothek 72' einen Speichervorrat 148, der wenigstens anfangs ein einzelnes Shell-Objekt 150 und möglicherweise die zusätzlichen Shell-Objekte 152, 154, 156 enthält. Jedes dieser Shell-Objekte 150, 152, 154, 156 repräsentiert einen unabhängigen Kontext innerhalb des Gerätetreibers 50. Ein oder mehrere der Shell-Objekte 150, 152, 154, 156 können zu irgendeinem Zeitpunkt innerhalb des Vorrats 148 in geeigneter Weise existieren, um eine Farbtiefe von einer oder mehreren dann gleichzeitig ausgeführten Anwendungen 60 zu repräsentieren. Kontexte, einschließlich des Kontextes, der durch das Shell-Objekt 150 repräsentiert wird, können später geschlossen werden, falls nicht, dann nimmt die ausgeführte Anwendung 160 auf die vom Kontext unterstützte Farbtiefe Bezug. Die Shell-Bibliothek 72' pflegt zusätzlich zum Managen des Vorrats der Shell-Objekte 148 auch einen aktuellen Kontextzeiger 158. Dieser Zeiger 158 wird verwendet, um die bestimmten Shell-Objekte 150, 152, 154, 156 zu identifizieren, die dem aktuellen Betriebsmodus der Steuervorrichtung 19 entsprechen oder diesen logisch definieren.
Wie allgemein in 5b gezeigt ist, erlaubt die Verwendung von Shell-Objekten zum Definieren von Kontexten im Betrieb des Gerätetreibers 50 die Instantiierung von verschiedenen Schnittstellenobjekte 170, 172 in jeweiligen Kontexten innerhalb des Gerätetreibers 50. Mit jeder Instantiierung eines Schnittstellenobjekts 170, 172 wird ein privater Datenraum 174, 176 zugewiesen und dem entsprechenden Schnittstellenobjekt 170, 172 zugeordnet. Alle Instantiierungen eines bestimmten Schnittstellenobjekts 170, 172 kapseln jedoch gemeinsam ein gemeinsam genutztes Schnittstellenmodul 178. Bei der Ausführung des Schnittstellenmoduls 178 wird die Bezugnahme auf die privaten Datenräume 174, 176 durch unabhängige Zeiger freigegeben, die in den jeweiligen Schnittstellenobjekten 170, 172 eingerichtet sind. Folglich ist das Schnittstellenmodul 178 implizit in einem spezifischen Kontext mit dem richtigen Objekt verbunden; das Modul 178 muss nicht explizit Aspekte der Existenz mehrerer Kontexte managen. Vielmehr ist die Funktion des Kontextmanagements und der Manipulation in den Routinen der Shell-Bibliothek 72' konzentriert und wird dort ausgeführt.
Der Prozess der Durchführung einer Kontextumschaltung findet gemäß den Prozessschritten statt, die in den 6a und 6b gezeigt sind. Eine Kontextumschaltung beginnt mit einer aktuell aktiven Kontextinstanziierung 150 des Shell-Objekts, das einen API-Aufruf empfängt, der wenigstens schlussfolgernd einen Moduswechsel zu einem Betriebsmodus spezifiziert, der die Beständigkeit eines bestimmten Aspekts des aktuellen Modus erfordert, wie z. B. ein Moduswechsel zu einer Farbtiefe verschieden von derjenigen des aktuellen Kontextes. Wie zuvor führt das Shell-Objekt 150 die anfängliche Überprüfung der Operanden des API-Aufrufs durch, bestimmt, das eine Kontextumschaltung aufgerufen ist, und gibt einen Erzeuge-Neuen-Kontext-Aufruf 180 an die Shell-Bibliothek 72' aus. Die Shell-Bibliothek 72' untersucht jede der bestehenden Instantiierungen des Shell-Objekts, die dann innerhalb des Kontextvorrats 148 existieren können, um zu bestimmen, ob ein Kontext mit der gewünschten Farbtiefe bereits existiert 184. Wenn eine Instantiierung eines Shell-Objekts existiert, wie z. B. das Shell-Objekt 152, mit der gewünschten Farbtiefe, gibt der Erzeuge-Neuen-Kontext-Aufruf an die Shell-Bibliothek 72' das Shell-Objekt 150 zurück.
Wenn jedoch der gewünschte Kontext nicht existiert, wird eine neue Shell-Objekt-Instantiierung erzeugt 186. Vor der Erzeugung dieses neuen Shell-Objekts, wenn die Kontextänderung die erste solche Änderung ist, die die Unterstützung für eine vorher nicht unterstützte Farbtiefe erfordert, kann die Shell-Bibliothek 72' modifiziert werden, um Unterstützung für die entsprechende Farbtiefenkonvertierung einzuschließen. In der bevorzugten Ausführungsform der vorliegenden Erfindung wird die Shell-Bibliothek 72' beim Erzeugen des zweiten existierenden Kontextes modifiziert, um Unterstützung für allen möglichen Farbtiefenkonvertierungen einzuschließen, lediglich der Bequemlichkeit halber. Genauer wird eine Routine zum Bestimmen und Konvertieren zwischen der aktuellen und der beabsichtigten Farbtiefe direkt in den Code der Shell-Bibliothek 72' eingebunden, um somit die beständige bedingte Prüfung, ob die Farbtiefenkonvertierung auf jede Zeichenoperation anwendbar ist, selbst wenn nur ein einzelner Kontext im Gebrauch ist, zu vermeiden.
Die Farbtieferoutinen der vorliegenden Erfindung sorgen für eine fliegende Konvertierung von geräteabhängigen Bitfeldern zwischen Farbtiefen von 8, 16, 24 und 32 Bits. Übersetzungen zwischen 16, 24 und 32 Bitfarbtiefe werden durchgeführt durch direkte Abbildung zwischen den RGB-Farbwerttupeln, die für jedes Anzeigepixel bei der aktuellen Anzeigefarbtiefe gespeichert sind. Übersetzungen von einem palettierten Farbraum unter Verwendung eines Farbindex von 8 Bit pro Pixel werden durchgeführt, indem zuerst das RGB-Farbwerttupel in der in PDevice gespeicherten Farbpalette und den Übersetzungstabellen des Kontextes der Quellanwendung nachgeschlagen wird, und daraufhin wieder ein direkte RGB-Farbabbildung auf die aktuelle Anzeigefarbtiefe durchgeführt wird.
Die fliegende Konvertierung von einer Farbtiefe mit 16, 24 oder 32 Bit zu einer palettierten Form mit 8 Bit ist etwas umständlicher. Die Übersetzung erfordert ein Durchsuchen des 8-Bit-Farbraumes nach einer besten Entspre chung für jedes RGB-Tupel, das konvertiert wird. Im allgemeinen kann ein Kleinste-Mittlere-Qudrate-Algorithmus verwendet werden, um eine Farbabbildung mit bester Entsprechung zu finden. Eine signifikante Leistungsverbesserung kann erreicht werden durch Zwischenspeichern übersetzter Farben. Zum Beispiel kann eine Basiszwischenspeichertabelle mit 8.192 32-Bit-Zwischenspeichereinträgen beim Übersetzen von 32-Bit-RGB-Tupeln in einen 8-Bit-Palettenindex verwendet werden. Jeder 10-Bit-RGB-Wert wird in der Präzision um 3 Bits reduziert, was zu einem 21-Bit-Tupel führt. Somit kann ein 8-Bit-Palettenindexwert, bestimmt durch einen fliegenden Kleinste-Mittlere-Quadrate-Beste-Entsprechung-Abgleich mit der aktuellen Farbpalette, mit jedem 21-Bit-Tupel zwischengespeichert werden, um eine Schnellkonvertierungs-Nachschlagtabelle einzurichten. Anschließende Farbkonvertierungen können dann zuerst die Tabelle für im voraus konvertierte Palettenindizes durchsuchen. Folglich können alle Farbtiefekonvertierungen direkt durch die Shell-Bibliothek 72' als Teil jeder API-initiierten Zeichenoperation direkt unterstützt werden.
Die Instantiierung eines neuen Shell-Objekts wird durchgeführt durch Aufrufen der Initialisierungsroutine des Shell-Schnittstellenmoduls. Wie bei der ursprünglichen Initialisierung des Gerätetreibers 50 wird eine neue Shell-Objekt-Instantiierung, nun das Shell-Objekt 152, zugewiesen und initialisiert. Ein Initialisierungsaufruf wird anschließend an die Leiterplattenbibliothek 74' gestellt. Da die Leiterplattenbibliothek 74', ähnlich der Shell-Bibliothek 72', eine konstante über alle Betriebsmodi der Steuervorrichtung 19 hinweg ist, werden die notwendigen Referenzen auf die Leiterplattenbibliothek 74', wenn verschieden von Referenzen zu den individuellen Hardware-Schnittstellenobjekten, mit dem neuen Shell-Objekt 152 verbunden. Die Leiterplattenbibliothek 74' ruft anschließend die Initialisierungsroutinen aller Hardware-Schnittstellenmodule der Reihe nach auf, um neue Instantiierungen der Objekte zu erzeugen und die Objekte mit der Leiterplattenstruktur des neuen Shell-Objekts 152 zu verbinden. Konstanten über die Farbtiefenumschaltungen hinweg, wie z. B. die Inhalte der Strukturen Registerhantierer aller Module können entweder vollständig neu erzeugt oder einfach kopiert oder aus den Objekten des aktuellen Kontextes bezogen werden. Zum Beispiel kann in der Initialisierung des Graphikhardware-Schnittstellenobjekts 138 ein neues Privat-Hardware-Beschleunigercode-Datenobjekt erzeugt werden. Der von diesem Datenobjekt gespeicherte Code kann Initialisierungskonstanten oder Ablaufsteuerungscode sein, der heruntergeladen wird, um den Hardwarebeschleuniger des Graphikunterelements der Steuervorrichtung 19 zu initialisieren. Andere Ablaufsteuerungscodesätze und Teilsätze können somit vom Graphikschnittstellenobjekt in verschiedenen Kontexten gemanagt werden. Diese Fähigkeit ist von besonderer Bedeutung, wenn der Beschleunigercode im Betrieb des Graphikunterelements innerhalb eines einzelnen Betriebsmodus bei Bedarf dynamisch austauschbar ist, um vielleicht den Beschleunigungsalgorithmus für die optimale Ausführung unterschiedlicher Zeichenbefehlssätze anzupassen. Die Leiterplattenbibliotheksinitialisierungsroute springt anschließend zur Shell-Bibliothek 72' zurück.
Die Initialisierungsroutinen der übrigen Betriebssystemschnittstellenmodule werden anschließend aufgerufen, um die Initialisierung des neuen Shell-Objekts 152 abzuschließen. Jedes Modul erzeugt eine neue Instantiierung eines entsprechenden Schnittstellenobjekts, erzeugt irgendeinen notwendigen privaten Datenraum für das Objekt, und verbindet anschließend das Objekt mit dem neuen Shell-Objekt 152. Genauer sorgt die Initialisierung des Direktzeichnungs-Betriebssystemschnittstellenobjekts 122 für die Erzeugung einer neuen kontextspezifischen Struktur PDevice und möglicherweise einer neuen Struktur GDI_Infotable. Wie bei den Hardware-Schnittstellenobjekten können die von diesen Strukturen gespeicherten Daten vollständig neu erzeugt werden, oder es können Daten von den entsprechenden Strukturen des aktuellen Kontextes verwendet werden, um die neuen Strukturen zu initialisieren. Die Daten in der neuen Struktur PDevice werden spezifisch modifiziert, um die Farbtiefe des neuen Kontextes zu definieren. In ähnlicher Weise wird das Pixeltiefefeld von GDI_Infotable modifiziert, um die neue Farbtiefe ebenfalls wiederzuspiegeln. Zeiger auf diese zwei neuen Strukturen, die anschließend von der Shell-Bibliothek 72' gemanagt werden, werden logisch mit dem Shell-Objekt 152 des neuen Kontextes verknüpft.
Folglich wird eine vollständige Ergänzung sowohl der Betriebssystem- als auch der Hardware-Schnittstellenobjekte erzeugt, um einen Kontext zu definieren, der logisch verschieden ist vom aktuellen Kontext, der durch das Shell-Objekt 150 repräsentiert wird. Die Ausführung kehrt anschließend von der Shell-Bibliothek 72' zum Shell-Objekt 150 zurück.
Das Shell-Objekt 150 gibt als nächstes 200 einen Aufruf an die Leiterplattenbibliothek 72' aus, um einen neuen Kontext zu verwirklichen. Das Shell-Objekt 150 stellt Operanden bereit, die ausreichen, um die Eigenschaften des neuen Kontextes zu identifizieren, einschließlich, in der bevorzugten Ausführungsform, der gewünschten Farbtiefe und der räumlichen Auflösung für den gewünschten Betriebsmodus der Steuervorrichtung 19. In Reaktion hierauf durchsucht die Shell-Bibliothek 72' den Kontextvorrat 148, um ein Shell-Objekt auszuwählen, wie z. B. das Shell-Objekt 152, das dem gewünschten neuen Kontext entspricht.
Bei der Vorbereitung für die wirkliche Durchführung der Kontextumschaltung gibt die Shell-Bibliothek 72' anschließend einen Moduseinstellaufruf mit einem Operanden "Modus wechselt bald" an jedes Schnittstellenobjekt aus, das an der Moduseinstellung 206 teilnimmt. Wie zuvor speichert jedes der teilnehmenden Schnittstellenobjekte irgendeine zustandsbezogene Information in den Entsprechenden privaten Datenräumen, um sicherzustellen, dass solche Informationen über nicht nur die Modusumschaltung hinweg, sondern auch über die Kontextumschaltung hinweg beständig sind.
Beim Rücksprung von den letzten der teilnehmenden Schnittstellenobjekten installiert die Shell-Bibliothek 72' das neue Shell-Objekt 152 als die Shell-Objekte, die den aktuellen Kontext definieren. Gleichzeitig richtet die Shell-Bibliothek 72' die Struktur PDevice und die Strukturen GDI_Infotable ein, die logisch dem Shell-Objekt 152 als die Strukturen zugeordnet sind, auf die von der Betriebssystemschicht 54 in nachfolgenden API-Aufrufen an den Gerätetreiber 50 Bezug genommen wird.
Die Analyseroutine der Shell-Bibliothek 72' wird anschließend aufgerufen, um die Befehle auszuführen, die zum Implementieren der Modusumschaltung notwendig sind. Die Verarbeitung und die Ausführung dieser Befehle sind konsistent mit der notwendigen Verarbeitung zum Implementieren einer einfachen Modusumschaltung, die keine Kontextumschaltung durch den Gerätetreiber 50 beinhaltet.
Sobald die Moduseinstellbefehle ausgeführt worden sind, gibt die Shell- Bibliothek 72' einen Moduseinstellaufruf mit einem Modusänderungsoperanden an jedes der teilnehmenden Objekte aus. Wie zuvor kann jedes der Objekte irgendwelche objektspezifischen Routinen ausführen, die zum Implementieren oder Unterstützen des neuen Betriebsmodus der Steuervorrichtung 19 erforderlich sind, wie z. B. Herunterladen eines neuen Ablaufsteuerungscodes zum Graphikbeschleuniger-Unterelement.
Schließlich gibt die Shell-Bibliothek 72' einen Moduseinstellaufruf an jedes der teilnehmenden Objekte mit einem Operanden "Modus hat gewechselt" aus. In Reaktion hierauf wird jedes der teilnehmenden Objekte ausgeführt, um die Betriebsumgebung der Steuervorrichtung 19 einzurichten, einschließlich z. B. der Neuzuweisung der Verwendung des Speichers im Anzeigepuffer 20 und der Einrichtung der Position des Hardware-Cursors auf der Anzeige 32. Außerdem wird ein Aufruf durch das Betriebssystemobjekt 128 gemacht, um einen Sturzbildschirmaktualisierer anzufordern. In Reaktion hierauf koordiniert der Betriebssystemkern 56 eine Reihe von Aufrufen an den Gerätetreiber 50, die Zeigerreferenzen auf die Bitfelder bereitstellen, wie auf der Anzeige 32 sichtbar sind. Wenn jedes Bitfeld durch den Gerätetreiber 50 verarbeitet worden ist, werden irgendwelche erforderlichen Farbtiefeübersetzungen in geeigneter Weise von der Shell-Bibliothek 72' ausgeführt.
Bei Rücksprung vom letzten teilnehmenden Objekt kehrt die Shell-Bibliothek 72' effektiv durch das Shell-Objekt 152 zur Betriebssystemschicht 54 zurück. Folglich hat der Gerätetreiber 50 sowohl eine Modusumschaltung als auch eine Kontextumschaltung im Wesentlichen unabhängig und ohne die umständliche Teilnahme der Anwendung 60 oder der Betriebssystemschicht 54 abgeschlossen.
VI. Betriebszustandsbeendigung:
Schließlich sorgt die vorliegende Erfindung für einen Prozess der Beendigung der Operation des Gerätetreibers 50, wie allgemein in 7 gezeigt ist. Implementierungen des Betriebssystemkerns 56, wie z. B. insbesondere Windows'95^TM, stellen einen Abschaltungs-API-Aufruf als einen Standardaufruf bereit, der an jeden der Gerätetreiber innerhalb eines Computersystems 10 bei Beendigung des Betriebssystemkerns 56 ausgegeben wird. Bei Empfang des Abschaltungs-API-Aufrufs arbeitet das Shell-Objekt des derzeit aktiven Kontextes, wie z. B. das Shell-Objekt 152, so, dass es die Verarbeitung irgendwelcher weiterer API-Aufrufe durch den Gerätetreiber 50 mittels Beendigungsakzeptanz 222 der nachfolgenden empfangenen API-Aufrufe durch die Betriebssystemschnittstellenmodule deaktiviert. Folglich kann der Gerätetreiber 50 anschließend eine Abschaltung in einer ordentlichen Weise durchführen, ohne durch den Empfang eines unerwarteten API-Aufrufs gestört zu werden.
Ein Vorgabeabschnitt der Konfigurationsdatei modes.dmm wird anschließend gelesen und von der Analyseroutine der Shell-Bibliothek 72' ausgeführt. Die von diesen Vorgabeabschnitt bereitgestellten Befehle werden verwendet, um einen Vorgabebetriebsmodus 224 der Steuervorrichtung 19 einzustellen. Die Steuervorrichtung 19 wird somit in einen bekannten Zustand versetzt, der für die potentielle Verwendung nach dem Abschalten des Betriebssystemkerns 56 geeignet ist.
Die Shell-Bibliothek 72' arbeitet anschließend so, dass sie den von den Schnittstellenobjekten und Modulen des Gerätetreibers 50 benutzten Systemspeicher freigibt. Genauer arbeitet die Shell-Bibliothek 72' so, dass sie jeden existierenden Kontext des Gerätetreibers 50 identifiziert. Für jeden identifizierten Kontext 228 ruft die Shell-Bibliothek 72' die Leiterplattenbibliothek 74' auf, um sequenziell jedes der für den bestimmten Kontext 230 spezifischen Hardware-Schnittstellenobjekten freizugeben. Die Leiterplattenbibliothek 74' ruft ihrerseits jedes Hardware-Schnittstellenobjekt auf, das den Shell-Objekt des identifizierten Kontextes zugeordnet ist. Mit dem Freigeben des letzten einem Hardware-Schnittstellenmodul zugeordneten Objekts ist der Speicherraum, der sowohl dem Objekt als auch dem Modul zugewiesen ist, freigegeben. Sobald alle Hardware-Schnittstellenobjekte für alle Kontexte freigegeben worden sind, wird erneut die Leiterplattenbibliothek 74' aufgerufen, um ihren eigenen Speicher 232 freizugeben.
Die Shell-Bibliothek 72' ruft jedes der Betriebssystemschnittstellenobjekte 234 für jeden existierenden Kontext auf, um den Speicherraum freizugeben, der den Objekte und den entsprechenden Modulen zugewiesen ist. Die Shell-Objekte, die die existierenden Kontexte des Gerätetreibers 50 definie ren, werden ebenfalls freigegeben. Die Shell-Bibliothek 72' endet anschließend 236, wodurch effektiv der zugehörige Speicher freigegeben wird, und wobei die Ausführung zum Betriebssystemkern 56 zurückkehrt, um das Beenden der Betriebssystemschicht 54 fortzusetzen.
V. Virtualisierte Treiberoperation:
In der bevorzugten Umgebung Microsoft Windows'95 besteht eine Notwendigkeit, Altanwendungen zu unterstützen, die in einem sogenannten geschützten DOS-Kasten-Ausführungsraum laufen. Eine geschützte Ausführung, relevant für eine bevorzugte Implementierung der vorliegenden Erfindung, ist entweder in einem Vollbildschirmmodus oder einem Fenstermodus vorgesehen. Altanwendungen ist es erlaubt, die Steuervorrichtung 19 im Vollbildschirmmodus direkt zu programmieren und darauf zuzugreifen. Im Fenstermodus wird ein virtualisierter Gerätetreiber, typischerweise als ein VxD-Treiber bezeichnet, zur Verfügung gestellt, um die von der Altanwendung erwarteten Hardware-Register zu emulieren. Um mit anderen Fensteranwendungen zu koexistieren und gemeinsam ausführt zu werden, wird vom VxD-Treiber erwartet, eine fensterbezogene Emulation der Hardwareprogrammierung bereitzustellen, die von der Altanwendung dynamisch vorgesehen ist. Typischerweise sind VxD-Treiber wiederum als einzelne monolithische Softwaremodule implementiert, die eine Emulation der Gesamtheit einer spezifischen Implementierung einer Steuervorrichtung 19 unterstützen. Folglich stoßen herkömmliche VxD-Treiber auf die gleichen Probleme, die den herkömmlichen Gerätetreibern zuzuordnen sind.
Wie allgemein in 8 gezeigt ist, kann die Architektur des Gerätetreibers 50 der vorliegenden Erfindung direkt und effektiv angepasst werden, um VxD-Treiber zu implementieren, einschließlich insbesondere eines virtuellen Anzeigetreibers (VDD). Ein Gerätetreiber 50, wie oben beschrieben worden ist, arbeitet vorzugsweise zur Unterstützung einer virtuellen Maschine (VM) 240 von Windows (Win16), die in herkömmlicherweise innerhalb der Betriebssystemschicht 54 eingerichtet ist. Eine DOS-VM 242 stellt den geschützten DOS-Kasten-Ausführungsraum für Altanwendungen zur Verfügung, die versuchen können, direkt auf die Hardware 30 zuzugreifen. Eine Version 50' des Gerätetreibers 50 ist vorgesehen, um die Konsequenzen von Hardware-Zugriffsversuchen, die durch die DOS-VM 242 oder von innerhalb derselben heraus gestartet werden, abzufangen, zu bewerten und, falls angemessen, zu emulieren. Wenn die VDD 50' bei der Unterstützung der Fenstermodusausführung einer Anwendung innerhalb der DOS-VM 242 aktiv wird, richtet sie selektiv eine Zugriffsfalle für den E/A-Bereich oder den Speicherraum ein, der der Registerschnittstelle 30 entspricht, durch eine herkömmliche Verwendung des Betriebssystems. Diese Zugriffsfalle wird im allgemeinen aufgelöst, wenn die DOS-VM 242 in einen Vollbildschirmmodus umschaltet, oder wenn die Ausführung zu einer weiteren virtuellen Maschine 240, 244 springt. Die Zugriffsfalle wird reaktiviert, wenn die Ausführung zu DOS-VM 242 im Fenstermodus zurückkehrt, oder bei einer Umschaltung vom Vollbildschirmmodus in den Fenstermodus.
Immer wenn die Zugriffsfalle einen Zugriffsversuch entdeckt, wird der VDD 50' die Zugriffscharakterisierungsinformation zur Verfügung gestellt, die von der Falle erhalten wird. Genauer wird der Leiterplattenbibliothek 74'', wie in 9 gezeigt ist, die Zugriffsversuchinformation vom Betriebssystem 54 logisch über die Verbindung 246 bereitgestellt. Die Komponenten der VDD 50' implementieren vorzugsweise eine einzelne Kontextversion des Anzeigetreibers 50. Es können jedoch leicht mehrere Kontexte als zur Unterstützung mehrerer Steuervorrichtungen 19 geeignet unter der DOS-VM 242 unterstützt werden.
Innerhalb eines einzelnen Kontextes arbeiten die Hardware-Schnittstellenobjekte 130', 132', 134' und 138 so, dass sie die Zugriffscharakterisierungsdaten speichern, um somit eine Repräsentation des beabsichtigten Zustands der Anzeige auf der Grundlage der aufeinanderfolgenden Versuche zum direkten Zugriff auf die Hardware zu erhalten. Die Strukturen RegClassMap, die den Hardware-Schnittstellenobjekten zugeordnet sind, werden vorzugsweise mit Zeigern auf Speicherraum für die Zustandsinformationen, die jeder Klasse von Hardware-Unterelementen zugeordnet sind, erweitert. Die Hardware-Schnittstellenobjekte stellen ferner Emulationsroutinen bereit, die Betriebssystemaufrufe mit Unterstützung des O/S-Objekts 128' erzeugen, um die Anzeige zu einer geeigneten Darstellung des beabsichtigten Bildschirmerscheinungsbildes zu veranlassen. Diese Aufrufe werden auf die Betriebssystemschicht 54 angewendet und wiederum geeignet zum Anzeigetreiber 54 geleitet. Bei einer Umschaltung in einen Vollbildschirmmodus kann der von den Hardware-Schnittstellenobjekten gehaltene Anzeigezustand direkt verwendet werden, um den beabsichtigten Anzeigezustand einzurichten durch Anwenden der Zustandsdaten auf die Registerschnittstelle 30.
Die Analysatorroutine des Gerätetreibers 50' wird effektiv bei der Umkehrung verwendet, um die Zugriffscharakterisierungsinformationen zu analysieren. Vorzugsweise dienen die Zugriffsfallen zum Charakterisieren von Zugriffsversuchen auf Geräteklassen implizit durch Zuweisung von Adressen zu Klassenfallenhantierern. Somit werden die Klasse, die Adresse und der Wert, die mit dem Zugriff bereitgestellt werden, von den Fallenhantierern gesammelt und der Umkehranalysatorroutine zur Verfügung gestellt. Mit jedem abgefangenen Zugriffsversuch werden somit die zugriffsbezogenen Daten in dem entsprechenden identifizierten Speicher RegClassMap gespeichert. Der Umkehranalysator führt ferner eine Analyse der Registerdefinitionen durch, die schließlich von dem Klassenregisteranweisungen bestimmt werden, die in der Datei modes.dmm gespeichert sind. Das Ergebnis der Analyse ist eine logische Bestimmung, ob das zu überschreiben beabsichtigte Register ein Indexregister ist, oder ein Managementfunktionsregister, oder ein Datenregister. Wenn das beabsichtigte Register ein Indexregister oder ein anderes Managementfunktionsregister ist, wird die resultierende Zustandsänderung aufgezeichnet. Wenn das beabsichtigte Register ein Datenregister ist, wird der neue Zustand des Registers aufgezeichnet, woraufhin bestimmt wird, ob eine bestimmte Emulation erforderlich ist. In Abhängigkeit von dem besonderen überschriebenen Register braucht keine Emulation erforderlich sein, oder die Vollindex- und Datenzugriffoperation kann anschließend durchgeführt werden.
Folglich werden im Wesentlichen die gleichen Hardware- und Betriebssystemschnittstellenobjektdefinitionen vorzugsweise verwendet, wobei ferner die gleichen Verfahren der Auswahl zwischen mehreren Funktionen, die unterschiedliche Anzeigeeigenschaften unterstützen, verwendet werden können, um unter den Anzeigeeigenschaft-Emulationsroutinen, die von den gekapselten Hardware-Schnittstellenmodulen implementiert werden, auszuwählen. Wenn die Analysatorroutine eine identifizierbare Moduseinstellung erfasst, kann das Shell-Objekt 126' über das O/S-Objekt 128' aufgerufen werden, um eine Moduseinstelloperation durchzuführen, wie vorher beschrieben worden ist. Die im Wesentlichen linearen Aufrufsequenzen, die durch die Betriebssystemobjekte 120', 122', 126' implementiert sind, werden direkt freigegeben. Die Funktionsaufrufbeziehung zwischen den Betriebssystemschnittstellenobjekten und dem Rest der VDD 50' ist daher die gleiche wie im Fall des Gerätetreibers 50.
V. Schlussfolgerung:
Somit wurde eine sehr optimale Gerätetreiberarchitektur beschrieben, die für die Unterstützung einer komplexen und multifunktionalen Peripheriesteuervorrichtung sowie den Betrieb als virtueller Gerätetreiber geeignet ist. Die Architektur des beschriebenen Gerätetreibers unterstützt direkt die dynamische Konfiguration des Gerätetreibers zum Ladezeitpunkt, um die Hardware-Konfiguration der Peripheriesteuervorrichtung spezifisch anzugleichen, wie vorzugsweise direkt von der Hardware auf einer genauen Grundlage je Unterelement bestimmt wird, die eine modulare Architektur verwendet, um eine funktionale Isolation von Moduländerungen entsprechend den spezifischen Unterelemententwürfen spezifisch zu unterstützen, für einen effizienten Mechanismus zum Durchführen von Modusumschaltungen des Betriebszustands der Steuervorrichtung zu sorgen, einen effizienten Mechanismus zum Pflegen und Managen von beständigen Daten unabhängig von Modusumschaltungen durch die Unterstützung von unabhängigem Kontext selektiv mit der Durchführung von Modusumschaltungen bereitzustellen, und für ein effizientes Management von Farbtiefetransformation in Videoanzeigesteuervorrichtungs-Anwendungen zu sorgen. Trotz der modularen Komplexität der Architektur ermöglicht ferner die unterstützte interoperative Beziehung zwischen den Modulen im Wesentlichen linearisierte Aufrufsequenzen, um die Betriebssystem-API-Aufrufe zu virtualisieren und zu implementieren.
Hinsichtlich der obigen Beschreibung der bevorzugten Ausführungsformen der vorliegenden Erfindung sind für Fachleute viele Modifikationen und Variationen der offenbarten Ausführungsformen offensichtlich. Es ist daher klar, dass die Erfindung innerhalb des Umfangs der beigefügten Ansprüche anders ausgeführt werden kann, als oben spezifisch beschrieben ist.

Claims

Verfahren des Bewerkstelligens einer kontrollierten Manipulation des Betriebszustandes einer Hardware-Steuervorrichtung, die an einem Computersystem angeschlossen ist, das einen Prozessor und einen Speicher enthält, wobei das Computersystem ein Betriebssystem ausführt, das über einen Gerätetreiber mit der Hardware-Steuervorrichtung gekoppelt ist, wobei das Verfahren die Schritte umfasst: a) Feststellen mittels der Operation des Prozessors, ob ein Moduswechselereignis von einem ersten vorgegebenen Betriebszustand zu einem zweiten vorgegebenen Betriebszustand der Hardware-Steuervorrichtung aufgetreten ist; b) Speichern von Daten, die einen ersten Kontext entsprechend dem ersten vorgegebenen Betriebszustand der Hardware-Steuervorrichtung an einem ersten vorgegebenen Ort, der innerhalb des Speichers reserviert ist, definieren, mittels des Gerätetreibers; c) Wiederherstellen von Daten, die einen zweiten Kontext entsprechend dem zweiten vorgegebenen Betriebszustand definieren, von einem zweiten vorgegebenen Ort, der innerhalb des Speichers reserviert ist, mittels des Gerätetreibers; und d) Anwenden der Daten, die den zweiten Kontext definieren, auf die Hardware-Steuervorrichtung, um den zweiten vorgegebenen Betriebszustand herzustellen.
Verfahren nach Anspruch 1, wobei der Schritt des selektiven Wiederherstellens die Schritte enthält: a) Feststellen, ob der zweite vorgegebene Ort vom Gerätetreiber reserviert worden ist; b) Reservieren des zweiten vorgegebenen Ortes für den Gerätetreiber, wenn der zweite vorgegebene Ort vorher nicht reserviert worden ist; und c) Initialisieren von Daten, die den zweiten Kontext definieren.
Verfahren nach Anspruch 1, wobei irgendwelche der Schritte des selektiven Speicherns und des selektiven Wiederherstellens übersprungen werden.
Verfahren nach Anspruch 1 oder Anspruch 3, wobei die Daten, die den zweiten Kontext definieren, dynamisch aus einer Datendatei erhalten werden, die sich außerhalb des Gerätetreibers befindet.
Gerätetreiber für die Verwendung in Verbindung mit einem Betriebssystem eines Computersystems für die Bereitstellung einer Betriebsschnittstelle zu einer programmierbaren Steuervorrichtung, wobei der Gerätetreiber umfasst: a) ein erstes Schnittstellenmodul, das mit einem Betriebssystem koppelbar ist und eine Einsprungspunktunterstützung für einen vorgegebenen API-Aufruf bereitstellt, um eine Moduseinstelloperation einzuleiten; b) ein zweites Schnittstellenmodul, das mit dem Betriebssystem koppelbar ist und eine Einsprungspunktunterstützung für einen vorgegebenen Betriebssystemaufruf bereitstellt, um Systemkonfigurationsdaten zu lesen; c) ein drittes Schnittstellenmodul, das mit einer programmierbaren Steuervorrichtung koppelbar ist und eine Einsprungspunktunterstützung für eine vorgegebene Hardwareschnittstellenregister-Programmierungsroutine bereitstellt; und d) ein Bibliotheksmodul, das mit dem ersten, dem zweiten und dem dritten Schnittstellenmodul koppelbar ist, wobei das Bibliotheksmodul auf den Empfang des vorgegebenen API-Aufrufes durch das erste Schnittstellenmodul reagiert, wobei das Bibliotheksmodul einen Aufruf an das zweite Schnittstellenmodul bewerkstelligt, um den vorgegebenen Betriebssystemaufruf zum Lesen vorgegebener Systemkonfigurationsdaten entsprechend den Betriebsmoduseinstelldaten einzuleiten, wobei das Bibliotheksmodul einen Syntaxprüfer enthält, um durch Ausführen vorgegebener Befehle, die in den vorgegebenen Systemkonfigurationsdaten vorgesehen sind, Registerprogrammierungsdaten zu erzeugen, wobei die Registerprogrammierungsdaten der vorgegebenen Hardwareschnittstellenregister-Programmierungsroutine des dritten Schnittstellenmoduls zur Verfügung gestellt werden.
Gerätetreiber nach Anspruch 5, wobei das Bibliotheksmodul wenigstens bei der Installation und Initialisierung des Gerätetreibers durch das Betriebssystem innerhalb eines Speichers des Computersystems mit dem ersten, dem zweiten und dem dritten Modul gekoppelt ist.
Gerätetreiber nach Anspruch 6, wobei das dritte Modul eine programmierbare Modulschnittstelle enthält, die mehrere Aufrufeinsprungspunkte in die vom dritten Modul unterstützten ausführbaren Funktionen aufweist, und wobei das dritte Modul die Initialisierung der mehreren Aufrufeinsprungspunkte auf eine vorgegebene Teilmenge der mehreren Aufrufeinsprungspunkte des dritten Moduls bewerkstelligt.
Gerätetreiber nach Anspruch 7, wobei das dritte Modul die Reinitialisierung der mehreren Aufrufeinsprungspunkte auf eine wechselnde Teilmenge der mehreren Aufrufeinsprungspunkte des dritten Moduls übereinstimmend mit der Moduseinstelloperation bewerkstelligt.
Gerätetreiber nach Anspruch 8, wobei das erste Modul eine Kopie der programmierbaren Modulschnittstelle enthält, und wobei die Kopie an die vorgegebene Teilmenge oder die wechselnde Teilmenge der mehreren Aufrufeinsprungspunkte, die in der programmierbaren Modulschnittstelle des dritten Moduls bereitgestellt werden, angepasst wird.
Verfahren der Durchführung einer Moduseinstellung des Betriebszustandes einer programmierbaren Steuervorrichtung, die an ein Computersystem angeschlossen ist, wobei die programmierbare Steuervorrichtung dem Computersystem eine Registerschnittstelle präsentiert, und wobei ein vom Computersystem ausgeführtes Betriebssystem einen Moduswechselaufruf bereitstellt, der vorgegebene Daten enthält, die vorgegebene Eigenschaften eines Betriebsmodus der programmierbaren Steuervorrichtung definieren, wobei das Verfahren Schritte umfasst: a) Festlegung in Reaktion auf den Moduswechselaufruf, eine Moduseinstellung der programmierbaren Steuervorrichtung durchzuführen; b) Festlegen eines Zielmodus für die Moduseinstellung auf der Grundlage der vorgegebenen Daten; c) Erlangen vorgegebener Konfigurationsdaten entsprechend dem Zielmodus; d) Syntaxanalyse der vorgegebenen Konfigurationsdaten, um mehrere Befehle, die innerhalb der vorgegebenen Konfigurationsdaten enthalten sind, zu identifizieren und auszuführen, wobei die Ausführung der mehreren Befehle Registerprogrammierungsdaten bereitstellt, die geeignet sind, um die Moduseinstellung der programmierbaren Steuervorrichtung auf den Zielmodus durchzuführen; und e) Bereitstellen der Registerprogrammierungsdaten für die Registerschnittstelle.