ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / MISC / XDOC_117.ZIP / XBBS_116.DOC < prev

Wrap

Text File | 1990-12-06 | 66.7 KB | 1,412 lines

╔══╗╔══╗╔═════╗╔═════╗╔════╗ ╓──╖ ╓──╖╓──────╖ ║ ║║ ║║ ┌┐ ║║ ┌┐ ║║ ║ ║ ║ ║ ║║ ║ ║ ╚╝ ║║ └┘ ║║ └┘ ║║ ╔═╝ ╙╖ ║ ╙╖ ║║ ╓──╖ ║ ╚╗ ╔╝║ ╔╝║ ╔╝║ ╚═╗ ║ ║ ║ ║╙─╜ ║ ║ ╔╝ ╚╗║ ┌┐ ╚╗║ ┌┐ ╚╗╚═╗ ║ ║ ║ ║ ║ ║ ║ ║ ╔╗ ║║ ││ ║║ ││ ║╔═╝ ║ ║ ║ ║ ║ ║ ║ ║ ║║ ║║ └┘ ║║ └┘ ║║ ║ ╓╜ ╙╖╓╖╓╜ ╙╖ ║ ║ ╚══╝╚══╝╚═════╝╚═════╝╚════╝ ╙───╜╙╜╙───╜ ╙─╜ Documentation for -=-= XBBS =-=- v1.17 Copyright (c) 1989/90 by M. Kimes -- All Rights Reserved * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Introduction: "Hey...you wanna see somethin' _really_ scary?" XBBS is a BBS designed for sysops who are more concerned with flexibility than ease of setup. If you want something you can run out of the box, XBBS is not for you. If, on the other hand, you are the kind of sysop who likes to constantly tinker, tweak and improve your setup, or if you want to do something with your BBS that no other software will allow, XBBS should be the one for which you're looking. If you're the type who wants to set something up in ten minutes and forget about it; trash XBBS and get something else. XBBS is written in C (with a dash of assembler), and like C, provides a great deal of power and flexibility, but puts the burden of telling it what to do (and ensuring you don't make mistakes) squarely on *your* shoulders. If you can't write a decent batch file, delete this archive immediately and download something simple, like Opus or Sapphire (no offense meant to the Penguin). XBBS is not forgiving of novices. It will reward you, however, if you have the time and patience to learn to use it properly. Some programming experience is a definite plus, as XBBS is basically a weird interpreted language for writing a BBS. If you can write a batch file, you can probably use the simpler features of XBBS (i.e. make it act like a "regular" BBS). If you can write a BASIC program, you can probably take advantage of its more sophisticated features. Reading the documentation, studying the samples, experimenting, and plain old work are required. If you don't like the sound of that, find a different BBS, please. XBBS was written in an attempt to do two major things: provide maximum flexibility and take advantage of DOS's strengths while avoiding its weaknesses. Remember: flexibility is a double-edged sword. "The urge to perform is no guarantee of talent," as a wiser man than I once said (hey, it could happen). It's very easy to make something with XBBS that no one in their right mind would want to try to use. It takes work to make a useable system, and more work still to make an exceptional one. This is not to say that you can't write a "maintenance free" BBS with XBBS. You can make almost *any* BBS maintenance free with the proper utilities (despite what some purveyors will tell you as they reach for your wallet). But there will be hard work up front, and please don't fool yourself about that. XBBS was first published in early 1985 as a BBS program for Commodore 128's. Since then, it's grown into a series of MS-DOS QuickBASIC and C doors and finally into an MS-DOS BBS. It is not affilliated with a similarly named ?nix product that came out in about 1987 or 1988. So much for the history lesson. Note: The source code mentioned in this document is included in the XDEV_116 archive, along with some other goodies programmers may find of interest and/or use. Anyone wishing to write utilities for XBBS is encouraged to do so (and <hint hint> it'd be nice if they were freely available). --Hardware/Software Requirements: To run XBBS, you'll need an IBM or close compatible with a minimum of 256K of RAM (more recommended, especially if you want to run Doors) and a hard drive. 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). ANSI.SYS or similar display driver should be used to interpret escape sequences; you might want to go with something like ZANSI that doesn't support keyboard redefinition for security reasons. Your CONFIG.SYS file should contain statements similar to these: Files = 25 Buffers = 15 These are recommended minimums. You could probably slide by with less, but why be such a tightwad? XBBS does _not_ 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, 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>. 2. It frees me from having to update my version to match the latest version of <name a protocol>. 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. We recommend LineEd, QuickEd, QEdit and ANSIEd respectively, though others may work fine for you and we 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... 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 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 we wanted comments in the damn header we 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 mean public domain, and it does not mean source should 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? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 (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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Quick Setup: ----------- "Long live the new flesh." If you're an impatient type, you're dying to get something running. Ok, but you don't get much with no work. First, you'll need to create some directories. About Directories: As with almost any BBS software for MS/DOS machines, you're going to have to make some directories to house different parts of the BBS. Here is the setup we recommend (the sample menus are geared toward it): C:\XBBS "Root" directory for the BBS C:\XBBS\MENU Directory for *.?BS menu text files C:\XBBS\MENU\BULLS Optional directory for intro files and Rules files in Bulls-mode C:\XBBS\MESS Directory for message area files C:\XBBS\NEWS Optional directory for news files C:\XBBS\XPORT Optional directory for exported mailpackets for users C:\XBBS\MPORT Optional directory for incoming mailpackets from users C:\XBBS\FORCE See discussion under XUser.EXE Menu files with .XBS extensions are looked for in the Menu directory (unless you include a path when you call them). There's more in-depth information on creating directories later in this file. If you have no idea how to make a directory with MS-DOS, you're probably not ready to run a BBS. KEEP YOUR PATHS SHORT. DOS command lines are limited in length. Next steps: 1. Run XConfig in the BBS root directory. Go through each screen of each option. Use F1 for help. This creates the configuration files CONFIG.BBS and NEWUSER.BBS. 2. Run XEdit. This edits your external up/download protocol records, message and file areas, creating the configuration files for each. 3. Run LOGON (just type LOGON at the DOS prompt). If you haven't copied the sample menus into the menu directory, you'll get Ijit mode after you finish your 'newuser login'. Probably not much you can do with an empty BBS, but you've started. Now finish reading the docs to find out how you can make XBBS do most anything you can envision. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "220, 221, whatever it takes." Utilities First: 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). 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). 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. 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). Source code is _not_ included, as the window library I used is from "Turbo C Memory-Resident Utilities, Screen I/O and Programming Techniques", an excellent book from MIS: Press by >>Al Stevens<<, and is not PD. If you're interested in the source and can send me _proof_ you purchased the book, we can work something out. --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. * Fields optional or ignored if you have a CONFIG.BBS in current directory. They are mainly for a HeadEdit running as a point sans XBBS. --XScan 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). --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. --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. --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> --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. 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). Note that in the above Download and Upload strings, *F gets replaced with the name(s) of the file(s) to be uploaded/downloaded. 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> --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. --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> --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 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... Note that XBBS' help system (which can, and probably should, be customized) starts at prompt #501, and space for sysop-defined help starts at #601. --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. --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. --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. --A word about 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. Complete source code for Logon is _not_ included. I taught myself C while writing this... There is no longer an "XMain" program. Logon is now overlayed. As with all overlayed programs, installation on a RAM disk 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, 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 (XNON_???.LZH). --Arguments for Logon: 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) 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. Any arguments beyond these initial arguments are copied into the XBBS variables starting with variable 0 and proceeding to variable 9. 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 don't multitask. 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 partition (depending on your Doors, of course). XBBS does use SHARE-compatible file i/o and locks message areas when writing to them. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "Whatever you do, don't go to sleep." Setup In setting up, you have to decide on three paths for the BBS to find and put information. These are: --------------------- 1) Message Path -- This is where XBBS will put the messages entered on the system. Each message base is in two files, one for header information, and the other for actual message text. Structures and sample code are in the XbbsDEVelopers archive. 2) Menu Path -- This is where XBBS will look for its menus. Logon will startup looking for START.XBS (and switch to MAIN.XBS if it can't find START.XBS) when run with the -R parameter, but you can specify another by following the -R switch at startup (defaults to MAIN.XBS if you don't put a filename immediately after the -R). If XBBS is looking in the menu path for a file that has a .XBS extension, and finds a .GBS of the same rootname, it will read that to ANSI users. You might also want to create a sub-directory from this directory (should be called BULLS) for the Intro/Rules files for the message areas you create using the Bulls-mode option (see textfiles section for further explanation) 3) BBS Path -- This just tells XBBS where it will find its files, such as the users file, config file, etc. Once you have these set up (in XConfig under Paths) and have made the directories, you will need to make a batch file to run XBBS. This can be the same batch file that controls your mailer or a separate batch file just for XBBS, but remember that a mailer or front-end is required, as XBBS does not have a way of answering the phone by itself . When the mailer exits, you must specify the baud rate to Logon. After the user logs in, Logon will make the appropriate files to remind itself (if you exit and restart with -R) who the user is. It also makes the USERINFO.XBS for XBBS Doors, and LASTUSEx.BBS, DORINFOx.DEF and DOOR.SYS for other Doors. The best way to set this up is have Logon get the user's name, and then jump into a loop in which Logon is called each time the loop exits with a -R argument, unless the errorlevel is 253 or greater. -----------> 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 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 If you're in a hurry to see how little XBBS will do if you don't create some menus, switch to the BBS directory and type LOGON (after running XConfig and without any menus in your menu directory). Here comes Ijit-mode... Remember, you get what you pay for (in terms of time and labor spent working on your BBS). If you're happy with Ijit-mode, fine; you've got a no-work, ready-to-run BBS. But ask yourself this question: why aren't you running Opus? It'll answer the phone and exchange mail, too... Okay, okay, let's assume that you want to get started with XBBS right away and build your menus as you go along (not a bad idea, really), so you want to start with Ijit-mode. First, Ijit-mode is invoked when XBBS can't find a MAIN.XBS in the menu directory. Ijit-mode has very few commands; however, most of them lead to submenus with more commands (a tree structure). It's designed to be simple to use, not flashy. (Be sure you edit XBBS.TXT prompt #208 so the usual error message (Can't find MAIN.XBS) doesn't get flashed at your users.) 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 which keys invoke which 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... Next, the asterick [*] will read a file called IJITXTRA.XBS if it can find one, allowing you to add (a) command(s) without disturbing anything else (there are corresponding *XTRA.XBS files for Bulls-mode, Files-mode and Door-mode--see SPECFILE.DOC). 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 #453 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, and [Q] for LOGOFF.XBS. (Quick note: XEdit can create 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. A final, more advanced trick, is available. Refer to the comment at XBBS.TXT prompt #453 for information. If you get to this point, you should probably just consider breaking down and writing a MAIN.XBS like the big boys (see "Basic Menu-Making" below). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "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 End: Toggle status line 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. CTRL-HOME and CTRL-END perform the functions you might expect HOME and END to perform in pop-up windows. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * "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. 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. A side effect would be increased message reading speed due to the two-files- per-area layout. Remember that XBBS' built-in message, file 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?" 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. 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. Remember, change your way of thinking! XBBS is an environment that can manage many diverse programs and turn them into a homogenous whole. 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. If no errorlevel is returned by the protocol, the download is considered to have been successful. 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 is the only file that XBBS opens *and leaves open* the entire time XBBS is active. It is opened in read-only mode; however, it's *not* a good idea to mess with it 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. 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 In MENU.LZH inside XDOC_116.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 with XBBS. Wayne Michaels kindly wrote a scanner-tosser for XBBS so I wouldn't have to (THANK YOU!). 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, 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