home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / OFFLINE / VALEN130.ZIP / SYSOP.DOC < prev    next >
Text File  |  1993-08-17  |  31KB  |  653 lines

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