Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!virtue!canterbury.ac.nz!phys169 From: phys169@canterbury.ac.nz Newsgroups: comp.sys.ibm.pc.misc Subject: Re: DR-DOS ver 5.0 Message-ID: <1990Sep12.101927.9142@canterbury.ac.nz> Date: 12 Sep 90 09:48:53 GMT References: <1990Aug13.162833.19793@EE.Surrey.Ac.UK> <15160001@hpspcoi.HP.COM> <1990Sep1.090154.4095@EE.Surrey.Ac.UK> Organization: University of Canterbury Lines: 101 In article <1990Sep1.090154.4095@EE.Surrey.Ac.UK>, chung@surrey.ac.uk (L N Chung) writes: > In article frotz@dri.com writes: >> >>It uses what memory is available between 640K and 1M (actually >>the first segment above 1M) to load itself, drivers, system >>structures and TSRs. > > Can it load everything above the 1M mark? My problem is that the Everex card > can only fill memory extended memory starting from 1M. In fact we have now > got 1M extended memory and 3M expanded memory on the card. However, there is > *no* memory between 640K and 1M. Will I be able to get more than 600K out of > the DR-DOS? > Yes, if you have a 386. Possibly otherwise. With a 2Mb 386 and Hercules graphics card, I get about 800Kb available, with a VGA I get about 620Kb available (with "reasonable" balance between speed and memory size). On a 386 with more than 1Mb of RAM, it can map memory down into any gaps in the 640K-1Mb region. Not all software likes going there, of course, but most will. Some 286 chip sets also let you do this, but none that I have tried yet. Even if you only have a common-or-garden-variety 286, with more than 640Kb of RAM, DR-DOS can use some of the first 64Kb above 1Mb, by saying it is segment number FFFF (i.e. within the first 1Mb area), but it only loads about 37Kb of its own kernel there, not your programs (still, you do get a bit more memory left at the bottom then). A few old AT motherboards seem to loose the extra 384Kb, though (so if you can't use it for Extended, you can't shove the kernel there either). Also, some 1Mb 386's seem to insist such RAM can be only be used for some purposes, limiting what DR-DOS can do with it. And on old 8088 machines, DR-DOS still usually gives you more memory than MS DOS 3.30, partly because it is more code-efficient, it seems, and partly because you have a lot of control over memory use. It will make better use of EMS (and extended) than DOS 3.30, but about the same as DOS 4. > If we use window3, and load himem.sys, will DR-DOS stop loading drivers, etc > to memory above 640K? > You can choose in config.sys whether device drivers are loaded "high" or not, and you can specify whether programs (e.g. TSR's) are to be loaded high, and whether upper memory should be turned on or off during execution. There is a special note mentioning using DR-DOS with windows3 and a few other 386-specific programs that comes with the software (but I haven't tried it yet). > "shadow ram"... Shadow RAM takes up the same memory space as the ROM it copies and replaces. It seems a good idea, but it is not always worthwhile shadowing video rom, since some loadable drivers bypass that code anyway. All in all, DR-DOS 5.0 seems a very nice product, especially if you have a 386 with a bit of memory you are wondering how to put to best use. The user interface is very good, well, compared with what has come before, from the installation process to the command interpreter and on-line help (why didn't they do that before??). But there are some limitations (really minor, but someone's got to mention them). [Please read these understanding that, on balance, DR-DOS is easily the nicest little o/s for a PC you can get, IMHO] (1) You don't get a great deal extra below-640K ram on a "normal" (non-C&T) 286, only 37K plus what you get from having less buffers and more memory-efficient FASTOPEN code, etc (say, about 60Kb more than DOS3.3). Still, that's important to some people who can't otherwise install a network driver and still run some big DTP software, etc. (2) Some software doesn't like going up above 640K, e.g. DECNET DOS can have problems if particular modules (like DNP) are loaded high, and MARK and RELEASE can give problems unless high memory is turned off. That's not really DR-DOS's fault, though. The sort of problems are assumptions in old software that the world ends at 640K, and that if a vector points above 640K it must still be pointing to BIOS ROM. The system has a too-common habit of freezing until you work out what can and cannot work; again, that might not be DR's fault. (3) The screen-oriented editor is much nicer than EDLIN, and very similar to Wordstar and Turbo's interactive compiler editors, but it lacks decent global search and replace options, and defineable keys (F1 is "Help", but no other function key is used). (4) The system call that returns the capacity of a disk fails if that disk is JOINed. (5) Trying to do: DEL *ABC*.* returns an error message, which is better than MS/PC-DOS (everyone know that bug? it does a DEL *.*), but it would have been better to fix the wildcard matching problem, since some software assumes the system calls to find a file matching *something* will return everything. (6) Their disk caching software slows down access times (it sounds like there are too many disk seeks being done for each access), although in other ways the caching system is very good (you keep good transfer rates with 1:1 controllers, and good software compatibility, and Norton's SI disk test returns very good performance figures). (7) Not all commands have on-line help (e.g. COPY and other internal commands). (8) The FILELINK program doesn't handle modems, and you have to keep going back into the program after each command, but is still a valuable tool. There may be a problem with the way it gets the date and time from the CMOS clock, but it might be my hardware - if anyone notices any strange behaviour, I'd be interested to know. Mark Aitchison, Physics, University of Canterbury, New Zealand.