home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / sysutl / tools.lbr / TOOLS.DZC / TOOLS.DOC
Encoding:
Text File  |  1987-08-07  |  6.3 KB  |  144 lines
  1.  
  2. INTRODUCTION
  3.  
  4. Over  the years I've heard a lot of folks complain about  what    a
  5. poor  operating system CP/M is.  For a long time I had a  bit  of
  6. trouble  understanding    this,  because I've been using    CP/M  for
  7. quite some time and really like it. Then I realized: it's not the
  8. operating system kernel they dislike, it's the TOOLS. The baroque
  9. unfriendliness of ED is legendary,  and few CP/M users waste much
  10. time  tossing it in favor of a nice screen editor.  But even such
  11. "necessities"  as STAT and PIP leave a lot to be desired,  as  do
  12. the built-in commands such as DIR and REN.
  13.  
  14. An operating system really consists of 3 parts:
  15.  
  16.  o The kernel, consisting of I/O drivers and the file system.
  17.  
  18.  o The command processor (CCP,    for CP/M).
  19.  
  20.  o The utility programs (tools) supplied with the system.
  21.  
  22. The  kernel  of  CP/M is pretty nice.  It  supports  about  every
  23. function  one  could desire except heirarchical  directories  and
  24. multitasking,  and  it does it quite a bit more efficiently  than
  25. most.  It's  the other two parts of the system that seem to  give
  26. people    heartburn,  and indeed,  these two elements can  make  or
  27. break  an  otherwise  nice  operating  system.     That's  not  too
  28. surprising,  since these are the parts that represent the  user's
  29. interface to the system. CCP replacements such as ZCPR3 take care
  30. of the second area. It's the third one that I address here.
  31.  
  32. Looking  back on it,  I realized that I have  gradually  replaced
  33. _ALL_  the  utilities  of plain vanilla CP/M with  more  friendly
  34. tools  from  various  sources.    This includes  all  the  built-in
  35. commands  except SAVE,    which is pretty hard to get around.  Some
  36. tools I wrote myself, some are from the public domain, and one is
  37. proprietary.  Over the years,  I've managed to make CP/M a pretty
  38. comfortable environment for me.
  39.  
  40. The  purpose  of this library is to give other people  access  to
  41. the tools that have proven useful for me.  What I'm doing here is
  42. to  describe  the environment that I have built for  myself,  and
  43. provide  those    parts  of it that are  legal  to  distribute.  Of
  44. course,  one man's meat is another man's poison,  and I  wouldn't
  45. expect    you  to find this particular set of tools as  comfortable
  46. for you as I do for me.  A lot depends upon your style,  and  the
  47. kinds of things you like to use your computer for.
  48.  
  49. Fortunately,  each of us has the option of configuring our system
  50. to  be comfortable for ourselves.  That's what the 'P' in 'PC' is
  51. all  about.  I    would  encourage  you to  take    a  look  at  your
  52. environment  and  the  tools you are  using,  and  make  whatever
  53. changes you think will make life more enjoyable. Still, the tools
  54. provided here have a proven track record with at least one of us,
  55. and  you  may find them useful as a starting point for    your  own
  56. personalized environment. I hope you like them.
  57.  
  58.  
  59. WHAT IS A TOOL?
  60.  
  61. The CP/M built-in commands DIR,  ERA, REN, and TYPE, are built in
  62. so  as to make them readily available without having to do a disk
  63. access.  Gary  Kildall    reasoned  that these  commands    would  be
  64. used often enough so that the RAM space that they occupy would be
  65. justified.  It sounds like a reasonable enough decision,  but  in
  66. retrospect  it    has turned out not to be such a great  idea.  The
  67. reason    is  that all four of these commands  need  disk  accesses
  68. anyway,  so  the small amount of extra time that would have  been
  69. required  to read them from the disk is hardly    noticeable.  More
  70. importantly,  they aren't very good. That's why Rick Conn elected
  71. to make them optional in ZCPR3.
  72.  
  73. The  utilities    included  in  this package are    just  COM  files,
  74. programs like any other. So what makes them utility tools? Simply
  75. that they tend to be used often in the typical session, just like
  76. the built-in functions.  To be useful in such a mode, they should
  77. have the following qualities:
  78.  
  79.  o  They  should be small enough to be able to be read    from  the
  80.     disk in negligible time.
  81.  
  82.  o  They  should return to the CP/M command level without a time-
  83.     consuming warm boot.
  84.  
  85.  o  They should support command line arguments, and the syntax of
  86.     the command line should be consistent from tool to tool.
  87.  
  88. The tools supplied here conform to these rules.  The syntax  I've
  89. chosen is one that should be familiar to users of Multics,  Unix,
  90. MSDOS, OS-9, or ZCPR3:
  91.  
  92.      COMMAND ARG ARG ARG ....
  93.  
  94. that is,  the command followed by arguments, all separated by one
  95. or  more  spaces.  In  general,  the  arguments  can  consist  of
  96. arbitrarily long lists of arguments, and wild card file names are
  97. supported.
  98.  
  99. THE TOOLS
  100.  
  101. The following tools are supplied in this LBR file:
  102.  
  103.  o  LS - A replacement for DIR
  104.  
  105.  o  PR - A replacement for TYPE
  106.  
  107.  o  RN - A replacement for REN
  108.  
  109.  o  DL - A replacement for ERA
  110.  
  111.  o  DUMP - A replacement for the CP/M utility
  112.  
  113.  o  CP - A replacement for PIP (DOC only ... program is not PD)
  114.  
  115.  o  LIST - A file print utility
  116.  
  117.  o  FORMAT - A replacement for the CP/M utility (Kaypro '84 only)
  118.  
  119.  o  SYSGEN - A replacement for the CP/M utility (Kaypro only,  DOC
  120.     only)
  121.  
  122. FEATURES AND OPTIONS
  123.  
  124. A  word  about    style and  organization:  Different  people  have
  125. different  ideas  about  what  features  and  options  should  be
  126. included in a program. Some folks try to make a program to be all
  127. things for all people,    by trying to anticipate all possible uses
  128. for  the  program and providing optional arguments  for  them.    A
  129. typical example might be SD116, which wll give a directory sorted
  130. either    vertically  or    horizontally,    depending  upon  optional
  131. arguments provided on the command line. Other people would rather
  132. have two different programs for such cases.
  133.  
  134. I  tend strongly toward the latter view.  Lots of experience  has
  135. proven to me that, unless I use the programs every day, I tend to
  136. forget what the options are,  anyhow. There have been a number of
  137. studies  in  the literature that show that I'm not alone in  this
  138. respect. For this reason, my programs tend to be gutless wonders:
  139. small,    fast, and special-purpose, with a minimum of frills. If I
  140. want  to  do something different,  I either get or  write  a  new
  141. program.  Admittedly,  this  may not work for everyone,  but it's
  142. worked nicely for me.  In any case, all the tools in this package
  143. follow that philosophy.
  144.