Printer Friendly

DOS 5.0 does Windows.

MS/PC-DOS, which has been around for a decade now, recently underwent a major upgrade. DOS upgrads are nothing new, ad in fact, occur regularly. Version 1 dates back to 1981 and the original IBM PC. Version 2 arrived with the XT in 1983. 1984 saw DOS 3.0 and the AT. Version 3 went through some minor upgrades to provide for such things as 3.5inch disks and networks, and then in 1988 we experienced DOS 4.

DOS 4 almost killed DOS, not because it was such a terrible operating system (it wasn't) or because it was full of bugs it was), but because it quickly gained a reputation - being the worst mistake IBM and Microsoft had made in a long, time.

The bugs were soon identified and eradicated in version 4.01, but many people (myself included) were content to stick with the tried and true 3.3 version. About the only advantage DOS 4 offered w- the ability to create hard disk partitions larger than 32 megabytes. I didn't (and still don't) see that as a needed feature. So DOS 4 was pretty much a bust.

Each successive version of DOS got bigger. The two hidden system files (EBMBIO.COM and IBMDOS-COM for PC-DOS; IO.SYS and MSDOS.SYS for MS-DOS), plus the command processor, COMMAND.COM, occupy a significant amount of RAM. It got to the point where, by the time DOS 4 came out, we were sacrificing upwards of 100K to the DOS gods (okay, SO it was more like 60K - it only seemed like 100K!). DOS 5 has changed all that.

This isn't going to be a review of DOS 5. Tom Wilson did a fine job of that in the September issue of CIL, so I needn't go into all of its features here. What I want to do is concentrate on some of the factors involved in running MicrosOft Windows 3.0 under DOS 5. The main issue is memory management, which happens to be one of the major improvements over prior DOS versions.

Thanks for the Memory

This DOS has made tremendous strides in the area of memory. Not only is it actually smaller (ever so slightly) than the Previous version of DOS, it incorporates the ability to do some wonderful things with memory. We'll look at those in just a moment. First, however, a very short review of memory is in order.

The- - three kinds of memory that concern us here: conventional, expanded, and extended, Conventional memory is that part of RAM located below the first megabyte. Expanded, or paged, memory is nonlinear and can be swapped (in 16K pages) into and out of a 64K EMS frame located in the adapter segment of conventional memory. Extended memory is linear memory, located above the first megabyte. If you need a short refresher course, you might want to check the article "Memory Recalled" in the May 1991 issue of CIL.)

With previous versions of DOS, the operating system itself, various device drivers, and any TSR (terminate-andstay-resident, or memory resident) programs you might use were all loaded into the 640K of main memory. This could well amount to 100 to 200K taken "off the top" so to speak, depending on what your computing habits were. So it was not uncommon for people to encounter situations where they had to unload something from RAM in order to make room for something else.

This condition became known as "RAM cram," and it has vexed countless computer users - so many in fact, that an associated industry has developed. There are several products available that exist solely to help us alleviate RAM -. Pop-Drop Plus, Switch-It, and Headroom are some that I have tried in the past. They all worked well, and I don't hesitate to recommend any of them to users of DOS 3.x, but of course I haven't tried them with DOS 5.

Loading High RAM cram is still possible, but DOS 5 has made it much easier to prevent. It does this in a couple of ways. One is by relocating most of DOS itself into the High Memory Area (HMA). The HMA is the first 64K of extended memory, directly -above the 1 megabyte of conventional memory. DOS 5 leaves a "stub" of less than 20K in conventional memory and Puts the rest of itself into the High Memory Area. In order to achieve this, you must put a line in your CONFIG.SYS file that reads "DEVICE=HIMEM.SYS" and another that reads "DOS=HIGH".

Perhaps a few numbers will help illustrate what happens. (Please keep in mind that these numbers are representative only - yours may vary.) With a clean environment (i.e., no device drivers or TSRs loaded), I get about 583K available RAM on a Particular 80386-based machine. By adding the extended memory manager HIMEM-SYS and the command to load DOS high, I get 622K free memory. That's a 40K improvement right off the bat.

If all we received was a 40K increase, that would be fine. But by adding another driver, EMM386.EXE, and modifying the DOS=HIGH command to read "DOS=HIGH,UMB" we gain access to the upper memory blocks that occupy the area between 640K and 1MB of conventional RAM. I'll have more to say about EMM386.EXE in a moment, but for now let's get back to those numbers.

I mentioned that I had about 583K available in a clean environment, but normally I load almost 50K of device drivers, leaving me with about 534K. This is with DOS 5, mind you, but without using the fancy memory tricks. That's more th- 100K Of Prime operating memory gone Out of the basic 640K of conventional RAM. Now watch closely, because here comes the fancy footwork. Add the following three lines to CONFIG.SYS:


