Last month I defined the terms:
Remember that allocation of memory by the people who designed DOS was based on the foolish assumption that 1 MB was all that we would ever need. They were influenced by the 8088 chip that IBM put into its first PC. The chip could not address any more than 1 MB. It did not know how to count any higher. Because everyone wrote programs that ran on this chip, under DOS, these same restrictions were applied to the programs. Regardless of how much memory you have, the program can't use it unless it has been specially written to do so. With the advent of the 286 chip, at least the chip knew about more memory. It could count up to 16 MB but that did not help the programs that were built to know only about the first megabyte. It was not until the 386 chip arrived, with its inbuilt memory management, that the user was able to implement effective influence over how it was done. Like skinning cats, there are a number of choices to make about which way to access more memory. Naturally during the early days everyone made different choices. Finally, after the usual initial confusion and multiplicity of approaches, the gurus involved settled on two standards. One for accessing Expanded Memory and one for Extended Memory. These days almost everything complies with these standards and we need not worry about them. Anything off-standard fell off the back long ago. This does not mean that memory management has become transparent, just as copying to a disk has become. You still need to tell the computer what you want to do and the tools to use to get the job done. Virtually all of this is done through the CONFIG.SYS file. This file only runs at start-up so if you make any changes you must reboot the computer for them to become operative. What follows is how to do it through DOS. There are a number of very good commercial memory managers that usually do a better job than DOS. Regardless of how you choose to implement memory management the methods are fairly similar. RTFM When you start up your computer you are starting in an environment that has pretty strong links with the bad old days when 1 MB was all we were allowed. Even if you have extra memory installed in your computer you still can't access it unless you establish a link to it. This link is the HIMEM.SYS file. You must have a line: DEVICE=C:\WINDOWS\HIMEM.SYS in your CONFIG.SYS. Of course it need not point to drive C: or the \WINDOWS directory but to wherever you have HIMEM.SYS. This line should be the first line. It absolutely must be ahead of any other memory management commands. Many default configurations have the SETVER command as the first line but it needs only go somewhere ahead of any commands that need it. Most computers don't use it at all and it can be safely removed. With HIMEM loaded you now have a link to extended memory and the High Memory Area. Many of the programs that know about Extended Memory will run. You still have a rat's nest of TSRs and wasted Upper Memory and no link to Expanded Memory. To gain access to those Upper Memory Blocks and to start to move some programs out of Low Memory these two lines should follow the HIMEM.SYS line. DOS=HIGH, UMB DEVICE=C:\WINDOWS\EMM386.EXE NOEMS (or) RAM The first line loads much of the working parts of DOS into the High Memory Area and makes the Upper Memory Blocks available for things that would otherwise have to happen in Low Memory. The effect of all of this is to free up Low Memory for running programs. The second line, the EMM386 line, is the one that opens up all kinds of possibilities. If you do not have a 386 computer then it will do nothing. With the parameter NOEMS there is no support for Expanded memory which is fine if you are not using it. A number of programs use Expanded Memory so you should check into your manual to find out if you need to enable Expanded Memory. If you need Expanded Memory then use the RAM parameter. Depending on your setup you may need to tweak the EMM386 line to include or exclude some parts of Upper Memory from the effects of EMM386.EXE. How to do that is not being discussed here. With those three lines heading your CONFIG.sYS you can then change all subsequent DEVICE= statements in the CONFIG.SYS to DEVICEHIGH=. You can precede all commands in the AUTOEXEC.BAT that load a memory resident portion with LH, or LOADHIGH if you like typing. DEVICEHIGH and LOADHIGH both load programs into the spaces in Upper Memory. If you want to see how you are going enter MEM /C at the DOS prompt. This will show you how much space is used and what is available. You can quickly assess how you are going. There is the familiar problem of having the information whizz off the screen before you can read it so you might like to try: MEM /C > ZZZ This outputs the command into a file called zzz instead of the screen. Now you can use LIST or EDIT to browse it. Call the next one XXX or something like that and you have a record of the last one to compare to. You can sent a copy to the printer with MEM /C > PRN Just to save you some frustration. Sometimes a file needs more memory to load into Upper Memory than it occupies once it is loaded. I know, I spent hours trying to fit a 25 kB file into 32 kB, and it would not go. Another tip. If you are going to load something from the command line, after you have started, you can still LH or LOADHIGH and it will work just fine provided there is sufficient Upper Memory available. There are lots of things I have not said but, generally speaking, this is all the average user with the average setup needs. Remember that this involves fiddling about with your startup files so make sure that you have a boot disk with copies of your drive C: startup files and possibly an editor to fix up any blunders. Make sure that the disk will run in drive A: at start up. Like most of computing, memory management is not as difficult to do as you anticipated. If you have not done it before then I suggest you owe it to yourself to have a go. Take a look around. Roll up your sleeves. And have a go. Reprinted from the April 1994 issue of PC Update, the magazine of Melbourne PC User Group, Australia |