DEVICEHIGH vs LOADHIGH: Which Approach Maximizes Conventional Memory for DOS Games?

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?