No idea how to query the free memory amount, but malloc() and new both allocate from the same memory. "Heap" and "free store" mean the same thing. In fact, 'new' calls malloc() internally to allocate memory, at least on the C++ implementations I'm familiar with.

In the Borland compilers it was coreleft() IIRC

In real mode assembly I've just used the program segment prefix method, where you sub the address of the psp from the address past the end of your program's pre-allocated memory (given as a word at the third byte of the psp). I'm not aware of this being a reliable metric though.

in general i want it three ways:
1. is there an interface on this from the dos extender? assume i am using djgpp/cwsdpmi or watcom/dos4gw.
2. is there any standard c/c++ library on this?
3. is there any dos interrupt feature on this?

call bios in general; as for extenders they sure do have something but i wouldnt know; at the very least allocation should tell you

i looked up djgpp library reference and found a few functions:
__dpmi_get_free_memory_information
__dpmi_get_memory_information
_go32_dpmi_get_free_memory_information
_go32_dpmi_remaining_physical_memory
however, whats the difference between them, and which one should i use?
__dpmi_get_memory_information is said to require dpmi1.0, while cwsdpmi supports only dpmi0.9, does that mean it would never work?

I wonder if those functions get...
a) the amount of memory left in your data segment.
b) the amount of memory left in DOS pool (i.e.: the 512 or 640Kb installed minus the memory already taken by OS, other processes and your program).
c) the amount of physical memory left(in 386 protected mode or in Windows 32/64 bits).
d) the amount of memory left for this process (in some Windows, you had only 2Gb available per process).
e) the total of memory left (I mean, physical plus virtual).

Zup wrote:

I wonder if those functions get... a) the amount of memory left in your data segment. b) the amount of memory left in DOS pool ( […]
Show full quote

I wonder if those functions get...
a) the amount of memory left in your data segment.
b) the amount of memory left in DOS pool (i.e.: the 512 or 640Kb installed minus the memory already taken by OS, other processes and your program).
c) the amount of physical memory left(in 386 protected mode or in Windows 32/64 bits).
d) the amount of memory left for this process (in some Windows, you had only 2Gb available per process).
e) the total of memory left (I mean, physical plus virtual).

not really. only _go32_dpmi_remaining_physical_memory returns an integer indicating available ram, other functions all return with complicated structures containing various information on memory.
however i am still not sure which one i should use...

further issues:
__dpmi_get_memory_information doesn't work with cwsdpmi, as it requires dpmi1.0.
the rest 3 seemed to work, but their results doesn't change after i malloced 4mb of ram(malloc seemed successful anyway as the returned pointer is not null) or free that ram.
what else shall i do to keep an eye on how much ram is left for use?

also, is there any equivalent in microsoftc or borlandc in real mode? and what can one do within 576kb of conventional ram(assume 64kb is used by dos and essential tsrs like rat driver)?
if i compile in large or compact mode, can i malloc over 64kb of ram in a single line?

http://www.delorie.com/djgpp/v2faq/faq15_2.html

noshutdown wrote:

the rest 3 seemed to work, but their results doesn't change after i malloced 4mb of ram(malloc seemed successful anyway as the returned pointer is not null) or free that ram.

That could be because malloc() is implemented using its own heap, in the C library.
So that means that the C library probably allocates a certain heap from the DPMI memory at startup, and calls to malloc() will take from that heap, not changing the DPMI memory (until the heap needs to be grown).
In that case there should be a function in the C library to query how much memory there is left on the heap. But that is proprietary, not part of the C standard.

if i compile in large or compact mode, can i malloc over 64kb of ram in a single line?

Yes, and in fact, if you compile in other modes, you can still use the 'big' malloc function, it is called farmalloc(), _fmalloc() or something like that.
Using a larger model simply makes this farmalloc() the default malloc() (and you can still use a nearmalloc() as well).
I personally always use small model, so I can get code and data in a single segment whenever I want, and use the far keyword to get access to other segments and buffers larger than 64k.

Query Free Extended Memory (Function 08h):
------------------------------------------

