Heap Overlays?

[jeff]

I am running Turbo C 3.0 in a DOS environment on an embedded board with
16MB DRAM installed. The heap at initialization is limited to about 490
kb, and is running out after less than an hour of malloc-ing memory to
build linked lists of messages from attached sensors. Any clues on how
to get the heap into extended memory, which is lying unused now?

 

[Keith Thompson]

I am running Turbo C 3.0 in a DOS environment on an embedded board with
16MB DRAM installed. The heap at initialization is limited to about 490
kb, and is running out after less than an hour of malloc-ing memory to
build linked lists of messages from attached sensors. Any clues on how
to get the heap into extended memory, which is lying unused now?

Try asking in an MS-DOS forum. comp.os.msdos.programmer looks like
a good possibility, but I don't know how active it is.

(Cue "MS-DOS is dead" responses.)

 

[Seebs]

I am running Turbo C 3.0 in a DOS environment on an embedded board with
16MB DRAM installed. The heap at initialization is limited to about 490
kb, and is running out after less than an hour of malloc-ing memory to
build linked lists of messages from attached sensors. Any clues on how
to get the heap into extended memory, which is lying unused now?

You need a newsgroup specific to your DOS environment, because this is
a feature of the environment, not a feature of C.

-s

 

[Sjouke Burry]

I am running Turbo C 3.0 in a DOS environment on an embedded board with
16MB DRAM installed. The heap at initialization is limited to about 490
kb, and is running out after less than an hour of malloc-ing memory to
build linked lists of messages from attached sensors. Any clues on how
to get the heap into extended memory, which is lying unused now?

Download the watcom compiler(free),and be able to use the whole
16MB.
It has a 16bit compiler and a 32bit one with extender(dos4gw.exe).

 

[Gene]

Download the watcom compiler(free),and be able to use the whole
16MB.
It has a 16bit compiler and a 32bit one with extender(dos4gw.exe).

Another option is DJ Delorie's DJGPP, which is a version of gcc that
uses extended memory to get access to whatever's in the machine.

 

[BGB / cr88192]

Try asking in an MS-DOS forum. comp.os.msdos.programmer looks like
a good possibility, but I don't know how active it is.

(Cue "MS-DOS is dead" responses.)

on most desktops maybe...

but, it is mentioned that it is an embedded system, and DOS (among many
others) live on in the embedded-systems space...

 

[John Kelly]

on most desktops maybe...

but, it is mentioned that it is an embedded system, and DOS (among many
others) live on in the embedded-systems space...

I still have Turbo C 2.0. That was a classic. Runs in DOSEMU on linux.

 

[BGB / cr88192]

I still have Turbo C 2.0. That was a classic. Runs in DOSEMU on linux.

I have a different version, still for DOS though, around here somewhere...

not as much reason to use it anymore though, since more likely I would use
DPMI or similar anyways.
last time I did much real-mode development, I had ended up writing all of
the RM code in assembler.


but, I have seen some embedded boards before which I guess just sort of fake
a 386 or 486 with a smallish amount of RAM (and maybe a flash-based HD or
similar), and it seems many install DOS (or FreeDOS) on these boards...

however, I haven't really personally worked with these (have seen them in
action though, like a small embedded panel device being reset, to reveal a
POST screen, followed by the usual DOS startup messages, then followed by
the UI coming up...).

many other devices run Linux and similar as well.

it is a mystery though which ones are more common, and how many of the ones
doing x86 have "real" x86 chips (of some sort), vs say ARM and a
firmware-level emulator, or similar... (well, I guess there is Intel Atom
and VIA Nano and Vortex86 and similar, and they probably have some market,
so yeah, probably makes sense...).


or such...