CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 31
by Benjamin H. Cohen
At a recent meeting of the CFOG Board of Directors a few adjustments were made in the CFOG program. Perhaps most significant were decisions to reduce Sunday afternoon meetings to four a year, to be held in February, May, September, and November and to discontinue the effort to present formal programs at meetings. Sunday meetings will continue to be held at the Skokie Public Library, 5215 West Oakton, Skokie. Dates are subject to the whim of the Library staff.
December Meeting Cancelled
Note that this change means there will be NO Sunday afternoon meeting in December.
This does not mean that there will be no programs: there will simply be no program chairman. If any members have something of interest that they would like to present as a program they can leave a message on the CFOG answering machine and we'll get out appropriate notice. When a program has been set for the meeting it will (normally) be noted in the message on the answering machine, so if you call and there's already a program either you'll be sharing the program time or you'll have to wait until the next meeting.
Disk Libraries
Bob Boswell, our new MS-DOS librarian, and Gerald Pine, our CP/M librarian, have agreed to attend the four quarterly meetings, so you'll still be able to get disks copied at the meeting. In the meantime you'll be able to get disks by mail for $2 per disk.
I'm hoping that before year end both Bob and Gerald will provide us with an up to date library catalog disk. When that has been done we will make that disk -- i.e., one disk with both catalogs on it, in MS-DOS 5.25 inch or CP/M formats -- available by mail for $2. While the catalogs will continue to be updated periodicially, we'll endeavor to keep up with the new software by publishing lists of the new disks in each issue of PIP.
PIP Continues
Yes, the plan is that PIP will continue to appear. Of course, this depends on the number of members who renew their membership for 1990. After all, if our membership gets much smaller I could probably save time by simply calling up each member and telling him or her everything I know!
Like this year, the appearance of our newsletter will be a bit irregular, not necessarily appearing when there is or isn't a meeting, but appearing when the spirit moves the editor. Of course the spirit is more likely to move the editor of some of YOU submit articles that can be published, but by hook or by crook or by exchange newsletter or by modem, we'll find material to publish. By the way, one series that we're thinking of running is a longish one called the "Plain Vanilla Guide to MS-DOS" that has been appearing in Toggle, a user group newsletter from the Seattle-Tacoma area. Are you interested?
New President
We regret to report that Steve Lucius has found it necessary to resign as President. The Board seriously considered telling him that his resignation would not be accepted, but that his authority and responsibility had been removed that he would continue as a figurehead president. On that basis -- that he would not be required to accept any additional duties -- Dave Jacobsohn reluctantly agreed to assume the title (if not the duties or responsibilities) of President. Congratulations, Dave!
Downtown Sig
The fate of the Downtown SIG was not discussed at the Board meeting, but when I postponed the October meeting for a week the result was the same as it had been earlier in the year: members stay away in droves. Therefore, I have arbitrarily decided to effectively discontinue the Downtown SIG. There will, however, be four downtown meetings a year, as get-togethers for the Board and any members who want to attend. These will be scheduled for the second Thursday in March, June, October, and December. The Downtown meetings will continue to be at 55 West Monroe Street, Suite 2400.
Remote Access System
CFOG's Antelope Freeway Remote Access System will continue. We admit that only about 20% of our members use the RCPM. [About the same percentage that come to meetings.] But even those who don't run with the Antelope get benefits from its existence: (a) most of the new software that gets into the disk libraries comes in through Antelope and (b) some portion of the material that appears here comes from the message system on Antelope.
New Sysop Needed -- Maybe
There is one possible fly in the ointment: the Antelope's sysop has given us due warning that with the anticipated completion of his Ph.D. qualifying exams he will be looking for employment. Since that employment may not be in the Chicago area..... we may not have a sysop any more. Therefore, applicants for the position of sysop are solicited. Since it's considered that anyone who might be interested in this position ought to have a modem, you should leave a message for Carson Wilson on the Antelope Freeway Remote Access System [312-764-5162].
The Future of CFOG
Does all this mean that CFOG's about to go away? Well, no, not really. You'll note that we're going to have meetings eight times a year, in February, March, May, June, September, October, November, and December. If you're a CFOG meeting junkie that ought to satisfy your craving. In recent years only a small number of members have been coming to meetings, and those who haven't will still be able to get out of CFOG what they have been getting in the past.
Renewal Notices
You'll be getting a renewal notice soon. Your vote in favor of this reorganization -- in the form of a prompt renewal check mailed to the CFOG post office box -- will ensure that CFOG doesn't go away.
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 32
No more program chairman means no more programs, right? Wrong. For the November meeting Rand Gerald has promised a program on Paradox, a relational database program for MS-DOS users. Since that means there will be an MS-DOS machine at the meeting, Ben Cohen says that if there's time and interest he'll give a few comments on 4DOS, the 'DOS shell that was reviewed in the August 31 issue of PIP.
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 33
by Barry Simon
Copyright 1986, by Barry Simon
Written expressly for and posted on Compuserve's IBM Forum. May only be reproduced commercially with the author's permission. May only be distributed with this copyright notice intact.
Introduction
During the startup of an IBM or IBM compatible computer, the operating system looks for two files of user supplied commands which allow you to customize your system in various ways. This article will attempt to explain some of the options available to you when you make these basic files. While I have written it for the relative novice, I hope it may provide some useful new tricks even to the more experienced user.
These two files whose names must be CONFIG.SYS and AUTOEXEC.BAT should reside in the root directory of your boot diskette or of your hard disk if you have a bootable hard disk (i.e. if you can start your system from your hard disk without placing a diskette in drive A). Actually, there is a method for placing the AUTOEXEC.BAT file in a subdirectory but despite the fact that I tend to be fanatical about keeping my root directory lean, I don't recommend using this option.
When you turn on your computer, the CPU is setup to begin a program in the ROM (read only memory) that all IBM compatible machines have. This ROM is distinct from and in addition to the working RAM (random access memory). When you are sold a machine with 256K of memory, that figure refers to the RAM. There is an additional 16K - 32K of ROM. RAM is cleared whenever you turn off your machine or reboot while the ROM is permanently burned in and should not change.
Booting Up
The program that is automatically run from ROM begins with a brief test (POST = "power on self test") of various components of your computer. If you have an XT or AT, the most noticeable part is the memory (RAM) test accompanied by counting up the memory on your screen as the test progresses. This test is skipped when you do a warm reboot by hitting Ctrl-Alt-Del. You may also notice your drives and printer "burping" as they get tested.
After this test, the machine searches for various "ROM extensions" that is additional ROM that can come with a hard disk or EGA card for example. The program then searches first drive A and then a hard disk if you have a bootable hard disk for a diskette or disk program to transfer control to. It transfers control to the very first sector on the disk which is called the boot sector. When you format a diskette, a little program is placed in the boot sector which will display the message "non system disk, replace and hit any key". When you transfer the operating system to the disk with the SYS command or via FORMAT /S, this boot sector program is changed to transfer control to a program which must be in the position immediately following the boot sector.
If the disk has the system on it, control is transferred successively to two hidden files which load the BIOS ("basic input/output system" part of which is in ROM) and the DOS ("Disk operating system"). When most users think of DOS they think of the familiar prompt and copy,.... commands. These parts of the DOS are only loaded later; the part in the hidden file involves services provided by DOS to programmers rather than directly to users. The two hidden files are called "IBMBIOS.COM" and "IBMDOS.COM" in PC-DOS and may have different names on other computers although surprisingly, the names persist even on some non-IBM brands!
Parenthetically, I want to note that there isn't really much hidden about hidden files. As you may know, the DIRectory you are used to display gets its information from a special file also called the directory. This file is essentially a little database with information about each file including the filename, extension, date and time of creation. One byte in the record for each file is called the attribute byte and contains eight "switches" to keep track of things like whether the file is a volume label, read only, etc. One of these switches is whether the file is "hidden". To anyone with any programming experience or with any of a large number of public domain or commercial programs, these files are not in any sense hidden. The basic DOS services like DIR and COPY are specially set up to ignore hidden files and that is the only sense in which these files are hidden. The two system files are hidden because their location is critical for a successful boot-up and they are less likely to be moved by accident if they are hidden.
After the second hidden file is mainly loaded, it looks for a special file called "CONFIG.SYS" and processes the commands in it. Then control is passed to the third file in the operating system, COMMAND.COM. As the final step in booting up, COMMAND.COM looks for a file names AUTOEXEC.BAT and if found it loads it and runs it. If not found, COMMAND.COM exits with the DATE and TIME commands.
Except for its special status as a bootup file, the AUTOEXEC.BAT file is an ordinary BATch file with the usual rules of syntax. The CONFIG.SYS file has a special syntax with a limited number of allowed commands. Both must be pure ASCII files, that is without any special formatting codes that some word processors add. Many word processors which have special codes have a "non-document" mode for preparing ASCII files. These files have separate lines which must be ended with carriage return / line feed pairs. If you have any doubts about whether the file is "pure ASCII" you can use the TYPE command to display it on the screen and see if it just has ordinary letters and numbers.
What Goes in Your Root Directory
When a subdirectory fills up, it adds another cluster of disk space to increase its size but the size of the root directory is fixed at the time the diskette or disk is formatted. It is not merely because of the size restriction that I recommend that you keep your root directory slight. Since the files in the root are likely to be of diverse type, it will be difficult to keep track of things if you put too much there. I mainly put subdirectories there and mainly subdirectories which have no files but only subsubdirectories. For example, I have a words subdirectory with my word processor, outliner, thesaurus, etc in subsubdirectories. Generally, there are only three files that I recommend go into the root: COMMAND.COM, CONFIG.SYS and AUTOEXEC.BAT. As I mentioned, one can put AUTOEXEC.BAT elsewhere and even COMMAND.COM but I feel that is carrying things too far. In fact, I even have a startup.bat file of the type I'll describe there but the point is to keep that directory thin and to complain bitterly about software so inconsiderate that it forces you to place it in the root directory. My point in mentioning this here is that I'm about to discuss device drivers which many people put in the root directory. If you like to be organized, I recommend you make a directory for device drivers (mine is called \bin\devices). Another option is to put the drivers in different directories with each driver in with related files so, for example, the drivers that come with DOS are kept in the same directory as the other DOS programs or the mouse driver is with the other mouse software.
Device Drivers
There are a group of programs which are made permanently resident and which are loaded as part of the CONFIG.SYS. Virtually any resident program can be produced in this format but certain ones must be of this form. Typically, console drivers and any program which controls "a device" must be loaded now. Most virtual disks and print spoolers also are loaded as device drivers. While device drivers are programs, they need not have the extension "com" or "exe". In fact, so far as I can tell their extension can be anything that you wish. Nevertheless virtually all commercially available device drivers have the extension "sys". Some drivers are available with the extension "dev". The syntax for loading a device driver in your CONFIG.SYS is
device=<path><name><parameters>
so if you have a device foo.sys in the directory \bin\devices of drive C: and it will take a numeric parameter to set the size of some buffer, you might load it with
device=C:\bin\devices\foo.sys 128
Note that it is essential to include the extension "sys" or else you will get an error message "bad or missing foo". The drive letter C: is not required but it can't hurt and I know of one person who claimed the device driver on her machine couldn't be found without it. The question of which parameters a given device driver allows or whether it allows any at all depends on the driver and should be dealt with in the documentation for the program in question. For the drivers ANSI.SYS and VDISK.SYS which come with DOS, I note that the former takes no parameters while the later takes parameters explained in the DOS manual. DOS 3.2 comes with a third driver called DRIVER.SYS while some versions of MSDOS 3.2 comes with an alternate ram disk called RAMDRIVE.SYS. Both take parameters.
Examples of Device Drivers: The Default Drivers
I will not attempt to describe all available device drivers since there are so many. For example, Chris Dunford, one of the sysops of Compuserve has written public domain programs which installs "devices" to control screen blanking (BURNDEV) and another allowing you to send control sequences easily to your speaker (SPKR). These represent examples where a real "device" is installed. A device is a virtual file which can typically be written too and read from. The most common example is "con" which you typically read from when you issue the command "copy con filename". Devices can only be installed via the CONFIG.SYS. Despite the name, the device command can load other programs which do not control devices and physical "devices" may not be devices in the sense of setting up a virtual file. A mouse is a good example of something which is not a device in this technical sense.
The hidden file IBMDOS sets up several devices even if you have no CONFIG.SYS: con, prn, aux, lpt1, lpt2, lpt3, com1, com2. Con, short for console is a combined keyboard / monitor device, prn for printer is by default a name for lpt1 and aux a name for com1. The DOS mode command allows reassignment of these devices. LPTn and COMn are names for the parallel and serial ports on the computer. These device names are assigned even if you don't have the full complement of ports.
Examples of Device Drivers: Console Drivers
The most common device driver to install is a console driver which replaces the default console driver. Some of these replacements attempt to address the notoriously slow display speed of the monitors and/or the annoying flicker on the color graphics display. In addition some of the escape sequences of the 1977 console standard of the American National Standards Institute (ANSI) are implemented. These sequences include ways of controlling colors, cursor position and some DOS level keyboard macros. (They are described in my article ANSI.ART). One console driver of this type called ANSI.SYS is supplied with DOS and takes about 2K of resident memory. It does not address the speed of display issue but it does implement several ANSI escape sequences. There are numerous programs which assume the ANSI.SYS is installed to operate properly (as well as a few that don't work properly if ANSI.SYS is installed!) so it is wise to install ANSI or an equivalent driver even if you do not want to use its features yourself. Actually, it is not hard to use the driver at the DOS level to set colors, set up a fancy prompt or redefine keys.
There are several alternatives available to ANSI.SYS which you might want to consider. NANSI.SYS is a public domain program which speeds up scrolling (when combined with RAW mode by a factor of about 2) and provides some additional ANSI escape commands at a cost of only 3K of RAM. FANSI CONSOLE and TALL SCREEN are two commercial programs (listing for $75 and $49 respectively) taking much more memory (around 60K with a reasonable amount of screen save memory) providing many more services: faster scrolling (FANSI only), screen blanking (FANSI only), DOS command line editing and recall (TALL SCREEN ONLY), screen memory and keyboard enhancements as well as additional features. While it is most natural to control scrolling by a device driver, there is at least one commercial com program which takes over the console by a different method and speeds up scrolling my a factor of six or more (FLICKER FREE). I am quite happy with FANSI but I have friends whose computer taste I trust using both NANSI and TALL SCREEN so the choice is not clear. And FLICKER FREE is an intriguing program whose second release (which will support the EGA) I eagerly await.
Examples of Device Drivers: Other drivers
If you have a Lotus / Intel / Microsoft EMS board or AST EEMS board, you will need to load a device driver to access this extended memory. Often the command will require various parameters to specify the amount of memory being set aside and various items like the region of conventional memory used for swapping and the port number to use. Be warned if you are setting up a CONFIG.SYS file for the first time that you may already have a CONFIG.SYS file which was made for you when you installed the EMS software that came with your board. Since this likely has the correct parameters, you should make your own CONFIG.SYS file by starting with this one and continuing from there. It is possible that you will need to load the EMS driver before anything else. I can report that if I try to load FANSI-CONSOLE on my AT before the EMS driver that Intel supplies with my Above Board AT, the EMS driver refuses to load and gives me the error message that my machine is "not a close enough AT compatible"! Also be warned that while there is an EMS "standard", this refers to the way EMS works once the driver that comes with your board is installed. More likely than not, drivers from different companies are incompatible and if you need a second EMS board, it will have to come from the company that supplied your first (this warning does not apply to extended memory on the AT but only to expanded EMS memory).
Some older hard disks are not self booting and require a device driver loaded in your CONFIG.SYS but that is not so common any more. DOS 3.2 has a program called DRIVER.SYS which is a device driver to initialize external 3.5 inch drives if you have one on an XT or AT. By far the most common drive device driver is to operate a RAM disk, that is a segment of RAM set aside as a fast virtual disk. There are com files loaded after the CONFIG.SYS which set up such drives but generally it is more sensible to use a device driver for this. DOS 3.x comes with a program VDISK.SYS to set up a RAM disk. This disk can operate in conventional or AT extended memory. It will not set up a RAM disk in EMS memory but most EMS boards come with device drivers to set up RAM disks in EMS. In addition Microsoft WINDOWS comes with a RAM disk device driver (which can be run independently of WINDOWS) and which can be set up in conventional, AT extended or EMS memory. Given Microsoft's experience and the care they have lavished on WINDOWS, I'd recommend using the WINDOWS RAM disk driver if you have it in preference to alternatives and, in particular to VDISK which also comes from Microsoft. However, if you are loading other programs that use AT extended memory, you may want to stick with VDISK because the specification that IBM uses to access AT extended memory is published while that of Microsoft is not and so other programs may clobber the Window's RAM DISK driver. If you want to set up more than one RAM disk, you can include more than one line loading a RAM disk driver in your CONFIG.SYS file. You can normally load the same driver twice or use different driver if you prefer. Be warned that there is typically a few K overhead in conventional memory to load a RAM disk and you will pay this overhead more than once if you load more than one RAM disk.
Print spoolers set aside some memory to receive printer output and then send that output to your printer as a background process. I regard them as a tremendous productivity tool. While there exist print spoolers loading as com files, many are loaded as device drivers.
The Microsoft Mouse requires software to install it so your system will recognize the mouse. The mouse comes with two versions of this software: MOUSE.SYS which is loaded as a device driver in your CONFIG.SYS and MOUSE.COM which is loaded later, typically in your AUTOEXEC.BAT. I do not believe there is any particular reason to prefer one over the other. Microsoft recommends using the device driver on all systems but the 3270 machines. If you are using Software Carousel, you'll want to use the com file in various partitions rather than the device driver.
As you may know you can place remarks in your BATch files and in particular in your AUTOEXEC.BAT. This is useful if you want to temporarily run your system without some resident program that is usually loaded in your AUTOEXEC.BAT file. You need only "remark it out", i.e. add the phrase "REM " at the beginning of the line including it. Technically, remarks are not allowed in CONFIG.SYS files. If you insert the word "REM" at the start of a line in your CONFIG.SYS file you will get the message:
Unrecognized command in CONFIG.SYS
However, since the rest of the line is not acted on, this procedure will have the desired effect of "commenting out" the line in question so you should not hesitate to use it.
ECHO also doesn't work in CONFIG.SYS so there is no direct way of placing messages on the screen during the loading of the CONFIG.SYS. However, there is a public domain program called COMMENT.SYS which allows you to echo comments to the screen via
device=path\comment.sys <message>
There is no stay resident part of comment.sys so you don't waste memory, only time, by using it. If you are a color freak, you can first load an ANSI compatible console driver and then use COMMENT.SYS to send color setting escape sequences to the screen and so see most of your bootup in living color!
The FILES Command
DOS is a prisoner of its past. Original IBM PC's came with only 16K of memory (!) so when DOS boots up it sets aside memory for various purposes in an incredibly frugal manner. The defaults for three regions of memory set aside for file handles, disk buffers and environment are woefully inadequate. If you know what you are doing, it is easy to change these defaults but it's unfortunate that the novice gets stuck with these small values. In any event, FILES and BUFFER commands are among the most important for you to include in your CONFIG.SYS. When DOS opens a file, it keeps certain information in memory to be able to quickly access the file. This information is called a file handle. During bootup, memory is put aside for these file handles so a limit is placed on the number of files that can be open at one time. The default is eight which may seem adequate since programs normally close files when they are done allowing the file handles to be reused. However, eight is often not adequate. DOS uses four of the handles itself for "files" like con and prn. Thus there are four available for your programs. Some resident programs leave files open and even the ones that don't, may need to open a file for an initial access at the same time that an application program have several files open. Database programs often have separate index and data files and typically may want to have more than four open files. If DOS is asked to open a file and a handle is not available, DOS issues an error message and the running program may even abort. I strongly recommend that you place the line
FILES=20
in your CONFIG.SYS file. Indeed since the cost of increasing files is less than 40 bytes per handle, you could even use a number larger than 20. For most purposes 20 should suffice but ever since it wasn't enough for me in a rather specialized situation, I've taken files=30 myself.
Buffers
You may have heard of disk caching. As you've noticed, diskette access is very slow and even a hard disk has access times 100 fold grater than RAM access times. Disk caching sets aside some RAM to keep a copy of the most recently accessed disk information so, for example, if a database is continually accessing a disk, the first time the disk is really read but the next time the copy in cache memory will be read instead. This is not the place to discuss the pros and cons of commercial disk caching software but you should know that DOS comes with some free rudimentary disk caching included. It keeps N buffers of 512 bytes each with the copies of the last N disk sectors accessed. By default N is only two (three on the AT). You should certainly make this number larger by including the line
BUFFERS=N
in your CONFIG.SYS where recommended values of N are between 10 and 25.
Let me tell you an anecdote to show how dramatic a difference this number can make. The first time that I ran my tape backup drive to backup my 30 meg hard disk, I was bitterly disappointed. Despite what I'd been told by the salesman, it took over 45 minutes! The next day, when I thought about it and tried again, it took only 8 minutes! What had happened? The first time I had been nervous about the effect my many resident programs might have so I put an original write protected DOS disk in drive A and rebooted before running the backup software. This disk had no CONFIG.SYS so I was running with the default three buffers. The next day, I used my regular hard disk boot with buffers=20 and that made the difference. I have done some time tests comparing something as simple as copying a directory from a hard disk to a floppy and I've found that using extra buffers can decrease times by 30 or 40 percent. So USE YOUR FREE DISK CACHING.
The issue of precisely how many buffers to take is not an easy one. Increasing the number of files handles has little effect on memory or efficiency so you can freely take files=99 if the mood strikes you. This is not so with buffers. Each buffer takes .5K of RAM so buffers add up. Moreover at some point it will take DOS longer to check through all its buffers looking to see if a file is there than it would take it to access it directly. I've seen the number 25 given as a dividing line but I would like to do some tests to check this out. I can only say that I've settled on buffers=20 myself and that with a floppy based system, you should take a higher figure than you might with a hard disk.
Increasing Your Environment
DOS sets up a special section of memory called the environment which has a default size of 160 bytes. This area must hold your path, your prompt, the place that COMMAND.COM can be found and various other strings. Programs can communicate with you by asking you to place information in the environment with the SET command. In addition you can keep global variables in the environment to pass between BATch files. If you attempt to place more there than it has room for you'll get a message "Out of environment space". With DOS 3.1 and later there is a CONFIG.SYS command allowing you to increase the amount of space reserved for your environment. There are known patches for earlier versions DOS which are listed for example in my article on ANSI.SYS. The procedure is documented in DOS 3.2 and so presumably it will be a permanent feature of DOS. It is undocumented in DOS 3.1. The syntax is
shell=C:\command.com /P /E:nnn
where n is the number of bytes you want to set aside for the environment. For DOS 3.1 nnn represents the number of 16 byte paragraphs you want to set aside. So for a 512 byte environment take nnn=32 in DOS 3.1 and 512 in DOS 3.2. Obviously with a floppy based system, replace C: by A:.
How much space do you need for your environment? That depends on your path, applications and how fancy a prompt you make. My advice is to do nothing until you have a problem at which point you should remember that there is something that you can do.
For more advanced users, I note that the environment is not as benign as you might think. I know of several programs which crashed if there was too much in the environment (most of the ones I know about have been fixed) and one that crashed if the PATH was the last thing set in the environment. I have occasionally been baffled at what could be causing a conflict only to discover the culprit was the environment.
Miscellaneous CONFIG.SYS Commands
There are some other commands that can go in your CONFIG. SYS:
- You can turn BREAK ON that is have the operating system check for control C more often than just during disk I/O. This slows down certain processing but gives you more safety from certain kinds of dead ends. The syntax is a line saying
BREAK=ON
Unlike any other CONFIG.SYS command, this one can also be issued from the DOS command line or in your AUTOEXEC.BAT file.
- In addition to file handles, DOS has something call file control blocks which in DOS 3.x can be changed by an FCBS command. These are needed only if you have a LAN (local area network) and the parameters to take should be discussed by your LAN software.
- DOS 3.2 has a STACK command. From what I've read this is a real cludge and the manual seems to suggest that it was added at the last minute to solve a problem connected with a new way that DOS 3.2 treats the stack. In any event, if you use DOS 3.2 and seem to have unexplained crashes, try adding
STACK=20
to your CONFIG.SYS.
- DOS 3.1 and later allows you to use the SUBST command to assign drive letters to directories. In addition, with several RAM disks you may want to assign a letter beyond the default last drive of E. DOS 3.x allows you to add a command
LASTDRIVE=?
where ? is a letter and then you can assign any drive up to and including that letter. Even a lastdrive=z only takes about 1 K of RAM.
- There is a COUNTRY command to control things like the time format. The default is USA.
One final remark about your CONFIG.SYS. The order of the commands is irrelevant except to the extent that certain device drivers like to be loaded before others (and if you are loading two RAM disks of different sizes you may care which is assigned which letter). As with most DOS commands the syntax is not case sensitive.
As a review of what a CONFIG. SYS can contain, let me list the CONFIG.SYS from one of my machines which is running DOS 3.2:
break=on
buffers=20
device=C:\bin\intel\emm.sys M3 I5 D
device=C:\bin\devices\fconbeta.dev
/C=1/S=2000/H=0/V=0/=200/L=1/W=1
device=C:\bin\devices\ramdrive.sys 1024 512 128 /A
device=C: \bin \devices\ramdrive.sys 1300 512 64 /E
device=C: \bin \devices\atqlpt1.sys 1644,1,3
device=C: \bin \devices\mouse.sys
files=30
lastdrive=z
shell=C:\command.com /P /E:512
What Should Your AUTOEXEC.BAT Contain?
Most of my AUTOEXEC.BAT file loads my own particular blend of resident programs. This is not the place for me to advise you on what resident programs you might want to put into your system but I would like to make some comments about DOS and general aspects of what goes into your AUTOEXEC.BAT file.
First, if you have very many resident programs, they may have conflicts and you must be prepared to permute the order of loading which often cures some or all of the conflicts. For technical reasons I won't go into here it really does pay to listen to SIDEKICK's demand to be loaded last although you need not take all the other Borland program demands quite so seriously.
In addition to loading a stable of resident programs your AUTOEXEC.BAT can contain some of the following:
- a VERIFY ON command. This slows down copying because DOS checks that the copy at least has consistent CRCs; this is not the same as comparing after copying but it is a fairly good check. Only several compensating errors could pass this test after an incorrect copy.
- set a PROMPT. At a minimum use
prompt=$p$g
Mine uses ANSI.SYS to set colors and place the path and date on the bottom line of my screen
- set a PATH. If possible, keep your path short since every time you type in a bad command, DOS will have to read every directory in the path before responding "Bad command or filename". Also try to list the path in the order of how many times you expect to access a given directory. That is place the directories you call most often early in your path. If you have a RAM disk, place its directories first in the path. If you have a relatively large RAM disk, think about copying your BATch file directory and the programs you call often to that RAM disk and place that RAM disk first in your path.
- If you have a large RAM disk, consider copying COMMAND.COM to it and placing the command
SET comspec=D:\command.com
in your AUTOEXEC.BAT (assuming D: is your RAM disk). Even without a large RAM disk, it is worthwhile to do this on a floppy based system. What the command does is tell DOS to look there when it needs to reload COMMAND.COM (large programs will overwrite a part of COMMAND.COM and when they exit, DOS will try to reload COMMAND.COM. With the above command, you'll no longer get "Place a disk with command.com in drive A: and hit any key to continue".)
- It really is important to put the proper date and time in your system. Be sure to include the DATE and TIME commands or else be sure to get a clock and place the appropriate commands setting the system time from the clock into your AUTOEXEC.BAT file.
- if you want to keep track of how often you boot, keep a record in a convenient directory. Make a file called junk consisting only of a carriage return line feed and include the lines
date >>directory\logon <junk
time >>directory\logon <junk
You will then get the lines
Current date is Wed 7-23-1986
Enter new date (mm-dd-yy):
Current time is 16:29:22.70
Enter new time:
for each time you bootup. With CED, EBL or some other programs you can get this record in a more elegant fashion without the "Enter new ..." lines.
Speed and Memory Tips
Some final remarks about tricks to minimize memory usage and speedup your bootup procedure. When DOS loads any program it saves a copy of the current environment in memory, one copy for each program. It doesn't force the copy to be as large as the empty space that you've set aside via a shell command but only to keep in full the present value of all environmental variables. Thus you can save memory by keeping the environment small while your AUTOEXEC.BAT file is loading your resident programs. Two variables are always present path and comspec. I start my AUTOEXEC.BAT file with a line
Path=A
This is incorrect syntax and gets ignored when the path is needed. I have to be sure to put down full path names of all the programs that I load but that speeds processing any ways. I reset the path and set the prompt at the end of my AUTOEXEC.BAT after I've loaded my resident programs. Given my fancy prompt, I save almost 200 bytes per resident program from what would happen if I set my path and prompt at the beginning of my AUTOEXEC.BAT. In total I save several K of RAM: not a lot but every little byte helps.
BATch files are read by DOS a line at a time so BATch files really do get processed much faster from a RAM disk than from a floppy. There is a smaller difference between a hard disk and a RAM disk. If you have a RAM disk and a floppy based system, it is well worth your while to place what would have been your AUTOEXEC.BAT in a file called startup.bat and have your AUTOEXEC.BAT read.
copy startup.bat C:
C: startup.bat
assuming your RAM disk is C:. To conserve space, you can have the last line in startup.bat say
erase C:startup. bat
You'll get a "batch file missing" error message but other than that the method will work perfectly. This procedure can also be used on a hard disk. The savings when I did it on my hard disk was two seconds out of about 65 so you may not feel it is worth your while.
You can slightly speed up processing of BATch files especially from floppies by using the FOR... IN... DO command to combine several commands in one line. For example, if you want to copy \bin\batfiles, \bin\dump and \bin\opsys to your RAM disk you might try
for %%a in (\bin\batfiles \bin\dump \bin\opsys) do copy %a C:\ >nul
if C: is your RAM disk. This can actually cut about 10% off a long AUTOEXEC.BAT file. Several warnings are in order. First, FOR... IN... DO parse the list at spaces so you can't combine commands which have parameters in this way. Secondly, I strongly recommend against using this device to load resident programs particularly if you plan to use Kokkenen's MARK/RELEASE package.
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 38
by Benjamin H. Cohen
An occasional gem of a comparison between Word Perfect and WordStar comes to my attention. For example, WP users seem to be astounded at WordStar's ability to put a non-printing note right in the middle of the file. I do it all the time. Clients or opposing counsel call up with requests that I add something to or change a draft contract I load up ZDE (well, we usually print with WordStar or NewWord) find the spot, hit ^N to insert a line (or several) enter three dots to make a note (I use Magic Series, too, which uses double dot commands, so I always use three dots for notes since two would be a command to Magic if we print the file with Magic), and start making notes on what the requested changes were. Then I make the changes while I'm on the phone, if they are short, or I wait until later to do the real work.
Depending on the situation, I may make a copy of the old paragraph and note it out, then make the changes so that the old and new are in the same file for ready comparison. If appropriate I may make a marked copy -- one showing the additions underscored and the deletions with strike-outs. Then a copy of that paragraph will be made into a note. In either event, when someone calls me I have a complete history of the revisions right in the file, including who asked for what revision when.
When I do change word processing software I'll want to be able to continue to do the same kind of thing.
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 39
by Benjamin H. Cohen
copyright Benjamin H. Cohen 1989
When I first started out with my Osborne 1 the file compression method in use was squeeze. Once a file was squeezed, a library utility (LU) would be put in a library file (.LBR) so that files would be grouped together and additional space could be saved. Squeeze has been supplanted (at least in some circles) by Crunch. LU has been largely supplanted by NULU (New Library Utility), and for some folks by VLU (Visual Library Utility) and a few others. In the MS-DOS world, ARC, ZIP, and other compression techniques have been developed, most of which use multiple algorithms (selecting the most efficient one for each target file) and gather multiple files together in a single ARC or ZIP or whatever. As these MS-DOS creations appear they are usually followed by CP/M utilities to open them up, so we have UNARC, ZIPDIR, and UNZIP.
Recently two new contenders have appeared on the CP/M scene: ARK (the CP/M equivalent of ARC) and LZH compression.
ARK compression is essentially similar to the ARC compression used by MS-DOS systems. By convention, ".ARC" files are for MS-DOS files and ".ARK" file are for CP/M files. ARK, like its MS-DOS counterparts, allows you to compress several files at one time while placing them in a single ".ARK", but unlike the LBR utilities the CP/M ARK utility has no ability to do any ARK maintenance: if you want to replace one file in an ARK you must get the group of files together and compress them all over again.
LZH is a new compression algorithm that is more efficient than the CRUNCH algorithm. LZH compression has been grafted onto Steven Greenberg's CRUNCH and UNCRUNCH Version 2.4, with the distribution file being called CRLZH11.LBR, and onto C.B. Falconer's Library Typer, in LT29.LBR. These work essentially the same way as CRUNCH 2.4 and LT 2.8, but the LZH algorithm has been added (or in the case of CRUNCH, it's areplacement).
The new ZIP algorithm for seems still more efficient, but there isn't a CP/M utility to make ZIP files, yet. On the other hand, UNZIP version 1.0 does seem to work well.
I performed a comparison to see how long it would take to squeeze (using NSWP 2.07 -- it's the only program I have around that squeezes), crunch, crunch with LZH, and ARK a 109 record (about 14K) text file, and how efficiently these programs would compress the text file. Table Three shows the relative efficiency in compressing the files, with a "Squeeze Rating" showing the compressed file size ratio to that achieved by LZH, the most efficient compressor.
Table One shows the timing results when done on a Kaypro 1 with a RAM disk and my "Overall Rating", which is the Time Rating (relative time compared to CRUNCH, the fastet compressor). Table Two shows the results when done on the same system on floppy disk.
The overall rating gives equal weight to elapsed time and file size saving. CRUNCH comes out on top because it is a lot faster than any of the other CP/M alternatives. The LZH algorithm saves about 7% more space, but takes more than twice as long. LZH comes out better on floppy disk because it makes the smallest file and the time to write the file is more significant on floppy disk than on the RAM disk.
Time saved for single files may be lost if you have to deal with multiple files, crunching them and then assembling them in a LBR file. ARK gains here, because it not only compresses the files but puts them in an ARK file at the same time. VLU (Visual Library Utility) will allow you to tag a series of files which VLU will then crunch and put in a LBR file all in one step. There are versions for vanilla CP/M systems and Z-System. For LBR file maintenance, however, NULU is still the king.
The compatibility factor may, however, indicate that ARK should be used. Files that may be transferred to MS-DOS computers can readily be UNARCed, but MS-DOS users may have problems with CRUNCHed files. My tests of the UNCR232 (for MS-DOS) indicate that it is unreliable. I don't know yet whether CRLZH files can be un-LZHed by any MS-DOS programs.
For personal use of single files, CRUNCH may be best: the files are only 12% larger than LZH files with a time saving that is considerable. But only the second half of the old saw, 'ya pays yer money and ya takes yer choice', applies here: all the programs are public domain.
TABLE ONE: In RAM disk
Raw Time Squeeze Overall
Method Time Rating Rating Rating
==============================================
SQ 52.8 1.70 1.76 2.98
CR 31.1 1.00 1.12 1.12
LZH 105.0 3.38 1.00 3.38
ARC 64.3 2.07 1.21 2.51
TABLE TWO: On floppy disk
Raw Time Squeeze Overall
Method Time Rating Rating Rating
==============================================
SQ 81.7 1.76 1.76 3.09
CR 46.4 1.00 1.12 1.12
LZH 124.6 2.69 1.00 2.69
ARC 99.8 2.15 1.21 2.61
TABLE THREE: Space Saved
Size in Percent Squeeze
Records Squeezed Rating
==========================================
ORIGINAL 429 --.-- -.--
SQ 297 69.23% 1.76
CR 189 44.06% 1.12
LZH 169 39.39% 1.00
ARC 205 47.79% 1.21
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 40
by Benjamin H. Cohen
No, WordStar International hasn't announced a new version of WordStar yet, but the tea leaves are beginning to fall in place. First there was the offer in the mail and now it's in WordStar News: your WS 5 free support ended on October 31 [6 months after the release of WS 5.5], so now you can upgrade to WS 5.5 for only $69.95 plus $2.50 shipping. Offer good through December 31, 1989, only. Tea leaves say: end of year is 8 months since last upgrade, last upgrade was not a full integer number, so it's time to move to verstion 6.
It's only logical. There are two ways that software houses make money: (1) sell to new users and (2) upgrade old users. While there may be more potential new users, there are still lots of actual users and while the 'list' price of WS 5.5 may be $495 the street price is around $220 and WordStar doesn't get all of that since the retailers have to make something. So an upgrade isn't all that much worse in revenue production than a new user.
When the potential of version 5.5 to tempt users to upgrade has run its course you need to come out with a version 6. There's another reason, too: the competition is and will be coming out with new versions with tempting new features. WordStar learned about this one the hard way: the length of time between WS 3.3 and WS 4 was so long that by the time WS showed up there were a number of upstart companies that had stolen the market from WordStar. Today WS is an also-ran (far behind Word Perfect and MicroSoft Word) in the word processing field, attracting few new users and losing old users all the time.
I won't get into the argument over whether WS is better or as good as WP or Word: I'm not familiar enough with WS 5 or 5.5 or WP or Word to be able to make an intelligent comparison. As a CP/M user I don't have to worry too much about it!
CFOG's PIP, November 1989, Volume 8 No. 4, Whole No. 72, page 40
by Benjamin H. Cohen
On my credenza I have two computers, a Kaypro 1 and an Osborne Executive (with Nuevo 2x2 ESU). WordStar 4 is on both of them. The WSPRINT:OVR file on each is identical, and comes from the 'new' WSPRINT.OVR file released by WordStar to correct the bugs in the original. One of those bugs was that with many printers WS4 would not send a formfeed to the printer after the last page. Try that one when you want multiple copies or send one file after another.
Here's my problem: when I print a file with the Kaypro everything is fine. When I print the same file using the same printer overlay on my Osborne Executive, there's no form feed at the end of the file.
To check this out I have even gone so far as to use WSCHANGE to modify the copy of WS.COM on the Kaypro 1 and then put it on the Executive. The only changes are the terminal and the active drives. It still doesn't work.