Windows-Verwaltung

Einblick in den Windows Vista-Kernel: Teil 1

Mark Russinovich

Kurz zusammengefasst:

• Threadpriorität und -planung
• Dateibasierte symbolische Verknüpfungen
• Abbrechen von E/A-Vorgängen

Dies ist der erste Teil einer Reihe, die sich mit den Neuerungen im Windows Vista-Kernel beschäftigt. In dieser Ausgabe gehe ich auf Änderungen im Bereich der Prozesse, Threads und E/A-Vorgänge ein. In zukünftigen Ausgaben werden die Themen Speicherverwaltung, Starten und Herunterfahren, Zuverlässigkeit und Wiederherstellung sowie Sicherheit behandelt.

Im Blickpunkt dieses Artikels stehen ausschließlich Änderungen am Windows Vista™-Kernel, insbesondere Ntoskrnl.exe und den damit eng in Verbindung stehenden Komponenten. Es sollte jedoch nicht vergessen werden, dass es in Windows Vista viele andere wichtige Änderungen gibt, die nicht in den Bereich des eigentlichen Kernels fallen und daher nicht behandelt werden. Hierzu gehören Verbesserungen an der Shell (z. B. integrierte Desktopsuche), an Netzwerkfunktionen (wie der neue IPv6-Stapel und die bidirektionale Firewall) und am Grafikmodell der nächsten Generation (wie die Aero™ Glass, Windows® Presentation Foundation, dem Desktopfenster-Manager und dem neuen Grafiktreibermodell). Ebenfalls nicht behandelt werden die neuen Windows-Benutzermodus- und Windows-Kernelmodus-Treiberframeworks (UMDF und KMDF), da diese auf früheren Versionen von Windows installiert werden können.

CPU-Zykluszählung

Windows Vista enthält eine Reihe von Verbesserungen im Bereich der Prozesse und Threads, zu denen die Verwendung des CPU-Zykluszählers für eine gerechtere CPU-Zuweisung und des neuen Multimediaklassen-Planungsdiensts (MMCSS) gehören, der Medienanwendungen bei der fehlerfreien Wiedergabe unterstützt.

Bei allen Versionen von Windows NT® bis einschließlich Windows Vista wird eine Intervallzeitgeber-Interruptroutine programmiert, die in Abhängigkeit von der Hardwareplattform ca. alle 10 oder 15 ms (Millisekunden) ausgeführt wird. Die Routine prüft, welchen Thread sie unterbrochen hat und aktualisiert die CPU-Nutzungsstatistik des Threads so, als ob dieser Thread während des gesamten Intervalls ausgeführt worden wäre, auch wenn die Ausführung des Threads in Wirklichkeit möglicherweise erst kurz vor dem Ende des Intervalls gestartet wurde. Darüber hinaus wurde der Thread möglicherweise technisch der CPU zugewiesen, erhielt jedoch keine Chance zur Ausführung, weil stattdessen Hardware- und Softwareinterruptroutinen ausgeführt wurden.

Obwohl die taktbasierte Zeitabrechnung für Diagnosetools, die die CPU-Nutzung durch Threads und Prozesse melden, möglicherweise in Ordnung ist, kann die Verwendung dieser Methode durch den Threadplaner zu einer ungerechten CPU-Zuweisung führen. Standardmäßig dürfen Threads auf Clientversionen von Windows bis zum Ablauf von 2 Zeiteinheiten des CPU-Takts ausgeführt werden (6 bei Ausführung im Vordergrund). Der Thread kann jedoch in Abhängigkeit von seinem Verhalten oder anderen Aktivitäten im System praktisch keine CPU-Zeit oder bis zu 6 Zeiteinheiten erhalten (18 bei Ausführung im Vordergrund).

Abbildung 1 zeigt die ungerechte Verteilung, die auftreten kann, wenn zwei Threads mit gleicher Priorität zum selben Zeitpunkt zur Ausführung bereit sind. Thread A wird bis zum Ablauf des nächsten Zeitintervalls ausgeführt. Dabei geht der Planer davon aus, dass der Thread während des gesamten Intervalls ausgeführt wurde, und entscheidet daher, dass die Ausführungszeit von Thread A beendet ist. Darüber hinaus geht der Interrupt, der während der Ausführung von Thread A aufgetreten ist, ungerechterweise zu dessen Lasten. Beim nächsten Intervall wählt der Planer Thread B aus, und dieser wird bis zum Ablauf des vollen Intervalls ausgeführt.

