From: schornak@nospicedham.web.de   
      
   Robert Wessel wrote:   
      
      
   > On Wed, 17 Oct 2018 21:48:54 +0200, Bernhard Schornak   
   >  wrote:   
   >   
   >> Robert Wessel wrote:   
   >>   
   >>> On Wed, 17 Oct 2018 10:45:39 -0700 (PDT),   
   >>> sdn45478@nospicedham.gmail.com wrote:   
   >>>   
   >>>> My understanding of how a COM program really works (in real life)   
   >>>> is that DOS reserves ALL 640K memory and all segments are supposed   
   >>>> to point to the code segment (64K or less). When you reallocate it   
   >>>> is up to you to define the SS. If you are mixing your COM program with   
   >>>> other code not in ASM then as Emilly Latella would say (never mind),   
   >>>> might as well use an EXE. I routinely use all available ram with tiny COM   
   >>>> programs and have never had a problem, but for COM programs NASM   
   >>>> doesn't assume anything, you must tell it.   
   >>>   
   >>> Actually DOS reserves all of the free memory segment it decides to   
   >>> allocate to the .COM, which may not be all of free memory if the   
   >>> storage is fragmented.  Which fragment was selected did change over   
   >>> time, but I don't believe it was always simple "biggest available".   
   >>   
   >>   
   >> As DOS is no multitasking OS, you can read all RAM you can address   
   >> and write data to all memory locations not assigned to DOS and the   
   >> BIOS functions. (You could write over those memory blocks as well,   
   >> but that might crash the machine when the code there is invalid.)   
   >   
   > There are still other things in the system that can have allocated   
   > RAM.  A TSR, or a parent program, for example.  While you *can*   
   > overwrite the storage allocated for those, it's generally a bad idea.   
   > So when DOS allocates storage for a new program being executed, it   
   > would allocate the entirety of one of the free areas (assuming there   
   > was more than one).   
      
      
   Each address occupied by a TSR can be found in the interrupt vector   
   table. Generally, TSRs were loaded before anything else runs, so we   
   can assume DOS put them at the bottom (below the addresses assigned   
   to user programs started later in the chain). I *never* encountered   
   any problem using the RAM starting at the end of my .COM file up to   
   9000:FFFF (inclusive zeroing those bytes for later use by the first   
   database engine I wrote). It should be clear that we cannot use the   
   entire RAM above A000:0000, but unused parts of the memory reserved   
   for graphics and expansion cards surely can be used as private area   
   to store even more data.   
      
   Because DOS puts itself to sleep until the launched program decides   
   to terminate itself and return control to DOS, there is *no* reason   
   to abstain from using the entire RAM behind ourself or assuming DOS   
   might launch another program using the same resources. Only if your   
   code starts other instances there might be a reason to care about a   
   shared environment...   
      
      
   Greetings from Augsburg   
      
   Bernhard Schornak   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)