Copyright: Copyright ¢1993 Gregg Hommel & Toby Simkin


GHOST BBS 3.00 Help


Overview

What (and why) is GHOST BBS?

Revision History

Credits

Support Questions

License and Warranty

Using This Help File


Installation

System Requirements

Before Installing GHOST

New Installations

Upgrading


Running GHOST

The GHOST Set Up dialog

The Waiting for a Call dialog

The Sysop Menu

System Security

The GHOST Utilities


Configuring GHOST

Basic Configuration

Advanced Configuration

The GHOST Utilities


GHOST Utilities - The Main Dialog
The GHOST Utilities

For help on each option, click on the button for that option.


What is GHOST BBS?

GHOST BBS is a single node bulletin board system, written in the Procomm Plus for Windows Aspect Script language. It is suitable for a small system, at minimal cost, and with minimal maintenance or set up needs, making it ideal for an individual who would like to run a BBS without the hassle of one of the larger bulletin board systems.

Although it can be simple to operate if the sysop chooses, GHOST BBS also has the flexibility to allow the sysop to modify the set up to suit his preferences, including ANSI screen support and multiple language support.

Why did we write GHOST BBS?

Did you ever really LOOK at the Procomm Plus for Windows Host mode, or have you just used it for long enough to let a friend get a file from you? If you've ever actually looked at it, you know why we wrote GHOST BBS!!

It began as a simple modification of Host to eliminate some bugs, and tries to make it look a touch better. What it ended up as is a mini-BBS for a "casual" (or not so "casual") user. It, of course, lacks some of the pizzazz and oomph of a full-fledged BBS, since the Windows Aspect language is not up to everything which full-blown programming languages can do, but it may surprise you in what it CAN do.

In the end, the scripts that we were working on were merely a "ghost" of their former selves (and have become more so with each version), and thus, the name "GHOST".


*Revision History of GHOST BBS
Revision History of GHOST BBS

Version 3.00

- INSTALLG - utility script to do installation or upgrading

- increased limit on maximum number of users from 250 to 1,200

- added support for up to 32,767 Download Libraries (Directories)

- sysop defined maximum libraries and reserved for private libraries

- increased support for up to 32,767 Bulletins

- access to private libraries and bulletins can be set globally, or on a per user basis

- all menus can be customised by sysop

- new user questionnaire "header" now available for editing

- all prompts can be customised by sysop

- added full ANSI support in menus and prompts

- added support for PCBoard style @variables in prompts

- added support for up to 99 Languages (menus, prompts)

- support files can now be moved and/or renamed by sysop

- multiple support drives/directories

- file libraries may be located on different drives

- "Welcome" screen of system information to users at logon

- added word wrap to chat mode

- sysop menu item to "force" chat with user

- rewrote keyboard handling to account for Procomm "bugs"

- added modem off hook - local log ons or system maintenance

- modem init. strings stored internally

- added back support for wild card transfers for level 4 or 5 users

- added file transfer options for auto logoff and abort

- added sysop defined timed log offs

- added sysop defined keyboard time-out detector

- added support for handling of DLP file transfer protocols

- ANSI Mode can be toggled from the main menu

- added GHOST Utilities for editing new parameters, modem strings, and user records

- Windows 3.1 version on line HLP file documentation

- HLP file is accessible from active GHOST scripts

- alias support no longer security level sensitive

Version 2.00

- private directories for level 3 users

- added Zmodem batch transfers for remote downloads

- L)ocate a user menu item

- added support for up to 99 bulletins

- addition of timed sessions (start and stop time)

- support for running  of a secondary script at session 1 shut down

- provision to run a second GHOST "session" (timed)

- added a 24 hour loop routine to allow unattended running of GHOST/secondary script combinations

- mail is packed automatically at shut down if messages have been deleted during session

- support for sysop defined screen clears between display pages for increased speed

- added alias support for level 4 and 5 security users

Version 1.20 (very limited release)

- added private directory capability for level 3 users

- extended multiple directory file transfers to level 4 users

Version 1.10

- fix for improper recycling of both Ring Monitor and GHOST BBS

- added additional lost carrier protection - now constant

- fix for bug in display of last date on the system at logon

- fix for "change of year" bug in GHOST 1.00

- speed improvements in connection and recycling

- rewrote some code to eliminate internal "speed hogs"

- faster screen display speed

- changed "end of edit" character to ESC to work around Procomm bug in handling European keyboards

Version 1.00

- Initial release of GHOST BBS


Credits

There are several people who deserve special thanks for their contributions to GHOST BBS as it is today. This help was not necessarily in the form of code or similar, but as ideas for features, feedback on the beta versions, and general assistance in debugging the alpha versions of GHOST.

First and foremost of these is David Anjo, who has spent countless hours on the phone connected to my system and trying to "break" it, and even more hours listening to me expound on ideas for inclusion, and offering his best advice and counsel. Thank goodness that David is a local caller, or his long distance bill to do this for me would have long ago put him into the poorhouse. David has also been the critic of my graphics and displays, being an artist, and has contributed a great deal to the look of the dialogs for GHOST BBS.

Then we have another "David".. David Head, who is NOT a local caller (at least, I don't think North Vancouver, B.C. is local <GG>). This David has been a staunch and strong hearted beta site, who has run the GHOST betas into the ground as his regular BBS, searching for little things that needed fixing... text that was incorrect, keys that did not work as expected, or that did things they weren't supposed to do, and so on. The basic idea behind the @variables came as a result of David's desire to word prompts differently than I had done. He also did extensive testing for me of the keyboard time-out feature, and using external protocols with GHOST.

Bryon Sinclair in Oregon has run GHOST BBS in all of its beta versions in real world situations as his regular BBS, and has provided me with a convenient distribution point for GHOST files. Apparently, it is cheaper for American callers to make the call to Oregon, than it is to place it to me here in Canada. Bryon has allowed his board to be used for this purpose, spreading GHOST around far more than I could have done myself. He has also, like David Head, pointed out many inconsistencies in prompts, pushed for ANSI support, and found a multitude of little things that needed fixing. Both Bryon and David suggested that a way to "force" a chat with a user would be of great use. Thus came that particular sysop menu item, which has indeed proven to be useful.

I'd better not forget Ralph Beemer (he won't let me anyway <G>), who bugged the he** out of me for more and better ANSI support, for the ability to edit the menus and prompts, and for almost all of the sysop customisation features of GHOST.

Speaking of ANSI... included with the GHOST distribution files is a ZIP called SCREENS.EXE, which is a self-extracting file containing a collection of ANSI menus and so on for GHOST. These were designed and submitted to me by a fellow who, until beginning work on the various GHOST screens he did for me, had only a couple of months experience with designing ANSI screens. I think he did a super job on designing several alternate examples of ANSI screens for GHOST, and would also like to thank him here for doing all this work. I suppose it takes on even more meaning when you realise that to send me these files, he called me countless times, long distance (and I do mean long distance) from his home in Brisbane, Australia. Many thanks to Vlad Balak for a real nice collection of alternative ANSI menus and screens that he graciously allowed me to include with the release of GHOST BBS 3.00.

Al Simcoe, Ralph Beemer and David Anjo all helped "debug" this Windows Help file, so that the text you are reading would be clear (and in English <GG>). Thanks for the patience, guys!

And of course, Marco Garibaldi  in Germany and Andreu Codina in Spain, who together, kept pushing me to write GHOST to allow support for languages other than English. Without this push, the ability to edit prompts may never have happened... in order to arrange for support for other languages, the prompts had to be "pulled" into their own file, making editing of the English prompts as much a reality as support for other languages.

When I look back on the development of GHOST 3.00, it is a remarkable sea of interaction. One beta site suggests that adding this feature would be nice, and these addition results in other changes that other beta sites have requested, simply because making the first change shows a logical way to make the others. Perhaps most remarkably, the writing of GHOST, all of the beta testing, all suggestions for changes and/or enhancements, has been done electronically. GHOST itself has been the tool used for the vast majority of the electronic communication, and has been tested under fire through that communication.

If I have missed any of a fairly large number of beta sites, all of whom have contributed greatly to the current state of GHOST BBS, I apologise. There are so many of you, and you have all helped out so much, that I can not possibly express the thanks necessary, but this is a feeble attempt.... to all of the beta sites for GHOST BBS, thank you for your help. It is appreciated more than you can ever know.

Gregg Hommel


Support Questions

Support for GHOST can be accomplished in one of several ways. The author,  Gregg Hommel, can be reached via the various electronic BBS network systems (NANet, Intelec, RIME, EchoNet, ILink and FIDO Windows conferences or NANet, Intelec, RIME and ILink Procomm conferences), CompuServe, Internet, or on his own BBS, Gregg's Place .

Questions about GHOST BBS of any nature, are welcomed and appreciated. We also would appreciate any suggestions that you may care to offer for future versions of GHOST BBS. GHOST is an ongoing process, and ideas for future enhancements or features are always appreciated.

There are no support costs associated with GHOST BBS, other than any toll charges, etc. to contact the author.  Support questions from, or informational requirements of,  registered users receive first priority, but all questions will be answered, regardless of registration status.


License Agreement and Warranty Disclaimer

You should carefully read the following terms and conditions before using this software.  Use of this software indicates your acceptance of these terms and conditions.  If you do not agree with them, do not use the software.

Shareware Version

You are hereby licensed to:  use the Shareware Version of the software for a 30 day evaluation period; make as many copies of the Shareware version of this software and documentation as you wish; give exact copies of the original Shareware version to anyone; and distribute the Shareware version of the software and documentation in its unmodified form via electronic means.  There is no charge for any of the above.

You are specifically prohibited from charging, or requesting donations, for any such copies, however made; and from distributing the software and/or documentation with other products (commercial or otherwise) without prior written permission.

Evaluation and Registration

This is not free software.  This license allows you to use this software for evaluation purposes without charge for a period of 30 days.  If you use this software after the 30 day evaluation period a registration fee of $25 is required.

In return for registering GHOST BBS, you will receive a registered name, registration number and validation code to insert in GHOST. This will result in the opening dialog box no longer appearing when you start GHOST. This registration also entitles you to support for the product, via email on BBS nets or CompuServe, or via the author's BBS. Your registration will be good for all future versions of GHOST BBS... all you will need do is download the latest version from your favourite bulletin board, and it will be automatically registered when run.

One registered copy of GHOST BBS may be dedicated to a single person who uses the software on one or more computers or to a single workstation used by multiple people.

You may access the registered version of GHOST BBS through a network, provided that you have obtained individual licenses for the software covering all workstations that will access the software through the network.

Governing Law

This agreement shall be governed by the laws of the Province of Ontario, Canada.

Disclaimer of Warranty

This software and the accompanying files are sold "as is" and without warranties as to  performance of merchantability or any other warranties whether expressed or implied. Because of the various hardware and software environments into which GHOST BBS may be put, no warranty of fitness for a particular purpose is offered.

Good data processing procedure dictates that any program be thoroughly tested with non critical data before relying on it.  The user must assume the entire risk of using the program. Any liability of the seller will be limited exclusively to product replacement or refund of purchase price.

GHOST BBS 3.00

Copyright © 1992, 1993 Gregg Hommel  - All Rights Reserved

Portions Copyright © 1992 Toby Simkin - All Rights Reserved

Portions Copyright © 1992 Datastorm Technologies, Inc. - All Rights Reserved

RingMonitor Portions Copyright © 1992 Bob Blow - All rights reserved


Registering GHOST BBS

GHOST BBS 3.00 Registration Form / Invoice

