Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #1391

Re: huge memory model, malloc() and sytem()

Show all headers | View raw

On Tue, 03 Jun 2014 04:01:17 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> I'm thinking of a heap implementation in a compiler targeting
> DOS and I'm a bit unsure how to do it.
>

May I take it that you're not wanting me to mention Doug Lea's
dlmalloc, John Walker's BGET, and Richard Harter's DSA, yet again.
Yes?  (i.e., a.o.d. 2006, 2007, 2007 ...)

> You see, if the compiled program uses either the tiny or the small  
> memory model (with all pointers being near), it's confined to 64-128KB,  
> within which the heap resides, and there's plenty of memory left for  
> this program to execute another program (via system() and the like).
>
> Now, if the program uses the huge memory model (with all pointers being  
> far), its heap can occupy whatever is left after loading the program  
> into the RAM. If I set the EXE header's maximum alloc field to the max,  
> then all (or almost all of) the memory will be allocated at load time  
> and there will be nothing left to execute another program. So, that's  
> definitely not a good thing to do.
>
> Let's see what the options are.
>
> First of all, I could, of course, set up the EXE header appropriately to  
> limit the amount of memory DOS would reserve at load time and thus limit  
> the size of the heap. But whichever value I choose, it might be too  
> little or too large, depending on what the program is actually going to  
> do. I'd like to avoid hard coding the value or having to specify it  
> explicitly at compile time.
>
> Next, I could pre-allocate nothing per the EXE header and instead simply  
> ask DOS to allocate memory for me and have malloc() and free() pretty  
> much thin wrappers around the appropriate int 21h functions. While that  
> would definitely work, I will be at the mercy of DOS and I'll have to  
> swallow the overhead of the memory control block (AKA MCB) preceding  
> every allocated block of memory. The MCB, if you didn't know, is 16  
> bytes long, and that is at least twice as big as necessary. Also,  
> there's the overhead of allocating anything smaller than 16 bytes  
> because int 21h memory functions work with 16-byte chunks. I'd like to  
> avoid these overheads as well.
>
> Which got me thinking...
>
> How acceptable would be (was something like it a common practice in  
> other compilers?) to allocate all the memory from DOS, manage it  
> manually, and then, inside system() free whatever memory isn't used by  
> creating artificial MCBs for DOS and then get it back from DOS when  
> system() is over?
>
> Basically, I want to be flexible w.r.t. default/hard-coded sizes and yet  
> with as little MCB overhead as possible. All that without driving DOS  
> crazy.
>
> Any other options?
>

Well, I came late to the programming DOS thing, around 2004.  AIUI,
DOS memory allocation calls will only allow you to allocate below 1MB.
That's acceptable for small memory models, but really, you want to
access all that wonderful, uncluttered, bountiful memory above 1MB
without any restrictions.  Yes?

There is EMS, XMS, VCPI, DPMI, etc used for memory allocation and
PM environments in DOS.  However, I like the combination of XMS and
DPMI.  XMS 3.0 can allow you to access upto 4GB.  Many DPMI hosts will
use XMS for their memory allocation calls when XMS is present.  Some
XMS clients will use BIOS E820h call instead of E801h or earlier calls.
So, I'd suggest either XMS or DPMI, if you're wanting to use an
existing memory manager.  If you use Microsoft's HIMEM, then Windows
98/SE can "inherit" the mapped XMS memory via a special interface.

If you're not wanting a memory manager, then I'd suggest the
memory allocators mentioned above and on a.o.d. in 2007 or so.

Of course, the *fun* is to create your own.  ;-)  That's when the
insanity or genious is expressed in code.  That's when you get to
test out your ideas for speed or effectiveness or simplicity.


Japheth HIMEMX
http://www.japheth.de/Jemm.html


Rod Pemberton

Back to comp.os.msdos.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

huge memory model, malloc() and sytem() "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-06-03 01:01 -0700
  Re: huge memory model, malloc() and sytem() "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-03 06:11 -0400
    Re: huge memory model, malloc() and sytem() "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-06-03 03:46 -0700
      Re: huge memory model, malloc() and sytem() Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-06-03 18:49 -0400
      Re: huge memory model, malloc() and sytem() "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-04 03:14 -0400

csiph-web