How did DOS know where to load itself in upper memory?

Question

If I remember correctly, you could ask DOS to load in upper memory by writing something like...

DOS=UMB

...somewhere in the CONFIG.SYS file.

But the question is, how did DOS know what portions of the UMA where available? Were there any BIOS functions that would report this info? (I know there's a INT 0x15, EAX = 0xE820 for this, but it only works for 32-bit machines).

If so, what if wanted to write a TSR that would monitor BIOS interrupts even before DOS is loaded? Would the OS overwrite my code or do I have any way to "protect" my TSR memory from being claimed later?

Answer 1

When configured to use upper memory (DOS=UMB) or high memory (DOS=HIGH) or both, the DOS “kernel” doesn’t find that memory itself; it relies on the services of a memory manager such as HIMEM.SYS, and the (XMS) APIs it provides. The memory manager determines what memory is available using a variety of techniques.

However, what you’re trying to do doesn’t require messing around with that behaviour. To hook BIOS interrupts and monitor them before the operating system starts, you’d effectively need to write something like a boot sector virus. The technique there is to position your code somewhere at the top of memory, then “hide” by altering the memory information so that the portion you’re using is no longer considered to be part of the available memory. On an 8086-class device, you would call interrupt 12h to determine how much memory is installed (in KiB), then hook that and return the amount reduced by however much you need — or better, change the value stored in a word in the BIOS information pages in segment 40h at offset 13h, which is used by the interrupt 12h handler. On a 286-class device with extended memory, you would hook interrupt 15h function 88h and sit at the top of extended memory. On a 386-class device, you could use V86 mode instead and then have some real fun — that’s how QEMM for example was able to implement its Stealth memory management and its fast boot option which re-initialised DOS without going through the BIOS at all. Once you’ve implemented any of these options, you can boot DOS after loading your “virus” and it won’t touch the memory you’re using.

Note that using upper memory (between 640KiB and 1MiB) without a memory manager is rather complicated: there are no guarantees that memory is actually mapped there. Typical 386+ DOS installations use EMM386 or a similar memory manager to map memory using the 386’s paging features (in V86 mode). Another approach, which works with 286-class systems too, is to use a chipset-specific driver such as UMBPCI (on Pentium-class systems) or a chipset-aware memory manager such as The Last Byte Memory Manager; these generally work by enabling “shadow memory” and using it for UMBs. So in your case you really are limited to using the top of either conventional memory or extended memory.

If you’re curious about the inner workings of all this, check out the memory managers in FreeDOS. For more advanced exploration of DOS and even Windows, I highly recommend 386SWAT which is a very sophisticated debugger. System startup, and the hoops DOS has to jump through to support the various low/UMB/high configurations it can encounter, are described in detail in chapter three of Geoff Chappell’s DOS Internals (and memory management in general occupies a significant portion of the book as a whole).

Answer 2

But the question is, how did DOS know what portions of the UMA where available?

DOS itself doesn't touch neither High-Mem (HMA) nor UMB without being ordered to do so. And even then it needs a driver capturing and providing these memory areas. Usually this is HIMEM.SYS.

If so, what if wanted to write a TSR that would monitor BIOS interrupts even before DOS is loaded?

Well, it can't be a standard TSR, as there is no DOS to load it. But yeah, as soon as there is memory above 640KiB it can be used to store a program surviving a restart and monitor activity before (and during) DOS load.

Would the OS overwrite my code or do I have any way to "protect" my TSR memory from being claimed later?

No, unless of course, you have it use HIMEM.SYS, which in turn would not hesitate, but just grab whatever is available.

---

The first task is to find some memory. HMA might seem like a good idea, but as said before, then HIMEM.SYS and DOS=HIGH can't be used at all. Better use a CGA as display adaptor, while installing some spare MDA (or vice versa), as they use different address areas in Upper Memory. OR even better, if at hand, use some (PC) memory card that allows the addition of RAM anywhere in the address space.

Now boot into DOS and start your 'special' TSR, which moves itself up into one of these additional RAM areas. The real work will be to find a combination of trigger that allows your code to keep itself in the loop during all stages of reset and boot.

If you found a way, it's all set to boot again and spy on DOS :)

Answer 3

Real-mode MS-DOS didn't care where BIOS and expansion card memory locations were and really didn't have to because it generally made use of the interrupt system for system calls. EMM386 had to do its own detective work to detect memory: note that the documentation for INT 15h AX=E820h has many caveats about what memory it shows, and I don't think that it couldn't be relied on to exist on every machine when MS-DOS 6.22 came out. INT 12h/address 0:413h was used to establish its memory map, which was correct unless something like EMM386 came afterwards to to backfill memory or extend it (which you could do if you didn't use VGA: the A0000h-AFFFFh range could be mapped and added to contiguous conventional RAM, or A0000h-B7FFFh if you only used monochrome text.)

IIRC, EMM386 used the same system that the BIOS did to locate memory: walk through physical addresses C8000h-F5FFFh (see step 27 of the link) and find a ROM signature and length. You could override this by adding explicit I=xxxx-yyyy and X=xxxx-yyyy switches to include and exclude memory, and use HIGHSCAN to use a more aggressive scan, but this was the general method.

If you wanted to run a program earlier in the boot process than DOS, you would have to alter the boot sector so that you could start before IO.SYS (@Stephen Kitt's answer details this.) The INT 12h method used by programs like hard disk manager drivers and (sadly) viruses continued to work because EMM386 had to honour the system configuration prior to going into protected mode and keep the memory map looking the same as much as possible: this is important as MS-DOS (and the expansion cards as well) were written to run in real mode and relied on memory addresses not to change.

Answer 4

DOS knows what memory is available because it requests this information from whatever upper memory manager you have installed via an XMS function call.

For example, EMM386 can be used to simulate upper memory using XMS memory (if you have an 80386 CPU or higher), and if it is doing so then it will also provide the needed XMS API functions to allow upper memory blocks to be requested.

The method used to communicate is via a particular interrupt function established by HIMEM.SYS (or a driver that provides similar functionality). HIMEM.SYS itself manages only the high memory area, for upper memory all it does is allow an upper memory manager to register itself via a hook so that it may recognize and respond to upper memory requests to request/release blocks as needed (via XMS functions 10h and 11h). For details consult the Extended Memory Specification, version 2.0 or higher (an Internet search for "xms20.txt" can be used to find this document).