Abbildung 1** Ungerechte Threadplanung **

In Windows Vista verwendet der Planer das Zykluszählerregister moderner Prozessoren, um genau zu verfolgen, über wie viele CPU-Zyklen ein Thread ausgeführt wird. Durch Schätzung der Anzahl der Zyklen, die die CPU in einem Taktintervall ausführen kann, kann er die CPU-Zeit exakter verteilen. Darüber hinaus zählt der Windows Vista-Planer die Interruptausführung nicht in Bezug auf die Ausführungszeit eines Threads. Das bedeutet, dass ein Thread unter Windows Vista immer mindestens die ihm zugewiesene CPU-Zeit und nie mehr als ein zusätzliches Taktintervall zur Ausführung erhält, was zu einer größeren Gerechtigkeit und einem besser vorhersehbaren Anwendungsverhalten führt. Abbildung 2 zeigt, wie Windows Vista auf das in Abbildung 1 dargestellte Szenario reagiert, indem beiden Threads mindestens ein Zeitintervall zur Ausführung eingeräumt wird.

Abbildung 2** Zyklusbasierte Planung in Windows Vista **

In der Randleiste „Überwachen der CPU-Nutzung durch Prozesse“ wird beschrieben, wie Sie die CPU-Zyklusnutzung durch Prozesse mithilfe des Dienstprogramms „Process Explorer“ selbst überwachen können.

Multimediaklassen-Planungsdienst

Benutzer erwarten, dass Multimediaanwendungen, einschließlich Musik- und Videoplayern, eine nahtlose Wiedergabeerfahrung bieten. Der CPU-Bedarf von anderen, gleichzeitig ausgeführten Anwendungen wie Antivirusprogrammen, Inhaltsindizierung oder sogar des E-Mail-Clients kann jedoch zu unangenehmen Unterbrechungen führen. Um eine bessere Wiedergabeerfahrung zu gewährleisten, wird in Windows Vista der Multimediaklassen-Planungsdienst MMCSS zur Verwaltung der CPU-Prioritäten von Multimediathreads eingeführt.

Eine Multimediaanwendung wie Windows Media® Player 11 registriert sich bei MMCSS mithilfe neuer APIs, die ihre Multimediamerkmale angeben. Diese müssen einem der unter dem folgenden Registrierungsschlüssel namentlich aufgeführten Merkmale entsprechen:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Abbildung A** Anzeigen von CPU-Zeit und Zyklenunterschied in Process Explorer **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3** Audio-Taskdefinition durch den Multimediaklassen-Planungsdienst **(Klicken Sie zum Vergrößern auf das Bild)

Der MMCSS-Dienst, der in %SystemRoot%\System32\Mmcss.dll implementiert ist und in einem Service Host-Prozess (Svchost.exe) ausgeführt wird, verfügt über einen Thread zur Prioritätsverwaltung, der mit der Priorität 27 ausgeführt wird. (Die Threadprioritäten unter Windows reichen von 0 bis 31.) Dieser Thread erhöht die Priorität registrierter Multimediathreads auf den Bereich, der dem in Abbildung 4 aufgeführten Scheduling Category-Wert des Registrierungsschlüssels ihres Tasks zugeordnet ist. In Windows liegen Threadprioritäten von 16 und höher im Echtzeitprioritätsbereich und über allen anderen Threads in einem System (mit Ausnahme der Memory Manager-Arbeitsthreads des Kernels, die mit der Priorität 28 und 29 ausgeführt werden). Nur Administratorkonten wie das lokale Systemkonto, in dem MMCSS ausgeführt wird, verfügen über das Recht zur Prioritätserhöhung, das zur Festlegung von Echtzeit-Threadprioritäten erforderlich ist.

Figure 4 MMCSS-Threadprioritäten

Bei der Wiedergabe einer Audiodatei registriert Windows Media Player Audio-Taskthreads und bei der Wiedergabe eines Videos Playback-Taskthreads. Der MMCSS-Dienst erhöht die Priorität aller Threads, die angegeben haben, dass sie einen Datenstrom liefern, wenn sie in dem Prozess ausgeführt werden, dem das Vordergrundfenster gehört, und wenn für sie der BackgroundOnly-Wert im Definitionsschlüssel ihres Tasks auf „True“ festgelegt wurde.

