Beijing Paradise BBS Backup

home *** CD-ROM | disk | FTP | other *** search

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / XBBS_118.ZIP / DOCS.ZIP / XBBS_118.DOC < prev

Wrap

Text File | 1992-04-04 | 68.9 KB | 1,515 lines

╔══╗╔══╗╔═════╗╔═════╗╔════╗ ╓──╖ ╓──╖ ╓────╖ ║ ║║ ║║ ┌┐ ║║ ┌┐ ║║ ║ ║ ║ ║ ║ ║ ┌┐ ║ ║ ╚╝ ║║ └┘ ║║ └┘ ║║ ╔═╝ ╙╖ ║ ╙╖ ║ ║ └┘ ║ ╚╗ ╔╝║ ╔╝║ ╔╝║ ╚═╗ ║ ║ ║ ║ ╙╖ ╓╜ ╔╝ ╚╗║ ┌┐ ╚╗║ ┌┐ ╚╗╚═╗ ║ ║ ║ ║ ║ ╓─╜ ╙─╖ ║ ╔╗ ║║ ││ ║║ ││ ║╔═╝ ║ ║ ║ ║ ║ ║ ┌──┐ ║ ║ ║║ ║║ └┘ ║║ └┘ ║║ ║ ╓╜ ╙╖╓╖╓╜ ╙╖║ └──┘ ║ ╚══╝╚══╝╚═════╝╚═════╝╚════╝ ╙───╜╙╜╙───╜╙──────╜ Documentation for -=-= XBBS =-=- v1.18 Copyright (c) 1989/90/91/92 by M. Kimes -- All Rights Reserved * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Introduction: ------------ "Hey...you wanna see somethin' _really_ scary?" XBBS was first published in early 1985 as a BBS program for Commodore 128s. Since then, it's grown into a series of MS-DOS QuickBASIC and C doors and finally into an MS-DOS C BBS. It's in the process of being completely rewritten as an integrated mailer/BBS for OS/2. It is not affilliated with a similarly named ?nix product that came out in about 1987 or 1988. Thus endeth the history lesson. --Features: o Users can select between two standard interfaces in a non-customized (or barely customized) XBBS. Standard interfaces take full advantage of ANSI graphics (including pulldown menus in one interface). o XBBS features a QuickBBS-like menu definition language or a much more powerful psuedo-programming language for full customization. The .XBS language can actually perform tasks that require special Doors on other BBS systems. o XBBS has a built-in text file library that allows users to browse through a directory of text files. o XBBS handles news in an intelligent manner. "New news" is located for the user at logon. Old news may be browsed as in a library. o XBBS handles Fidonet messaging by design. Message text can be stored compressed for extra disk space savings. Message files are in a public domain two-files-per-area format with plenty of utilities. Messages can be exported in three formats (and imported from two formats with provided import program). o XBBS can run Doors in an almost seamless fashion. DORINFO?.DEF (both RBBS and QuickBBS styles), full DOOR.SYS and USERINFO.XBS exit files are created, as well as an XBBS-specific exit file. o "Plug-and-play" interface for editors and protocols allows you to use whatever support software you like. o Full source code is available for customization. A developer's kit and Door-writing library are available. o No charge for non-commercial use (see License below for full details). --Hardware/Software Requirements: To run XBBS, you'll need an IBM or close compatible with a minimum of 256K of RAM (more recommended) and a hard drive (if you want to do much). You'll also need a modem and phone line, and if you didn't know that, you'd better delete the archive and go back to playing games... XBBS requires a FOSSIL driver, probably available where you got this archive. Three that are in wide use are X00, Opus!Comm and BNU. Different FOSSILs work differently on different machines; experiment until you find the combination right for you. A video fossil is not required or supported (though it won't hurt if you have one loaded). Your CONFIG.SYS file should contain statements similar to these: Files = 25 Buffers = 15 (add /X if you have a 286 or better) These are recommended minimums. You could probably slide by with less, but why be such a tightwad? XBBS doesn't answer the phone; you'll need a front end, or mailer, like BinkleyTerm or FrontDoor, to get started. XBBS is geared more toward BinkleyTerm than FrontDoor because the author uses (and loves) Bink (used to; switch to OS/2 and went insane), and because BinkleyTerm concerns itself with transport layer and not application layer, whereas FrontDoor wants to meddle in your BBS files. XBBS has no built-in protocols. All upload/download protocols are external. The most useful is probably DSZ, which should be available where you got this archive. Register it. I understand there is also a PD package similar to DSZ called PCZ, but I have no experience with it. The reasons for this are simple: 1. Everyone wants the latest version of <name a protocol> (witness the DSZ of the week club). 2. It frees me from having to update my version to match the latest version of <name a protocol>. 3. It means there's only one interface to worry about for protocols. No sysop/user confusion over internal vs. external. XBBS has no built-in text editors. It supports a line editor, full-screen editor, local (text editor) editor, and ANSImation editor, but all must be external. I recommend LineEd, QuickEd, QEdit and ANSIEd respectively, though others may work fine for you and I won't discontinue your non-warranty if you use something else. Again, experiment and use what suits you best. Change whenever the mood strikes you. Isn't flexibility great? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Could you say that again, in English?" --Disclaimer XBBS is guaranteed to do nothing more than take up space on your disk drive until it doesn't. We hope that it does more, but don't guarantee it. XBBS is _free_ and isn't necessarily worth more than you paid for it. Under _no_ circumstances will the author be responsible for damages incurred from the use, misuse, abuse, overuse or failure to use XBBS. Or for anything else. You're on your own, goodnight... --License XBBS is free software. Donations are accepted but not solicited. All rights to this software, however, remain with the author, M. Kimes. I do request that anyone who decides to run the software (as opposed to "just trying it out") drop me a line letting me know (just want to get an idea how many and where). >>>>[][][]The EXCEPTIONS to the "free" rule are:[][][]<<<< 1. The use of XBBS as a "pay-for" BBS. If you charge your users for access (or "full" access), you must register XBBS after a 30 day trial period for $25.00 or discontinue its use. If they gotta pay, you gotta pay, and it serves you right. 2. The use of XBBS in commercial environments. Use on more than three lines or for advertising, selling, etc. is generally considered commercial. Contact the author for terms. 3. The use of XBBS by government organizations. Contact the author for terms. 4. The use of XBBS by religious organizations (actually falls under "commercial environments", and maybe #5 below). Contact the author for ludicrously expensive terms. 5. The use of XBBS for illegal or immoral (your morals; I ain't got none) purposes. Contact the police for punishment or your priest for penance. Do not pass Go. XBBS may be freely distributed so long as the contents of the archive(s) are not altered in any way (this does not include repacking with a different archiver, though I don't much like it, but does include removing from, adding to or changing the files in the archive). Do *not* put comments in the archive header. If I'd wanted comments in the damn header I would have put them there. You may not charge anything for distributing XBBS, including disk fees and time charges. *If you can't handle it, don't distribute it.* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Statement of preferred policy (this is not legal stuff, just the author's personal preference regarding the direction of XBBS): I would greatly prefer to see all programs which work with XBBS remain free-for-the-asking or at least fully functional shareware (this does not necessarily mean public domain, and it does not mean source must be available (although source would be nice :-)). My main concern is that there *never* be a product *required* by XBBS that is available *only* as a commercial product. There should always be a free or fully functional shareware option. This is a hobby, right? Are we having fun yet? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Meatloaf AGAIN?!?" Upgrading: --------- Skip this if you're installing (or thinking about installing) XBBS for the first time. Anytime you upgrade XBBS, follow these simple rules to avoid heartache: 1. ALWAYS run XConfig again and go through each screen. I don't usually bother to write config file converters. You might want to first jot down the # of calls to your system and the next user id #, along with any other info you forget easily, from your old config with the old XConfig. 2. Check XBBS.TXT for added prompts. Be prepared to have to move some of your help prompts if you use them (this sucker just keeps growing...). 3. Check the archive for anything named CONVERT*.EXE. Run it if you find it for instructions. As an example, there was a user file converter included with one upgrade. 4. Run XEdit and see if there are any new fields you might want to take advantage of. 5. Sometimes added (new) commands don't work just right. They probably weren't used by anyone else to get the bugs out (there are so many commands it's hard to actually strenuously use them all). Consider them lagniappe; you were getting by with just the old stuff, remember? 6. At least skim through COMMANDS.DOC and SPECFILE.DOC. You should probably check the help screens on the utilities to see if they have new uses you can take advantage of. Also look for new utilities. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "There are seven working defenses from this position." First-time Installation: ----------------------- Unpack the archive in a scratch directory (only the "top layer," not all subarchives). Run the INSTALL program. Answer a few questions, follow directions, fill in the blanks, make the decisions. USE THE F1 (Help) KEY. Reboot so your new Path takes effect. Link to your mailer. Simple (at least, as simple as it gets in this hobby). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "220, 221, whatever it takes." Utilities: --------- Overview: -------- XConfig is your configuration editor. It creates the files CONFIG.BBS and NEWUSER.BBS. CONFIG.BBS contains information about things like what your directory structure looks like, what your Fidonet address is, how you want some things in XBBS to look. NEWUSER.BBS contains information used by the login routine; which questions to ask, what level to start a new user at, and so forth. XEdit edits some of the various control files that XBBS can use. A message area look-up file, file area look-up file, and the external protocol control file are included in these. XUser edits your user file. You can even edit the current (online) user with it (if you need to do in-depth editting; minor editting is available in the BBS itself). All the above can be installed on ALT-# keys (keys which can cause an external program to be invoked while the BBS is active). In this way, XBBS serves as a BBS manager, creating a homogenous environment with which you can design your own uniquely tailored BBS. XMsg is the message base maintenance program. It's probably best to run it once in a while in a scheduled event from your mailer, late at night. It packs out deleted messages and maintains areas at set maximums or by date, among other things. Indexer should be run anytime you edit the XBBS.TXT prompt file (XBBS.TXT contains most of the 'standard' text that XBBS spits out, allowing you to totally customize or convert to foreign languages). XBBS will try to remember if you forget. XST is the XBBS Scanner Tosser for Fidonet net/echomail. It is written by Wayne Michaels. XST is in a separate archive! It is freely available to non-commercial systems (read its license). Another scanner/ tosser, XGroup, is also available. There are frequent threats from other people about others becoming available. The above are the only 'required' utilities. All the others are just to make things easier for you, or to let you do things that might be difficult or even impossible otherwise. I have included most of the other utilities in the main archive because, frankly, if you're planning on running XBBS you must be a power sysop and will probably have need of some of the things these utilities can do for you. XBBS uses a version 6 nodelist. It can use a FIDOUSER.LST (must be indexed with INDEXUSR). In Detail: --------- --XConfig Most of the features in XConfig are self explanatory; just hit the F1 key for help. If you've got a mouse, load the rodent's driver. The feature "Run ANSI through BIOS" is an option for people running Fansi, or some other ANSI replacement that traps BIOS routines for ANSI output. If you are using Fansi and want this option, you must specify /M=1 in the Fansi command line in Config.Sys. XConfig should be run in the directory which will be XBBS' "home", with XConfig.HLP in the same directory or on your DOS path. It creates two files, CONFIG.BBS and NEWUSER.BBS. These are your standard and logon configuration files, respectively. You can rerun XConfig to make changes anytime you want (even while someone is online, _if_ XBBS is temporarily removed from memory, as when another program is Exec'ed). For multi-node use you'll need to create CONFIG?.BBS by copying CONFIG.BBS's...a point only for the advanced. XConfig can also be run with the argument IN or OUT to change the SysOp's status (intended for use from a batch file in conjunction with mailer events). You *have* to run this at least once to set up your initial configuration file. If you used the auto-install program, it should have run it for you. --XMsg XMsg is the program that maintains the XBBS message areas. It must be run in the BBS' "home" directory, as it reads CONFIG.BBS to find out where the message bases are, and needs to update the last message read pointers in LASTREAD.BBS. It is recommended that you run XMsg nightly to compact your message bases, removing deleted messages and other special functions you may want to invoke. It's not good practice to run XMsg while anyone is online, as it'll probably mess up the last message read pointers. Source code is included. See CLEAN.BAT in the distribution archive for examples. XMsg is rather spartan at this time; if you're a programmer, you might consider contributing to the cause and beefing it up. For those who are mildly interested, XBBS keeps its message bases in two files per area: XDATA.### and XTEXT.###. XDATA is a random file containing FidoNet-like headers. XTEXT is a binary file containing the actual message text. If a file gets hopelessly corrupted, the worst you can do is lose one area. However, you do not have thousands of individual *.MSG files lying around everywhere. Details of the structures can be found in MSG.H in the XDevelop archive. Usage: XMsg -A<action filename> XMsg -P [LoBd#] [HiBd#] (options) Packs out deleted messages XMsg -T [LoBd#] [HiBd#] [#mess] (options) Trim to specified # XMsg -D [LoBd#] [HiBd#] [#days] (options) Delete older than # days XMsg -R [LoBd#] [HiBd#] (PRIVATE) (options) Deletes received messages XMsg -K [LoBd#] [HiBd#] (options) Kills Junk msgs by (options) (XMsg operations take place on all boards between [LoBd#] and [HiBd#]) Options (separated by a space if more than one is used): B (delete backups after packing is complete) V (verify deleted messages present before packing) D (don't pack this pass--valid for -T, -K and -D commands only) M<message path> (Path to msg bases) N<#LMRs> (Number of Last Message Read pointers kept in LASTREAD.BBS) F<fromname> (From string for killing junk) T<toname> (To string for killing junk) S<subject> (Subject string for killing junk) P (check for Subject string anywhere in msg subject) A (if any kill junk criteron matches, kill it) C<#bytes> (compress message >#bytes while packing; default 1K) U<#bytes> (uncompress messages while packing) XMsg is sensitive to the order of its arguments. An XMsg action file will be used if the -A argument is passed. This action file would contain lines of commands. See sample XMSG.CTL in samples in doc archive. BTW, the Kill junk option in XMSG (and XHMS and HeadEdit) doesn't necessarily mean I support censorship. Remember, this is a hobby. If someone keeps spouting crap in echoes, don't put up with it. Delete the messages before you read them. This will keep your temperament on an even keel and your bloodpressure down, and keep the hobby fun. I mean, it's not like there's not plenty of stuff to read anyway, right? Just remember *not* to delete messages before passing them up/downstream (XMsg won't do that, anyway). How often do you run XMSG? That depends on your tastes and available disk space. Once a night, once a week, once a month, whatever it takes. --XScan First off, XST or XGroup are strongly advised over this kludge. XScan is used to import/export messages from/to your XBBS message areas from/as *.MSG files for use with things like GroupMail and UFGate that can only work with *.MSG files. This is a "kludge". XST should normally be used for net/echo mail processing. XScan is application-layer-to-application-layer (X*.### to *.MSG), whereas XST is application-layer-to-transport-layer (X*.### to *.PKT (*.OUT)). XScan requires either an -Import or -Export (or both) on the command line to function (there are other options--type XSCAN with no arguments for a list). It also requires a configuration file in the following format: First line: Path_to_XBBS_message_areas Subsequent lines: Area# Directory Area_Tag When XScan runs, it imports all *.MSG files from 2.MSG upwards into your XBBS message bases, then exports any messages waiting to go out as *.MSG files. You should immediately process the *.MSG files left after an export and then delete all *.MSG files in the directories, or they will be imported on the next run (not to mention wasting space). There is a special Area_Tag *NETMAIL* which can be used to import/export a netmail board (high water marks are not skipped/deleted in that case). XScan can fill in incomplete (read "brain-damaged type 2") message headers from kludge lines, and does so as the default. This means XBBS will display the Zone and Point information correctly without having to read the message first, and makes processing a little faster when reading. XScan always "treats" messages as it imports them (removes soft CR's and linefeeds, which are useless junk some brain-dead software pollutes the net with). When would you use XScan. I'd recommend you don't unless you *know* that you need to use it. --XUser XUser is your user editor. Again, it must be run in the "home" directory. XUser lets you change most of a user's parameters. In addition, it has some special command line arguments that cause it to act in different ways (type XUser ? at the DOS prompt for a quick reminder). XUser DOS will invoke XUser writing through stdout for remote usage with CTTY or GateWay. XUser PACK will invoke XUser to pack out deleted users (intended for use from a batch file). XUser DAYS # will pack out users who haven't called for # days (also intended for use in a batch file). To invoke XUser in its standard local mode, just type XUser. Source code is included so you can see how to manipulate the user files. Take a look at CLEAN.BAT again for example of batch file usage. You can play one fancy trick with XUser. First, install it as an Exec from an ALT-# key. Then, use that key while a user whose parameters you want to modify is online. Press F6 to edit the online user (his parameters in ONLINE.XBS). When you return to XBBS, it will reload the user's parameters from ONLINE.XBS, and the changes will become permanent. This allows you to modify things you normally couldn't from XBBS while a user is online. The F6 key is _only useful when a user is online and you are _out_ of XBBS_ as it writes directly to ONLINE.XBS in that case, instead of the USERS.BBS. There's a second page for each user; hit ? while at the Command: prompt to get more info. Note that the "User id: <8-digit hex #>.<3-digit #>" is a filename you can use to "force" messages to be read to a user at logon. Just create a directory called FORCE off of your BBS' home directory and edit a file by the appropriate filename. It'll be deleted after the user finishes reading it. There's at least one third-party user editor out called XUE if you detest XUser (which is rather spartan). --HeadEdit HeadEdit is a local message reader that uses windows and other fancy gimmicks. It's highly recommended that all XBBS sysops get and use a copy. Load that rodent driver... Note that HeadEdit is for sysop-use only (or for a point). Don't try to use it or allow its use as an offline >user< reader! Use XHMS for that. HeadEdit allows total control over your message areas; XHMS has built-in limitations so users can't do things they're not supposed to be doing. IT IS STRONGLY RECOMMENDED THAT YOU GET AND USE HEADEDIT. Without it, as a sysop, you're crippled. Besides, it's slick. Also available in an OS/2 version. --XPort XPort is a small program that eXPorts a message as a text file. Type XPort with no arguments for a list of what you need to tell it. Note that XPort will not overwrite an existing file. XPort is intended to be used from within XBBS as a spawned program, but can be used from the command line. Since XPort can create a *.MSG file from the message exported, you can utilize existing analysis utilities based on that old, slow format. Source code is included so you can see how to manipulate the message bases. There's another program (in source only) in the archive called XMove. I've had no chance to test it, but some intrepid programmer out there might want to compile, check and fix it up for general use. Usage: XPort <directory\> <base#> <msg#> <filename> <net> <width> <MSG> What use does this have? I have no real idea. HeadEdit is much easier to use. --XProto NOTE: It's advised that you use XEdit instead of XProto, but some advanced automation routines might find XProto useful. Remember we said that XBBS has no built-in protocols? XProto is the utility that will convert a text file into a PROTOCOL.CTL file, which XBBS uses to figure out what external protocols you have available, and how to call them. Take a look at Protocol.TXT in the archive; this is the raw text file that was used to create the enclosed Protocol.CTL file, also in the archive. Modify Protocol.TXT to your liking and run XProto on it (XProto Protocol.TXT). Save a copy of the raw text files to facilitate making changes later. Protocol.CTL is not easily human-editable. The included files support DSZ, MultiLink, CLINK (SeaLink), Super8K, JModem, and others. Source code for XProto is included for whatever use you can make of it. Here's a typical entry in PROTOCOL.TXT with comments. Don't include the comments: ZModem ;Protocol label Z ;Key to select protocol 85 ;Protocol efficiency C:\XBBS\DSZ.COM port *p restrict D sz *F ;Download string C:\XBBS\DSZ.COM port *p D rz -y *F ;Upload string type a dozen CTRL-X's ;Abort string Y ;Wildcards? (Y or N) Y ;Multiple filenames N ;Simultaneous u/d (not used) Y ;Will use a "list" file Y ;Filename(s) sent by remote* Y ;Uses DSZLOG* N ;Always N (future) N ;Always N (future) The two items marked with an asterick (Uses DSZLOG and Filename(s) sent by remote) are implemented but not thoroughly debugged; use with care and discontinue if you run into problems. NOTE!: When using DSZLOG, the DSZLOG environment variable must be set *and* the string "DSZLOG" _must_ appear in the filename (i.e. SET DSZLOG=C:\XBBS\DSZLOG.LOG). In the above Download and Upload strings, *F gets replaced with the name(s) of the file(s) to be uploaded/downloaded (or the name of the filelist if "will use 'list' file" is on). Again, it is recommended that you use XEdit instead of XProto. It's a hell of a lot easier for most applications. Usage: XProto <file-to-convert> Why would you want to use this instead of XEdit? The heck if I know. --XEdit An easier way to handle PROTOCOL.CTL is to use XEdit. It can edit MSGAREAS.XBS, FLSEARCH.CTL, PROTOCOL.CTL and PEEKER.CTL files in an easy fashion (local use only). It can even make message area and file area menus for you to customize (okay, if you're still here, you deserve a little encouragement; but don't let it go to your head). Source is available in the XEDIT.LZH archive. Don't forget you can put XEdit.HLP anywhere on your DOS Path, and XEdit can find it. Note that PEEKER.CTL is a file used by my Peeker program, an archive viewer/disassembler. It isn't required by XBBS itself, so don't bother making one unless you're running Peeker as a Door (think about it; it's far superior to XBBS' built-in archive viewing). How do you run it? Just type XEDIT. You can edit the first four lines to change the defaults XEDIT uses for message and file area control file names and the message path, using any text editor suitable for writing batch files. --XLog XLog will read USERS.BBS and create the appropriate files for "instant logon". Normally this would be for the local sysop to bypass the standard login procedure, but there are other uses. Run from the default directory without arguments, XLog creates the files for user #1 at 0 baud (local), and displays the arguments it will accept for other uses. Note that if you pass a user name to XLog instead of a user number, you must separate the first and last names with an underline instead of a space. XLog will then search the user file for user name (it'll put the space back in) and exit with 254 (serious error or locked-out user), 253 (couldn't find the user), or 0 (user found, files created, ready to run XBBS). Source code is included so you can see how a user logs on, how exit files are created, etc. Judicious use of XLog and Logon can allow you to run XBBS as a door from another BBS with a minimum of user logon time. Usage: XLOG <user#/user_name> <baud> <timetoevent> <other args> What's it good for? A lot of things, but probably the most common usage is to log the sysop on without having to go through the login procedure: :Localon XLOG LOGON0 -R ... --MessChek This program is invoked each time a message is entered (if it can be found in the default directory...leave it out if you don't want to use it). It should check the message for whatever criterion you like (I have mine check for ALL CAPS messages) and return either errorlevel 0 (no errorlevel) or errorlevel 3 (failed message check). Messages which fail the check are dumped. I have included the source for the caps-checking program. Write your own in any language and incorporate it in your system. You could use this hook for other purposes, too, like an online spelling checker. Use your imagination. Note that this program is *not* required. --Indexer This little program just indexes the prompt file(s) XBBS.TXT (and XBBS.GXT for ANSI users, if you use it; not really necessary). XBBS.TXT is a file of text prompts separated by ASCII 1's (CTRL-a's). Lines in the prompt file serve various purposes. Lines which do not contain a special leading character (a control character from 1-17) are simply displayed (they run through the metastring translator first). Here are how the special leading characters in XBBS.TXT affect the lines (note that XLate refers to whether or not metastring translation takes place, and Used refers to whether or not the leading character is retained in the output string): ASCII value Affect XLate Used =========== ======================================= ======= ==== 2 Used internally; be very careful! no no 3 Sent to log file yes no 4 Printed local only yes yes 5 Use for ANSI users only yes no 6 Use for ASCII users only yes no 11 Gosub to this file yes no 14 Paged-read this file yes no 15 Send this text to DOS (shell) yes no 16 Used internally; be very careful! yes no 17 Pause until return hit (line ignored) n/a n/a 18 Load a topic file (not reentrable!) yes no 19 Clear screen (line ignored) n/a n/a 20 Use only if expert flag not on yes no 21 Use only if twit flag is on yes no 22 Use only if special flag is on yes no 23 Read named help from file,topic no n/a 24 Read .MNU menu file no n/a 25 Right-justify line yes no 28 Center line yes no 29 Convert metas, continue yes no 30 Use for FANSImenu users cond. no 31 Use for non-FANSImenu users cond. no Indexer must be used to reindex this file after you have made customizing changes, which you are encouraged to do. Be very careful with lines containing things like %s, %u, %lu, etc...you might want to leave them alone. They are used as format strings for C functions; even changing the length of these can produce a crash. If you've got a good knowledge of C, you'll know what to do... When should you run Indexer? Anytime you change your XBBS.TXT file (the file that contains almost all the "standard" prompt text XBBS uses). If you forget XBBS will try to remember for you, but it'll detract from the current user's time, as he'll have to wait while it runs. You might want to make a batch file for editting XBBS.TXT that first calls your editor, then runs Indexer, so you don't forget. It's pretty quick, so there should be no real hardship. --XGateKpr This is the GateKeeper for XHMS, the offline reader for users. XBBS will pack up netnode.MAL for the user in .\XPORT and receive netnode.RPK in .\MPORT. XGateKpr should be run when a file is detected in .\MPORT after a user gets offline from the XBBS directory. It gets the user's number from CONFIG.BBS and merges the replies into the BBS message bases. Source is included. If you'd like to write an offline reader for XBBS, feel free to use this source as a guideline (or steal it _if_ your reader is free). Obviously, if you aren't allowing export of mail packets, you don't need XGateKpr. (XGateKpr contains the stub for QWK REP importing if some programmer wants to take the blame for adding it). When do you run XGateKpr? You don't, unless you're allowing messages to be sent by XHMS or a point to XBBS. If you are, something like: :CheckIm if exist C:\XBBS\MPORT\*.* goto Import ... :Import XGATEKPR --XBASIC XBASIC is a sorta-BASIC interpreter that understands XBBS file structures. With it you can change things that even XBBS won't let you change. It can also handle ISAM database files. I'd recommend this as an addition to any *serious* XBBS sysop. (Note: as of 3/21/92 this hasn't been updated from 1.17 to 1.18) --Log Log makes entries to a logfile that match the way XBBS makes them. Just call LOG <Filename> Text to go to logfile and Log makes the entry, including the time and date. Why use it? Well, you don't have to, but it'll make your log look a little neater if you write to it from batch files. --A word about online text editors Editors should return errorlevel 1 for abort, errorlevel 2 for idle timeout, or no errorlevel if everything is fine. This is in line with the way QuickBBS interprets returns from its editors, which means you should be able to use QuickBBS-compatible editors with XBBS (and vice-versa). Note that *all* editors are external in XBBS, even the line editor. This lets you change editors as new and better ones become available, or just to suit your changing fancy. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Demons to some, angels to others..." The Guts: -------- XBBS comes in two flavors, Logon0, and Logon. Logon0 is for 808x machines; Logon is for 80x86 machines. They are functionally equivalent, but the 80x86 version is marginally smaller and faster. Logon and Logon0 (I'll just refer to Logon from here on out, but comments apply to both versions) are overlayed. As with all overlayed programs, installation on a RAM disk or use of a good disk cache is recommended for speed since the program loads pieces of itself while running. Also, since the overlay manager is pretty dumb, you can't rename the program unless you use a sector editor (PCTools, Debug, DE, etc.) to change the filename embedded in the program itself. Logon must be in the current directory or on the DOS Path to be able to find itself. I'd suggest putting it on the Path in case you switch directories accidentally. BTW, I keep a non-overlayed version floating around here available for file request if you have extreme problems (LOGON0NO.LZH). It requires considerably more memory to run, but that won't matter if you're not trying to multitask DOS (an unnatural act, anyway), and you'll see a speed increase. --Arguments for Logon: Initial arguments to Logon have no preceding identifiers. They must be given in the following order: Baudrate (0=local, default) Time_to_event (in minutes, no event default) Node_Number (1 default, see -N# below) Multitasker (see -M# below) (Any other arguments are copied into variables 0-9) You should ALWAYS run Logon first with these parameters! This is where your user logs onto the BBS, and where the file ONLINE.XBS is created, which Logon uses to tell who's online and what their stats/ preferences/ security clearance is. The only exception would be if you are doing something fancy with XLOG--it's up to you to figure that out if you feel the urge. If you rerun Logon with a -R argument, Logon assumes that there is already a user online and that a valid ONLINE.XBS exists (it will be very peeved if one doesn't). You can also pass a -N argument if you are using -R, where a number follows the -N to indicate the node number. To recap, when Logon is run with a -R argument, it behaves as if a user is already online: -R<start_menu> Logon starts up with a text file called START.XBS. If you use the -R argument without <start_menu>, Logon uses MAIN.XBS as the starting file. If you use -R<start_menu>, Logon will start up with <start_menu> as the starting menu file. -N# Logon will assume node number # if started with this argument. Node #1 is the default. -M# Multitasker set to # (0 = none, DesqView = 1, DoubleDos = 2, MOS = 3, TV = 4, OS/2 = 5). Overrides autodetection. You probably don't need to worry about this. -W Wait for a call. This hasn't been tested and probably doesn't work right. Any arguments beyond these initial arguments are copied into the XBBS variables starting with variable 0 and proceeding to variable 9, which allows your batch file to communicate with the "XBS" language (see COMMANDS.DOC if you're feeling brave). Please note that although XBBS allows entry of a node number, there's no guarantee at this time that multiple nodes will get along well. That's because I didn't multitask when I ran DOS (it's an unnatural act). Use multiple nodes at your own risk (but let me know if you encounter bugs; I'll try to fix them). With swapping turned on, you can easily run XBBS in a 256K or smaller partition (depending on your Doors, of course). XBBS does use SHARE-compatible file i/o and locks message areas appropriately when writing to them. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Running XBBS from a batch file: ------------------------------ -----------> Sample part of simple RUNBBS.BAT <----------- REM The front end must determine baud rate so you can use it to jump REM to the appropriate label in the batch file (in this application) REM If 2400 baud, the batch file would begin at the label 2400Baud, REM if 0 baud begin at label Local, etc. :2400Baud REM Switch to BBS directory CD\XBBS REM Invoke Logon at 2400 baud, no event scheduled, node #1 LOGON.EXE 2400 REM After logon, go to the errorlevel test goto AfterX :1200Baud CD\XBBS LOGON.EXE 1200 goto AfterX :300Baud cd\XBBS LOGON.EXE 300 goto AfterX :Local cd\XBBS LOGON.EXE 0 REM or REM XLOG REM LOGON -R goto AfterX :AfterX REM Trap errorlevels 253 and higher; end program IF ERRORLEVEL 253 GOTO Start REM If errorlevel was 80 that might be your cue to run a Door REM You could have several traps here... if ERRORLEVEL 80 goto RunaDoor :Restart_X REM Restart XBBS at menu/file YOUBACK.XBS Logon.EXE -RYOUBACK.XBS REM Reloop to test after exit in case a door was Exec'd or is being REM exitted to with a specific errorlevel GOTO AfterX -----------> End Sample <---------- (There are more samples in the distribution archive) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Aw, Andy..." Ijit-mode Ijit-mode is how I affectionately refer to the interface that comes up on a non-customized XBBS when it starts. It's wild, it's wonderful, it's colorful, it's strange, it's simple to use. XBBS uses it anytime it can't find a MAIN.XBS or MAIN.MNU in the menu directory (usually MENU off the main XBBS directory). You can customize Ijit-mode quite a bit. XBBS.TXT prompt #453 contains the characters used as command keys. You can edit that prompt line to change the keys that invoke functions. Prompts #448 and 454 may also be of interest for cosmetic changes. Don't forget that a prompt can tell XBBS to read a menu file... Before executing several of the built-in commands, XBBS will attempt to read a menu file that you can create; this is a way of superceding the built-in commands. For instance (using the default XBBS.TXT prompt #458 in this discussion), if you make a file called MSGS.XBS in the menu path, XBBS will read it if the user presses [M] instead of invoking Bulls-mode (the default action). [F] looks for FILES.XBS instead of invoking Files-mode, [D] for DOORS.XBS instead of invoking Door-mode, [C] for CONFIGUR.XBS, [L] for LIBRARY.XBS, [N] for NEWS.XBS, [!] for MACROS.XBS and [Q] for XLOGOFF.XBS. (Quick note: XEdit can create nasty FILES.XBS and MSGS.XBS for you to customize) Other quick customizing you can do might involve goto/gosub files. These are files that XBBS can be told to read when certain keypresses are detected (most anywhere!). XConfig lets you setup up to ten of each. Let your users know about them in a news file. More advanced tricks are easily available. Add commands to the end of XBBS.TXT prompt #458. Then make an IJIT###.XBS file that will be read if that key is pressed. For example: @00448: Msgs Files Doors Config Users Library News !Macros Setup Areas Yell for Sysop Other Interface Quit (LOGOFF) Help! Page Sysop @00449: If [P] is pressed, IJIT010.XBS will be read. It might contain the following ".XBS program": Yo, Sysop!...<^G>@; @P1@; .<^G>@; @P1@; .<^G>@; @P1@; .<^G>@; @P1@; .<^G>@; Guess he didn't hear you. @P1 You could then press ALT-C to chat if the whim took you. (Note that this silly example more-or-less duplicates the function of the built-in Yell command) Now suppose you wanted to usurp the Library command to call the XBBS Library Door instead of the default internal library. XBBS will first attempt to read a file named LIBRARY.XBS in the menu path before executing its internal routine (see SPECFILE.DOC for a list of these "alternate" files). So you could put this in LIBRARY.XBS (it should be all on one line): @ESLibrary.EXE Dc:\xbbs\library G*G B*B T*T L*l W*w EREAD NC:\XBBS\LIBRARY\ENTRY.TXT That would invoke the Library Door for you. Since the file was successfully read, XBBS won't bother with its internal Library function. See COMMANDS.DOC for a complete list of ".XBS language" commands. You'll also find a basic .XBS menu writing course later in this doc file if you're interested and sufficiently masochistic. Some of the prompts you might want to take a look at in XBBS.TXT: 83: Files-mode commands 206: Macro-mode commands 267: After-page command letters for paged text reading 268: After-page command letters for FILES.BBS listing 293: Paging message 294-298: After-message messages 340: After-page message for FILES.BBS listing 400-401: Programmable status lines 402-411: "Spawn" key commands (ALT-0 - ALT-9) 434: After-message command letters 435: After-write command letters 437: After-page message for paged text reading 446: Name of default FLSEARCH.CTL-style file 448: Xijit-mode 1 commands 456: Configuration commands 477: Scan page message 486: Default MSGAREAS.XBS-style file 487: Minimum free drive space to allow uploading 493: Default DOORLIST.XBS-style file 574: Library-mode commands 582: Bulls-mode commands 610: Internationalization letters -- Stop, Pause, Yes, No, etc. 624: Scan page command letters 641: Default News-mode directory 642: News-mode commands 680-701: Xijit-mode 2 commands There are a lot of others you may find interesting; shop around in the XBBS.TXT file with a good text editor. You'll find you can customize just about everything by careful editting. Note that it's not required that you customize or write your own interface. If you're happy with Ijit-mode, don't worry about it. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "I believe the law of conservation of momentum is very important...don't you?" Special Local Keys: ------------------ XBBS has several special local-only keys. ALT +: Add to user's time ALT -: Subtract from user's time CTRL-End: Toggle status line CTRL-Home: Display a list of local keys (XBBS.TXT prompt #345) ALT-B: Bail out (end XBBS, don't update files) (XBBS.TXT prompt #2) ALT-C: Enter and exit cheap chat mode (XBBS.TXT prompts #190-191) ALT-G: Ring a bell on the remote's system ALT-J: Jump to DOS (XBBS.TXT prompts #3-5) ALT-O: Pop-up options window ALT-U: Pop-up user editor CTRL-ALT-DEL: For those really sticky situations BRS: When CAD just won't do. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * We will now begin to get technical. This continues in COMMANDS.DOC and SPECFILE.DOC. Skip it if you don't care, until you do care. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Beat 'em or burn 'em; they go up pretty easy." --Security It's a fact of SysOp's lives...just as soon as you finish a great BBS system, some jerk will come along and try to crash it. There's no way to make a BBS truly crash-proof (other than disconnecting the modem), but there are some common sense things you can do (or not do) to make things as secure as possible. First, _never_ allow an upload from anyone other than yourself to enter the menu or BBS directories. The reasons for this should be obvious; suppose someone uploaded a menu file and the BBS read it...XBBS will do almost anything with those embedded commands, like drop them to DOS with remote control, format your hard drive, or write a confession letter on the printer to your wife. Not the sort of thing you want to have happen. So play it safe and don't give anyone access to those areas. XBBS will decline uploads of files with names beginning with "FILES." or ending with ".BBS" or ".GBS". FILES.BBS couldn't hurt you (and FILES.GBS would be ignored), but it might allow a hacker to insult your users with "your name," so to speak, and any attempt to upload a matching file will log the user off, increase his violation count (like dropping carrier would), and leave you a note in the file. I suggest you watch anyone who tries that like a hawk. Never let XBBS read a file uploaded by a user unless you disable embedded commands first, or use the paged reading method. Check any user-submitted files thoroughly before allowing reading with the interpreter, probably doing a search for ^A and eliminating any you find. If you find any ^A sequences that just happen to be XBBS embedded command sequences, it's probably not a coincidence, and the user will bear careful watching. Put a double password on your account if it's called remotely (just check for your name, check for a baudrate > 0, and then ask for a second password). If someone was visiting and sneaked a peek at your primary password (the one Logon requests), the second password (via embedded commands) will stop them. Remember to add a note to the logfile and hang up on them when they fail the test, then change both passwords (and probably lock the user out if you know who it was). If you allow users to utilize offline readers to enter messages at home and upload them (or even if you don't), check your message areas now and then for abuse, PARTICULARLY Matrix areas. There's only one way to really prevent someone from entering abusive messages; don't give them access to the message areas. Use your judgement, but don't get kicked out of the net because you were too lenient with someone who has demonstrated that they were not going to abide by your rules. Above all else, use your common sense. If you have extra, send me some. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "With great power comes great responsibility." --Hints and Tips Because of the way the menus are set up, and with the commands provided, you can simulate almost anything, and have endless unique features that aren't in the BBS. Doors are a breeze to implement with XBBS...it's a "door machine." Study the included sample menus to see how they do what they do. Modify and use them. Get into the XBBS Echo and ask questions (but at least try it yourself first). Study the docs; often the answers to your questions are buried in there somewhere. The docs are fairly technical, but then, XBBS is intended for the advanced sysop. If you'd like something to help get you started, take a look at the menu MAIN2.XBS in MENU.LZH inside XDOC_*.LZH. Nothing will replace reading the docs and experimenting, though... If you have XBBS doing something really weird and want it to "reset" itself, remember that you can Exec Logon -R and start clean. This is a useful way to reset the program when you're deep into the gosub stack with no apparent way out. When swapping is enabled, don't forget to include the extensions of files you're spawning. This is something commonly forgotten and can cause you a lot of frustration if you do forget it. Best practice is to *always* include extensions, even if you're not swapping, so if you change someday you won't have to be tracking down every spawn function in every menu, config file, and so forth. You can spawn COMMAND.COM /c to run a batch file even though you're swapping. Spawn searches the DOS path for files that don't have a path specified. Sometimes certain combinations of things just don't work. Don't let it get you down. For instance, I tested XBBS for a couple of weeks under a friend's copy of DoubleDos. Had very few problems, none that you wouldn't expect (some doors didn't have enough memory, some insisted on direct screen writes, etc.). However, when I returned his copy and he then tried to run under DoubleDos, he couldn't get swap to work, despite the fact he was running basically the same setup I'd just tested. Why? Don't know, but that's the way it happened. The cookie sometimes crumbles. There are many ways to run an XBBS. One sysop I know runs the entire BBS off of Bulls-mode, another off of pull-down menus. You could also use a hypertext file-based BBS menu structure. An ANSI cursor menu tree would be possible, as would a full-word entry system, hot keys, or, possibly more importantly, any combination of these, including user-selectable interfaces of various types(!). One thing you can do to make your life easier is utilize the @G and @' commands to provide "fancy" menus with little effort on your part. Use metastrings wherever possible for things like display and completing filenames with system paths. A disk cache (*not* required) will speed up XBBS menu reading slightly and avoid "disk thrashing" if you utilize a lot of long branches in your menus. 32K should be more than sufficient for most purposes (bigger is, as always, better). A side effect would be increased message reading speed due to the two-files-per-area layout. Remember that XBBS' built-in message, file, library, news, configuration and Door modes are not only conveniences for starting sysops, but can be alternatives for your users who might prefer to have a variety of choices in menu topology, even after you've "replaced" them with custom menues. A lot of ex-QuickBBS/RA sysops ask me "when do I run XST (or XGroup)?" Anytime you want to. Change your mindset; XBBS isn't like Quick/RA, so don't try to fit it into that mold. You'll miss all the slick stuff you could be doing. Don't mistake the finger for the moon to which it is pointing. For you gamer types, XBBS can be used to set up a game (or games) with comparative ease. Use the user's lastarea flag to "put him back where he was" in a maze. Use security levels or user variables to track "character attributes." Use @eR to randomize action. You can even have users battle each other with an XBASIC program, "die" for a variable number of days (set a variable and decrement each day; deny write access to anyone with that variable > 0), win points, and so forth. Your imagination is the limit. For those of you who dabble with programming, don't forget that XBBS can act based upon returned ERRORLEVELs of external programs, and read files over the modem that were created by externals. This means you can do a lot with very little coding, letting XBBS (or XBASIC) handle the userfile and modem i/o (Wayne Michaels' XVER user verifier uses this principle). Here are a couple of examples to hopefully give you ideas: 1. Use Xport to make a text file of a message the user entered. Use a simple GWBASIC program to read the text file and write a menu increasing or decreasing his security level based upon analysis of the message. @J the menu when you return to XBBS. 2. Write a batch file using @EW to make a report from a database with user-specified criteria. Run the batch file, then read the resulting report file to the user. 3. Use FGREP to search a directory full of text files for a string of interest to a user. Display the redirected output to him for reference in selecting files to read. Since XBBS finds the message and file areas and Doors to which a user has access from the files MSGAREAS.XBS, FLSEARCH.CTL and DOORLIST.XBS for many commands, it's easy to create custom files for users to limit them (or provide addtional access to them) when they log on. You can make a series of complicated tests one time (say, in the WELCOME.?BS file), copy the appropriate files to MSGAREAS.XBS, FLSEARCH.CTL and DOORLIST.XBS, and use the functions which use those files. After that, you don't have to worry about security checking. MSETUP can further refine this process by allowing the users to turn areas on and off to taste. Remember, change your way of thinking! XBBS is an environment that can manage many diverse programs and turn them into a homogenous whole (the big strength of a non-multitasking OS like DOS). Try not to limit yourself to the 'old' ways of doing things; imagination will serve you well. More hints and tips will be added as we get the time. Feel free to contribute your own. --Technical info When a protocol's "filename(s) sent by remote" flag is set, XBBS handles uploads by creating a temporary directory off the upload directory named for the node number. For instance, an upload to C:\XBBS\UPLOADS\ will first cause the creation of temporary dir C:\XBBS\UPLOADS\001\\ (for node #1). Then the upload will be directed into that directory (XBBS actually switches into that directory). The upload is moved into C:\XBBS\UPLOADS\ as the descriptions for each file are entered by the user (and credit given). After all files uploaded have been commented, the temporary directory is removed. It is possible for a broken connection to leave files in the temporary directory. You can move them out manually, automatically with a batch file, or leave them there to be wiped before the next upload. All this allows XBBS to figure out what a user sent without the user having to type in each filename. To do a "local upload" for testing or whatever, create the directory manually, copy what you want into it, then go through the "normal" upload procedure. Security checks are skipped for local uploads. If a protocol's "uses DSZLOG" flag is set, XBBS reads DSZLOG instead of just checking manually for files. Downloads are handled more simply. XBBS switches to the download directory and calls the external protocol. Switching to the download directory allows more filenames to be passed on DOS' limited command line, since paths don't have to be appended to each file. If no errorlevel is returned by the protocol, the download is considered to have been successful. Exception: if "uses @listfile" is on for the protocol the user selects and the type of download allows searching all paths in the FLSEARCH.CTL file, XBBS builds a file named TRNSLIST.### (where ### is 001 for node 1, 002 for node 2, etc.) containing fully qualified pathnames of the files to be downloaded. This allows true global downloading with protocols like DSZ that support the use of a file containing filespecs (DSZ -sz @TRNSLIST.001, for example). In this case XBBS does not switch to the download directory. If no errorlevel is returned by the protocol, the download is considered to have been successful. Exception: if "uses DSZLOG" is on for the protocol used, XBBS reads DSZLOG instead of just checking the errorlevel. External messaging (where you call the message editor to allow the user to input a message, and XBBS imports it on return) relies on the file MSGTMP (or, for nodes other than 1, MSGTMP#, node 2 being MSGTMP2, node 3 being MSGTMP3, etc.). XBBS.TXT and XBBS.IDX are the only files that XBBS opens *and leaves open* the entire time XBBS is active. They are opened in read-only mode; however, it's *not* a good idea to mess with them if someone's online. XBBS.TXT (and .IDX) can be on your DOS path, so you can either use separate files for each node or a common file. You can switch "languages" with some creative copying and/or renaming. XBBS considers a message to be "treated" when it's had the useless soft CR's (ASCII 141) and linefeeds (ASCII 10) removed. XBBS will attempt to treat an untreated message on-the-fly whenever it reads one, as being treated speeds up subsequent message reading and reduces disk storage requirements (after a pack). XBBS compresses files using a method commonly referred to as LZSS. See XSCANLZS.C in the developer's archive if you're curious as to how it's done. Note that not all utilities will support compressed messages (though most do). XBBS can create its own "mail packets" for use with XHMS. You can do it with @r (you'll have to include a MSGAREAS.XBS with the files XBBS makes and arc them into a self-extractor yourself), or you can let Bulls-mode do it for you (it handles everything). XGatekpr will import reply packets that XHMS makes. A utility called MSETUP.EXE (in the executable archive) can let a user limit his file areas so that script files can be easily used to create packets and download them without human intervention. If you have questions about how to do this outside of Bulls-mode, netmail me. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Would you believe a boy scout and a sling-shot?" --Basic Menu-making In its simplest and most common form, a menu just present the user with some choices, asks for a selection, then does what the user selected. What that may be varies; you might go to a sub menu (another set of choices), run a Door (external program), send the user a file, read something, etc. The first step, displaying the choices, is simple. Load up your word processor and type in what you'd like the user to see in the way of your menu text (choices). We'll write a sample menu file here, and call it (appropriately enough) SAMPLE.XBS: ---------------------------------- @~@p1@a1 MENU: ===== [Q]uit [R]ead [W]rite Enter selection: @lRem ---------------------------------- The first line (@~@p1@a1) clears the screen, then turns off pausing and aborting. Notice the @lRem (remember @'s are representing ASCII 1's) at the end of the last line. This simply causes XBBS _not_ to print a CR/LF after "selection: ", so the cursor remains positioned a space after the colon. You can use "meaningless labels" to comment your menus. We could fancy this up a bit by putting in the time. Add this line between [W]rite and Enter selection: @tc @tr mins remaining. That will display the current and remaining time. You might also add a @C before that, which will display the current message area's status. If you need to change message areas from the default, you might need a @M statement as the second line of the file (after the no-abort no-pause stuff); something like: v---Subop status #1 +--------------------------------+ | @MSample Area,12,50,1,999,999 | +--------------------------------+ ^ ^ ^ ^ ^---Subop status #0 | | | +--Board # | | +--Max # messages | +--Area attributes (private(4)+public(8)=12) +--Area name Now we have to get some input from the user. We do it by adding this as the next line: ---------------------------------- @0I1 0 1 1 1 ---------------------------------- This gets a single uppercased character, number or symbol from the user. The input is "hot", which is to say the user doesn't have to press [Enter] after the key (unless their "cold input" flag is on). You can vary how this input works; for instance, you might make it "cold" so the user has to press [Enter], or you might make it so the user can type the entire word representing the command (i.e. "QUIT" instead of "Q"). The best change to make to the line above would be to limit the input to alphabetic characters only. (Boys and girls, can you figure out what one number to change to do that? I knew you could. Where's my sweater?) In our example, variable #0 will receive the user's input. Now that we have the user's choice, we need to do something with it. This requires a series of tests to see which command key was entered. If no command key was entered, we need to cover that, too. If you've written batch files, you might liken this to testing the ERRORLEVEL returned by a program. If you've written BASIC programs, you might think of it like testing the contents of A$ for a particular character. There are a couple of ways to do this. We could test for equality for each valid choice, and branch to a label if matched. If we fall all the way through, we'd display an "Invalid choice" message and loop to the beginning. Alternatively, we could test each valid choice for _inequality_ and branch from test to test, taking action when we finally find a match, again falling through to an "Invalid choice" message. Here's one way we could do it: -----------------+ @lRead |<--Just a label @0C!R |<--If the user didn't enter R lEnter |<--go to this label----------------------+ ead messages |<--else display this | @r0,0 |<--and read messages | @h |<--then pause until user hits enter | @jSAMPLE.XBS |<--and restart the file | @lEnter |<--branched here from above, remember?<--+ @0C!W |<--test for W lQuit |<--if not, go to this label----+ rite a message |<--if it was, print this | @w0,0 |<--and write a message | @jSAMPLE.XBS |<--then restart the file | @lQuit |<------------------------------+ @0C!Q |<--Was it Q the user hit? lHuh? |<--If not (! means not) go to this label---+ uit to Main Menu |<--Display rest of "Q" message for show | @jMAIN.XBS |<--Return to main menu | @lHuh? |<--User's entry didn't make sense, so<-----+ +--------------+<--print a blank line I have no idea what that means! |<--Show user this and @P1 |<--Pause for a second @jSAMPLE.XBS |<--Restart file --------------------------------+ Now, suppose you don't want to allow people with a security level #0 of less than 10 to be able to read messages in this area. All you need to do is add another check _after_ you've made sure they pressed R. Therefore, the above would become: @lRead @0C!R lEnter -----------------------------------------------+ @S<010 lNoRead ------------------------------------------+ | ead messages | | @r0,0 | | @h | | @jSAMPLE.XBS | | @lNoRead <-----------------------------------------+ | | Sorry, you don't have enough access to read messages here. | @jSAMPLE.XBS | @lEnter <----------------------------------------------+ ...etc.... You could extend this method to checks for all sorts of things (multiple security levels, various flags like ANSI, etc.). You could also do similar tests and branches when displaying the choices so that only those who could read would see the [R]ead prompt (be awfully friendly of you to do that...). You have just written your first menu. There's a lot left to learn, but it's all basically the same method to the madness. Experimentation won't hurt anything as long as you're sure to allow only thoroughly debugged menus to be accessed by callers. Don't forget the power of batch files and external programs, either. Here's a sample skeleton for a complicated menu (THISMENU.XBS) which shows how to combine three different menu types (ASCII, High ASCII and ANSI) in one file. The ^<letter> combinations refer to a control character here; for example, ^K would be CTRL-K and ^[ would be ESCape. Note that under @lASCIIMenu we're also differentiating between Expert, Novice and Twit users. This menu gives each type of user a different, tailored menu but minimizes duplicate coding by using the same input routines for everyone. There are only about two dozen other ways to accomplish basically the same thing with XBBS; this isn't necessarily the best, but is a good exercise. :-) @^[@blANSIMenu <--ANSI users go to the ANSI menu @^N@blHigh_ASCII <--HighASCII users go to the High ASCII menu @^KlBriefASCII <--Experts jump to @lBriefASCII @lWhichMenu2 <--We come here if the user entered ? @^[@blANSIMenu2 <--? for ANSI users goes to their expanded menu @^N@blHigh_ASCII2 <--Ditto for High ASCII users <--Fall-thru to ASCII expanded menu The Menu is: <--Experts don't see this unless they enter ? =========== [A]...Do an A thing [B]...Do a B thing [C]...Do a C thing [D]...Do a D thing @^L@blDontOffer <--Twits only Do you need more help? (Y/n) @; @0I1,0,1,1,5 @0C=N lDontOffer @JHelpIjit.XBS <--Would contain painful detail on choices @lDontOffer Select: @; <--Normal and twits see this @blGetInput @lBriefASCII <--Experts get this [A,B,C,D or ?]: @; @lGetInput @0I1,0,1,1,1 <--Takes input for everybody @0=A lDoA @0=B lDoB @0=C lDoC @0=D lDoD @blWhichMenu2 <--Musta been ? (or dumb, invalid keystroke) ... <--DoA...DoD would go here @lHigh_ASCII ... <--You'd display your High ASCII menu and prompt here <--then branch to @lGetInput @lANSIMenu ... <--You'd display your ANSI menu and prompt here <--then branch to @lGetInput Inside SAMPLES.LZH there's a file called MAIN.SMP. This is a simple but thoroughly commented main menu file you might find enlightening to study. Also take a look at MAIN2.XBS which uses the automatic functions (Bulls-mode, Files-mode, Door-mode) of XBBS. It more-or-less mimics Ijit-mode. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "It's all right, maw, I'm only dyin'" I'd like to thank my long-suffering betatesters, especially Mike Berry, Clinton Adams and Ariel Szczcupak (the Israeli phone system would probably also like to thank Ariel), for their time, patience and help. Thanks to TurboPower for the source to their swap routines, which were modified and incorporated into XBBS (let's hear it for programmers who share! Thanks, Mike.). The SDS gave XBBS its own distribution area--thanks, guys (and give 'em hell, Harry!). The BT3 wrote a great, flexible mailer that I personally use (or used to) with XBBS. Tom Jennings invented the diverse thing we call Fidonet. Wayne Michaels kindly wrote a scanner-tosser for XBBS so I wouldn't have to (THANK YOU!). Then I went and did it anyway. Commit me, please. As with any project of this size, you may find a bug or two. This product was extensively betatested, but sh*t happens. If you find a bug, please report it with plenty of information (when it shows up, when it doesn't, what happens before, during, after, copy of the menu/datafiles, how to *make* it happen, etc.) and a fix will be incorporated into the next release. Above all else, remember that the developers of XBBS and XST are doing this as a hobby, not a business. Whatever you get out of XBBS is more than you paid for it. Treat us as friends or leave us alone. Thank you, and good night. <click> M. Kimes (XBBS) 1:380/16 (318)222-3455 data 542 Merrick Shreveport, LA 71104 Wayne Michaels (XST) 1:380/100