So I'm working on a DOS project (writing a game engine in 8086 assembler, to be specific.) I'd like to build it as a COM file, mostly to save myself the hassle of linking individual bits together. If Wikipedia is to be believed, DOS's memory-management facilities are not available to COM programs; it states that "all memory is available to the application." This suits me fine, as I wanted a couple facets of memory management to line up with the rest of the engine more neatly, and it wasn't all that hard to hack up replacements for the routines I need. The thing is, I'm also trying to write the engine to play nicely with its operating environment; I want it to be able to make a nice clean exit and leave the computer in exactly the same state it found it, and I want to make sure that I know how to do my own memory management without clobbering any drivers or other TSR software loaded into conventional memory.
I'm currently figuring that it's a safe assumption that the program will be loaded fairly low in memory, so I don't need to bother with reading or writing below the start of the program segment, which means that I only need to worry about stuff that's been loaded under the top boundary of the conventional memory area (it's my understanding that this is where DOS and drivers tend to go.) I see an entry in the Program Segment Prefix for memory size, and what I'm wondering is if this reflects the actual, physical amount of conventional memory installed, or the amount free when my program was loaded; i.e., can I rely on that value to tell me where I should not write past?