home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
DOOR
/
DDPLUS67.ZIP
/
DDPLUS.DOC
< prev
next >
Wrap
Text File
|
1994-11-22
|
81KB
|
1,808 lines
DDPLus Version 6.7 Door Driver Toolkit for Turbo Pascal
DISCLAIMER
----------
The contributors have taken every precaution to insure that no harm or
damage will occur on computer systems operating this package. Nevertheless,
they shall NOT be held liable for whatever may happen on your computer
system or to any computer systems which connects to your own as a result of
operating this package. The user assumes full responsibility for the correct
operation of this software package, whether harm or damage results from
software error, hardware malfunction, or operator error. NO warranties are
offered, expressly stated or implied, including without limitation or
restriction any warranties of operation for a particular purpose and/or
merchantability. If you do not agree with this then do NOT use DDPLUS.
COPYRIGHT INFORMATION ON DDPLus TOOLKIT (C)
---------------------------------------------------
Most of the source code for the DDPlus package comes from the original Door
Driver Kit 5.0 and that code is copyrighted by Scott Baker and Derrick
Parkhurst. This copyright includes all source code and sample doors
originated by them. These authors have permitted the original code to be
published as Freeware, although they still retain copyrights to their
original material. All other material, other then the original Scott
Baker/Derrick Parkhurst items, is Copyrighted by Steven Lorenz and Bob
Dalton who are solely responsible for it's content, not to mention any
bugs <grin>.
LICENSE AGREEMENT
-----------------
The program source code, support files, and documentation NOT part of the
the original Door Driver Kit package are copyrighted products of Steven
Lorenz and Bob Dalton. These authors reserve all rights to these products.
This is protected by the United States of America (USA) and International
Copyright Laws. You may modify or use the the enclosed source code for your
programs but you may NOT distribute DDPLUS source code modifications as
part of the DDPLUS package. In cases where this may infringe on the
Copyrights of the original Door Driver Kit authors, then their Copyrights
will take precedence.
Tampering with or altering the contents or integrity of the DDPlus software
package is prohibited IF you intend to give a copy of the DDPLus archive
package to others. No fee may be charged by any agency beyond the cost of
distributing copies. The bottom line folks: Don't make any changes in this
package and redistribute as coming from us, and you can't re-label or modify
the DDPLUS package and market it as your own!
WHAT'S IT GOING TO COST YOU TO USE THIS PACKAGE?
------------------------------------------------
Nothing! The DDPlus package is distributed as FREEWARE and requires NO
registration and NO royalties for door products produced with this package.
We will NOT however turn down a registered copy of any program created
with this package if it is offered to us in appreciation for all the work
involved <grin>. These will ALWAYS be gladly accepted! (Hey, we ARE
sysops as well as programmers after all!!)
INTRODUCTION:
------------
DDplus is a package of pascal units for use in creating programs for
use with Bulletin Board Systems (BBS). These programs are called "DOORS"
and are stand alone products which "link" with the BBS to allow users
to enjoy games and utilities of all types. The DDPlus package takes the
tedium out of Door programming by allowing you to concentrate on the
writing of door specific code and not having to worry about details such
working with fossils, multi-tasker support, handling communications I/O and
the processing of BBS drop Files.
Features of DDPLUS:
-------------------
1. IRQs 0-15 are supported.
2. Comports 1-4 supported.
3. Selectable Port Addresses.
4. DV aware routines.
5. Detects Rip.
6. Fast and correct ansi color routines.
7. Lock baud and comm baud rates to 115,200
8. Built in Windows,WindowsNT,OS/2,DOS 5.0+ time
slice releasing.
9. Fossil support to 38,400 using normal fossil calls.
10. Fossil support to 115,200 using extended
fossil calls. Use XFossil for any fossils (X00 or
BNU) over 38,400. This option does not open or
close the fossil but meerly writes to it the way
it is.
15. Local video can be toggled off to save processing
time in multitasking windows or to give some user
privacy when competing in game against the sysop.
16. Multiple control files can be accessed by a
command line parm.
17. Will work with OR without the presence of a fossil.
18. ALL source code is provided and you modify it to
do whatever you need it to do! Just be sure to
document your changes as new versions of DDPLUS
come out periodically and will not have your changes
in them.
REQUIREMENTS:
------------
At this point in time the only requirements are that you must be using
Turbo Pascal version 6.0 or 7.0. If you use file locking and sharing
then users must be notified that SHARE is required to be loaded prior
to use. The same goes for ANSI.SYS as well if ANSI graphics are used.
Files Included
--------------
Below is a listing of all files for the this Package. Feel free to give
out copies of the ENTIRE archive package but please make sure all the
files below are in that package:
DVAWARE.ASM - DDPlus support source code unit.
SLASYNC.ASM - DDPlus support source code unit.
SAMPLE1.BAT - A sample BAT file which runs a DDPlus game program from the
game directory. Feel free to distribute these batch
files with your DDPLus game package creations.
SAMPLE2.BAT - A sample BAT file which runs a DDPlus game program from any
node directory. Feel free to distribute these batch
files with your DDPLus game package creations.
SAMPLE3.BAT - A sample BAT file identical to the one I use on my Single
node WildCat Support BBS to run my DDPlus Games. Feel free
to distribute these batch files with your DDPLus game
package creations.
GAME.CTL - Un-edited Control file for use with all games produced
with DDplus package. Provided mainly for information
as DDSET661.ZIP now provides a VGA setup program for
inclusion with programs made with this package.
FILE_ID.DIZ - Ascii Description File for BBS Sysops on DDPLUS67.ZIP
DDPLUS.DOC - The file you are now reading.
HISTORY.DOC - History file of changes made to the DDPlus package.
SYSOP.DOC - A sample SYSOP.DOC file I include with my DDPlus game
packages to explain to sysops how to setup up the
DDPlus Game with THEIR BBS system. Feel free to modify
this file for your door products and distribute it with
YOUR DDPlus creations. All we ask is that you keep us
in the credits section of the document file. Hey, it's
only fair we get some credit....
DVAWARE.OBJ - DDPlus support unit (compiled)
SLASYNC.OBJ - DDPLus support unit (compiled)
ASYNC2.PAS - DDPlus support source code unit.
BBSLIST.PAS - Example source code for a simple door from Scott Baker.
COMIO.PAS - DDPlus support source code unit.
DDANSI2.PAS - DDPlus support source code unit.
DDFOSSIL.PAS - DDPlus support source code unit.
DDOVR.PAS - DDPLus support source code unit.
DDOVR2.PAS - DDPlus support source code unit.
DDPLUS.PAS - Main DDPlus source code unit. Needs to be compiled.
DDSCOTT.PAS - DDPlus support source code unit.
INITOVER.PAS - A sample overlay initialization unit. Can be used to
automatically provide overlay support. Not part of
DDPlus but provided to help out new door programmers.
JUNGLE.PAS - Example source code for a simple door from Scott Baker.
MISC.PAS - A utility unit with several "must have" procedures
and functions for use with any door. Not part of
DDPlus but provided to help out new door programmers.
NEWS.PAS - Example source code for a simple door from Scott Baker.
NUMDOOR.PAS - Example source code for a simple door from Scott Baker.
DDSET661.ZIP - VGA Setup program for distribution with doors you
make using the DDPlus Package. Freeware.
Installation and Preparation for Use
------------------------------------
1. Move this package to a temporary diirectory and "unzip". Do not
at this time unzip the DDSET661.ZIP package. The DDSET661.ZIP
package is for distribution with DDPLus created products, although
you will probably want to use it yourself for testing, etc..
2. Using Turbo Pascal 6.0 or 7.0 compile DDPLUS.PAS.
3. AFTER compiling, move ALL files ending with the extension TPU or OBJ
to your Pascal units directory.
4. That's all you have to do! The package is now ready to use in your
door programs.
WHAT ARE DROP FILES?
--------------------
When the BBS transfers control to a door program it provides a file,
called a "DROP FILE" to the door program which contains essential
information such as the users name, time remaining, com port, connect
speed, etc.. The format for this "DROP FILE" varies from BBS to BBS.
At this time the DDPlus Package supports the following drop file formats:
DOORSYS - The DOOR.SYS format (Wildcat!,GAP,TAG, etc)
RBBS - Rbbs version 16.1+ (uses DORINFOx.DEF*)
QUICK - Quickbbs,Force,R.A. (uses DORINFOx.DEF**)
PCB12 - Pcboard version 12 (note: see COMPORT note below)
PCB14 - Pcboard version 14
PCB15 - Pcboard version 15
PHOENIX - Phoenix bbs (uses INFO.BBS)
SPITFIRE - Spitfires bbs (uses SFDOORS.DAT)
WWIV - WWIV bbs (uses CHAIN.TXT)
2AM - 2 A.M. software (uses JUMPER.DAT)
TRIBBS - TriBBS software (uses TRIBBS.SYS)
CALLINFO - Old Wildcat 2.xx(obsolete dropfile CALLINFO.BBS)
THE DOOR CONTROL FILE (CTL)
---------------------------
To run properly DDPlus requires configuration information from a control
(CTL) file. For your use a GAME.CTL file is enclosed with this package.
The GAME.CTL file is unedited and heavily commented so that you might
understand what each line does. Note that lines beginning with the ";"
character are NOT read by the DDPlus program unit. This CTL file tells
the DDPlus portion of your program how to act, what drop file to use, etc.
It should be noted that a program produced with DDPlus will NOT function
without the presence of a CTL file. The CTL file can be renamed, such
as GOC.CTL or RAW.CTL and is loaded and processed automatically when your
program calls "INITDOORDRIVER" (explained below). It has been our
experience that most problems experienced by users of doors made with
DDPlus are from improperly configured CTL files. To help correct this
Steven Lorenz has created a standard CTL setup program which can be
distributed with your programs and is FREEWARE. This setup program
(DDSET661.ZIP) provides VGA and mouse support and is very professional
is appearance. It is also suggested that you provide a copy of the
GAME.CTL file with your door packages for user information purposes and
as a backup in those rare cases where the CTL setup program does not
function correctly because of an odd system configuration.
Command Line Parameters
-----------------------
DDPlus supports several parameters which may be specified on the command
line. These parameters are handled automatically when you call
"INITDOORDRIVER". An example would be if you wanted to run the GodFather
of Crime Door Game locally then you would type the Command Line
parameter: GOC /L
The following is a list of DDPlus supported Command Line Parameters.
"/Bxxxxx" This tells GAME.EXE to lock its baud rate at
xxxxx. In order to get the most efficiency out of a high speed
error correcting modem (9600 baud or above), you may lock the baud
rate to a speed higher than what the caller is actually using.
By locking the baud to say 38,400, the modem can compress text data
that is being sent and achieve a baud rate much higher than the
actual transmission rate.
This will lock the baud rate at the same value for all nodes that
use this command line. If you perfer a more selective way to lock
baud use 'LOCKBAUD' command in the GAME.CTL file.
"/Cx" (where x is 1..4) This specifies a comport number.
Some bbs software does not create door information files (dropfiles)
that contain the comport number. If your bbs does have a comport
listed in the dropfile then there is no need for this parameter.
The default is comport 0, local mode.
"/E" - Expanded Memory Specification If your machine has over one
megabyte of memory, then you may have some available. GAME.EXE can
utilize EMS to improve game performance and reduce conventional
memory requirements.
This command will tell GAME.EXE to use EMS memory to hold its
overlay buffer. Otherwise disc area may be used to hold this buffer.
This needs a memory manager and when enabled and is compatible with
DESQview.
"/L" This tells GAME.EXE to load up in LOCAL mode.
This is good for testing or when a sysop just wants to "try out" the
door without messing with his BBS setup. The "/L" mode will ask the
user for his name and run the door in local mode.
"/Nx" (where x is 1..9) This specifies a "node number".
Some bbs software support multinode environments in which you must
know the node number of the drop file to use. For example, RBBS-PC
uses DORINFOx.DEF. If you specified "/N2" then GAME.EXE would use
DORINFO2.DEF.
"/Mx" (where x is up to 2 filename acceptable characters)
Used to specify one of Multiple control files. If you have created
more than one GAME.CTL file (GAME1.CTL, GAME2.CTL, etc.) for each
node or network PC then you can select the one you want by using
the /M parm.
Example: "/M2" will force GAME.EXE to use GAME2.ctl.
"/Pyyy" This specifies the path to the drop files.
For example, "/PC:\WILDCAT\WCWORK\NODE1" would tell GAME.EXE to
look for the drop file in C:\WILDCAT\WCWORK\NODE1. If this is left
out the program assumes the drop file is local.
"/V" This command will tell GAME.EXE not to show any display
on the local screen. Only a colored screen and a message will be
displayed. The cursor will not move as it will be turned off.
Saves a little processing on multi-tasking systems.
"/W" This flags the program that a network is present even
though no multitaskers are detected. This is useful if the door is
run on a network such as Novell that doesn't use multitaskers.
Special Note on RIP Support
---------------------------
DDplus can detect if RIP is present but YOU must program in any code to
make use of RIP. The extent of RIP support is to provide for both
detection AND to pass a variable which tells your program that the
door user has RIP.
Special Note on Multi-Tasker Support
------------------------------------
DDplus can detect the presence of DesqView, OS2, Windows 3.1, and Windows
NT and provide automatic time slice releasing to them. All without any
coding required on your part.
--------------------------------------------------------------------------
SPECIAL NOTE: The following sections are from the original door driver
documentation from Scott Baker and have been changed to allow them to
be consistent with the the updates reflected in the DDPlus package.
--------------------------------------------------------------------------
Overview of DDPlus Routines
---------------------------
The procedures, functions, and variables in DDPLus usually fall in one
of the following categories:
* INPUT [INP]
Get information from the user who is online.
Example: SREAD() which performs the
functional equivelant of READLN().
* OUTPUT [OUT]
Send information to the user. Example:
SWRITE() which performs the equivelant of
WRITE().
* INFORMATIONAL [INF]
Provide information about the user, such as
his name, baud rate, etc. Example:
USER_FIRST_NAME which stores the current
user's first name.
Informational variables are usually
read-only, but some can be written to as
well. Use common sense and you should get
by.
* CONTROL [CTL]
Procedures which perform various control
functions over how DDPLUS operates.
In the sections to follow, all functions/procedures/etc will be placed in
one of these categories for ease of use and easy identification.
Reference - Procedures
----------------------
INITDOORDRIVER(filen: string); [CTL]
This procedure MUST be called before any of
DDPlus's features are used. In fact, in most cases it
should be the first statement that your program executes.
The FILEN variable specifies the filename of the control
file that DDPlus will use (i.e. GAME.CTL).
InitDoorDriver does a variety of things including
loading and processing the control file, reading the drop
files, setting up serial I/O. It also sets up an "EXIT
Procuedure" which will automatically close down the serial
I/O when your program is finished.
DISPLAYFILE(Filen: String); [OUT]
This Procedure is usefull in that it will transfer an
Ascii or Ansi file, and will put "(C)ontinue, (S)top,
(N)onstop" to stop an Ascii file from scrolling of the
page and thus allowing the user to read this file at his
or her own speed.
DISPLAY_MACRO(s: string); [OUT]
This procedure is used to display a macro-string. The
macro string is usually contained in the variable
MACRO_STRING.
PROMPT(var s: string; length: integer; hi: boolean); [INP]
The prompt procedure is a high-level string input
routine. It allows you to specify the maximum length of
the input string and if HI is set to true, it will hilight
the input in reverse background. The colors for the prompt
routine are defined in the control file.
RECORD_MACRO(var s: string); [INP]
This procedure allows the user to record a macro
string, up to 255 characters that will be invoked whenever
the CTRL-N key is pressed. The macro is stored in the
string variable S. To activate the macro capability, you
must place the macro into the string variable
"MACRO_STRING".
SCLRSCR; { ANSI code } [OUT]
This procedure clears the remote side's and the local
side's screen.
SCRLEOL; [OUT]
This procedure will clear up to then end of the
current line. (note: only works when caller has ANSI
capabilities)
SET_FOREGROUND(b: byte); {chg SRL to byte } [OUT]
The set_foreground procedure sets the current
foreground color to the one specified by the byte
variable, b. The color is set both on the local side and
the remote side if the remote user has ANSI toggled on.
The acceptable range for the color is 0-31. Colors 0-15
are standard foreground colors and 16-31 represent colors
0-15 but in blinking mode.
SET_COLOR(f,b: byte); {by S. Lorenz } [OUT]
The set_color procedure sets the current foreground
color and background and are specified by the variable
bytes f and b. The color is set both on the local side and
the remote terminal if the remote user has toggled his
ANSI on. The acceptable range for the f is 0-31 and b is
0-7. If the color is currently set to foreground or back-
ground then that process is skipped. If a (7,0) is sent
then an ansi reset color code is sent.
SET_BACKGROUND(b: byte); {chg SRL to byte } [OUT]
The set_background procedure sets the current
background color to the one specified by the byte
variable, b. The color is set both on the local side and
the remote terminal if the remote user has toggled his
ANSI on. The acceptable range for the color is 0-7.
SGOTO_XY(x,y: integer); [OUT]
Sgoto_xy allows you to position the cursor on the
local and remote screen. The valid range for X is 1 to 80
and the valid range for Y is 1 to 24.
SREAD_CHAR(var c: char); [INP]
This procedure waits for a character to be pressed
and then returns that character in the character variable.
No echoing is performed (i.e. the user will not see the
key he pressed). If you wish echoing, you must again write
the character with SWRITE below. This routine is useful
for writing your own lowlevel readln routines or
performing "hot-key" operations. It is a direct
replacement for CH:=READKEY.
SREAD(var s: string); [INP]
The sread procedure accomplishes the equivilant of
the Turbo Pascal procedure READLN. A string is read from
the user and wher the CR character is obtained, the
procedure exits with the string stored in the string
variable, s.
SREAD_NUM(var i: integer); [INP]
The sread_num procedure is almost identical to the
sread procedure except it will read an integer variable
instead of a string. Only the characters 0-9 are allowed
to be entered by the user. The value returned will be in
the range of -32768 to +32768.
SREAD_NUM_BYTE(var b: byte); [INP]
The sread_num_byte procedure is almost identical to
the sread procedure except it will read an byte variable
instead of a string. Only the characters 0-9 are allowed
to be entered by the user. The value returned will be in
the range of 0 to 255.
SREAD_NUM_WORD(var w: word); [INP]
The sread_num_word procedure is almost identical to
the sread procedure except it will read an word variable
instead of a string. Only the characters 0-9 are allowed
to be entered by the user. The value returned will be in
the range of 0 to 65535.
SREAD_NUM_LONGINT(var l: longint); [INP]
The sread_num_longint procedure is almost identical
to the sread procedure except it will read an longint
variable instead of a string. Only the characters 0-9 are
allowed to be entered by the user. The value returned will
be in the range of -2147483648 to +2147483647.
SWRITE(s: string); [OUT]
The swrite procedure is the equivilant of the Turbo
Pascal WRITE procedure. Swrite will simultaniously write
to both the local screen and the remote terminal. No CR/LF
sequence is added to the end of the string. (note: You may
also use WRITE(SOUTPUT,s))
SWRITELN(s: string); [OUT]
The swriteln procedure is the equivilant of the Turbo
Pascal WRITELN procedure. Swrite will simultaniously write
to both the local screen and the remote terminal. A CR/LF
sequence is appended to the end of the string. (note: You
may also use WRITELN(SOUTPUT,s))
DDASSIGNSOUTPUT(f: text); [CTL]
This procedure assigns the simultanious output
channel to a text file. This is done automatically by
INITDOORDRIVER to SOUTPUT (i.e. DDASSIGNSOUTPUT(SOUTPUT).
But, if you wish to assign it to a different file, you may
do it with this procedure. For example:
DDASSIGNSOUTPUT(my_output_file);
rewrite(my_output_file);
writeln(my_output_file,'This will go to both local and '+
'remote.');
Reference - Functions
---------------------
SKEYPRESSED: Boolean; [INF]
SKEYPRESSED will return TRUE if a key has been
pressed and is waiting to be read and FALSE if no key has
been pressed. It is the equivelant of Turbo Pascal's
KEYPRESSED function.
This also allows the program to pause until the user
presses a key. When used in a loop like this it stops
everything until user input occurs.
Repeat Until skeypressed;
TIME_LEFT: Byte; [INF]
The time_left function returns the amount of time
left in minutes. This time is computed automatically by
DDPLUS for you.
Reference - Variables
---------------------
SOUTPUT: text; [OUT]
This text file is associated with the simultanious
output channel. It provides an alternate form of IO than
using swrite/swriteln. To use, simply treat SOUTPUT as it
were a normal text file. For example,
Writeln(SOUTPUT,'This is a test'); is the same as
swriteln('This is a test');
When is this useful? When you want to use WRITELN's
ability to write various data types (i.e. integers, reals,
etc) or it's ability to format output. For example:
USING SWRITELN: str(integer_data,tempstr);
swriteln(tempstr);
USING SOUTPUT: writeln(soutput,integer_data);
ALTKEYS: (see configurable alt key section)
ALTHELP: (see configurable alt key section)
ANSION: boolean; [CTL]
This variable controls whether local output (it has
nothing to do with remote) will go directly to the local
screen or if it will be sent through DDPLUS's
emulation routine. Since the emulation routine is slow in
comparison to direct output, this variable is defaulted to
FALSE. If you want to send your own ANSI codes to the
screen through SWRITE/SWRITELN, then you will have to set
this variable to TRUE.
BAUD_RATE: integer; [INF]
This variable holds the user's current baud rate.
BBS_SOFTWARE: byte; [INF]
The following numbers indicate software names:
Number Supported BBS DropFile Format
------ ------------------------ --------------
1 Local Only Operation N/A
3 QUICK DORINFOx.DEF
4 PC BOARD Vers 12 PCBOARD.SYS
5 WWIV CHAIN.TXT
6 PC BOARD Vers 15 PCBOARD.SYS
7 RBBS 16.1 DORINFOx.DEF
8 PHOENIX INFO.BBS
9 WildCat Vers 2 or earlier CALLINFO.BBS
10 PC BOARD Vers 14 PCBOARD.SYS
11 DOOR system format DOOR.SYS
(Wildcat 3.X or 4.X,GAP,TAG, etc)
12 SPITFIRE SFDOORS.DAT
13 2AM JUMPER.DAT
14 TRIBBS TRIBBS.SYS
BBS_TIME_LEFT: integer; [INF]
This holds the amount of time that the user had left
when he entered the door. It is loaded from the DROP FILE
by INITDOORDRIVER. Note that this provides the time left
when the user ENTERED the door, not the current time left.
The current amount of time left is calculated by the
function TIME_LEFT.
BOARD_NAME: String[70]; [INF]
Board_Name hold the current BBS's name that is set in
the control file.
CHARORIGIN: CharOriginType; [INF]
Returns either LocalChar or RemoteChar depending on
where the last sread_char was received from. This is
mainly used in the chat routine to set different
foreground colors for local and remote users.
COM_PORT: byte; [INF]
Contains the current com port that serial output is
going to. Should be a zero if in local mode.
CURRENT_FORGROUND: byte; [INF]
This variable stores the current foreground color.
CURRENT_BACKGROUND: byte; [INF]
This variable stores the current background color.
CURLINENUM: byte; [INF]
This variable is used internally to control the more
prompt. It is incremented when a line of text is sent out.
When it reaches 24, a <more> is sent. This is of course,
providing that morechk:=true.
[INF]
GRAPHICS: byte;
Graphics specifies a text mode:
1 : Ascii - General Text
2 : Ascii's Extended Graphics and General Text
3 : Ansi Color and Graphics
4 : Ansi Color and Graphics and Ansi Music (See
Section on ANSI.TPU)
5: RIP Color and Graphics
LOCAL: boolean; [INF]
This boolean is alway true if in local mode and false
if in remote mode.
MINTIME: byte; [INF]
(check this - don't know)
MORECHK: boolean; [CTL]
This boolean allows you to toggle the more prompts on
or off. If TRUE, then DDPLUS will display a "more"
prompt every 24 lines.
NODE_NUM: byte; [INF]
Returns the current Node that the door is running
under. Defaulted to 1 in a single node system. This
corresponds directly to the "/Nx" command line parameter.
NOTIME: String; [CTL]
(check this)
When the users time limit has been reached this
string will be displayed then the user will be returned to
the bbs. This string has a default of "(***TIME LIMIT
EXCEEDED***)".
STACKED: string; [---]
The Procedure sread and sreadln can have stacked
commands which is when a user type something in like this:
"m;101;m;102;m;103;m;104"
Notice the ";"'s throughout the example. well this is
a stacked command. the ";"'s indicate a seperate
operation. This allows the user to type in multiple
operations to preform on one line and not have to go
through each and every prompt of the door. This can be
very useful when used in combi- nation with the
Record_Macro command.
STATFORE: byte; [CTL]
The status line foreground.
STATBACK: byte; [CTL]
The status line background.
STATLINE: boolean; [CTL]
A status line pops while any door is in operation if
this boolean is set true. The status line contains the
user name and the program name an the users time left.
SYSOP_FIRST_NAME: string[30]; [INF]
Returns the first name of the sysop. The name is
entered into door-driver through the control file.
SYSOP_LAST_NAME: string[30]; [INF]
Returns the last name of the sysop. The name is
entered into door-driver through the control file.
USER_FIRST_NAME: string[30]; [INF]
Returns the first name of the current user of the
door program. The user's name is determined from whatever
door information is passed from the bbs software.
USER_LAST_NAME: string[30]; [INF]
Returns the last name of the current user of the door
program. The user's name is determined from whatever door
information is passed from the bbs software.
USER_ACCESS_LEVEL: word; [INF]
Returns the access level of the user. The user's
access level is determined from whatever door information
is passed from the bbs software.
PROGNAME: String[60]; [CTL]
This option must be set by the programmer, preferably
in the beginning of the door. It sets the name that will
be displayed centered on line 25 of the screen. It is
simply used for cosmetic purposes.
MACRO_STRING: string; [INF/CTL]
The contents of this variable are treated as a
macro. Whenever the user types a CTRL-N, the string will
be output. The string may be easily recorded with the
RECORD_MACRO procedure and displayed with the
DISPLAY_MACRO procedure.
SETFORECHECK: boolean; (default=FALSE) [CTL]
This variable when set to TRUE will cause DOORDRIV
to filter out repetetive SET_FOREGROUND() calls. If for
example, you set the foreground to gray, then set it to
gray again later while the foreground is still gray, the
second call would be ignored. This can spare the user from
the slowdown effects of meaningless, repetetive
SET_FOREGROUND calls.
Reference - Procedure Substitutions
-----------------------------------
This section is provided to help you in figuring out which
DDPLUS routines you should call to replace turbo's
standard I/O routines.
READKEY:
Readkey is used in many normal programs to get a
single character. (i.e. CHAR:=readey). This can be
replaced by SREAD_CHAR(char);.
WRITELN(xxxx); (or WRITE(xxxx))
The writeln procedure is probably the most common and
numerous change that you will have to make. DDPLUS
provides the SWRITE/SWRITELN procedures to do the job of
turbo's write/writeln. In addition, the SOUTPUT file is
also available. Let's take a look at some examples:
Ex 1
----
Convert "writeln('Scott was here!');"
--> swriteln('Scott was here!');
or --> writeln(soutput,'Scott was here!');
Ex 2
----
int is an integer.
Convert "write(int);"
--> str(int,tempstr); swrite(tempstr);
or --> write(soutput,int);
Ex 3
----
r is a real.
Covert "writeln(r:2:2);"
---> str(r:2:2,tempstr); swriteln(tempstr);
or ---> writeln(soutput,r:2:2);
As you can see, the SWRITE/SWRITELN method is easier
if you are using string type data, but the
write(SOUTPUT,xxx) method is better for numerical types.
You can use whichever you like.
CLREOL:
You can replace CLREOL with SCLREOL, but please note
that it will only work when the caller has ANSI
capabilities. If the caller doesn't have ansi, then he'll
get a load of garbage.
CLRSCR:
CLRSCR can be directly converted to SCLRSCR. This
works for either ANSI or non-ANSI users.
GOTOXY(x,y):
GOTOXY(x,y) can be converted into SGOTO_XY(x,y), but
again, this will only work for ansi users.
READLN(string_variable) ---> SREAD(string_variable)
READLN(integer_variable) ---> SREAD_NUM(integer_variable)
READLN(word_variable) ---> SREAD_WORD(word_variable)
READLN(long_variable) ---> SREAD_LONGINT(long_variable)
REFERENCE - Units
-----------------
The following is a brief list of the included units and what they do
here.
*DDPLUS.PAS
This is the main unit that you need to use.
*DDANSI2.PAS
Contains procedures used by DDPLUS to display
ANSI on local screen.
*DDFOSSIL.PAS
Contains procedures used by DDPLUS to interact
with fossil drivers.
*DDSCOTT.PAS
Miscellanious procedures used by DDPlus.
*COMIO.PAS
Medium-level COM I/O used by DDPlus.
*ASYNC2.PAS/SLASYNC.OBJ
Internal COM routines.
*DVAWARE.OBJ
Routines for support of Desqview
*DDOVR.PAS
Overlayable unit containing code that gets
information out of bbs drop files (i.e. DORINFOx.DEF, etc)
*DDOVR2.PAS
Overlayable unit that contains code to process
control file.
SAMPLE DOOR PROGRAM SOURCE CODE
-------------------------------
Enclosed in this package is the source code to several simple door programs.
These remain copyrighted by Scott Baker. They are:
NEWS.PAS: a program that he once wrote as an online
news reader for USA Today, Movie Review, and a few other
electronic magazine services. It's a good demonstration of
how to use ANSI, displayfile, and several of DDPlus's features.
BBSLIST.PAS: a bbs list maintainer that he wrote some
while back. Like NEWS, it's a good example of ANSI in use.
NUMDOOR.PAS: A simple number guessing game he wrote.
JUNGLE.PAS: A story door where users keep adding to the story.
Under Scott Baker's copyright you are free to use code in these
programs if you like, but he maintains a copyright on those programs.
If you do use this code, he expect to be "cut in" to whatever
extent the code was used. For example, if you developed BBSLIST.PAS
into a more powerful program and started distributing it, he
would expect a reasonable portion of whatever profits you make.
--------------------------------------------------------------------------
SPECIAL NOTE: The following tutorial was originally authored by Scott
Baker and has been modified for use with DDPlus. The unaltered parts
remain copyrighted by him.
--------------------------------------------------------------------------
HOW TO WRITE A DOOR
-------------------
* Writing a BBS Door - Tutorial by Scott M. Baker
Doors are programs written for a bulletin board system
to allow the user to perform other tasks than the bulletin
board software allows. For example, a door could be
anything from a bbs lister to a multiplayer simulation
(such as Galactic Warzone, Yankee Trader, Trade Wars,
etc). This article will be a tutorial on how to write
door programs. The programs will be written in Turbo
Pascal (version 6 or 7) and will use the DDPlus
routines to provide support for RBBS, QuickBBS, Wildcat,
WWIV, etc.
Right now, we're just going to stick with the
DDPLus routines since they are the routines that I am
most familiar with.
REQUIREMENTS
What you'll need:
- Turbo Pascal by Borland. Either version 6.0 or
7.0 will do.
- DDPLUS67.ZIP. This is a DDPLUS support
package for TP6 and TP7 It includes async
support, bbs interfacing, etc. Available from
the TANSTAFL BBS (501-741-5699) (FIDO 1:391/3010).
If you have a 9600 baud or above modem you can freq
it from the TANSTAFL BBS using the magic name of DDPLUS.
- A basic understanding of Pascal (specifically
Turbo Pascal). You don't need to be a Pascal
wizard or anything, but the more knowledge you
have, the better.
BASIC ELEMENTS OF A 'DOOR'
Ok, time to get started. First lets talk about the basic
elements that a door needs.
1) Async communications support.
The door must be able to talk to the user through the
communications port. Support has to be provided for
multiple com ports, locked baud rates, etc. The program
also must monitor the presence of the CARRIER DETECT modem
line to make sure the carrier is not dropped while the
door is in use.
2) BBS software interfacing.
The door needs to be able to grab the user's name, time
left, and other associated information from the bbs
software. Since bbs programs lack standardization, there
are several different methods that have to be accounted
for.
3) Support for ANSI (color) graphics and animation.
Just about every door has ANSI capabilities these days,
so if you want yours to be seriously considered, you'd
better have it as well.
DDPlus will handle the first two points for you
automatically when you call the INITDOORDRIVER procedure
described below. DDPlus has support for the third
point (ANSI graphics), but you'll need to use your own
skills in deciding where you wish to put colors, what
colors to use, etc.
DDPLUS PROCEDURES
There are a series of procedures that DDPLUS will
provide to you for accomplishing these tasks. Without
getting too complex, let's discuss a few of them:
PROCEDURE INITDOORDRIVER(ctl_file_name: string);
This procedure initializes the door support system, comm
port, grabs the user name, and a few other necessary
things. The variable "ctl_file_name" is a string
containing the name of the control file that your door
will use. For now, let's just ignore the control file and
use the sample included with the DD package.
PROCEDURE SWRITE(out_str: string);
This is DDPLUS's compliment to the Write() statement of Turbo
Pascal. The "S" stands for simultaneous. Output will be
written to both the remote user (through the com port) and
the local screen. "out_str" is the string containing the
data you wish to write. Most of your output will use
either this or the following SWRITELN procedure.
PROCEDURE SWRITELN(out_str: string);
Same as SWRITE, except a carriage return/line feed is
appended to the end of the string. This is similar to
TP's writeln statement.
variable USER_FIRST_NAME: STRING;
After INITDOORDRIVER has been called, this variable will
contain the user's first name. The string will be all
upper-case.
variable USER_LAST_NAME: STRING;
Similar to USER_FIRST_NAME, this variable will contain the
user's last name. As with USER_FIRST_NAME, it is only
valid after the call to INITDOORDRIVER has been made.
YOUR FIRST DOOR
Now that you've seen a few of DDPLUS's support
routines, lets put them to work in the "hello door." The
hello door will be simply a door version of the standard
hello program. Meaning that it displays "hello world" to
the screen. First, a note about my code, I'll be placing
line numbers ({1}, {2}, etc) in the code. These are
intended for discussion purposes and are not needed in the
pascal program itself.
HLODOOR.PAS:
{1} Program HelloDoor;
{2}
{3} uses crt, ddplus;
{4}
{5} begin
{6} InitDoorDriver('GAME.CTL');
{7} swriteln('Hello World!');
{8} delay(5000);
{9} end.
Experienced pascal programmers will feel a bit insulted by
the simplicity of the above program, but it is a necessary
step in learning to use door driver.
COMPILING AND RUNNING THE DOOR
Once you've got that typed in, then it's time to compile
HLODOOR. Using either Turbo Pascal version 6.0 or version
7.0, compile the program to disk. If all goes well, then
you'll be left with HLODOOR.EXE on your hard drive.
DDPLUS.DOC (supplied with DDPLUS) includes infor-
mation on how to configure / run the door on your system.
For now, let's just worry about running the door in local
mode. For local mode, type "/L" on the command line. For
example, "HLODOOR /L" will run HLODOOR. Since you are a
local user, the door will prompt you for your first and
last name. A remote user's information would be gathered
from the bbs information file (i.e. DORINFOx.DEF). We
won't worry about that for now.
ANALYSIS OF CODE
Now lets go through the important lines of code one by
one.
LINE 3: Uses crt, DDPlus;
The "uses" statement is required by Turbo Pascal to tell
TP which units we will be using. Obviously, we need
"DDPLUS" for DDPLUS's procedures. "crt" is required because
we use the DELAY procedure.
LINE 6: InitDoorDriver('Game.CTL');
This is that all-important initialization statement
described somewhere above. It tells DDPLUS to get
things all set up and working. The 'GAME.CTL' is the
name of that "control file" and we won't pay any attention
to it for now.
LINE 7: swriteln('Hello World!');
This is our screen output. It'll write "Hello World" to
both the user and the local screen. Since its SWRITELN
and not SWRITE, a carriage return and line feed also will
be sent. There are several ways that this could have been
done. For example:
{1} swrite('Hello');
{2} swriteln(' World!');
- - - or - - -
{1} swrite('Hello');
{2} swrite(' World!');
{3} swriteln('');
The output will be the same in the above situations.
LINE 8: Delay(5000);
This routine is provided by Borland and will cause our
program to delay so you can see the "hello world" before
DDPLUS exits and clears the screen. The string "Hello
World!" looks pretty plain, doesn't it? Maybe we should
put something a bit more impressive in, such as the user's
name. This would involve using the variables
USER_FIRST_NAME and USER_LAST_NAME. The modification is
simple enough:
Change line 7 from:
{7} swriteln('Hello World!');
to:
{7} swriteln('Hello, '+user_first_name+' '+
user_last_name+'!');
As you may have noticed, I used plus signs (+) instead of
commas (,) to separate the string parameters in the
SWRITELN line. With a standard WRITELN statement, you may
use as many variables as you wish, but with SWRITELN, we
are limited to 1 string variable. The point is, TP
requires us to merge our string variables together with
the plus sign.
We will now dig deeper into some interactive communication
with the user. The best way to do this is with a sample program.
Our last sample, HLODOOR was pretty plain, so let's write
something that is a bit more exciting.
The following is NUMDOOR.PAS: a simple little game
designed to demonstrate some interactive communication
with the user.
{ 1} program numdoor;
{ 2}
{ 3} uses ddplus;
{ 4}
{ 5} procedure DoTheTitle;
{ 6} begin;
{ 7} sclrscr;
{ 8} swriteln('Hello, '+user_first_name+
{ 9} ' '+user_last_name+
{10} '. Welcome to NumDoor!');
{11} swriteln('');
{12} end;
{13}
{14} procedure playgame;
{15} var
{16} thenum: word;
{17} playerguess: word;
{18} guessnum: byte;
{19} done: boolean;
{20} tempstr: string;
{21} begin;
{22} swriteln('I''m thinking of a number.'+
{23} ' Can you guess what it is?');
{24} swriteln('');
{25} guessnum:=0;
{26} randomize;
{27} thenum:=random(100)+1;
{28} done:=false;
{29} while not done do begin;
{30} inc(guessnum);
{31} swrite('Guess #');
{32} str(guessnum,tempstr);
{33} swrite(tempstr);
{34} swrite(': ');
{35} sread_num_word(playerguess);
{36} if playerguess>thenum then swriteln('Lower!') else
{37} if playerguess<thenum then swriteln('Higher!') else
{38} if playerguess=thenum then begin;
{39} swriteln('Correct!');
{40} done:=true;
{41} end;
{42} if guessnum=10 then done:=true;
{43} end; {while}
{44} if thenum<>playerguess then begin;
{45} swriteln('You Lost!');
{46} str(thenum,tempstr);
{47} swriteln('The number was '+tempstr+'.');
{48} end;
{49} end;
{50}
{51} procedure waitforkey;
{52} var
{53} ch: char;
{54} begin;
{55} swriteln('');
{56} swriteln('Press any key to continue.');
{57} sread_char(ch);
{58} end;
{59}
{60} begin;
{61} initdoordriver('GAME.CTL');
{62} dothetitle;
{63} playgame;
{64} waitforkey
{65} end.
Some of you were asking for a real door.. Well, there
it is. All 62 lines worth. Those of you using our new
LOCREAD program may wish to load up a second window on the
screen so you may view both the above source and the rest
of the article at the same time. On with the discussion...
First lets look at an overview of the structure of
NUMDOOR. We've got three main procedures: DoTheTitle,
PlayGame, and WaitForKey. These procedures are pretty self
explanatory. DoTheTitle displays a little title
information about NUMDOOR. PlayGame performs the actual
task of playing the game, and WaitForKey waits for the
user to press a key once the game is over.
Let's go through the program section by section. At
the very top, you'll notice lines one and three. Line 1
(Program NumDoor;) is simply us formally telling TP the
name of our program. Line 2 (Uses DDPLUS;) is the
all-important "uses" statement which tells TP that we will
be using the DDPLUS TPU.
Procedure DoTheTitle
The first procedure, DoTheTitle displays a little
introduction to the user so he knows where he is. Let's
look inside this procedure and see how it works:
LINE 7: SCLRSCR;
This is a DDPLUS procedure which we have not
introduced before. Sclrscr is DDPLUS's compliment to
the Turbo Pascal clrscr procedure. The clrscr procedure is
provided by TP to allow us to clear the screen. If you're
familiar with basic, then this is equivalent to a CLS.
Obviously, we will need to clear both the remote and the
local screens, so that's why we have to use DDPLUS's
Sclrscr.
LINES 8-10: SWRITELN('Hello, '+user_first_name+ .....
These lines display the introduction. As we learned in
part one of this tutorial, SWRITELN is DDPLUS's
compliment to Turbo Pascal's writeln procedure. You may
notice that I have separated the parameters across three
lines. This is perfectly legal - as long as the individual
components include plus (+) signs in between them, we can
split it up that way.
Another important note about this line: We include the
variables USER_FIRST_NAME and USER_LAST_NAME. These were
discussed in part one. For those who may have missed it,
DDPLUS places the user's first and last names into
those two respective variables. Sticking them in the
SWRITELN allows us to be a bit more personal to the user.
LINE 11: SWRITELN('');
You may be wondering, what is the point of writing
_nothing_ to the screen? The point is, like TP's writeln,
swriteln will output a CR/LF sequence. So even if we do
not write any data, the Carriage Return still goes out.
The effect is a blank line.
Procedure PlayGame
PlayGame is where all of the real work takes place.
Let's take a minute to talk about what exactly the "game"
is that we are playing.
The game is a very common number guessing game. The
computer generates a random number and the user gets ten
shots to guess what it is. If the user guesses
incorrectly, the computer will tell whether he needs to go
"higher" or "lower". Now that we know what we want to do,
lets see how we would go about doing it. In pseudocode,
here's what we need to do:
1) Generate a random number
2) Ask the user for a guess
3) Compare the user's guess to our random number.
4) Say "lower", "higher", or "correct" based on the
outcome of #3's comparison.
5) Loop back to 2 until either the user guesses the
number correctly or uses up all ten tries.
6) If the user used up all ten tries, tell him he
lost.
That's our strategy. Now, let's go thought the actual
code.
LINES 16-20: Variable Declarations
We need a multitude of variables to store some of our
information in. THENUM is a word variable which will hold
the random number which we generate. PLAYERGUESS is
another word to hold the player's current guess. GUESSNUM
is a counter to hold how many times the user has guessed.
DONE is a boolean to tell us when we are done. And
finally, TEMPSTR is a temporary string which we will
discuss when we come to it.
LINES 22-24: SWRITELN('I''m thinking of .....
These lines comprise a little instruction that we give
the user. They're just simple swriteln statements, similar
to the ones we encountered in DoTheTitle.
LINE 25: GUESSNUM:=0;
Since Turbo Pascal does not initialize our variables,
we will have to do it ourselves. Guessnum is our counter
of how many guesses the user has made. Since he hasn't
made any yet, we've got to set it to zero.
LINE 26: RANDOMIZE;
The Randomize procedure is provided by Turbo Pascal to
randomize TP's random number generator. Without it, the
game would pick the same random number each time it runs.
LINE 27: THENUM:=RANDOM(100)+1
Here is where we get our random number. The random
function returns a number between zero and it's parameter
minus one. (i.e. Random(100) will include 0..99, not 100)
So we add 1 to it to get numbers between 1 and 100.
LINE 28: DONE:=FALSE;
Right now, we aren't done yet, (we haven't even hardly
started!) so we'd better set our variable accordingly.
LINE 29: WHILE NOT DONE DO BEGIN;
Line 29 sets up our "loop" which will ask the user for
up to ten guesses. We want to keep going as long as DONE
is not true. The loop consists of lines 29-43 which ask
the user for his guess and check it's validity.
LINE 30: INC(GUESSNUM);
We're on the first guess, so set guessnum accordingly.
LINES 31-34: SWRITE('Guess #' .....
These lines prompt the user for his guess. Although
they may seem complicated, they are really nothing more
than the simple SWRITE statements that we have seen
before. We just need to do some "magic" to manipulate our
data.
Let me explain our problem: SWRITE/SWRITELN only
accept string data. But, our variable GUESSNUM is a byte
variable which holds numeric information. So how do we get
this data into something we can use? The answer is that we
use Turbo Pascal's STR procedure. STR is a very handy
procedure which converts a numeric format variable to a
string format variable. So, when we say
STR(GUESSNUM,TEMPSTR), we are telling pascal to "take the
number in guessnum, convert it to a string, and place it
in tempstr".
Once this has been done, TEMPSTR now contains our
number which we can send out to swrite with no problem.
LINE 35: SREAD_NUM_WORD(PLAYERGUESS);
This line the major new concept that we are trying to
introduce. SREAD_NUM_WORD is a DDPLUS procedure which
will read a word variable from the user. It handles all
the details of waiting for the user to press keys,
converting the data to a word, etc and just gives us a
nice word variable.
This is where the "interaction" takes place. Until
now, we have just been displaying information to the user.
Now, we ask the user for some information back.
Specifically, we ask him for his guess. The guess is
stored in the variable PLAYERGUESS.
LINES 36-41: If playerguess>thenum then ....
This block comprises the code to test the player's
guess and act upon the results. We display "higher" or
"lower" if the number is higher or lower and if the user's
guess is correct, we display "correct" and set DONE to
true to end our loop.
This code is all standard pascal stuff (with some
swrites thrown) in so I won't go into too much detail
here. We've got to try to stick to the DDPLUS-related
things or our little tutorial could get very big very
quickly.
LINE 42: IF GUESSNUM=10 THEN DONE:=TRUE;
If we're at the tenth guess, then it's time to end our
loop.
LINES 44-48: IF PLAYERGUSS<>THENUM THEN BEGIN; ....
We could have exited the loop for one of two reasons:
1) The user guessed correctly and DONE was set to true or
2) The user ran out of turns. These lines will check and
see if the user's guess was correct. If it was not, then
we got to break the bad news to him - he lost.
This code also includes our little trick of using STR
to convert the data. In this case, we have THENUM and we
need to convert it to a string so we can tell the user
what the number was. It works identically to the situation
we had in lines 31-34.
Procedure WaitForKey
After we have finished PlayGame, we need to have a
little pause so the user gets to absorb the full impact of
his game playing. We could use a simple DELAY(2000) for a
20 second delay, but we are out to demonstrate interactive
communication, so let's wait for a keypress.
I'm not going into this line-by-line as it is such a
simple procedure. Rather, I'll describe what it does.
First, we tell the user we want him to hit a key with a
SWRITELN statement.
Then, we use DDPLUS's SREAD_CHAR procedure to read
a single character. SREAD_CHAR will wait for a key and
then return it to us. We used the variable CH to hold this
character.
The Main Procedure
The main procedure, comprising lines 60-65 executes
all of our other procedure. Please note that similar to
HLODOOR, we had to call INITDOORDRIVER() to get DDPLUS
setup and ready for use.
After that, we just called DoTheTitle, PlayGame, and
WaitForKey in order. Then, we exit.
Interactive Routines
We have introduced two new very important routines:
SREAD_NUM_WORD and SREAD_CHAR. DDPLUS includes a whole
set of similar routines for doing similar things. Here's a
listing of them:
SREAD(s: string); Reads in a string
SREAD_NUM(i: integer); Reads in an integer
SREAD_NUM_WORD(w: word); Reads in a word
SREAD_NUM_LONGINT(l: longint); Reads in a longint
SREAD_CHAR(CH: CHAR); Reads in a char
The first four of these routines will read in data
until the user presses the return key. For example
"1234"<return>. They allow the user to backspace back and
forth to correct his mistakes. These are very similar to
Turbo Pascal's READLN and Basic's INPUT statements.
The fifth procedure (SREAD_CHAR) will wait for a
character and return that character. It's simply for when
you want one character and only one character. The user
can't correct his mistakes with backspace or anything.
This routine also does not echo to the screen.
SREAD_CHAR performs almost identically to Turbo
Pascal's READKEY function. In Turbo Pascal you would use
ch:=READKEY; With DDPLUS, use SREAD_CHAR(CH).
REFERENCE - IMPORTANT THINGS
----------------------------
-> What happens when the user runs out of time, sleep
-> disconnects, or drops carrier?
DDPLUS will HALT. This will cause an immediate
termination of the door. If your door needs to save any
data then you should use an EXIT PROCEDURE to save the
data. For example:
{$F+} procedure myexit; {$F-}
begin;
save_our_data;
exitproc:=exitsave;
end;
{main program}
begin;
InitDoorDriver......
ExitSave:=Exitproc;
ExitProc:=@myexit;
.......
end.
This will setup MYEXIT so it is run whenever your program
exits for any reason. This is the best way to trapped
carrier dropped, out of time, etc.
NOTE #1: The carrier, time left, and sleep disconnect are
only tested when DDPLUS is waiting for a keypress
(i.e. sread_char, sread, etc)
NOTE #2: If checktime=false then DDPLUS will not check
to see if the user is out of time.
-> How do you use ANSI in your programs?
You can use ANSI by two methods:
1) By using the set_foreground, set_background, and
sclrscr procedures, you can perform some basic ANSI
functions. DDPLUS will automatically enable these
fucntions when ANSI is available and disable it when
not.
2) If you set ANSION:=TRUE, then you can just SWRITE your
ansi sequences directly to the screen. When you turn
ANSION on, it will slow down screen writes, so it is
advisable to do it only when necessary.
--------------------------------------------------------------------------
This ends the copyrighted Scott Baker part of the documentation.
The rest of this document is from Steven Lorenz and Bob Dalton.
--------------------------------------------------------------------------
TO USE THE INITOVER.PAS UNIT
---------------------------
If your program becomes to large you can use this unit to provide automatic
overlay initialization and setup. To use it see the partial extract of the
following door example (main unit) for GodFather of Crime (GOC):
PROGRAM World;
{$B+}
{$R-}
{$S+}
{$I+}
{$N-}
{$M 65520,16384,655360}
Uses Overlay, {Must be listed first!}
InitOver, {Must be listed second!}
Dos, {Must be listed third, if used}
Crt, {Must be listed fourth, if used}
DDPlus, {Must be listed next}
Wutil, {your other units you are using are listed next}
WorldVar,
Wmap,
WStart,
Woption,
Wsave,
Woption2,
Woption3,
Wduel;
{$O DDOvr } {Must be shown if you are using overlays}
{$O DDOvr2 } {Must be shown if you are using overlays}
{$O Wmap } {Next comes the units you intend to overlay}
{$O Woption }
{$O Woption2 }
{$O Woption3 }
{$O Wduel }
Var Dummy:PlayerRecord;
etc...
In each of the overlayed units you would show the following:
UNIT Wmap;
{$F+,O+,V-} {Must be exactly as shown}
INTERFACE
Uses Crt,WorldVar,DDPlus,Wutil; {units used by this unit}
Procedure InitGraph(VAR M: MapArray); {your various procedures}
Procedure ShowGraph( M: MapArray );
Procedure InitCountry( VAR C: CountryArray );
etc...
Notes:
1. You cannot overlay ANY unit that makes a dos interrupt service call,
such as CRT, MISC.PAS or INITOVER.PAS unit.
2. See the INITOVER.PAS unit for other things you will have to do.
THE MISC.PAS UNIT
-----------------
The MISC.PAS unit contains the following "must have" program functions
and procedures:
FUNCTION SHAREINST - Detects if DOS SHARE is present. Returns a boolean
value of True or False. True if present, False if
not.
FUNCTION FILE_EXISTS - Detects if a DOS file is present in the same
directory. Returns true if it is and false if it is
not.
PROCEDURE TERMINATE--|
PROCEDURE TRAPEXIT---| All three of these work together to trap an exit
PROCEDURE MYEXIT1----| and redirect it so that an error.log is created
that's can tell you what happened and why. Makes
debugging a lot easier. Just make sure users send
you the error.log when they report a problem.
Here is a sample of the first several lines of my main program which shows
you how to implement some of the above:
BEGIN (*** M A I N ***)
OvrFileMode := 64; {File mode for overlay units}
ShareInst; {Is share installed?}
IF ShareInst then FileMode:=66;
SaveExitProc:=Exitproc;
ExitProc:=@MyExit1;
RANDSEED:=(TICKCOUNT); {Good way to randomize a number}
GetDate(Year,Month,Day,DOW);
INITDOORDRIVER('GOC.CTL');
PROGNAME:='GODFATHER OF CRIME by Bob Dalton';
NOTIME:='*** TIME HAS EXPIRED ***';
If Graphics < 3 Then
Begin
Wn('The game requires ANSI or RIP color and graphics.');
Wn('Your current parameters do not qualify you for either.');
Wn('To play this game, go back to the BBS and select the ANSI');
Wn('or RIP graphics option usually found in the Utilities Menus.');
Crlf;Wn('ASK YOUR SYSOP IF YOU HAVE FURTHER PROBLEMS!');
Crlf;
Crlf;
Wn('Sending you back to the BBS.....');
Delay(2500);
Crlf;
Exit
End;
TC(10);
Clr;
DisplayFile('GOCOPEN.ANS');
Delay(3000);
Assign(GenFile,'GEN.DAT');
IF ShareInst then FileMode:=64;
IF FILE_EXISTS('GEN.DAT') THEN
Begin
OpenAttempts:=1;
Repeat
{$I-}
Reset(GenFile);
{$I+}
GoAhead:= (IOResult = 0);
If Not GoAhead then OpenAttempts :=OpenAttempts+1;
Until (GoAhead) or (OpenAttempts>15);
End;
Read(GenFile,General);
Close(GenFile);
IF ShareInst then FileMode:=66;
etc....
TO USE FILE LOCKING AND SHARING (QUICK & SIMPLE METHOD)
-------------------------------------------------------
If you want to design multi-node capable games/programs then you must
use the services of DOS SHARE to perform file locking and sharing.
Below is a simple method, with example, of how this can be done.
Use FILEMODE=64 to lock files to prevent changes while you are working
on it/them. Use FILEMODE=66 as a general rule to tell SHARE to allow
other programs to READ/WRITE files at the same time. Use something like
the following section of code to lock/unlock files:
Assign(GenFile,'GEN.DAT');
IF ShareInst then FileMode:=64; {Tells to lock next file operation}
IF FILE_EXISTS('GEN.DAT') THEN {Uses function to see if file present}
Begin
OpenAttempts:=1; {Begin counter in case file in use}
Repeat
{$I-}
Reset(GenFile); {Attempts to Reset File for reading}
{$I+}
GoAhead:= (IOResult = 0); {Did we get a goahead?}
If Not GoAhead then OpenAttempts :=OpenAttempts+1; {If not then loop}
Until (GoAhead) or (OpenAttempts>15); {Until we do or 15 times}
End;
Read(GenFile,General); {Read that file}
Close(GenFile); {Close the file}
IF ShareInst then FileMode:=66; {After done unlocks file for whatever}
CREDITS:
--------
This relatively small section is just to recognize the people who have made
the DDPLUS package a possibility.
Scott Baker -=*=- The authors of the original DoorDriver Kit
and are to be thanked for releasing the
Derrick Parkhurst source code to their great kit! Without
that act of kindness DDPLUS would NOT
be possible. Hopefully Steve and I
have done your kit justice and given it
a new lease on life in the programming
world. Scott is the author of several
door games, most notably Land of Devastation,
which uses the original doordriver kit.
Steven Lorenz -=*=- The author of the enhanced add on package
to Scott Bakers DoorDriver Kit. Thanks to
his code modifications, add ons and enhancements
DDPLus is a much more complete and capable
package then originally released in the
DoorDriver Kit. He is also responsible for
the DDPlus setup program which he freely donated.
Steve is the author of several door games, most
notably Railroad Empires, Romans At War, and
Empires at War, all of which use DDPlus.
Bob Dalton -=*=- The author of most of the documentation in this
package and contributor of the MISC.PAS and
INITOVER.PAS units. Bob is the author of several
door games, such as GodFather of Crime, Rise To
Power, Task Force Broadside, Ship of the Line,
Grunt Fest, Way Freight and the Adventure Door
Game Toolkit, all of which use DDPLus.
DESQview is a registered trademark of Quarterdeck Office Systems.
Ripscript & Ripterm are registered trademarks of TeleGrafix Communications.
Where to reach us
-----------------
We can usually be reached at the following places:
Steven Lorenz - The Officer Club BBS - Telephone Number: 818-248-9487 (CA)
Bob Dalton - The TANSTAFL BBS - Telephone Number: 501-741-5699 (AR).
FIDO Node Number: 1:391/3010
Scott Baker - Although he NO longer supports his original DoorDriver
kit I am sure he would appreciate any free program you
were to offer him. He can be reached at his Not Yet Named
BBS at 602-544-4655 (AZ) or FIDO Node Number 1:300/9. Keep
in mind he will NOT answer any questions about this kit!
NOTE: Both Steve Lorenz and Bob Dalton habitually monitor the FIDO door
related National and International echos if you have questions.
Bug Reports/Comments/Suggestions
--------------------------------
We have made every attempt to make sure this package is free of bugs, BUT
the possibility always exists that one may have been missed by us.
If you find a bug, or have a suggestion or comment to make which would make
future versions of DDPlus even better, then netmail Bob Dalton or post a
message on one of our BBS's. We do read ALL of them and those people that
lead us to find a bug or generate a better package will receive credit in
the next DDPlus version published. PLEASE DO NOT NOTIFY US OF PROBLEMS AND
EXPECT US TO FIX THEM IF YOU HAVE FAILED TO PROVIDE US WITH COMPLETE
INFORMATION ON THE PROBLEM!
FIDO INFORMATION
----------------
Bob Dalton's BBS supports file "freq"ing at 9600 baud or above. Just call
1:391/3010. He also carries a door library of over 350 of the all time best
door games which he tries to keep current. For a list of these doors just
freq "DOORS". We are always adding new things to DDPlus so most likely
there will be a later version of the program available on one of our BBS's
then the one you have. For a current version of DDPLUS you can call
either Steve's or Bob's BBS and download it, or if you are a member of
the FIDO network and have a 9600 baud or above modem you can freq the
magic name "DDPLUS" for the latest version. Bob Dalton carries a large
Turbo Pascal support file section. If you would like a list of these files
just freq "FILES" from him. If you are a door game/program writer
why not send Bob or Steve a copy of your game/program? If you have a more
current version of a door then we have, please consider sending us a copy
as a token of your appreciation for the service we offer at NO cost to you.
Thanks!