Registering through the CompuServe Shareware Registration Database: enter GO SWREG at the ! prompt and follow the menus.  (GHOST BBS' registration ID is 1330, registration fee on CompuServe - $ 30.)

Registering by cheque:  To register by cheque send this registration form and a cheque to :

Gregg Hommel,

Computer etceteras / WiGuys Software

19 Rushbrook Drive,

Kitchener, ON, Canada

N2E 3C1

To print this registration form, click on Print Topic in the File pull-down menu.  Alternately, you can print the ASCII text file  REGISTER.TXT. Payment may also be sent in the form of an international postal money order.

GHOST BBS 3.00 Single Registration  ____    	copies at $25 each =   _______

 	Total payment             _______

(Price guaranteed through December 1993.)

            Name: _______________________Date:___________

         Company: _______________________________________

         Address: _______________________________________

City, State, Zip: _______________________________________

         Country: _______________________________________

       Day Phone: _________________Eve:__________________

Electronic Mail address: ________________________________

How did you hear about GHOST BBS? __________________________

Where did you get your copy of GHOST BBS? __________________________

Comments:


Using This Help File

Using this Help file is little different than using most other Windows Help files. It uses all of the "normal" Help file conventions, however, some of them are perhaps used in a somewhat different manner than other Help files use them.

As is "normal" in Windows Help files, whenever you see a word or phrase highlighted in colour and with a broken underline, clicking on it will put a popup on the screen. When the word or phrase is highlighted in colour but has a solid underline, clicking on it will jump  to a new topic (try it here <GG>).

These are "normal" for Windows Help files. However, unlike some "normal" Help files that I have seen, I decided not to clutter the screens in this one with an abundance of items to jump back and forth through the file. Rather, this Help file relies on the navigation buttons which appear above the screens, i.e. Contents, Search, Back and so on. If you use these buttons, you will find navigating this Help file to be relatively painless.

There are, however, some different items in this particular Help file. These topics appear on the screen as the dialog boxes which you will see when actually using GHOST BBS. Since most of what a sysop does when configuring or running GHOST is done via these dialog boxes, they are used in this Help file extensively as a tool for explanation of what can be done from them. When one of these dialogs appears, they will look and behave similar to this one :

Behave? Well, to see how a dialog in this Help file "behaves", move your mouse cursor over the dialog box above. At various places, the normal arrow cursor will change to a "pointing hand". There are four spots in the above dialog where this will happen : the edit box of the dialog, the Save It button, the Exit button, and one more that you will find by using the other ones <g>.

This is important to being able to use this Help file. With some practice here, on this sample dialog, and using the Windows Help engine navigation buttons at the top of the screens, you should have no difficulty in finding your way around this help file.


A Jump Example

This is just to demonstrate how a topic "jump" works in a Windows Help file. To return to reading the section on Using This Help File, click on the word return.


System Requirements

Host machine

- MS Windows version 3.00 or higher (version 3.1 preferred)

- Procomm Plus for Windows version 1.00 or higher (version 1.02 preferred)

Since GHOST BBS is a Procomm Plus for Windows Aspect Script Application, you must have a copy of Procomm Plus for Windows to run it (along with, of course, Windows). Beyond these basics, GHOST BBS may be run by anyone, individual or corporation.

For proper operations and display of ANSI screens, when running GHOST, your Procomm Plus for Windows terminal should be set to N81, with ANSI BBS emulation. To ensure this, GHOST will take care of setting the terminal when it begins, and resetting it upon exit from GHOST.

Remote User

GHOST BBS has been tested by using the following applications to log in.....

Telix (DOS)

QModem (DOS)

QModem Pro (DOS)

Procomm Plus for DOS

Windows Terminal

CrossTalk for Windows

Procomm Plus for Windows

Windows Terminal experiences some slow down of screen draws, and can show "junk" on screen (if GHOST is set for ANSI screens), due to its inability to correctly interpret the ANSI codes sent it by GHOST BBS. All other applications tested worked perfectly with GHOST BBS.

The remote user should have his terminal set to N81, and whatever ANSI BBS emulation is available to him. If he does not have a proper ANSI emulation set up in his comm. app., he should answer N to the prompt asking if he wants ANSI graphics.

Remote users with Procomm Plus for Windows should use the scripts supplied in the GHOST distribution package to log on to a GHOST 3.00 system. The source code for these scripts is included in the distribution package so that the remote user can modify responses to the language and/or graphics prompts.


Before Installing GHOST

Before beginning the installation of GHOST BBS, there is something you should consider.

GHOST has a fairly large number of support files. These files include menus, bulletins, file listings, and user records and can easily "clutter" your ASPECT directory, if they were to all be installed there. Furthermore, if they are all put in that directory, any editing that you might wish to perform, or any clean up of old files that needs be done, could be unnecessarily difficult if the files from GHOST BBS are mixed among the script files and so on already in your ASPECT directory.

For this reason, GHOST BBS will place its support files in a directory other than your default ASPECT directory if you let it. When you install GHOST BBS for the first time, or upgrade a previous version of GHOST, you will be asked for the basic drive/directory where you would like your GHOST support files placed. If necessary, the installation routine will create that directory.

Although the numbers and sizes of the files stored are, at installation, not a huge amount, they can grow quickly as people use the system and the sysop adds bulletins, file listings and so on. Therefore, you should ensure that, whichever drive(s) you chose for your GHOST support files, there is sufficient room for growth. You may also wish to move the support files from a single sub-directory, to directories for each type of support file (see Moving the Support Files in the Advanced Configuration section).


New Installations

To do a new installation of GHOST BBS (i.e. one where no previous version of GHOST is on the system) is a simple procedure under GHOST 3.00.

1) Make sure that you have read the Before Installing GHOST section of this help file, and have decided where you would like GHOST BBS to install its files.

2) If you have not yet unzipped the distribution file, please do so now. GHOST will install itself from either a floppy drive on your system, or a working directory on your HDD, but the unzipped distribution files must be in that location before you run the installation script.

3) From the unzipped distribution files, locate the file INSTALLG.WAX, and copy it to your \PROWIN\ASPECT subdirectory.

4) Start Procomm Plus for Windows, and from the script listing drop down in the tool bar, select the INSTALLG script. This will begin the installation procedures.

5) INSTALLG will need to know (and ask you for) the location of the GHOST distribution files. Type in the floppy drive letter, or the HDD directory where you have unzipped them, and press enter.

6) The installation will first run this Help file for you to browse, and will not continue until you tell it to do so. Take your time before continuing, and read whatever you wish to in this Help file.

7) Once it continues, INSTALLG will then need to know from you what directory you want it to use as the "base" for your installation. Type in the base support file location, and press enter.

Most of the rest of the installation is automatic. INSTALLG will either create, or install, those files that it needs to operate. There is one last bit of data that INSTALLG will ask you for, however. When it is almost finished, INSTALLG will want to create a default user record file, and user listing file. To do this, it will need to create a user record for someone, and in this case, you, the sysop, make a good first user. This record should, however, be created in your own name, rather than the name "Sysop" (since INSTALLG will create an entry for [SYSOP] automatically). One precautionary word. Don't be alarmed if the screen appears to lose Windows and Procomm for a moment. The routines that create the user list, of necessity, drop to DOS to "sort" the list. This will result in a temporary full screen DOS session while the list is sorted. It should only last a brief second or two.

When INSTALLG finishes installing GHOST, it will bring up this help file, and delete itself and any temporary files it used, before it shuts down.


Upgrading GHOST
Upgrading

If you have been running an earlier version of GHOST BBS, and have left your installation on your system, then GHOST will recognise this older installation and do an upgrade, rather than a complete install.

To upgrade your earlier version of GHOST to version 3.00 :

1) If you have not yet unzipped the distribution file, please do so now. GHOST will do the upgrade from either a floppy drive on your system, or a working directory on your HDD, but the unzipped distribution files must be in that location before you do the update.

2) Copy the INSTALLG.WAX file to your \PROWIN\ASPECT subdirectory.

3) Start Procomm Plus for Windows, and run the INSTALLG script. This will begin the updating procedures. The first thing that INSTALLG will need to know (and ask you for) is the location of the GHOST distribution files. Enter the floppy drive letter, or the HDD directory where you have unzipped them, and press enter.

4) INSTALLG will first run this Help file for you to browse, before continuing with the installation procedures. When you are ready, either close or minimise this Help file, and answer the dialog box on the screen.

5) When updating a previous GHOST BBS installation, INSTALLG will use your default GHOST support directory from the previous installation as the GHOST 3.00 "base" directory. Just in case, though, INSTALLG will ask you if this is the directory you want to use as the "base" before it continues.

Most of the rest of the update is automatic. INSTALLG will either create, or update, those files that it needs to operate. However, since some "new" support files replace previous GHOST files that may have been customised on your system, before replacing these with the "new" versions, INSTALLG will ask if it is OK to do so. If you choose not to replace these files, you may want to look at the "new" versions to see if there are any changes that you may wish to incorporate into your custom files.

One last item. Before it finishes, INSTALLG will look for a user list. In GHOST 2.00, this file was optional. However, GHOST 3.00 uses that file as the basis for selection of the user records to edit (in the GHOST Utilities), and in the [L]ocate a user menu item in GHOST itself. If INSTALLG does not find this file (default name is GHOSTUSR.LST), it will use your current GHOST.USR file to create it. During the process, INSTALLG will also translate your current GHOST.USR file into the new, version 3.00 USR/REC combination for user records, and update the GHOST.INI file for these changes. While creating the user list, the routines will need to drop to DOS once, in order to sort the list. This may result in a temporary, full screen DOS session, but with nothing on screen (the output is "piped" into the file, rather than the screen). It should only last a few seconds (as example, it takes about 45 seconds to create a user list of 150 users on my 386sx/20 system), and then Windows will reappear with Procomm Plus for Windows still active.


The GHOST Set Up dialog

Click on any dialog box or option choice for further information on that item.


The Waiting for a Call dialog

Click on any dialog box or option choice for further information on that item.


Running Freedom as secondary script

GHOST can run any script here (such as Jerry Sully's MailRun), but since I have specifically coded PCB Freedom to take advantage of this feature, it is a nice example to use. (Besides, you all are using my other script application, PCB Freedom anyway, aren't you?? <GG>)

OK, so we have selected the "Run Script ?" Yes radio button. Now, in the edit box labelled "Script :" we enter "FREEDOM". You might also enter "FREEDOM.WAX", or indeed, the full path and filename, but if Freedom is in your Aspect subdirectory, simply entering the word "FREEDOM" will take care of letting GHOST know which script to run.

PCB Freedom does not accept or act upon a string passed to it from GHOST, so we can leave the "String :" edit box empty. However, Freedom DOES accept and act upon an integer passed to it. In this case, we have three options for the "Integer :" edit box....

1) We can leave the edit box empty, in which case, Freedom will run "normally", i.e. it will start up, go into delayed dialling mode if it finds a dial time, or open the main Freedom window if there is no dial time. Doing your mail runs will be the normal task under Freedom.

2) We can put a "1" in the edit box. If PCB Freedom is passed an integer value of 1 from GHOST, it will ignore its "defaults" and immediately begin a mail run on the list of systems set up to be called, just as if you had started it yourself by clicking in the Dial icon in Freedom. But that's not all.... once the mail run on the listed systems is complete, Freedom won't simply return to its main window as it normally does after a mail run. Rather, it will immediately shut itself down, and return control of the modem to GHOST.

3) We can put a "2" in the edit box. If PCB Freedom is passed an integer value of 2 from GHOST, it will act very similarly to when it is passed a 1 from GHOST. There is one big difference, though... if the integer passed to Freedom is a 2, the "standard" dialog boxes which normally appear when Freedom is running (the dialqueue and "System Options" dialogs) will not appear. Since, in most cases, it is assumed that you are not around when GHOST and Freedom are doing this, having the Freedom dialog boxes appear on the screen is not normally a problem. However, there are two cases when having these dialogs "pop up" can be problematic. One, of course, is if you happen to be working on something else when GHOST switches over to PCB Freedom and calls you dial list.

The other case is a little more obscure. During "normal" operation, and this is what happens when Freedom is run with a passed integer of 1, the "System Options" dialog box is timer controlled, remaining on screen for 10 seconds, and if no activity in the dialog occurs within that time, it clears, and uses the defaults. Normally, this works just fine. However, some beta sites have reported that on some WildCat systems, if the "System Options" dialog remains on screen for 10 seconds, the WildCat "Main Menu" prompt can be missed (sometimes), leaving the mail run out of whack.

If this happens to you (try logging on to a WildCat system via PCB Freedom, and letting the "System Options" dialog time out and disappear on its own. If the script continues to run normally (mine does when logged on to the Mustang HQ BBS), then you need not worry about this "quirk". If, on the other hand, it hangs, and stays at the "Main Menu" prompt without sending a response, your system is one of the "quirky" ones), then passing the integer value of 2 will solve the problem, since the "System Options" dialog won't appear if that integer is passed to Freedom from GHOST.


Using Ring Monitor

Imagine this type of scenario (with many thanks to Bob Blow for his contribution of the code, and apologies if we screw up the idea behind it).....

You have one telephone line for all of your many needs; voice, data, and answering machine, say. You have to go back to the office tonight, but there are some files on your home system which you may need later. So you start GHOST BBS, and leave for the office. Later in the evening, you get the files you need then by calling your home system, and logging on to GHOST.

However, unknown to you, your Great Aunt Minnie from California has just won 15 million dollars at Bingo. Since you are her favourite Great Nephew (or Great Niece <GG>), she decides to send you half of it, if she can reach you before her money-grabbing kids get to her. She calls you, but, after two rings, she hears a horrible screech on the line, and so, hangs up. Five minutes later, her kids get there, and ...... let's just say that it is NOT a pretty picture.

Well, Bob figured a way around this dilemma; Ring Monitor. It is actually an amazingly simple concept, and something we are happy to include with GHOST BBS.

What Ring Monitor does is this - when you start GHOST in Ring Monitor mode, GHOST doesn't actually initialise. Instead, Ring Monitor does. It lurks there, waiting for someone to call. In the above scenario, you are at the office, and decide that you do indeed need those files at home. You call your home number as if making a voice call, BUT hang up the line in the middle of hearing the second ring at home. Now you turn to Procomm, and after waiting around thirty seconds, call your home number as if GHOST was active. Guess what??? It IS active now, and waiting for your call. You get the files, hang up, and GHOST immediately goes back to Ring Monitor mode.

Great Aunt Minnie calls, but since you are not home, the phone rings and rings.  After 4 rings, your answering machine picks up, takes the message from Great Aunt Minnie, and you're RICH!!

How is it that the answering machine picked it up, instead of GHOST?? Well, if Ring Monitor detects more than two rings, it says to itself "That's not for me! Let the machine get it!" (much as you might do when at home <GG>)  However, when Ring Monitor detects two rings followed by silence (as when you called home and hung up), it says "That one's for me... someone wants GHOST!" and it initialises GHOST BBS.

