Microsoft

Optimize your system's memory usage when using real mode drivers

Determining which real mode device driver you can load into upper memory blocks can be a challenge. Brien Posey offers a logical process to eliminate the guesswork.


If you have ever used DOS, you probably remember having to tweak memory usage to make device drivers and Terminate and Stay Resident (TSR) programs all work within DOS’s 640-KB conventional memory limit. Windows 9x has the same conventional memory limit as the version of MS-DOS that shipped 20 years ago when using real mode drivers. Here, I’ll explain how to optimize conventional memory usage in your Windows 9x system.

Catch up on your reading
If you missed Brien Posey’s previous articles on real mode and protected mode drivers, check out these links:
Troubleshooting real mode and protected mode drivers, part 1 Troubleshooting real mode and protected mode drivers, part 2 Understanding the limitations of conventional memory in Windows 9x


Figuring out your current memory amount
Begin the process by inserting your boot disk and booting the system from it. When the system boots, enter the MEM /C | MORE command. You’ll then see a summary of everything that’s loaded into memory. If you receive a Bad Command or File Name error, it’s because either the file MEM.EXE or MORE.COM does not exist on your boot floppy. You can copy these files from the C:\WINDOWS\COMMAND directory. You also need to make sure that your boot disk isn’t write protected when you execute this command.

Normally, this summary information will consume at least two screens. The | MORE portion of the command forces the MEM command to pause after each screen full of information. Figure A and Figure B are typical of the first and last screens displayed by this command.

Figure A
The top portion of the screen lists all of the drivers loaded into memory.


Figure B
The bottom portion of the screen displays a summary of the total memory usage.


As you look at the figures, you’ll notice that I ran the MEM /C | MORE command from a command prompt window. I used a command prompt window because it was much easier to get a screen capture than if I had been using true native mode. The types of information you will see through a command prompt window are identical to what you would see if you had booted the system into real mode. The only difference is a few Windows-related drivers (WIN and VMM32) are present when you use a command prompt window but not when you use real mode. Thus, the numbers you will see are inaccurate. Although I am using a command prompt window for demonstration purposes, be sure to boot your system from the disk you made so you’re working in true real mode.

You’ll notice there’s a summary of the total amount of memory used by the system. Make note of the amount of free conventional memory. In Figure B, my free conventional memory is 593,344 bytes. You need to keep track of this number because many of the problems experienced with real mode drivers are related to low conventional memory. Therefore, your goal is to increase the conventional memory to as high a number as possible. You’ll need to know how much conventional memory you started with so you’ll know whether your changes had any affect on the system.

Files and buffers
Once you’ve established your base conventional memory amount, take a look at your CONFIG.SYS file. Enter the command EDIT A:\CONFIG.SYS. If you receive a Bad Command or File Name error message, the DOS editor isn’t on your boot disk. You can add the editor to the boot disk by copying to your boot disk the EDIT.COM and EDIT.HLP files from the C:\WINDOWS\COMMAND directory.

Once you’ve loaded your CONFIG.SYS file into the DOS editor, you need to look at the files and buffers. Remember, by default, Windows sets the files to 60 and buffers to 30, so Windows will have enough free files and buffers to load the GUI. So, make sure the number of files is no lower than 60 and the buffers are no lower than 30.

Once you’ve verified that the FILES= and BUFFERS= commands meet the minimum requirements, make sure they are set high enough to meet the needs of your real mode drivers. Usually, if any of the real mode drivers have file and buffer requirements, they will be listed in the documentation that came with the driver. If some of your drivers do not have any documentation, you can experiment with different values in the FILES= and BUFFERS= lines. You can set a large number of file handles without having to worry about memory constraints. Try setting the file handles at around 100 and see what happens. Buffers are a different story. Each buffer that you reserve consumes some amount of conventional memory. Don’t reserve any excess buffers unless it’s absolutely necessary.

Freeing conventional memory
After making changes to the files and buffers, reboot the system by booting from your boot disk. Enter the MEM / C | MORE command and make note of the free conventional memory amount. Remember, if you’ve changed the number of buffers, the amount of free conventional memory will also change. Make note of the new number so you can benchmark memory gains or losses produced by future adjustments.