ARGS: AH = 08h
RETS: AX = Size of the largest free extended memory block
in K-bytes
DX = Total amount of free extended memory in K-bytes
ERRS: BL = 80h if the function is not implemented
BL = 81h if a VDISK device is detected
BL = A0h if all extended memory is allocated

This function returns the size of the largest available extended memory
block in the system.

NOTE: The 64K HMA is not included in the returned value even if it
is not in use.

root42 wrote:

http://www.delorie.com/djgpp/v2faq/faq15_2.html

thanks, i replaced malloc with new and now the report does indicated corresponding amount of ram being used.
now onto next question: what to do with other compilers without dpmi?

doaks80 wrote:

Query Free Extended Memory (Function 08h): ------------------------------------------ […]
Show full quote

Query Free Extended Memory (Function 08h):
------------------------------------------

ARGS: AH = 08h
RETS: AX = Size of the largest free extended memory block
in K-bytes
DX = Total amount of free extended memory in K-bytes
ERRS: BL = 80h if the function is not implemented
BL = 81h if a VDISK device is detected
BL = A0h if all extended memory is allocated

This function returns the size of the largest available extended memory
block in the system.

NOTE: The 64K HMA is not included in the returned value even if it
is not in use.

yeah but which interrupt is this, 21h or something? does it work with conventional ram too?
and, how does mem.exe and chkdsk.exe report amount of free ram?

This is XMS: http://www.phatcode.net/res/219/files/xms30.txt

You need to query the XMS control function address via int 2Fh and can then call the control function with above mentioned arguments.

Note that this ONLY reports XMS extended memory. So I do not think this will help you with DPMI / protected mode that may use more than the XMS, or does not even necessarily rely on XMS.

Scali wrote:

Yes, and in fact, if you compile in other modes, you can still use the 'big' malloc function, it is called farmalloc(), _fmalloc() or something like that.
Using a larger model simply makes this farmalloc() the default malloc() (and you can still use a nearmalloc() as well).
I personally always use small model, so I can get code and data in a single segment whenever I want, and use the far keyword to get access to other segments and buffers larger than 64k.

but why do documents say "huge is mostly the same as large, except that it allows single array larger than 64kb"?

root42 wrote:

This is XMS: http://www.phatcode.net/res/219/files/xms30.txt

You need to query the XMS control function address via int 2Fh and can then call the control function with above mentioned arguments.

Note that this ONLY reports XMS extended memory. So I do not think this will help you with DPMI / protected mode that may use more than the XMS, or does not even necessarily rely on XMS.

i see, but this is not very useful as xms driver is not always guaranteed to be present, and i've settled with dpmi in djgpp.
now the remaining problem is how to report free conventional ram with a compiler in real mode. in borlandc there is coreleft(), but borland admitted that its not very accurate, as it only returns space from the top of DOS memory down to the last allocated block, and would not include any previously used but now freed blocks below that, so it takes more to sum up.
and i wanna know how mem.exe and chkdsk.exe reports free conventional ram?

Different dos extenders will do different things, some might use swap space etc. dpmi vs vcpi.. then you get into heap vs stack... its not like dos where you can do ah=0x48,bx=-1 and get paragraphs free.

djgpp, cswsdpmi will often use swap unless told not to. or another extender is present.

watcom... sooo many extenders to choose from, so many options of memory. (pmodew, wdosx, dos32a, dos4g pro, dos4g non-pro)

noshutdown wrote:

but why do documents say "huge is mostly the same as large, except that it allows single array larger than 64kb"?

There are basically 3 kinds of pointers in 16-bit segmented mode.
As you probably know, a pointer is a combination of two 16-bit integers, segment and offset.
The linear address is formed by (segment*16)+offset.

A near pointer stores only the offset, the segment is the 'default' segment for data or code. The advantage is that pointers are smaller, and pointer arithmetic is faster, because the segment is fixed.
A far pointer stores offset and segment, but the segment is 'static'. That is, pointer arithmetic only updates the offset part. This is still relatively fast, but obviously limits you to a 64k block of data starting at the given segment.
A huge pointer updates both segment and offset, which allows you to address all memory as if it is linear. So you can use it for arrays of more than 64k, but it is also the slowest.

In a huge model, all pointers are huge by default.