DOS Protected Mode Services
Not being a DOS extender by itself, DPMS is a minimal set of extended DOS memory management services to allow slightly modified DOS resident system extensions (RSX) such as device drivers or TSRs (as so called DPMS clients) to relocate themselves into extended memory and run in 16-bit or 32-bit protected mode while leaving only a tiny stub in conventional memory as an interface to communicate with the conventional DOS environment. The DPMS clients do so through DPMS services provided by a previously loaded DPMS server. The necessary size of the remaining stub depends on the type of driver, but often can be reduced downto a few hundred bytes for just the header even for complex drivers.
By executing the driver in extended memory and freeing up conventional memory, DPMS not only allows very large drivers to load and take advantage of the available memory, but also to leave more memory available for normal DOS drivers to load or non-extended DOS applications to execute within the space constraints of the conventional memory area. This will also help to increase the amount of free system resources under Windows. Providing unified interfaces for the software to allocate and use memory in protected mode without having to tunnel all requests through real mode DOS, DPMS at the same time can help to improve system performance as well.
DPMS was originally developed by Novell's Digital Research GmbH, Germany, in 1992. It is compatible with any DOS and can coexist with memory managers and DOS extenders such as DPMI, VCPI, etc. The DPMS API is reentrant and compatible with multitaskers such as the DR-DOS multitasker or DESQview. By providing a built-in DPMS VxD-driver, it is also compatible with Windows 3.x and Windows 9x.
The DPMS server must be loaded after the memory managers (and before the drivers using it), either as a "DPMSXXX0" device driver per DEVICE statement in CONFIG.SYS (preferred method), or later as a TSR. For debug purposes (for example in conjunction with Microsoft's WDEB386.EXE), SDK-versions of EMM386.EXE 3.00 can alternatively provide DPMS services via EMM386 [/]DPMS[=ON] through a built-in DPMS.SYS module, then running at ring 1 instead of ring 0, as with the stand-alone version of DPMS.EXE. The DPMS [/]NOCR3 option allows debugging under Nu-Mega's SoftICE.
Depending on circumstances the server will occupy between about 700 to 1400 bytes of conventional memory by itself and cannot be loaded into UMBs. The DPMS server will require at least a 286 machine to run, but since DPMS-enabled software can be designed in a way so that it continues to execute in conventional memory if DPMS services are not available, the software does not need to give up compatibility with systems not providing DPMS services, either because DPMS is not loaded or not available (for example on pre-286 processors). On 386 CPUs (and higher), the DPMS server will not only provide a set of 16-bit, but also a set of 32-bit services. Even on these machines, DPMS can be forced to load only its 16-bit services using the DPMS [/]2 option.
DPMS will allocate memory either through VCPI or XMS, depending on what kind of memory is available. VCPI will typically call down to XMS as well. Newer versions of DPMS can be forced to utilize one of these interfaces using the DPMS [/]MEM=XMS|VCPI option. In some versions, it is possible to specify the maximum amount of extended memory to be allocated with DPMS [/]MB=nnnn.
DPMS registering services can be disabled or re-enabled at any time after load using the DPMS [/]OFF or DPMS [/]ON command, however, this will only affect new drivers loaded, not those already running and using DPMS.
There are basically three revisions of the DPMS specification, DPMS beta, DPMS 1.0 (original Novell DOS 7 shipment) and DPMS 1.1 (since March 1994 update). The 1.0 specification continued to support the beta specification as well, whereas the 1.1 (and higher) implementation does not.
DPMS saw its debut in beta versions of DR DOS "Panther" in October 1992, which, besides others, came with DPMS-enabled versions of the Super PC-Kwik disk cache, the SuperStor disk compression, and DEBUG as "stealth" protected mode system debugger. The PCMCIA card services CS in PalmDOS were DPMS-enabled as well. Later retail products such as Novell DOS 7 and Personal NetWare 1.0 in December 1993 also came with many DPMS-enabled drivers such as the file deletion tracking component DELWATCH 2.00, the adaptive disk cache NWCACHE 1.00, NWCDEX 1.00, a CD-ROM redirector extension, the peer-to-peer networking server SERVER 1.20, and STACKER 3.12, the disk compression component. DPMS was also provided by Caldera OpenDOS 7.01, DR-DOS 7.02 and 7.03, which, at least in some releases, added DPMS-enabled issues of DRFAT32 (a FAT32 redirector extension), LONGNAME (VFAT long filename support) and VDISK (virtual RAM disk). DR-DOS 7.03 contains the latest version of DPMS 1.44.
Stac Electronics also produced a DPMS-enabled stand-alone version of Stacker 4.
Some third-party DOS driver suites such as the Eicon Diva CAPI ISDN drivers or PCMCIA driver stacks such as Award's CardWare 2.5 (or higher) are known to support DPMS as well. After Phoenix' acquisition of Award, their PCMCIA drivers 6.0 (and higher) have been sold off to UniCore.
In 1993, Helix Software's memory manager Netroom 3 introduced a feature very similar to Novell's DPMS: CLOAKING was used to relocate Helix' network drivers into extended memory. Providing its functions as an extension to the real-mode EMS and XMS interface, its protected mode services are available under INT 2Ch.
Together with Award, Helix developed cloaked system and video BIOSes to reduce their real-mode memory footprint downto 8 KB (instead of 96 KB) and use them as mapped-in overlays in conjunction with their memory managers.
There was also a product named Multimedia Stacker consisting of Stac's DPMS-enabled Stacker 4.01 with Helix' suite of cloaked DOS utilities.
In contrast to Novell's DPMS, Helix' CLOAKING can be loaded high, but it does not run on 286 machines and does not provide 16-bit services. Also, CLOAKING 2.01 has been found to be incompatible with the DR-DOS multitasker (EMM386 /MULTI[=ON] + TASKMGR).
If no DPMS server is present when CLOAKING.EXE loads, it will, by default, also provide a cloaked DPMS server at a mere 100 bytes increase of its DOS memory footprint. However, it can also coexist with a DPMS server loaded before CLOAKING. The loading of its built-in DPMS server can be suppressed using the CLOAKING /NODPMS parameter. Therefore, DPMS-enabled drivers will work with both, DPMS or CLOAKING, but not vice versa.
Novell's DPMS utility may not be used to temporarily disable DPMS with a DPMS [/]OFF command if those DPMS services are provided by CLOAKING instead of DPMS itself, because Helix' implementation will erroneously not only disallow new drivers to register with DPMS, but completely switch off DPMS services even for already loaded drivers, leading to a system crash.
In 1993 Novell had announced plans to convert their resident workstation management utilities as well as their DOS network driver stacks (shells, redirectors and requestors) to utilize DPMS, however, so far only the Personal NetWare server component had actually taken advantage of it.
In 1996, Novell introduced a new 32-bit DOS/Windows NetWare client (Client32) based on ODI32/NIOS, replacing the former 16-bit client based on ODI/VLM. The NIOS (NetWare Input/Output System) client used techniques very similar to DPMS or Cloaking to relocate and run the code of the loaded NLMs (NetWare Loadable Modules) in protected mode and extended memory in order to reduce the conventional memory footprint of the network stack downto about 2 to 5 KB.
NIOS neither required nor used DPMS or Cloaking directly, and it did not provide a generic interface which could be utilized by non-NLM modules, however, it was certainly inspired by the DPMS technology and it can coexist with both of them.
While Novell's Personal NetWare continues to be published unmodified as part of the DR-DOS suite by its newer owners Caldera, Lineo and DeviceLogics up to the present, Personal NetWare had been abandoned since 1995 within Novell itself. This led to the situation that Novell never published a PNW.NLM driver to support the Personal NetWare protocol under the newer 32-bit ODI32/NIOS stack, so that users of Personal NetWare, who could take advantage of the PNW server module's DPMS capabilities already, were ironically bound to continue to use the memory-consuming ODI/VLM 16-bit client with its PNW.VLM protocol driver.
- Caldera, Inc. (1997). OpenDOS Developer's Reference Series — DOS Protected Mode Services (DPMS) 1.0 API — Programmer's Guide. Printed in the UK, August 1997. Caldera Part No. 200-DODG-005 ().
- Matthias Paul (1997-07-30). "NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds". MPDOSTIP (e-book) (in German) (edition 3, release 157 ed.). Retrieved 2012-01-11. NWDOSTIP.TXT is a comprehensive work on Novell DOS 7 and OpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the NWDOSTIP.TXT file.
- Matthias Paul (2001-04-09). "NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds". MPDOSTIP (e-book) (in German) (edition 3, release 183 ed.).
- Schulman, Andrew; Brown, Ralf; Maxey, David; Michels, Raymond J.; Kyle, Jim (1994). Undocumented DOS - A programmer's guide to reserved MS-DOS functions and data structures - expanded to include MS-DOS 6, Novell DOS and Windows 3.1 (2 ed.). Addison Wesley. p. 11. ISBN 0-201-63287-X. ISBN 978-0-201-63287-3.
- Ralf Brown (2002-12-29). "The x86 Interrupt List". Ralf Brown's Interrupt List (61 ed.). Retrieved 2012-01-14. See also: Ralf Brown's Interrupt List