Obgleich MMCSS darauf abzielt, Multimediathreads zur erforderlichen CPU-Zeit zu verhelfen, muss der Dienst gleichzeitig sicherstellen, dass andere Threads zumindest etwas CPU-Zeit erhalten, damit das System und andere Anwendungen reaktionsfähig bleiben. MMCSS reserviert daher einen bestimmten Prozentsatz der CPU-Zeit für andere Aktivitäten, der im folgenden Registrierungswert angegeben wird:

HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness 

Standardmäßig beträgt dieser Wert 20 Prozent. MMCSS überwacht die CPU-Nutzung, um sicherzustellen, dass die Priorität von Multimediathreads über einen Zeitraum von 10 ms nicht mehr als 8 ms lang erhöht wird, wenn andere Threads CPU-Ressourcen benötigen. Um die Multimediathreads für die verbleibenden 2 ms aus dem Weg zu räumen, verringert der Planungsdienst ihre Priorität auf den Bereich 1 bis 7.

Sie können erfahren, wie MMCSS die Threadpriorität erhöht, indem Sie die Randleiste „Überwachen der Prioritätserhöhung durch MMCSS“ lesen.

Dateibasierte symbolische Verknüpfungen

Zu den mit E/A-Vorgängen verbundenen Änderungen in Windows Vista gehören dateibasierte symbolische Verknüpfungen, effizientere Verarbeitung des Abschlusses von E/A-Vorgängen, umfassende Unterstützung für den Abbruch von E/A-Vorgängen und nach Priorität geordnete E/A-Vorgänge.

Ein Dateisystemfeature, das von vielen Benutzern in NTFS vermisst wurde – die symbolische Dateiverknüpfung (oder der Softlink, wie er in UNIX genannt wird) – wird nun mit Windows Vista eingeführt. In der Windows 2000-Version von NTFS wurden als Verzeichnisverbindungen bezeichnete symbolische Verzeichnisverknüpfungen eingeführt, mit denen Sie ein Verzeichnis erstellen können, das auf ein anderes Verzeichnis verweist. Vor Windows Vista unterstützte NTFS jedoch nur feste Verknüpfungen für Dateien.

Ein Hauptunterschied bei der Art und Weise, in der Windows symbolische Verknüpfungen und Verzeichnisverbindungen auflöst, liegt darin, wo die Verarbeitung stattfindet. Windows verarbeitet symbolische Verknüpfungen auf dem lokalen System, selbst wenn sie auf einen Speicherort auf einem Remotedateiserver verweisen. Verzeichnisverbindungen, die auf einen Remotedateiserver verweisen, werden von Windows auf dem Server selbst verarbeitet. Symbolische Verknüpfungen auf einem Server können daher auf Speicherorte verweisen, auf die nur von einem Client zugegriffen werden kann (beispielsweise auf andere Clientvolumes), während dies bei Verzeichnisverbindungen nicht möglich ist. Zur Lösung dieses Problems unterstützt Windows Vista den neuen symbolischen Verknüpfungstyp sowohl für Dateien als auch für Verzeichnisse.

Viele Dateisystembefehle wurden aktualisiert, um das Verständnis der Auswirkungen symbolischer Verknüpfungen zu gewährleisten. Der Delete-Befehl z. B. folgt Verknüpfungen nicht, da dies zur Löschung des Ziels führen würde, sondern löscht stattdessen die Verknüpfung. Da jedoch möglicherweise nicht alle Anwendungen symbolische Verknüpfungen richtig verarbeiten, wird zum Erstellen einer symbolischen Verknüpfung das neue Recht zum Erstellen symbolischer Verknüpfungen benötigt, über das standardmäßig nur Administratoren verfügen.

Sie können mit dem Mklink-Befehl eine symbolische Verknüpfung über eine Eingabeaufforderung erstellen. Der integrierte Verzeichnisbefehl der Eingabeaufforderung identifiziert eine symbolische Verknüpfung, indem er sie mit <SYMLINK> kennzeichnet und Ihnen das Ziel in Klammern anzeigt, wie in Abbildung 5 dargestellt. Windows-Explorer erkennt ebenfalls symbolische Verknüpfungen und zeigt sie mit dem Verknüpfungspfeil an. Sie können das Ziel einer Verknüpfung im Explorer anzeigen, indem Sie dem Browserfenster die Spalte „Linkziel“ hinzufügen.Überwachen der Prioritätserhöhung durch MMCSS

