DM> CB> I'm needing some suggestions on how to reasonably portable calculate 
th
DM> CB> amount of free memory left.
DM>OS/2: Use the API.  Mind you, there's much more information than you need
I'll save it and take a look at it.
DM> CB> Rather than each place checking the pointer for success, it just uses 
a
DM> CB> very simple minded wrapper that aborts the entire program if
DM> CB> unsuccessful.  That's not a very good strategy!
DM>It probably is - how often does your code run out of memory?  ;-)
Actually, as I haven't actually done anything with it, never!
And with a virtual memory system, (or even a few hundred K), it's not
likely.
D-Flat itself, probably uses, at worst, 64k.  Even for a major session.
About 300 bytes for each window, plus whatever memory to save that area
of the text screen, plus memory for dialogs and such (perhaps extra 100
bytes for the dialog window structure), plus memory for strings and
controls (such as text in a selection window, etc.).  The online help
system uses some for the index of the context sensitive help, but I
think that's only a few K, since the text itself remains on disk until a
specific section is needed.  It's actually fairly meager usage.  All of
the allocations are small ones.  I've seriously considered just
allocating 64k or so and just letting D-Flat itself use that.  (I chose
against that because of the possibility of fragmentation.)
Except for the editor. The problem is the way the editor is written.  I
need to rework it. That's the main thing that can fail.  The text is
kept in memory all at once (of course), and then when it needs to
increase the buffer, it just uses realloc, and if it fails, the whole
program aborts.  I could just fix this (and I do need to rewrite parts
of it), but even without it, the very fact that D-Flat can just fail and
simply the exit the program is not a satisfactory action.
Turbo Vision doesn't have this problem, but only because it doesn't
resize the editor buffer.  You set a fixed limit size when you
initialize the editor, and then when it's full, there's nothing you can
do about it.  I could make D-Flat like that, but I like its ability to
increase the size of the buffer as needed.
DM> CB> The real problem, I guess, is the possibility of running out of 
emory
DM> CB> abruptly, without giving the user fair warning.
DM>"If this program aborts, get more memory, or try the DPMI version."
Not everybody has that option.  If I'm going to make it 'generic', then
I need to make it really generic enough to handle most computers.
--- QScan/PCB v1.19b / 01-0162
---------------