DEVICE--EMM386.EXE NOEMS (or RAM; see below)


The result is that most of DOS is relocated to the HMA as noted above, and all of the device drivers are sent to UMBs by writing "DEVICEHIGH=" rather than "DEVICE=" for each of them. We are left with (drum roll) 614K of conventional RAM available ! Let's take a close look at the two drivers that make this possible.


Most Windows users are at least somewhat familiar with HIMEM.SYS because it is an extended memory manager and most computers running Windows have some extended memory. An earlier version of HIMEM.SYS is packaged with Windows, but you should erase it from your hard disk and use the one in DOS 5 instead. It is optimized for DOS 5 and more efficient than the Windows version.

HIMEM.SYS is of course fully compatible with the Extended Memory Specification, or XMS, not to be confused with EMS, the Expanded Memory Specification. This is the driver that makes all that extended memory accessible to DOS, since DOS by itself only knows about conventional memory. Without it, you couldn't run your disk cache in extended memory or even let a program like Paradox use that extra memory, with or without Windows.

You may need to include one or two switches on the line that loads HIMEM.SYS. The first is "/hmarnin=x", where x is a number of kilobytes between 0 and 63. This switch specifies the amount of memory a program must use before it can load in the HMA. No two programs can use that area at the same time, and without the switch, the first program requesting HMA access will get it. This means a program that uses 30K, for example, could take over the HMA, wasting 34K and denying the space to a program that would occupy 60K. Setting "/hmamin=50" would prevent that situation from occurring.

Another switch you might find necessary is "/machine=xxx", where xxx is a code referring to a particular type of computer. Some computers can confuse DOS's ability to handle the HMA, making it necessary to specify the type of machine. The DOS manual and the file README.TXT installed in the DOS directory list a variety of machine codes. Check to see if your computer is listed.

Even if yours is not listed, you may want to experiment and use one of the switches anyhow, especially if you have a clone. This magazine's editor, using an older 386 clone, was unable to boot his machine with EMM386.EXE and SMARTDRV.SYS until he included the "/machine=" switch. If you do experiment, make sure you have a floppy with which to boot your computer should it freeze.


A version of EMM386.EXT, is also packaged with Windows, but again, you should use the one that comes with DOS 5 instead. This driver serves two purposes. First, it is an expanded (LIM EMS) memory emulator that can convert the extended memory in your computer to expanded MeMOry for those non-Windows applications that might make use of it.

If you run these programs in 386 Enhanced mode, Windows itself can simulate expanded memory, so you don't need EMM386.EXE for that purpose. But it still is useful for providing expanded memory outside of Windows.

The other function of EMM386.EXE is to provide access to those upper memory blocks. In order to use the DEVICEHIGH command and load your device drivers into high memory, you need to include EMM386.EXE in your CONFIG.SYS whether you need expanded memory or not. There is a comparable command for TSRS, LOADHIGH, that will place them in high memory.

EMM386.EXE is a complex driver, and it has numerous options, or switches, that you may or may not need to include. One you've seen already in the example above. By itself, EMM386.EXE only provides expanded memory emulation. If you also want access to UMBs (and that's the whole point here), you must include either the RAM switch (which gives you both) or the NOEMS switch (which gives you UMBs but not expanded memory).

You can specify "X=xxxx-yyyy", where xxxx-yyyy represents a range (in hexadecimal) of memory to be excluded from use by EMM386.EXE if you find some other device needs that particular portion of memory. For example, I have a Token Ring LAN card in my computer at work, and I have to use the X=" switch to tell EMM386.EXE not to use the memory location that the card uses.

There are several other switches, but I won't go into them here. You will just have to see what works best in your particular situation. For example, the CONFIG.SYS file on my computer at work includes this line:


