VMM ( eng. Virtual Machine Manager Virtual Machine Manager ) 1. virtuell maskinhanterare ( hypervisor ) för Windows 95-delsystemet, som tillhandahåller dynamisk minnesallokering, uppgiftsschemaläggning, DPMI -serverfunktioner , dynamisk laddning, arbete med virtuella MS-DOS -maskiner (skapande , lansering, kontroll och avslutande av arbete, tillhandahåller tjänster för hantering av minne, processer, avbrottshantering, skydd). Hypervisorn fanns i filen WIN386.EXE (innan Windows 95 släpptes ) och i VMM32.VXD (för operativsystem ( Windows 9x ) tillsammans med VxD-drivrutinerna installerade på systemet. [1] 2. Virtual Memory Manager - den virtuell minneshanterare tillåter operativsystemet (till exempel Windows 2000) att använda hårddiskminne som en del av RAM. Styr processen att byta sidor från disk till RAM och vice versa (se även swap , virtuellt minne ).
Inledningsvis utvecklades MS-DOS virtuell maskinhanterare (med V86-läget för processorer från 386 och högre) i det virtuella läget för X86 -processorn .
Tidigare introducerade Windows 2.1 en version av Windows/386 som inkluderade en virtuell maskinhanterare för att stödja multitasking och exekvering av flera MS-DOS-applikationer.
VMM- hypervisorn stödde förebyggande multitasking mellan processer (virtuella maskiner, eftersom varje process ursprungligen var en instans av en virtuell DOS-maskin, dessutom kördes alla Windows-applikationer i en av VMM-processerna).
Internt använde inte VMM- hypervisorn förebyggande multitasking (ungefär som tidiga versioner av Linux och andra UNIX -system, särskilt tidiga).
VMM- hypervisorn är implementerad i assembler, som också erbjöds som ett språk för att utveckla ytterligare moduler (den så kallade VxD). Att skriva VxD-moduler i C krävde många omslag.
Tillhandahöll ett antal funktioner för VxD -moduler :
VMM själv stödde förebyggande multitasking, men inte inom sig själv.
Win16 API hade dock allvarliga problem med detta och förlitade sig på delat minne mellan uppgifterna. Dessutom var undersystemen GDI (2D-grafik) och USER (användargränssnitt, fönsterhanterare) inte trådsäkra. Detta beror på det faktum att dessa delsystem utvecklades före VMM för processorer äldre än Intel 386.
Problemen var så allvarliga att de inte löstes förrän flytten till Win32 , som är helt trådsäker och inte internt, åtminstone utanför kärnläget, förlitar sig på delat minne (även om det stöder det för applikationer som vill till).
Således har ingen version av Windows och har inte förebyggande multitasking mellan Win16-applikationer. Även på Windows NT körs alla dessa applikationer i samma delade NTVDM.EXE-process.
När det gäller Windows, baserat på VMM, har de för alltid 16-bitars USER- och GDI-undersystem, som dessutom inte är trådsäkra. 32-bitars applikationer fångade Win16Lock mutex i prologen av alla anrop till dessa undersystem, och när 16-bitars applikationer kördes, fångades detta objekt under hela varaktigheten av deras exekvering (tills processorn gavs till 32-bitars applikationen, som dessutom slutade vänta på detta objekt tills sextonbitarsapplikationen inte explicit överförde processorn).
Detta ledde till en svaghet i implementeringen av multitasking i VMM-baserade Windows - inga anrop till fönsterhanteraren och grafik kunde exekveras (med maskinen frysning) om sexton-bitarsapplikationen gick i loop eller väntade medan den läste en fil från nätverket , data från ett uttag och så vidare. .
Sann förebyggande multitasking i VMM var endast mellan virtuella MS-DOS-maskiner, som av uppenbara skäl inte kände till USER och GDI och aldrig fick tillgång till dem.
Det är vanligtvis en drivrutin i kärnläge att fullt ut implementera alla enhetsoperationer. Dessutom ingår vanligtvis moduler som liknar drivrutiner i OS-kärnan, men de implementerar det som kräver globala data och tabeller för hela maskinen - TCP / IP-stacken, filsystem. Dessutom ingår de moduler som fungerar i nära anslutning till allt som anges ovan (nätverkspaketfilter, vanliga polymorfa delar av vissa arkitekturer, såsom sockets, etc.).
VMM har alltid utvecklats som ett tillägg till MS-DOS. När det gäller enheter så innehöll DOS-applikationer vanligtvis all kod för att arbeta med "sina" enheter, och VMM inkluderade därför inte heller enhetsdrivrutiner från början.
Syftet med VxD var ursprungligen inte att betjäna enheter i sig, utan att serialisera en representation av en enhet mellan flera virtuella MS-DOS-maskiner. Uppgiften för drivrutinen för den virtuella videoadaptern (även VxD) var också den fullständiga emuleringen av en sådan adapter för virtuella maskiner som för närvarande är osynliga eller visas i fönstret.
I Windows 3.1 dök VxD-modulen upp för första gången, som fullt ut implementerade arbetet med enheten - WDCTRL för PC / AT-hårddiskkontrollern (det som senare blev standard IDE-kontrollern). Funktionen visades i användargränssnittet som "32-bitars diskåtkomst", och bestod i att fullständigt köra int 13h-avbrott inuti WDCTRL, som själv hade tillgång till hårdvaran för detta, utan att använda BIOS och dess int 13h-hanterare.
Fördelen med detta var att hanteraren i BIOS inte var något annat än att snurra i en avfrågningscykel medan disken bearbetade ett kommando, vilket gjorde det nästan omöjligt att hålla CPU:n sysselsatt med att göra något annat vid den tiden.
Genom att använda WDCTRL kunde viss kod exekveras medan disken bearbetades, samt arbetade med växlingsfilen i bakgrunden. Detta förbättrade prestandan avsevärt.
Från och med WDCTRL började VxD ta på sig funktionerna hos riktiga enhetsdrivrutiner, och VMM (om än fortfarande baserat på DOS) tog på sig funktionerna hos en riktig OS-kärna.
Vidare, i Windows for Workgroups, implementerades hela SMB / CIFS- protokollstacken i form av VxD (med ett transportlager - endast NetBEUI ), både klienten och servern, förutom den lägsta nivån - nätverkskortets drivrutin, sistnämnda användes på samma sätt som i MS LAN Manager Client för DOS, och laddades med DOS-kärnan genom att ange den i filen config.sys.
Eftersom SMB-klienten logiskt sett är ett filsystem, dök också en VxD kallad IFSMGR upp, som distribuerade MS-DOS-systemanrop för att arbeta med filer (int 21h) mellan andra VxD:er, och i extrema fall, skicka dem till DOS-kärnan (den DOS från vilken VMM är laddad).
I Windows 3.11 var FAT-filsystemet (32-bitars filåtkomst, förbättrad prestanda på grund av användningen av virtuella minnessidor, snarare än små DOS-kärnbuffertar, för cache) redan implementerat i form av VxD. Dessutom har detta operativsystem möjlighet att köra drivrutiner för nätverkskort i form av VxD -moduler .
Plug and Play -tekniken i Windows 95 implementerades fullt ut i form av VxD -moduler , varav den viktigaste är CONFIGMG.VXD.
Alla enhetsdrivrutiner som deltog i det var tvungna att antingen själva vara av typen VxD, eller också ha en andra drivrutin - en laddare som känner till den första och är VxD. Den andra användes för NDIS- och SCSIPORT-kompatibilitetsmiljöer som stöder inläsning av nätverkskortsdrivrutiner och styrenheter för masslagringsenheter från Windows NT utan ändringar (även om Windows NT-drivrutiner hade ett annat filformat - samma som Win32-applikationer).
Också i form av VxD implementerades hela stacken för att arbeta med en CD / DVD-enhet (inklusive filsystemet CDFS / Joliet), såväl som TCP / IP-stacken.
Användningen av Virtual Machine Manager inom ramen för Windows 95 gjorde det alltså möjligt för Microsoft att göra marknadsföringspåståendet att "Windows 95 inte längre använder MS-DOS", vilket var helt osant. Först bevisade forskarna (Andrew Shulman) snabbt att VMM fortfarande kallar den underliggande DOS för operationer som "get the current time". För det andra hade operativsystemet självt förmågan att göra en MS-DOS-startdiskett, med samma DOS-kärna som användes för att starta VMM för huvudoperativsystemet.
Windows 98 implementerade idén med samma drivrutiner för Windows 9x och Windows NT nästa generation - Windows Driver Model (WDM). För att implementera idén lades stöd för PnP och strömhantering till Windows NT-drivrutinsmodellen (implementerad 2 år senare än Windows 98, i Windows 2000), varefter den resulterande modellen förenklades genom att ta bort några gamla NT 3.x-anrop från den och överförs till miljön VMM.
En VxD kallad NTKERN var ett omslag runt VMM som implementerade WDM och kunde ladda drivrutiner i Windows NT-format. Till exempel implementerades Windows NT IoInvalidateDeviceRelations-anropet (endast i WDM, en del av PnP-stödet) via CM_Reenumerate_Devnode i CONFIGMG, och så vidare.
Detta gjorde det enkelt att implementera stöd för USB- och 1394 -bussar i båda versionerna av Windows samtidigt - alla dessa drivrutiner implementerades i WDM. Dessutom fungerade dessa .sys-filer från betaversioner av Windows 2000 bra i Windows 98.
På den tiden fanns det olika koncept för "WDM-drivrutin" och "Windows NT-drivrutin", den senare kunde använda en något rikare uppsättning anrop som inte implementerades i NTKERN. Med "utrotningen" av VMM-baserade Windows har även denna distinktion försvunnit, nu är WDM inget annat än ett Windows-kärn-API för att utveckla hårdvarudrivrutiner (till skillnad från nätverkspaketfilter, filsystem, etc. - sådana drivrutiner var alltid i grunden olika i Windows 9 .x och Windows NT).
De "riktiga" virtuella maskinerna som dök upp i IBM 360 och som nu är implementerade i Xen , Virtual PC , VMWare Workstation, ESX Server , Hyper-V och andra produkter skiljer sig från de virtuella DOS-maskiner som implementerades i VMM.
Till exempel låter de dig starta nästan alla operativsystem och nästan alla versioner av det med ett gästkonto, samt starta om gästsessionen helt. För att göra detta emuleras all hårdvara där, liksom det grundläggande in-/utgångssystemet (BIOS).
VMM virtuella maskiner använde dock stöd från processorn - V86-läge. Riktiga virtuella maskiner kräver antingen trick som virtuell TLB för sitt arbete , vilket leder till ett stort antal "fall" i hypervisorn på ett sidfel och är långsam (vissa hypervisorer byter helt enkelt till kommando-för-kommando tolkning av "gästen" kod i vissa fall, särskilt när du kör med en videoadapter), eller stöd för flernivåsidtabeller som redan finns i själva processorn ( Vanderpool ), som dök upp tidigast omkring 2003.
Adekvat prestanda för riktiga virtuella maskiner uppnåddes endast i Pentium III-generationen, medan virtuella VMM-maskiner fungerade bra på i386.
Bristen på multitasking mellan 16-bitars Windows-applikationer, tillsammans med användningen av 16-bitars grafik och användargränssnittsundersystem i alla VMM-baserade Windows, och avsaknaden av minnesskydd mellan sådana applikationer, resulterade i dålig tillförlitlighet i alla dessa versioner av Windows.
Detta är knappast en förebråelse för VMM, snarare mot Win16 API och de nämnda undersystemen, men det gav ändå starka skäl till Microsofts motståndare (från UNIX-världen) att tala om bristen på sann multitasking i Windows.
Denna åsikt sträckte sig till och med till Windows NT, där det är en otvivelaktig myt, som endast stöds av den extremt svaga implementeringen av gaffelanropet () i Cygwin -paketet , som tillåter portering av programvara från UNIX till Windows NT. Cygwins fork()-implementering kopierar hela adressutrymmet, främst på grund av stöd för VMM-baserade Windows - VMM hade aldrig fork(), till skillnad från Windows NT-kärnan (NtCreateProcess med SectionHandle == NULL), den senare används i POSIX-delsystemet Windows och dess ättlingar Interix och tjänster för UNIX.
Windows NT på ett antal sätt – bra för sitt tidsstöd för multiprocessormaskiner och förebyggande multitasking även inom kärnan – överträffade många UNIX, såsom tidiga Linux och FreeBSD, när det gäller multitasking. Det finns dock en stark åsikt i Linux-världen att förebyggande multitasking inuti kärnan inte behövs.