En informática , la Interfaz de Modo Protegido DOS ( DPMI ) es una especificación introducida en 1989 que permite que un programa DOS se ejecute en modo protegido , dando acceso a muchas características de los nuevos procesadores de PC de la época no disponibles en modo real . Fue desarrollada inicialmente por Microsoft para Windows 3.0 , aunque Microsoft luego entregó el control de la especificación a un comité de la industria con membresía abierta. [1] [2] Casi todos los extensores DOS modernos se basan en DPMI y permiten que los programas DOS direccionen toda la memoria disponible en el PC y se ejecuten en modo protegido (principalmente en el anillo 3, menos privilegiado). [3]
DPMI son las siglas de DOS Protected Mode Interface. Es una API que permite que un programa se ejecute en modo protegido en procesadores de la serie 80286 y posteriores, y que realice las llamadas al modo real sin tener que configurar estos modos de CPU manualmente. DPMI también proporciona las funciones para administrar varios recursos, en particular la memoria . Esto permite que los programas habilitados para DPMI funcionen en sistemas operativos multitarea , lo que permite que un núcleo de sistema operativo distribuya dichos recursos entre múltiples aplicaciones. DPMI proporciona solo la funcionalidad que necesita implementarse en modo supervisor . Puede considerarse como un microkernel de una sola tarea . El resto de la funcionalidad está disponible para los programas habilitados para DPMI a través de las llamadas a los servicios DOS y BIOS en modo real , lo que permite que la API DPMI en sí misma permanezca en gran parte independiente de DOS. Las cosas que hacen que la API DPMI sea específica de DOS son solo 3 funciones para administrar la memoria DOS y la letra "D" en el acrónimo "DPMI".
Un servicio DPMI puede ser de 16 bits, 32 bits o "universal" y se denomina núcleo DPMI , host DPMI o servidor DPMI . Lo proporciona el sistema operativo host ( host DPMI virtual ) o un extensor DOS ( host DPMI real ). El núcleo DPMI puede ser parte de un extensor DOS, como en DOS/4GW o DOS/32A , o independiente, como CWSDPMI o HDPMI .
El uso principal de la API DPMI es permitir que los extensores DOS proporcionen un entorno independiente del sistema operativo del host. El extensor DOS comprueba la presencia de un núcleo DPMI e instala el suyo propio solo si el que no estaba instalado ya estaba instalado. Esto permite que los programas extendidos por DOS se ejecuten en un sistema operativo multitarea que proporcione su propio núcleo DPMI o directamente en un sistema DOS de hardware , en cuyo caso el extensor DOS utiliza su propio núcleo DPMI. Los núcleos en modo usuario de Windows 3.x y 9x se construyen con un extensor DOS, por lo que dependen completamente de una API DPMI que proporciona el núcleo ring-0 de Windows.
Los primeros borradores de la especificación DPMI fueron publicados en 1989 por Ralph Lipe de Microsoft. [4] [1] Aunque se basaba en una versión prototípica de DPMI para Windows 3.0 en modo mejorado 386, varias características de esta implementación fueron eliminadas de la especificación oficial, incluyendo una característica llamada Extensiones MS-DOS [5] o traducción de API DOS que había sido propuesta por Ralph Lipe en los borradores originales. [6] La mayor parte era la implementación de interfaces DOS y BIOS (debido a esta historia algunas API INT 21h como 4Ch tienen que ser implementadas por todas las implementaciones DPMI). La versión 0.9 de DPMI fue publicada en 1990 por el Comité DPMI recién formado. El número de versión 0.9 de la especificación resultante fue elegido para reflejar la naturaleza simplificada y el estado incompleto del estándar sobre el que los miembros del Comité DPMI pudieron ponerse de acuerdo. [1] Aunque Windows informa de la versión 0.9 de DPMI por motivos de compatibilidad, en realidad también implementa las otras partes, ya que representan una parte vital del sistema. [5] [1] Esta naturaleza completa no documentada de DPMI se ha conocido como " auténtico DPMI " en la industria. [7] El estándar DPMI no fue el único esfuerzo para superar las deficiencias de la especificación VCPI . Al mismo tiempo que Microsoft desarrolló DPMI para Windows 3.0, otra alianza de la industria que incluía al Software Focus Group de Intel , [8] [1] Lotus , [8] Digital Research , Interactive Systems y otros desarrollaron una especificación llamada Extended VCPI ( XVCPI ) para hacer que la gestión de memoria y las capacidades multitarea del 386 estuvieran disponibles para aplicaciones DOS extendidas. [8] [1] [9] Cuando resultó que la propuesta DPMI de Microsoft abordaba una serie de problemas similares y contaba con el apoyo de Windows, estos esfuerzos llevaron a la creación del Comité DPMI en febrero de 1990 durante una reunión en Intel en Santa Clara. [8] [1]
En 1991, el Comité DPMI revisó DPMI a la versión 1.0 para incorporar una serie de aclaraciones y extensiones, pero aún no incluía los bits faltantes de "auténtico DPMI" implementados en Windows. De hecho, el "auténtico DPMI" nunca llegó a formar parte de la especificación oficial de DPMI, y Windows tampoco implementó las extensiones de DPMI 1.0 (y no muchos hosts DPMI lo hicieron).
Si bien DPMI está diseñado para ejecutar software de aplicación DOS extendido en modo protegido y memoria extendida, [10] no es particularmente adecuado para extensiones de sistema residentes. Otra especificación llamada DPMS , [10] desarrollada por Digital Research / Novell alrededor de 1992, aborda específicamente los requisitos para reubicar fácilmente el software de controlador DOS modificado en la memoria extendida y ejecutarlo en modo protegido, reduciendo así su huella de memoria convencional a pequeños stubs . Esto también es compatible con Helix Cloaking .
El "método" DPMI es específico del DOS y del IBM PC. Otros tipos de ordenadores se actualizaron de 16 bits a 32 bits, y el soporte avanzado de programas se proporcionó actualizando el sistema operativo con una nueva API de 32 bits y nuevas capacidades de gestión y direccionamiento de memoria. Por ejemplo, el sistema central OS/2 admite programas de 32 bits y se puede ejecutar sin la GUI. La solución DPMI parece ser necesaria principalmente para abordar la necesidad de terceros de conseguir que los programas en modo protegido DOS se ejecuten de forma estable en Windows 3.x antes de que el proveedor dominante de sistemas operativos, Microsoft, pudiera o quisiera abordar el futuro de Windows de 32 bits. Además, Microsoft no vio la respuesta a la transición a 32 bits en un DOS de 32 bits, sino en un Windows de 32 bits con una API completamente diferente (e incompatible).
Si bien Windows 3.0 implementa "DPMI real" [5] y reporta compatibilidad con DPMI 0.9, [11] la versión 1.0 de DPMI nunca se implementó en Microsoft Windows , por lo que la mayoría de los programas y extensores de DOS se escribieron principalmente para la versión 0.9. Sin embargo, pocos extensores implementan "DPMI real".
Las versiones beta de Qualitas 386MAX implementaron "DPMI real" y podían ejecutar KRNL386.EXE de Windows desde la línea de comandos, pero se afirmó en un correo electrónico interno que esta opción estaba deshabilitada en el producto lanzado. [5] Sin embargo, DPMIONE (creado por Bob Smith y basado en el código 386MAX) puede hacerlo. Actualmente, DPMIONE y 386 MAX también son los únicos host DPMI que admiten DPMI 1.0 por completo (por ejemplo, memoria no comprometida) y son los principales promotores de DPMI 1.0. [12]
El KRNL386.SYS (también conocido como "MultiMAX") de DR DOS "Panther" y "StarTrek" , que ha estado en desarrollo desde 1991, [nb 1] y los administradores de memoria EMM386.EXE de Novell DOS 7 , [10] Caldera OpenDOS y DR-DOS 7.02 y superiores tienen soporte integrado para DPMI cuando se cargan con la /DPMI[=ON]opción. KRNL386.SYS incluso tenía una opción de línea de comandos /VER=0.9|1.0para proporcionar soporte para DPMI 1.0 o 0.9. [13] La traducción de la API de DOS se denominó "interrupción llamada 21 desde el modo protegido". DOS multiusuario , System Manager y REAL/32 también admiten DPMI.
El núcleo DPMI independiente más famoso es probablemente CWSDPMI ; es compatible con DPMI 0.9, pero no tiene ninguna "traducción de API DOS" no documentada. Otra variante llamada PMODE por "TRAN", también conocido como Thomas Pytel, fue popular entre los programadores de 32 bits durante la escena de demostración de los años 90. Muchos juegos usaban DOS/4GW, que fue desarrollado por Rational Systems como un subconjunto de DOS/4G y se distribuyó con el compilador Watcom C.
HDPMI (parte de HX DOS Extender ) proporciona "traducción de API DOS" y una implementación casi completa de DPMI 1.0.
El Comité DPMI 1.0 se reunió entre 1990 y 1991 y estuvo compuesto por 12 grupos:
[…] Los creadores de VCPI eran muy conscientes de sus limitaciones y ya estaban trabajando arduamente en una especificación de segunda generación llamada Extended VCPI ( XVCPI ), cuando Microsoft irrumpió en la escena con las versiones de prueba beta de Windows 3.0 y su DPMI. Durante unos meses pareció que el incipiente mercado de extensores de DOS se fragmentaría en dos direcciones mutuamente excluyentes […] Microsoft entregó el control de la especificación DPMI a un comité de la industria con membresía abierta, y los patrocinadores del esfuerzo XVCPI decidieron unir fuerzas detrás de DPMI. […] Microsoft acordó eliminar las partes de la DPMI que cruzaban hacia el territorio de los extensores de DOS, específicamente, el soporte directo de las interrupciones de DOS y ROM BIOS en modo protegido . En consecuencia, DPMI, versión 0.9, la primera versión pública, publicada por el Comité DPMI en mayo de 1990, define solo las funciones de bajo nivel o de bloques de construcción […] Naturalmente, la interfaz de nivel superior o extensor de DOS de Windows 3.0 todavía existe, pero ha retrocedido a la zona de penumbra de la funcionalidad no documentada. No documentada, pero difícilmente inutilizable […]
[…] [Ralph Lipe:] Creo que están registrados en el proyecto
Win386
. En la raíz MSDOS.DOC (mira todos los archivos .DOC en la raíz) […] ¡NO! Este es un asunto extremadamente delicado ya que básicamente le dice a […]
los ISV
(también conocidos como
DR-DOS
e
IBM
) cómo ejecutar
Windows
en modo estándar . Debes consultarlo con
BradSi[lverberg]
antes de distribuirlo. [Greg Lowney:] SoftNet fabrica un
limitador
. Leyeron en el manual
de C7
que puedes ejecutar C7 dos-extended si tu limitador admite las extensiones MS-DOS para la especificación DPMI. Entonces […] nos llamaron para obtener una especificación sobre exactamente qué son esas extensiones. Aparentemente no están documentadas. […] No son tan complicadas, en su mayoría solo lo que MS-DOS y BIOS llaman que mapeamos para la aplicación, y Qualitas no tuvo problemas para realizar ingeniería inversa. (El nuevo
386MAX
fue, en versión beta, capaz de ejecutar KRNL386 desde la línea de comandos, pero creo que deshabilitaron esa característica en su producto final para evitar pisarnos los pies. 386MAX, por supuesto, admite C7). […] Ralph, ¿se distribuyó la especificación a los miembros del comité DPMI? […] [Dave Cole:] No deberíamos documentar esto en absoluto. […]
El prototipo DPMI inicial fue desarrollado por Microsoft para la versión 3.0 de Windows, con aportes de Lotus Corporation y Rational Systems, como parte de un esfuerzo general para mejorar el rendimiento de Windows al permitir que el núcleo de Windows se ejecute en memoria extendida. En paralelo, Intel estaba trabajando con fabricantes de entornos multitarea, emuladores EMS y extensores DOS para garantizar que una especificación VCPI extendida pudiera utilizar por completo las características de virtualización y protección del 80386. En febrero de 1990, las partes implicadas en las actividades antes mencionadas acordaron formar el Comité DPMI y formular un estándar para toda la industria para aplicaciones DOS en modo protegido. El Comité publicó la primera Especificación DPMI pública, Versión 0.9, en mayo de 1990.