Fixing HIMEM and EMM386 Conflicts in a FreeDOS Memory Configuration

Memory-manager failures can look like hangs, reboots, corrupted displays, protected-mode errors, or applications that suddenly lose conventional memory. These symptoms do not identify one cause. Start by preserving the exact boot messages and configuration, then test a small number of reversible profiles. Do not begin by stacking another manager on top of the one already failing.

Map the roles before changing CONFIG.SYS

An XMS manager provides the XMS interface and controls access to extended memory and, depending on implementation, the High Memory Area. A 386-class expanded-memory manager can create upper-memory blocks (UMBs), provide EMS services, and offer interfaces such as VCPI. Those are related but distinct roles. FreeDOS installations commonly use HIMEMX with JEMM386, or a combined manager such as JEMMEX. The exact implementation and options differ from Microsoft’s HIMEM.SYS and EMM386.EXE.

Use only one XMS manager and one UMB/EMS provider in a given profile. JEMM386 requires an external XMS manager; JEMMEX includes its own XMS manager. Do not load HIMEMX and JEMMEX together as if both were required. Likewise, do not leave an unrelated EMM386-compatible driver enabled alongside JEMM unless the documentation for that exact combination explicitly calls for it. Duplicate memory ownership is a configuration error, not a way to add capacity.

Create diagnostic boot profiles

Copy the current boot files and record which file FreeDOS actually reads (FDCONFIG.SYS or CONFIG.SYS, and FDAUTO.BAT or AUTOEXEC.BAT). Add a temporary menu profile that omits optional memory managers and third-party TSRs. If the kernel boots there, add one manager at a time. A minimal HIMEMX-only stage can look like:

DEVICE=C:\FREEDOS\BIN\HIMEMX.EXE /VERBOSE

Only after that stage works should a separate profile add JEMM386:

DEVICE=C:\FREEDOS\BIN\HIMEMX.EXE
DEVICE=C:\FREEDOS\BIN\JEMM386.EXE
DOS=HIGH,UMB

Paths and directives should match the installed FreeDOS release and boot files. If using JEMMEX, use its documented line as the XMS/UMB provider instead of also loading HIMEMX. DOS=HIGH,UMB requests DOS kernel placement and UMB linkage where the configured manager supports it; it is not itself a memory manager. Keep a conventional-memory fallback profile in case UMB allocation breaks a driver.

After each boot, record the manager’s messages and MEM output, for example MEM /C /P. Compare conventional, upper, XMS, and EMS figures across identical profiles. A numerical change alone is not a failure: managers reserve memory for their own tables and buffers. What matters is that expected services are present, the same workload starts, and the memory map changes consistently when one component is added.

Investigate A20 handling without importing MS-DOS switches

The A20 gate controls access above the first megabyte on legacy PC-compatible systems. A message such as “unable to control A20 line” may come from a specific XMS implementation, but the wording and remedies are not universal. Microsoft HIMEM options such as /M:n or /A20CONTROL:OFF are not generic FreeDOS switches. Do not paste them into a HIMEMX or JEMMEX line.

HIMEMX documents its own /METHOD: choices for A20 handling, including BIOS, keyboard-controller, and port-92h approaches. Change that method only when the installed HIMEMX help identifies the option and the machine or emulator provides evidence that the default method is the failing point. First remove duplicate managers and confirm which XMM is actually loading. If a method change is required, change one option in one boot profile, retain the previous profile, and verify cold boot, warm reboot, XMS allocation, and the application’s real workload.

Treat upper-memory exclusions as hardware-specific

Upper memory between conventional RAM and the one-megabyte boundary contains adapter memory, option ROMs, BIOS regions, and sometimes usable RAM. A manager may scan for candidate UMB areas, but memory maps vary with firmware, video hardware, option cards, shadowing, and virtualization. A range marked as available on one computer is not safe to copy to another. JEMM’s X= option excludes a range from use; an incorrect exclusion can remove usable UMB space, while forcing a range that is not really free can cause instability or corruption.

Do not add exclusions merely because a forum post says they improved free memory. Start with automatic detection and the manager’s verbose output. If a conflict is reproducible only when a particular range is used, identify that range from the actual machine’s documentation or diagnostic output and test a narrowly scoped change. If the evidence is unclear, disable high loading for the affected driver and keep a stable conventional-memory profile instead of guessing at address boundaries.

Add drivers in the right phase and isolate consumers

CONFIG.SYS drivers initialize before AUTOEXEC.BAT programs. Load the XMS provider before drivers that request XMS, and the UMB provider before using DEVICEHIGH, DOS=UMB, or LH for resident programs. Keep the actual order visible in the boot file. Then add disk caches, CD-ROM drivers, sound drivers, mouse TSRs, and network components individually. A system that boots without them but fails after one addition has narrowed the search substantially.

Applications can impose incompatible requirements. One may need EMS or VCPI while another works best without EMS emulation. Keep separate profiles for those workloads rather than continually reconfiguring a single global boot. Record the selected profile next to application-specific launch instructions; otherwise, a later successful test may be impossible to reproduce.

Keep a memory-manager test ledger

For each profile, use the same boot medium, emulator or hardware, and workload. Record each manager’s startup banner, exact executable path, checksum or package version, switches, and MEM result. Also note whether the failure occurs before DOS reaches the prompt, when a driver loads, when an application starts, or only after a particular operation. These points separate early address-map failures from later allocation or API compatibility failures.

Profile	XMS provider	UMB/EMS provider	Added driver	Result to record
Baseline	none optional	none optional	none	reaches prompt and memory report
XMS	HIMEMX or JEMMEX	none additional	none	XMS available, no duplicate host
UMB	HIMEMX plus JEMM386, or JEMMEX	one provider	one small TSR	high load result and measured memory
Workload	same selected manager	application-specific	required drivers only	repeated program behavior and exit

Do not compare readings from profiles that also changed FILES, BUFFERS, shell environment size, or DOS version; each of those can affect low-memory totals. If the manager reports a warning, preserve the literal message and consult the matching version’s manual. Repeating the same failure after changing multiple unrelated options makes the result less useful, not more.

Memory optimization should come after stability. Load a small, non-critical resident utility high and confirm that MEM shows the expected placement before moving core disk or network drivers. High memory can be fragmented, and a driver may have its own limitations; a successful LH for one program does not prove that another can use the same UMB. Keep a profile that favors compatibility even if it leaves less conventional memory for applications.

Acceptance and rollback

For each candidate configuration, cold boot twice and test the same applications, not just MEM. Confirm XMS or EMS with an application that actually requests it, load one intended high resident program, and check that failure messages do not appear. Record manager versions, checksums, options, memory totals, and any exclusions. Restore the previous profile immediately if the test produces unexplained corruption, a lock, or inconsistent memory reports. A stable, documented set of mutually compatible managers is a better outcome than the largest possible free-memory number.

Related:

Sources: