IMO, yes (as previously noted), QEMM is excellent, but the tools provided by M$ are already installed
For most folks (mortal or not), on most systems, the "broad strokes" are sufficient - it's only if you want or need to squeeze out a few more K that you'd have to roll up your sleeves.
Ok - the basics (as I see them) in M$-DOS 6xx
For a start, setup memory management in config.sys - the first two lines should be (and in order):
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE NOEMS
* NOEMS means "No Expanded Memory" emulation - you won't require this unless you intend to run some oddball program from the '80s or so. Using EMS memory generally means setting up a 'PAGE FRAME' which consumes 64K(!) Then:
DOS=HIGH,UMB
Technically, this can go anywhere but it makes more sense following the first two.
Ok - now DOS should be loaded 'high', freeing up conventional memory, and you should have the capability of loading drivers and devices into Upper Memory (UMBs) with 'DEVICEHIGH' and 'LOADHIGH' (LH) statements in config.sys or autoexec.bat (even the command line, if need be)
A typical system starts out with maybe 100 - 150 K of available UMBs. You may be able to free up more of those by turning off 'ROM shadowing' in the BIOS - check the options there - if present, you will also see the range of HEX addresses used by each choice.
Some devices such as network cards or SCSI controllers may require some of those addresses - short of removing the device (or reconfiguring, if possible), those must be left alone. In some cases you may have to employ the 'EXCLUDE' parameter with EMM386 (X= )
That's about it, and is well covered by the DOS6 HELP (Qbasic) application. For the majority, likely this is enough.
You can determine UMB status using mem/f command, and overall useage with mem/c/p
Now, there are a few methods that may allow you more UMBs (more upper memory):
Make 'intelligent' software or configuration choices. For example, not all drivers are created equal - the CD driver "oakcdrom.sys" (supplied with Win98) uses 25K, but you can just as easily use "vide-cdd.sys" instead (5K)
Don't bog DOS itself down with unecessarily high parameters. Setting FILES or BUFFERS too high can bloat DOS to the point where it won't fit into high memory, rendering the DOS=HIGH statement useless. Every setting uses *some* memory, so you may not need to set your 'LASTDRIVE' as Z: or have FCBs or STACKS, or run SETVER. Lower Smartdrv settings can use less memory as well.
Check for unused UMBs. UMASCAN (as I may have mentioned previously) will squirrel these out for you, if present - although more common on older machines, never hurts to look. If found, you would use EMM386's 'INCLUDE' parameter (I= )
If you're really adventuresome, you can steal some addresses from the video controller by employing (likewise) the 'INCLUDE' switch:
I=B000-B7FF
... this is the 'mono' range - not usually needed, but some graphical applications may surprise you (and crash)
If you can create more than one 'region' of UMBs (and 'mem/f' will confirm that) then you could specify which one a particular application or driver loads into, using the region parameter with DEVICEHIGH or LOADHIGH
Order of loading: drivers and applications may require more memory to initialize, then release some once loaded. Rule of thumb is to load the largest ones (memory consumption-wise) first, in reducing order.
In the same vein, in AUTOEXEC.BAT, if you load executables first, SET statements afterwards (including PATH ) you may use less as well.
Recommended Reading:DOS6 Help (yes, again) - Micro$oft Application
DOS6 Memory Management - Jeff Prosise - PC Magazine
Memory Management For All Of Us - John M. Goodman - SAMS
The One Minute Memory Manager - Phillip Robinson - M&T BOOKS
As it turns out, this is somewhat less than book length itself - hopefully not too many exclusions or errors.
I hope it's of some use, and may provide something of a starting point.
Experiment
If you get people asking the wrong questions, you don't have to worry about the answers
