VMM ( ing. Virtual Machine Manager Virtual Machine Manager ) 1. administrador de máquinas virtuales ( hipervisor ) del subsistema de Windows 95, que proporciona asignación dinámica de memoria, programación de tareas, funciones de servidor DPMI , carga dinámica, trabajo con máquinas virtuales MS-DOS (creación , lanzamiento, control y terminación de obra, brinda servicios para la gestión de memoria, procesos, manejo de interrupciones, protección). El hipervisor estaba contenido en el archivo WIN386.EXE (antes del lanzamiento de Windows 95 ) y en VMM32.VXD (para sistemas operativos ( Windows 9x ) junto con los controladores VxD instalados en el sistema. [1] 2. Virtual Memory Manager: el El administrador de memoria virtual permite que el sistema operativo (por ejemplo, Windows 2000) use la memoria del disco duro como parte de la RAM. Controla el proceso de intercambio de páginas del disco a la RAM y viceversa (ver también intercambio , memoria virtual ).
Inicialmente, el administrador de máquinas virtuales de MS-DOS se desarrolló (usando el modo V86 de los procesadores de 386 y superiores) en el modo virtual del procesador X86 .
Anteriormente, Windows 2.1 introdujo una versión de Windows/386 que incluía un administrador de máquinas virtuales para admitir múltiples tareas y la ejecución de múltiples aplicaciones de MS-DOS.
El hipervisor VMM admitía la multitarea preventiva entre procesos (máquinas virtuales, ya que cada proceso era originalmente una instancia de una máquina virtual DOS, además, todas las aplicaciones de Windows se ejecutaban en uno de los procesos VMM).
Internamente, el hipervisor VMM no usaba la multitarea preventiva (al igual que las primeras versiones de Linux y otros sistemas UNIX , especialmente los primeros).
El hipervisor VMM se implementa en ensamblador, que también se ofreció como lenguaje para desarrollar módulos adicionales (los llamados VxD). Escribir módulos VxD en C requería numerosos contenedores.
Proporcionó una serie de funciones para los módulos VxD :
El propio VMM admitía la multitarea preventiva, aunque no dentro de sí mismo.
Sin embargo, la API de Win16 tuvo serios problemas con esto, ya que dependía de la memoria compartida entre tareas. Además, los subsistemas GDI (gráficos 2D) y USER (interfaz de usuario, administrador de ventanas) no eran seguros para subprocesos. Esto se debe a que estos subsistemas se desarrollaron antes de VMM para procesadores anteriores al Intel 386.
Los problemas eran tan graves que no se resolvieron hasta el cambio a Win32 , que es completamente seguro para subprocesos y no depende internamente, al menos fuera del modo kernel, de la memoria compartida (aunque la admite para aplicaciones que necesitan a).
Por lo tanto, ninguna versión de Windows tiene ni tiene multitarea preventiva entre aplicaciones Win16. Incluso en Windows NT, todas estas aplicaciones se ejecutan en el mismo proceso NTVDM.EXE compartido.
En cuanto a Windows, basado en VMM, siempre tienen subsistemas USER y GDI de 16 bits, que, además, no son seguros para subprocesos. Las aplicaciones de 32 bits capturaron el mutex Win16Lock en el prólogo de cualquier llamada a estos subsistemas, y al ejecutar aplicaciones de 16 bits, este objeto fue capturado durante toda su ejecución (hasta que se le dio el procesador a la aplicación de 32 bits, que, además, dejó de esperar en este objeto hasta que la aplicación de dieciséis bits no transfirió explícitamente el procesador).
Esto condujo a una debilidad en la implementación de multitarea en Windows basado en VMM: no se podían ejecutar llamadas al administrador de ventanas y gráficos (con la máquina congelada) si la aplicación de dieciséis bits estaba en bucle o esperando mientras lee un archivo de la red. , datos de un socket, etc.
La verdadera multitarea preventiva en VMM era solo entre máquinas virtuales de MS-DOS que, por razones obvias, no sabían acerca de USER y GDI y nunca accedieron a ellas.
Por lo general, el trabajo de un controlador en modo kernel es implementar completamente todas las operaciones del dispositivo. Además, por lo general, los módulos similares a los controladores se incluyen en el kernel del sistema operativo, pero implementan lo que requiere datos y tablas globales para toda la máquina: pila TCP / IP, sistemas de archivos. También se incluyen aquellos módulos que funcionan en conjunto con todo lo mencionado anteriormente (filtros de paquetes de red, partes polimórficas comunes de algunas arquitecturas, como sockets, etc.).
VMM siempre se ha desarrollado como complemento de MS-DOS. En lo que respecta a los dispositivos, las aplicaciones de DOS normalmente contenían todo el código para trabajar con "sus" dispositivos y, por lo tanto, VMM tampoco incluía originalmente los controladores de dispositivos.
El propósito de VxD originalmente no era servir dispositivos per se, sino serializar una representación de un dispositivo entre múltiples máquinas virtuales MS-DOS. La tarea del controlador del adaptador de video virtual (también VxD) también fue la emulación completa de dicho adaptador para máquinas virtuales que actualmente son invisibles o se muestran en la ventana.
En Windows 3.1, el módulo VxD apareció por primera vez, implementando completamente el trabajo con el dispositivo: WDCTRL para el controlador de disco duro PC / AT (lo que luego se convirtió en el controlador IDE estándar). La función se mostraba en la interfaz de usuario como "acceso a disco de 32 bits" y consistía en la ejecución completa de interrupciones int 13h dentro de WDCTRL, que a su vez accedía al hardware para esto, sin usar el BIOS y su controlador int 13h.
El beneficio de esto fue que el controlador en el BIOS no era más que girar en un ciclo de sondeo mientras el disco procesaba un comando, lo que hacía casi imposible mantener la CPU ocupada haciendo otra cosa en ese momento.
El uso de WDCTRL permitió que se ejecutara algún código mientras el disco procesaba operaciones, además de trabajar con el archivo de paginación en segundo plano. Esto mejoró mucho el rendimiento.
Comenzando con WDCTRL, VxD comenzó a asumir las funciones de controladores de dispositivos reales, y VMM (aunque todavía basado en DOS) asumió las funciones de un kernel de sistema operativo real.
Además, en Windows for Workgroups, toda la pila de protocolos SMB / CIFS se implementó en forma de VxD (con una capa de transporte, solo NetBEUI ), tanto el cliente como el servidor, excepto el nivel más bajo: el controlador de la tarjeta de red, el Este último se usó igual que en MS LAN Manager Client para DOS, y se cargó con el kernel de DOS especificándolo en el archivo config.sys.
Dado que el cliente SMB es lógicamente un sistema de archivos, también apareció un VxD llamado IFSMGR, que distribuye las llamadas del sistema MS-DOS para trabajar con archivos (int 21h) entre otros VxD y, en casos extremos, las envía al kernel de DOS (ese DOS de que VMM está cargado).
En Windows 3.11, el sistema de archivos FAT (acceso a archivos de 32 bits, rendimiento mejorado debido al uso de páginas de memoria virtual, en lugar de pequeños búferes del kernel de DOS, para la memoria caché) ya estaba implementado en forma de VxD. Además, este sistema operativo tiene la capacidad de ejecutar controladores de tarjetas de red en forma de módulos VxD .
La tecnología Plug and Play en Windows 95 se implementó completamente en forma de módulos VxD , el más importante de los cuales es CONFIGMG.VXD.
Se requería que todos los controladores de dispositivos que participaban en él fueran del tipo VxD o que tuvieran un segundo controlador: un cargador que conozca el primero y sea VxD. El segundo se usó para entornos compatibles con NDIS y SCSIPORT que admiten la carga de controladores de tarjetas de red y controladores de dispositivos de almacenamiento masivo desde Windows NT sin modificaciones (aunque los controladores de Windows NT tenían un formato de archivo diferente, igual que las aplicaciones Win32).
También en forma de VxD, se implementó la pila completa para trabajar con una unidad de CD / DVD (incluido el sistema de archivos CDFS / Joliet), así como la pila TCP / IP.
Por lo tanto, el uso de Virtual Machine Manager dentro del marco de Windows 95 permitió a Microsoft hacer la afirmación de marketing de que "Windows 95 ya no usa MS-DOS", lo cual era completamente falso. Primero, los investigadores (Andrew Shulman) demostraron rápidamente que el VMM todavía llama al DOS subyacente para operaciones como "obtener la hora actual". En segundo lugar, el sistema operativo en sí tenía la capacidad de hacer un disquete de arranque de MS-DOS, usando el mismo kernel de DOS que se usaba para arrancar el VMM del sistema operativo principal.
Windows 98 implementó la idea de los mismos controladores para Windows 9x y Windows NT de próxima generación: Windows Driver Model (WDM). Para implementar la idea, se agregó soporte para PnP y administración de energía al modelo de controlador de Windows NT (implementado 2 años más tarde que Windows 98, en Windows 2000), después de lo cual el modelo resultante se simplificó eliminando algunas llamadas antiguas de NT 3.x. de él, y transferido al entorno VMM.
Un VxD llamado NTKERN era un contenedor de VMM que implementaba WDM y podía cargar controladores en el formato de Windows NT. Por ejemplo, la llamada IoInvalidateDeviceRelations de Windows NT (que solo aparecía en WDM, como parte de la compatibilidad con PnP) se implementó a través de CM_Reenumerate_Devnode en CONFIGMG, etc.
Esto facilitó la implementación de soporte para buses USB y 1394 en ambas versiones de Windows a la vez; todos estos controladores se implementaron en WDM. Además, estos archivos .sys de las versiones beta de Windows 2000 funcionaron bien en Windows 98.
En aquellos días había diferentes conceptos de "controlador WDM" y "controlador de Windows NT", este último podía usar un conjunto de llamadas un poco más rico que no estaba implementado en NTKERN. Con la "extinción" de Windows basado en VMM, esta distinción también ha desaparecido, ahora WDM no es más que una API del kernel de Windows para desarrollar controladores de hardware (a diferencia de los filtros de paquetes de red, sistemas de archivos, etc.; dichos controladores siempre fueron fundamentalmente diferente en Windows 9 .x y en Windows NT).
Las máquinas virtuales "reales" que aparecieron en IBM 360 y ahora se implementan en Xen , Virtual PC , VMWare Workstation, ESX Server , Hyper-V y otros productos son diferentes de las máquinas virtuales DOS que se implementaron en VMM.
Por ejemplo, le permiten iniciar casi cualquier sistema operativo y casi cualquier versión del mismo con una cuenta de invitado, así como reiniciar completamente la sesión de invitado. Para ello, allí se emula todo el hardware, así como el sistema básico de entrada/salida (BIOS).
Sin embargo, las máquinas virtuales VMM usaban compatibilidad con el procesador: modo V86. Las máquinas virtuales reales requieren trucos como TLB virtual para su trabajo , lo que conduce a una gran cantidad de "caídas" en el hipervisor en una falla de página y es lento (algunos hipervisores simplemente cambian a la interpretación comando por comando del "invitado" código en algunos casos, especialmente cuando se ejecuta con un adaptador de video), o soporte para tablas de páginas multinivel ya en el propio procesador ( Vanderpool ), que apareció no antes de 2003.
El rendimiento adecuado de las máquinas virtuales reales solo se logró en la generación Pentium III, mientras que las máquinas virtuales VMM funcionaron bien en el i386.
La falta de multitarea entre las aplicaciones de Windows de 16 bits, junto con el uso del subsistema de interfaz de usuario y gráficos de 16 bits en todos los Windows basados en VMM, y la falta de protección de la memoria entre dichas aplicaciones, dieron como resultado una confiabilidad deficiente en todas estas versiones. de Windows.
Esto no es un reproche a VMM, sino a la API de Win16 y los subsistemas mencionados, pero sin embargo dio fuertes razones a los oponentes de Microsoft (del mundo UNIX) para hablar de la falta de una verdadera multitarea en Windows.
Esta opinión se extendió incluso a Windows NT, donde es un mito indudable, respaldado únicamente por la extremadamente débil implementación de la llamada fork() en el paquete Cygwin , que permite portar software de UNIX a Windows NT. La implementación de fork() de Cygwin copia todo el espacio de direcciones, principalmente debido a la compatibilidad con Windows basado en VMM: VMM nunca tuvo fork(), a diferencia del kernel de Windows NT (NtCreateProcess con SectionHandle == NULL), este último utilizado en el subsistema POSIX de Windows. y sus descendientes Interix y Servicios para UNIX.
Windows NT de varias maneras (bueno por su soporte de tiempo para máquinas multiprocesador y multitarea preventiva incluso dentro del kernel) superó a muchos UNIX, como los primeros Linux y FreeBSD, en términos de multitarea. Sin embargo, existe una fuerte opinión en el mundo de Linux de que no se necesita la multitarea preventiva dentro del kernel.