DOS ain't dead

Memory requested by malloc and later freed by free won't be given back to DOS instant and therefore you are out of ram pretty fast because the memory becomes only available again after the exe terminated?

Can I somehow force to flush the memory to the operating system so I can request it again for other tasks?

> Memory requested by malloc and later freed by free won't be given back to
> DOS instant and therefore you are out of ram pretty fast because the
> memory becomes only available again after the exe terminated?
>
> Can I somehow force to flush the memory to the operating system so I can
> request it again for other tasks?

Are you're talking about C/C++? There is no "standard" how they implement their heap management, so at best you can ask for information about how a certain compiler does handle this issue.

Usually there are extensions available - I vaguely remember dos_allocmem() - which allow to directly alloc memory from DOS, and which can be freed once you're done.

---
MS-DOS forever!

> Are you're talking about C/C++?

Yes.

> There is no "standard" how they implement
> their heap management, so at best you can ask for information about how a
> certain compiler does handle this issue.

I used watcom.

> Usually there are extensions available - I vaguely remember dos_allocmem()
> - which allow to directly alloc memory from DOS, and which can be freed
> once you're done.

dos_allocmem exists but the informations found on google are very rare.

> dos_allocmem exists but the informations found on google are very rare.

this is what I found (MS VC 1.5):
---------------------------------------------------------------
unsigned _dos_allocmem( unsigned size, unsigned *seg );

size Block size to allocate
seg Return buffer for segment descriptor
#include <dos.h>
#include <errno.h>

Remarks

The _dos_allocmem function uses MS-DOS service 0x48 to allocate a block of memory size
paragraphs long. (A paragraph is 16 bytes.) Allocated blocks are
always paragraph aligned. The segment descriptor for the initial segment of the new block is returned in the word that seg points to. If the request cannot be satisfied, the maximum possible size (in paragraphs) is returned in this word instead.

Return Value

If successful, the _dos_allocmem routine returns 0. Otherwise, it returns the MS-DOS error code and sets errno to ENOMEM, indicating insufficient memory or invalid arena (memory area) headers.

---------------------------------------------------------------

---
MS-DOS forever!

> ... the memory becomes only available again after the exe terminated?

How did you check that?

---
Forum admin

> > ... the memory becomes only available again after the exe terminated?
>
> How did you check that?

While the application was running, malloc 500 K memory, ok, freeing, malloc 500 K again, failed.

> > > ... the memory becomes only available again after the exe terminated?
> >
> > How did you check that?
>
> While the application was running, malloc 500 K memory, ok, freeing,
> malloc 500 K again, failed.

Then you must be doing something wrong. Could you please post a short source code example to reproduce this behaviour?

---
Forum admin

> Then you must be doing something wrong.

Yeah. :)

> Could you please post a short
> source code example to reproduce this behaviour?

http://nopaste.com/p/azIAZwhSW

It's a bit strange. Initially I can malloc 500 * 1024 (and also 650 * 1024 which would be 650 KB) and later in the loop it breakes after 59 * 1024 (which should be only 59 KB) due to malloc error.

> It's a bit strange. Initially I can malloc 500 * 1024 (and also 650 * 1024
> which would be 650 KB) and later in the loop it breakes after 59 * 1024
> (which should be only 59 KB) due to malloc error.

(Note: I don't really know C++, so take this with a grain of salt.)

Why are you using long double to define how much you want? Floats / doubles are always stored differently. Plus, you're mixing C malloc() with C++ stuff instead of using new / delete (why?). Anyways, at least DJGPP (for example) won't malloc() any mem until you actually need it, unlike calloc().

P.S. Try asking in openwatcom.users.c_cpp if none of us can help.

EDIT: 650k should never work (else you're doing something VERY weird).

> EDIT: 650k should never work (else you're doing something VERY weird).

This sounds all like it is in FPC, so maybe this is a 32-bit compiler?

(malloc (getmem) allocates from 32-bit mem, dos_alloc from realmode mem (which is unused, except for 100k extender stuff) so a malloc(650k) will work (even a 128MB could), but dos_alloc(650k) won't.

> Memory requested by malloc and later freed by free won't be given back to
> DOS instant and therefore you are out of ram pretty fast because the
> memory becomes only available again after the exe terminated?
>
> Can I somehow force to flush the memory to the operating system so I can
> request it again for other tasks?

If you use the system malloc in the default setup, this will be very hard. Why? After a bunch of mallocs the whole memory is fragmented like a big cheese. So even while e.g. half of the mem is still free, there is no contiguous block of that size that is free at the end of the memoryspace.

So that means you will have to limit your heap, and/or manually administer it, so that the parts that you free before doing (what I assume is shelling) are really free in one contiguous block. Then you can probably call some sbrk() a like to shrink the datasegment and shell.

Somewhat fancier is to swap the entire real mode mem to ems before shelling, but that means undoing any callbacks you have installed (e.g. interrupt vector fiddling)

In the 32-bit case, this could be easier, since then you can simply not use the dos 640k much, and extenders often already allow to swap the remaining content out, except for some core extender interrupt handlers. Is your watcom 32-bit or 16-bit?