INTRODUCTION Over the years I've heard a lot of folks complain about what a poor operating system CP/M is. For a long time I had a bit of trouble understanding this, because I've been using CP/M for quite some time and really like it. Then I realized: it's not the operating system kernel they dislike, it's the TOOLS. The baroque unfriendliness of ED is legendary, and few CP/M users waste much time tossing it in favor of a nice screen editor. But even such "necessities" as STAT and PIP leave a lot to be desired, as do the built-in commands such as DIR and REN. An operating system really consists of 3 parts: o The kernel, consisting of I/O drivers and the file system. o The command processor (CCP, for CP/M). o The utility programs (tools) supplied with the system. The kernel of CP/M is pretty nice. It supports about every function one could desire except heirarchical directories and multitasking, and it does it quite a bit more efficiently than most. It's the other two parts of the system that seem to give people heartburn, and indeed, these two elements can make or break an otherwise nice operating system. That's not too surprising, since these are the parts that represent the user's interface to the system. CCP replacements such as ZCPR3 take care of the second area. It's the third one that I address here. Looking back on it, I realized that I have gradually replaced _ALL_ the utilities of plain vanilla CP/M with more friendly tools from various sources. This includes all the built-in commands except SAVE, which is pretty hard to get around. Some tools I wrote myself, some are from the public domain, and one is proprietary. Over the years, I've managed to make CP/M a pretty comfortable environment for me. The purpose of this library is to give other people access to the tools that have proven useful for me. What I'm doing here is to describe the environment that I have built for myself, and provide those parts of it that are legal to distribute. Of course, one man's meat is another man's poison, and I wouldn't expect you to find this particular set of tools as comfortable for you as I do for me. A lot depends upon your style, and the kinds of things you like to use your computer for. Fortunately, each of us has the option of configuring our system to be comfortable for ourselves. That's what the 'P' in 'PC' is all about. I would encourage you to take a look at your environment and the tools you are using, and make whatever changes you think will make life more enjoyable. Still, the tools provided here have a proven track record with at least one of us, and you may find them useful as a starting point for your own personalized environment. I hope you like them. WHAT IS A TOOL? The CP/M built-in commands DIR, ERA, REN, and TYPE, are built in so as to make them readily available without having to do a disk access. Gary Kildall reasoned that these commands would be used often enough so that the RAM space that they occupy would be justified. It sounds like a reasonable enough decision, but in retrospect it has turned out not to be such a great idea. The reason is that all four of these commands need disk accesses anyway, so the small amount of extra time that would have been required to read them from the disk is hardly noticeable. More importantly, they aren't very good. That's why Rick Conn elected to make them optional in ZCPR3. The utilities included in this package are just COM files, programs like any other. So what makes them utility tools? Simply that they tend to be used often in the typical session, just like the built-in functions. To be useful in such a mode, they should have the following qualities: o They should be small enough to be able to be read from the disk in negligible time. o They should return to the CP/M command level without a time- consuming warm boot. o They should support command line arguments, and the syntax of the command line should be consistent from tool to tool. The tools supplied here conform to these rules. The syntax I've chosen is one that should be familiar to users of Multics, Unix, MSDOS, OS-9, or ZCPR3: COMMAND ARG ARG ARG .... that is, the command followed by arguments, all separated by one or more spaces. In general, the arguments can consist of arbitrarily long lists of arguments, and wild card file names are supported. THE TOOLS The following tools are supplied in this LBR file: o LS - A replacement for DIR o PR - A replacement for TYPE o RN - A replacement for REN o DL - A replacement for ERA o DUMP - A replacement for the CP/M utility o CP - A replacement for PIP (DOC only ... program is not PD) o LIST - A file print utility o FORMAT - A replacement for the CP/M utility (Kaypro '84 only) o SYSGEN - A replacement for the CP/M utility (Kaypro only, DOC only) FEATURES AND OPTIONS A word about style and organization: Different people have different ideas about what features and options should be included in a program. Some folks try to make a program to be all things for all people, by trying to anticipate all possible uses for the program and providing optional arguments for them. A typical example might be SD116, which wll give a directory sorted either vertically or horizontally, depending upon optional arguments provided on the command line. Other people would rather have two different programs for such cases. I tend strongly toward the latter view. Lots of experience has proven to me that, unless I use the programs every day, I tend to forget what the options are, anyhow. There have been a number of studies in the literature that show that I'm not alone in this respect. For this reason, my programs tend to be gutless wonders: small, fast, and special-purpose, with a minimum of frills. If I want to do something different, I either get or write a new program. Admittedly, this may not work for everyone, but it's worked nicely for me. In any case, all the tools in this package follow that philosophy.