1) QSV_TOTAVAILMEM
Apples...2) QSV_MAXPRMEM
Oranges...You are conflating two separate concepts: 'physical/virtual memory' and 'linear address space'. Here's a simplistic analogy.
You have a store with inventory (RAM) and shelving to put it on (address space). Periodically, you'll face one of two problems:
A) you want to add more shelf space but you have nothing to put on it because your entire inventory is already on the other shelves. You could put empty boxes on the shelves (i.e. swap space) to make it look like you have more inventory than you really do but eventually you'll run out of that too. In the real world, you're out of 'physical/virtual memory'.
B) you have plenty of inventory but can't put it out because the shelves where it should go are already full. In the real world, you're out of 'linear address space'.
These days 'A' isn't the problem it used to be - most of us have far more than we can use. And for many of us, we can't even find a use for all the physical RAM we _could_ use, so we never run out and *never swap*. Those of us who know their needs are modest (don't build QT6, don't keep 40-50 browser tabs open, etc.) have no reason to give physical memory a second thought.
In contrast, 'B' (linear address space) will always be an issue because OS/2 will always be limited to 512mb of low/16-bit compatible memory. It isn't as bad as it used to be with the advent of high memory (i.e linear address space whose addresses start at 512mb). Still, it's worth monitoring - which is why I wrote a little widget to do so (shameless plug).
With the possible exception of PUMon when it uses 'Win32K.sys' (which I've never seen), every monitor that attempts to show available private and shared memory suffers from the same problem: GIGO. The values returned for QSV_MAXPRMEM and QSV_MAXSHMEM are misleading and substantially useless because the same stretch of memory is included in both. To illustrate this, I've copied the screen shot of my 'memmap' widget from an earlier posting. Take a look at it.
QSV_MAXPRMEM includes both the areas in red and those in gray. QSV_MAXSHMEM includes the areas in gray and in green. What good is that? I labelled the area in gray as "Free" due to space constraints but it's more correctly labelled "Unassigned". It's available for use as either private or shared memory, whichever claims it first.
When I took the screenshot, Dooble had been open and had claimed 46mb of the unassigned memory for private use (in addition to the 64mb of private memory every app is guaranteed). Even after closing Dooble, that 46mb would remain assigned to "private" until the system was forced to reclaim it. If you were to look at a typical mem monitor, you'd get the mistaken impression that Dooble had allocated but not freed 46mb of shared memory. But that wouldn't be correct because that memory was _never_ shared, it was "unassigned".
FYI... "real" shared memory starts at the lowest address that's actually being used. If that allocation is freed, it goes back into the unassigned pool. Any memory above that which gets freed is stuck behind the dividing line and will remain shared memory - whence the figure for "Shared - unused".
FYI2... unassigned memory claimed for private use, then freed, is not reclaimed until the system has run out of shared and unassigned mem. It will then survey all running apps to see how much private memory they're actually using. If <= 64mb, it will return the excess to the pool, then use what it needs to fill the request for shared mem that triggered the review.
Correction: high mem starts at 512mb, not 1gb as originally written
