FreeDOS CWSDPMI Runtime Ownership: One-Shot, Resident, and Bundled Hosts

For a DJGPP program on FreeDOS, a missing DPMI provider is a runtime dependency failure, not proof that the executable is corrupt. CWSDPMI is one provider designed for DJGPP, but it can be started for a single client, left resident for later clients, or bundled with a DJGPP executable through the companion stub. Those are different ownership models. Copying CWSDPMI.EXE into a directory, adding it to a boot file, and embedding it in an executable should not be treated as interchangeable fixes.

The operational boundary is the DPMI host already serving the environment. DJGPP’s startup stub can use a host supplied by an operating environment, or load CWSDPMI when no provider is available. Running a second provider because an application prints “No DPMI” can be the wrong fix if a host exists but the DJGPP stub cannot locate the intended file. Establish the exact executable, target environment, host banner, and selected file before changing a working boot profile.

Choose the host lifetime before changing startup

The CWSDPMI release-7 manual documents two useful lifetimes. Starting CWSDPMI with no parameters creates a temporary server for a single DPMI process: it stays resident while that client runs and unloads when that application exits. This is a convenient test or application-specific path because it avoids retaining a DPMI server after the client has finished.

The -p mode instead leaves the server resident until explicitly removed with -u; the manual notes that this mode can be loaded high with LH when a suitable upper-memory arrangement exists. That is a system-level resident component. It consumes memory, becomes part of the boot/runtime compatibility profile, and should have one documented owner. Before unloading it, close every DPMI client that could still depend on it. Keep the -p/-u experiment in a disposable VM or a boot-menu entry with a known-good fallback rather than silently inserting it into the only production startup path.

The contrast is easier to review as a lifecycle table:

Mode	Lifetime described by the manual	Appropriate use
`CWSDPMI` with no options	Resident for one DPMI client, then unloads on client exit	Isolated launch test or an application that needs its own host session
`CWSDPMI -p`	Remains resident until `CWSDPMI -u`	Deliberate shared-host profile where several clients need the same installed provider
`CWSDSTUB` packaging	Host code is included in a single DJGPP executable image	Distribution where a one-file delivery is an explicit requirement

The table describes the maintainer’s release-7 documentation. The FreeDOS repository currently catalogs package version 7a, so verify the installed package’s own documentation and banner before treating every switch or default as invariant across builds.

Diagnose discovery before adding a resident server

The DJGPP FAQ identifies a malformed or unexpected PATH as one reason its startup stub can fail to find an installed cwsdpmi.exe. It suggests checking the executable location and path rather than assuming the DPMI service itself is unavailable. The same FAQ warns that some environments, including Windows NT DOS sessions, provide their own DPMI path and cannot use CWSDPMI in the same way. That example is historically specific, but the general operational rule remains: identify the host owner for the active environment before launching another provider.

Start with a controlled baseline:

MEM /C /P
VER
DIR C:\DJGPP\BIN\CWSDPMI.EXE

Then record the application checksum, DJGPP runtime/stub, FreeDOS kernel, boot profile, host banner, and complete startup message. A file that exists at one path does not establish that the application stub searches that path. Conversely, a successful launch does not prove that the intended host was selected if the environment already provides another one. Keep the test environment free of extra TSRs and document the exact command sequence.

For a one-client test in a disposable profile, use the no-option mode and run only a harmless diagnostic executable:

MEM /C /P
C:\DJGPP\BIN\CWSDPMI
C:\APPS\DPMI-DIAGNOSTIC.EXE
MEM /C /P

The manual’s no-option mode is intended to unload after that DPMI client exits. The before/after memory reports help show whether the server remained resident unexpectedly, but they do not prove DPMI compatibility or a particular memory allocation. Do not insert a real production workload until the diagnostic’s DPMI version query, exit path, and cleanup behavior have been tested.

Treat the swap path as a storage dependency

CWSDPMI can use a disk-backed swap file. The manual documents an explicit -s path and -s- to disable virtual memory; it also says that -s must be the last option because the remaining characters are interpreted as the path. Do not disable swapping merely to suppress a disk error: doing so changes the host’s capacity behavior and may cause a workload to fail sooner. If the application requires a configured swap file, validate the exact volume, free space, writable directory, and recovery plan before launch.

The manual’s swap diagnostics distinguish inability to open the configured file from a full disk when the file must grow. Capture the exact message and correlate it with the configured path and disk state. Do not clean up or overwrite a path that may contain application output, and do not create a swap file on a damaged or removable target just to make a test pass. Where a predictable local scratch volume is required, choose and monitor it as part of the runtime contract.

Understand the large-page and ring 0 variants

The release-7 manual describes automatic use of 4 MiB pages for large memory requests and documents limitations: those regions are treated as locked, DPMI 1.0 page-attribute operations do not work on them, and a resize may fail if it would have to move a memory zone containing such a page. It documents a CWSPARAM bit that suppresses 4 MiB pages. That is a compatibility and memory-policy setting, not a universal speed switch. Measure the actual application and host build, then compare allocation behavior and repeated runs in a disposable profile.

Do not substitute CWSDPR0 casually. The maintainer manual describes it as a ring 0 variant with virtual memory disabled and warns that its current hardware-interrupt stack behavior can make features such as SIGINT and SIGFPE fail with double- or stack-fault errors. A request for raw hardware access is not enough reason to move a normal DJGPP application into a more privileged execution mode. Follow the application’s documented runtime contract and use the least powerful host mode that satisfies it.

Bundle only when distribution requires one executable

CWSDSTUB.EXE lets a distributor construct a single executable image containing the CWSDPMI stub/host. The manual describes a specific EXE2COFF and binary concatenation procedure, as well as a separate ring 0 stub. This is a packaging path with format and redistribution constraints, not a command-line flag that makes arbitrary host binaries safe to append. Reproduce the procedure from the matching package documentation, preserve the corresponding source/notice obligations, and test the resulting executable on each supported environment.

An embedded host does not remove the need to test the runtime. Check that the delivered image starts under the intended DOS configuration, reports an expected DPMI capability set, handles low conventional memory and swap failure clearly, and exits without leaving state behind. Test an environment where a provider is already present as well as plain FreeDOS, but do not make a second host compete with a host owned by a VM or multitasker.

For a release record, store the DJGPP runtime and CWSDPMI package versions, the external or bundled host path, lifetime mode, swap policy, CWSPARAM configuration, FreeDOS build, and a repeated launch/exit result. A successful startup banner is only one check: the application must exercise the services it needs, handle allocation and exception failures, and release the host according to the chosen lifetime.

CWSDPMI is dependable when its provider, lifetime, memory policy, and package form are explicit. That small amount of configuration discipline prevents an application-specific compatibility test from becoming an undocumented global change to every DOS program on the machine.

Related:

Sources: