Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Beachten Sie beim Entwerfen eines Kernelmodustreibers die folgenden Punkte:
Treiber können mehrschichtig sein, und mehrere Treiber können eine einzelne E/A-Anforderung (IRP) verarbeiten.
Ein Treiber kann keine Annahmen darüber treffen, welche anderen Treiber im Gerätestapel enthalten sein werden. Daher sollte jeder Treiber darauf vorbereitet sein, Anforderungen von jedem anderen Treiber zu erhalten, und sollte alle potenziellen Fehlerfälle behandeln.
Treiber kommunizieren den Erfolg oder Fehler eines angeforderten E/A-Vorgangs im E/A-status-Block des IRP. Der E/A-Manager kommuniziert den Erfolg oder Fehler eines angeforderten E/A-Vorgangs an einen Benutzermodus-Anforderer.
Treiber müssen und dürfen nicht so konzipiert sein, dass sie anwendungsspezifische Unterstützung bieten. Ein geschütztes Subsystem oder dessen subsystemspezifische Benutzermodustreiber bieten diese Art von Unterstützung. Es gibt eine Ausnahme von dieser Regel: Eine MS-DOS-Anwendung, die auf einem anwendungsdedienten Gerät basiert, kann einen Kernelmodustreiber zur Steuerung des Geräts und einen eng gekoppelten Virtuellen Win32-Gerätetreiber (Virtual Device Driver, VDD) erfordern. Weitere Informationen zu VDDs finden Sie in der Dokumentation zu Treibern für virtuelle Geräte im Windows Driver Development Kit (DDK). (Das DDK war dem Windows Driver Kit [WDK] vorangestellt.)
Ein neuer Treiber muss den gleichen Satz von IRP_MJ_XXX verarbeiten wie jeder vom System bereitgestellte Treiber, den er ersetzt. Der E/A-Manager gibt STATUS_INVALID_DEVICE_REQUEST für eine bestimmte E/A-Anforderung an ein Zielgerät zurück, wenn der Treiber keinen Einstiegspunkt für dieses IRP_MJ_*XXX definiert. Ein Gerätetreiber muss auch die gleichen E/A-Steuercodes für IRP_MJ_DEVICE_CONTROL* Anforderungen verarbeiten wie jeder vom System bereitgestellte Treiber, den er ersetzt. Anders ausgedrückt: Ein neuer Gerätetreiber darf anwendungen nicht unterbrechen, indem er weniger Funktionen implementiert als ein vorhandener Treiber für denselben Gerätetyp.
Ein neuer Zwischentreiber, der in eine Kette vorhandener Treiber eingefügt wird, sollte den gleichen Satz von IRP_MJ_XXX erkennen wie der Treiber, den er verdrängt. Der neue Treiber kann irPs für diese Anforderungen, die nicht verarbeitet werden, einfach an den Treiber der nächstniedrigen Ebene übergeben. Ein neuer Zwischentreiber darf jedoch nicht die Kette für Treiber oberhalb und unterhalb des Treibers "unterbrechen", indem er es versäumt, einen Einstiegspunkt für eine IRP_MJ_XXX-Anforderung zu definieren, die der neu verschobene Treiber der nächstniedrigen Ebene verarbeitet.
Ein Treiber der niedrigsten Ebene kann nur auf seinen eigenen E/A-Stapelspeicherort in jedem gesendeten IRP zugreifen. Ein Treiber auf höherer Ebene kann nur auf seine eigenen und die E/A-Stapelspeicherorte des nächstniedrigen Treibers in jedem IRP zugreifen, der gesendet wird.
Jeder Treiber kommuniziert Informationen an übergeordnete Treiber (und letztendlich an Benutzermodusanwendungen über den E/A-Manager) nur in den E/A-status Blöcken von IRPs, da der E/A-Manager den entsprechenden E/A-Stapelspeicherort auf Null stellt, da jeder Treiber in einer Kette ein IRP abschließt. Jeder neue Treiber, der versucht, die Back-Door-Kommunikation mit einem bestimmten höheren (oder niedrigeren) Treiber zu implementieren, gefährdet seine Portabilität und seine Interoperabilität mit anderen Treibern von einer Windows-Plattform oder -Version zur nächsten.
Ein Treiberpaar kann eine Reihe von gerätespezifischen (auch als private) E/A-Steuerungscodes für IRP_MJ_INTERNAL_DEVICE_CONTROL Anforderungen definieren, die der höhere Teil des Paars an das untere des Paars senden kann. Ein solches Treiberpaar muss jedoch alle oben genannten Richtlinien befolgen, wenn sie portierbar und mit anderen Treibern von einer Windows-Plattform oder -Version zu einer anderen kompatibel bleiben sollen. Wenn Sie ein Treiberpaar mit einer privaten Schnittstelle entwerfen, sollten Sie den Satz von E/A-Steuercodes sorgfältig definieren. Gestalten Sie sie so allgemein nützlich wie möglich, und entwerfen Sie Ihre gekoppelten Treiber so, dass sie die vorherigen Richtlinien befolgen, sodass Sie (oder eine andere Person) ihre neuen Treiber oder beide neuen Treiber problemlos wiederverwenden, ersetzen oder verdrängen können, wenn sie von einer Windows-Plattform oder -Version zu einer anderen migrieren.