Suppose though that you call, ring twice, and hang up, then decide that you don't want those files. Does this mean that GHOST is once more monopolising your system, and Great Aunt Minnie won't be able to get through?? We thought of that, also. If a call does not successfully connect to GHOST within 90 seconds of initialisation, GHOST decides the first two ring call was a mistake, and drops out, returning to Ring Monitor mode.

One last thing..... suppose you do not want to use Ring Monitor? Simply uncheck the box labelled "Enable Ring Monitor" in the "Run Time Options" section of the main GHOST dialog, and save it as a permanent change. You can still use it temporarily via the "Temporary" buttons, or indeed, change your mind and make it permanently enabled again at any time.


The Sysop Menu

When GHOST is running, the first thing that you will notice in the Procomm Plus for Windows window is that the normal tool bar and menu bar are missing. GHOST has replaced them with a menu of its own, the Sysop Menu. This menu allows the sysop to perform several GHOST specific functions.

At various times, the Sysop menu may contain a combination of the above choices, either as an active menu item or an inactive (greyed) menu item as in the sample. For further information on each menu item, simply click on that item.


System Security

There are six levels of security in GHOST BBS 3.00. These security levels allow you to control what a remote user can and can not do while on line and are as follows :

0 - Restricted User - no file transfers, read / write of mail only

1 - Limited User - able to download from the main Library #1 only - no uploading of files, can read / write mail

2 - Normal User - full uploads and downloads, regular security for the system

3 - Special User - access to private bulletins and private file libraries - can be the global private bulletins and libraries, or the sysop may specify (in the user record, via the GHOST Utilities) which ones he is allowed access to

4 - SuperUser - sysop type of access but they can't abort GHOST, allowed to do wild card file transfers if enabled

5 - Sysop - full high security access to all areas of the BBS, including the [A]bort GHOST BBS menu item

The default New User Security Level can be set to Restricted, Limited or Normal through settings in the GHOST Utilities. (The installation "default" is for a Limited New User Security Level).

In addition, system security is enhanced through the use of a New User Questionnaire which is part of the log in for a new user. In this questionnaire, a new user will be asked for their full address, voice telephone number, and fax/data telephone number (if they have one). Using the information filled in to this questionnaire, and stored by GHOST in the user record file, you, as sysop, can "validate" a new user, by verifying their address and phone numbers, say through directory information.

It is, of course, up to you whether or not you wish to verify a new user before giving him or her full access to your system. For this reason,  GHOST allows you to set the security level for a new user to Normal, if you wish. However, we also think that system security is an important aspect of any BBS system, and thus have made provisions for more restricted access via the Restricted and Limited new user security levels.

All of the information regarding a particular user is stored in the user files  (see The GHOST USR & REC Files), and can be read and/or edited using the "Edit User Records" utility in the GHOST Utilities script. Almost all fields of the user record are edited from here, including the user security level. In addition, GHOST 3.00 allows the sysop to "delete" a user from here, by entering, as his security, the letter d (small or cap). When you do so, and save the user record, GHOST will automatically delete that user's entry from the USR file, and change their security in the appropriate REC file to "D x" where the x is their security level prior to the deletion. By maintaining the user record, with security marked in this fashion, GHOST also allows you to add the user back again, simply by adding the pointer for their record to the USR file, and then removing the "D " portion of their security level record in the REC.


Basic Configuration

Setting up for GHOST

Making GHOST into your BBS

Identifying the GHOST files

The Main Menus

Bulletins

File Libraries


Setting Up For GHOST

GHOST BBS requires that the terminal emulation used by both ends of the connection (i.e. host and remote) be an ANSI BBS terminal. This is, of course, necessary to support the ANSI codes sent by GHOST to the remote system, and to display them properly on the host system.

It is good practice to set Procomm Plus for Windows to a terminal emulation of ANSI BBS, and parity settings of N81 before starting GHOST,  however, to be sure this is properly set, GHOST BBS will double check, and if necessary set these parameters internally before it begins. When doing so, it also will store any settings that it changes, and restore them when the programme is exited, either through the timed settings or manually. This includes if the programme is only partially exited, i.e. GHOST shuts down in order to run a secondary script. Whenever the actual run time file for GHOST BBS is terminated, GHOST will reset all parameters of the host system to their settings before GHOST began.

For safety, GHOST will also make a back up copy of your Procomm Plus for Windows PW.PRM (parameter) file when it begins, and restore that back up copy on exit. This helps to ensure that any changes which GHOST makes to your system settings are returned to your original settings when it is finished.

GHOST BBS allows several methods of running. These include, but are not limited to, 24 hour loops (a single GHOST session, starting and stopping at set times, which may or may not run a secondary script between sessions, but runs automatically, each 24 hours without ever stopping the GHOST launcher script), single and double sessions, with or without the running of a secondary script between sessions, and stopping GHOST after the sessions complete, and quick runs (for immediate use of GHOST BBS without timed functions or secondary scripts).  (see also The GHOST Set Up Dialog)


Identifying the GHOST files

GHOST BBS, in a default installation, stores all of its support files in the directory which you have specified during that installation as the "support" directory. GHOST tries to make it easy for you to determine which files do what. In a default installation, the basic indicator of the purpose of any given GHOST support file is the extension of the file.

GHOST BBS uses, as defaults, the following extensions for support files

DNL

There can be several of these files (two possible for each File Library on your system). They are Library listings created by the sysop to be shown to a user when they ask for a listing of files in a Library. If DNL files for a given Library number do not exist, then a user will be shown an "actual" list of the files in that directory. Using DNL files allows the sysop to control what the user sees as a file list, and to add descriptive text about the files. By default, GHOST installs two sample DNL files, GHOST1.DNL (ANSI version) and GHOSTT1.DNL (text version). These files are samples for Library 1, as indicated by the 1 in the filename.

HLP

The GHOST BBS help file shown to a user when they use [H]elp from the main menu. In a default installation, the file GHOST.HLP is the "ANSI" version of this file, and GHOSTT.HLP is the text version of the help file.

GHOST3.HLP

This is NOT one of the help files, described above and available to the user on the system. This is a Windows Help file (actually, this one <GG>), and is available to the sysop when GHOST is running (see also Using This Help File). This file is somewhat different from other support files... it is located in the same directory as the Procomm executables are (normally, \PROWIN), and can not be moved from there. That is the only location which a script can use to find and run it, so it must remain in that directory.

MNU

This extension indicates a GHOST menu file. GHOST uses several of these files, dependant upon the menu required. The most important of these, of course, is the Main menu, which GHOST installs as files MAIN.MNU (ANSI) and MAINT.MNU (text). There are also menus for : a local "sysop" logon (SYSLOC.MNU and SYSLOCT.MNU); a remote "sysop" logon (SYSREM.MNU and SYSREMT.MNU); transfer protocol menus (GHOSTP.MNU and GHOSTTP.MNU); and four sample menu files, two for your bulletin listings (GHOSTB.MNU and GHOSTTB.MNU), and two for your Library listings (GHOSTL.MNU and GHOSTTL.MNU) (see also Advanced Configuration - Screen Displays )

NWS

Similar to the DNL files in naming format, files with this extension are the ANSI and text versions of your bulletin files. Like the DNL files, there is a number in each file name which indicates to GHOST that this file is to be displayed when a user selects that number from the Bulletin menu. Furthermore, GHOST will compare the file dates of all NWS files, to the "last on" date of a user during log in, to decide which bulletins need to be shown to that user as "new". Again, the default installation will have copied two "sample" NWS files into your support directory, GHOST1.NWS (ANSI) and GHOSTT1.NWS (text).

NUF

There are several files used during a new user logon, and these are indicated, in a default installation, by the NUF extension. They consist of; NUHEAD.NUF, used for both ANSI and non-ANSI log ons, which gives the new user information regarding the new user questionnaire, and user validation, before the questionnaire is presented; NODATA.NUF, again used for both types of log ons, and which is put on screen IF the new user does not complete all data in the questionnaire; and GHOST.NUF (ANSI) and GHOSTT.NUF (text), which contain information for new users regarding their security level, rights on the system, and so on (as the sysop may decide).

NIL

There will be only one of these files, GHOST.NIL, which is an icon library used by GHOST as a source for icons in various dialog boxes.

WAX

These are the compiled script files used by GHOST for various functions.

PMT

This file is VERY important to GHOST, since it contains ALL of the prompts which GHOST presents on the screen to a user. The default file, LANG1.PMT, is the prompt file for the default language (English) of GHOST. The prompt file name must include the language number (English is 1 in a default installation). This file may be edited by the sysop to "customise" the prompts on the system (see Advanced Configuration - Prompts and The Prompt File Contents  ).

LST, USR, and REC files

These files are created by GHOST as and when needed. The USR file  contains pointers to the appropriate REC file where the actual user data is stored. The LST extension indicates the user list used for the [L]ocate a User menu item in GHOST, and to present the user list of names in the Edit User Records portion of the GHOST Utilities.

LOG, MSG, HDR, BAK

Each of these extensions indicates a file created by GHOST during its operation. The LOG file is used to store logon, etc. information for a GHOST session, and the MSG, HDR and BAK files are created to store and back up mail messages.


The Main Menus

GHOST BBS ships with a set of default, sample menus to use, including all of the main menus necessary. It is quite possible to continue running GHOST indefinitely with these menus. However, if you wish to make GHOST into your own BBS, you may, with only minor effort, edit these default main menu files to add custom messages for your system.

One caution.... when editing ANY GHOST file, INI, USR, MNU or anything else, it is always best to use a text editor. One beta site had repeat problems running GHOST simply because he used Windows Write to edit his files, and forgot to select the "No Conversion" button when the file loaded, or forgot to use Save As to save the files as text. (See, even beta testers aren't perfect <GG>) GHOST only uses files in straight ASCII (Text) format, and will have problems if the files it needs are in another format.

There are certain restrictions to the size of the main menu files. They can not exceed 78 displayed characters per line, or they will appear quite strange on screen. GHOST is designed to wrap text in 80 column mode, and thus, if a menu line exceeds around 78 displayable characters per line, that line will wrap to the next when displayed, resulting in a look not quite what you intended .

Also, the main menus have a limit on the number of lines they may contain. As example, in order to display, with the prompt, on a single screen, without scrolling, the main menu can not exceed 20 or 21 lines in total (see also Screen Displays).

For our purposes here, we will simply edit the lines of the default, sample main menu files, without adding any additional lines to the menus.

The sample ships with space for up to seven lines of text (or blank lines) at the top, above the menu itself. In terms of appearance on screen, it is best to leave the top line, and the last line just prior to the menu blank. This gives a good "visual" feel to the display. However, the lines from 2 through 6 (5 lines total) are quite suitable for anything you'd care to place there. This can be advertising for your products, the name of your BBS, sales phone numbers you have (if applicable) and so on. On Gregg's Place, the lines from 2 through 5 are used and contain this information :

GHOST BBS 3.00 System

Computer etceteras / WiGuys Software

The home of PCB Freedom and GHOST BBS

                        (519) 745-9717

Again, for visual purposes, you may wish to keep the text you place here centred in the 78 column display space allowed. This is visually more appealing to remote users, however, is not a requirement at all. The text may be left justified, right justified, centred, or even take up the full 78 character spaces allowed. It does not even have to specify what type of BBS is being run (as above), although we would certainly appreciate it if you left the first line of the sample menu alone as advertising for GHOST <GG>.

Once you have changed the main menus to display the information you want in the headers, simply save them in your GHOST support directory and they will be used when next you run GHOST. If you would like to see what the end product looks like on screen, run GHOST and select the Quick button to initialise GHOST. Log on as a local user, and take a look at what a remote user will see.


Bulletins

Bulletins in GHOST, are files that have an NWS extension, and which are displayed to a user immediately after he has logged on. GHOST uses a comparison of the users last on time and date with the time and date of each bulletin file that it finds, in order to decide which of the bulletins on the system should be displayed to a user at logon.

Additionally, your users may access a menu of the available bulletins on the system, and select one to read if they wish. GHOST does not allow all users to access all bulletins however, since it recognises and restricts access to private bulletins (see Private Bulletins and Libraries)

The default installation of GHOST BBS provides a "generic" bulletin menu and one bulletin. Like the menus installed, by GHOST, these files may, if you wish, be used "as is", however, you may want to edit these to be more useful to your users.

The menu files (GHOSTB.MNU and GHOSTTB.MNU) are subject to some of the same restrictions as the main menu files, in particular, the need to not exceed 78 displayed characters per line. However, unlike the main menus, it is possible (indeed, probable) that, at some point in the future, you might have enough bulletins on your system to make it impossible to fit them all into a single menu of 20 or 21 lines maximum. Thus, scrolling of the menu for bulletins becomes a definite possibility. To this end, GHOST allows the user, in the prompt for the bulletin menu, to re-display the bulletin menu, should he need to do so in order to find the bulletin number he wants. This then, removes the restriction that exists in the main menus, to stay under 21 lines long for this menu.

The actual bulletin files themselves (samples installed as GHOST1.NWS and GHOSTT1.NWS), have no real limitations on their design. Of course, if you are using ANSI graphics in the bulletin (see Using ANSI), you won't want to exceed 78 displayed characters per line in order to have the bulletin show on screen properly, but there are no limits on the length of the file, and so on. When one screen full (23 lines) of the file is displayed, the user will be asked if they want to see more of the file, or stop the display.

Bulletins are a great way to tell your users when something has changed on the system, to inform them of the latest and greatest files you have for them to download, and so on. You may have as many as 32,767 bulletins on your system, as long as you ensure that GHOST knows the proper name (see Renaming the Support Files) and location (see Moving the Support Files) for them, and that you update your bulletin menu for any bulletin # that you want a user to be able to access from that menu (see also Advanced Configuration - Private Bulletins and Libraries).


File Libraries

Just as it does for bulletins, GHOST supplies a default File Library menu (GHOSTL.MNU and GHOSTTL.MNU), and a set of sample download file listing files (GHOST1.DNL and GHOSTT1.DNL), and you may, as you wish edit these and/or add to them as you require for your system.

However, these files are not displayed to the user at logon, but are only available from the File Library menu. There is a further difference which you should consider when working with these files.... if a DNL file does not exist for one of the File Libraries on your system, GHOST will display for the user, a list of the actual files in the directory, similar to the DOS dir command, instead of the DNL.

Using a DNL file for each File Library has several advantages; chief among them is the ability to then add a description for each file, making it easier for your users to locate a file they might need or want.

But there is also a "hidden" reason to use a DNL file... private files. GHOST does support private File Libraries (see Advanced Configuration - Private Bulletins and Libraries), however, this involves increasing a user's security level and several changes to their user record if you want to restrict them to a single Library to get a private file. Then, if that was the only file they were going to get, you would want to change everything in their user record back. A lot of work, and even more so if there is more than one user involved.

Fortunately, the use of a DNL provides an alternate method of doing something like this. Since the DNL shows a user only what you have listed for him to see, as opposed to the actual contents of a directory, it is quite possible to have, in that same directory, files that are not listed in the DNL. However, GHOST does not read the DNL to determine that a file exists... it reads the directory. Thus, if a user knows the name of a file that is in that directory, he can successfully download it, even if it is not in the DNL listing. This means that you may have "private" files on the system, without the need to set up a user for access to private Libraries. All you need to do, is to inform him of the name of the file to download.

As an example of one way to use this.... I have agreed to allow the use of my system as the distribution point for the beta files for another shareware author. This fellow is long distance from everywhere (he is in the "boonies"), and wants a way for his beta sites to get the files without incurring the fairly expensive long distance charges to call his system (running GHOST BBS, BTW <GG>).

On my system, a new user security level of 1 has been set via the GHOST utilities, so new users may only download from Library 1 on their first call, and this might have posed a problem. His beta sites would have to call in to my board, get set up as a new user, and wait to be validated before being able to download the beta files from a private library on my system (not to mention the work on my part to set each of these users up to have access to that private library). The solution was to use the DNL to keep the beta file private, and also in Library 1, where his beta sites could download it on their first call to my system. He simply told each of his beta sites what the file name to download was, they logged on, got the file, and logged off. Quick and simple. Without using a DNL for Library 1, none of this would have been as easy.


Advanced Configuration

The GHOST INI File

The GHOST USR and REC Files

Moving the Support Files

Renaming the Support Files

Customising GHOST

Screen Displays

Prompts

Using ANSI

Using @Variables

Adding Languages

Setting Up File Libraries

Private Bulletins and Libraries

File Transfers

Modem Settings


The GHOST INI file

Although GHOST has a few simple utilities which will set changes to the GHOST.INI file, it was simply not practical to write script utilities to edit EVERYTHING in it. As a result, for most of the more advanced options in GHOST, a manual edit of the GHOST.INI file is necessary, using such applications as NotePad or Norton's DeskEdit.

When editing the GHOST.INI file, it is always a good practice to keep a safe copy of it, perhaps as GHOSTINI.BAK or similar. Since GHOST.INI contains all of the most basic data that GHOST needs in order to run, one must exercise care when editing it, and the use of a safe backup is simply part of that care.

Below is the basic structure of GHOST.INI, along with some notes on what each section contains or controls. Please note, that a section listed as [Section#] indicates that there may be more than one section with a similar name, where the # is replaced by the number of one of the languages defined by the sysop. In some sections, mention will be made of two lines for each file, etc. This refers to the use of the numbers 0 and 1 to indicate non-ANSI and ANSI files respectively. Thus the line

Dnl0=	indicates a non-ANSI file pointer and

Dnl1=	indicates an ANSI file pointer

[Start Up]

contains the basic running information for GHOST, including the default new user security level, what type of system this is (Closed or Open), the number of languages set by the sysop, and so on. Most of the entries in this section can be edited using the GHOST Utilities, Basic Setup Data, and Advanced Options.

[Modem]

The various strings GHOST needs to control the modem while it runs are listed here. They may be edited best via the GHOST Utilities  Edit Modem Strings

[Run Data]

contains all of the information needed by GHOST to determine when it should start, how long it should run, whether it should run a secondary script, etc.

[Languages]

contains a pointer to the location for the prompt files (PMT) used by GHOST, and also a list of the languages available to users of the system (see Adding Languages).

[Security#] (a "multiple" section)

contains the descriptions used by GHOST to tell a user what their current security level is.

[Protocols]

holds the information GHOST needs as to which protocols are allowed batch downloads, how many files are allowed per batch, whether wild card transfers up and down are allowed, and if so, with which protocols, and a "translation" table matching the letters used in the protocol menu with the names used by PCP/Win (see File Transfers)

[Libraries]

contains the pointers for the default GHOST upload path, the list of GHOST download Library directories, the maximum and reserved numbers for both the File Libraries and the Bulletins.

[Lib#]

contains the file pointers for both the DNL files (download listings) and the NWS files (Bulletins)

[Run Files]

contains several very critical file pointers. They are for the GHOST user database, the main GHOST script file (GHOSTRUN), the RingMonitor control script, the user list created from the database of users, the GHOST log file location, the GHOST icon file location, and last, the name of the Win 3.x format help file used with GHOST (the location of this file cannot be changed... it MUST be in the same directory as the PCP/Win executable.

[Mail]

contains the file pointers that GHOST requires to manage and record mail. This includes the basic mail files, the backup mail files, the GHOST MailManager WAX file, and several temporary files used with mail functions.

[Menus#]

contains the file pointers for all of the menus, main, bulletin, file library and transfer protocol. Two entries for each menu, one being the non-ANSI menu file, the other the ANSI menu file.

[NewUser#]

pointers for the files used when a new user logs on, including the header file for the new user questionnaire, the information displayed when a new user fails to complete all of the information in the questionnaire, and the information file shown to new users after a successful logon. Again, two lines for each file, non-ANSI and ANSI.

[Base#]

contains the locations (two lines for each file) of the GHOST on line help files, the welcome screens, and the good-bye screen.

[Registration]

contains registration data for GHOST use. Not user editable.


The GHOST USR & REC files

The default GHOST.USR  and USER1.REC files contain the user record database for GHOST. The GHOST.USR file contains a pointer to the appropriate REC file used to store the actual user information. These files are numbered files (depending upon how many users you have), beginning with the default USER1.REC. Each section of this file is the data for one user. You should rarely, if ever need to edit this file manually, however, should you ever need to edit the REC file manually, here are the contents of a user record in that file (not all of which appear for every user) :

[FIRST LAST]

first_log=	;date the user first accessed the system - information only

password= 	;user password

security=	;user security level from 0 to 5 ("D x", where x is a security number, indicates a deleted user)

pvt_dnl=	;per user allowed access to private libraries for level 3 users

pvt_nws=	;per user allowed access to private bulletins for level 3 users

street=	;user municipal address

city=	;city and prov/state for a user

zip=	;postal/zip code and country for user

phone=	;voice phone number

fax=	;fax/data phone number

transfer_prot=	;default transfer protocol if set

last_on=	;date of last logon

time_on=	;last logon time

time_off=	;last logoff time

alias=	;optional second name for mail searches

There is one thing that you will have to remember, and be careful of, if you ever decide to change the location or name of the REC files.  This can be done relatively easily by editing the GHOST.INI file for the new pointer, but this does NOT change the pointer in the USR file. If you decide to move the REC files to a different location from where they began, or change the name of the REC from USER# to something else, you will also have to do a global search and replace (via a text editor) on the USR file. Since the USR file contains a set of pointers to the location and name of the REC file for each user of the system, it must be changed here as well in GHOST.INI.


Moving the Support Files

The GHOST.INI file contains pointers to all of GHOST's support files. This has a big advantage to you as a sysop, because it means that very little support file information is hard coded into GHOST.

Because of this, you, as sysop, may set up your GHOST support files in a directory structure which makes sense to you. As example, on my system, I use the directory X:\GHOST as a basic support directory, with sub-directories branching from there to contain various files. For me, this makes finding a given type of file easy, and makes system maintenance the same.

As an example of a possible directory structure for GHOST, let's look at mine, and the files that are contained there :

X::

|__ GHOST	(GHOSTRUN.WAX, GHOSTRM.WAX, MAILMAN.WAX, GHOST.NIL)

   |__ HELP	(HLP, WEL, BYE)

   |__ LIBS	(DNL)

   |__ MAIL	(GHOST.HDR, GHOST.MSG, HDR.BAK, MSG.BAK)

   |__ MENUS	(MNU)

   |__ NEWS	(NWS)

   |__ NEWUSER	(NUF)

   |__ PROMPTS	(PMT)

   |__ USERS	(GHOST.LOG, GHOST.USR, USER#.REC, GHOSTUSR.LST)

This is by no means the ultimate set up for GHOST, but it is one which I find easy to use. I can locate a file that I wish to edit quite easily, usually simply by looking at the directory names.

How you might want to set up your support files for GHOST is entirely up to you. You may, if you wish, continue with the default set up of all support files in one directory. The point here is that GHOST allows you the flexibility to set things up as you wish, including renaming the support files to a system preferable to yourself.

To change the location of a given GHOST support file, merely requires a manual editing of the GHOST.INI file to change the pointer for that support file to its new location.

There is one other file which is restricted in its location (although the sysop may, if they wish, change the file name). The entry for this is located in the [Run Files] section, as

HelpName=ghost3.hlp

Under Procomm Plus for Windows, a help file used by a script MUST be in the directory where the Procomm executable is located (\PROWIN as example). It can not be moved to a different location, so please, do not attempt to move this particular file.


Renaming the Support files

In general, almost any support file for GHOST may be renamed by the sysop to a file name which he may feel is more appropriate for his use. The default naming scheme for GHOST BBS, uses, as part of the file name, GHOST to indicate an ANSI support file, and GHOSTT (with an extra T) to indicate a text (or non ANSI) file. This may be suitable for some, however, perhaps others would prefer to use ANSI and TEXT in the file names to distinguish the two types of support files.

Other sysops may prefer that the GHOST screen display help files have an extension other than HLP, to avoid any possibility of errors occurring because of an incorrect launching of the Windows Help Engine, which Windows associates with files that have that extension.

Wherever possible, GHOST will accommodate these sysop changes. All it normally requires is to locate the pointer for that file in the GHOST.INI file, and modify it to change the name of the support file that GHOST will use. This procedure is very similar to that used when moving a support File, and indeed, the two changes may be made at the same time, if you wish.

However, there are several files which have restrictions upon the names that can be used. Basically, these restrictions arise because GHOST is internally adding certain information to data taken from the GHOST.INI file, in order to determine which file to search for.

There are four types of support files to which the above applies. In all four cases, GHOST will supply two portions of the completed file name; a number of some sort to indicate which of multiple files is needed, and the file extension for that type of file. One can see these entries in the GHOST.INI file fairly easily, because, unlike all of the other pointers in that file, these entries do not have a complete file name, i.e. an extension. One is in the [Languages] section, and the others together make up the complete [Lib#] sections.

In the [Languages] section of GHOST.INI, you will find a line for

PromptFile=

This line will contain a file path, and a portion of a name (the default name is LANG), but no extension for the file. The reason is that GHOST supports up to 99 different languages(see Adding Languages), and must determine which prompt file is needed while a user is logged on by adding the language number they have chosen (default for a single language system is a 1) to what it finds in the GHOST.INI file, and then adding the extension PMT to that. Thus, for a default English logon, the prompt file would be LANG1.PMT when GHOST was done.

You may replace the default file name base of LANG with anything you chose, providing it leaves enough room for the number of languages installed. Since DOS file names must consist of eight characters maximum, and GHOST needs at least one of those for the default "1", the maximum characters for the INI file name portion is seven. If however, you have set GHOST for more than 9 languages, this maximum is reduced to six so that GHOST has room to add numbers from 10 up to your maximum.

The same general principals apply to the entries in the [Lib#] section, which are for

Dnl0=	;the DNL files for non ANSI

Dnl1=	;the DNL files for ANSI displays

Nws0=	;the Bulletin files for non ANSI

Nws1=	;the Bulletin files for ANSI display

These entries are restricted to names determined in a fashion similar to those for the prompt files, however, because of higher maximums allowed for bulletins and download libraries (up to 32,767) the maximum number of characters allowed here is eight less the number of characters in your maximum settings for each. As example if you have a maximum number of file libraries set at 150, and the maximum number of bulletins set to 35, then the DNL lines above could use a filename portion of up to 5 characters, while Bulletin file entries above could use a filename portion of up to 6 characters.

To these filename portions, GHOST adds the number of the file it is looking for, along with the extension DNL for the file library listings, and NWS for the bulletin files.

The last file to which this applies is the user record database files. Due to Windows limits on INI format files, GHOST 3.00 stores the user records in a series of these, with the pointer to the REC stored in the USR file (see The GHOST USR and REC Files). The entry for this file is located in the [Run Files] section of GHOST.INI as :

UserPath=

You will also find a second line here, which GHOST uses to determine the location for new user record storage. This line is :

CurrUser=

and should never be edited. It is an internal pointer for GHOST, and is set by GHOST itself as needed.

When GHOST determines that a REC file is larger than 55,000 bytes in size, it will create a new REC, based upon a number stored in the GHOST.INI file, and the data for the user record path as stored above.

The extensions added during these procedures (PMT, DNL, NWS, REC) are hard coded in GHOST, and can not be changed by the sysop (for now <GG>).

Other than these few limitations, any GHOST support file may be renamed to any valid DOS file name, by the sysop. Future versions of GHOST will read this information from the INI file, and use it when upgrading the various support files.


Screen Displays

In general, it is a good idea to limit any display files that you create (menus, etc.) to less than 21 lines total. This is because GHOST will almost invariable use two lines (one for a blank line, one for a prompt) out of the normal 23 line single screen for itself. There are a couple of exceptions to this "rule" however...

Two menus may not be possible to create as a maximum 21 lines; the Bulletin Menu, and the File Library Menu. If you are using too many Bulletins or File Libraries to fit into a single 21 line screen, GHOST will scroll these menus. Since the prompt includes a method for the user to re-list them (the 0 response), this should not be a problem. If possible, however, keeping both of these files to 21 lines or less will make things easier on your user

The other files which have different "rules" are the welcome and goodbye screens, and the new user questionnaire header file (NUHEAD.NUF).

The welcome file should, if possible, be no longer than 17 or 18 lines, in order to accommodate the logon prompts which appear on screen with it. The goodbye screen should be kept to 15 or 16 lines, because it will appear with logoff information. Since GHOST does not issue a clear screen command to the remote at logoff, anything on screen then will remain on the remote screen after they are disconnected. If the goodbye screen is longer than 15 or 16 lines, some of it will scroll off screen before logoff, and thus, the effect will not be the same.

Finally, the NUHEAD.NUF file, which is used to provide information to a new user regarding the data required in the questionnaire; since the questionnaire lines will appear below it, and there are 5 of these (plus a blank "separator" line), this should be limited to no more than 15 or 16 lines total (and 4 or 5 lines is best).


Prompts

The prompts for GHOST are contained in the PMT file. Virtually all GHOST prompts may be edited by the sysop as to text and ANSI coding (see Using ANSI), along with language if one is using an alternative language set up (see Adding Languages). However, one can not simply edit them at will, without remembering a few items to watch for.

First, remember that GHOST has a maximum display width of 80 characters. Since most of these prompts require user input after they are placed on screen, one should not create a prompt line that is in excess of around 78 displayed characters, less the room that GHOST will need to get the user input. When you edit a prompt, remember where it is used, and what will be input after it, and you should have little difficulty.

One also must remember the Wasp limitation of 255 characters per string, displayed or not. This means that any given prompt can not exceed 255 characters inclusive of ANSI codes, etc. In other words, don't get carried away with the ANSI coding and make each letter of each word a different colour, or you may run into the 255 character limitation on strings.

A sysop should also remember that his users may be logging on using a script. Indeed, the GHOST distribution files come with one (GHOSTLOG) in both compiled and source form, that you may put on line for your users to get if they are using Procomm Plus for Windows. But... this script is designed to watch for, and react to the "?" at the end of the default GHOST prompts. If you decide to change to something other than this "?", you may mess up the use of scripts to log on to your system. If you do change things like this in your prompts, make sure that your users are aware of the custom prompts, and can modify their scripts accordingly.

The last item to remember when editing prompts, is that GHOST uses  triggers to determine what action it will take. As example, when downloading files, GHOST will prompt the user (after he has made his file request) as follows

[G]oodbye when done, [A]bort, [Enter]=continue ?

Here, the triggers are G, A, and the Enter key. These should not be modified if possible. However, if you do want to change the wording of the prompt such that these triggers are no longer viable, it is possible to change them. One needs to set up a translation table for these trigger keys in the PMT file for that language in order to do this.

Most of the prompts in the PMT file are fairly straightforward, but some of the entries are somewhat more obscure in meaning. For an explanation of some of these take A Look at the PMT File Contents .


Using ANSI

There are many ways to use ANSI with GHOST. Virtually all screen displays and prompts can be edited to contain ANSI coding which can change screen or text colours, cause text to be bold or dim, and so on. This file is not intended to be a primer in the use of ANSI coding for screen displays. For the basics of this, you should consult either your DOS documentation (in Appendix - Installable Device Drivers for DOS versions earlier than 5.0, or by typing HELP ANSI.SYS at the DOS prompt for versions 5.0 and 6.0).

However, since I myself was a rank amateur at this when I began work on GHOST, and only added support for ANSI codes at the constant urging of Ralph Beemer and David Head, perhaps some tips and tricks may be in order.

One thing to do is to ensure that the editor which you use to edit the GHOST files allows the entry of ANSI escape codes in some fashion or another. Editors such as Qedit in the DOS world, allow several methods of doing this, not least of which is the use of the ALT-Number pad key combinations to enter non-displayable keys, such as escape (ALT-27). Coupled with this, if you are using a Windows editor, you should also make sure that it will display the ANSI characters you use as they will appear in GHOST. Editors such as Notepad are limited this way, but those such as the Norton Desktop for Windows Desktop Editor, allow the user to change the screen display font. By selecting the OEM fixed font, the screen will display lines drawn as proper lines, the escape character as an arrow and so on, making the editing of ANSI displays in GHOST much easier.

ANSI code sequences are called "escape sequences", simply because they require the use of ESC (ANSI char 27) as the first character in the sequence to indicate that this is an ANSI code sequence, immediately followed by an "[". Generally, the most common use of these escape sequences in menus or prompts for a BBS, are to set colours to be seen by the remote user. DOS gives a complete list of the numbers used to control colours, but the general format for an ANSI colour sequence is

{ESC}[{attribute};{foreground};{background}m

The most commonly used attribute codes are either 0 (normal) or 1 (bright). Although the format above is the basic, not all elements of it are necessary. You only need enter the element if you are changing from whatever is currently set. In its default set-up, GHOST uses cyan text on a black background for the basic ANSI display. The code for this (in the LANG1.PMT file, section [Prompt1], line ClearScreen=) is

{ESC}[0;36m

Since the DOS default is a black background, an entry for the background is not necessary. In the above, 0 indicates a normal attribute for the colours, 36 the cyan foreground (text) colour. What if, as default, you preferred white text on a blue background? Simply change the code in the ClearScreen line from {ESC}[0;36m to {ESC}[0;37;44m. (Trust me... with a little practice, this is not as difficult as it first appears <G>) Just one thing... also in this line of the PMT file, you will find another ANSI escape sequence, {ESC}[2J. DO NOT REMOVE THIS ANSI SEQUENCE! This sequence is the ANSI code to clear the screen, and must be there for GHOST to operate properly.

If you would like some simple examples of designing menus with DOS ANSI escape sequences, take a look at the default GHOST menu files, such as GHOSTL.MNU, GHOSTB.MNU and the main GHOST menu, MAIN.MNU. These are not the greatest menus ever designed, but they were all done without the use of an ANSI drawing package, i.e. simply by entering codes for the colour changes.

Of course, there are DOS level applications which can be used to design ANSI screens. Most of these were written specifically to answer the ANSI needs of sysops, and quite a few of them are shareware, including two commonly used ANSI drawing programmes, TheDraw and Laughing Dog (hey, I don't name them, just list them...). When using these ANSI drawing programmes to design screens for GHOST, try to remember to stick to the limits on these files as explained in the Screen Displays section of this help file.

For those who may want a starting point, take a look at the sample screens drawn by Vlad Balak of Australia for inclusion in GHOST. You can find these samples in the file SCREENS.EXE in the distribution files.


Using GHOST @Variables

GHOST BBS supports the use of a limited number of PCBoard style @variables in prompts. These variables allow the sysop to further customise prompts by including information in them pertinent to the current user on line.

Using these @variables is fairly easy.... simply place one of them in a prompt where you would like the corresponding system information to appear. As example, the default main menu prompt (MainMenu= in the PMT file) is

(@ONLINE@ min. online) Main Menu Command, @FIRST@ ?

When reading this prompt, GHOST would replace the two @variables with their corresponding system value, and the user would see something like

(10 min. online) Main Menu Command, GREGG ?

These @variables may be used in any prompt on the system, but, as with any other prompt editing, you must take some care. Remember both the line length limitation for GHOST prompts (80 characters less user input), which the replacement for an @variable can change, and also the maximum Wasp limit of 255 characters for a string.


*Adding Languages
Adding Languages

Although used in many parts of the world, English is far from a universal language. Even for many of those who are required to know the language and use it for commercial and other purposes, it is not as comfortable as whatever their native tongue may be. With early versions of GHOST BBS in use basically within the confines of continental North America, this was not a major concern. But as GHOST began to travel, and came into use in Europe, the Far East, and elsewhere, the use of English as the sole language in GHOST began to emerge as something of a concern to sysops. The end result of all this is that GHOST now supports the use of up to 99 languages.

To add an additional language, the sysop needs to do several things..

1) The sysop will need to create support files for the new language. This may or may not include new language versions of every support file GHOST displays on screen, such as the MNU, NWS, DNL, HLP, and NUF files, and the creation of a PMT support file for the new language, with, of course, all text and prompts translated to the new language.

2) Wherever possible in the menus and prompts, it is best to maintain the same trigger keys for all languages. However, this is not always feasible, so GHOST allows for it through the use of  translation tables for trigger keys in that language. There are actually 6 separate translation tables for each language in its appropriate PMT file. The default prompt file, LANG1.PMT, shipped with GHOST includes the section headers for all 6 tables for you to use in a PMT file for a new language. These sections are:

[Main]

translation table for all commands on the various main menus, both regular user and high security "sysop" menus

[Y/N/Q]

translation table for prompts which use either the Y/N (Yes/No) query, or the Y/N/Q (Yes/No/Quit) query in the English form of the prompts, e.g. ANSI=, NewMail=, or MailSendOK= in the PMT file

[NewLog]

use this section to translate the trigger keys for the prompt which appears when a user's name is not found in the database, i.e. when they are a new user and will be shown the NewUser= prompt

[DoneTrans]

this will translate the trigger keys for the prompt given a user for options upon completion of a file transfer, i.e. the DoneTransfer= prompt

[SendMail] and [ReadMail]

for those prompts used when sending mail or reading it, i.e. the SendOptions= and ReadOptions= prompts

3) Once all of the basics for a language are completed, GHOST will need to know where to find these files. This is done by adding sections to the GHOST.INI file. Assuming that English is the default language (i.e. # 1), and the new language is language # 2, the sysop would need to add the following sections to the INI file; [Security2], [Lib2], [Menus2], [NewUser2], and [Base2]. The simplest way to do this is to copy the sections with a 1 in them, then edit the pointer for each file to the appropriate ones for the new language.

Once all of this is done, GHOST will need one last bit of information; in the [Languages] section; a name for the new language to be used in the menu at logon (Lang2= ).

GHOST is now ready to use a second language if the remote user requests it, but that second language is not yet enabled. To enable its use by GHOST, load the GHOST Utilities, and select the Advanced Options button. Change the entry for Maximum languages from 1 to 2, and save the change. The next time GHOST is run, a user will be presented with a language options menu at logon, giving him the choice of either of the two languages installed and enabled.

The same procedures must be followed for each new language added to GHOST.


Setting up File Libraries

GHOST BBS 3.00 supports up to 32,767 File Libraries (or download file directories), including a sysop defined number of private File Libraries (see Private Bulletins and Libraries). These File Libraries may be on the same drive as GHOST, a different drive, or, may even be on several different drives. As long as GHOST can locate them via the listings of the [Libraries] section of GHOST.INI, and they exist, GHOST will use them.

Setting up these libraries is fairly simple. Obviously, the first thing to do is to create them all. Then, both the GHOST.INI file, and the Libraries menu file must be modified so that they list the libraries a user may chose from AND so that the two sets of information match. The number a user selects from the Libraries menu list must match the number used in the Download#= line of GHOST.INI's [Libraries] section, or confusion will result.

There are, however, a couple of things to consider when setting up your file libraries. Perhaps the most important consideration is based upon understanding how GHOST searches for a file when the user requests it for download.

When a user requests a file for download, GHOST searches each directory listed in the [Libraries] section for it (unless the library is private and the user does not have access to it). The directories are searched in numerical order starting at the Download1= entry in the INI. As soon as GHOST has found the file, it stops searching. This affects the time it takes to locate a file after a user has asked for it. Obviously, the more directories it must search, the longer it takes to do so.

There are things a sysop can do to speed up this searching for a file, however. Obviously, one of these is to simply use a reasonable maximum number of file libraries so that GHOST doesn't have to search as hard. But the organisation of the file libraries also can be important. Basically, if the files on your system which are popular, the ones that are downloaded most frequently, are stored in the first few libraries listed in the INI, GHOST will obviously find them that much quicker.

By checking the log file frequently to see which files are being downloaded, and some careful organisation of download files and libraries based on that information, a sysop may help keep a user's time on line down to a minimum.

One more thing... with the advent of DOS 6.0, and the popularity of utilities like Stacker, compressed drives are becoming more and more common. When GHOST is running, it doesn't care a fig if the drives it uses are compressed or not. However, you, as sysop, may. Since ZIP files are compressed already, storing them on a compressed drive is perhaps a waste of the space your compression utility gains you. If you are using a compression utility, you may want to keep your download libraries on an uncompressed volume, if the files available for download on your system are mainly ZIP files. There is no performance gain or anything similar from doing this. It simply doesn't waste the compressed volume in storage of files that can't be compressed when stored.


Private Bulletins and Libraries

OK, so you've told GHOST (through the utilities) how many bulletins and file libraries you want on the system. But now, you want to set some of these up as private, and restrict who can see them.

The first thing to do is to decide how many of each you want reserved as private. GHOST will take that many bulletins or libraries from the TOP, i.e. the higher numbered bulletins or libraries, and treat those as the private bulletins or libraries. As example, let's assume that you have told GHOST that you want a maximum of 30 file libraries. If you then tell GHOST to reserve 10 of those as private, they will be libraries # 21 through 30. To tell GHOST to reserve a number of private bulletins or libraries, you use the GHOST Utilities - Advanced Options.

Once you have defined a number of libraries or bulletins as private, anyone with a security level less than 3 (i.e. new or normal users) will not be able to access them. In the case of bulletins, no matter how new they are, GHOST will not show private bulletins to a user at logon unless they are security level 3 or above.

In this fashion, a sysop may set private bulletins or libraries on a global basis for GHOST. However, there is still another setting of private files which GHOST will allow, that being a per user setting.

To illustrate this, again we'll use my system. I use private bulletins and libraries (both being #s 20 through 29) for, amongst other things, my beta testers to have access to the files and information they need for that. Since I currently have two different script applications (GHOST and PCB Freedom), I have one of these private libraries and bulletins set for information and files for each application. For most beta sites, global access to the private areas is fine, however, I have a couple of GHOST sites that don't use PCB Freedom. As a result, I limit their access to only the GHOST beta private areas.

To do this is a fairly simple procedure, again, using the GHOST utilities. This time, however, since the control is on a per user basis, you use the Edit User Records utility. In that dialog, there are two entries, one for Pvt Libraries and another for Pvt Bulletins. To limit a user to accessing only certain private areas, you need to specify those areas to GHOST here. For each entry, simply enter a list of the numbers the user is allowed to access.

The only condition on that list is that the numbers entered must be discrete, i.e. separated in some fashion so that GHOST can locate one number amongst those listed. To accomplish this, simply use some form of separator in the list. Valid lists might be "20,22,27,29" or "20 22 27 29", while "20222729" is an invalid list since there is no separation of the individual numbers.

Of course, per user restricted access is only applicable to security level 3 users for file libraries. Since security level 4 or 5 users can access ANY directory on your system, setting Pvt Libraries for a level 4 or 5 user has no effect.

Before we leave this discussion of private areas, perhaps this is a good spot to discuss private FILES (not libraries or bulletins, but individual files). GHOST does have a method of allowing private files without having to set a user's security to 3, and/or setting up private library access for that user. If you are using a DNL file as the list of files in a given library, a remote user will see that file whenever he asks for a list of the files in that library. However, that DNL contains only those files that you, as sysop, have placed in the list. It does not contain the actual contents of that directory (matter of fact, on my system, the release files for GHOST and Freedom are shown in several different libraries, even though the actual files are only contained in one directory).

BUT... when a user asks to download a file, GHOST searches the actual contents of the directory to locate it. Suppose you have, in Library 2, a file GUEST.ZIP, which is NOT included in the DNL listing for that library. No one would know it is there (since it is not in the listing), and thus, they would not ask to download it. If, however, you were to leave a private message to one of your users, telling him that the file GUEST.ZIP is available for him to download, he could quite readily download it, since, when he requests a file by that name, GHOST would locate it as a valid file for downloading.

This gives GHOST a simple method of having private files available to selected users, without the need to increase their security level, and so on.


File Transfers

By default, GHOST BBS allows the use of all internal file transfer protocols available in Procomm Plus for Windows. However, Procomm Plus for Windows also supports the use of external transfers protocols, written as a special form of DLL file, called a DLP (Dynamic Link Protocol). An external transfer protocol, written in this format, will appear to Procomm Plus for Windows as an additional "internal" protocol, i.e. it will be part of the list of available protocols in all set up functions.

To date, there is only one external protocol available in this format, Samuel Smith's HS/Link protocol. In one way, I am grateful that Mr. Smith's protocol was released, even if in beta, before I finished working on GHOST 3.00. This allowed me to write support for external protocols into GHOST BBS, and test it prior to releasing GHOST 3.00.

Adding an external protocol to GHOST is as uncomplicated as I could make it, and still support several features of any protocol written in this DLP format. The first thing to do is, of course, to install the DLP protocol into Procomm Plus for Windows, and configure it as you wish.

Once installed in Procomm Plus for Windows, all the sysop needs to do to enable the new protocol under GHOST is to tell GHOST that the protocol is available. This is done by adding an entry in the [Protocols] section of GHOST.INI to let GHOST see the protocol. That entry is in two parts. The first is a letter which matches the one that you will use for selecting the protocol from the menu of available transfer protocols (as example, we'll use H for HS/Link), followed by the usual = sign. The rest of the entry depends upon the root of the DLP file for the protocol which you are adding. Again, using HS/Link as example, the DLP file in the distribution ZIP is HSLINK.DLP. Thus, an entry to add the HS/Link DLP format protocol to GHOST might be

h=HSLink

Once this is added, don't forget to edit the protocol menu files to show the new protocol to your users.

Now, you need to know two things about the new protocol; 1) Does it allow wild card file transfers and 2) does it support auto-downloading (which means that GHOST may use it for batch file transfers)?

If the new protocol allows wild card transfers (HS/Link does), if you wish to allow their use in GHOST, you must add the transfer protocol trigger letter (in our example, H) to the entries in the [Protocols] section of GHOST.INI for wc_down= and wc_up= as necessary.

If the new protocol supports auto-downloading, it can be set up as a batch file transfer protocol under GHOST (HS/Link does support auto-downloading). To enable this, all you need do is to add the trigger letter for the protocol to the [Protocols] section entry batch_down= .

That's it... the new protocol will now be available for your users.

While we are here though, let's discuss wild card transfers. GHOST 2.00 implemented batch file downloading, but in the process, eliminated support for wild card file transfers. The reason for eliminating them was simply that I was unable to come up with code for the batch file downloading routines which would successfully handle wild cards, before the release of 2.00.

With GHOST 3.00 however, wild card file transfers are re-enabled. However, because of the search methods employed by GHOST when using multiple file libraries, wild card transfers can only be enabled for level 4 or 5 users of your system. The enabling of wild card downloads for level 4 and 5 users is automatic during the installation of GHOST. It may be disabled as a feature, by the sysop, if they remove the line wc_down=ZGKYH in the [Protocols] section of GHOST.INI .

However, the installation of GHOST does NOT enable wild card uploading. There is a reason for this... in my opinion (and it counts because I wrote the installation routines <G>), wild card uploads for level 4 or 5 users, coupled with the ability to upload to ANY directory of the host system, is dangerous. This danger exists simply because there is then no overwrite protection, and the remote user could easily destroy critical files on the host system, if a mistake were made during the upload. I therefore feel  it safer to NOT have the installation routines enable wild card uploads, but, rather, to leave doing that in the hands of each individual sysop.

Should you wish to enable wild card uploads for level 4 or 5 users, simply copy the contents of the wc_down= line to the wc_up= line.


Modem Strings
Modem Settings

Although a lot of systems will operate absolutely perfectly running GHOST and using the default settings for the modem as defined in WMODEMS.DAT, some systems may require some "tweaking" for better operations. Now, I am far from a modem expert, however, in conversations with sysops of various bulletin boards, and other users of GHOST who do know something about modems, I have discovered that they often use custom initialisation strings for their systems when running as a BBS. The GHOST users, however, complained that they would have to set up their modem with this init. string for GHOST every time they wanted to use it, and this was quite a headache.

To this help eliminate this problem, the ability to store and use its own init. strings was added to GHOST 3.00. These strings may be edited via the GHOST Utilities - Edit Modem Strings, and can be customised by the sysop for his system.

In general, there are apparently three of the standard Hayes "S" registers which can be "tweaked" for BBS operations, S2, S10, and S12.  I can not, and will not make recommendations as to any changed settings for these S registers, since I do not understand them well enough myself to do so. I can make comments here, however, based on the information I have been given as to the purpose of these registers.

S2 - Escape Character - this setting controls which "escape" character is recognised by the modem in order to switch from Data mode to Command mode while maintaining the connection with a  remote. The default value for this is 43, or the character "+", however, many sysops tell me that they prefer to change this default to prevent a remote user from somehow inadvertently entering this character three times, and switching the host modem to command mode.

S10 - Carrier Loss Time - which determines how quickly the modem recognises a carrier loss as an actual "lost carrier". On some lines, depending upon noise, a carrier may be momentarily lost, without there actually being a disconnect. The setting of this register controls how quickly the modem decides that a carrier loss is actually to be treated as a hang up. Default value is generally 14, in tenth's of a second (or 1.4 seconds). If your users are being disconnected too quickly, or GHOST is not recycling fast enough between calls (because it is taking too long to recognise the dropped carrier), you may want to look at this setting.

S12 - Escape Character Guard Time - which controls the amount of time before and after one enters the three escape control characters ("+++").  This guard time prevents the modem from misinterpreting the escape characters as data, and likewise, can, if set to a longer time, prevent these characters sent as data (say in a message, etc.) from being interpreted as the modem escape characters. Default value is  generally 50, in fiftieths of a second (1 second).


Utilities - Basic Set Up

Click on an edit box or option choice for further help.


Utilities - Advanced Options

Click on an edit box or option choice for further help.


Utilities - Edit Modem Strings

Click on an edit box or option choice for further help.


Utilities - Run Mail Manager

Click on an edit box or option choice for further help.


Utilities - Edit User Records

Click on an edit box or option choice for further help.


Prompt File Contents
A Look at the Prompt File Contents

There are basically two sections in the PMT file, [Prompt0] for non-ANSI, [Prompt1] for ANSI prompts. Most prompts are fairly easy to understand as to where they are used, but there are some that might need a little explanation...

ClearScreen={ESC}[2J

commands to be used when GHOST clears the screen. At the least, this MUST include the ANSI clear screen code above. It may also contain ANSI coding to change the default colours, both foreground and background.

ResetAnsi={ESC}[0;37m

The default ANSI code here sets the text to white on a black background. This code is sent when a user selects the M menu command, and the use of this menu item results in ANSI graphics turned off. It can and should be the same for both the [Prompt0] and [Prompt1] sections.

SetChoice=Choice, [Enter]=exit ?

This is a multipurpose prompt. It is used in most spots where a user has a choice to make from multiple options, generally indicated by numbers, but not always.

NotUser=@FIND@ is not a user of this system.

FoundUser=@FIND@ was located in the user files.

These two prompts are not prompts per se, but GHOST responses to a user action. They are used when a user of the system either uses the [L]ocate menu command to see if someone is a user of the system, or when a user is sending mail, the NotUser= line is displayed when the To: address in the mail is not a user of the system.

ListDir=Directory, [Enter]=@DIR@ ?

This prompt is only applicable to level 4 or 5 users who are allowed to select the directory they want for a file listing.

StopEdit=[ESC] when done...

When entering mail, or chatting with the sysop, the trigger to exit either mail edit mode, or chat mode, is the escape key. This prompt appears before either activity, so that the remote user is aware of which key to use.


Shareware

Shareware is copyrighted software which is distributed via electronic means. It is neither public domain nor free, requiring the payment of a registration fee after an evaluation period is complete.


Sysop

The SYStem OPerator is responsible for maintaining the system, and keeping the BBS running properly.


Section

In an INI format file, a section is a group of statements defined by some term enclosed in square brackets as a header for that section.


Pointer

A GHOST pointer is a line in the GHOST.INI file which tells GHOST where to find the file or data that it requires.


GHOST Utilities

GHOST BBS ships with a utility script which allows the sysop access to various settings in the INI file without having to use an editor to manually change them. The utilities also allow the sysop to manage the mail, and the user record database.


Trigger

In GHOST BBS terms, a trigger is a key which is used after a prompt to "trigger" an action as a result of entering that key.


Translation Table

Each GHOST prompt file (PMT) may contain up to six defined translation tables. These tables can be used to tell GHOST that the triggers it is expecting are to be replaced with the translated keys.


CompuServe  Gregg Hommel, 72537,552

Internet    gregg.hommel@canrem.com

FIDO        1:229/15


Gregg's Place BBS

(519) 745-9717 - operating from 11:30 PM to 6 AM Eastern Time - support for up to 12K connects (with a remote v.32bis modem)


Disconnect user!

This menu item will only be active when a remote user is on line, and it does basically what it says, i.e. selecting this menu item will result in an immediate disconnection for the remote user. GHOST will then recycle to wait for a new call.


Chat with user

Allows a sysop to interrupt whatever a remote user is doing on line, and force a chat with him. When selected, the screen will be cleared (both remote and local) and a message put on the screen informing the remote that the Sysop wants to chat. After a short pause, GHOST will enter chat mode. This menu item will be disabled (greyed) whenever the remote user is "inaccessible", i.e. when he is reading or entering mail, during file transfers, and so on.


Recycle!

This menu item will only appear during a "local logon". When selected, GHOST will immediately recycle and wait for a call. It is a quick way to get back to the "Waiting for call" dialog, without having to go through the [G]oodbye menu item.


Exit BBS

As the name implies, selecting this menu item will disconnect any users on line, and then exit GHOST back to the launcher script. If mail has been deleted during this session, GHOST will pack the message base during exit.


Help

Does just what it says... calls this help file (Pressing F1 while a user is on line will do the same thing)


Help

Calls up this help screen


About GHOST

Clicking here, will bring up the GHOST "About" dialog. This dialog will be different for the shareware and registered versions, but the basic information contained (about GHOST, and its authors) is the same.


Your BBS Name

The text entered in the BBS Name edit box is the text which will be shown to a user at logon, identifying your system for them. You have a maximum of 74 characters, including spaces, for this text, i.e. one line on the display at logon. Since this line is displayed prior to any user choices being made, ANSI coding and @variables are not allowed here.


Upload Directory

All files uploaded to your system, by level 3 or lower users, are stored in a single upload directory, so that you may scan them for viruses, etc. before posting them on your system. This edit box tells GHOST where that directory is located. Since uploaded files will likely be ZIPped, you might consider using an uncompressed drive for this directory.


Download Library #1

Although GHOST optionally supports multiple File download Libraries, the minimum number that must be set up is 1. This edit box is for that purpose, i.e. to set up the directory for File Library # 1. The directory set here is also the directory which will be used for new user downloads, if you have set the new user security level to 1. To make most efficient use of disk space, if you expect to have ZIP files on your system, locate this directory on an uncompressed volume.


New User Level

When a new user logs on to an Open system, he will be assigned a default new user security level. GHOST allows the sysop to choose one of three levels for this purpose, determined by the button selected here :

Restricted - the new user is allowed to read mail and browse the system only, until validated

Limited - the new user can read mail, download from Library 1, and browse, but can not upload files, until validated

Normal - a new user is given full normal security for the system when he logs on.


System

GHOST allows two different system "types", Open and Closed. On an Open system, new users are allowed to log on at any time, subject to the validation later, by the sysop. In a Closed system, new users are not allowed a log in. Rather, they must be set up in advance, in the user database, by the sysop. Under a Closed system, if GHOST can not find the user name in the current database, it will not allow the user to continue logging in.


Connection

Under most circumstances,  the selection in this box will be for a Modem connection. However, some GHOST systems are Closed, and do not use telephone lines for the connection. Instead they connect via null-modem cables. These few systems should be set for a direct connect.


Save

Selecting this button will save any information you have added or changed to any of the fields or choices in this dialog box.


DL Batch Maximum

This edit box allows the sysop to define the maximum number of files allowed by GHOST in a single batch file download. The default installation value is 10, but it can be set for any number of files the sysop chooses. We do not recommend a number here larger than 99.


Maximum Languages

By default, GHOST BBS is set for one language, English, as a default. However, if your users speak other languages, it is possible to set up menus, prompts and screens in other languages (see Advanced Configuration - Adding Languages for more information). If you wish to set up other languages for your users to optionally log on to the system using, then you must change the number in this box in order to enable them. GHOST allows a minimum number here of 1, and a maximum of 99.


Word Wrap mail/chat

The sysop may, at his discretion, decide that the default word wrap location used by GHOST (at 76 characters) when displaying messages and the chat screen, is too long. If so, this is where he would change that setting. GHOST allows a number from 55 to 76. The number entered here is used by GHOST as a guide. To wrap text, GHOST begins looking for a "space" anytime after a point 15 characters before this maximum. If it finds a "space", it assumes this to be the end of a word, and wraps the next word onto a new line.


Maximum # of libraries

GHOST allows a sysop defined maximum number of File Libraries to be recorded. This number can be anywhere from 1 to 32,767. However, when a user asks for a file to download, GHOST will search all Libraries recorded in the INI file for a the requested file. GHOST does this by reading from the INI file for each Library in numerical order. Thus, if you have set the maximum to 500, GHOST will have to read the INI 500 times to see if that number has a directory associated with it, and this can become time consuming.

Because of this search for files, you should keep this number to a reasonable level for your anticipated needs. It can always be changed later if necessary. We recommend a maximum of 29 or 30 Libraries for most systems, unless you have specific need for more.


# of private libraries

Dependent upon the maximum number of File Libraries set by the sysop, GHOST also allows him to "reserve" a particular number of these as "private" (i.e. for access by security level 3 and above users only). These private libraries are "reserved" at the high end of the allowable libraries. As example, if you have defined 30 as the maximum number of File Libraries, and reserve 10 of those as private, the first private library will be Library # 21. GHOST accepts a number here ranging from 0 to 1 less than the maximum defined libraries.


Auto logoff seconds

When a user logs off your system, in a default installation of GHOST, they will be presented with a "timed" prompt, allowing them to change their mind, and return to the system. If nothing happens within a defined time period, the logoff will go ahead. This box is where you, as sysop, can define that logoff time. The allowable number of seconds for this box is from 5 to 60.


Maximum # of bulletins

GHOST allows a sysop defined maximum number of Bulletins to be recorded here. This number can be anywhere from 1 to 32,767. However, when a user logs on to the system, GHOST must search for each of these bulletins on the system, and check the file date and time to determine if it is "new" for this user. If so, he is shown the bulletin. This obviously can become time consuming, depending upon the number of possible bulletins that GHOST must search for.

Because of this search at logon, you should keep this number to a reasonable level for your anticipated needs. It can always be changed later if necessary. We recommend a maximum of 29 or 30 Bulletins for most systems, unless you have specific need for more.


# of private bulletins

Dependent upon the maximum number of Bulletins set by the sysop, GHOST also allows him to "reserve" a particular number of these as "private" (i.e. for access by security level 3 and above users only). These private bulletins are "reserved" at the high end of the allowable bulletins. As example, if you have defined 30 as the maximum number of bulletins, and reserve 10 of those as private, the first private bulletin will be Bulletin # 21. GHOST accepts a number here ranging from 0 to 1 less than the maximum defined bulletins.


Keyboard inactivity

A remote user logs onto your system via a script. However, when that script logs on, the remote user is actually having dinner, and not there to know that the script has logged on to your system. GHOST remains at the main menu command for the next hour and a half until they have finished dinner, and they realise they have made a connection. Meanwhile, your system is tied up for that hour and a half, and the remote user is angry because he will have a huge LD bill for that call.

To prevent this from happening, GHOST allows the sysop to define a number of seconds for a keyboard inactivity time-out. If there is no activity for that time period, GHOST will log the remote user off the system. The number of seconds before this happens is set here. It can be in the range of 60 seconds through 32,767. If you wish to disable the keyboard inactivity checking, place a 0 in this box, and GHOST will no longer check for keyboard inactivity from the remote user.


Clear Display for

Normally, GHOST will "scroll" the display of files to a remote user. This is quite useful, say for file listings, as it allows the remote user time to read the list, even if it is scrolling off screen. However, at other times, speed is more of a concern, and this scrolled display of a file is quite a bit slower than if the screen is cleared between "pages" of the file. By default, GHOST will scroll all displays of files. For those, files that you do not want GHOST to scroll the display, enter the extension applicable to those files here. Files such as the NWS (bulletin) files are good candidates for a listing here.


Goodbye Option

When a remote user logs off, GHOST can optionally perform one of two actions. Normally, GHOST will "Recycle", i.e. it will set all system variables back to default, and reinitialise the modem for another caller. However, if you are using GHOST differently, such as only for friends or business associates to call at prearranged times, to do some file transferring, you may want to have this option set to "Exit" which results in GHOST shutting down when a remote user logs off.


Autobaud

Most high speed modems, and some slower ones, operate in answer mode best when they are set with the modem autobaud detection feature disabled. Others (like my ZOOM 9600 Turbo) operate better when autobaud detection is enabled. To accommodate all types of modems, GHOST will enable or disable autobaud detection based upon the selection in this box.


Modem Init. String

Enter the modem initialisation string that you want GHOST to use when setting itself up. Although in most cases, the default modem initialisation string will work fine here, some users of GHOST have informed me that their modem requires certain changes in order to operate GHOST efficiently (see Advanced Configuration - Modem Settings). If you wish to use a customised initialisation string for GHOST to start up with, enter it here. (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


Modem Reset String

Enter a modem string for GHOST to use at shut down, to reinitialise the modem to the settings which you require when in Procomm, but not with GHOST running. GHOST will use this string to reset the modem for other uses when it shuts itself down (or is shut down). (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


AutoAnswer On String

Enter the string GHOST will use to turn auto answer mode on. On most systems, this will be the default string from your modem set up, however, some systems, like mine, can record this string without the normal pauses (~) and escapes (+) for modem attention, thus making recycling of GHOST faster. (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


AutoAnswer Off String

Enter the string GHOST will use to turn auto answer mode off. On most systems, this will be the default string from your modem set up, however, some systems, like mine, can record this string without the normal pauses (~) and escapes (+) for modem attention, thus making recycling of GHOST faster. (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


Off Hook String

There are times, such as when someone is logged into GHOST locally, that you want a remote user to get a busy signal when calling, as opposed to a "ring-no answer". This would also apply if you wanted to do some system maintenance, such as a file backup, and did not want a remote to call in during that backup. To handle these situations, GHOST will take your phone "off hook", giving a busy signal to anyone calling in. Enter the modem string needed to do this here. The default is ATH1M0, which takes the phone off hook (H1) and turns the modem speaker off (M0), so that you won't be bothered by the sound of a dial tone constantly. (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


On Hook String

When GHOST has taken the phone "off hook", it then needs to put the phone back "on hook" again, in order to restore the system for remote callers. Enter a modem string here to do this. The default setting is ATH0M1, which places the phone "on hook" (H0), and resets the modem speaker to a on (M1). (These modem settings do not affect your default Procomm set up, as they are internal to GHOST.)


MailManager

Maintaining the mail on your system may not appear to be of paramount importance, however, it does have certain advantages which can not be denied. One of these advantages is system speed. Although as fast as we can make it, GHOST still is limited by the Windows Aspect language that it is written in. One of these limitations is that, the larger the mail files (GHOST.HDR and GHOST.MSG), the longer it will take to search for new mail at logon, and so on.

To keep mail searches to a minimum, the sysop should frequently perform maintenance on the mail, to delete old public messages and already read private messages, and so on, in order to keep the mail files small, and make searching the mail base quicker. To facilitate this, GHOST provides the MailManager with a screen containing complete information about a given message, including its number on the system, whether public or private, whether read or not, and so on.

The data on this screen is not editable. The MailManager is intended for read only of the mail, and to delete old mail and pack the mail base.


Next

Use this push-button to advance in a forward direction through the messages in your mail base. This button advances one at a time through the mail, allowing easy deletion of older messages.


Goto

If you wish to advance to a particular message number, use this button. When pressed, a dialog will appear asking for the message number to go to.


Delete

Using this button will mark the message currently on the screen as deleted. The message will remain in the mail base until it is next packed, however, it will no longer be "visible" to users on line.


Pack

When messages in your mail base are marked for deletion, they are not removed from the mail files, but instead, are simply marked as a deleted message, and therefore "invisible" to your users. In order to physically remove the deleted messages from your mail base, it must be packed. This button performs that procedure, by removing all messages marked as deleted from the mail base (the same procedure is performed whenever a user on line deletes a message. To conserve time and resources, the message base is packed upon GHOST shut down, whenever a message has been marked for deletion by a user.)


User Name

This is a drop down selection box which uses the user listing (the same one used on line for [L]ocate a user) to present you with a list of the user database. Selecting a name from this list will allow you to edit the information in the REC file for any given user.


Password

If necessary, the sysop can modify a user's password. This should only be done with the knowledge of the user, since changing his password without his knowledge will mean that he can not get on line the next time he tries. However, just in case, the ability to edit the password is provided here.


Security

This is likely to be the box most often used. From here, the sysop may change a user's security level. The level may be set here to any of the supported levels 0 through 5, plus one additional setting. This is a "D" or "d" which will result in the "deletion" of the user (actually, only the pointer in the USR file will be deleted. The user record will remain in the REC file, but with a security of "D x" where x is his old security level, thus allowing the sysop to restore a deleted user if he chooses.)

If a user's security is set from a "new" level (i.e. 0 or 1) to a "normal" level (i.e. 2), GHOST will record this, and before exiting this utility, will automatically update the user list if it has not been done via the Update List push-button.


Protocol

This box will contain the default transfer protocol for this user ( a blank if the user has not selected a default transfer protocol) . The sysop can change the user's default from here.


Pvt Libraries

GHOST allows the sysop to set private file libraries (accessed only by those with level 3 or higher security). This is a global setting of private libraries. However, GHOST also allows the sysop to set those libraries accessible by a level 3 user, on a per user basis. To restrict a level 3 user to only certain private libraries, make a list here (separated by commas) of those library numbers that he is allowed to access. If GHOST finds a list here, it will only allow this user to access those libraries in the list, no matter how many other private libraries are set on a global basis.


Pvt Bulletins

GHOST allows the sysop to set private bulletins (accessed only by those with level 3 or higher security). This is a global setting of private bulletins. However, GHOST also allows the sysop to set those bulletins accessible by a level 3 user, on a per user basis. To restrict a level 3 user to only certain private bulletins, make a list here (separated by commas) of those bulletin numbers that he is allowed to access. If GHOST finds a list here, it will only allow this user to access those bulletins in the list, no matter how many other private bulletins are set on a global basis.


Address lines

These edit boxes contain the contact information for a user, such as address and telephone numbers. If you change a user's City and Prov/State, and exit this utility without using the Update List push-button, GHOST will, on exit, automatically update the user list. If the user himself changes these items while on line (using the [Y]our settings menu item), you may wish to update the user list from here, via the Update List push-button, since that file contains a list of users by name, with their city as part of the entry. and  a change to that field should be updated in the user list.


Alias

When a user logs on to GHOST, a search of the mail base is done, to check for new messages for him. However, it is possible that the user may have more than one "name" on the system (e.g. he forgets his password, and logs on a second time as a new user, with a slightly different name. After being validated as that new user, he may have mail left to him in that new name, along with older mail left to his original name). Furthermore, it is quite probable that you, the sysop, have two user records in the database, one as Sysop (for local logons), and another under your own name (for remote logons). When you log on to the system, mail could be left for you in either name.

To handle this kind of situation, GHOST allows the use of an alias for mail purposes only. When GHOST does mail searches and such, if there is an entry in this field, it will also search for any mail to that name, and display it for the current user.


Last On

This is a non editable field which indicates the last date that a user was on line, for sysop information only.


Update List

Selecting this button will result in the creation of a new user list (containing the names and cities of all of your users) based upon the current contents of the USR file. When completed, the file will be sorted, and will then replace any older list which GHOST finds in your support directories.

To do this, GHOST will create a temporary directory, under the \PROWIN directory (or wherever you have installed Procomm). When finished, GHOST will clean up all extra files, leaving only a new user list in its proper location.

Any user with a security level of 0 or 1, will appear in the list with "* New User *" beside their name, rather than a city as for a validated user. Thus, you might want to update the user list after validating any new users, or when you or a user has changed the city already recorded in the user database. However, when you update a user's security from a new user level, or modify the City, Prov/State field, GHOST will automatically update the user list on exit from this utility, even should you forget to use this button to do so.


Sort List

This button will result in the sorting (via DOS) of the currently existing user list. The file will be sorted on the first name of each user, using DOS level commands. This may mean that you will have a full screen DOS session take over the computer for a few seconds, as it completes the sort. If you are using Windows in 386 enhanced mode, and change the settings of the file _DEFAULT.PIF so that it opens as a windowed application rather than full screen, GHOST will do the DOS sort of the user list in "hidden" mode, i.e. you will not see any DOS session, windowed or full screen.


24 hour loop

This is a set of two radio buttons (No and Yes). When Yes is selected, GHOST will perform in an "endless" 24 hour loop of its instructions as set and stored. This setting is great for say, a weekend when you will be away, or similar. Also, if you don't want to be bothered worrying about GHOST, set up the times, etc. for it, set it for a 24 hour loop, and add it to your StartUp group. Every time you start Windows, GHOST will start up, and go into the loop.


Start time

This edit box is used to set up a start time for the first GHOST session. If you enter a time here (24 hour format, i.e. 10 PM is 22:00 ), by default, GHOST will start at this time when you run it (i.e. it will delay starting until that time of day). If this box is left empty, GHOST will immediately initialise and run when the default button is pushed to start GHOST.

Using the start time setting, in conjunction with the stop time setting for the first GHOST session, you can set GHOST to keep a daily schedule for you. I tell everyone that my system is "up" from 11:30 PM to 6 AM, Eastern time each night. With GHOST 2.00, this is easy... set the "Start time" as 23:30, the "Stop time" as 06:00 in the first set of edit boxes. If I then place GHOST in my StartUp group, it starts operation, but without actually initialising GHOST. It reserves this until 11:30 PM, when it initialises GHOST and the modem automatically.


Stop time

Whether the "Start time" is set or not, this edit box, can be set independently. If there is a time set here, GHOST will stop its main run at that time. It doesn't matter whether a start time is present or not. With a blank start time, GHOST will begin running immediately, and will automatically shut down when this stop time is reached (unless this field is blank also).

Using the stop time setting, in conjunction with the start time setting for the first GHOST session, you can set GHOST to keep a daily schedule for you. I tell everyone that my system is "up" from 11:30 PM to 6 AM, Eastern time each night. With GHOST 2.00, this is easy... set the "Start time" as 23:30, the "Stop time" as 06:00 in the first set of edit boxes. If I then place GHOST in my StartUp group, it starts operation, but without actually initialising GHOST. It reserves this until 11:30 PM, when it initialises GHOST and the modem automatically.


Run Script

These are two more radio buttons, again a No and a Yes. What setting this to Yes does is fairly simple... when GHOST shuts down from its first run (either through a "Stop time" setting, or if the sysop manually shuts down GHOST from the "Waiting for a call" dialog), it runs a secondary script, waits for it to finish, and then returns control of operations to GHOST.


Script

If "Run Script ?" is set to Yes, then this edit box becomes more important. Here you can enter the name of a script that you want GHOST BBS to run when it shuts down from it first session. I, of course, use PCB Freedom here....

If you would like to look at a more detailed explanation of doing this, see Running Freedom as Secondary Script.


Integer

When you elect to run a secondary script after the first GHOST run, you may, if the script has been written to take advantage of it, pass an integer, a string, or both to that secondary script. This edit box allows you to enter and save the integer (if any) that you want passed to the secondary script (see Running Freedom as Secondary Script for more information on this).


String

When you elect to run a secondary script after the first GHOST run, you may, if the script has been written to take advantage of it, pass an integer, a string, or both to that secondary script. This edit box allows you to enter and save the string (if any) that you want passed to the secondary script (see Running Freedom as Secondary Script for more information on this).


2nd GHOST

IF you have set the "Run Script ?" radio button to Yes, you will have noticed that when you did so, this second "group" of dialog items became active, below the  "Main GHOST Run" group. This group is labelled "Secondary GHOST", and is used if you want to restart GHOST BBS after running the secondary script. These radio buttons allow you to tell GHOST either to run (Yes) or not to run (No) a second "session" of GHOST after the secondary script (or first session) completes.


Start time

This edit box is used to set up a start time for the second GHOST session. Like the first session time settings, you can place a time in 24 hour format here, or leave it blank. GHOST will use this information to determine how it will start a second session of itself.


Stop time

A time entered here behaves mush like a stop time set for the first GHOST session. There is one difference however. When GHOST stops at this time, it will not run a secondary script, but will shut down completely.


Enable Ring Monitor

Checking this box will enable the use of Bob Blow's Ring Monitor code (see Using Ring Monitor)


Run Minimized

Checking this box will tell GHOST that you want it (and any secondary script) to run in a minimised state on the desktop.


Exit Procomm When Done

Checking this box will tell the GHOST "launcher" that you want it to completely exit Procomm when GHOST is finished the current session(s). If this box is unchecked, the GHOST "launcher" will stop running, but Procomm will not.


Permanent Change

Selecting this button will enable the two buttons below it, "Save" and "Cancel". This will allow you to make changes to the settings of this dialog box on a permanent basis (i.e. the changes you make are saved).


Permanent Save

This button will save the settings from the rest of the dialog box, making them the new permanent settings for GHOST BBS.


Cancel

This button will cancel the current activity.


Temporary Change

Selecting this button will enable the two buttons below it, "Run" and "Cancel". This will allow you to make changes to the settings of this dialog box on a temporary basis (i.e. no changes are saved, but merely used for this session of GHOST only).


Temporary Run

After you have made any temporary changes to the settings of GHOST that you want to take effect for this session only, pressing this button will enable the changes and run GHOST.


Quick

The Quick button will cause GHOST BBS to run just like the early versions, i.e. no start time, no stop time, and no secondary script. GHOST will immediately initialise, and wait for a call, and will remain this way until the sysop shuts it down. Any settings for a second GHOST session are likewise ignored, and no second session is run.


Default

This will likely be the most commonly used button in the dialog. Selecting this will run GHOST using whatever settings were last saved as your permanent settings. The timer (10 seconds) on this dialog box will use these same settings if it is allowed to run out, i.e. it will behave just as if you had pressed the default button.


Utils

This will call up the GHOST Utilities and run them. When you exit from the utilities, you will be back at this dialog box again.


T

Since this main GHOST dialog does have a timer on it (if no activity takes place within 10 seconds, GHOST assumes an unattended session, and starts using the default settings), we put in a button with no other purpose than to stop that timer. This then gives you more time to decide if changes you want to make should be permanent, or temporary, etc.


The current GHOST @variable list

@NAME@	the full name of the user on line

@FIRST@	the first name only of the user on line

@SEC@	the word phrase for a user's security level (from GHOST.INI)

@LDATE@	the date the user was last on the system

@LTIME@	the time of his last log in

@ONLINE@	the number of minutes a user has been on line

@FIND@	a name that has been searched in the user list

@DIR@	the currently active directory (generally for level 4 or 5 users)

Future versions of GHOST will likely support additional @variables, but the constraints of the current Wasp compiler limit us to these for now.


An Example of a translation table

My French is atrocious. I have not used it in so long that I have almost completely forgotten 99.999% of it. I do however, remember that the French for YES is OUI... so let's look at a translation table for the English Yes/No/Quit prompt that in "my" French version is Oui/Non/Abort (with apologies to anyone who DOES speak French). The translation table in the PMT file for "my" French prompts would look like this

[Y/N/Q]

o=y

y=x

a=q

q=x

The purpose of the above table is to tell GHOST how it should interpret a user response to the prompt. In the default English language prompts, GHOST allows only y (yes), n (no), or q (quit). With the above translation table, GHOST would allow only o (oui), n (non), or a (abort). The two lines, y=x and q=x effectively tell GHOST to ignore the y or q response, since GHOST will translate them as "x", which is an invalid response to all prompts in GHOST (with the exception of the transfer protocol menu, which is not translated in this fashion anyway... see File Transfers). If the sysop leaves out the two "ignore" lines, GHOST would accept y (yes), o (oui), n (no or non), a (abort) or q (quit) as response to this prompt.


Statistics

After a caller (local or remote) has completed a log on to GHOST, this section of the Waiting for a Call dialog will list who the last caller was, when they logged on, and when they logged off.


Off Hook

If the sysop wants to perform any system maintenance (e.g backup some files, etc.) and does not want to have a caller interrupt the work being performed, he can click on this button to take the phone off hook, thus giving a busy signal to a caller.


On Hook

When any system maintenance is completed, this button will place the modem back on hook, allowing callers to log on to the system.


Local Logon

Pressing this button will result in GHOST taking the modem off hook, and then asking if the local caller wants to log on as SYSOP. Logging on as sysop allows you to work at security level 5 on the system. If you do not log on as sysop, then the logon is treated in precisely the same manner as if you were calling from a remote location. This is a good way to see how the system looks to your callers.


Shut Down

Selecting this button will shut down the current GHOST session, returning you to the whatever activity is scheduled next, such as the running of a secondary script. If nothin is scheduled to occur, or if this is a Quick launch of GHOST, the entire script will be shut down, and you will be returned to PCP/Win.


Popup

This is an example of a Windows Help file popup display. It is often used for definitions of terms, or to give a user of the Help file access to some small bit of information appropriate the the particular topic in use at the time.


Using This Help File - Edit Box

In one of the regular dialog boxes appearing in this file, clicking here would give you information about what data was to be entered via this control, in this case, a standard PCP/Win edit box requiring text entry.


Using This Help File - Save It button

Clicking on something like this button in one of the dialogs presented in this Help file would do one of two things. In most cases, you would see a popup similar to this telling you what the button does. However, in the main GHOST Utilities dialog box, selecting one of the buttons there will take you to another screen containing the dialog that pressing that particular button would normally call up.


Using This Help File - Exit button

In almost all of the sample dialogs used in this Help file, clicking on a button marked as "Exit" or "Done", will result in almost the same thing as happens when actually running GHOST, i.e. you will exit that dialog and return to the screen you were at before jumping to the dialog display. This one is obviously different so that this explanation can be given. If you want to see what would normally happen, select the Control icon in the upper left of the sample dialog, or click here.