DEVICEHIGH vs LOADHIGH: Which Approach Maximizes Conventional Memory for DOS Games?
0 reputation · 24 Jul 2024, 06:08 UTC
0 reputation · 24 Jul 2024, 06:08 UTC
When running DOS games or legacy applications that require at least 50 KB of conventional memory, the decision between using DEVICEHIGH in CONFIG.SYS and LOADHIGH in AUTOEXEC.BAT becomes critical. Both directives aim to relocate code into Upper Memory Blocks (UMBs) when HIMEM.SYS and an UMB provider such as EMM386.EXE are present, but they differ in ordering, scope, and failure behaviour.
The main constraints are that DEVICEHIGH silently falls back to conventional memory if no UMB space is available, with no error message, while LOADHIGH requires a relocatable executable and must be invoked after all drivers have been loaded. The MS‑DOS documentation does not define a deterministic allocation order when multiple DEVICEHIGH entries compete for limited UMB space, leading to version‑sensitive load success across 5.0‑6.22.
Because of the silent fallback, users cannot reliably detect when a driver intended for UMB ends up in conventional memory, which complicates troubleshooting and memory budgeting.
1) How can we programmatically detect that a DEVICEHIGH entry has silently fallen back to conventional memory?
2) Is there a documented priority or ordering rule that ensures LOADHIGH relocations occur after all DEVICEHIGH drivers have been processed?
3) What is the impact on conventional memory usage when both DEVICEHIGH and LOADHIGH are used for the same driver or TSR?
31775 reputation · 24 Jul 2024, 15:27 UTC
1) Detecting a silent fallback of DEVICEHIGH
MEM /C. The output lists all memory blocks, including UMB ranges (above 640 KB). Look for the driver’s name or file path; if it appears in the UMB section, it was successfully relocated.CONVENTIONAL, it fell back silently. The Largest Executable Program Size column will also shrink accordingly.MEM /C output, or use MEM /T to capture the full memory map and search for the driver string.2) Ordering and priority between DEVICEHIGH and LOADHIGH
DEVICEHIGH entries are processed during the CONFIG.SYS load phase, before the command processor starts. They occupy UMB space first.COMMAND.COM), then executes AUTOEXEC.BAT. Only at this point does LOADHIGH attempt relocations.LOADHIGH always runs after all DEVICEHIGH drivers. There is no documented interleaving; the order is deterministic across DOS 5.0–6.22.3) Impact when the same driver or TSR is specified in both directives
DEVICEHIGH, it will occupy a UMB block first. When AUTOEXEC.BAT later invokes the same driver with LOADHIGH, the loader will find no free UMB space and will silently fall back to conventional memory (unless the driver is marked non‑relocatable, in which case LOADHIGH will print an error).Largest Executable Program Size reported by MEM will reflect this increase.LOADHIGH entry for that driver or ensure enough UMB space remains after all DEVICEHIGH loads.In practice, the safest approach for DOS games that need at least 50 KB of conventional memory is:
DEVICEHIGH in CONFIG.SYS, keeping the list short.LOADHIGH in AUTOEXEC.BAT only for TSRs that are known to be relocatable and that you want to keep in UMB.MEM /C to verify the memory map and adjust if any driver has fallen back.These steps maximize the remaining conventional memory for the game while maintaining stability.
Missing diagnostic detail
To refine the recommendation, could you confirm whether HIMEM.SYS is loaded and EMM386.EXE is configured to provide UMBs? If not, both directives will default to conventional memory regardless of the settings.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.