Sie können die Erhöhung der Threadpriorität verfolgen, die der MMCSS-Dienst auf Windows Media Player-Threads anwendet, indem Sie einen Video- oder Audioclip abspielen, den Systemmonitor ausführen, die Diagrammskala auf 31 festlegen (die höchste Threadpriorität in Windows) und den Zähler „Aktuelle Priorität“ für alle Instanzen der Threadobjekte von Windows Media Player (Wmplayer.exe) der Anzeige hinzufügen. Ein oder mehrere Threads werden mit der Priorität 21 ausgeführt.

Abbildung B** Erhöhung der Threadpriorität für Windows Media Player **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 5** Erstellen einer symbolischen Verknüpfung mit Mklink **(Klicken Sie zum Vergrößern auf das Bild)

Abschluss und Abbruch von E/A-Vorgängen

Es gibt eine Reihe von internen Änderungen am E/A-System, die die Leistung von Serveranwendungen verbessern können. Diese Anwendungen verwenden in der Regel ein als Abschlussport bezeichnetes Synchronisierungsobjekt, um auf den Abschluss von asynchronen E/A-Anforderungen zu warten. Vor Windows Vista führte bei Abschluss eines solchen E/A-Vorgangs der Thread, der die E/A-Anforderung gesendet hatte, die Aufgaben zum Abschluss des E/A-Vorgangs aus, wodurch ein Wechsel zu dem Prozess bewirkt wurde, zu dem der Thread gehörte, und alle anderen Vorgänge unterbrochen wurden. Dann aktualisierte das E/A-System den Status des Abschlussports, um einen Thread zu aktivieren, der auf die Änderung des Status wartete.

Bei Windows Vista wird der Abschluss von E/A-Vorgängen nicht unbedingt von dem Thread verarbeitet, der die E/A-Anforderung gesendet hat, sondern von dem Thread, der auf seine Aktivierung durch den Abschlussport wartet. Durch diese relativ kleine Änderung werden unnötige Threadplanung und überflüssige Kontextwechsel vermieden, die die Gesamtleistung der Anwendung und des Systems beeinträchtigen können. Zur weiteren Verbesserung der Leistung kann ein Server die Ergebnisse mehrerer E/A-Vorgänge beim Abschluss in einer Anforderung abrufen, wodurch Übergänge in den Kernelmodus vermieden werden.

Die wahrscheinlich offensichtlichste Änderung im E/A-System aus der Endbenutzerperspektive besteht in der Unterstützung des Abbruchs synchroner E/A-Vorgänge in Windows Vista. Falls Sie jemals mit Windows XP oder Windows Server® 2003 einen Net View-Befehl ausgeführt haben oder versucht haben, auf eine Freigabe auf einem im Offlinemodus befindlichen Remotesystem zuzugreifen, kennen Sie die Probleme mit E/A-Vorgängen, die nicht abgebrochen werden können: Der Befehls- oder Dateibrowser reagiert erst nach Ablauf eines Netzwerktimeouts. Eine Anwendung kann nur warten, bis der Vorgang fehlschlägt, da sie dem Gerätetreiber, der den E/A-Vorgang ausführt, nicht mitteilen kann, dass der E/A-Vorgang nicht mehr erforderlich ist.

In Windows Vista können die meisten E/A-Vorgänge abgebrochen werden, einschließlich des E/A-Vorgangs zum Öffnen von Dateien, der von Net View und Explorer verwendet wird. Anwendungen müssen jedoch aktualisiert werden, damit sie auf Endbenutzeranforderungen zum Abbruch von E/A-Vorgängen reagieren. Viele Dienstprogramme von Windows Vista, die mit Geräten interagieren, für die Timeouts festgelegt sind, verfügen über die erforderliche Unterstützung. In den Dialogfeldern zum Öffnen und Speichern von Dateien, die in nahezu jeder Windows-Anwendung verwendet werden, einschließlich Anwendungen von Drittanbietern, ist jetzt die Schaltfläche „Abbrechen“ aktiviert, wenn versucht wird, den Inhalt eines Ordners anzuzeigen. Beim Net-Befehl werden ebenfalls die zugehörigen synchronen E/A-Vorgänge abgebrochen, wenn Sie STRG+C drücken.

Sie können sich von den Vorteilen des Abbruchs von E/A-Vorgängen überzeugen, indem Sie in Windows Vista eine Eingabeaufforderung öffnen und Folgendes eingeben:

net view (\\nonexistentmachine)

