FreeDOS MEM Diagnostics: Read the Report Before Tuning Conventional Memory

FreeDOS MEM is most useful when treated as an observation tool, not as a repair command or a universal memory oracle. It can show conventional and upper-memory blocks, classify resident programs and device drivers, and report on expanded or extended memory when the relevant manager exposes that information. It cannot prove that a particular application will obtain the exact block, page, selector, or amount it needs. The diagnostic value comes from comparing controlled snapshots and correlating them with the application’s own failure.

That distinction matters because DOS memory is not a single pool. The kernel’s conventional-memory arena, upper-memory blocks, the high memory area, XMS, EMS, and a protected-mode extender have different owners and allocation rules. A MEM total from one domain cannot be substituted for a request made in another. Before moving drivers or changing a memory manager, identify the resource the program actually requests and record the exact boot profile.

Capture a baseline that can be repeated

Start from the same boot menu entry and working directory that produce the symptom. Record the FreeDOS release or kernel build, the shell and MEM executable found through PATH, the active FDCONFIG.SYS section, loaded memory managers, and resident drivers. If there are multiple copies of MEM on the disk, resolve the command explicitly with DIR and run the intended executable by full path. A command name alone does not prove which package was executed.

Take a short report before launching the affected program:

MEM
MEM /C /P
MEM /FREE
MEM /DEVICE

The exact options supported by an installed copy can differ from older FreeDOS distributions. Consult MEM /? on the target and save the output before using a switch in a script. Current FreeDOS help documents /C for classifying modules below 1 MB, /FREE for free conventional and upper-memory blocks, /DEVICE for resident drivers, /DEBUG for programs and devices, /FULL for a complete block list, /E for EMS, and /X for extended-memory information. Do not silently replace an unavailable long option with an undocumented abbreviation.

Preserve the raw report in a file or transcribe it exactly. Record whether it was captured after boot, after a TSR or driver load, after the application failed, or after a child program returned. An observation taken at a different lifecycle point is not a comparable baseline. If output redirection changes the way a particular MEM build paginates or reports, use an interactive capture and note that limitation rather than assuming redirected output is identical.

Choose the report for the question

The default summary is a starting point, not the complete diagnosis. Use /C when the question is which conventional-memory allocations belong to which modules. Use /FREE when the question is whether a suitably sized conventional or upper-memory block appears available. Use /DEVICE to locate resident drivers, and /M name or /MODULE name when the installed implementation supports a focused module query. /FULL or /DEBUG can expose more of the layout, but the longer output increases the chance that a screen-only capture will lose the important lines.

Use /E and /X only when the corresponding memory service is present and the application actually uses it. FreeDOS help explains that EMS reporting depends on LIM EMS compatibility and that XMS information comes from an extended-memory manager such as HIMEM. An absent or zero report does not establish that the machine has no physical memory above one megabyte; it can mean the relevant manager is absent, incompatible, not loaded, or does not expose the expected service. Check the manager’s own status command and the application’s documentation before diagnosing hardware.

Do not interpret MEM’s conventional-memory value as free space available to every program. The kernel, shell, device drivers, TSRs, and other allocations divide the address region. The largest free block can be more important than the sum of all reported free blocks because a legacy program may need one contiguous allocation. Use the detailed block report to investigate fragmentation or placement, then confirm with the application’s actual allocation result. A display of many small blocks is evidence about the current layout, not proof of what the next process can allocate after the shell creates its environment and loads the executable.

Compare one change at a time

If a program fails after a startup edit, boot a known-good profile and compare the reports. Change one driver placement or manager option, reboot, and capture the same reports again. For example, a test of loading one compatible resident driver high might record:

MEM /C > C:\TEST\BEFORE.TXT
REM Reboot into a profile with one documented DEVICEHIGH change.
MEM /C > C:\TEST\AFTER.TXT

The shell’s redirection syntax and the target drive must be available in both profiles. If a command fails before the second report is written, that missing file is a failed measurement, not evidence of zero use. Keep the original configuration file and a bootable recovery path; a memory optimization is not worthwhile if it removes the only way to start the machine.

Compare not only the final free count but also module order, block sizes, and whether the program or driver appears in conventional versus upper memory. A high load that saves a few kilobytes may reduce an upper-memory region needed by another device or application. A change in free conventional memory can also reflect a different shell environment size, boot-menu branch, or set of resident programs rather than the intended driver move. Record these variables alongside the numbers.

Separate memory services instead of adding their totals

Conventional memory is directly addressable in the real-mode DOS program model. Upper-memory blocks occupy available regions between the conventional-memory ceiling and the adapter/firmware areas, and a memory manager may need to provide them. The high memory area is a distinct region just above the one-megabyte boundary. XMS is an API for managed extended memory; EMS presents expanded-memory pages through a window. DPMI adds another protected-mode service boundary. These concepts are related, but they are not interchangeable balances on one account.

For that reason, do not add the free conventional, XMS, and EMS numbers and claim that the resulting number is available to the program. A conventional real-mode executable might never request XMS or EMS. A DPMI application may depend on an extender or host and still have a separate small conventional-memory requirement for startup, environment, or DOS transfers. The relevant acceptance test is whether that exact program starts and completes its workload under the intended profile.

MEM’s device classification is also not a complete dependency graph. A TSR can hook interrupts or rely on another driver without the report explaining the relationship. A driver can load successfully yet fail later when particular hardware or application behavior is exercised. Use MEM to identify what is resident, then consult each component’s documentation and test a reversible profile. Do not infer that a driver is safe to remove merely because its name is unfamiliar or it appears small.

Avoid common diagnostic traps

First, do not compare a current FreeDOS report with a screenshot from another DOS, shell, MEM version, virtual machine, or emulator and treat the difference as a regression. Tool output and compatibility layers have their own version-specific behavior. Second, do not treat an apparent total as a reservation. Between the report and the next allocation, another resident component or shell action can consume memory. Third, do not use /OLD or undocumented short switches to make an old script appear compatible unless the target MEM help and project documentation confirm the exact meaning.

Fourth, beware of the word “free.” Free conventional memory, free EMS pages, and unallocated XMS are not candidates for the same request. Fifth, do not optimize solely to maximize one line in the report. Relocating a TSR can change interrupt-chain order, device availability, compatibility, and which programs can use an upper-memory region. Finally, a crash that happens after a long workload may be caused by a corrupt pointer, an incompatible extender, or a driver defect rather than insufficient initial memory. Capture the program’s own diagnostic, exit result, and reproducible trigger as well.

A practical acceptance record

For a production-like retro workstation, preserve three artifacts: the boot configuration, a baseline MEM report, and a test report from the exact application workload. State the desired resource explicitly, such as a minimum contiguous conventional block or a confirmed EMS/XMS service, rather than “more memory.” List every change between baseline and test, including boot menu, shell, driver order, memory manager, and executable path.

Accept a tuning change only if the application now completes the same workload, the intended memory request is observable or documented, and required devices still work. Reboot into the recovery profile after testing to prove it still loads. If the application still fails, restore the last-known-good configuration and investigate the next boundary rather than stacking unrelated memory switches. MEM supplies a useful map of reported state; the program’s successful, repeatable behavior is the final evidence.

Related:

Sources: