EAZIHOST VERSION 2 User Manual Copyright (C) 1990/1991, P.M Opacic & SandSoft. All rights reserved. INTRODUCTION EaziHost is a comprehensive, yet easily mastered, Bulletin Board System developed from, and much expanding on, EaziLink's host mode. Those already familiar with EaziLink's host mode will find the move to EaziHost particularly effortless. All comments are welcome and should be posted as public messages on The SandSoft Support Board (Skipton (0756) 791298). Please note that details of BBS based technical support, for REGISTERED USERS, is included with the full registration package. EaziHost has most of the features expected of a BBS and is very simple to set up. Features include ANSI display support, user access levels, user time limits, members only access to selected file or message areas, multiple message bases with bulk message download capability, multiple file areas, news bulletins, doors, user defined colours, menus and help screens, archive viewing facilities and a flexible file up/download mechanism. The 1200/75 split baud rate, still used in Britain, is also supported when speed buffered modems are used. EaziHost should run on all IBM PC/XT/AT machines and close compatibles with 512K+ of RAM (640K recommended for maximum versatility) and fitted with a VGA, EGA, CGA, MDA or HGC video adapter. The program will run on large capacity floppy disk based systems but full use of all features is only practical with a hard disk. The program is supplied with default modem control strings to suit a Miracle WS3000 modem but EaziHost can generally be configured to suit any Hayes compatible modem or one which has a very similar range of capabilities. EaziHost is configured to make use of external file transfer protocol drivers rather than having such drivers built-in. This approach offers maximum flexibility and enables improved drivers to be incorporated as and when they are released. Please remember that these third party protocol drivers, such as the widely available DSZ (tm), are themselves usually Shareware products and should be registered with the copyright holders if you intend to use them with EaziHost. Two computers, one running EaziHost, can also be connected locally by cable. (See the DIRECT CONNECTION section) DISTRIBUTION RESTRICTIONS Evaluation EaziHost is NOT a public domain or free package. Non-registered users of EaziHost are granted a restricted license to use the product for a limited evaluation period, to determine it's suitability for their purpose. Continued use of EaziHost beyond this evaluation period, not exceeding 21 days, requires registration. Package Integrity EaziHost must be distributed in a completely unmodified form, including all the original program, document and support files. Commercial Organisations EaziHost may not be distributed as part of any other product or service by a business, organisation or institution, without entering into a suitable bulk registration agreement with SandSoft. Bulk registrations involve the supply of multiple full registration packages and attract a sliding scale of discounts up to a maximum of 40% - 5+ Copies 10% Discount 25+ Copies 20% Discount 50+ Copies 30% Discount 100+ Copies 40% Discount Where a number of copies of EaziHost are to be used at the same working location, a site license may be purchased. Site licenses involve the supply of one master disk and one printed manual - the reproduction and distribution of copies is the responsibility of the client. Site licenses attract a fixed discount of 50% for all copies after the first for which the full registration fee applies. BBS operators may offer EaziHost for download and Shareware disk vendors may distribute the package freely, provided that no charge is made for the software itself and provided that EaziHost is not supplied as part of a commercial package or service as outlined in the 'Commercial Organisations' section above. Special Arrangements Organisations with special or unusual licensing requirements are invited to contact SandSoft with their proposals. SandSoft will also consider requests for the production of customised versions of this product. REGISTRATION Individual copies of EaziHost may be registered by sending the 35.00 registration fee along with your name and address to: P.M. Opacic, 5 Lytham Close, Skipton, N. Yorks. BD23 2LF The printed manual is supplied only to users who have registered EaziHost and paid the registration fee. If you have registered we would like to take this opportunity to thank you for your support. Please DO NOT copy and distribute the printed manual or the registered program disk supplied with it. Important: SandSoft reserves the right to exclude the printed manual for registrations outside Great Britain and the EEC unless sufficient additional postage is included (i.e. enough to cover a 300 gram package). If you wish to pass on copies of EaziHost to other prospective users, please offer them the Shareware version only. Registration entitles you to future upgrades at reduced cost and also to BBS based technical support. A standard registration entitles a user to run EaziHost on ONE computer at a time. If any group or organisation requires multiple copies of EaziHost they may negotiate a bulk registration agreement with SandSoft, or purchase a site licence. (See 'Distribution Restrictions') Using The SandSoft Support Board we will attempt to answer queries, receive bug reports etc. and keep a fully updated copy of EaziHost for registered users to download at all times. Details of any additions or improvements to EaziHost will also be posted on the board. The SandSoft Support Board: Skipton (0756) 791298 Do make use of the support board - It is a service provided for you as a registered user. When you first log onto the support board, leave a message to the author of EaziHost, Michael Opacic, requesting upgrade. Once upgraded you will have access to an additional registered file area. If you have any problems or queries please 'Post' a public message on the support board. We or other EaziHost users will help where possible. THE FULL REGISTRATION PACKAGE REGISTERED users will receive the registered version of EaziHost along with a printed and bound manual. Note: The 35.00 registration fee applies to EaziHost v1.x & v2.x. SandSoft reserves the right to increase the fee for subsequent major version number releases - enquire via the support board, or by voice on (0756) 794046, for the latest version and registration fee. Registered users will receive a number of utility programs designed for use with EaziHost. More utilities are being produced all the time - below is a list of those currently supplied. EAZIEDIT.EXE A fast full screen ASCII text editor using WordStar (tm) compatible commands. A comprehensive editor in which all the usual editing and block manipulation commands are supported. You may install this as your external 'Editor'. EAZIFILE.EXE A file management program which allows files to be tagged and copied, deleted, renamed etc. This may be installed as your external 'Filer'. ANSITYPE.EXE A utility which enables the user to type files containing ANSI escape codes without the need for ANSI.SYS. See how those EaziHost host mode screens will look. EAZICD.EXE A CD ROM interface for EaziHost - extends the total file areas in EaziHost up to a maximum of 99 and handles file transfers from the CD ROM. QUESTION.EXE A simple Questionnaire door program for EaziHost. EHTYPE.EXE A file typer for door type 2 use which honours all EaziHost's '^' special codes and '%' system variables. A number of third party utility programs, designed specifically for use with EaziHost, are already available, or in the process of being written, and will be made available to users via the support board. INSTALLING EAZIHOST The Distribution Files The following files are included in the distribution package: EAZIHOST.EXE The main program EXE file. EAZIHOST.OV1 The main program overlay file. CONFIG.EXE EaziHost's configuration module. EAZIHOST.DOC The main documentation file. ANSIED.EXE EaziHost's full screen ANSI editor. EAZIHOST.PRO External protocol definitions. INSTALL.EXE EaziHost's auto-install program. SETTIMES.EXE Utility to set user time limits. SETTIMES.DOC Documentation for Settimes. ELX.EXE EaziHost's Xmodem protocol. ELX.DOC The Xmodem documentation. *.MNU Default menus displayed to callers. *.HLP Default help files displayed to callers Note: We Strongly recommend that you set up EaziHost in the directories located and named as in this section - the INSTALL program will do so automatically. This will make installation of EaziHost, and other support programs which you might wish to add later, much easier. Automatic Installation If you are installing EaziHost on a hard disk or large capacity floppy disk, you can make basic installation relatively pain free by using the INSTALL.EXE program included with the package. To auto-install EaziHost, follow these steps: 1) Create a new directory called 'EAZIHOST', off the root directory of the disk on which you wish to install EaziHost. 2) Copy all the files supplied with the EaziHost package into the newly created EAZIHOST directory. If the EaziHost files are stored in archives you will need to extract them - make sure you also extract files from any smaller archives within the main one. 3) Whilst in the new EAZIHOST directory execute INSTALL.EXE from the DOS prompt and follow the on-screen instructions. If your modem was included on the INSTALL program's list, you should now be ready to run - otherwise you will need to consult your modem manual and configure EaziHost manually. The INSTALL program can be used at any future time to change the modem type - it will NOT undo any existing configuration settings which are not related to the modem. Manual Installation We have assumed here that the drive on which you wish to install EaziHost is hard disk C. Create a new directory, immediately off your hard disk's root directory, called 'EAZIHOST' - this will be referred to from here on as the 'EaziHost Directory'. Change to the newly created EaziHost Directory and create the following sub-directories: C:\EAZIHOST\HOSTMAIN A general host file path C:\EAZIHOST\HOSTUP The default file upload path C:\EAZIHOST\HOSTDOWN The default file download path C:\EAZIHOST\HOSTMESS The default message base path C:\EAZIHOST\XFER The protocol driver path Note: The three 'default' paths are required by the most basic EaziHost configuration only and may not be used in more complex set-ups - this will be clarified in the appropriate sections later in the manual. Copy EAZIHOST.EXE, EAZIHOST.OV1, CONFIG.EXE, ANSIED.EXE, and EAZIHOST.PRO into the EaziHost Directory. (EAZIHOST). Copy SETTIMES.EXE and all the '.MNU' and '.HLP' files, into the 'Host Main Path' (HOSTMAIN). Copy ELX.EXE and any other external file transfer protocol drivers which you intend to use, e.g. DSZ.COM, into the 'Protocol Path' (XFER). To run EaziHost, simply, ensure you are in the main 'EaziHost Directory' and type EAZIHOST at the DOS prompt. Before you do so however, read the following section on file transfer protocols and edit EAZIHOST.PRO, if necessary, to reflect the protocols which you have installed. If you are happy with the ELX and DSZ range of protocols or you are unsure, at this stage, of how to edit EAZIHOST.PRO then DO NOT modify it - It will work initially as it is supplied. Then you can start up EaziHost. (Note: Run the Configure section from the EaziHost Main Menu before doing anything else.) FILE TRANSFER PROTOCOLS All file transfer protocols used by EaziHost are External. This provides the most flexible method of transferring files since the user can define up to 16 protocols of his/her own choice. Several protocols supported by the popular DSZ protocol driver have been defined in the sample 'EAZIHOST.PRO' file supplied with the package. Since no file transfer protocols are built into EaziHost, it is recommended that you edit the 'EAZIHOST.PRO' file first thing. Add any protocols which you have available to callers. You may find that the ELX and DSZ options supplied are enough to start with - you can add others later of course. All installed protocols are available unless suppressed by use of the semi-colon modifier the effect of which is described later in this section. The file 'EAZIHOST.PRO' can be created by any standard ASCII text editor. Any line starting with a '\', '.' or ';' character is considered to be a comment and is ignored by the program. The General form of a complete protocol definition is as follows: name MenuName hotkey Character upload UploadCommandLine download DownloadCommandLine where: 'MenuName' is the protocols name as it is to appear on the menu. 'Character' is the key to be pressed to select it. (A..Z, 0..9) 'UploadCommandLine' is the full upload command line. 'DownloadCommandLine' is the full download command line. These four lines must be in the order shown and all lines must be present for each protocol defined, or an error message will be generated and EaziHost will abort at start-up. If any of the defined protocols are to be temporarily excluded from those offered to callers, add a semi-colon (;) to the end of 'MenuName' i.e. 'MenuName;'. This will prevent display and use of that protocol. If a protocol supports multiple file names on the command line, as DSZ's Ymodem & Zmodem do, multiple download capability can be specified by adding an asterisk '*' to the end of 'MenuName' i.e. 'MenuName*'. The caller can then specify up to 9 separate files for download in a transfer session. Both the upload and download command lines are the lines you would normally type at the DOS prompt to invoke a file transfer with the selected protocol. These command lines may contain 'system variables' (fully described later) to pass information to the protocol driver. The system variables relevant to file transfers are as follows: %port Is replaced by the current comms port number. %speed Is replaced by the current DTE baud rate. %linespeed Is replaced by the current line baud rate. %file Is replaced by the, user entered, file name/s to be transferred. %path Is replaced by the current path. This is always where EaziHost wants incoming files to be stored and can be used to prevent file path specifications transmitted certain protocols from influencing the incoming file's location on your disk. Note: DSZ does not accept a root path in the form 'A:\', as passed by the %path variable, and DOS's CD command, as valid. It will only accept a path without a trailing '\'. You must use upload and download paths which are not root paths if you intend to use %path in a DSZ protocol definition, within EAZIHOST.PRO. For example If you wish to direct downloads to floppy drive 'A' - make the path 'A:\DOWNLOADS' and %path will direct downloads correctly. If a command line contains the '%file' system variable then the user is prompted to enter the file name/s before file transfer commences, otherwise the file transfer routine will expect the names to be supplied in the header from the remote service as happens in the case of Zmodem. Simpler protocols like Xmodem need the '%file' to be included in both send and receive modes. Example: name Zmodem hotkey Z upload DSZ.COM port %port speed %speed sz %file download DSZ.COM port %port speed %speed rz %path Note: The extension '.COM', '.EXE' or '.BAT' MUST be used with the protocol driver name since EaziHost executes each file type differently. The driver name may contain a path specification, to indicate where the driver will be found. If not, the protocol driver must be in the directory specified in the configuration 'Protocol Path' field. Study the supplied EAZIHOST.PRO file to see how the ELX and DSZ protocols have been defined. Note: EaziHost executes those protocol drivers which appear in EAZIHOST.PRO with a '.COM' or '.EXE' extension, directly as child processes without using the command processor - COMMAND.COM. If the extension is '.BAT' then the command processor is used to execute the protocol driver. Some drivers need to be executed by the command processor and should be set up as batch files which appear in EAZIHOST.PRO with the extension '.BAT'. If an external protocol driver does not work when configured for EaziHost as ELX and DSZ are, try installing it as a batch file. IMPORTANT: Where a file transfer protocol is configured as a batch file - the batch file and the protocol driver itself should both be in the same directory - that which is indicated by the 'Protocol Path' field in the configuration section (XFER). The name of the driver in the batch file itself MUST include the driver's FULL path name. This is necessary because once the batch file has gained control, EaziHost has no way of controlling where the batch file should look for the executable driver itself. Our own Xmodem external protocol, ELX, is supplied with EaziHost to ensure that users have at least one common protocol to offer callers. We recommend that Sysops also install DSZ (tm). ELX and DSZ definitions are included, ready for use, in the supplied EAZIHOST.PRO file. Make sure that you have located ELX.EXE (and DSZ if you have a copy) in the 'Protocol Path' (XFER) directory. Note: ELX is an Xmodem implementation but is installed to use hot key 'E' to avoid conflict with DSZ's Xmodem entry. It is compatible with other Xmodem and Xmodem-1k implementations supported by various communication packages. (See ELX.DOC) MAIN MENU OPTIONS On program start-up, immediately after the initial copyright screen, the Main Menu is displayed. +----------| MAIN MENU |----------+ | | | Host | | Modem | | Editor | | Shell | | Configure | | Utilities | | Quit | | | | | | Enter host mode | +---------------------------------+ The options available are as follows: Host Sets EaziHost in Host Mode - described more fully later. Modem Allows commands to be typed directly to the modem to assist in testing and setting up - This facility is NOT intended for making calls to online services. The communications port, baud rate and handshake used in this mode are taken from the relevant fields in the configuration section so configure EaziHost correctly before using the 'Modem' option. Editor Invokes the editor specified by the user during the configuration procedure. Shell Invokes a DOS shell from which DOS commands and programs can be executed. Type exit at the DOS prompt to return to the program. Configure Enables default settings to be selected and saved to the EAZIHOST.CNF file in the EaziHost Directory. This file will be read when EaziHost is started up in future and the settings it contains will be adopted. When you first run EaziHost, select this option first and work through each installation section carefully. Refer to your modem manual when entering modem control strings. Changes which you make are automatically saved on returning from the configuration section. Utilities Presents the Utilities menu. The on-line Alt U option offers the same set of utilities. The options available are: Command.......Execute a single DOS command. Any command which can be entered at the DOS command line may be executed from here. If you want EaziHost to pause before regaining control, in order to see the resultant output of the command, then add a semi-colon ';' to the end of the command line. Shell.........Run the DOS shell. Repeated on this menu for convenience. Editor........Run the editor defined in the configuration section. Repeated on this menu for convenience. File manager..Run the file management program defined in the configuration 'Optional Utilities' section. File Lister...Run the file listing program defined in the configuration 'Optional Utilities' section. Quit Exit from EaziHost to DOS. The HOST.LOG file is closed where appropriate. CONFIGURING EAZIHOST EaziHost can be configured to suit a users hardware and working environment preferences. Configurable items are presented on a menu: +---| Configuration |---+ | | | Port Number | | Modem Control | | Optional Utilities | | Host Mode | | Colour | | Alarm | | Quit | | | +-----------------------+ Any one or all items may be edited. The configuration section's menus have been designed to allow the user to cursor up or down to any particular field within a configuration block, and thus edit fields selectively. This mechanism rotates around the menu fields - when it reaches the bottom it returns to the top and vice versa. When all changes have been made, press ESC to leave the block. If any item in the block has been changed you are prompted to indicate whether you wish to keep the changes or not. Port Number Select the comms port to be used 1..4. (if in doubt select port 1 if you have an external modem or port 2 in you have an internal card modem) Modem Control EaziHost may be configured to answer calls via the modem's auto- answer capability or operate on a software answering basis where the software itself tells the modem when to answer the call. The software method is safer and generally recommended. NOTE - If Software answering is employed, the modem's auto-answer feature MUST be turned OFF (usually S0=0 on a Hayes compatible modem) Hardware answering The 'Reset' string is sent as the system is put into host mode, followed immediately by the 'Initialise' string. Just before recycle 'Reset' is sent (before RECYCLE.BAT runs). After recycle the 'Reset', 'Initialise' sequence is sent again - and so on. 'Reset' is sent when local mode is entered or host mode is exited. Software answering The 'Reset' string is sent as the system is put into host mode, followed immediately by the 'Initialise' string. 'Reset' and 'initialise' are NOT sent again before each following call nor is 'Reset' sent before recycle commences nor before entering local mode (see below for exceptions to this rule). 'Reset' is sent when host mode is exited. NOTE: The above software answering logic ALWAYS applies with systems running with a fixed DTE. The same logic also holds true for those systems where the DTE is not fixed (i.e. where DTE is dropped back to the caller's line speed) when the caller is actually online at the SAME speed as that set in the Host mode configuration section. HOWEVER, on non-fixed DTE systems, where a caller is online at a lower rate than that set in the configuration section, the modem is re-initialised, after recycle, using the 'Initialise' string to ensure that the modem can pick up the rate at which it should be set, from the 'AT' command in the 'Initialise' string, ready for the next call. For this reason such systems must have at the very least an 'AT' command in the 'Initialise' string. Even if modem memory is being used to set the modem up, the 'Initialise' string should contain at least 'AT|'. The modem is controlled by EaziHost using the entries made in these fields: +----------------| Modem Control Strings |----------------+ | Reset : ATZ ^M | | Initialise : ~~~~+++~~~~AT X1 V1 S0=1 S24=5 ^M | | Hang-up : ~~~~+++~~~~AT H0 ^M | | Answer Mode : Hardware | | Answer Call : ATA^M | | Ring Message : RING | | Ring Count : 2 | | Connect Time : 40 | | Command OK : OK | | Connect 300 : CONNECT^M | | Connect 1200 : CONNECT 1200 | | Connect 1275 : CONNECT 1275 | | Connect 7512 : CONNECT 7512 | | Connect 2400 : CONNECT 2400 | | Connect 4800 : | | Connect 7200 : | | Connect 9600 : | | Connect 12000: | | Connect 14400: | | Connect 19200: | | Connect 38400: | +---------------------------------------------------------+ Note: The following characters have special effects in modem control strings: | RETURN ^ The following character is treated as a control character if it is in the range '@'..'[' (0..27) otherwise the following character is sent as is. e.g. ^M^J sends a carriage return followed by a line feed, ^| sends a the '|' character (not RETURN as usual), ^^ sends the '^' character itself. ~ Causes a half second delay. The default strings in EaziHost are suitable for the Miracle V22 WS3000 modem. The default modem control strings are as follows: Reset.........ATZ| Resets the modem back to it's factory settings (don't forget the '|' carriage return symbol). Initialise.....~~~~+++~~~~AT X1 V1 S0=1 S23=1 S24=5 | This is the modem control string required to initialise the modem and will be different depending on whether hardware or software answering is to be employed. The example above shows strings suitable for use with hardware answering. The string should also ensure that baud rate scanning is activated, if available. The various elements in the default string above, have the following effect. '~~~~+++~~~~' forces the modem into command mode, 'AT' Hayes attention command, 'X1' use extended result calls - enables callers baud rate to be returned in the form 'CONNECT 1200' etc.,'S0=1' answer incoming calls after 1 ring, 'S24=5' WS3000 modem specific - scans the baud rates in 5 second steps to determine the callers baud rate. Hang-up.......~~~~+++~~~~AT H0 | The string required to hang-up the modem. The first '~~~~' pauses for 2 seconds, '+++' forces the modem into command mode, '~~~~' another 2 second delay, 'AT' the Hayes attention command, 'H0'the hang-up command, '|' the terminating carriage return. Answer Mode......Hardware Used to indicate whether Hardware or Software answering is to be used. Answer Call......ATA | Used to force the modem to answer a call - Software answering only. Ring Message......RING The string returned by your modem when it detects a ring on the line (Default: RING). Make sure your modem does return RING - At least one modem returned just 'NG'! To check, put your system in Modem mode and get someone to call your number and make sure you are getting the RING string from the modem - Software answering only. Ring Count.....2 This is the ring count after which the software is to answer the call. (Default: 2) - Software answering only Connect Time.....40 This is the maximum time, in seconds, for which EaziHost waits for a connection after the call has been answered. Make sure this is long enough to allow for a connection at all speeds which your modem supports and all possible error correction negotiation possibilities where applicable. Do not make this period too long because no other calls can be answered within this time. As a good guide to the time required for your modem - Go into Modem mode and type ATA followed by RETURN and time how long it takes for your modem to give up trying for a connection. Make 'Connect Time' one step higher than this. (Default: 40) - Software answering only. Command OK....OK The string returned by the modem if a command is understood and executed correctly. This is usually 'OK'. Connect 300....CONNECT^M Connect 1200...CONNECT 1200 etc... These are the strings returned by the modem when it makes a successful connection at each baud rate. Each baud rate which your modem supports MUST be filled in - any which it does not support may be left blank. Note:It is important that your modem raises DCD immediately a connection is established. If the 7200, 12000 or 14400 rates are supported by your modem you MUST operate your modem and EaziHost in fixed DTE mode (particularly where 12000 is concerned). Note: '^M' or '|' may be used in a connect string to represent a carriage return. This is important where a modem returns a simple 'CONNECT' string for a 300 baud connection. The '^M' must be added to prevent 'CONNECT' from being confused with the 'CONNECT' part of the longer connect strings issued for other baud rates. Optional Utilities External programs may be installed for use from within EaziHost by filling in the following fields: Editor Path EaziHost allows you to name an editor of your choice, to be invoked from the main menu and also using the Alt E command whilst on-line. Enter the full path and name of the editor here. Note: You MUST include the file name extension. Filer Path EaziHost allows you to name a file management program of your choice, to be invoked from the Utilities menu and also by using the Alt U command whilst on-line. Enter the full path and name of the program here. Note: You MUST include the file name extension. Lister Path The file listing program of your choice may be specified here. The program can be invoked from the Utilities menu and also by using the Alt U command whilst on-line. Enter the full path and name of the program here. Note: You MUST include the file name extension. Note: In the case of the Editor, Filer and Lister the '%file' system variable and the trailing semi-colon (;) are supported. If the '%file' variable is appended to the full program path name, separated from it by a space character, a file name is requested from the user to be passed as a parameter to the external program. If [ENTER] is pressed without any input, the external program is invoked and no filename parameter is passed. If [ESC] is pressed then a file window is opened for the user to interactively select a file. If [ESC] is pressed at this stage then the command is aborted. If semi-colon is appended to the full program path name including any optional '%file' variable, then the external program will pause on termination until a key is pressed - rather like the Utility menu's Command option. Example: C:\EAZIEDIT.EXE %FILE Here a file name would be prompted for and passed to EAZIEDIT. Host Mode EaziHost's environment and mode of operation is controlled by the following fields: +------------------------| Host Mode |------------------------+ | Board Identity : SAND | | Host Main Path : C:\EAZIHOST\HOSTMAIN | | Host Message Path : C:\EAZIHOST\HOSTMESS | | Host Download Path : C:\EAZIHOST\HOSTDOWN | | Host Upload Path : C:\EAZIHOST\HOSTUP | | Protocol Path : C:\EAZIHOST\XFER | | Sysop's Name : SYSOP NAME | | Sysop Password : SYSOP PASS | | Log Host Calls : Yes | | Default Chat ON : Yes | | Open System : Yes | | Speed Scanning : Yes | | Baud Rate : 1200 | | Fix DTE Rate : No | +-------------------------------------------------------------+ Board Identity A field of up to 6 characters chosen by the Sysop to enable mailbags to be identified as being from his own particular EaziHost board. Be sure to use only characters valid in DOS file names. (NOTE the points made below) IMPORTANT - This field must be left blank to enable David Foster's original offline mailer to be used with the board. Fill in this field only if you require callers to use David's new mailer written specifically for EaziHost v2.x. When this field is left blank the mailbag is called MAILBAG.MSG as in previous versions of EaziHost. If the new mailer is in use and this field is filled in, it changes the name of the mailbag file thus enabling the sysop to give mailbags from/to his board a unique name. This helps callers to avoid mix-ups when he/she uses mailbags from several EaziHost boards. Suppose, for example, you chose the identity 'SAND', then the mailbag into which a caller's messages, bulletins etc. would be collected would be called 'SAND-D.MSG' rather than 'MAILBAG.MSG'. The '-D' is added by EaziHost to identify the mailbag as a download mailbag in order to differentiate it from an upload, or reply, mailbag which would be called 'SAND-U.MSG' or .ZIP etc. All other operations on the mailbag would be performed on the newly defined 'SAND-D.MSG' rather than the now redundant 'MAILBAG.MSG'. NOTE: Remember to change the name in your 'BATCH.BAT' file from mailbag to your board's new mailbag name, or mailbag compression will not work. When a caller attempts to upload a reply mailbag under the new system, he is given the name of the mailbag and only asked to add the file name extension thus: Add file extension: SAND-U. This helps to ensure that callers don't make mistakes in naming upload mailbags. Host Main Path This is the main Host path where EaziHost system files, logos etc. are stored. Host Message Path This is where the files containing the text of messages are stored. (Default used for single message area set-up) Host Download Path This is where you should put files which you wish to make available to callers if you do not intend to make use of multiple download areas. (Default used for single file area set-up) Host Upload Path This is where files uploaded by callers will be stored. Unless overridden as described later. Protocol Path This is where EaziHost looks for the external file transfer protocol drivers. This path may be overridden by full path name entries in the EAZIHOST.PRO protocol definition file, but there is no real advantage in doing so. The default is the main EaziHost directory. Sysop's Name The Sysop must enter his/her name here. First and last name only - exactly as you will enter your name when logging onto EaziHost. Any messages from users addressed to the 'Sysop' and log-off messages will then be directed to you. Sysop Password This is a special password which gives full access to the host mode and also gives the remote caller access to the DOS shell on your machine - BE VERY CAREFUL who you give this password to. Log Host Calls This setting determines whether incoming calls are to be logged in HOST.LOG. HOST.LOG is created automatically in the main EaziHost directory. If turned on, the log file will record details of each callers online session. Information includes the name of the caller, the date and time when the connection was made, uploads, downloads and duration of the call. If the configuration is saved with this option turned on, then EaziHost will automatically open the log at start-up and close it at program termination. If HOST.LOG already exists, information is appended to previous log entries. Example log entries: * Host Log Opened: Tuesday January 23, 1990 1:49 p.m. | JOHN SMITH | 2400 BAUD | Download | [Z] TEST.ZIP | Upload | [Z] FILE.ZIP
| Elapsed Time | 00:23:06 - GOODBYE * Log Closed Note: The letter on square brackets, [Z], indicates the protocol used, the
indicates that the upload was made to the private
directory, GOODBYE indicates a normal log-off - NO CARRIER would
indicate a dropped line.
Open System
If this is set to 'YES' then any caller will be given access to
EaziHost provided they complete the log-on sequence correctly.
Otherwise only callers previously logged by the system operator
(Sysop) will be given access.
Speed Scanning
If your modem supports speed scanning in auto-answer mode and you
have initialised your modem, in the 'Auto Answer' string, to use
it then this should be set to 'YES'. If callers are to contact
EaziHost at a single set speed then set this option to 'NO' and
set the selected baud rate in the field described below. EaziHost
will then assume a connection is established when a carrier
signal is detected rather than upon receipt of a connect string
from the modem.
Baud Rate
This is the baud rate to which the comms port will be set each
time EaziHost resets itself ready for a caller. This setting may
be relevant whether you are are speed scanning or not. If you
are speed scanning this will usually need to be the highest baud
rate which your modem supports. Check your modem manual to see
which baud rate to set here.
Fix DTE Rate
Some modems can be set to fix the computer port rate and handle
speed buffering between the actual line baud rate and the fixed
port rate. If you have such a modem and have included the
command in the Init string to hold the DTE (computer port) speed
then you must set this configuration field to 'Yes' to prevent
EaziHost from resetting the port rate - otherwise leave this
field set to 'No'. Note: This setting determines whether
EaziHost uses CTS handshaking with the local modem. (see General
Overview later).
Colour
Set the general display colour, window contents colour and window
frame colour by selection from the displayed foreground and
background colours. Each are set in turn as indicated by the
prompt above the sample window. The menu border style can also
be changed using the 'Y' and 'Z' options.
Alarm
The rather strident alarm which is sounded when incoming calls
are connected can be disables using this option. The bell which
accompanies error messages is not affected.
Quit
Return to the main EaziHost menu.
SYSTEM VARIABLES
Certain system variables, starting with a '%' character are
supported within EaziHost. These variables may be used in file
transfer definitions or host menus and display files and are
replaced as follows:
%Port
Replaced by the current comms port number.
%Parity
Replaced by the current parity, represented by a single upper
case character 'N' (none), 'O' (odd), 'E' (even).
%Speed
DTE baud rate. (or 'LOCAL' if log-in is local & not used in a
file transfer)
%LineSpeed
Line baud rate. (or 'LOCAL' if log-in is local & not used in a
file transfer)
%Cts
A single upper case letter indicating whether CTS handshaking is
being used between DTE and modem - 'Y'es or 'N'o.
%Ansi
A single upper case letter indicating whether ANSI displays are
in operation - 'Y' yes or 'N' no.
%HotKey
A single upper case letter indicating whether the Hot-key option
is in operation - 'Y' yes, or 'N' no.
%Expert
A single upper case letter indicating whether the short expert
menus are in operation - 'Y' yes, or 'N' no.
%First
Current caller's first name.
%Last
Current caller's last name.
%Password
Current caller's password.
%Ver
Replaced by the software ID and version number in the form 'EH20'
%Reg
Replaced by 'Y' if EaziHost is registered - Otherwise 'N'.
%Id
Replaced by the board identity set in the configuration section's
'Board Identity' field.
%Level
Replaced by a single digit (0..9) representing the current
callers validation level.
%NewUser
Replaced by 'Y' if the caller is a new user, Otherwise 'N'.
%Sysop
Replaced by the letter 'Y' if the current caller used the Sysop's
password to log-on. Otherwise 'N'.
%TimeLeft
Replaced by the online time left for the current caller, in
minutes, or by the string 'UNLIMITED' If the caller has no limit.
%DateLastOn
Date the caller was last on the board in the form 'dd-mm-yy' -
e.g. 09-08-89.
%TimeLastOn
Time the caller was last on the board in the form 'hh:mm' (24
hour clock) - e.g. 20:16
%Arc
The name of an archive file (used in VIEWS.HST).
%Path
Replaced by the current path. This can be useful in file
transfer definitions within EAZIHOST.PRO. EaziHost always logs
onto the file path where it wants incoming files to be stored
immediately prior to starting the file transfer.
%File
The name of a text file within an archive (used in VIEWS.HST) or
to represent a file to be up/downloaded, edited etc.
%MessAreaNumber
Replaced by the current message area number.
%MessAreaTitle
Replaced by the current message area title.
%MessAreaPath
Replaced by the current message area path. If no 'MESSAGES.HST'
exists it is replaced by nothing.
%MessageCount
Number of messages in the current message base.
%MessAreaUpdate
Replaced by 'Y' if the MESSAGES.HST file area list has been
updated since the user's last call - Otherwise replaced by 'N'.
(Returns 'N' if no MESSAGES.HST is defined)
%AreaPath
Replaced by the current download path. If no 'FILES.HST' exists
it is replaced by nothing.
AreaNumber
Replaced by the number of the current file download area.
%AreaTitle
Title of the current file download area.
%SysopName
Replaced by the Sysop'd name as defined in the configuration.
%Home, %Hostup, %Xfer
Replaced by the EaziHost base directory (where EAZIHOST.EXE is
located), the 'Upload Path' and 'Protocol Path', repectively.
SYSTEM.HST
Whenever EaziHost shells out, for example to run a door program,
a file called 'SYSTEM.HST' is automatically created in the 'Host
Main Path'. This file may be used by door writers who wish to
obtain information about the current caller or the state of the
board at the moment of shell-out.
SYSTEM.HST is created or updated by EaziHost each time a caller
logs in. It is automatically updated whenever appropriate.
SYSTEM.HST contains all the information which can be obtained via
the '%' system variables, and is provided as an alternative way
for door programs to obtain information about the current caller.
For example, EAZICD gets it's information from this file. The
'SYSTEM.HST' file is always created in the 'Host Main Path' and
has the following format and typical contents.
VER EH20
REG Y
ID SAND
LINESPEED 2400
SPEED 9600
PORT 1
PARITY N
CTS N
SYSOP N
ANSI Y
HOTKEY N
EXPERT N
LEVEL 5
NEWUSER N
FIRST John
LAST Smith
PASSWORD WARLORD
TIMELEFT 65
DATELASTON 21-12-89
TIMELASTON 16:12
ARC
FILE
PATH C:\EAZIHOST\SHARE
MESSAREAPATH C:\EAZIHOST\GENMESS
MESSAREANUMBER 1
MESSAREATITLE ^C33General Messages - Public access.^C0
MESSAGECOUNT 94
MESSAREAUPDATE N
AREAPATH C:\EAZIHOST\SHARE
AREANUMBER 1
AREATITLE ^C33Shareware files - Public access.^C0
SYSOPNAME MICHAEL OPACIC
HOME C:\EAZIHOST
HOSTUP C:\EAZIHOST\HOSTUP
XFER C:\EAZIHOST\XFER
Note that each line consists of an upper case system variable
name without the '%' prefix, followed by a space and then the
current value. Some values may be blank if no values have been
assigned to them - for example MESSAREATITLE would be blank if no
'MESSAGES.HST' file was defined. If you write doors which refer
to SYSTEM.HST for information DO NOT rely on the order of the
lines remaining the same between EaziHost versions - always check
the first field to identify the variable first and then the
second field for it's content.
Please note that SYSTEM.HST remains intact until another caller
successfully logs on. A program invoked by RECYCLE.BAT could
pick up details of the last caller from SYSTEM.HST if required.
Note: RECYCLE.BAT is only run on termination of a SUCCESSFUL log-
on.
Note: DSZ does not accept a root path in the form 'A:\', as
passed by the %path variable, and DOS's CD command, as valid. It
will only accept a path without a trailing '\'. You must use
upload and download paths which are not root paths if you intend
to use %path in a DSZ protocol definition, within EAZIHOST.PRO.
For example If you wish to direct downloads to floppy drive 'A' -
make the path 'A:\DOWNLOADS' and %path will direct downloads
correctly.
Note: %Speed and %LineSpeed can return different values if a
fixed DTE is being used with a speed buffered modem. To return
correct line speed the CONNECT messages must be correct in the
configuration section and 'Speed Scanning' MUST be set to 'Y'es.
Protocol main baud rates must be passed via the %Speed variable.
If a protocol allows an additional 'actual line speed' baud rate
to be passed to it for use in estimating file transfer times.
%LineSpeed can be used for that purpose on fixed DTE systems.
A GENERAL OVERVIEW
EaziHost provides powerful BBS facilities. Callers can log-on by
entering their name and password. Users can elect to use simple
TELETYPE or full colour ANSI-BBS terminal emulation. Users
calling the host mode must do so with their communications
package set for 8 DATA BITS, NO PARITY, 1 STOP BIT (8-N-1) and
Xon/Xoff handshaking. Baud rate may be any rate which the host
modem can scan for and detect. EaziHost expects extended reply
strings like 'CONNECT 1200' to be returned by the modem when a
connection is made. EaziHost also requires the carrier detect
pin to be raised when a carrier signal is detected.
IMPORTANT: EaziHost itself ALWAYS uses Xon/Xoff software
handshaking downline with the caller. If the 'Fix DTE Rate'
field of the configuration section is set to 'Yes', CTS hardware
handshaking is also used between DTE and the modem. If you are
using a modem which uses a fixed DTE baud rate and speed buffers
down to a caller's line speed, you MUST set your modem up to use
CTS handshaking with the DTE - raising CTS when the modem is
ready to accept more data from the DTE and lowering it when the
modem's buffer is full. This ensures that such speed buffered
modems do not suffer buffer overflow and lose data. With all
modems you must set them up to allow Xon/Xoff flow control
characters to pass through the modem freely without being acted
upon by the modem - Xon/Xoff handshaking between modem and DTE
must be turned OFF. With simpler modems, where 'Fix DTE Rate' is
set to 'No', EaziHost uses Xon/Xoff handshaking directly between
the two sites in the normal way and CTS plays no part.
If the carrier signal is lost during communication, provided that
the remote user is not currently in the host machines DOS shell
or a type 2 door which has not been written to recover under
control, EaziHost will automatically recycle and wait for the
next call. EaziHost has it's own carrier watch built-in. If the
remote caller is in a door without it's own carrier monitoring,
or has used the Sysop password to enter the DOS shell and the
carrier is lost, EaziHost will recover by carrying out a soft re-
boot. To force EaziHost to go back on-line in host mode after a
carrier loss re-boot either use 'EAZIHOST /H' in your
AUTOEXEC.BAT file on your hard disk or put a specially prepared
system disk in drive A: with the required AUTOEXEC.BAT and
CONFIG.SYS files etc. on it. No external carrier watch program
is needed if you set up the system as directed. EaziHost should
be able to recover in all carrier loss situations.
The host mode incorporates multiple message bases, doors, news
bulletins, archive viewing, multiple file areas with file
upload/download facilities and an on-line chat feature. Messages
can be posted to any other user on the system or to all users,
They may be marked private if desired, in which case only the
named recipient and the original sender may read them. When a
user logs on, he is informed of the presence of any new messages
addressed to him, which he has not yet read. Where such messages
exist the user is given the option of reading them immediately.
A caller may elect to collect new messages from one or all
message areas and bulk download them for reading off-line.
Please note that the 'Host Download Path' and 'Host Message Path'
are made redundant if you elect to set up multiple file or
message areas. Please note that some protocols which allow paths
to be specified during uploading can be dangerous. For example
if a user uploaded a file called 'C:\CONFIG.SYS' it could over-
write your config file even though you have set up a separate
'Host Upload Path'. A system variable '%path' has been
introduced to help in some such cases. The '%path' variable is
replaced by the current path. In EaziHost the receiving path is
made current immediately prior to file transfer. The '%path'
variable can thus be used to good effect to override incoming
path specifications.
EaziHost uses the computers time and date system to date stamp
messages and keep track of a callers last time on. Always make
sure the time and date are set correctly before using EaziHost.
IMPORTANT: The remote use of the host shell and doors type 2 rely
on DOS I/O redirection for their operation. These mechanisms
will therefore only work with communication ports supported by
DOS itself - i.e. generally ports 1 and 2. If you configure
EaziHost to work on port 3 or 4 it will function fully in all
other respects.
System Errors
Any system errors generated by EaziHost, i.e. those preceded by
the words 'SYSTEM ERROR' are automatically logged in a file
called SYSTEM.ERR in the 'Host Main Path' directory. This makes
it easier for the Sysop to track down errors which have occurred
in his absence.
The general form of entries in in SYSTEM.ERR is as follows:
EAZIHOST 23-01-90 Failed to create PCBOARD.SYS!
EAZIHOST 24-01-90 C:\EAZIHOST\GENMESS\134.MSG - Not found!
PROGRAM FILES
In addition to the files supplied in the distribution package,
the following files are either generated by EaziHost or may be
optionally created by the Sysop for various purposes:
HOST.LOG Host caller log file (Generated by program)
USER.HST The user list file. (Generated by program)
LOGO.HST Host opening logo. (Generated by user)
NOTICE.HST Special notice screen. (Generated by user)
LOGOFF.HST Special log-off screen. (Generated by user)
NEWUSER.HST Special New User text. (Generated by user)
WELCOME.TXT Teletype welcome screen. (Generated by user)
WELCOME.ANS ANSI welcome screen. (Generated by user)
FILELOGO.TXT Teletype file area logo. (Generated by user)
FILELOGO.ANS ANSI file area logo. (Generated by user)
MESSLOGO.TXT Teletype message area logo. (Generated by user)
MESSLOGO.ANS ANSI message area logo. (Generated by user)
XXXXXXXX.XXX File descriptions. (Generated by user)
MESSAGE.IDX Message base index files. (Generated by program)
n.MSG Message texts (n = number) (Generated by program)
RECYCLE.BAT File to be run on recycle. (Generated by user)
BATCH.BAT Compresses the mailbag. (Generated by user)
COLOUR.HST Colour translation table. (Generated by user)
TIMES.HST Caller time limits. (Generated by user)
MAILBAG.MSG Message mailbag. (Generated by program)
FILES.HST File area definitions. (Generated by user)
MESSAGES.HST Message area definitions. (Generated by user)
DOORS.HST Main Door definitions. (Generated by user)
ENTRY1.HST First entry door. (Generated by user)
ENTRY2.HST Second entry door. (Generated by user)
EXIT1.HST First exit door. (Generated by user)
EXIT2.HST Second exit door. (Generated by user)
FILE.UTL File area 'X'tra doors. (Generated by user)
MESSAGE.UTL Message area 'X'tra doors. (Generated by user)
SYSTEM.HST Current system details. (Generated by program)
LOCAL.EDT Optional Local editor. (Generated by user)
Please note that all files marked (Generated by user) are
optional and need not exist for the EaziHost to function. Where
the user chooses to create these files they must be in the 'Host
Main Path' directory. The 'MESSAGE.IDX' files and 'n.MSG' files
are automatically created in the appropriate message area's
directory and are maintained directly by EaziHost. The HOST.LOG
file, if activated, is created and updated in the main EaziHost
directory (NOT the 'Host Main Path'). If RECYCLE.BAT exists in
the 'Host Main Path' it is run each time EaziHost recycles ready
for the next call. The '.MNU' and '.HLP' files supplied with
EaziHost must be located in the 'Host Main Path' - they are the
menus and help screens displayed to callers.
The ANSI Editor
The file ANSIED.EXE is EaziHost's full-screen ANSI editor.
Callers who's comms package supports ANSI may choose this editor
rather than the basic line editor, for posting or replying to
messages. Editors are selected on a callers first log-on and, at
any other time, via the (F)ullEditor option on the (O)ptions menu
as described later. Callers may choose from three levels of ANSI
emulation to suit their communication program's capabilities.
They range from a full ANSI editor which requires a high degree
of ANSI emulation, down to a simple but slower version which
requires only a PC ANSI.SYS level of emulation. The intermediate
level was introduced to cope with certain idiosyncrasies of
Procomm Plus (tm). For maximum compatibility, a WordStar style
set of control keys are supported to facilitate movement within
the editor - more capable packages will also support the
following IBM keys:
Cursor Left, Right, Up, Down, HOME (Start of line), END (End of
line), TAB, BACKSPACE & DEL.
To save on completion, or abort the message press '^KD' and
indicate the appropriate action. The editor word-wraps during
text entry. If text is inserted into a line, the text will not be
allowed to move to the right beyond the 75 character limit. Two
adjacent lines can be wrap-joined together, where possible, by
placing the cursor on the first character of the second line and
pressing Backspace or by placing the cursor after the last
character on the first line and pressing Del. As many full words
as possible from the start of the second line, will be appended
to the end of the first.
Although packages like EaziLink and Telix will drive the High
level ANSI version of the editor perfectly, not all packages with
ANSI capability will do so. Callers will have to experiment to
find the most suitable version for them.
Since they can respond to a large number of movement control
characters, full-screen editors are particularly susceptible to
line noise which can really mess things up. If a caller has
consistently poor lines he would be best advised to revert to the
simpler line editor.
A number of 'Refresh' commands are provided to enable a caller to
clean up the display if line noise has messed things up. The
caller can thus see what text the editor actually contains rather
than what it appears to contain ('^' represents the CTRL key).
^W Refreshes the whole screen.
^T Refreshes all text in the editing window.
^L Refreshes text on the current line only.
ANSIED.EXE, like CONFIG.EXE, should be considered to be an
integral part of EaziHost and must be present in the main
EaziHost directory where EAZIHOST.EXE is located.
SPECIAL CODES
In some cases two separate files with the same name but different
extensions, '.ANS' and '.TXT', need to be created if you want
both ANSI and TELETYPE users to receive an appropriate screen
display. Where this is so, it is mentioned in the 'SETTING UP
EAZIHOST' section. The special codes described below may be used
in the '.TXT' variant of such files but must NOT be used in true
'.ANS' files.
With the exception of 'LOGO.HST' the text files with the
extensions '.TXT' or '.HST' may contain system variables,
described in the 'SYSTEM VARIABLES' section, and special codes,
prefixed with the '^' symbol, to add colour and other special
effects. Since these codes play a major part in the appearance
of the host mode they will be described in detail before we
discuss the setting up of the host mode proper. Such variables
and codes must NOT be used in LOGO.HST because it is shown before
the caller actually logs-on and no caller details are known at
that point.
Special codes are prefixed by the '^' symbol. Here are the non-
colour related codes:
^^ DISPLAY THE ^ CHARACTER ITSELF
^G RING BELL
^I TAB
^M RETURN
^J LINE-FEED
^L CLEAR-SCREEN
^H BACKSPACE-DELETE
^P Pause for [RETURN] to be pressed.
^Z A special code used only in menus - described in the
'SETTING UP HOST MODE' section later.
^A All following text in the same line is sent only to ANSI
users - another ^A will cancel.
^T All following text in the same line is sent only to TTY
users - another ^T will cancel.
^Dnn This command introduces a delay between characters of
'nn' 1/100ths of a second for all following characters in
the same line of text. A ^D0, or the line end, cancels
the delay. The range for 'nn' is 0..99.
In the case of '^A', '^T' and '^Dnn', the switch only affects the
current line of text - it is automatically cancelled at the end
of the line.
Examples:
"Hello %first,
I see you have ^T not^T chosen to receive ANSI colour screens
etc..."
Only TTY users would see the 'not' in the above text.
"Hello %first,
^D10The EaziHost^D15^H^H^H^H^H^H^H^H^D10EAZIHOST BBS..."
The above text would be slowly displayed as if being typed live.
After 'EaziHost' is displayed the speed drops even more as the
word is deleted and replaced with 'EAZIHOST' in capital letters.
The '^P' code should be read as 'wait for return to be pressed'
note that it is left up to the Sysop to ensure that a suitable
message is embedded in the text. For example if the following
line is the first line of one of the .MNU files:
^C36Press:^C1^C33 [RETURN]...^C0^P^L
(menu text here...)
The message 'Press: [RETURN]...' will be displayed and the '^P'
will wait for RETURN to be pressed. The '^L' clears the screen
before the menu itself is displayed. If you wish to remove the
prompt rather than clear the screen you can use '^H' control
codes to delete each character of the prompt like this:
^C36Press:^C1^C33
[RETURN]...^C0^P^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H
Note that a '^H' is required only for each character which is
actually displayed - not for the control sequence characters like
'^C36'.
The '^P' control code is particularly useful where deep menus
have been created by the Sysop. It can be used to ensure that
information on the screen is not scrolled off the top by a deep
menu, before the caller has had time to read it.
The special codes used to generate colours are in the form
'^Cnn'. These codes are ignored by the TELETYPE driver thus they
can be used freely in any text which is to be shown to ANSI and
TELETYPE users alike. The sequence '^Cnn' turns the ANSI colour
or effect 'nn' on. The 'nn' is a one or two digit standard ANSI
number required for the chosen colour or effect as listed below:
ANSI values
0 Normal default 1 High intensity
5 Blink on 7 Reverse video
8 Concealed 30 Black foreground
31 Red foreground 32 Green foreground
33 Yellow foreground 34 Blue foreground
35 Magenta foreground 36 Cyan foreground
37 White foreground 40 Black background
41 Red background 42 Green background
43 Yellow background 44 Blue background
45 Magenta background 46 Cyan background
47 White background
For example, a 'XXXXXXXX.XXX' file description line:
^C1^C33EAZIHOST.ZIP^C35 A new British BBS package.^C0
would display the file name in high intensity yellow and the
description in high intensity cyan. The ^C0 at the end sets
colour back to default - don't leave it out!
The above line would appear coloured to ANSI users and normal
monochrome to TELETYPE users.
Note: If a special code sequence requires only a single digit
value and the next proper text character is a digit - e.g.
'^C180386 chip details.', pre-fix the special code value with a
'0' to make it two digits long - thus making it '^C0180386 chip
details.' instead. This will prevent the system from associating
the text digit, 8 in the above example, with the special code.
SETTING UP EAZIHOST
EaziHost can be set up to be as simple or as complex as the Sysop
wishes - many of the features are optional. In it's simplest
form, EaziHost offers just one download file area and one message
area - i.e. the directories specified in the configuration's host
mode section. News bulletins, doors, file viewing facilities,
mailbag archiving, recycle operations etc. need not be defined.
Members Only!
If multiple download or message areas are to be offered, in
addition to the basic access level restrictions, 'Members Only'
status may be assigned to any area in FILES.HST or MESSAGES.HST.
This membership scheme works as follows:
If a file area or message area is to have access to it restricted
to a specific list of callers, the Sysop may create such a list
in the 'Host Main Path' directory. Any number of such lists may
be created and linked with any file or message area. The list of
area 'members' takes the form of a simple text file with the
first and last name of each member on each line. For example you
might create a membership list called 'TOPUSER.LST' thus:
JOHN SMITH
JOE SOAP
FRED BLOGGS
If this membership list is associated with a file download area
or message area, only those users listed will have access to that
area. Membership lists are associated with particular message
and file areas via a 'MEMBER_LIST' field in FILES.HST and
MESSAGES.HST described later.
The MEMBER_LIST field may be left empty, in which case all users
will be considered members and will have access to the area
provided that their access level is high enough. If a
MEMBER_LIST entry is included it must be in the form of a short
file name and extension. No drive or path elements are allowed.
Remember that the membership list itself must be located in the
'Host Main Path'. Even if the MEMBER_LIST field is left empty,
the semi-colon must be included.
If a user is not a file or message area member he will not be
able to see or download any of the files or read or send any
messages. If membership of an area is open a caller's access to
an area is restricted by access level, in the normal way.
Note: The first two fields only in a membership list are checked
for a match with a users name. Door writers should note that
other fields may be added, separated from each other by a space
for use by doors written to look for the extra fields. For
example a list like this may be created:
JOHN SMITH
JOE SOAP SS
FRED BLOGGS
Where the 'SS' after JOE SOAP may perhaps signify Sub-Sysop
status to a special door program written to enable members to be
added or deleted from a membership list by a selected user (JOE
SOAP in this case).
The 'SS' field does not interfere with EaziHost's ability to
match the name on the list.
Note: IF a membership list is used to control access to a file or
message area, it generally makes most sense to give that area an
access level of 0 to ensure that a member of the area is not
denied access because their validation level is too low.
The Optional Features
If a full featured host mode is required the following facilities
may be made available to callers:
News Bulletins
Up to 16 news items may be defined in a file called NEWS.HST.
This file must be in the 'Host Main Path' directory as must each
news text file. Each news item entry in NEWS.HST must consist of
a single line of the following form:
FILENAME.EXT; TITLE; l
Where FILENAME can be any name and EXT any extension. If EXT is
not included then .NWS is assumed. Note: Path names must NOT be
included. The TITLE is the news item's title to appear on-screen.
TITLE can be up to 60 characters long and may contain '^' special
codes as may the news bulletin itself. The 'l' represents a
single character - either 'Y' or 'N'. This should be set to 'Y'
if special '^' codes or '%...' system variables have been used in
the text of the news item - otherwise enter 'N' to indicate a
standard ascii file. The 'N' switch option has been provided to
enable the Sysop to get an ascii file from any source and offer
it as a news bulletin without having to check that no '^'
characters exist in the file, which would otherwise be
interpreted by EaziHost as special control codes.
Example NEWS.HST file:
HISTORY.NWS; ^C32Full EaziHost release history.^C0;Y
LATEST.NWS; ^C32Latest EaziHost V2.2.^C0;Y
The titles would be displayed in green (^C32). The news files
HISTORY.NWS and LATEST.NWS must be in the 'Host Main Path'
directory. These text files may also contain '^ ' special codes
and system variables (use the 'Y' switch), or may be plain ascii
files (use the 'N' switch). The two ';' field separators must be
present - one or more spaces may be located before or after them
if desired.
Note: NEWS.HST may be edited from within host mode itself but you
MUST drop back into EaziHost's main menu and enter host mode
again before any changes will take effect.
Multiple Download Areas
Up to 64 separate download file areas can be defined in a file
called FILES.HST. This file must be located in the 'Host Main
Path' directory. If it does not exist then the 'Host Down Path'
in the configuration section will be the download path made
available. The FILES.HST file is a normal ASCII file in which
each line represents a separate download directory - the form of
each entry is as follows:
FULL_PATH_NAME; n; TITLE; MEMBER_LIST; LOGO; l
Where 'FULL_PATH_NAME' is the directory where the group of files
is to be found, 'n' is the access level required to download from
the directory and 'TITLE' is a file area description of up to 60
characters, to be displayed to callers - the '^' control codes
may be used in 'TITLE'. 'MEMBER_LIST' is an optional membership
list used to control a callers access to an area - see the
earlier section entitled 'Members Only!' for full details.
'LOGO' is the optional name of a logo file to be displayed on
entry to that particular file area. The 'LOGO' field may be left
empty if no logo is required BUT the third field separator MUST
be present. Please note that the 'LOGO' field must be a simple
file name only (up to 8 characters Max.) without an extension.
EaziHost adds the extension .ANS or .TXT as appropriate - the
Sysop may create two files for ANSI and TELETYPE users. The logo
files must be located in the 'Host Main Path' directory. The 'l'
field is a single letter - either 'Y' or 'N'. This indicates
whether the logo is to be displayed every time a caller enters
that particular download area. If set to 'N' the logo will only
be displayed the first time a caller enters that file area in any
one on-line connection. As in the case of the 'LOGO' field, the
'l' field may be left empty but the fourth ';' must be present.
If 'l' is empty but 'LOGO' is not, then a default 'l' of 'N' is
assumed.
Example FILES.HST file:
C:\EAZIHOST\SHARE; 0; General Shareware.; ; GENLOGO; Y
C:\EAZIHOST\REG; 5; Registered users.; ;REGLOGO; Y
C:\EAZIHOST\PRIVATE; 0; Private area - no access.; PRIVLIST.LST;;
In this example any user can have download access to the first
area. Only users with an access level of 5 or over may download
from the second area. Only users included on the membership list
'PRIVLIST.LST' can see or download files from the third area. The
five ';' field separators must be present - one or more spaces
may be located before or after them if desired.
Note: All new users are automatically give an access level of 0.
The Sysop could encourage users, via NEWUSER.HST, to leave a
message requesting upgrade.
If full descriptions of download files are to be provided for
callers, each file area directory should have within it a text
file called 'XXXXXXXX.XXX' which contains one line per file name
and description. This file is a standard ascii file, created by
the Sysop, and may contain the special '^' control codes. The
XXXXXXXX.XXX file is ignored by the (W)ide option (as is
XXXXXXX.BAK) and will not be seen by users even though it is
amongst the download files. When (L)ist is used the contents of
the XXXXXXXX.XXX file in the current download file area is
displayed to the caller.
Callers can move between file areas via the (A)rea option on the
file menu. If no file areas are defined then the single default
file area logo, if it has been created, is FILELOGO.ANS/TXT.
When separate file areas are defined each may be assigned it's
own logo named in each entry's 'LOGO' field in FILES.HST as
detailed above. All such logos must be located in the 'Host Main
Path' directory.
Note: FILES.HST may be edited from within host mode itself but
you MUST drop back into EaziHost's main menu and enter host mode
again before any changes will take effect.
Separate Upload Areas
Uploads from callers are normally sent to the 'Host Upload Path'
defined in the configuration section. Uploads can however, be
directed to individual upload areas.
If the caller is in a file download area in which the Sysop has
created a local sub-directory called 'UPLOADS', the upload will
go into that UPLOADS directory rather than into the default 'Host
Upload Path'.
If the caller indicates that the upload is Private, then if the
local 'UPLOADS' subdirectory exists, the file is sent to a
directory called PRIVATE off the local 'UPLOADS' directory. In
other cases the 'Host Upload Path' and PRIVATE subdirectory off
it is used. In all cases, if the PRIVATE directories do not
exist, EaziHost creates them as and when they are required.
Multiple Message Areas
Up to 64 separate message areas can be defined in a file called
MESSAGES.HST. This file must be located in the 'Host Main Path'
directory. If it does not exist then the 'Host Message Path' in
the configuration section will be the only message area
available. The MESSAGES.HST file is a normal ASCII file in which
each line represents a separate message area - the form of each
entry is as follows:
FULL_PATH_NAME; n; TITLE; p; MEMBER_LIST; LOGO; l
Where - 'FULL_PATH_NAME' is the directory where the message base
is to be established. 'n' is the access level required to read or
post messages in that area. 'TITLE' is the message area
description to be displayed to callers (60 characters max). 'p'
is a single letter 'Y' or 'N' indicating whether users may mark
their messages as PRIVATE or not, whole message areas can made
public in this way. The optional 'MEMBER_LIST' field controls
access to the message area - see the earlier 'Member Only!'
section. If the area is designated as 'members only' then only
members may access messages in that area and the system prevents
messages from being posted in that area, addressed to users who
are not members. 'LOGO' is a logo file in 'Host Main Path' and
'l' indicates whether or not the logo is to be displayed on every
entry to that message area or not - see the FILES.HST section for
more details on the use of logos.
Note: 'n' may optionally contain 'S' instead of an access level
0..9. 'S' may only be used for one area and indicates that log-
off messages to the Sysop should always be stored in that message
area. The access level of an 'S' area is always 0 - thus any
caller can leave a log-off message to the Sysop. If no message
area is marked 'S', message area 1 is always used for log-off
messages. Please note that you should NOT assign a membership
file to the area which is to receive log-off messages to the
Sysop, nor should you assign an access level other than 0 to area
1 if 'S' is not used - full access is then available to all
callers.
Please note that all message areas are searched in the mail check
when a caller logs on, so that no messages addressed to him/her
will be missed.
Note: The Batch sub-options (A)ll and (R)ange (described fully
later) only collect messages from the CURRENT message area when
adding messages to the MAILBAG, the (N)ew option can be made to
collect from the current message area only, or from ALL message
areas defined in MESSAGES.HST, at the callers discretion.
Doors
It is possible to run external programs (doors) from EaziHost's
host mode. One of EaziHost's three types of Door mechanism is
compatible with version 12 of the PCBOARD BBS (tm) which means
that a large number of games and other Door programs written for
that system can be run from EaziHost. Another door type is
compatible with doors which require a QBBS/Remote Access style
'DORINFO1.DEF' door file The different types of Door program
which can be run from EaziHost are:
Type 1 - PCBOARD v12 compatible door programs which have their
own comms I/O built-in. Immediately before this type of door
program is run, a file PCBOARD.SYS is created in the door
program's directory. This file contains information required by
the external program. In addition the PCBOARD file, PCBOARD.DAT
must be copied into the directory where the Door program is
located. This file also contains information required by the
external program and can be obtained from a PCBOARD archive file.
Type 2 - Batch files and/or programs which use DOS I/O ONLY - the
I/O of which can be re-directed to the comms port by DOS I/O
redirection. All batch file commands can be used with this door
type as can any program which receives it's input and directs
it's output through the basic DOS functions. Programs which use
direct hardware access or BIOS calls for their I/O will NOT work
with this door type. I/O redirection is automatically handled by
EaziHost. If you want to see ANSI output locally when running
Type 2 doors in local mode, you must have the DOS device driver
ANSI.SYS installed. This does not apply to the display seen
locally when a real caller is online, which is handled by
EaziHost's internal ANSI-BBS driver.
IMPORTANT - The I/O redirection method used with type 2 doors,
would allow the DOS prompt and even the words 'ECHO OFF' to be
passed through to the caller if the door being run is a batch
file. To prevent this, EaziHost does not send any output from a
type 2 door batch file to the caller until the command 'ECHO OFF'
has been executed. It is therefore VITAL that you include the
line 'ECHO OFF' in your door type 2 batch files at a point after
which you want output to be transmitted - If you do not, no
output will be sent at all. You may exclude the 'ECHO OFF'
command if your door is carrying out some housekeeping job and
does not need to send anything to the caller during it's
operation. Just think of the batch line 'ECHO OFF' as a switch
to turn ON transmission to the caller. Note: Do NOT use the
'@ECHO OFF' variant introduced in MS-DOS 3.3, because this
'hides' the 'ECHO OFF' which prevents EaziHost from detecting it.
Please don't forget about this because such doors WILL operate
properly in local test mode without 'ECHO OFF' but NOT online.
All of this only applies to BATCH files run as TYPE 2 doors,
whether they be defined in DOORS.HST, ENTRY1.HST, ENTRY2.HST,
EXIT1.HST, EXIT2.HST or the (X)tra utility doors defined in
FILE.UTL and MESSAGE.UTL. Type 1 or 3 doors and other batch
files used by EaziHost, like RECYCLE.BAT and BATCH.BAT, are not
affected.
Type 3 - This is exactly the same as a Type 1 door but does not
generate PCBOARD.SYS. If your door program has it's own comms
I/O built-in and does not require PCBOARD.SYS or any other non-
EaziHost door information file - use a Type 3 door.
Type 4 - QBBS/Remote Access compatible doors which require
a DORINFO1.DEF file to take information from. The DORINFO1.DEF
file is automatically generated by EaziHost in the door's
directory. If used in conjunction with TeleLink Software's
DoorMaster (tm) program, the type 4 door mechanism can be used to
run doors originally designed for PCBOARD v14, Wildcat, QBBS,
Remote Access, RBBS etc.
Note: Type 2 Doors should only be provided if you are using a
communications port supported by your version of DOS - usually
restricted to port 1 or 2.
Up to 16 Doors can be defined in a special file DOORS.HST which
must be located in the 'Host Main Path' directory. Any of the 16
entries may, optionally, be a pointer to another list of 16 doors
making it possible to define up to 240 doors. DOORS.HST is a
standard ascii file containing one definition per line with the
following structure:
n; l; t; TITLE; FULL_PATH_NAME
The 'n' is a single digit, 0..9, representing the access level
required to run the Door. The 'l' is a letter 'Y' (Yes) or 'N'
(No) which indicates whether EaziHost's built-in soft re-boot
recovery should be employed if the line drops whilst a door is in
use. The 't' indicates which Door type the program requires (1
to 3). 'TITLE' is the name of the Door program to be displayed
to the caller (60 chars Max.). 'FULL_PATH_NAME' is the full file
name, and must include drive, path, file name, filename extension
and parameters, of the Door program (100 chars Max). The file
name MUST include either a 'BAT', 'COM' or 'EXE' extension.
Example DOORS.HST file entry:
5; N; 1; BlackJack; C:\EAZIHOST\GAMES\PCB21V17.EXE PCB21V17.CFG
Here users with an access level of 5 or over can play BlackJack.
The 'N' indicates that the Door program monitors the carrier
itself so the EaziHost soft re-boot recovery will not be needed
if the line drops. All door file names must include the 'COM',
'EXE' or 'BAT' extension because each file type is handled
differently. Type 2 doors are always executed by the command
processor and are ideal for executing batch files which can be
written to carry out simple or very complex tasks - the
possibilities are almost unlimited.
The four ';' field separators must be present - they may have one
or more spaces on either side if desired.
Please note that immediately before a door is run, EaziHost
changes to the directory path contained in 'FULL_PATH_NAME' - if
any. Thus when the program runs it can find all it's support
files in it's own, current, directory. This is also where
PCBOARD.SYS (or DORINFO1.DEF for type 4 doors) is automatically
created and also where the Sysop should put the PCBOARD.DAT file
if the door is of type 1. The PCBOARD.SYS file is NOT created
for door types 2 and 3. The system variables can be used in a
door program parameter list to pass information from the main
board to a door program or batch file. (see: SYSTEM VARIABLES)
Door list pointers
As mentioned above any of the 16 entries in DOORS.HST may be a
pointer to another list of 16 doors. A pointer entry of this
type takes the form:
n; l; t; TITLE; DOORS.ext
Where 'n' is access level and 'l' can be either 'Y' or 'N' as it
is not used in pointer entries. Door type 't' must be set to '0'
to indicate a pointer entry. 'TITLE' will be used as the
displayed header for the secondary door list. 'DOORS.ext' must be
a simple file name without path elements and must match the file
name form 'DOORS.*' - i.e. the file name must be 'DOORS' but the
extension may be anything. The door list defined by 'DOORS.ext'
must be located in the HOSTMAIN directory. Secondary door lists
of this kind can contain normal door entries but NOT further
pointer entries.
Example door pointer entry:
0; N; 0; Games; DOORS.1
When selected, this option would display another list of doors
with the title 'Games', which have been defined in 'DOORS.1'
which must itself have been created in 'HOSTMAIN' by the Sysop.
Access level is honoured in the pointer entries just as for other
doors.
Doors & memory swapping
Some larger doors may need more memory to run in than is normally
available when shelling from EaziHost. EaziHost's code is in two
files - EAZIHOST.EXE and EAZIHOST.OV1. A large section of code,
contained in the .OV1 file, can be temporarily removed from
memory allowing about 100K of extra memory to be made available.
After the external program has terminated, the swapped out code
is re-loaded from the .OV1 file.
This memory expanding feature is always used when RECYCLE.BAT,
BATCH.BAT and the remote shell are run and can be selected for
use with door programs on a door by door basis. Doors types are
normally numbered 1..4 (type 0 is a special pointer type). To
specify that a door is to use the new memory reclaiming mechanism
you simply add 5 to the door type digit in the door definition
file - i.e:
Original Door Type Memory Reclaiming Equivalent
------------------ ----------------------------
1 6
2 7
3 8
4 9
The word 'Door' includes doors specified in DOORS.HST,
ENTRY1.HST, ENTRY2.HST, EXIT1.HST, EXIT2.HST, xxxx.UTL doors,
additional menu option doors etc. - In fact anywhere within the
EaziHost system where standard door definition lines are used to
define an external program.
Since EaziHost needs to access the .OV1 file regularly it is
important that this file is always accessible to the program.
The (X)tra Utilities
Special utility doors can be accessed from the file and message
areas, via the (X)tra option, if the Sysop creates the required
files.
Up to 16 utilities may be provided in the form of a list of
doors. These door lists are called 'FILE.UTL' and 'MESSAGE.UTL'
for use from the Files area and Message area (X)tra options,
respectively. These .UTL files, if required must be created in
the 'Host Main Path' directory. The format of the files is
identical to that of the 'DOORS.HST' file except that pointer
entries are NOT allowed.
The ENTRY Doors
Two optional files called 'ENTRY1.HST' and 'ENTRY2.HST may be
created by the Sysop in the 'Host Main Path' directory. These
files consist of a single line door definition like those used in
DOORS.HST. If ENTRY1.HST exists, the door program defined within
it is run immediately before the 'NOTICE.HST' file has been
displayed. If 'ENTRY2.HST exists, it is run immediately after
the WELCOME screen is displayed - before the mail check run.
These entrance doorways could be used, for example, to offer a
questionnaire to new users or for any other purpose for which a
door can be used. Note that the 'Title' field is not used but
must be present even though it is empty (i.e. the semicolon
separator is required). The door's access level determines
whether the door is to run for a particular caller or not, as
usual.
The EXIT doors
Exactly like the ENTRY doors above but located before and after
the prompt asking if the caller wishes to leave a message to the
Sysop at log-off.
Archive Viewing
The Host mode file section has an archive View feature. Files in
any archive may be listed and any text file within an archive can
be read, on-line, by a caller. The file menu option (V)iew
invokes external de-archiving utilities, which the Sysop must
provide. Archive types may be ARC, ZIP, PAK or any other which
becomes available. To make Viewing facilities available, a
special ascii file named 'VIEWS.HST' must be created in the 'Host
Main Path' directory. Within this file up to 5 different de-
archiving tools may be defined - one per line. The file's format
is as follows:
EXT; LIST; EXTRACT
The field 'EXT' is the 3 letter archive type's extension. The
'LIST' field contains the de-archiving utility's name and
parameters required to generate a list of files within the
archive. The 'EXTRACT' field contains the de-archiving utility's
name and parameters required to extract a single named file from
an archive. The archive file's name is included in the parameter
list by use of the %arc system variable and the text file to be
extracted (for reading) from an archive is passed in the system
variable %file. The 'LIST' and 'EXTRACT' field entries may
contain the full path names of the de-archiving tools or just the
short file name if the tools are located in a directory pointed
to by the DOS PATH command.
Example VIEWS.HST file:
ZIP; PKUNZIP/V %arc; PKUNZIP %arc %file
ARC; PKXARC/V %arc; PKXARC %arc %file
PAK; PAK v %arc; PAK e %arc %file
The two ';' field separators must be present - one or more spaces
may be located before or after them if desired. Callers
selecting the View option are prompted to enter the name of the
archive, the contents of which they wish to view. A simple short
file name without drive, path or wild card components must be
entered. If no extension is included then EaziHost will
automatically find the first matching file which has any one of
the extensions defined in the 'EXT' fields of VIEWS.HST. If for
example the caller types 'EAZIHOST' and the file 'EAZIHOST.ARC'
exists then the VIEWS.HST utility installed to deal with ARC
files will automatically be used to process the file.
Batch Message Compression
Callers may optionally fill a Mailbag with messages, news items
etc. and download it using the (B)at command. The caller's
selected items are added to a file called 'MAILBAG.MSG' which
EaziHost creates in the 'Host Main Path' directory. If the
optional file 'BATCH.BAT' has been created by the Sysop in the
'Host Main Path' directory, the caller is given the option of
compressing the mailbag - otherwise the mailbag is downloaded in
ordinary ascii form. The BATCH.BAT file only needs to contain
two command lines - one to archive the 'MAILBAG.MSG' file, and
the second to delete the original 'MAILBAG.MSG' file. It is
important to delete the original file after archiving because
EaziHost will download the first file in the 'Host Main Path'
matching 'MAILBAG.*' regardless of the extension - thus any
archiving tool may be used. This is a typical 'BATCH.BAT' file:
pkzip mailbag.zip mailbag.msg
del mailbag.msg
Note: the above example assumes that PKZIP is in a directory
pointed to by your PATH command - the 'Host Main Path' is the
current directory when 'BATCH.BAT' is run so no path
specifications are required in the batch file. ALL files
matching the mask 'MAILBAG.*' are erased from the 'Host Main
Path' whenever a caller logs on. Remember to change the name
'mailbag' to your board's special mailbag name if you are using
the 'Board Identity' field.
The first line of a downloaded mailbag will include board
identity and date information like this:
Board Identity: SAND Collected: 02-10-91
Time Limits
Daily time limits may be imposed on callers if desired. Time
limits are related to validation levels. The time allowance to
be linked to a particular access level is controlled by a file
called 'TIMES.HST' which the Sysop creates in the 'Host Main
Path' directory. If TIMES.HST does not exists ALL users are
given UNLIMITED time. If TIMES.HST did exist but it has been
deleted to give UNLIMITED time allowances to all, run the
supplied SETTIMES utility to correct the values in the USER.HST
file. Likewise whenever you change the contents of TIMES.HST,
run SETTIMES.
The general form of this ascii text file is as follows:
0: 30
1: 60
2: 70
3: 80
etc...
8: 130
9: 0
The first digit represents the access level and the number after
the colon is the daily time allowance in minutes (Max 255). At
midnight a caller's full daily allowance is automatically
restored. A caller who exceeds his daily allowance will be
logged off when he next enters a menu (those produced by the .MNU
files) - he will not be able to log back on that same day. Time
taken to upload files is automatically credited to the caller who
is thus not penalised for uploading.
Note: The time value of 0 allocated to level 9 users - a time
value of 0 means UNLIMITED time is allocated to such users. If
any access level is not defined in TIMES.HST, users with that
level are given UNLIMITED time, i.e. a time value of 0. Although
0 is allocated to level 9 users in the example, any level may be
given UNLIMITED time in the same way.
To help to manage daily time limits, two Sysop features have been
provided. The Main menu offered to the Sysop, when he logs on
with the Sysop's password, now includes a (T)imeLeft option.
This enables the Sysop to change the current day's time allowance
for any user - note that at midnight it will revert to the time
allowance related to the callers access level once again.
Whilst a caller is online, the Sysop may use 'Alt T' to change
the current caller's time allowance on the spot. The new time
may exceed the callers normal maximum and will be valid until
midnight.
Note: Neither of these two time control options can be used on a
user with UNLIMITED time.
All callers, who do not have UNLIMITED time, are given their time
left for the day at log-on.
When a user logs on with the Sysop's password he is ALWAYS
allocated UNLIMITED time. This does not affect any time limit
which may apply to that user when he logs on under his normal
password.
The Sysop is advised to use the '%TimeLeft' system variable in
the MAIN.MNU file, to show a user how much time he has left
whenever that menu re-displays.
For example:
^C32MAIN MENU - ^C36You have^C1 %timeleft^C0^C36 minutes left.^C1
^C36(^C33N^C36)ews (^C33F^C36)iles (^C33M^C36)essages etc...
^C0^C32Select: ^Z
Recycle Housekeeping
If the optional file 'RECYCLE.BAT' is created by the Sysop in the
'Host Main Path', it is automatically run after each caller has
logged off, before the host mode resets itself ready for the next
caller. This could be used to copy/update files, run a utility
or carry out any between call housekeeping which the Sysop
desires. If RECYCLE.BAT is not returned from within 15 minutes
the system reboots in an attempt to clear any problem.
Note: RECYCLE.BAT only runs after a SUCCESSFUL log on.
Local Editor
The Sysop may, optionally, specify an external editor to be
invoked when (P)osting or (R)eplying to messages within EaziHost.
This editor will be offered via the prompt 'Use local editor?
Y/N:', when in LOCAL MODE ONLY. If the Sysop wants to implement
this feature he must create a file called 'LOCAL.EDT' in the
'Host Main Path' directory. This file requires a single line
entry in the form:
FULL_PATH_NAME %file /I
For example to use EaziEdit in this role you might have the line:
C:\UTILITY\EAZIEDIT %file /I
The '%file' is converted, automatically, to the correct 'n.MSG'
file name to which your text is to be saved. Note: it is
important that your chosen editor can take the full path name of
a file to be loaded and edited, as a parameter as shown above.
The '/I' parameter is optional and is NOT passed on as a
parameter to your editor. If you have specified the '/I' flag
and your message is a Reply, the text of the message to which you
are replying is automatically imported into your editor with each
line of the original text prefixed with 'FL> ' - 'F' is the first
name initial and 'L' the last name initial of the original
message sender. You may delete and edit lines as you wish and
insert your own text in order to answer selected points from the
original message. If the '/I' parameter is not included, a new
empty file is always offered for editing.
Menu Customisation
The text for most menus is held in external files. The default
menu files are supplied. If these files are not placed in the
'Host Main Path' directory, a short 'Expert' menu, which is
built-in, is displayed instead. In the same way, all help
screens are external files which must be placed in the 'Host Main
Path' directory. If any help file does not exist, a 'No help is
available!' message is displayed to the caller. Default .HLP
files are also supplied, corresponding to each .MNU file. Menu
files have the extension '.MNU' and help file '.HLP'.
Since these files are standard text files, the Sysop can edit
them to change the colour and general layout of the menus but
remember that the options available remain the same - the newly
designed menu should make all available options clear to callers.
The files may include any '^' special codes and any system
variables. The appropriate .HLP file is displayed when the '?'
option is selected. A .HLP file exists for each of the MNU files
except VERTICAL.MNU and have the same file name as the .MNU files
but with the extension .HLP e.g. MAIN.HLP, DOOR.HLP etc.
The .MNU files are as follows:
MAIN.MNU The MAIN MENU.
SYSMAIN.MNU The MAIN MENU (Sysop extended version)
FILE.MNU The FILES menu.
MESSAGE.MNU The MESSAGES menu.
OPTION.MNU The OPTIONS menu.
NEWS.MNU The news menu which starts - 'NEWS: ...'
DOOR.MNU The door menu which starts - 'DOOR: ...'
VIEW.MNU The view menu which starts - 'VIEW: ...'
BATCH.MNU The full batch menu which starts - 'BATCH: ...'
MINBAT.MNU The cut-down batch menu which starts - 'BATCH: ...'
EDITOR.MNU The editor menu which starts - 'EDITOR: ...'
EDIT.MNU The edit menu which starts - 'EDIT: ...'
READ.MNU The message menu which starts - 'READ: ...'
MAIL.MNU The message menu which starts - 'MAIL: ...'
FIND.MNU The message menu which starts - 'FIND: ...'
A number of additional items have been added specifically for use
within the .MNU files:
1) A '^Z' string embedded in any of the xxxx.MNU files, causes
the display of that file file to terminate abruptly. This
can be used to ensure that the menu display stops after the
user-input prompt thus ensuring that the character entered
by the user is echoed in the correct position.
2) The system variable %messagecount has been added to enable
the number of messages in the current area to be included in
MESSAGE.MNU - for example:
^C0^C32MESSAGES - ^C36There are %messagecount messages.^C0
3) The system variable %areatitle enables the current file area
title to be included in FILE.MNU. The system variable
%areanumber enables the current file area number to be
included - for example:
^C0^C32FILES - AREA %areanumber: ^C36%areatitle^C0
Example MAIN MENU definition file:
^C33-MAIN MENU-^C0^C32 - %first %last on-board at %speed baud.
^C36^C1(^C33N^C36)ews, (^C33F^C36)iles, etc...
^C0^C32Your choice %first: ^Z
This would appear to a caller called John Smith as:
-MAIN MENU- - John Smith on-board at 2400 baud.
(N)ews, (F)iles, etc...
Your choice John: _
Please note the use of '^Z' to stop the display dead at the point
where the user's input character needs to be echoed - without it
a RETURN and LINE-FEED would be sent and the users input would
be echoed on the line below the new menu. Menus can be
completely re-designed or re-coloured with this system but it is
best not to create very deep menus or you may find that in
certain cases text scrolls of the screen before it can be
properly studied. Please note you do not need to use '^C0'
before '^Z' to cancel colours, nor are leading '^C0', '^M^J'
sequences or blank lines required because they are hard-wired
into the program code. This ensures that, following arbitrary
text file output to the screen, any colours set by ANSI or '^C'
special codes in the text file are cancelled and the menu is
always preceded by a blank line when re-displayed.
A special file 'VERTICAL.MNU' contains information about how the
numbers ahead of vertical menus like Door titles, News bulletins,
File areas etc. and the letter which precedes file transfer
protocols, should be displayed. A default file is supplied.
The file consists of just one line of text which is, in effect,
a mask where the number or letter is represented by a single
'*'.
For example if VERTICAL.MNU contains:
^C36[^C33*^C36]
vertical menu numbers would appear thus:
[1] - Item 1
[2] - Item 2
etc.
Whereas:
^C36<-^C33*^C36->
would cause vertical menu numbering to appear thus:
<-1-> - Item 1
<-2-> - Item 2
etc.
Two or three leading indentation spaces and a a trailing ' - '
sequence are automatically added by the program. If
VERTICAL.MNU does not exist then the plain number or letter is
displayed in basic default colours. No leading or trailing '^C0'
is needed.
To make even the short 'Expert' menus redesignable, an optional
short Expert menu file may be created, for each menu, in the
'Host Main Path' directory. These files have the same name as
the .MNU files described above but with a letter 'X' prefixing
the name. For example the Expert menu definition file for the
NEWS menu is called 'XNEWS.MNU'. These 'X' menus should be kept
short or their purpose is defeated. The advantage of using 'X'
files is, of course, that they can be coloured and reshaped to
suit your taste or match the full menu files that you may have
designed.
The menu shown under the different possible circumstances will
be as follows:
Expert Menus On 1) The short 'X' menu on disk - if it exists!
2) The hard-wired menu within the program.
Expert Menus Off 1) The full menu on disk - if it exists!
2) The short 'X' menu on disk - if it exists!
3) The hard-wired menu within the program.
Note: The default disk based full menus and help screens may be
supplied in a compressed file called EHTEXT.ZIP (or ARC) from
which they must be extracted.
Removing menu options
Any menu option can be suppressed altogether if required. For
example those wishing to provide a simple support board, on which
say doors will play no part, can disable the 'D' key option on
the main menu which, in conjunction with editing the text of the
relevant .MNU file to remove the (D)oor option, totally hides the
fact that doors were ever available.
A key option can be suppressed by making the first line of the
relevant .MNU file start with a '#' character which is followed
by the keys to be blocked. For example to block the use of
(D)oors and (N)ews from the main menu, the first line of MAIN.MNU
would look like this:
#dn
Pressing the 'N' and 'D' keys at the main menu will then have no
effect at all.
Note: The '#' symbol must be the FIRST character on the line -
Of course ordinary menu lines must not start with '#' or the
system will treat the line like a key blocking sequence.
IMPORTANT: Since the blocked characters are defined in the .MNU
files, you must create the expert versions of the .MNU files too
and include the '#' blocking sequence in those too. Otherwise
callers using Expert menus will be offered the hard-wired expert
menus which cannot be edited and on which options cannot
therefore be blocked. Another way to handle this would be to
make expert menu mode inaccessible by blocking the (E)xpert entry
on the Options menu.
Adding menu options
Up to ten extra menu options per menu, in the form of doors, may
be added to the four major section menus - Main menu, File menu,
Message menu and Options menu.
This mechanism could be used, for example, to add commands to
invoke BiModem or access a CD-ROM interface directly from the
File menu.
The method is similar to that used to suppress options. The .MNU
files carry the extra command information in lines starting with
a '+' symbol rather than the '#' symbol used for key suppression.
The general form of an added command is:
+L FILENAME
Where '+' indicates that the line is an added command definition,
'L' is the character to be the hot-key used to access the new
command and 'FILENAME' is a DOS file name up to 8 characters long
with NO extension.. EaziHost adds the extension '.ADD' itself.
EaziHost expects a file matching the name 'FILENAME.ADD' to have
been created by the Sysop in the HOSTMAIN sub-directory.
FILENAME can be any name except DOORS, ENTRY1, ENTRY2, EXIT1 or
EXIT2. FILENAME.ADD must contain a single line door definition
just as ENTRY1.HST & ENTRY2.HST do.
If the added command has the same hot-key as one of the menu's
built-in commands, it will take precedence over it and , in
effect, disable the built-in command.
File menu example:
+M BIMOD
+R CDROM
^C32FILE AREA %AreaNumber: ^C0%AreaTitle^C0^C1
^C36(^C33A^C36)rea (^C33L^C36)ist etc...
^C36(^C33C^C36)hat CD-(^C33R^C36)OM Bi(^C33M^C36)odem etc...
^C0^C32Select: ^Z
Here 'M' is used for Bi(M)odem to prevent conflict with (B)at and
'R' is used for CD-(R)om to prevent conflict with (C)hat. The
single line door definition files BIMOD.ADD and CDROM.ADD must be
created in HOSTMAIN by the Sysop.
Colour Customisation
The colours used in display files, menus, help screens etc. can
be controlled by using the '^' special codes within the text - as
described above and in the 'SPECIAL CODES' section.
The colours of the hard-wired headings messages and prompts etc.
within EaziHost's host mode can also be defined by the Sysop. A
special file called 'COLOUR.HST' may be created in the 'Host
Main Path' directory, containing the required colour sequences.
ONLY FOREGROUND colours should be used in this file - background
changes may create odd effects. The COLOUR.HST file consists of
up to 9 lines starting with a colour number like this:
n: codes
where 'n' is a digit in the range 1..9 and 'codes' is a string of
digits and semi-colons representing the ANSI colour codes
required to create the desired effect. For Example:
2: 1;36
would assign to colour number 2 the codes to produce bright cyan
text. The sections of text affected by each colour number are as
follows:
1: General comments, error messages and prompts.
2: The EDITOR and FIND two line user explanation texts.
3: Expert menu headings and section headings such as 'News
Bulletins', 'Doors', 'Files', 'File Descriptions' etc.
4: The