Der Befehl bleibt hängen, während Windows versucht, Kontakt zu dem nicht vorhandenen System aufzunehmen. Sie können ihn jedoch mit STRG+C beenden. In Windows XP hat STRG+C keine Wirkung, und der Befehl wird erst zurückgegeben, wenn beim Netzwerkvorgang ein Timeout auftritt.

Eine andere Art von E/A-Vorgängen, die Benutzer in früheren Versionen von Windows vor Probleme stellte, waren E/A-Vorgänge, die von Gerätetreibern nicht ordnungsgemäß abgebrochen wurden. Dies beruhte darauf, dass die Treiber nicht ohne weiteres feststellen konnten, ob der Vorgang abgebrochen werden sollte. Wenn Sie je einen Prozess beendet haben und dieser anschließend in Tools zum Anzeigen von Prozessen weiterhin aufgeführt wurde, haben Sie erlebt, dass ein Gerätetreiber nicht auf eine Beendigung eines Prozesses reagiert und vom Prozess gesendete E/A-Anforderungen abgebrochen hat, die noch nicht abgeschlossen worden waren. Windows kann die endgültige Prozessbereinigung erst dann durchführen, wenn alle E/A-Vorgänge des Prozesses beendet oder abgebrochen wurden. In Windows Vista können sich Gerätetreiber auf einfache Weise für die Benachrichtigung über die Beendigung von Prozessen registrieren. Daher entfallen die meisten Probleme mit Prozessen, die sich nicht beenden lassen.

E/A-Priorität

Obwohl Windows schon immer die Priorisierung der CPU-Nutzung unterstützt hat, fand das Konzept der E/A-Priorität keine Anwendung. Ohne E/A-Priorität können Hintergrundaktivitäten wie Suchindexerstellung, Virensuche und Datenträgerdefragmentierung das Reaktionsvermögen von Vordergrundvorgängen stark beeinträchtigen. Wenn ein Benutzer eine Anwendung startet oder ein Dokument öffnet, während ein anderer Prozess z. B. Datenträger-E/A-Vorgänge ausführt, treten Verzögerungen auf, da der Vordergrundtask auf den Datenträgerzugriff wartet. Die gleiche Beeinträchtigung betrifft die Streamingwiedergabe von Multimediainhalten wie Musiktiteln von einer Festplatte.

Mit Windows Vista werden zwei neue Arten der E/A-Priorisierung eingeführt, damit E/A-Vordergrundvorgänge den Vorzug erhalten: Priorität für einzelne E/A-Vorgänge und für E/A-Bandbreitenreservierungen. Das E/A-System von Windows Vista umfasst interne Unterstützung für fünf E/A-Prioritäten, wie in Abbildung 6 dargestellt. Es werden jedoch nur vier Prioritäten verwendet (zukünftige Versionen von Windows könnten „Hoch“ unterstützen).

Figure 6 E/A-Prioritäten von Windows Vista

E/A-Vorgänge haben standardmäßig die Priorität „Mittel“. Der Memory Manager verwendet „Kritisch“, wenn er in Situationen mit niedriger Arbeitsspeicherkapazität geänderte Speicherdaten auf die Festplatte schreiben muss, um im Arbeitsspeicher Platz für andere Daten und Code zu schaffen. Der Windows-Taskplaner legt die E/A-Priorität für Tasks mit der Standardtaskpriorität auf „Niedrig“ fest. Die Priorität, die von für Windows Vista entwickelten Anwendungen vorgegeben wird, die die Hintergrundverarbeitung durchführen, ist „Sehr niedrig“. Für alle Hintergrundvorgänge von Windows Vista, einschließlich Windows Defender-Scanvorgängen und Desktopsuchindexerstellung, wird die E/A-Priorität „Sehr niedrig“ verwendet.Anzeigen sehr niedriger E/A-Priorität

Process Monitor, ein Dienstprogramm von Sysinternals zur Dateisystem- und Registrierungsüberwachung in Echtzeit, sammelt ausführliche Informationen für Lese-und Schreibvorgänge im Dateisystem, einschließlich ihrer E/A-Prioritäten unter Windows Vista. Die hervorgehobene Zeile zeigt ein Beispiel für eine E/A-Anforderung mit sehr niedriger Priorität, die von SuperFetch gesendet wurde (worauf ich in meinem nächsten Artikel eingehen werde).

Abbildung C** Anzeigen sehr niedriger E/A-Priorität in Process Monitor **(Klicken Sie zum Vergrößern auf das Bild)

