Aktualizace: 31.10.2008
Autor: Michal "Mitch" Pavlík
Power Management
Mnoho uživatelů notebooků očekává, že po sklopení displeje jejich notebook přejde do stavu hibernace, ale v některých případech
k tomu nedošlo. Hlavním důvodem bylo to, že systém k přechodu vyžadoval souhlas aplikací a ovladačů. Stačil tak jeden chybný
ovladadač nebo neodpovídající aplikace a systém nemohl přejít do jiného režimu.
Power Manager ve Windows Vista stále informuje ovladače a aplikace o změnách napájecího režimu, ale nevyžaduje jejich souhlas.
Na odpověď od aplikace se čeká maximálně 20 sekund (ve starších verzích Windows to byly 2 minuty). Ve výsledku si tak uživatelé
mohou být jisti, že se jejich notebook dostane do požadovanho režimu.
Kernel Transaction Manager
Jedna z nejhorších věcí při vývoji softwaru je oštření chyb, které mohou nastat. Zvláště když se vyžaduje provedení několika
operací a aplikace vykoná jen část z nich. Například aplikace provádějící update zapisuje informace do registru a přepisuje
soubory novými verzemi. Může se stát, že tato aplikace zapíše do registru, nahradí několik souborů a u dalšího v řadě mu systém
odmítne přístup. Pokud nechce aplikace nechat update nekonzistentní, musí vrátit veškeré změny. Testování návratového mechanismu
je náročné a tak se většinou jeho implementace přeskakuje.
Aplikace psané pro Windows Vista získávají automaticky schopnost návratu a to pomocí Kernel Transaction Manager-a (KTM), který
využívá podporu transakcí v NTFS a registrech. Když chce aplikace provést několik operací, může buď vytvořit Distributed
Transaction Coordinator (DTC) a potom handle KTM, nebo vytvořit handle KTM přímo a asociovat změny souborů nebo registru s
transakcí. Pokud se všechny operace zdaří, aplikace spustí transakci a změny se provedou, ale aplikace může kdykoliv transakci
zrušit a dostat systém do původnho stavu.
Výhoda je také v tom, že ostatní aplikace nevidí změny dokud neproběhne samotná transakce, takže aplikace využívající DTC mohou
koordinovat svoje transakce s SQL Server-em, Microsoft Message Queue Server-em (MSMQ) nebo jinými databázemi. Updatovací
služba tak už nikdy nenechá nekonzistentní update. Transakce využívají například Windows Update a System Restore.
KTM umožňuje transakčním resource manager-ům (správci zdrojů) jako je NTFS nebo registr, aby koordinovaly aktualizace pro
určitou sadu změn, které chce aplikace provést. NTFS používá transakční rozšíření zvané TxF a registr pak TxR. Tito správci
pracující v kernel-mode spolupracují s KTM na koordinaci transakcí, stejně jako správci používají DTC na koordinaci mezi sebou
v user-mode vrstvě. Vývojáři třetích stran tak mohou využít KTM při implmenetaci vlastních správců zdrojů.
TxF a TxR přinášejí novou sadu API funkcí pro práci s transakcemi souborového systému a registru. Pokud chce aplikace vytvořit
soubor a využít přitom transakcí, použije nejprve KTM k vytvoření transakce a pak projde její výsledky.
Systém transakcí spoléhá na Common Log File System (CLFS, %SystemRoot%\System32\Clfs.sys), který byl uveden ve Windows Server
2003 R2 a zaznamenává operace souborového systému. TxF a TxR používají CLFS k trvalému ukládání stavu transakce před tím, než bude
provedena a to jim umožní vrátit změny v souborovém systému nebo registru, pokud například během vykonávání skupiny operací vypadne
proud. TxR navíc může pomocí záznamů z CLFS vytvořit skupinu souborů, ve kterých jsou uložené informace o transakcích registru.
Tyto soubory jsou uložené v %Systemroot%\System32\Config\Txr a každý soubor je pro určitý registry hive (primární klíč s názvem
začínajícím na HKEY). TxF tyto data ukládá pro každý disk zvlášť do skrytých složek \$Extend\$RmMetadata.
Obrázek 1 - Výpis adresáře s logovacími soubory
Mitch