In this case M9 means the EMS page frame goes to address EOOO. I=BOOOB700 means include that area of memory (since I'm not using a monochrome video adapter and it would go to waste otherwise). X=CDOO-DBOO excludes the area used by the LAN card.

Uh-oh, I Knew There Would Be a Down Side

So the good news is that you can greatly increase the amount of available conventional RAM in your computer by using DOS 5 and its memory management programs, HIMEM.SYS and EMM386.EXE. Me bad news is (you guessed it) that EMM386.EXE works only on 80386 or 80486-based computers. Sorry folks, but that's the way it is. It's just another nail in the 8088/80286 coffin.

That doesn't mean you can't run DOS 5 on those (there's just no other way to say it) inferior machines. You can still benefit from using the HMA for DOS on a 286, and even on an 8088 DOS 5 uses less RAM Ehan DOS 4. Possibly you can find a replacement for EMM386.EXE that will allow you to load other drivers high on your 286. One I have heard about, but not tested, is HRAM from Biologic. If you look into this type of solution, be sure to investigate fully its compatibility with DOS 5.

Something else you might consider to be bad news is that Windows cannot run in standard mode if you use EMM386.EX-E. Windows runs faster in standard mode than in 386 enhanced mode, so if you nm only Windows programs you would normally want to use standard mode. Since that is not possible with EMM386.EXE, your only options are not to use EMM386.SYS and forego utilizing the HMA. run in enhanced mode and suffer a slight slow down of Windows programs, or try a different memory manager such as QEMM386.SYS.

Squeezing That Last Bit of Memory

If you really need to make that last possible byte available, there are a few tricks you should keep in mind. For one, unless you really have a need for expanded memory outside of Windows, use the NOEMS rather than the RAM switch for EMM386.EXE. That will save you several kilobytes. Also, don't use SETVER unless it's required by some program you run, and don't load a mouse driver unless you need it outside of Windows because Windows has a built-in mouse driver. And don't use DOSKEY. (We're in Windows here, for goodness sake, so don't use the command line.)

Those are the easy things. Next you need to experiment with the order in which you load your device drivers. EMM386.EXE will put a driver in the next available memory block, even if it's three times as big as the driver needs. That could result in the next driver not having a large enough UMB, in which case it would have to load in conventional memory. So try it one way in your CONFIG.SYS, reboot, check your memory, and then change your CONFIG.SYS and do it again. One caveat: be sure you have a bootable floppy handy. You'll probably need it before you're finished.

Although you will need to try various configurations to see which is right for your system, the following recommendations are a good place to start when ordering your CONFIG.SYS statements.

First, load the basic system configuration commands, such as "BUFFERS=xx" and "FILES=yy".

Second, add your extended memory manager "DEVICE=HIMEM.SYS".

Third, for device drivers that use extended memory, add


Fourth, add the UMB,EMS driver


Fifth, add any devices drivers that use expanded memory, although with Windows you are much better off if you can avoid expanded memory drivers other than EMM386.EXE.

Finally, add any device drivers that use the UMBS: "DEVICEHIGH=SMARTDRV.SYS", etc.

Having written that, let me remind you again that you still will need to experiment. It turns out that, on my machine at work, I needed to rearrange that order a little, because I found that I could get a whopping 1.2K more free memory by loading RAMDRIVE.SYS high after EMM386.EXE.

Memory Utilities

DOS 5 includes a nifty utility called MEM that will help you in this trial-and-error process. Type "MEM", and it will tell you how much free memory of each type you have. Type "MEM/C", and it will tell you what is loaded in conventional memory and what is loaded in upper memory. Type "MEM/D", and it will give you the exact location of everything in memory.

The truly desperate might want to investigate other memory managers as well. One with an excellent reputation is 386Max, made by Qualitas, or their PS/2 version, BlueMax. I haven't used either, but I've read good things about them.

I have used QEMM386 from Quarterdeck (makers of DESQview, the nonGUI multitasker). QEMM386.SYS is a replacement for both HIMEM.SYS and EMM386.EXE. Playing around with it and DOS 5, 1 discovered that it generally offers a slight improvement over EMM386.EXE. It occupies slightly less conventional RAM than do the other two, and I was able to squeeze out about 6K more by using it. Also, Windows can run in standard mode with QEMM386.SYS, whereas it won't with EMM386.EXE.

One big advantage of QEMM is that it's a lot easier to set up in its optimal configuration for your system than the DOS 5 driver. That's because it includes a program called OPTIMIZE that does it all for you. It's much simpler than the trial-and-error and constant rebooting I went through to get EMM386.EXE just right. There is also a program called MANIFEST that will tell you everything you want to know, and more, about your system memory.

Figure I shows sample CONFIG.SYS and AUTOEXEC.BAT files that show how some of the memory functions described above may be put to use. They are taken from my machine at work.


1. Thanks for the Memory." This was the original title of the "Memory Recalled" article in the May 1991 issue, but the editor wouldn't let me use it because some guy named Michael Schuyler beat me to it in something he wrote. I thought I'd try to sneak it by here.
COPYRIGHT 1991 Information Today, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1991 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:MS-DOS 5.0 vs. Microsoft Windows 3.0: a tale of two operating systems
Author:Marmion, Dan
Publication:Computers in Libraries
Article Type:Evaluation
Date:Oct 1, 1991
Previous Article:Business systems.
Next Article:No Windows here!

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |