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

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

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

Show key headers only | View raw

On Tue, 03 Jun 2014 06:46:10 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> The specific question I'm having is how to best marry memory management  
> with DOS in the absence of DPMI, VCPI, protected mode, himem.sys and all  
> the rest, in real mode (or virtual 8086, as it should be transparent and  
> unimportant).
>
> [...]
>
> I want my C compiler to target DOS and make it possible for programs
> compiled with it to use all the conventional memory (that is, under 1MB)
> via malloc() while staying in the same CPU mode (real or v86).

Well, I think allocating all the memory from DOS and managing it yourself
as you mentioned is probably the place to start.  I.e., you can control
the header size used to manage each memory region, or not even use a
header, e.g., tables, stacks, linked-lists, etc.  If you can create a
more efficient method than DOS, it's probably worth doing.  I'm not
familiar with how DOS internally manages memory.  If you don't need
historic DOS memory management, that's a bonus, but very few use DOS
without XMS.

As for creating "artificial MCBs for DOS" and somehow telling DOS about
them, I'm not sure how that would work, or if it could.  I know Windows 98
has a special interface to "inherit" XMS memory structures, but I've never
heard of a method to tell DOS about MCBs created outside of DOS.  Of  
course,
there are examples of programs which patch DOS structures.

As for intending to use "all the conventional memory".  C needs contiguous
memory.  You can use most of the conventional memory, i.e., below 640K,
or below 512K to be safe since early machines stopped at 512K, minus
in-use low memory IVT, BDA, etc.  You could also allocate C objects in
the free memory blocks between 640KB and 1MB, but then you might need
to start keeping track of the ranges of valid memory so you don't
allocate something too large for the upper block, or resize the memory
and exceed the block size.  If you're going to start managing blocks
and not use existing DOS solutions, then perhaps a version of XMS could
be implemented within compiler...  No XMS, your version goes into effect.
XMS present, external XMS used.  This way, you don't have to write the
code to call two different functions.  I.e., you don't have to select
between calling your non-XMS memory manager and calling XMS.

As for allocating vie EXE header, I would probably set that very
conservatively, but not zero it, e.g., 1KB, 2KB, 4KB, and hope that
I got the dynamic heap memory allocation working correctly.  You might
test out how much you really need for a typical minimal heap.  It might
be far less than you think, e.g., 512 bytes.

Was some aspect of this about dealing with differently sized segments,
or 16-bit segment:offset versus 32-bit offsets?


Rod Pemberton

Back to comp.os.msdos.programmer | Previous | Next — Previous 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