VMM

Стиль этой статьи неэнциклопедичен или нарушает нормы русского языка. Статью следует исправить согласно стилистическим правилам Википедии.

VMM (англ. Virtual Machine Manager) — ядро операционной системы Windows версий 2.1/386, 3.x, 95, 98 и Me.

Находилось в файлах WIN386.EXE (до Windows 95) или VMM32.VXD (Windows 95 и выше).

История

Первоначально был разработан как менеджер виртуальных машин MS-DOS (с использованием режима V86 процессоров от 386 и выше).

Версии Windows до 95 поддерживали процессоры, более старые, чем 386. В этом случае VMM не использовался никак, вместо него загружался DPMI-хост dosx.exe. В таком режиме любое запущенное приложение MS-DOS немедленно останавливало исполнение (и иногда отгружало на диск) вообще всех остальных приложений в ОС, передать им управление можно было только кнопкой переключения задач. Также не поддерживалось исполнение MS-DOS приложений в окне (только на полном экране, посколько исполнение в окне программ MS-DOS, как правило напрямую обращающихся к видеоконтроллеру, требует полной эмуляции аппаратуры видеоконтроллера).

В Windows 2.1 появилась версия Windows/386, включавшая в себя VMM с целью поддержки многозадачного исполнения нескольких приложений MS-DOS и их исполнения в окнах.

Версии 3.x «на выбор» могли загружать VMM (так называемый «расширенный режим 386»), или же — особенно при исполнении на процессоре, более старом, чем 386 — dosx.exe (так называемый «стандартный режим»).

Windows 95 (и более новые) не поддерживала процессоры младше 386, и VMM был единственным ядром ОС.

Архитектура

32разрядное, никак не совместимое с процессорами младше 386, ядро операционной системы.

Поддерживало страничную виртуальную память с использованием таблиц страниц и прерывания page fault (появилось в 386).

Поддерживало вытесняющую многозадачность между процессами («виртуальными машинами», ибо первоначально каждый процесс был экземпляром виртуальной машины DOS, кроме того, в одном из процессов VMM выполнялись все приложения Windows).

Внутри себя ядро не использовало вытесняющую многозадачность (примерно так же, как ранние версии Linux и многие иные UNIX, особенно старые).

Реализовано на ассемблере, который также предлагался и как язык разработки дополнительных модулей (так называемые VxD). Написание VxD на C требовало массивных оберток.

Обеспечивало ряд функций для VxD:

• богатый набор функций по работе со страничной памятью, в том числе возможность отобразить принадлежащий VxD блок памяти в адресное пространство виртуальной машины DOS (эмуляция видеопамяти и так далее).
• низкоуровневые примитивы синхронизации — ожидание/пробуждение, нечто вроде condvar
• установка перехватов на обращения к портам — при исполнении машинных команд IN/OUT в виртуальной машине управление передавалось в определенную процедуру одного из VxD.
• установка точек останова — при попадании исполнения в виртуальной машине на точку останова управление передавалось в определенную процедуру одного из VxD.

Многозадачность и 16-битные приложения

Сам VMM поддерживал вытесняющую многозадачность, хотя и не внутри самого себя.

Тем не менее Win16 API имел с этим серьёзные проблемы, полагаясь на разделяемую между задачами память. Кроме того, подсистемы GDI (двумерная графика) и USER (пользовательский интерфейс, менеджер окон) не были thread-safe. Это связано с тем, что данные подсистемы были разработаны до VMM для процессоров старше 386.

Проблемы были настолько серьёзны, что не были решены до перехода на Win32, который полностью thread-safe и не полагается внутри себя, по крайней мере вне режима ядра, на разделяемую память (хотя и поддерживает её для приложений, того желающих).

Таким образом, ни в одной версии Windows не было и нет вытесняющей многозадачности между приложениями Win16. Даже в Windows NT такие приложения все исполняются в одном общем процессе NTVDM.EXE.

Что же касается Windows, основанных на VMM, то в них навсегда остались 16битные подсистемы USER и GDI, которые вдобавок не thread-safe. 32битные приложения захватывали мьютекс Win16Lock в прологе любого вызова этих подсистем, а при исполнении 16битных приложений этот объект был захвачен на все время их исполнения (до отдачи процессора 32битному приложению, которое вдобавок останавливалось в ожидании на этом объекте до тех пор, пока 16битное приложение не осуществляло явную передачу процессора).

Это приводило к слабости реализации многозадачности в основанных на VMM Windows — никакие обращения к менеджеру окон и графики не могли исполняться (с зависанием машины), если 16битное приложение зациклилось или же находилось в ожидании в процессе чтения файла с сети, данных из сокета и так далее.

