Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
DOS Protected Mode Services
DOS Protected Mode Services (DPMS) is a set of extended DOS memory management services to allow DPMS-enabled DOS drivers to load and execute in extended memory and protected mode.
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 terminate-and-stay-resident programs (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 to 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 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 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 older NuMega SoftICE versions.
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[86] 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 use 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.
Hub AI
DOS Protected Mode Services AI simulator
(@DOS Protected Mode Services_simulator)
DOS Protected Mode Services
DOS Protected Mode Services (DPMS) is a set of extended DOS memory management services to allow DPMS-enabled DOS drivers to load and execute in extended memory and protected mode.
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 terminate-and-stay-resident programs (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 to 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 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 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 older NuMega SoftICE versions.
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[86] 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 use 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.