Los Servicios de Modo Protegido DOS ( DPMS ) son un conjunto de servicios de administración de memoria DOS extendidos que permiten que los controladores DOS habilitados para DPMS se carguen y ejecuten en memoria extendida y modo protegido . [1] [2] [3]
Al no ser un extensor de DOS por sí mismo, DPMS es un conjunto mínimo de servicios de administración de memoria DOS extendida para permitir que extensiones de sistema residentes en DOS ligeramente modificadas ( RSX ) como controladores de dispositivos o programas residentes de terminación y permanencia (TSR) (como los llamados clientes DPMS ) se reubiquen en la memoria extendida y se ejecuten en modo protegido de 16 bits o 32 bits mientras dejan solo un pequeño trozo en la memoria convencional como interfaz para comunicarse con el entorno DOS convencional. [2] [4] [5] Los clientes DPMS lo hacen a través de servicios DPMS proporcionados por un servidor DPMS previamente cargado . [1] El tamaño necesario del trozo restante depende del tipo de controlador, pero a menudo se puede reducir a unos pocos cientos de bytes solo para el encabezado incluso para controladores complejos.
Al ejecutar el controlador en la memoria extendida y liberar la memoria convencional, DPMS no solo permite que los controladores muy grandes se carguen y aprovechen la memoria disponible, sino que también deja más memoria disponible para que los controladores DOS normales se carguen o para que las aplicaciones DOS no extendidas se ejecuten dentro de las limitaciones de espacio del área de memoria convencional. Esto también ayudará a aumentar la cantidad de recursos libres del sistema en Windows. Al proporcionar interfaces unificadas para que el software asigne y use memoria en modo protegido [1] sin tener que canalizar todas las solicitudes a través del DOS en modo real, DPMS al mismo tiempo también puede ayudar a mejorar el rendimiento del sistema.
DPMS fue desarrollado originalmente por Novell 's Digital Research GmbH, Alemania, en 1992. [6] [nb 1] Es compatible con cualquier DOS y puede coexistir con administradores de memoria y extensores de DOS como DPMI , VCPI , etc. La API de DPMS es reentrante [1] y compatible con multitareas como el multitarea DR-DOS o DESQview . [7] Al proporcionar un controlador DPMS VxD integrado , también es compatible con Windows 3.x y Windows 9x . [7]
El servidor DPMS debe cargarse después de los administradores de memoria (y antes de los controladores que lo utilizan), ya sea como un controlador de dispositivo "DPMSXXX0" [7] por instrucción DEVICE en CONFIG.SYS (método preferido), o más tarde como un TSR. [7] Para fines de depuración (por ejemplo, junto con WDEB386.EXE [1] de Microsoft ), las versiones SDK de EMM386.EXE 3.00 pueden proporcionar servicios DPMS [1] de manera alternativa a través de EMM386 [/]DPMS[=ON] mediante un módulo DPMS.SYS integrado, [8] que se ejecuta entonces en el anillo 1 en lugar del anillo 0 , como con la versión independiente de DPMS.EXE. La opción DPMS [/]NOCR3 permite la depuración en versiones anteriores de NuMega SoftICE . [8]
Dependiendo de las circunstancias, el servidor ocupará entre 700 y 1400 bytes de memoria convencional por sí solo y no se puede cargar en UMB . [7] [nb 2] El servidor DPMS requerirá al menos una máquina 286 para ejecutarse, pero dado que el software habilitado para DPMS se puede diseñar de manera que continúe ejecutándose en la memoria convencional si los servicios DPMS no están disponibles, el software no necesita renunciar a la compatibilidad con sistemas que no brindan servicios DPMS, ya sea porque DPMS no está cargado o no está disponible (por ejemplo, en procesadores anteriores a 286). [1] [7] En CPU 386 (y superiores), el servidor DPMS no solo proporcionará un conjunto de servicios de 16 bits, sino también un conjunto de servicios de 32 bits. [1] Incluso en estas máquinas, se puede forzar a DPMS a cargar solo sus servicios de 16 bits usando la opción DPMS [/]2[86] .
DPMS asignará memoria a través de VCPI o XMS , [8] dependiendo del tipo de memoria disponible. VCPI normalmente también llamará a XMS. Las versiones más nuevas de DPMS pueden ser forzadas a usar una de estas interfaces usando la opción DPMS [/]MEM=XMS|VCPI . [8] En algunas versiones, es posible especificar la cantidad máxima de memoria extendida que se asignará con DPMS [/]MB=nnnn . [8]
Los servicios de registro de DPMS se pueden deshabilitar o volver a habilitar en cualquier momento después de la carga utilizando el comando DPMS [/]OFF o DPMS [/]ON , sin embargo, esto solo afectará a los nuevos controladores cargados, no a los que ya se están ejecutando y utilizan DPMS. [1] [7]
Básicamente, existen tres revisiones de la especificación DPMS: DPMS beta, [9] [10] DPMS 1.0 (versión original de Novell DOS 7) [1] y DPMS 1.1 (actualizada desde marzo de 1994). [11] La especificación 1.0 siguió admitiendo también la especificación beta, mientras que la implementación 1.1 (y posteriores) no lo hace. [11]
DPMS debutó en las versiones beta de DR DOS "Panther" en octubre de 1992, [8] [nb 1] que, entre otras cosas, venía con versiones habilitadas para DPMS de la memoria caché de disco Super PC-Kwik, [8] la compresión de disco SuperStor de Addstor , [9] [8] y DEBUG como depurador de sistema en modo protegido "oculto". [8] Si bien DPMS ya se llamaba "DOS Protected Mode Services" en ese momento, el controlador DPMS.EXE/DPMS.SYS 0.10 aún mostraba mensajes de inicio de "DOS Protected Mode Server". Los servicios de tarjeta PCMCIA CS en PalmDOS también estaban habilitados para DPMS. [8] Los productos minoristas posteriores, como Novell DOS 7 [3] y Personal NetWare 1.0 en diciembre de 1993, también vinieron con muchos controladores habilitados para DPMS, como el componente de seguimiento de eliminación de archivos DELWATCH 2.00, la caché de disco adaptable NWCACHE 1.00, [9] [7] NWCDEX 1.00, [6] [7] una extensión de redirector de CD-ROM , el servidor de red peer-to-peer SERVER 1.20 y STACKER 3.12, el componente de compresión de disco. DPMS también fue proporcionado por Caldera OpenDOS 7.01, [1] DR-DOS 7.02 y 7.03, que, al menos en algunas versiones, agregaron problemas habilitados para DPMS de DRFAT32 (una extensión de redirector FAT32 ), [8] LONGNAME ( soporte de nombre de archivo largo VFAT ) [8] y VDISK ( disco RAM virtual ). [1] [10] DR-DOS 7.03 contiene la última versión de DPMS 1.44.
DPMS también fue proporcionado por PC DOS 7.0 de IBM [12] [13] y PC DOS 2000, que venían con una versión anterior del servidor DPMS de Novell y una versión habilitada para DPMS de Stacker 4.02 incluida. [12] [13]
Stac Electronics también produjo una versión independiente de Stacker 4 habilitada para DPMS. [14]
El Super PC-Kwik 6.xx para DOS de PC-Kwik Corporation [15] y su Power Pak 4.0 para Windows también incluyeron el caché de disco habilitado para DPMS SUPERPCK en 1994. [16]
Se sabe que algunas suites de controladores DOS de terceros, como Eicon Diva o High Soft Tech GmbH (HST) Saphir [17], los controladores CAPI ISDN o las pilas de controladores PCMCIA/PCCard como CardWare 2.5 (o superior) de Award , también admiten DPMS. [8] Después de la adquisición de Award por parte de Phoenix , sus controladores PCMCIA 6.0 (y superiores) se vendieron a UniCore. [8] CardWare 6.0 y 7.0 estaban disponibles a través de APSoft, [18] [19] Socket Services (SSxxxxxx.EXE), Card Services (PCCS.EXE), PC Enable (PCENABLE.EXE) y los manejadores de tarjetas (PCDISK.EXE, PCSRAM.EXE, PCATA.EXE y PCFLASH.EXE) podían usar DPMS. A través de la integración de la pila por parte de LXE en sus PC DOS reforzados, DPMS también encontró su camino hacia la suite Datalight ROM-DOS . [20] [21] [22]
En 1999, Funk Software introdujo una versión de su software de control remoto Proxy Host con DPMS habilitado, lo que permitía a PHOST ocupar solo 9 KB de memoria convencional. [23] El software de cliente de acceso telefónico remoto REMOTE para el servidor de acceso remoto 833 de Perle Systems podría aprovechar DPMS para el mismo propósito al menos desde 2002. [24] Kendall Bennett de SciTech Software investigó la posibilidad de agregar soporte DPMS a su suite de controladores DOS alrededor de 2000 también, pero esto nunca se publicó.
Bret Johnson desarrolló controladores de impresión de pantalla a archivo (PRTSCR) habilitados para DPMS y USB para DOS. [25] [26]
En 1993, el administrador de memoria NETROOM 3 de Helix Software Company introdujo una característica muy similar al DPMS de Novell: CLOAKING se utilizó para reubicar los controladores de Helix y de terceros en la memoria extendida [2] y ejecutarlos en el anillo 0. [27] Proporcionando sus funciones como una extensión a la interfaz EMS y XMS de modo real , sus servicios de modo protegido están disponibles bajo INT 2Ch. [10] [28] Un kit de desarrollador CLOAKING estaba disponible que incluía un depurador NuMega SoftICE . [29] [30] Las interrupciones de enganche de software TSR o controlador encubierto tenían que dejar un pequeño trozo de 11 bytes en la memoria convencional que invocaría al servidor CLOAKING para pasar la ejecución a la parte de modo protegido del software del controlador. [27]
CLOAKING incluye soporte para el funcionamiento en Windows 3.x y Windows 95, proporcionando servicios INT 2Ch compatibles a controladores en modo protegido a través de un VxD de Windows, así como depuración a través del inicio de Windows utilizando SoftICE. Esta capacidad de transición entre entornos de host en modo protegido también es objeto de una patente. [31]
CLOAKING se integra y funciona con programas de control de memoria virtual existentes, sin cambiar las tablas de descriptores ni restablecer los registros de control. Esto permite un procesamiento más rápido de las interrupciones, según la documentación de Helix. [30] [31]
A diferencia del DPMS de Novell, el controlador CLOAKING de Helix se puede cargar en alto, [7] [nb 2] pero no se ejecuta en máquinas 286, [7] [nb 2] aunque admite servicios de 16 bits y estructura de programa en una 386. Además, se ha descubierto que CLOAKING 2.01 es incompatible con el multitarea DR-DOS ( EMM386 /MULTI[=ON] + TASKMGR ). [7]
Si no hay ningún servidor DPMS presente cuando se carga CLOAKING.EXE, CLOAKING, por defecto, también proporcionará un servidor DPMS camuflado con un mero aumento de 100 bytes de su huella de memoria DOS . [14] [7] Sin embargo, también puede coexistir con un servidor DPMS cargado antes de CLOAKING. La carga de su servidor DPMS incorporado puede suprimirse utilizando el parámetro CLOAKING /NODPMS . [7] Los controladores habilitados para DPMS funcionarán tanto con DPMS como con CLOAKING, pero no al revés. [7]
En NETROOM v3.04, la distribución del disco suplementario del 10 de febrero de 1995 incluía el archivo de recursos protegido por contraseña NR.ZIP (679.271 KB) como un archivo no documentado; DPMSCLK.EXE (13.904 KB), "Servidor DPMS encubierto v3.03". El archivo no revela compatibilidad con ninguna opción o parámetro cuando se consulta utilizando la opción de ayuda estándar, DPMSCLK /? . Este archivo no se descomprime con el programa SETUP.EXE de NETROOM 3 y no se instala. No hay ningún indicio de la existencia del archivo en el manual del software de NETROOM 3 [32] ni en ninguno de los documentos del programa en disco ni en los archivos legibles por humanos. [33] Esta versión final de NETROOM tal como se publicó básicamente ignoró DPMS.
Helix obtuvo la licencia de una versión del BIOS de Award Software y desarrolló BIOS de sistema y video encubiertos que se ejecutaban completamente en modo protegido, reduciendo su huella de memoria en modo real a 8 KB (en lugar de 96 KB [10] ) y los usó como BIOS de tiempo de ejecución junto con su administrador de memoria NETROOM . [7] [28]
Como parte de su producto Multimedia Cloaking , Helix proporcionó versiones encubiertas del controlador MOUSE 6.33 de Logitech , MSCDEX de Microsoft y un caché de disco desarrollado internamente para reemplazar los controladores SmartDrive de Microsoft .
También había un producto llamado Multimedia Stacker que consistía en el Stacker 4.01 de Stac con DPMS habilitado y el conjunto de utilidades DOS encubiertas de Helix mencionado anteriormente. [14] [34]
El controlador del mouse DOS de Logitech desde MouseWare 6.50 también fue habilitado para aprovechar la función CLOAKING, reduciendo así la huella de memoria del controlador del mouse visible para las aplicaciones DOS de 27 KB a 1 KB. [7]
CLOAKING también fue licenciado a Symantec para su suite de utilidades, a Corel para sus productos CD Creator y Corel SCSI, y a SMC Networks para sus controladores Ethernet.
La utilidad DPMS de Novell no se puede usar para deshabilitar temporalmente DPMS con un comando DPMS [/]OFF si esos servicios DPMS son provistos por CLOAKING en lugar del propio DPMS, porque la implementación de Helix erróneamente no solo no permitirá que nuevos controladores se registren con DPMS, sino que también desactivará por completo los servicios DPMS incluso para los controladores ya cargados, lo que provocará un bloqueo del sistema. [7]
En 1993, Novell había anunciado planes para convertir sus utilidades de administración de estaciones de trabajo residentes así como sus pilas de controladores de red DOS (shells, redirectores y solicitantes) para usar DPMS, [10] sin embargo, sólo el componente de servidor Personal NetWare fue modificado para realmente aprovecharlo.
Anunciado en 1993, [35] [36] [37] [38] Novell introdujo un nuevo cliente NetWare DOS/Windows de 32 bits (Client 32) basado en ODI32 / NIOS en 1996, reemplazando al antiguo cliente de 16 bits basado en ODI / VLM . [7] El cliente NIOS ( NetWare I/O Subsystem [37] [39] [40] ) para DOS y Windows utilizaba técnicas muy similares a DPMS o Cloaking para reubicar y ejecutar el código de los NLMs ( NetWare Loadable Modules ) cargados en modo protegido y memoria extendida para reducir la huella de memoria convencional de la pila de red a aproximadamente 2 a 5 KB. [7] [39]
NIOS no requirió ni utilizó DPMS o Cloaking directamente, y no proporcionó una interfaz genérica que pudiera ser utilizada por módulos no NLM, sin embargo, ciertamente se inspiró en la tecnología DPMS y puede coexistir con ambos.
Aunque el Personal NetWare de Novell fue publicado sin modificaciones como parte de la suite DR-DOS por sus nuevos propietarios Caldera , Lineo y DeviceLogics hasta 2018, Personal NetWare había sido abandonado desde 1995 dentro de la propia Novell. Esto llevó a la situación de que Novell nunca publicó un controlador PNW.NLM para soportar el protocolo Personal NetWare bajo la nueva pila ODI32/NIOS de 32 bits, de modo que los usuarios de Personal NetWare, que ya podían aprovechar las capacidades DPMS del módulo de servidor PNW, estaban obligados a seguir usando el cliente ODI/VLM de 16 bits que consumía memoria con su controlador de protocolo PNW.VLM . [7]
[…] [hasta] 1992
Digital Research GmbH
[…]
DR DOS 6.0
[…] Extensor de modo protegido DPMS diseñado e implementado para controladores de dispositivos para DR DOS 7. […]
{{cite book}}
: |work=
ignorado ( ayuda ) (NB. NWDOSTIP.TXT es un trabajo exhaustivo sobre Novell DOS 7 y OpenDOS 7.01 , que incluye la descripción de muchas características y componentes internos no documentados. Es parte de la colección MPDOSTIP.ZIP aún más grande del autor, mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace provisto apunta a una versión anterior convertida a HTML del archivo NWDOSTIP.TXT).{{cite book}}
: |work=
ignorado ( ayuda )[…] En
Stacker 4.0
,
Stac
proporcionó compatibilidad con los servicios de modo protegido de DOS (DPMS), lo que permite que la mayor parte del controlador de Stacker se mueva a
la memoria extendida
. […]