Настоящая вытесняющая многозадачность в VMM была только между виртуальными машинами MS-DOS, которые по очевидным причинам не знали о USER и GDI и никогда туда не обращались.

VxD и «настоящие» драйвера устройств

Обычно задачей драйвера режима ядра является полная реализация всех операций с устройством. Также обычно в ядро ОС включают модули, аналогичные драйверам, но реализующие то, что требует глобальных на всю машину данных и таблиц — TCP/IP стек, файловые системы. Также включают и те модули, которые работают в плотной связке со всем перечисленным выше (фильтры сетевых пакетов, общие полиморфные части некоторых архитектур, таких, как сокеты и т. д.).

VMM всегда разрабатывался как надстройка над MS-DOS, и первоначально использовал реализацию файловой системы FAT оттуда. Что касается устройств, то приложения DOS обычно содержали в себе весь код для работы со «своими» устройствами, и VMM потому первоначально также не включал в себя и драйверы устройств.

Задачей VxD первоначально было не обслуживание устройств как таковых, а сериализация представления устройства между несколькими виртуальными машинами MS-DOS. Задачей виртуального драйвера видеоадаптера (тоже VxD) также являлась полная эмуляция такового адаптера для виртуальных машин, на данный момент невидимых или изображаемых в окне.

В Windows 3.1 впервые появился VxD, полностью реализующий работу с устройством — WDCTRL для PC/AT-контроллера жесткого диска (то, что впоследствии стало стандартным IDE контроллером). Возможность была показана в интерфейсе пользователя как «32битный доступ к диску», и заключалась в полном исполнении прерываний int 13h внутри WDCTRL, который для этого сам обращался к аппаратуре, не используя BIOS и тамошний обработчик int 13h.

Выигрыш от этого был в том, что обработчик в BIOS не более чем крутится в цикле опроса все то время, пока диск отрабатывает команду, делая почти невозможным занять процессор в это время исполнением чего-то ещё.

Использование WDCTRL позволяло исполнять какой-то код в то время, пока диск отрабатывает операции, а также вести работу с файлом подкачки страниц в фоновом режиме. Это сильно повышало производительность.

Начиная с WDCTRL, VxD начали приобретать функции настоящих драйверов устройств, а VMM (хотя и по-прежнему основанный на DOS) — функции настоящего ядра ОС.

Далее в Windows for Workgroups в виде VxD был реализован весь стек протокола SMB/CIFS (с транспортным уровнем — только NetBEUI), как клиент, так и сервер, кроме самого нижнего уровня — драйвера сетевой карты, последний использовался тот же, что в MS LAN Manager Client для DOS, и загружался вместе с ядром DOS путем указания в файле config.sys.

Так как SMB клиент логически является файловой системой, появился и VxD под названием IFSMGR, распределяющий системные вызовы MS-DOS по работе с файлами (int 21h) между другими VxD, а в крайнем случае — отправляющий их в ядро DOS (того DOS, из которого загружен VMM).

В Windows 3.11 в виде VxD была реализована уже файловая система FAT (32bit File Access, улучшала производительность из-за использования страниц виртуальной памяти, а не крошечных буферов ядра DOS, под кэш). Кроме того, в этой ОС появилась возможность исполнения драйверов сетевых карт в виде VxD.

Windows 95 и позже

Технология Plug and Play в Windows 95 была полностью реализована в виде VxD, главнейший из них — CONFIGMG.VXD.

Все драйверы устройств, участвующие в ней, были обязаны либо сами быть VxD, либо же иметь второй драйвер — загрузчик, знающий о первом и являющийся VxD. Второе было использовано для сред совместимости NDIS и SCSIPORT, поддерживающих загрузку драйверов сетевых карт и контроллеров устройств массовой памяти от Windows NT без изменений (даже несмотря на то, что драйверы Windows NT имели иной формат файла — тот же, что и приложения Win32).

Также в виде VxD был реализован весь стек работы с CD/DVD приводом (в том числе файловая система CDFS/Joliet), как и TCP/IP стек.

Таким образом, VMM стал уже практически полностью самодостаточным ядром ОС, что позволило Microsoft сделать маркетинговое заявление о том, что «Windows 95 более не использует MS-DOS». Заявление было абсолютной неправдой. Во-первых, исследователи (Эндрю Шульман) быстро доказали, что VMM по-прежнему обращается к нижележащему DOS для операций вроде «получить текущее время». Во-вторых, в самой ОС была возможность сделать загрузочную дискету MS-DOS, при этом использовалось то же ядро DOS, что и для загрузки VMM основной ОС.

