VMM ( angl. Virtual Machine Manager Virtual Machine Manager ) 1. správce virtuálních strojů ( hypervizor ) subsystému Windows 95, který zajišťuje dynamickou alokaci paměti, plánování úloh, funkce DPMI serveru , dynamické načítání, práci s virtuálními stroji MS-DOS (vytváření , spouštění, řízení a ukončení práce, poskytuje služby pro správu paměti, procesů, obsluhu přerušení, ochranu). Hypervizor byl obsažen v souboru WIN386.EXE (před vydáním Windows 95 ) a ve VMM32.VXD (pro operační systémy ( Windows 9x ) spolu s ovladači VxD nainstalovanými v systému. [1] 2. Správce virtuální paměti - správce virtuální paměti umožňuje operačnímu systému (například Windows 2000) používat paměť pevného disku jako součást RAM. Řídí proces výměny stránek z disku do RAM a naopak (viz také swap , virtuální paměť ).
Zpočátku byl správce virtuálních strojů MS-DOS vyvinut (pomocí režimu V86 procesorů od 386 a vyšších) ve virtuálním režimu procesoru X86 .
Dříve Windows 2.1 představil verzi Windows/386, která obsahovala správce virtuálních strojů pro podporu multitaskingu a spouštění více aplikací MS-DOS.
Hypervizor VMM podporoval preemptivní multitasking mezi procesy (virtuální stroje, protože každý proces byl původně instancí virtuálního stroje DOS, navíc všechny aplikace Windows běžely v jednom z procesů VMM).
Interně hypervizor VMM nepoužíval preemptivní multitasking (podobně jako rané verze Linuxu a dalších UNIXových systémů, zvláště raných).
Hypervizor VMM je implementován v assembleru, který byl nabízen i jako jazyk pro vývoj přídavných modulů (tzv. VxD). Zápis modulů VxD v C vyžadoval četné obaly.
Poskytuje řadu funkcí pro moduly VxD :
Samotný VMM podporoval preemptivní multitasking, i když ne v sobě.
Win16 API s tím ale mělo vážné problémy, spoléhalo na sdílenou paměť mezi úkoly. Také podsystémy GDI (2D grafika) a USER (uživatelské rozhraní, správce oken) nebyly bezpečné pro vlákna. To je způsobeno skutečností, že tyto subsystémy byly vyvinuty před VMM pro procesory starší než Intel 386.
Problémy byly tak vážné, že nebyly vyřešeny až do přechodu na Win32 , který je zcela bezpečný pro vlákna a nespoléhá interně, alespoň mimo režim jádra, na sdílenou paměť (ačkoli ji podporuje pro aplikace, které chtějí na).
Žádná verze Windows tedy nemá a nemá preemptivní multitasking mezi aplikacemi Win16. I ve Windows NT všechny tyto aplikace běží ve stejném sdíleném procesu NTVDM.EXE.
Co se týče Windows, tak ty mají navždy 16bitové USER a GDI subsystémy, které navíc nejsou bezpečné pro vlákna. 32bitové aplikace zachytily mutex Win16Lock v prologu libovolného volání těchto subsystémů a při spouštění 16bitových aplikací byl tento objekt zachycen po celou dobu jejich provádění (dokud nebyl procesor předán 32bitové aplikaci, který navíc na tomto objektu přestal čekat, až šestnáctibitová aplikace explicitně nepřenese procesor).
To vedlo ke slabosti implementace multitaskingu ve Windows založených na VMM – nebylo možné provést žádná volání správce oken a grafiky (se zamrznutím počítače), pokud šestnáctibitová aplikace cyklovala nebo čekala při čtení souboru ze sítě. , data ze zásuvky a tak dále.
Skutečný preemptivní multitasking ve VMM byl pouze mezi virtuálními stroji MS-DOS, které z pochopitelných důvodů nevěděly o USER a GDI a nikdy k nim nepřistupovaly.
Úkolem ovladače v režimu jádra je obvykle plně implementovat všechny operace zařízení. Obvykle jsou také moduly podobné ovladačům součástí jádra OS, ale implementují to, co vyžaduje globální data a tabulky pro celý stroj - zásobník TCP/IP, souborové systémy. Zahrnuty jsou také ty moduly, které úzce spolupracují se vším výše uvedeným (filtry síťových paketů, běžné polymorfní části některých architektur, jako jsou zásuvky atd.).
VMM byl vždy vyvíjen jako doplněk k MS-DOS. Pokud jde o zařízení, DOSové aplikace většinou obsahovaly veškerý kód pro práci se „svými“ zařízeními a VMM tedy původně neobsahovaly ani ovladače zařízení.
Účelem VxD nebylo původně sloužit zařízením jako takovým, ale serializovat reprezentaci zařízení mezi více virtuálními stroji MS-DOS. Úkolem ovladače virtuálního grafického adaptéru (též VxD) byla také kompletní emulace takového adaptéru pro virtuální stroje, které jsou aktuálně neviditelné nebo zobrazené v okně.
Ve Windows 3.1 se poprvé objevil modul VxD, který plně implementoval práci se zařízením - WDCTRL pro řadič pevného disku PC / AT (který se později stal standardním řadičem IDE). Tato funkce byla zobrazena v uživatelském rozhraní jako „32bitový přístup k disku“ a spočívala v plném provedení přerušení int 13h uvnitř WDCTRL, které za tímto účelem samo přistupovalo k hardwaru, bez použití BIOSu a jeho obsluhy int 13h.
Výhodou toho bylo, že obslužná rutina v BIOSu nebyla ničím jiným než otáčením v cyklu dotazování, zatímco disk zpracovával příkaz, takže bylo téměř nemožné zaneprázdnit procesor v tu chvíli něčím jiným.
Použití WDCTRL umožnilo spuštění některého kódu, zatímco disk zpracovával operace, a také práci se stránkovacím souborem na pozadí. Tím se výrazně zlepšil výkon.
Počínaje WDCTRL začal VxD přebírat funkce skutečných ovladačů zařízení a VMM (byť stále založený na DOSu) převzal funkce skutečného jádra OS.
Dále ve Windows for Workgroups byl celý zásobník protokolů SMB / CIFS implementován ve formě VxD (s transportní vrstvou - pouze NetBEUI ), klient i server, s výjimkou nejnižší úrovně - ovladače síťové karty, posledně jmenovaný byl použit stejně jako klient MS LAN Manager pro DOS a byl načten s jádrem DOS zadáním v souboru config.sys.
Vzhledem k tomu, že klient SMB je logicky souborový systém, objevil se i VxD s názvem IFSMGR, který distribuoval systémová volání MS-DOS pro práci se soubory (int 21h) mezi ostatní VxD a v extrémních případech je posílal do jádra DOSu (ten DOS od který VMM je načten).
Ve Windows 3.11 byl již systém souborů FAT (32bitový přístup k souborům, zlepšený výkon díky použití stránek virtuální paměti, spíše než malých vyrovnávacích pamětí jádra DOSu, pro mezipaměť) implementován ve formě VxD. Kromě toho má tento OS schopnost spouštět ovladače síťových karet ve formě modulů VxD .
Technologie Plug and Play ve Windows 95 byla plně implementována ve formě modulů VxD , z nichž nejdůležitější je CONFIGMG.VXD.
Všechny ovladače zařízení, které se na něm podílely, musely být buď samy typu VxD, nebo měly druhý ovladač - zavaděč, který ví o prvním a je VxD. Druhý byl použit pro prostředí kompatibility NDIS a SCSIPORT, která podporují načítání ovladačů síťových karet a řadičů velkokapacitních paměťových zařízení ze systému Windows NT bez úprav (i když ovladače systému Windows NT měly jiný formát souboru - stejný jako aplikace Win32).
Také ve formě VxD byl implementován celý zásobník pro práci s jednotkou CD / DVD (včetně souborového systému CDFS / Joliet) a také zásobník TCP / IP.
Takže použití Virtual Machine Manager v rámci Windows 95 umožnilo Microsoftu učinit marketingové tvrzení, že „Windows 95 již nepoužívá MS-DOS“, což bylo zcela nepravdivé. Za prvé, výzkumníci (Andrew Shulman) rychle dokázali, že VMM stále volá základní DOS pro operace jako „získání aktuálního času“. Za druhé, samotný OS měl schopnost vytvořit zaváděcí disketu pro MS-DOS pomocí stejného jádra DOS, které bylo použito k zavedení VMM hlavního OS.
Windows 98 implementoval myšlenku stejných ovladačů pro Windows 9x a Windows NT příští generace - Windows Driver Model (WDM). Pro realizaci myšlenky byla do modelu ovladače Windows NT přidána podpora pro PnP a řízení spotřeby (implementováno o 2 roky později než Windows 98 ve Windows 2000), načež byl výsledný model zjednodušen odstraněním některých starých volání NT 3.x times z něj a přeneseny do prostředí VMM.
VxD s názvem NTKERN byl obal kolem VMM, který implementoval WDM a byl schopen načíst ovladače ve formátu Windows NT. Například volání Windows NT IoInvalidateDeviceRelations (objevilo se pouze ve WDM, součást podpory PnP) bylo implementováno prostřednictvím CM_Reenumerate_Devnode v CONFIGMG a tak dále.
To usnadnilo implementaci podpory pro USB a sběrnice 1394 v obou verzích Windows najednou – všechny tyto ovladače byly implementovány ve WDM. Navíc tyto soubory .sys z beta verzí systému Windows 2000 fungovaly v systému Windows 98 dobře.
V té době existovaly různé koncepty „ovladače WDM“ a „ovladače Windows NT“, který mohl používat o něco bohatší sadu volání, která nebyla implementována v NTKERN. Se „zánikem“ Windows na bázi VMM zmizelo i toto rozlišení, nyní WDM není nic jiného než API jádra Windows pro vývoj hardwarových ovladačů (na rozdíl od síťových paketových filtrů, souborových systémů atd. – takové ovladače byly vždy zásadně odlišné ve Windows 9 .xa ve Windows NT).
„Skutečné“ virtuální stroje, které se objevily v IBM 360 a jsou nyní implementovány v Xen , Virtual PC , VMWare Workstation, ESX Server , Hyper-V a dalších produktech, se liší od virtuálních strojů DOS, které byly implementovány ve VMM.
Umožňují vám například zavést téměř jakýkoli operační systém a téměř jakoukoli jeho verzi pomocí účtu hosta a také zcela restartovat relaci hosta. K tomu je zde emulován veškerý hardware a také základní vstupní/výstupní systém (BIOS).
Virtuální stroje VMM však využívaly podporu z procesoru – režim V86. Skutečné virtuální stroje ke své práci vyžadují buď triky, jako je virtuální TLB , které vedou k velkému počtu „pádů“ do hypervizoru při chybě stránky a jsou pomalé (některé hypervizory jednoduše přejdou na interpretaci „hosta“ příkazem za příkazem kód v některých případech, zejména při běhu s grafickým adaptérem), nebo podpora víceúrovňových tabulek stránek již v samotném procesoru ( Vanderpool ), která se objevila nejdříve kolem roku 2003.
Adekvátního výkonu skutečných virtuálních strojů bylo dosaženo pouze u generace Pentium III, zatímco virtuální stroje VMM fungovaly na i386 dobře.
Nedostatek multitaskingu mezi 16bitovými aplikacemi Windows spolu s použitím 16bitového grafického a uživatelského subsystému ve všech Windows založených na VMM a nedostatečná ochrana paměti mezi těmito aplikacemi vedly ke špatné spolehlivosti všech těchto verzí. systému Windows.
To sice není výtka VMM, spíše Win16 API a zmíněným subsystémům, přesto to dalo odpůrcům Microsoftu (ze světa UNIXu) pádné důvody mluvit o nedostatku opravdového multitaskingu ve Windows.
Tento názor se rozšířil i na Windows NT, kde jde o nepochybný mýtus, podporovaný pouze extrémně slabou implementací volání fork () v balíčku Cygwin , které umožňuje portovat software z UNIXu na Windows NT. Cygwinova implementace fork() kopíruje celý adresní prostor, hlavně kvůli podpoře Windows na bázi VMM – VMM nikdy neměl fork(), na rozdíl od jádra Windows NT (NtCreateProcess with SectionHandle == NULL), posledně jmenovaného používaného v POSIX subsystému Windows a jeho potomci Interix a Services for UNIX.
Windows NT v mnoha ohledech – dobré pro svou časovou podporu pro víceprocesorové stroje a preemptivní multitasking dokonce i v jádře – předčily mnoho UNIXů, jako raný Linux a FreeBSD, pokud jde o multitasking. Ve světě Linuxu však panuje silný názor, že preemptivní multitasking uvnitř jádra není potřeba.