home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ENTERPRS / CPM / UTILS / F / LH-CPM12.ZIP / LHVW12.UPD < prev    next >
Text File  |  1990-11-24  |  7KB  |  115 lines
  1. LHRD V. 1.2 UPDATE NOTES -- 5 April 1990
  2.  
  3.     When I first saw LHRD, I was very interested in using it both on an 
  4. RCP/M and on personal CP/M machines still kicking around my work studio. But
  5. I had several concerns with v. 1.1. So I undertook to quick-hack the
  6. following:
  7.     --    Ensure that line noise or an evil-minded RCP/M caller couldn't
  8.     potentially crash the system by grossly overwriting the arcname and
  9.     member filename buffers. V. 1.1 didn't check for this, so I added
  10.     appropriate code.
  11.     --    I can barely manage with programs which don't accept user-area
  12.     arguments, requiring that you first change user areas, THEN run the
  13.     programs. (So few programs still omit this feature that it's hard to
  14.     remember that fact when using them.) The new v. 1.2 accepts drive,
  15.     user area, both or neither as part of the arcname argument. Related
  16.     to the first point, the arcname buffer was extended to allow this
  17.     feature.
  18.     --    A few remaining RCP/Ms don't protect against command-line arguments
  19.     specifying private drives and/or user areas. Even for those that do
  20.     (like one I run), it's useful to have "legal" drives and/or user areas
  21.     on which files can be hidden yet accessed by selected callers, yet for 
  22.     which a given program won't execute. Also, many vanilla CP/M
  23.     systems hang outright if the user inadertently specifies an 
  24.     unavailable drive. For both these reasons, I added code to declare
  25.     a maximum and user area at compile time.
  26.     --    Some systems also hang (or at best demolish the screen display) if an
  27.     attempt is made to display .EXE and similar files. To this end, .EXE,
  28.     .COM, .OBJ and wildcard member filenames have been disallowed. This
  29.     list certainly isn't definitive, but does cover the vast majority of 
  30.     problems.
  31.  
  32.     The changes that have been made are less than polished, though have
  33. been tested as functionally sound. As such, they are released at this time.
  34. These modest changes involved efforts extending over five months, and enough 
  35. is enough!
  36.     Why five months? Several reasons, the least of which is that, though I
  37. develop software on a professional basis using C, I hadn't touched CP/M code 
  38. in some time. But far more significantly, I have no CP/M C compiler that would
  39. accept LHRC's source code without a significant rewrite, something I hadn't 
  40. the time or energy to do. So I put up a BBS flare for someone with AZTEC C 
  41. to "just compile and link" the changes. Poor, good-hearted Bill Mattson 
  42. responded.
  43.     In the intervening months filled with trips out of town by each of us,
  44. we communicated via a BBS. We discovered some "standard" C functions which I'd
  45. used in the modifications weren't available under AZTEC C or used compiler-
  46. specific syntax. And Bill wasn't familiar with some of the necessary linking 
  47. requirements for his compiler. And a typo or two somehow crept in when I 
  48. merged testing modules written under DOS into the original source code. And 
  49. lastly, an error in logic needed fixing. In many cases, Bill waded through my 
  50. hackings and some problems in the source code as I'd received it without
  51. requests or hints that he do so. In other cases, I reworked what he'd sent
  52. back my way.
  53.     In short, as all now tests well in practice, we're sending the baby
  54. out into the cold, cruel world. Good luck, kid. . . .
  55.  
  56.     Because the two libraries as I received them (LH-CPM11.LBR and 
  57. LHCPMSRC.LBR) are quite small and contained some redundancy in member files,
  58. and as some users will STILL want the older version (see below), I've merged 
  59. the libraries into the new LH-CPM12.LBR. This library contains all of the
  60. original documentation files in both libraries and the latest version of the
  61. source code. It also contains FOUR executable (.COM) files:
  62.  
  63. LHVWZ80.COM    This is the new version, compiled for Z-80 CP/M machines,
  64.         which covers just about all remaining CP/M machines these 
  65.         days. (If you're unsure, just try it and see if it bombs.)
  66. LHVW8080.COM    The new version, compiled with 8080 mnemonics. (Will run on
  67.         all CP/M machines, albeit a little slower than the above.)
  68. LHRD.COM    The earlier v. 1.1 untouched. This version EXTRACTS as well
  69.         as displays archive member files, and has no drive/user area
  70.         restrictions (or any of the other mentioned enhancements).
  71. LHVW.COM    V. 1.1 untouched. This is the VIEW-ONLY version.
  72.  
  73. Why might someone prefer one of the older versions? Well, with apologies, 
  74. recompilations arn't readily feasible here for the mentioned reasons and the
  75. currently available .COM files created from the revised source code DON'T do 
  76. two things:
  77.  
  78. 1) They don't EXTRACT files--just display them.
  79. 2) They don't accept arcnames for all drives and user areas on CP/M machines.
  80.    The maximum user area currently is set to 8, the maximum drive to C:.
  81.  
  82. Both of these features are right for our RCP/M. If someone has access to
  83. AZTEC C and can offer a minimal amount of time (really!) on the (now-
  84. -syntactically-checked!) source code, I would urge you to:
  85.  
  86. 1) Set maximum the maximum user to 15 and maximum drive to B: (by far the most
  87.    common configuration for CP/M machines).
  88. 2) Then recompile it twice, once with Z80 mnemonics, once with 8080.
  89. 3) Set the VIEWONLY compiler directive to false, then repeat step 2.
  90. 4) Finally, delete all the current .COM files in the library, replacing them
  91.    with the four newly-created copies.
  92.  
  93. Doing so would make the latest enhancements more useful to a broader set of
  94. users and would be a real service to the CP/M community. LHARC is a wonderful
  95. tool and CP/M users should be capable of maximizing use of archives they'll
  96. inevitably receive created by it.
  97.  
  98. For the cited reasons, I can't promise to undertake more work on this project
  99. (it was to be a night's work!). But if you discover bugs or envision major
  100. enhancements, I might be tempted. That temptation would be increased if
  101. someone with access to AZTEC C would be willing to share the chores Bill has
  102. so graciously accepted, far beyond his original commitment. (Depending upon
  103. his willingness to offer continued availability, it may even be necessary for
  104. someone to accept all compiling and linking responsibilities.) In any case, I
  105. would hesitate to ask him to continue to shoulder full responsibility.
  106.  
  107.     -- Jerry Olsen
  108.        Sysop, The Advocate / NOWAR RCP/M
  109.        312.939.4411 (central Chicago, 24 hrs., 300/1200/2400, 8/n/1)
  110.        Advocate Enterprises, Ltd.
  111.        117 W. Harrison Bldg.
  112.        6th Floor Mail Stop #A-408
  113.        Chicago, IL  60605
  114.  
  115.