В Windows 98 была реализована идея WDM — одинаковых драйверов для Windows 9x и Windows NT нового поколения. Для реализации идеи в модель драйверов Windows NT добавили поддержку PnP и управления питанием (реализовано на 2 года позже Windows 98, в Windows 2000), после чего полученную модель упростили, убрав из неё некие старые вызовы времен NT 3.x, и перенесли в среду VMM.

VxD под названием NTKERN являлся оберткой вокруг VMM, реализующей WDM, и умеющей загружать драйверы в формате Windows NT. Например, вызов Windows NT IoInvalidateDeviceRelations (появился только в WDM, часть поддержки PnP) реализовывался через CM_Reenumerate_Devnode в CONFIGMG, и так далее.

Это позволило легко реализовать поддержку шин USB и 1394 сразу в обеих версиях Windows — все эти драйверы были реализованы в WDM. Более того, эти .sys файлы из бета-версий Windows 2000 нормально работали в Windows 98.

В те времена была разница «драйвер WDM» и «драйвер Windows NT», последний мог использовать немного более богатый набор вызовов, не реализованных в NTKERN.

С умиранием основанных на VMM Windows умерла и эта разница, ныне WDM есть не более чем API ядра Windows для разработки драйверов аппаратуры (в противовес фильтрам сетевых пакетов, файловым системам и т. д. — такие драйвера всегда отличались коренным образом в Windows 9.x и в Windows NT).

Сравнение с настоящими виртуальными машинами

«Настоящие» виртуальные машины, появившиеся ещё в IBM 360, а ныне реализованные в Xen, Virtual PC, VMWare Workstation, ESX Server, Hyper-V и других продуктах, отличаются от тех виртуальных машин DOS, что были реализованы в VMM.

Например, они позволяют загрузить в «госте» почти любую ОС и почти любую её версию, а также полностью перезагрузить с нуля «гостя». Для этого там эмулируется абсолютно вся аппаратура, а также BIOS.

Виртуальные машины VMM были куда слабее по возможностям. Их нельзя было перегрузить, только уничтожить экземпляр и создать новый. В них не могло работать ничего, кроме MS-DOS и её приложений, при этом версия DOS была та же, что «основная» DOS на машине.

Термин sandbox («песочница») подходит к ним куда лучше.

Тем не менее, виртуальные машины VMM использовали поддержку от процессора — режим V86 — и работали крайне быстро. Настоящие же виртуальные машины требуют для своей работы либо трюков вроде virtual TLB, что приводят к гигантскому количеству «проваливаний» в гипервизор по отказу страницы и работает медленно (некоторые гипервизоры просто переключаются в режим покомандной интерпретации кода «гостя» в некоторых случаях, особенно при работе с видеоадаптером), либо же поддержку многоуровневых таблиц страниц уже в самом процессоре (Wanderpool), которая появилась не ранее примерно 2003 года.

Адекватная производительность настоящих виртуальных машин была достигнута только в поколении Pentium III, виртуальные же машины VMM прекрасно работали и на 386.

Критика

Отсутствие многозадачности между 16-битными приложениями Windows, вместе с использованием 16-битной подсистемы графики и пользовательского интерфейса во всех основанных на VMM Windows, а также отсутствие защиты памяти между такими приложениями, приводило к низкой надежности всех этих версий Windows.

Это вряд ли упрек в адрес VMM, скорее в адрес Win16 API и упомянутых подсистем, но тем не менее это давало мощные основания противникам Microsoft (из мира UNIX) говорить об отсутствии настоящей многозадачности в Windows.

Такое мнение распространялось даже на Windows NT, где оно есть несомненный миф, поддерживаемый разве что крайне слабой реализацией вызова fork() в пакете Cygwin, позволяющем перенос ПО из UNIX под Windows NT. Реализация fork() в Cygwin копирует всё адресное пространство, в основном из-за поддержки основанных на VMM Windows — VMM никогда не имел fork(), в отличие от ядра Windows NT (NtCreateProcess при SectionHandle == NULL), последнее использовалось в POSIX подсистеме Windows и её потомках Interix и Services for UNIX.

Windows NT по ряду возможностей — хорошая для своего времени поддержка многопроцессорных машин и наличие вытесняющей многозадачности даже внутри ядра — превосходила многие UNIX, такие, как ранние Linux и FreeBSD, в вопросе многозадачности. Впрочем, в мире Linux есть серьёзное мнение, что вытесняющая многозадачность внутри ядра не нужна.

Для улучшения этой статьи желательно?: Викифицировать статью. Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное. Исправить статью согласно стилистическим правилам Википедии.