FreeDOS DOSDATA=UMB: Move Kernel Data into Upper Memory Blocks
Understand FreeDOS DOSDATA=UMB, how it differs from DOS=UMB and DEVICEHIGH, what it requires, and how to validate or roll back a memory-layout change.
DOSDATA=UMB is a narrowly scoped FreeDOS CONFIG.SYS directive: it asks the FreeDOS kernel to try to place kernel data structures in Upper Memory Blocks. It is easy to mistake it for a driver-loading command or for DOS=UMB, but neither interpretation is correct. It does not relocate DEVICE= or INSTALL= drivers, and it does not create upper memory. The FreeDOS reference describes it as an attempt, not a guaranteed allocation or a fixed amount of conventional memory recovered.
That boundary makes DOSDATA=UMB useful as a controlled memory-layout experiment. You can test one kernel setting, measure the result on the same machine and boot profile, and revert it independently of driver load order. You should not treat it as a general-purpose memory optimizer or assume that a configuration tested under another DOS kernel will have the same meaning.
What the directive does and leaves alone
The documented syntax is a single setting:
DOSDATA=UMBThe FreeDOS help says that the directive tries to load kernel data into UMBs. It compares the behavior to using the [name]HIGH variants of kernel parameters, naming FILESHIGH, LASTDRIVEHIGH, and STACKSHIGH as examples. It also states that DOSDATA is internal to KERNEL.SYS and needs no separate file of its own.
The same reference explicitly excludes drivers loaded with DEVICE= or INSTALL=. For example, adding DOSDATA=UMB does not move a CD-ROM driver declared as DEVICE=C:\FDOS\BIN\XCDROM.SYS, nor does it change an INSTALL= resident utility. Driver placement is a separate configuration problem; FreeDOS documents DEVICEHIGH= as the attempt to load a device driver into high memory first, with conventional-memory fallback if that attempt fails. Do not attribute a driver’s memory use to DOSDATA=UMB when measuring a boot.
The word “tries” is operationally important. Available UMBs depend on the machine, memory manager, and firmware or chipset layout. The FreeDOS memory overview describes the region between 640 KB and 1 MB as reserved in practice for items such as video RAM and BIOS, with managers exposing usable gaps in hardware-dependent ways. A machine can have too little suitable space, or no configured UMB provider at all. The directive cannot make an occupied or unavailable address range safe to use.
Keep DOS=UMB, DOS=HIGH, and DOSDATA separate
FreeDOS documents DOS=HIGH|LOW,UMB|NOUMB as controlling two different choices: whether the kernel should try to load itself high or remain in conventional memory, and whether UMBs should be linked with normal memory. The guide requires a high-memory manager such as FDXMS or HIMEM before requesting DOS=HIGH. DOSDATA=UMB is a separate directive about kernel data placement.
These settings can be combined, but one should not be used as shorthand for another. DOS=HIGH,UMB does not mean that every driver moves high; DEVICEHIGH= addresses a driver; and DOSDATA=UMB does not request that the kernel image itself move high. Each setting has a distinct target. Confirm the syntax and prerequisites for the exact FreeDOS kernel and memory-manager versions installed instead of transplanting a line from an MS-DOS or another DOS distribution guide.
The FreeDOS kernel documentation also notes that it looks for FDCONFIG.SYS and uses it instead of CONFIG.SYS when the former exists. Before editing a boot file, determine which file the running installation actually reads. Otherwise a careful test can appear to have no effect simply because the edited file is inactive.
Test it as a reversible boot-profile change
Start by recording the kernel version, active configuration filename, UMB provider and its options, loaded driver order, and a baseline memory report. Preserve a working copy of the configuration and make the test on a disposable VM snapshot or a boot profile with a known-good fallback. Keep the existing driver lines unchanged so that the experiment isolates DOSDATA=UMB rather than mixing it with unrelated driver rearrangement.
After confirming that the machine has a supported UMB setup, add the directive to the active FreeDOS configuration. If the goal is only to test data placement while keeping the kernel in conventional memory, a profile might contain a separately selected low-kernel/UMB policy and then the data directive:
REM Example only: retain the tested UMB-provider setup for this machine
DOS=LOW,UMB
DOSDATA=UMBThis is not a universal boot recipe. The comment does not install a memory manager, and DOS=LOW,UMB does not make one available. Keep the system’s already-tested provider and configuration syntax; if the desired policy includes DOS=HIGH, follow the FreeDOS requirement to load the high-memory manager first. Do not add both alternative policies to a file without understanding its parser and active menu branch.
Reboot fully into the same profile and collect the same report at the same boot point. A comparison is meaningful only when the kernel, manager, options, drivers, TSRs, and shell environment are otherwise held constant. Repeat the boot at least once to distinguish a stable effect from an accidental configuration or load-order change. Record any change in conventional memory and UMB usage, but do not infer a universal saving from a single machine: the directive’s documented behavior is an attempt, and available regions vary.
For clearer attribution, keep two named boot choices: one with the known-good baseline and one with only DOSDATA=UMB added. Verify that both still load the expected storage, input, and filesystem drivers and that representative DOS applications start. If boot behavior changes unexpectedly, select the baseline profile or remove the one directive from the active file, reboot, and compare against the preserved report. Do not “fix” a failed test by changing several memory-manager ranges at once; that obscures which change caused the result.
Diagnose a no-change result without escalating blindly
A report that does not change is not proof that the directive was ignored, nor is it evidence that the kernel moved drivers. First verify that the boot used FreeDOS KERNEL.SYS, that the active file contains the directive in the selected menu path, and that the configured manager actually exposes UMBs. Then compare the same measurements under the same driver order. If those checks hold and no useful placement change is observable, remove the directive unless a specific application or deployment profile benefits from retaining it.
If the system fails to boot, use the fallback profile or restore the saved configuration before changing provider ranges. UMB managers can expose only suitable gaps; a mistaken include/exclude range can conflict with hardware mappings. Diagnose the provider separately using its own documentation. DOSDATA=UMB is not a substitute for understanding which physical address ranges the manager makes available.
Practical limits and acceptance criteria
Treat this as a FreeDOS-kernel feature, not a portable DOS standard. The FreeDOS help identifies the directive as internal to KERNEL.SYS; another kernel may reject it, ignore it, or implement different configuration semantics. Keep it out of a shared boot file intended for unrelated DOS kernels unless each one is tested independently.
Accept the change only when the tested machine boots reliably, the expected UMB provider is active, relevant programs behave correctly, and the measured memory report improves or the documented profile has another explicit benefit. Keep a rollback path and record the tested kernel and manager versions. If there is no measurable benefit, no need to preserve the line exists: removing it is safer than carrying a setting whose effect is unknown.
DOSDATA=UMB is best understood as a small kernel-data placement hint within a larger UMB configuration. It neither relocates drivers nor guarantees extra conventional memory. Separating it from DOS=UMB, DOS=HIGH, and DEVICEHIGH= lets an operator test the actual feature, keep results reproducible, and avoid turning a one-line experiment into an untraceable boot failure.
Related:
- Upper Memory Blocks and Loading TSRs High
- The FreeDOS Kernel: How It Diverges from Original MS-DOS Internals
Sources: