Extended memory

[Peter Tipton]

Dear fellow MS-DOS C programmers:

I am a Microsoft C 6.0 user thinking of switching to Borland C++
3.1. My main concern is accessing about 7 megs of extended memory past
the 640K limit imposed by DOS. I am already using large linked lists
rather than multidimensional arrays to conserve memory, but I still need
more. Does anyone know about Borland's Extended Memory Interface or its
VROOM features? For example, will it let me access this much memory? Is
there a counterpart in Borland C++ to Microsoft's _huge pointers? Can I
mix memory models with Borland (i.e. _huge pointers with a large memory
model compilation)? Any other thoughts on or reactions to Borland's
product would be much appreciated.

 

[Ben Pfaff]

I am a Microsoft C 6.0 user thinking of switching to Borland C++
3.1. My main concern is accessing about 7 megs of extended memory past
the 640K limit imposed by DOS. I am already using large linked lists
rather than multidimensional arrays to conserve memory, but I still need
more. Does anyone know about Borland's Extended Memory Interface or its
VROOM features? For example, will it let me access this much memory? Is
there a counterpart in Borland C++ to Microsoft's _huge pointers? Can I
mix memory models with Borland (i.e. _huge pointers with a large memory
model compilation)? Any other thoughts on or reactions to Borland's
product would be much appreciated.

I think that this question would be more likely to receive good
responses in comp.os.msdos.programmer.

 

[Sjouke Burry]

Dear fellow MS-DOS C programmers:

I am a Microsoft C 6.0 user thinking of switching to Borland C++
3.1. My main concern is accessing about 7 megs of extended memory past
the 640K limit imposed by DOS. I am already using large linked lists
rather than multidimensional arrays to conserve memory, but I still need
more. Does anyone know about Borland's Extended Memory Interface or its
VROOM features? For example, will it let me access this much memory? Is
there a counterpart in Borland C++ to Microsoft's _huge pointers? Can I
mix memory models with Borland (i.e. _huge pointers with a large memory
model compilation)? Any other thoughts on or reactions to Borland's
product would be much appreciated.

Use the Watcom free compiler, quite professional, has 16 ans 32 bit
support, and a very useful help function.
(oh and if you need it , also an assembler and a fortran compiler)

 

[Gene]

Dear fellow MS-DOS C programmers:

     I am a Microsoft C 6.0 user thinking of switching to Borland C++
3.1.  My main concern is accessing about 7 megs of extended memory past
the 640K limit imposed by DOS.  I am already using large linked lists
rather than multidimensional arrays to conserve memory, but I still need
more.  Does anyone know about Borland's Extended Memory Interface or its
VROOM features?  For example, will it let me access this much memory?  Is
there a counterpart in Borland C++ to Microsoft's _huge pointers?  Can I
mix memory models with Borland (i.e. _huge pointers with a large memory
model compilation)?  Any other thoughts on or reactions to Borland's
product would be much appreciated.

Traditional linked lists usually require _more_ memory than carefully
allocated arrays because you'll use at least four bytes per pointer in
addition to the data space. Moreover, if you call malloc() to allocate
list nodes, there is probably a space overhead (often 4 bytes) for an
allocation header. You might want to look at DJ Delorie's good old
djgcc http://www.delorie.com/djgpp/ . I ran programs requiring over
100 MB of RAM under MSDOS with that system. I don't think it's
activly maintained any more, but neither is MS V6 or BCC.

 

[Peter Nilsson]

...You might want to look at DJ Delorie's good old
djgcchttp://www.delorie.com/djgpp/.  I ran programs
requiring over 100 MB of RAM under MSDOS with that
system.  I don't think it's activly maintained any
more, ...

Don't be fooled by the 'last updated' references on the
web pages. Unless it's been abandoned in the last twelve
months, it's still keeping good pace with gcc.