Der Systemspeicherklassen-Gerätetreiber (%SystemRoot%\System32\Classpnp.sys) erzwingt die E/A-Prioritäten, sodass sie automatisch für an die meisten Speichergeräte gesendete E/A-Anforderungen gelten. Die Klassentreiber und anderen Speichertreiber fügen E/A-Anforderungen mit der Priorität „Mittel“ vor denen mit der Priorität „Niedrig“ und „Sehr niedrig“ in ihre Warteschlangen ein. Sie senden jedoch pro Sekunde mindestens eine wartende E/A-Anforderungen mit der Priorität „Niedrig“ oder „Sehr niedrig“, damit die Hintergrundprozesse Fortschritte machen können. Das Lesen von Daten mit sehr niedriger E/A-Priorität führt zudem dazu, dass der Cache-Manager Änderungen sofort auf die Festplatte schreibt, statt diesen Vorgang auf später zu verschieben. Darüber hinaus wird seine Vorausleselogik für Lesevorgänge umgangen, die andernfalls vorausschauend aus der Datei lesen würde, auf die gerade zugegriffen wird. Ein Beispiel für sehr niedrige E/A-Priorität unter Verwendung des Dienstprogramms „Process Monitor“ finden Sie in der Randleiste „Anzeigen sehr niedriger E/A-Priorität“.

Die Unterstützung der Reservierung von Bandbreite in Windows Vista ist für Anwendungen zur Medienwiedergabe nützlich. Die Bandbreitenreservierung wird von Windows Media Player in Verbindung mit der Prioritätserhöhung durch MMCSS zur Gewährleistung der nahezu fehlerfreien Wiedergabe lokaler Inhalte verwendet. Eine Anwendung zur Medienwiedergabe fordert das E/A-System auf, ihr zu garantieren, dass sie Daten mit einer bestimmten Geschwindigkeit lesen kann. Wenn das Gerät Daten mit der angeforderten Geschwindigkeit liefern kann und die vorhandenen Reservierungen es gestatten, teilt es der Anwendung mit, wie schnell sie E/A-Anforderungen senden sollte und wie groß diese sein sollten. Das E/A-System bearbeitet andere E/A-Anforderungen nur dann, wenn es die Anforderungen von Anwendungen erfüllen kann, die Reservierungen für das Zielspeichergerät vorgenommen haben.

Die letzte erwähnenswerte Änderung im E/A-System bezieht sich auf die Größe von E/A-Vorgängen. Seit der ersten Version von Windows NT wurde die Menge der von einer einzelnen Speicher-E/A-Anforderung verarbeiteten Daten vom Memory Manager und E/A-System auf 64 KB begrenzt. Selbst wenn eine Anwendung eine viel größere E/A-Anforderung sendet, wird diese in einzelne Anforderungen mit einer maximalen Größe von 64 KB aufgeteilt. Bei jedem E/A-Vorgang entsteht ein Mehraufwand für Übergänge in den Kernelmodus und das Einleiten einer E/A-Übertragung auf dem Speichergerät. Daher wird in Windows Vista die Größe von Speicher-E/A-Anforderungen nicht mehr begrenzt. Mehrere Benutzermoduskomponenten von Windows Vista wurden geändert, um die Unterstützung für größere E/A-Anforderungen zu nutzen, einschließlich der Kopierfunktionalität von Explorer und des Copy-Befehls der Eingabeaufforderung, die jetzt E/A-Anforderungen mit einer Größe von 1 MB senden.

Ausblick

Sie haben jetzt zwei Bereiche kennen gelernt, in denen der Windows Vista-Kernel verbessert wurde. Sie können weitere detaillierte Informationen in der nächsten Ausgabe meines Buchs Windows Internals erwarten (gemeinsam mit David Solomon verfasst), dessen Veröffentlichung für den gleichen Zeitpunkt wie die nächste Version von Windows Server mit dem Codenamen „Longhorn“ geplant ist. In meinem nächsten Artikel werde ich Ihnen weitere Einblicke in den neuen Kernel geben, indem ich auf die Speicherverwaltung und das Starten und Herunterfahren des Systems eingehe.

Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von „Microsoft Windows Internals“ (Microsoft Press, 2004) und hält häufig Vorträge auf IT- und Entwicklerkonferenzen. Er wechselte bei der kürzlichen Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er die Dienstprogramme „Process Explorer“, „Filemon“ und „Regmon“ veröffentlichte.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.