home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / v / valen102.zip / SYSOP.DOC < prev    next >
Text File  |  1993-03-16  |  29KB  |  622 lines

  1.                                   Valence
  2.                           QWK Door for Searchlight
  3.                                 version 1.02
  4.  
  5.                              by William McBrine
  6.                    Copyright (c) 1993 Iconoclast Software
  7.  
  8.             Written using the Searchlight Programmer's Libarary
  9.               Portions Copyright (c) 1992 Searchlight Software
  10.  
  11.  
  12. :::: INTRODUCTION ::::
  13.  
  14. This program is my own dream QWK door. There are no compromises or half-
  15. measures anywhere in it. It doesn't compromise the QWK format, and it
  16. doesn't compromise Searchlight's features. You get full support of such
  17. features as included files, color codes, and metacharacters, as well as such
  18. basics as Bulletins and Welcome, News, and Goodbye files. Plus, the setup is
  19. both extremely simple and extremely flexible, making use of Squish's
  20. COMPRESS.CFG for archivers, and Searchlight's own definitions for protocols.
  21. And the program has so far proven to be very fast and very reliable.
  22.  
  23. I won't give you an intro to the idea of the QWK format or offline reading
  24. here; by now, I assume that if you're reading this, you know what it's
  25. about. (If not, you may find more info in VALENCE.DOC.) You may also know
  26. something of the less-than-illustrious history of offline reading with
  27. Searchlight. Those days are past. Offline reading should be simpler, easier,
  28. and MORE FUN than online reading, not less. Not to brag, but with Valence, I
  29. believe Searchlight has finally reached that point.
  30.  
  31. I first started planning this program last summer, and did some of the code
  32. then and sporadically since, but most of it has been written in the past
  33. month. For speed and compactness, much of the program is written in
  34. assembly, and I intend to convert even more of it to assembly. The rest is
  35. written in Turbo Pascal 6.0. (I'd like to complement Borland for having an
  36. assembler built into their Pascal compiler that's easier to use than bloody
  37. MASM.) Valence makes extensive use of the SLTPUs, and I modified the index
  38. number conversion routine (which comprises maybe sixteen bytes out of the
  39. whole program) from one printed in Patrick Y. Lee's text file on the QWK
  40. format, and credited to Greg Hewgill (with a question mark). The rest is
  41. entirely by me, from scratch. It was quite a lot of scratching, too.
  42.  
  43. I use this program every day myself. Indeed, while writing it I sometimes
  44. found it hard to tear myself away from reading messages to actually work on
  45. the program. What can I say - I'm a message addict. :-)
  46.  
  47. Valence should work with all versions of Searchlight from 2.15C through 3.0
  48. (and beyond), but it has only been tested with 2.25D, 2.25 Demo, and 3.0
  49. beta. I've tried to iron out all the bugs, and it seems quite reliable to
  50. me, but of course I assume NO reponsibility if it annihilates your board.
  51. :-)
  52.  
  53.  
  54. :::: LICENSE DISAGREEMENT ::::
  55.  
  56. Among the many great features of Valence, the best one may be its price:
  57. $0.00.
  58.  
  59. You are hereby authorized to make as many copies of this program as you
  60. like, and use it on as many machines simultaneously as you like, forever,
  61. without paying me anything, as long as you're not making any money off of
  62. it. Commercial use requires a license (which I'll worry about when it comes
  63. up). This program may be freely distributed throughout the universe,
  64. provided you charge no more than a minimal copying fee (say, $5.00).
  65. Distribution of the program at profit, or bundled with commerical software,
  66. requires a license.
  67.  
  68. *** Why free? ***
  69.  
  70. Because I'm a programmer, not a businessman. I have no interest in that
  71. stuff, and really just can't be bothered. Because I hate all registration
  72. "incentives" and crippling, and couldn't stand to contaminate my program
  73. with such. Because I don't want to be subject to the harassment I've
  74. witnessed recently of authors who didn't "deliver" in a timely manner on
  75. things such as registration keys. Because I don't want to contaminate my
  76. program CODING registration keys. Because I did it out of love. Because I
  77. did it for myself. Because it's too good to keep to myself. Because I'm a
  78. Hacker.
  79.  
  80. *** However ***
  81.  
  82. Donations will be MORE THAN WELCOME!!! AS LONG AS you understand that if you
  83. send me a donation, this is NOT a business transaction, that you are NOT
  84. "registering", and that I am NOT being placed under any obligation to
  85. "support" the program or you. I will be more than happy to support it, in
  86. reality, but I will *NOT* be OBLIGATED to do so.
  87.  
  88. If I have to suggest an amount, I'll say "whatever you would've paid for
  89. that other offline mail door you don't have to register now". :-)
  90.  
  91.  
  92. :::: SETUP ::::
  93.  
  94. You'll believe me if I say the system requirements are "minimal", when I
  95. tell you Valence was written and developed entirely on an 640k 8088, 8mhz,
  96. with CGA monitor, one 5.25" DD and one 3.5" DD drive, and NO hard drive!!
  97. And it runs beautifully on this system. I can even shell to ARJ (a notorious
  98. memory hog) to archive the packets, while running under Searchlight (2.25
  99. Demo), with a 128k ramdisk and 24k DIET driver loaded.
  100.  
  101. One thing you SHOULD have is a lot of file handles to open. At its worst,
  102. Valence has eleven files open at once. I recommend setting FILES=xx in your
  103. CONFIG.SYS to some ungodly number.
  104.  
  105. The setup is designed to be as simple as possible, yet allow maximum
  106. flexibility. If you haven't yet, read the READ.ME file, and try the
  107. INSTALL.EXE program. You can have Valence up and running on almost any
  108. Searchlight system in seconds.
  109.  
  110. For options beyond what Install asks, please read the included VALENCE.ORG,
  111. COMPRESS.CFG, and INTPROT.CFG files. These are the actual configuration
  112. files used by Valence (VALENCE.ORG should be renamed VALENCE.CFG to run it),
  113. complete with extensive comments.
  114.  
  115. Note that VALENCE.ORG, as supplied, boils down to this:
  116.  
  117. BBSID     NAKED
  118. Sysop     William McBrine
  119. Locale    Salisbury, NC
  120. Phoneno   704-633-7817
  121. Rename
  122.  
  123. To Valence, they are exactly equivalent. This is all the basic info you need
  124. in the .CFG file, and you may never want to use more. But there are a
  125. plethora of options there if you need them.
  126.  
  127. In the two most important and complex parts of the configuration, archivers
  128. and protocols, I've tried to reduce the sysops' work to zero, while adding
  129. about as much flexibility as possible.
  130.  
  131. *** Memory usage ***
  132.  
  133. Valence takes up about 130k when shelling to an archiver or protocol, and a
  134. variable amount over 32k beyond that the rest of the time. (The amount
  135. depends on the number of subboards you have; usually it will be very small.)
  136. I am hoping to reduce the memory usage in future versions. For my comments
  137. on swapping out to disk/EMS/XMS, see below under "FOR THE FUTURE".
  138.  
  139. *** Protocol configuration ***
  140.  
  141. For external protocols, the protcol engine uses Searchlight's own
  142. definitions. If the protocols work in Searchlight, they should work in
  143. Valence. It doesn't get much easier. For the "internal" protocols, read the
  144. text file INTPROT.CFG, and edit it as needed.
  145.  
  146. Bidirectional protocols are supported by scanning for uploaded .REPs after
  147. each Download. However, this feature is at present untested.
  148.  
  149. *** Archiver configuration ***
  150.  
  151. For its archiver setup, Valence turns to the brilliant "COMPRESS.CFG"
  152. file format, as used by Squish (and, increasingly, other programs). There is
  153. a sample COMPRESS.CFG included with Valence; if it works for you, you may
  154. not need to worry anymore about it. You should at least check it for
  155. protocols you don't have on your system, however. If you're using a
  156. COMPRESS.CFG currently, you can set Valence up to use that one. See my
  157. COMPRESS.CFG and VALENCE.ORG for details.
  158.  
  159. *** Manual setup ***
  160.  
  161. With the included INSTALL.EXE, I hope you'll never have to look at the
  162. inside of a menu file when setting up Valence. But if you WANT to, technical
  163. details are as follows:
  164.  
  165. Valence should be run with com support turned ON - on the menus, that means
  166. either "Standard" or "Force Color". (Force Color is used by INSTALL.EXE.) In
  167. a DOORS.DEF-style file, it means "1" or "2" for the first value. Next,
  168. "Abort" should be set to NONE (0 for DOORS.DEF). Valence will recognize when
  169. carrier is lost and recover by itself. Needless to say, write-protect should
  170. also be off. For the directory setting (here's where it gets interesting),
  171. DO NOT specify the path to the Valence directory! Use a "." to indicate the
  172. current directory to Searchlight. THEN, in the "Command" field, specify the
  173. full pathname to Valence (e.g., "C:\VALENCE\VALENCE.EXE"). Please include
  174. the ".EXE" extension, to save yourself some loading time and memory.
  175.  
  176. Valence will read the CONFIG.SL2 file from the current directory, if
  177. present; if not, it checks the "SLBBS" environent variable. Note that with
  178. Valence, unlike many other programs, you DO *NOT* NEED to set this variable!
  179. You may, if you like, but it shouldn't be needed. It finds its own data
  180. files in the directory of the .EXE, regardless of what directory it was run
  181. from.
  182.  
  183. When run without parameters, Valence will pop up a simple menu. When run
  184. with a parameter, it will jump directly to one of the functions on that
  185. menu. The recognized parameters are:
  186.  
  187. 'D': dowmnload
  188. 'U': upload
  189. 'O': set options
  190. 'S': edit subboard list
  191. 'P': upload pointer files
  192.  
  193. Only the first letter is checked, and case is irrelevant. Install uses these
  194. parameters to create a menu bar with six options on it (the sixth being
  195. "Quit").
  196.  
  197. A sample DOORS.DEF line for Valence:
  198.  
  199. 2;0;0;5;Valence QWK Door (offline mail);.;C:\VALENCE\VALENCE.EXE
  200.  
  201. You can get the same thing, with variations in access level and directory as
  202. appropriate, by running "INSTALL D". For a sample menu entry, please run
  203. Install and examine the .MNU it produces ("VALENCE.MNU", by default). You
  204. can modify this as you like, just like any other .MNU. Also, you'll have to
  205. edit the menu THAT menu is entered on if you want to set attributes for
  206. Valence as well as access levels; at present, the Install program doesn't
  207. ask for attributes.
  208.  
  209. *** Multiple MAIN.SUBs ***
  210.  
  211. This is a tricky one. If you're using more than one MAIN.SUB, and swapping
  212. them, you have to kludge around it. You can either combine the subboard
  213. lists into one file, and place it in the Valence directory, or have separate
  214. Valence directories to correspond with each MAIN.SUB. (In the latter case,
  215. you also need to swap menus or door lists.) If you DON'T do this, you'll get
  216. people uploading replies to the wrong subboards.
  217.  
  218. Combining the subboard lists is, I hope, self-explanatory. But if you want
  219. to maintain truly separate sub-BBSes, you have to use the multiple install
  220. method. When doing this, make SURE you enter a different name than "Valence"
  221. (the default) at the "Command name [Valence]:" prompt in Install for the
  222. second and subsequent installations. Otherwise, the first menu will be
  223. overwritten.
  224.  
  225. The principle to remember here is that if you have separate MAIN.SUBs,
  226. you're essentially setting up completely different boards, and you must
  227. treat them as such. Each separate installation of Valence should have its
  228. own BBSID, so any packets mistakenly uploaded under the wrong MAIN.SUB will
  229. be rejected.
  230.  
  231. You can mix and match these methods. Say you have three MAIN.SUBs:
  232.  
  233. MAIN.SUB
  234. FIDO.SUB
  235. ADULT.SUB
  236.  
  237. And say your board is named "My BBS". You might set up Valence twice; in the
  238. first installation, say in directory "C:\VALENCE", you can combine MAIN.SUB
  239. and FIDO.SUB into the file "C:\VALENCE\MAIN.SUB", and use the BBSID "MYBBS".
  240. In the second installation, say in "C:\VAL-AD", you could use the BBSID
  241. "MYADULT". Note you would not need a MAIN.SUB for this installation,
  242. providing it could only be run while ADULT.SUB was active.
  243.  
  244. If you CAN'T swap menus or door lists for different MAIN.SUBs, you can have
  245. two or more installations of Valence with fixed MAIN.SUBs in each Valence
  246. directory accessible from the same menu or door list.
  247.  
  248. Note there's an option for users to turn off the MAIN.SUB file altogether,
  249. which avoids the whole problem (and makes Valence work like some lesser QWK
  250. doors). This could, however, be regarded as a security breach. My advice to
  251. you is to have certain attributes required for access to each subboard not
  252. on the main list. In fact, speaking generally, you're much better off
  253. dividing your subboards with attributes than with MAIN.SUBs.
  254.  
  255.  
  256. :::: BASIC OPERATION ::::
  257.  
  258. The basic operation is outlined in VALENCE.DOC, but there are a few details
  259. which differ when you use it in local mode.
  260.  
  261. When Valence shells to an archiver or protocol, you'll see four numbers
  262. displayed. E.g.:
  263.  
  264. 265840 265632
  265.  
  266. 298000 298000
  267.  
  268. (These are made up and do not reflect real values.) The bottom two are the
  269. amount of free memory when shelling, and should both be the same (let me
  270. know if they aren't!). You can use this for debugging. It is NOT displayed
  271. to the remote users, only at the local console. (Neither is the display from
  272. the archiver or protocol.) The top two numbers are the amount of free memory
  273. and the size of the largest free block before RELEASE-ing the heap. This is
  274. really just left over from my own debugging, but it may be useful to others
  275. as well.
  276.  
  277. *** Local mode ***
  278.  
  279. When running Valence locally, you must either run it under Searchlight, OR,
  280. exit Searchlight by responding "No" to the "Reset?" prompt, rather than by
  281. pressing ALT-X at the waiting screen, and make sure you run it in the way
  282. outlined above under "Manual Installation": from the directory of the node
  283. you were logged in to, with the full path to VALENCE.EXE.
  284.  
  285. *** Downloads ***
  286.  
  287. Instead of invoking a protocol to send the file, Valence will simply move
  288. the file to a directory specified in VALENCE.CFG, and will rename it with a
  289. number appended if need be. The directory defaults to the Valence directory.
  290. See VALENCE.ORG for details.
  291.  
  292. *** Uploads ***
  293.  
  294. Same deal here. The .REP file is read from the directory specified, or from
  295. the Valence directory. Note that while remote users can use free-form names
  296. (anything with the .REP extension is accepted), local users must rename
  297. their .REPs in the form "<BBSID>.REP", if they aren't already named that.
  298.  
  299. *** Pointers ***
  300.  
  301. The pointer files MUST BE RENAMED to "<BBSID>.PTR" when used locally. When
  302. used remotely, "<BBSID>.PT*" are accepted. Non-batch protocols will rename
  303. the file to "<BBSID>.PTR". Since none of the three included .PT* files
  304. actually ends in ".PTR", you'll HAVE to rename it here. .PTR files are
  305. retrieved from the same directory as .REPs.
  306.  
  307.  
  308. :::: TECHNICAL DETAILS ::::
  309.  
  310. Oh, you thought we were already into that part, eh? :-)
  311.  
  312. There is considerable semi-technical info in the files VALENCE.ORG,
  313. COMPRESS.CFG, and INTPROT.CFG, and I refer you there for most of it.
  314.  
  315. VALENCE.EXE is compressed with LZEXE 0.91. The uncompressed size on last
  316. compile was 110960 bytes.
  317.  
  318. *** Shelling ***
  319.  
  320. I put as much of my data as possible on the heap, and Valence discards it
  321. when shelling. Also I've used local variables on the stack extensively - I
  322. even put an 8k buffer on the stack in several places.
  323.  
  324. Note that when I said the memory use when shelling depends on how many
  325. subboards you have, that doesn't mean I keep Searchlight's subboard list in
  326. memory. The only heap data that isn't released is the user's subboard list
  327. from the user file (see below).
  328.  
  329. On my last compile, I had 91840 bytes code, 25932 bytes data, and 16384
  330. bytes stack. Add a few hundred bytes to that and you have the memory used
  331. when shelling.
  332.  
  333. *** User file ***
  334.  
  335. One of the cleverist bits in Valence is the user file. This file records not
  336. only the myriad options, but the list of subboards for each user. The
  337. sublist is used for two things: to translate the record numbers on uploaded
  338. .REP messages, and to hold the special attributes for each subboard (i.e.,
  339. scan in personal-only mode or personal/all mode, enforce fido taglines,
  340. allow high-bit characters in uploads, and the ansi/metacharacter conversion
  341. options). Each subboard takes up 2 bytes if you have under 255 subboards on
  342. your system, and 3 bytes if you have 255 or over. This is rounded up to the
  343. nearest 128 bytes, and the main part of the user record is also 128 bytes.
  344. The header for the file overall is 128 bytes.
  345.  
  346. The user file will grow along with your system; if you add subboards that
  347. take it past the limits of the current record size, Valence will
  348. automatically (and quickly) resize the whole file the next time it's run. It
  349. will start out with the smallest record size that will contain the number of
  350. subboards you have when it's first run. Thus, small systems with little
  351. drive space are not penalized by oversized user files, but large systems
  352. with hundreds of echos can easily be accomodated. Note the user file is only
  353. resized up, never down.
  354.  
  355. For rapid searches, the user file is constructed as a binary tree. This is
  356. just like Searchlight's user file, except there is no parent pointer in
  357. Valence, only left and right. There's no parent pointer because there are no
  358. deleted records. New users are always added to the end of the file. Removal
  359. of users deleted from the BBS will require a separate maintenance program,
  360. to be released later. I don't think you'll find this is a problem, though.
  361. The maintenance program should also allow you to resize the user file down
  362. if you've deleted subboards.
  363.  
  364. *** Errorlevels ***
  365.  
  366. There a bunch of errorlevels returned by Valence - a different one for each
  367. error message. At present, there is nothing to check these, but perhaps they
  368. will be useful in the future (in a QWK network environment?). Errorlevels
  369. start at 80.
  370.  
  371. *** Limitations ***
  372.  
  373. The maximum length for a single message in QWK mode is limited to from 16 to
  374. 32k, depending on how full the output buffer is at the time the message is
  375. processed. There is no limit in Text mode. (The theoretical maximum length
  376. of a Searchlight message is 77 characters (76 per line, plus EOL) times 400,
  377. or 30800 bytes. However, this does not include INCLUDEs, which (as far as I
  378. know) can be any length.) I intend to double the size of the buffer
  379. eventually. Note that a reader like SLMR, which limits the length of
  380. messages to 150 lines, can't read more than 12k per message anyway.
  381.  
  382. Valence theoretically limits you to 8191 subboards. Memory usage makes the
  383. actual limit more like 1000-2000. Let me know if this is a problem for
  384. anybody. :-)
  385.  
  386. Oh, and you can only have two billion users, and they can only download two
  387. billion messages before the number overflows into a negative value.
  388.  
  389.  
  390. :::: WHY "VALENCE"? ::::
  391.  
  392. When I first started planning this program, last June or so, I intended to
  393. call it "Spotlight". Then, recently, that name was preempted. :-( After
  394. that, my second choice was "Maverick"... that kinda got preempted too. So
  395. I'm left with a more or less random name. It has a nice sound, I think, but
  396. it doesn't have any real meaning or signifigance. (Sorry to disappoint those
  397. of you who were thinking, "Gee, I wonder why he called it that? Bet there's
  398. a good story behind it." :-)) It may be changed if I think of a better one.
  399.  
  400.  
  401. :::: FOR THE FUTURE ::::
  402.  
  403. The future of this program depends on you. Send me your complaints,
  404. suggestions, and especially donations.
  405.  
  406. *** Known flaws in the present version ***
  407.  
  408. * Although the colors in the display are read from CONFIG.SL2, the colors in
  409.   the filelist and the headers in Text mode are hard-wired. This should be
  410.   corrected. The color scheme may also need revision (what do you think?).
  411.  
  412. * High-speed modem download time calculation is not very accurate. This MAY
  413.   be fixed shortly for systems running 3.0+; have to wait for details on 3.0
  414.   and see. In any case, it should not be fatal.
  415.  
  416. * Lines in uploaded messages are simply truncated if they're over 76
  417.   characters long. I hope to add an option to wrap instead.
  418.  
  419. * The ANSI wrap is applied only to included files. Some readers (SLMR, at
  420.   least) will rather crudely "wrap" the line at 80 characters if it goes
  421.   over that length. If a message has color codes and replacement characters
  422.   in it, it may be subjected to this. I may apply wrapping to regular
  423.   message lines in the future to correct this.
  424.  
  425. * The ANSI wrap works great on pictures that fit within one screen, even
  426.   animated ones, but messes up on scrolling pictures. I can fix this, but it
  427.   may be more trouble than it's worth.
  428.  
  429. * In implementing Searchlight's color codes, I had to make a choice about
  430.   "\no" ("normal"). In Searchlight, this is a different color for every
  431.   system, but Valence will use light grey (color 7) always, which is the
  432.   ANSI default. To do it the Searchlight way, I would have to insert a color
  433.   code at the beginning of EVERY message, even those with no ANSI in them,
  434.   because I'd have no way of knowing beforehand whether it was needed.
  435.   However, the code to do it this way is already implemented, and it should
  436.   be an option in future versions - at least for text packets, if not QWK.
  437.  
  438. * The (non-)handling of MAIN.SUB swapping is a kludge - when I designed it,
  439.   I called it "the Tom Curtis kludge", because I did it only to kludge
  440.   around HIS kludge of using a batch file to swap his MAIN.SUB and ADULT.SUB
  441.   subboard lists. Since swapping the MAIN.SUBs is now a real feature of
  442.   Searchlight, with its own internal command, I'll have to try to find a
  443.   better way to handle it.
  444.  
  445. * Swapping out to disk/EMS/XMS - There is no swapping. There will not be any
  446.   swapping, unless I get a machine I can test such a feature on. (640k and
  447.   two floppies won't do it.) If you want swapping, send me a lot of money.
  448.  
  449. * Despite my best attempts to eliminate sources of lockups, the SLTPUs will
  450.   occasionally hang on a grunged message (as will Searchlight). For this
  451.   reason, as well as reasons of speed, I'd like to replace them with my own
  452.   code, but first I need more info on Searchlight's internal text format.
  453.   (Anybody that has it, shoot.)
  454.  
  455. * The .PTX files will not be recognized when uploaded using protocols that
  456.   save in even block sizes, such as Xmodem. I only just realized this as I
  457.   typed it into VALENCE.DOC. :-(
  458.  
  459. * Subboard attributes other than Personal and Personal/All cannot be set
  460.   remotely, only online.
  461.  
  462. * The Install program leaves two copies of VALENCE.DOC on your disk - one to
  463.   be sent to new users automatically, and one to be pulled up as a help file
  464.   when users press ? on the "Valence" option, if it's allowed on that menu.
  465.   This is a bit wasteful, as the file is 40k. You can delete the help file
  466.   version of it if you like. (In some menus, it won't be accessible anyway.)
  467.  
  468. * It has been pointed out to me that there are cosmetic inconsistencies,
  469.   e.g.,  the use of the term "High" in the subboard list editor, but the
  470.   term "Last Read" in the new message scan to mean the same thing.
  471.  
  472. * There are some others that I know of which slip my mind at the moment.
  473.  
  474. *** What you'll see in future versions ***
  475.  
  476. * Carbon copies - Put a "CC: name, name, name" in your message and the
  477.   header will automatically be duplicated to those people, just like in
  478.   Searchlight.
  479.  
  480. * Netmail - As soon as Frank releases the information. Right now, Valence
  481.   will recognize received netmail and put a "Netmail: x:xxx/yyy" message in
  482.   the first line of any netmail you receive, but it will not send netmail.
  483.  
  484. * QWK networking - As soon as I get ANY info on how it works. Right now I
  485.   have NOTHING!! If you have any text files on the subject, please send them
  486.   my way. I think I have a solid base for QWK networking, because in testing
  487.   I've done things like upload 500 messages in a .REP packet, without a
  488.   hitch (it went just about as fast as the download). Much faster than
  489.   SLMAIL, too.
  490.  
  491. * User file maintentance program - To trim VALENCE.USR. As it is, it only
  492.   grows, never shrinks. Valence of course has no way of knowing when users
  493.   are deleted from the BBS. The maintenance program will compensate.
  494.  
  495. * Long message split - Many readers can only handle messages up to x lines
  496.   long, and truncate them if they go over the limit. Invariably, x is way
  497.   less than Searchlight's max of 400 lines. I hope to be able to split long
  498.   messages into multiple messages automatically; but this will require a
  499.   signifigant rewrite.
  500.  
  501. * Option to tear off messages below tearlines in uploaded messages - That's
  502.   why they're called tearlines, right? This is already coded and in fact is
  503.   one of the first elements of Valence I wrote, but the option isn't set up
  504.   yet.
  505.  
  506. * Running without being logged in - As it is, sysops running Valence locally
  507.   must still be "logged in" to use the program. Also, running without being
  508.   logged in may allow pre-packing of mail.
  509.  
  510. * %% upload - You'll be able to send a message to Valence and have it
  511.   convert it to an included file. This will be the easiest way to post ANSI.
  512.  
  513. * MAIN.SUB files configurable by each user, twit filters configurable by
  514.   each user - Maybe. Not a high priority, just something I thought would be
  515.   cool.
  516.  
  517. * More error-checking - It already takes up more of the code than I like,
  518.   but I can't have this thing crashing.
  519.  
  520. * Improved documentation - I hope. This was a RUSH job.
  521.  
  522. * More - I'll let you know as I think of it.
  523.  
  524. *** What you won't see ***
  525.  
  526. * Constant lockups
  527. * Crippling
  528. * Registration nags
  529. * License agreements
  530. * Obnoxious added taglines
  531. * Exclusion by baud rate - I think it's mean.
  532.  
  533.  
  534. :::: MY SAD STORY ::::
  535.  
  536. I've told you already that I programmed this on a dual-floppy CGA 8088. The
  537. fact is, I have no money to upgrade. I also don't have my own board - I'd
  538. like to, but couldn't possibly afford it - and had to do a lot of remote
  539. testing. On a 2400 bps modem, working at 1200 half the time (see below). I
  540. don't have many technical manuals, either, which I could really use, and
  541. only a very limited selection of software.
  542.  
  543. Your donations can help, and if I get a better machine, it will speed up
  544. development of Valence. (You can't imagine how long it takes to recompile
  545. this thing... it's obscene.)
  546.  
  547.  
  548. :::: WHERE TO REACH ME ::::
  549.  
  550. Netmail to WILLIAM MCBRINE at 1:379/301 - preferred method. (THANKS for this
  551. new feature, Frank.) Please note I am NOT the sysop; send it to WILLIAM
  552. MCBRINE!
  553.  
  554. Regular E-mail to WILLIAM MCBRINE on:
  555.  
  556. The Big Byte BBS                   704-279-2295 or 8873
  557. Sysop: Tom Curtis                  1:379/301, 250:101/226
  558.  
  559. Official support site #1. Node 1 is HST, Node 2 is v.32bis. No mailer on
  560. Node 2.
  561.  
  562. (Personally, due to line noise, I can't reliably connect at better than 1200
  563. on Node 2 with my 2400 bps modem. Naturally, as fate or an angry god would
  564. have it, I had to do the majority of my remote testing on Node 2, because
  565. Node 1 and the board below were always busy.)
  566.  
  567. HomeBoy's Digital UnderGround BBS  704-637-2342
  568. Sysop: Daniel Rymer                1:379/306, 250:101/756
  569.  
  570. Official support site #2. 2400 bps only.
  571.  
  572. The Chandrasekhar Limit BBS        704-637-1884
  573. Sysop: Allan Tomkinson             1:379/307
  574.  
  575. Not a Searchlight system, but a board where I can usually be reached.
  576.  
  577. US Mail:
  578.  
  579. William McBrine III  <---- PLEASE include the "III", to distinguish me from
  580. 514 S. Jackson St.         my father!!!
  581. Salisbury, NC 28144-5428
  582.  
  583. Also try the SL_NET echos.
  584.  
  585. Whichever method you use, please spell my name correctly. It's NOT "McBride"
  586. nor "McBrian" nor any other variation; it's "McBrine". M-C-B-R-I-N-E. If you
  587. mispell my name in e-mail, I will probably not receive it. I hate having to
  588. say this, but people mess up my name all the time.
  589.  
  590.  
  591. :::: OTHER THINGS ::::
  592.  
  593. I put more features in this program than I sometimes remember myself. If you
  594. discover any omissions from the documentation (and I KNOW there are some),
  595. please let me know.
  596.  
  597.  
  598. :::: ACKNOWLEDGMENTS ::::
  599.  
  600. Thanks to Tom Curtis and Daniel Rymer for access to their systems, testing,
  601. and encouragement. Thanks also to Tom for many of the files needed to
  602. complete this project.
  603.  
  604. Thanks to Patrick Y. Lee (especially) and Jeffery Foy for their text files
  605. on the QWK format. These were the entire basis for my code, apart from a
  606. little reverse engineering of existing QWK packets. The Foy file is widely
  607. distributed; the Lee file is about three times as long, and at least three
  608. times as useful, if you can find it.
  609.  
  610. Thanks to Scott Dudley (?) for inventing the COMPRESS.CFG format, and my
  611. complements on an elegant design.
  612.  
  613. Special thanks to Richard Bullock, sysop of Collaboration BBS in Los
  614. Angeles, 213-779-3414, for first getting me (finally) using QWK in the first
  615. place, and for many other files needed in this project. Thanks for a great
  616. board, too, even if it is Wildcat. :-)
  617.  
  618.                                    * * *
  619.  
  620.         This program is dedicated to Madonna, my divine inspiration
  621.           and to the memories of Isaac Asimov and Melena Weinhold
  622.