Next, make a list of your system’s memory usage. Note the names of each module that exists in memory and the amounts of the various types of memory that each module is using. For example, in Figure A, the driver D011V110 is using 20 KB of conventional memory and no upper memory. To save time writing, you can print the information, assuming a printer is directly connected to your system. To do so, enter the following command:
MEM /C  >PRN

This will dump all of the pertinent memory information to your printer. If you’re using a laser printer, you’ll probably need to press the form feed button to eject the page after issuing the command. Remember, using a print command, such as the one above, doesn’t involve using a printer driver and therefore will not issue a form feed at the end of the print job.

Once you’ve compiled a list of everything in memory, determine which objects Windows loads and which objects you’re loading from your configuration files. Go through your list and cross off the following device drivers:
  • MSDOS
  • HIMEM
  • DBLBUFF
  • IFSHLP
  • COMMAND

You should remove these items because Windows loads them automatically. Next, use the DOS editor to look at A:\CONFIG.SYS and A:\AUTOEXEC.BAT. Look for any commands that involve the modules listed above. If you find such commands in either file, remove the command and save the file. Then, reboot the system from your boot disk and check your conventional memory. You should also check the modules that haven’t been crossed off your list to make sure the free memory amounts haven’t changed. If any of the remaining module’s memory amounts changed, make note of the new numbers.

Adjusting your configuration
Each device driver contains a listing of how much conventional memory and how much upper memory it’s using. Upper memory is the memory space between the first 640 KB and 1 MB. One of the most effective methods of freeing conventional memory is to move everything possible into upper memory.

To move devices into high memory, you need only change the command that loads the device. If the device is being loaded from the CONFIG.SYS file, change the DEVICE= command to read DEVICEHIGH=. If the device is being loaded in AUTOEXEC.BAT, try preceding the command with LH (load high).

Simply telling these commands to load into high memory is only part of the battle, though. The real trick is to know what order in which to load the commands. I had you to write down how much memory each driver was using. If possible, load the devices that use the most memory first. Doing so makes DOS, and therefore Windows 9x, load the drivers in the most efficient manner.

Notice also in Figure B that the summary section tells you how much free upper memory exists. Beneath the summary, there’s also a listing of the largest free upper memory block. The total free upper memory is typically larger than the largest free upper memory block, because the free upper memory is composed of multiple upper memory blocks.

The number you see for the largest free upper memory block represents the largest driver that can be loaded into upper memory. Therefore, if you see a driver on your list occupying a larger amount of conventional memory than is available in the largest free upper memory block, there’s a good chance you won’t be able to load that driver into upper memory. I should mention, though, some drivers are able to fragment themselves. Such drivers load as much of the driver as they can into upper memory and the remainder of the driver in conventional memory. Therefore, you’ll just have to experiment with loading excessively large drivers into upper memory.

Generally, DOS uses the largest upper memory blocks first. Try loading the largest drivers first and work toward the smallest. Unfortunately, drivers specified in the CONFIG.SYS file always load before drivers specified in the AUTOEXEC.BAT file. Because of this, you should arrange the CONFIG.SYS file to load the largest devices first and work toward the smaller drivers. Do the same thing with your AUTOEXEC.BAT file.

As you arrange your device drivers, don’t waste a large upper memory block with a small driver. If you have a really big driver that you’re loading in the AUTOEXEC.BAT file, you might experiment with the idea of loading most of the CONFIG.SYS drivers in low memory and saving the large upper memory blocks for drivers found in AUTOEXEC.BAT.

Making your changes permanent
So far, all the configuration changes you’ve made have been applied to your boot disk. The configuration on your hard drive remained unchanged. Therefore, it’s necessary to update your hard drive’s system files to reflect the new configuration. Enter the following commands:
C:
CD\
RENAME C:\CONFIG.SYS C:\CONFIG.XXX
RENAME C:\AUTOEXEC.BAT C:\AUTOEXEC.XXX
COPY A:\CONFIG.SYS C:\
COPY A:\AUTOEXEC.BAT C:\


At this point, the configuration is updated. Remove the boot disk and boot your system. Windows should run with an optimum configuration, and any real-mode-device-related problems should be gone.

Conclusion
When you can’t find or encounter problems with protected mode device drivers, you can sometimes get away with using real mode drivers. Doing so can add to your problems, however, because you can bump against conventional memory limitations. When you know how to deal with these limitations and tweak your system, you can often get real mode drivers working with Windows 9x with little effort.

Editor's Picks