I recall that expanded memory managers were needed for many DOS games.

Not so much, no. Many DOS games included their own "DOS extenders" that took care of everything on their own.
https://en.wikipedia.org/wiki/DOS_extender

QEMM was indeed very popular, but many games came with instructions noting that there may be potential incompatibilities (particularly in "stealth mode").

EMM386 is most important nowadays as it is required for the magic tricks performed by the PCI Sound Blaster DOS driver. I expect QEMM would also work for that. JEMM386 is a free open-source expanded memory manager that tends to work very well, but it will not work with Windows. (EMM386 also doesn't technically "work" with Windows, but it is safely and automatically disabled when Windows is in use.)

Nowadays none of this really matters like it used to. On a DOS gaming PC, pretty much the only TSRs you'll have are a mouse driver and maybe a CD-ROM driver, and there are some much better options for those now than there used to be, like SHSUCDEX and CuteMouse. It's not like back when people also wanted to do work on their computers and were running other things. UMBPCI is also extremely popular for providing upper memory blocks without much of the overhead of EMM386 or its alternatives.
http://www.uwe-sieber.de/umbpci_e.html

There were the games that needed base memory maximized - using a memory manager and/or a stripped down configuration.

Not sure if there were many games which actually USED the HIMEM / EMM386 setup.

There were also a good many which used their own DOS extender / memory manager, with vary degrees of (in)compatibility with other memory managers.

In the old days of network drivers and Win3, I swore by (and at) MEMMAKER - actually, more important than what MEMMAKER came up with, was it's ability to log the load size and final size of the components, allowing me to reposition some, moving those with high load to final ratio to earlier positions if possible.

Also, if EMS was needed, I moved the page frame down to the end of the VGA, to avoid splitting the UMB - the only real need for MEMMAKER was to tune allocation of multiple UMB blocks, and even then, the aforementioned reverse load size order sorting would probably allow it to make a better fit.

PS. Things with self-loadhigh such as CTMOUSE generally did a good job of fitting, taking any load size burden before locating to UMB

PS. For UK Keyboard, I seem to recall another utility (can't find it now) I think called UKKEYB.SYS which just altered the few different keys and was many times smaller than KEYB UK

I agree with the other posters. IMHO the EMM386/MemMaker combo is probably the easiest, albeit a bit slow on 386/486 machines sometimes.
In virtual machines or on Pentium machines, the use of V86 can quite improve performance, though.
I'm speaking under correction, though. I haven't gained so much experience with EMM386.
I'n fact, I'm avoiding it whenever possible, as I prefer to run my DOS in Real-Mode without interception.
This goes so far as that I'm still using these old expanded memory boards (lo-tech still sells primitve versions of them, btw). ^^
Games that can utilize EMS are, for example, Commander Keen 4 (page frame only), Wing Commander and Lollypop.

The previous posters explained it quite well.

I will add that I never used anything other than EMM386, nor ever needed to. In principle, I could rely on UMBPCI (which I didn't know about it at the time) for 95% of scenarios, but I did have a few games that actually needed EMS.

I could consistently get 610K+ of conventional memory free using some basic EMM386 configurations, loading all the drivers /TSRs I needed, which were not many - CD driver (VIDE-CDD + MSCDEX), mouse (CuteMouse), Doskey and SmartDrive. 610K is more than any game I know of can possibly need, so it was good enough for me without tweaking anything.

Now, if I had the need for more stuff (Networking? sound cards that use TSR? Antivirus real-time scanners? Multiple code pages?) I would probably need to tweak it more, perhaps use a more advanced tool for some configurations, have multiple configurations, etc. But the need hasn't come up.

Now, a question that I've been thinking about and never found a full answer to - can all these extra tools and third party memory managers (MemMaker / QEMM / etc) actually do something that EMM386 cannot? Or would, you, if you had known the optimal memory ranges / order of driver/TSR loading, be able to achieve the same using only EMM386 and its switches, and reordering the lines in Config/Autoexec?

dr_st wrote:

Now, a question that I've been thinking about and never found a full answer to - can all these extra tools and third party memory managers (MemMaker / QEMM / etc) actually do something that EMM386 cannot? Or would, you, if you had known the optimal memory ranges / order of driver/TSR loading, be able to achieve the same using only EMM386 and its switches, and reordering the lines in Config/Autoexec?

It was my understanding that conveniently rearranging your startup files is pretty much all MemMaker really does.

I also understand that QEMM and JEMM386, and even alternative versions of EMM386 from DR-DOS, may have substantially lower overhead than Microsoft's EMM386. I thought I remembered seeing some neat comparisons at www.mdgx.com, but I can't seem to find them at the moment.
See also https://en.wikipedia.org/wiki/QEMM .

Sorry for dragging up this old topic, but I didn't see a point in making a new one. I've got a few questions that fit this thread. Can any driver be loaded into high memory, and is there a way to check the amount of free conventional memory available?

Most drivers can be loaded into upper memory, the notable exceptions being the drivers that actually make upper memory available (XMS manager, EMS manager, and a small part of DOS's core).

Running MEM with no arguments shows you the amount of free memory - conventional, upper, extended (XMS) and expanded (EMS), if they are available. Running MEM /C /P shows a more detailed split of what's loaded where; running MEM /D /P displays even more detailed information.

Also note that there's a mismatch in German DOS, in regards to high memory and upper memory, so that might be in other language releases, too.
These localized DOS releases (mainly DOS 5 and 6) mixed up the meanings of the terms high memory and upper memory for some reasons.
The terminology was fixed in DOS 7 and higher. See http://www.dosforum.de/viewtopic.php?p=84553

Thanks for the replies. I think I've about got it figured out now. I think I've got about 615k free at the moment, not a bad number.

CMR779 wrote:

Thanks for the replies. I think I've about got it figured out now. I think I've got about 615k free at the moment, not a bad number.

I get 634k free using QEMM 97 on MS-DOS 6.22. That's with cd-rom, mscdex, smartdrv, mouse (the 24k Microsoft one), softmpu, doskey and setver all loaded. And there's still 40k of upper memory left.

AFAIK, 634k is actually the theoretical maximum of free conventional memory in DOS. I don't think you can get any more. Not even DOSBox gives any more. So QEMM hitting that maximum is quite nice.

I've gotten 635K in QEMM

If you had enabled QEMM patented "Stealth" mode to obtain large area of upper memory block, then it might break certain software. I had only come across one Taiwanese game that actually requires 620KB of free conventional DOS memory to run, so anything more than that would be artificial. I was able to get 628KB with HIMEM.SYS and UMM.SYS on Win98 DOS 7.1 UMM.SYS is public domain open-sourced and its resident size is only 64 bytes. It can be customized easily to add chipsets programming to enable upper memory block. For 32KB VBIOS, no USB, I used to have 192KB of upper memory block from 0xC8000-0xEFFFF. No V86 mode overhead, so as the games didn't require EMS memory, this is the best and most compatible configuration.

realnc wrote:

AFAIK, 634k is actually the theoretical maximum of free conventional memory in DOS.
I don't think you can get any more. Not even DOSBox gives any more. So QEMM hitting that maximum is quite nice.

On a VGA machine ? If you've got CGA or Hercules graphics, then there's no 640KiB limit. End of the road would be 704KiB (HGC/MDA) or 736KiB (CGA) then. 😉

Edit: I also recommend reading tha old InfoWorld review about Netroom by Helix software.

kjliew wrote:

If you had enabled QEMM patented "Stealth" mode to obtain large area of upper memory block, then it might break certain software.

Interesting. Do you have an example of something that breaks?

kjliew wrote:

I had only come across one Taiwanese game that actually requires 620KB of free conventional DOS memory to run, so anything more than that would be artificial.

That's news to me. I never encountered a game requiring anything close to that. 😀

One case to be made for aiming for a lot of conventional RAM (>610K) is if you want to load specific memory-heavy TSRs, while playing games (like a music player that stays in the background); that might eat a few tens of KB.

kjliew wrote:

I was able to get 628KB with HIMEM.SYS and UMM.SYS on Win98 DOS 7.1 UMM.SYS is public domain open-sourced and its resident size is only 64 bytes. It can be customized easily to add chipsets programming to enable upper memory block. For 32KB VBIOS, no USB, I used to have 192KB of upper memory block from 0xC8000-0xEFFFF. No V86 mode overhead, so as the games didn't require EMS memory, this is the best and most compatible configuration.

That's very cool. I agree that it's the best if you don't need EMS. If you need EMS, then with Win98 DOS it should be rather easy to achieve 621KB free with HIMEM/EMM386 (624KB if IFSHLP is excluded).

dr_st wrote:

kjliew wrote:

If you had enabled QEMM patented "Stealth" mode to obtain large area of upper memory block, then it might break certain software.

Interesting. Do you have an example of something that breaks?

I don't remember specific examples, but I do remember that I came across a game or application from time to time that refused to work with "stealth" enabled.

Fortunately, you don't really need that function. It's only useful if you really have tons of drivers and TSRs.

Another compatibility issue with QEMM is its "DOS-up" function. It can load most of DOS into upper memory even in DOS 6.22. Normally only DOS 7 does that. But if you do that, I found at least one game that gets bugged (Ultima 8, the intro sequence doesn't play.) So you need to configure QEMM (using QSETUP) to do "partial" DOS-Up, setting "Resources", "COMMAND.COM" "DOS=HIGH" to "Yes", but "DOS Data" to "No". Which fixes the problem, but drops you from 634k free to 630k free (or 629k free.)

kjliew wrote:

One case to be made for aiming for a lot of conventional RAM (>610K) is if you want to load specific memory-heavy TSRs, while playing games (like a music player that stays in the background); that might eat a few tens of KB.

Usually you can load those TSRs into high memory too. With QEMM, you just prefix them with "loadhi" (not loadhigh). Most TSRs will happily work from upper memory. Actually even normal programs will mostly work. For example, I can run Norton Commander with "loadhi nc" and it runs from upper mem just fine.

Without QEMM, though, you will probably not have sufficient upper memory, or large enough contiguous blocks of it (after you load the fundamental drivers/TSRs).

In any case, these are specific and uncommon scenarios. Once I realized I can get ~620K without any advanced tools, I stopped messing with it.

dr_st wrote:

kjliew wrote:

If you had enabled QEMM patented "Stealth" mode to obtain large area of upper memory block, then it might break certain software.

Interesting. Do you have an example of something that breaks?

By the end of 486 era and the dawn of Pentium era, especially the introduction of PCI local bus and PnP, there are standard software interfaces defined as 16-bit/32-bit entry points for protected mode software by scanning for the magic tables in ROM. I remember PCI, PnP and VESA, all have such ROM table. QEMM "Stealth" mode functional concept is based on 386/pre-486 era of software interfaces where everything was going through INTxx. So when QEMU "Stealth" mode is enabled, it scans the interrupt vector table for every pointer into ROM and redirect them to itself. It is expecting callers to use INTxx to invoke a ROM function so that it gets the chance to unmap the upper memory and expose the underlying ROM. This does not work for protected mode software that directly scan for the entry points in ROM. Fortunately, the same software interface always has an equivalent INTxx mechanism for real-mode software, and would be the fallback when ROM scanning failed.

realnc wrote:

For example, I can run Norton Commander with "loadhi nc" and it runs from upper mem just fine.

Huh, what happened to NCSMALL, the loader for Norton Commander's NC main executable ?
I always used that in NC 1.x and it apparently was also still in the brand new NC 2.0 releases.
On DOS 6.2, I used to run Norton Commander via LH NCSMALL. 😀

Jo22 wrote:

Huh, what happened to NCSMALL, the loader for Norton Commander's NC main executable ?
I always used that in NC 1.x and it apparently was also still in the brand new NC 2.0 releases.

Never heard of it. The earliest version of Norton Commander I've ever used was 5 😜