bbs/magicka
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added Magiedit to makefile

Browse Source
This commit is contained in:
Andrew Pamment
2017-03-19 07:49:46 +10:00
parent 981eb3a4c9
commit ec69297cd8
111 changed files with 110 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

809
deps/odoors/historic/ODHIST.TXT vendored Normal file
View File

@@ -0,0 +1,809 @@
OpenDoors Door Programming Toolkit History
------------------------------------------
This document describes the development history of the OpenDoors door
programming toolkit. This document is divided into two sections. The
first section provides a brief timeline of the OpenDoors releases since
version 1.00. The second section provides detailed information on the
changes and enhancements that were made for each version.
OPENDOORS TIME LINE
-------------------
VERSION RELEASE DATE HIGHLIGHTS
-------------------------------------------------------------------------------
1.00 Fall, 1990 Initial beta version
1.10 Winter, 1991 First public release
1.20 Spring, 1991 Minor enhancments, including RA 1.00 support
1.30 Spring, 1991 A Few bug fixes
1.40 Spring, 1991 Message customizability
2.00 Summer, 1991 AVATAR support, improved ANSI support
2.10 Summer, 1991 Added od_printf() and a new registration key system
2.20 Summer, 1991 Further customizability, DesqView support
2.30 Summer, 1991 Minor bug fix
3.00 Fall, 1991 Beta release, with RA system file support
3.10 Fall, 1991 Public release with bug fixes from 3.00
3.20 Winter, 1992 Support for enhanced FILES.BBS format
3.30 Winter, 1992 Further bug fiexes
3.40 May, 1992 Full locked-BPS rate support
4.00 July, 1992 New manual, inline colour setting with od_printf()
4.10 February, 1993 Configuration file and log file systems
5.00 September, 1994 Built-in serial I/O, multiple compiler support
DETAILED HISTORY OF OPENDOORS EVOLUTION
---------------------------------------
VERSION 1.00 Initial beta test version of the OpenDoors doordriver. Proved to
be very bug-free.
VERSION 1.10 First public release.
VERSION 1.20 Made several changes:
- Support for the new RemoteAccess 1.00 enhanced
exitinfo.bbs file, with many extra pieces of information.
- Added a Alt-K function key to allow the sysop to
temporarily disable the user's keyboard
- Added full support for turning on and off status line.
Status line has been changed slightly in format, and [F9]
help function key added.
- Improved sysop chat mode (added multi-colour and wordwrap)
- Fixed up shell-to-DOS to automatically shell to the
command processor specified in COMSPEC instead of always
using COMMAND.COM. OpenDoors now also returns to system to
the drive and directory it was in before DOS shell was
issued.
- Added support for the new RemoteAccess "sysop next" key.
VERSION 1.30 A few quick changes to perfect all the features of this version
before beginning major development work on OpenDoors 2.00. Fixed
two problems:
- The status line can no longer be turned back on by the
sysop using F1 - F9 keys when a door program has disable
the status line itself.
- A rather major problem was fixed for use of OpenDoors in
conjunction with RA 1.00. We accidentally forgot to save
some of the data that is unused in previous versions, but
is now used in the new version. This bug caused some
unexpected problems, including damage to the USERSXI.BBS
file.
VERSION 1.40 Another maintenance release. This version should now function
perfectly when used in conjunction with older versions of Turbo
C. Other changes in this version include:
- Better error recovery in the case that the door
information file has been damaged.
- OpenDoors was made more customizable, including allowing
the programmer to alter the various OpenDoors messages,
and provisions for user defined function keys for the
sysop. (ie, it is now possible for the programmer to make
Alt-Y another hotkey for the sysop)
VERSION 2.00 Another release, adding a number of new features, such as:
- Added support for AVATAR graphics. OpenDoors will
automatically detect the presence of AVATAR graphics mode
when running under Remote Access, and will allow your door
to toggle it when running under other BBS systems.
- Improved ANSI routines. Added some new functions, and
changed existing functions to send more efficient ANSI
codes in some circumstances.
- The "Sysop Next" key should now work correctly with RA
1.00 and later.
VERSION 2.10 Changes in this version include:
- Implementation of a registration key-code to allow
registered users to more easily upgrade to new versions.
- Added an od_printf() function for ease of formatted output
from within OpenDoors.
VERSION 2.20 More improvements, including:
- Fixing of some minor bugs, such as incorrect handling of
the path to DORINFO1.DEF/EXITINFO.BBS files.
- Added support for more customization, such as hooks for
functions that will be called before and after Shell to
DOS and sysop chat.
- OpenDoors is now DesqView aware. OpenDoors will
automatically detect the presence of DesqView, and uses
the DesqView `virtual screen buffer' for screen display if
present.
- A QuickBBS 2.75 compatibility problem has also been fixed.
VERSION 2.30 Fixed a small bug in the registration system.
VERSION 3.00 A major upgrade, released as a beta-test version, including the
following additions/changes:
- Eliminated many bugs.
- Added support for door information files from: WWIV, PC-
Board, Spitfire, WildCat, GAP, TriTel and others.
- Added .ASC/.ANS/.AVT file display support with automatic
interpretation of QBBS/SuperBBS/RA control characters.
- Added ALT-D key to drop the user back to the BBS without
hanging up.
- Added direct access to RA style configuration, file area,
message area, external protocols, event configuration,
caller history, users online, menu files, user base and
other system files.
- Added complete set of message base manipulation routines,
with full support for the RA 1.01 message base locking
scheme.
- The user manual has also been re-written in order to make
it easier to work with.
VERSION 3.10 The following bug fixes and changes have been made since the
release of the beta version, 3.00:
- Time fields in messages are now correctly formatted
- Corrected a bug in the od_set_attrib function where the
intensity setting would not correctly be transmitted to
the remote when using ANSI graphics.
- Fixed a bug in the re-writing of the DORINFO1.DEF which
cause sysop and user's last names to be corrupted.
- Registered users may now disable the display of copyright
and registration information when the door starts up.
VERSION 3.20 A few more changes and bug fixes were made since version 3.10,
including:
- Fixed the FILES.BBS lister to correctly support FILES.BBS
files located in directories other than the default dir,
and added page pausing to the FILES.BBS lister.
VERSION 3.30 The following changes and bug fixes were made since version 3.20:
- OpenDoors no longer re-writes the DORINFO1.DEF upon
exiting. No BBS's are known to actually make use of the
information changed in DORINFO1.DEF, and re-writing this
file was causing more troubles than it was worth.
- The od_msg_read_hdr() function's NEXT_MESSAGE command now
works correctly.
- Added an od_errno variable to assist in debugging of
programs written with the BBS file engine portion of
OpenDoors.
VERSION 3.40 A minor upgrade version, with the following changes:
- Fixed a compatibility problem with some locked baud rates.
Now, if OpenDoors receives a baud rate the door
information file that is not supported in the FOSSIL
definitions, it will continue without setting the baud
rate. (Whereas before, OpenDoors would report an error and
exit.)
- Made some changes to the manual, and included a utility to
remove the extended-ASCII characters from the manual to
ease printing on some printers.
VERSION 4.00 This version is a major overhaul of the entire OpenDoors package,
including a great many enhancements and additions. As of version
4.00, OpenDoors is available as two separate packages - the door
programming toolkit (this package), and the BBS interface package
(which is available separately) Among the major changes to
version 4.00 of the OpenDoors door programming toolkit are:
- A complete re-organization of the manual, including the
re-writing of a large portion of the manual. In order to
ease printing on some printers, the manual has been re-
formatted in order that it no longer contains extended
ASCII characters. More thorough documentation on the
OpenDoors functions and structures was written, along with
the addition of many more examples. Also added to the
manual are an index, glossary and other features intended
to make the reference manual an even more powerful and
flexible tool.
- Full support for the changes to RemoteAccess 1.10/1.11 has
been added for version 4.00. These include the addition of
some new fields stored in the EXITINFO.BBS door
information file, and proper adjusting of the user's time
remaining online. Version 4.00 also now has full support
for the new QuickBBS-specific EXITINFO.BBS file.
- All of the text displayed by OpenDoors is now fully
customizable using od_control structure variables. This
permits both greater door customization, and adds the
ability to write 100% non-English doors and programs.
- The OpenDoors status lines have been changed. OpenDoors
now provides additional user information through multiple
RemoteAccess-style status lines, accessible through the
F2, F3, etc. keys. Also, the status line may now be turned
off by using the F10 key, allowing the sysop to view all
25-lines of the information displayed by a door program. A
new function od_set_statusline(), permits program
selection of the current status line setting.
- OpenDoors now allows colour codes to be embedded in
od_printf() functions, to eliminate the need for long
chains of alternating od_disp_str(), od_set_colour() /
od_set_attrib() function calls.
- A new formatted input function, od_edit_str() has been
added for use in door programs running in ANSI or AVATAR
graphics mode. The od_edit_str() function features
advanced line editing capabilities which are normally
found only in non-door programs, such as inserting or
deleting text from the middle of a string, moving the
cursor with the arrow keys, and so on. The od_edit_str()
function also provides input formatting, allowing you to
force the user's input into any format you wish, from
phone number formats to date formats to username formats.
The od_edit_str() also provides special modes for
implementing features such as password input, field input
(where the user may move from one field to another using
arrow/tab keys), input field highlighting, editing
existing strings, auto-delete, and much more. The old
od_input_str() function still provides a subset of these
features which do not require ANSI or AVATAR graphics.
- New functions have been added to the door driver module of
OpenDoors. Among these, are an od_putch() function for
displaying one character at a time, and an od_spawn()
function, for easily executing other programs from within
OpenDoors. The od_spawn() function automatically saves the
contents of the current door screen, system drive and
directory, and provides a separate screen on which the
spawned-to program can execute. The od_draw_box() function
allows you to easily display windows in door programs,
using ANSI or AVATAR graphics codes. Also added is are
od_carrier(), od_set_statusline() and od_edit_str()
functions, mentioned elsewhere.
- More changes have been made in order to permit greater
customization and flexibility of OpenDoors. An
od_carrier() function has been added to detect the state
of the carrier detect signal in programs that disable
OpenDoor's internal carrier detection. Also, it is now
possible to shut down OpenDoors without exiting via the
od_exit() function.
- OpenDoors now yeilds the processor to other executing
tasks in multitasking environments (ie. DesqView), when
the door is inactive or waiting for input.
- The door driver function od_clr_scr() now only checks the
user's screen clearing setting if that information is
available from the door information file. If the
information is not available, the od_clr_scr() function
will always clear the screen.
- Many other small changes were also made for version 4.00.
Among these, you now have access to the user's reason for
chat and you can switch the pause and stop keys on and off
during listing of available files or displaying a text
file. Also, previous versions of OpenDoors would read the
user's information from the first door information file
found. Instead, version 4.00 now reads the most recently
created door information file. A bug in the od_clr_line()
function has also been fixed.
VERSION 4.10 A great deal of work has been done between version 4.00 and 4.10
of OpenDoors. This work falls into three major categories: bug
fixes, improved performance, and new features. In fact, enough
changes and improvements have been made that this version really
ought to be numbered 5.00. Below is a summary of the changes that
have occurred since version 4.00:
- Much of the door information file interfacing code has
been revamped, in order that OpenDoors now works correctly
with the newest versions of the BBS packages it supports.
OpenDoors now differentiates between three different
DOOR.SYS formats - the DoorWay format, the PC-Board / GAP
format, and the Wildcat format. Also, the SFDOORS.DAT code
has been fixed to correctly work with the newest version
of Spitfire.
- OpenDoors will now attempt to swap itself and your entire
door program to expanded memory or disk when the sysop
shells to DOS, or when you call one of the od_spawn...()
functions. Memory swapping may be configured in a number
of ways, or even disabled. The OpenDoors swapping code
adds only 2K to the door's .EXE file size.
- OpenDoors now includes a new od_spawnvpe() function. In
addition to the features of the "quick-spawn" od_spawn()
function, od_spawnvpe() also returns the errorlevel the
called program returned, allows you to alter the
environment passed to the child process, and uses the same
parameter format as the C spawnvpe() function. (see page
117)
- The od_page() function now checks the sysop paging hours,
set in the OpenDoors control structure. If the user
attempts to page the sysop outside of the defined paging
hours, he or she will be notified that the sysop is not
available.
- OpenDoors now includes a configuration file sub-system
that you may choose to include in your OpenDoors programs.
This sub-system automatically parses the configuration
file you specify, responding to any of the built-in
configuration commands, and passing configuration options
specific to your program back to you. With only a single
line of code on your part, this sub-system will allow
people running your program to configure many options such
as sysop paging hours, system directories, maximum time
within the door, etc. It also allows the sysop to provide
information that may not be supplied by their particular
BBS software, such as modem settings, the system's name
and so on. In addition to all these built in commands, you
can add your own configuration options, such as display
colours, registration key numbers and other information
needed by your program - without the need to write your
own configuration file parsing routines. (See page 76)
- OpenDoors now supports custom, sysop-defined door
information file (drop file) formats. By defining a custom
door information file format in the cofiguration file,
OpenDoors door programs can now be made to run directly
under BBS packages that use proprietary file formats that
are not directly supported by OpenDoors. (see page 78)
- In order to make doors written with OpenDoors even more
foolproof for the sysop to setup, an intelligent door
information file (drop file) locator has been added.
OpenDoors will automatically search for a door information
file in the directory specified by the configuration file,
the directory specified by your door's source code, the
current directory, and the directory pointed to by the
environment variables used by any of a number of BBS
packages.
- OpenDoors now includes a log file sub-system that you may
choose to include in your programs. The log file system
handles all access and formatting of the logfile, allowing
the programmer to make log file entries by simple function
calls such as od_write_log("User downloading file");.
Also, since the log file system is closely integrated with
the rest of OpenDoors, choosing to include the logfile
system in a program causes OpenDoors to automatically
output the most common logfile entries for events such as
the user paging sysop, the user hanging up, sysop chatting
with the user, user inactivity timeouts, and so on. (see
page 89)
- OpenDoors 4.00 would not always correctly turn on and off
high intensity or flashing colour attributes in ANSI mode.
The ANSI colour handling code has been reworked for
version 4.10, to eliminate these problems.
- An od_get_answer() function has been added, which can be
used to easily permit only certain keys to be pressed in
response to a prompt. For instance, to get a Yes/No
response from the user, use od_get_answer("YN"); (see page
66)
- A popular addition to OpenDoors 4.00 was the ability to
change the current display colour within od_printf()
format strings, using imbedded control characters.
However, the programmer was forced to use a rather cryptic
two-byte control sequence, where the second character of
the sequence contained an 8-bit colour attribute value. It
is now possible to change the display colour within
od_printf() by specifying the names of the desired
foreground and background colours, delimited by a set of
BACK-QUOTE (`) characters. For example:
od_printf("`Red` THIS TEXT IS RED `Blue` THIS TEXT IS BLUE");
od_printf("`Flashing bright green on dark green` AND THIS IS GREEN");
(see page 93)
- Version 4.10 would not correctly "freeze" the user's time
during DOS shell and sysop page operations, when the door
was operating under RemoteAccess 1.11. This has been
fixed.
- A new variable, od_spawn_freeze_time, has been added to
the OpenDoors control structure. When set to FALSE, the
user's time remaining continues to be deducted during the
execution of any of the od_spawn... functions. When set to
TRUE, the user's time remaining is frozen during the
execution of an od_spawn... function.
- The current directory is now correctly restored to its
original setting after the sysop returns from a DOS shell,
and after calls to the od_spawn... functions.
- A number of people were experiencing difficulty using the
od_edit_str() function in version 4.00. A number of
improvements to this function's logic have been made in an
attempt to make od_edit_str() more foolproof to use. Also,
a new flag setting, EDIT_FLAG_LEAVE_BLANK has been added.
However, there were a few reports of problems which we
were not able to reproduce. If you are still having
difficulty with this function, please carefully re-read
the section of the manual pertaining to it's use. In
particular, be sure that your difficulty is not resulting
from the flag settings you are using. If you still suspect
a bug in this function, please include with your bug
report the source code that is causing the problem.
- Page pausing within the od_send_file() and od_list_files()
(FILES.BBS listing routine) functions can now be disabled
and re-enabled by the programmer.
- The "Continue? [Y/n/=]" end of screen prompt and response
keys are now fully customizable.
- The od_list_files() FILES.BBS listing function now works
correctly in all memory models. The function has also been
fixed to correctly handle cases where the trailing
backslash is not supplied in the path parameter.
- The actual BBS line (node) number is now displayed on the
default status line, provided that this information is
supplied by the BBS software.
- It is now possible to detect whether keystrokes originated
from the remote or local keyboard. This is a feature that
is useful in some special applications, such as split-
screen sysop chat programs.
- Version 4.00 would not always correctly display the status
lines, if there was information missing from the
EXITINFO.BBS file. This has been fixed. In addition, the
"next event" information is now correctly displayed on the
status lines. Also, if the user's birthday is available,
their age will also be calculated and displayed on the
status line.
- If you temporarily disable inactivity timeouts, OpenDoors
will no longer automatically trigger and inactivity
timeout as soon as you re-enable this feature.
- A new function, od_hotkey_menu(), has been added to
facilitate displaying a menu with "hot keys". Like the
od_send_file() function, od_hotkey_menu() will display an
ASCII, ANSI or AVATAR file. However, od_hotkey_menu() also
allows you to pass a string listing possible hot keys. If
the user presses any of these keys while the menu is being
displayed, menu display will immediately cease, and the
function will return the key pressed by the user. (See
page 71)
- The od_send_file() (the ASCII/ANSI/AVATAR file display
routine) no longer sends the EOF character if it happens
to exist at the end of a file.
- In addition to the EZVote OpenDoors tutorial door, an
number of other example doors are now included in the
OpenDoors package.
- A few errors have been corrected in the documentation, and
additional information has been added about the new
features in this version.
VERSION 5.00 Version 5.00 represents several major steps forward for
OpenDoors. In addition to numerous bug fixes and minor
improvements, a number of major new features have been added to
this version. These include an optional multiple personality
system which allow the sysop to choose the status line and
function key style they prefer. This version also adds text-mode
support for RIP (Remote Imaging Protocol) graphics, and adds a
group of advanced ANSI/AVATAR/RIP functions for scrolling areas
of the screen, saving and restoring portions of the screen and
creating pop-up windows and menus. Also new in this version is
support for compilers other than Borland/Turbo C(++), such as
compilers from Microsoft. Version 5.00 also adds built-in
communications support, making the use of a FOSSIL driver
optional. Furthermore, direct support for additional BBS systems
has been added. The list below provides more detail of the
changes and new features in version 5.00:
- The nonstop key ([=]) now works correctly during
FILES.BBS listing.
- New door information file formats now supported include:
RA 2.00 EXITINFO.BBS.
- If the TASK environment variable is set, OpenDoors will
now use its value to determine the current node number.
- The od_control.od_spawn_freeze_time variable now works
correctly. Previously, the user's time would always be
frozen during od_spawn...() execution, regardless of the
value of this variable.
- A new feature known as the "Multiple Personality System"
has been added to this version. If you choose to include
the Multiple Personality System in a door, the sysop will
be able to specify which of a number of "personalities"
should be used. Each personality defines the statusline
appearance and function keys seen by the sysop, and has
no effect on the door's operation from the user's
standpoint. OpenDoors 5.00 includes personality
definitions for WildCat, RemoteAccess, PC-Board, and it's
own simplified RA style status lines. You can also define
your own personalities by writing a personality
definition function. If your choose not to include the
Multiple Personality System in a door, you will still be
able to define which single personality you wish
OpenDoors to use.
- This version of OpenDoors can be used with a larger
variety of compilers than where supported by the previous
version. OpenDoors 5.00 is known to work with all
versions of Turbo C, Turbo C++, Borland C++, Microsoft C,
Microsoft C++, Quick C and Visual C++. It should also
work with any other MS-DOS based ANSI C compiler that
supports the Microsoft/DOS .OBJect and .LIBrary file
formats.
- A new diagnostics feature has been added to OpenDoors,
which allows you to determine the reason for the most
recent OpenDoors function failure. When any OpenDoors
function returns a failure condition, it also sets the
new od_control.od_error variable to indicate the reason
for the failure.
- Added additional definitions to OPENDOOR.H, to map names
of OpenDoors functions and variables with the word
"colour" from the U.S. spelling "color". In other words,
both od_set_colour() and od_set_color() are now
recognized by OpenDoors.
- The od_list_files() now supports more intelligent path
specifications. If the parameter to od_list_files() is
NULL or empty, it will search for a FILES.BBS file in the
current directory. If a directory path is specified, it
will look for a FILES.BBS in that directory. If a full
directory and filename are specified, the specified
filename will be used in place of FILES.BBS.
- To save space, the compact memory model library is no
longer included in the normal OpenDoors package. The
compact memory model library is now available seperately.
- A new function, od_set_dtr(), has been added to allow the
DTR line to the modem to be manually controlled. This can
be useful in writing programs where you wish to force the
modem to hangup, such as a call-back verification door.
- Added additional support for various DOS multitasking
environments. OpenDoors is now specifically Microsoft
Windows aware. OpenDoors also now gives up time to other
waiting tasks when it is idle during chat mode.
- The od_edit_str() "M" mode now capitializes a character
following a dash '-' character.
- When transmitting more than one character at a time,
OpenDoors now uses the FOSSIL trasfer block function,
instead of multiple calls to the transfer character
function. This should help to improve performance over
high speed connections when running on slow PCs or under
multitasking environments.
- OpenDoors 4.10 would not correctly change the display
colour from high-intensity back to low-intensity. This
problem has been fixed.
- OpenDoors now recognizes DORINFO?.DEF filenames with
alphabetical identifiers (ie, DORINFOA.DEF thru
DORINFOZ.DEF) for nodes 10 thru 35.
- Improvements have been made to the logfile system. An
exit at errorlevel zero no longer causes garbage to be
written to the logfile. The logfile functions have been
made more reliable when operating under low stack
availability conditions. In the past, if a large number
of local variables where allocated on the stack, the
logfile functions would fail, often writing garbage to
the logfile. When the user pages the sysop for chat, the
user's reason for wishing a chat is also written to the
logfile.
- Support for text-mode RIP (Remote Imaging Protocol)
graphics has been added. Because this version of
OpenDoors always operates in DOS text-mode, none of the
graphics mode RIP features (such as drawing lines,
circles and displaying icons) will appear on the local
screen. Plans for a version of OpenDoors that will
operate in graphics mode and optionally display graphics
locally are currently under consideration. In this
version, RIP support includes a number of new features.
OpenDoors will now recognize the RIP setting passed in an
RA 2.00 EXITINFO.BBS file and WildCat DOOR.SYS file, and
also allows the RIP setting to be specified in a custom
door information file. The od_send_file() and
od_hotkey_menu() functions will now search for files with
.RIP, .AVT, .ANS and .ASC extensions. When displaying RIP
graphics to the remote user, a pop-up window appears on
the local screen, indicating to the sysop which file is
being displayed.
- A set of new functions have been added to permit advanced
screen manipulations. These functions include
od_gettext() and od_puttext() to save and restore
portions of the screen, and od_save_screen() and
od_restore_screen() to save and restore the entire
screen. od_scroll() can be used to scroll any portion of
the screen upwards or downwards. od_save_screen() and
od_restore_screen() will operate in any mode, but the
other functions require ANSI/AVATAR/RIP mode to be
available.
- Three additional functions, od_window_create(),
od_window_remove() and od_popup_menu(), have been added
to facilitate the creation of popup windows and menus.
When such a window or menu is removed from the screen,
the are of the screen "under" the window is returned to
it's original state. This allows you to create multiple
overlapping windows within a door program. The
od_popup_menu() function creates a popup window with a
menu from a simple menu definition string. The user can
select an option from this menu by pressing the key
associated with an option, or by moving a menu selection
bar using their arrow keys. These three functions require
an ANSI/AVATAR/RIP mode to be available.
- A new function, od_chat() has been added, to allow you to
explicitly invoke the OpenDoors chat mode from within
your program.
- A new setting variable, od_control.od_always_clear has
been added. When set to TRUE, od_clr_scr() will always
clear the screen, regardless of the user's screen
clearing setting. When set to FALE, od_clr_scr() will
only clear the screen if the user has screen clearing
enabled.
- It is now possible to configure the errorlevels OpenDoors
exits with under various circumstances, such as when the
user runs out of time remaining online. See the
od_control.od_errorlevel variable
- A new setting variable, od_control.od_force_local, can be
used to easily force OpenDoors to operate in local mode.
Using this variable you can easily add a command line
parameter such as "-local" to allow the sysop to force
your door to operate in local mode. When OpenDoors is
forced into local mode using this variable, it does not
look for a door information file, and uses default
settings for the user's name, etc.
- OPENDOOR.H now sets structure packing to single byte
alignment for the od_control structure when Borland and
Microsoft compilers are being used. In the past,
programmers using OpenDoors have experienced difficulties
the od_control structure when the compiler has been set
to use word packing.
- OpenDoors now closes the FOSSIL driver prior to
performing a spawn or sysop DOS shell. This allows doors
or other communications programs which use the FOSSIL
driver to be executed while the door's execution is
suspended.
- When used with a FOSSIL driver, OpenDoors normally
changes the BPS rate to that passed from the BBS (if the
BBS passes a valid FOSSIL BPS rate). This BPS rate
setting may now be disabled by setting the
DIS_BPS_SETTING bit of the od_control.od_disable
variable.
- A function hook has been added to allow you to install a
function to be called whenever od_kernel() executes
(od_control.od_ker_exec). Another function hook,
od_control.od_time_msg_func, can be installed to override
OpenDoor's time limit warning messages.
- A new array, od_control.od_hot_function, allows the you
to define functions to be called when any of the
programmer-defined sysop hotkeys have been pressed.
- A function hook, od_control.od_no_file_func, has been
added. This function will be called whenever OpenDoors is
unable to find or read a door information file. This
allows you to add your own door information file reader,
or to provide a local login prompt when no door
information file is present.
- Previously, OpenDoors would stop correctly updating the
user's remaining time at midnight when running under
certain BIOSes. This problem has been fixed.
- The current display colour attribute can now be accessed
through an control structure member,
od_control.od_cur_attrib.
- od_send_file() and od_hotkey_menu() no longer pause with
a "Continue?" prompt prematurely in files that have line
lengths greater than 254 characters.
- The local keyboard may now be disabled by setting the
DIS_LOCAL_INPUT bit of od_control.od_disable. This only
affects the sysop's input in circumstances that input is
also accepted from the remote user; this setting has no
effect on the sysop function keys.
A new function hook: -
void (*od_control.od_local_input)(int);
has been added. If set, this function will be called
whenever the sysop presses a non-sysop-function key on
the local keyboard.
- od_control.od_clear_on_exit now controls whether the
screen is cleared before shelling or executing
od_spawn...(), in addition to before OpenDoors shuts
down.
- od_page() now restores the original display colour before
returning.
- It is now possible to display an entire string of
characters with terminal emulation, using the new
function od_disp_emu().
- OpenDoors will now display a small popup window when
disconnecting the current connection.
- A new variable, od_control.od_in_buf_size, can now be set
prior to calling any OpenDoors function to set the size
of OpenDoors combined local/remote keyboard input buffer.
By default, this buffer is 256 bytes in size.
- Previously, there were a number of OpenDoors API
functions that would not correctly initialize OpenDoors
if they were the first function called in the program.
This has been fixed.
- To facilitate setting of bps rates up to 115,200,
od_control.baud is now an unsigned long.
- A new setting, od_control.od_no_ra_codes, has been added
to disable the use of RemoteAccess/QuickBBS control codes
by od_send_file()/od_hotkey_menu()/od_disp_emu(). The
RemoteAccess/QuickBBS ASCII 1 "pause for key" is also now
recognized.

70
deps/odoors/historic/ODN.FRM vendored Normal file
View File

@@ -0,0 +1,70 @@
Essentially, the OpenDoors Distribution Network is a list of "official"
OpenDoors distribution sites that will be distributed with future
versions of OpenDoors, and anyone is welcome to participate. The idea
behind the "OpenDoors distribution network" is simply to make it easier
for you, the OpenDoors programmer, to obtain OpenDoors updates. While
the newest version of OpenDoors is always available from the OpenDoors
Support BBS, and often from any system carrying the "Programmer's
Distribution Network", most OpenDoors programmers would find it useful
to know of a system closer to them where the newest version of OpenDoors
is always available. Although I would like to be able to send the newest
version of OpenDoors to any support site, the cost of doing so
unfortunately makes this impossible. However, it is likely that you
would pick up the newest version of OpenDoors when it is available
anyhow, so this shouldn't really make any difference. So, if you are
interested in becoming an official OpenDoors distribution site, simply
fill in the form below, and send it to me, either electronically or by
conventional mail at one of the addresses listed at the end of this
file.
Brian Pirie
OPENDOORS OFFICIAL DISTRIBUTION SITE APPLICATION FORM
-----------------------------------------------------
YOUR NAME : ________________________________________
(eg. Brian Pirie)
LOCATION : ________________________________________
(eg. Ottawa, Ontario, Canada)
DATA NUMBER(S) : ________________________________________
(eg. (613) 526-4466)
NETWORK ADDRESSES: ________________________________________
(eg. 1:243/8 in FidoNet)
MODEM TYPE: ________________________________________
(eg. 9600, V32bis, v42bis, HST)
OTHER INFORMATION: ________________________________________
________________________________________
(eg. Hours of BBS operation, file request hours,
guest login and password, etc.)
I CAN BE INFORMED OF NEW RELEASES BY:
____
| | - ***ROUTED*** FIDONET NETMAIL
|____|
____
| | - OPENDOORS SUPPORT CONFERENCE
|____|
____
| | - INTERNET EMAIL
|____|
____
| | - OTHER: ________________________________
|____|
FidoNet NetMail: 1:243/8
InterNet EMail: brian@bpecomm.ocunix.on.ca
OpenDoors BBS: +1 613 526 4466
Conventional mail: 1416 - 2201 Riverside Drive
Ottawa, Ontario
Canada
K1H 8K9

170
deps/odoors/historic/ODN.NFO vendored Normal file
View File

@@ -0,0 +1,170 @@
Below is a list of sites from which the newest version of OpenDoors is
available, as of July 11, 1993, sorted by country. If you would like
to join the list of official OpenDoors distribution systems, please see
the following message.
In addition to the sites listed below, the newest verion of OpenDoors
will likely be available from any system that carries "Programmer's
Distribution Network" files. Also, if you send a self-addressed
envelope, along with either a 3-1/2" or 5-1/4" (360K) diskette, and
$2.00 to cover postage, I would be happy to mail the newest version of
OpenDoors to you. My address is included in the list, below.
Also, the newest version of this file is always available for download
or file request from my system, with the filename OD_SITES.ZIP.
AUSTRALIA
---------
Sydney, Australia - Rosalyn Anderson
Data Number : +61 2 552 3255
Modem : 9600, v.32/PEP
Fidonet : 3:712/618
Intlnet : 58:2100/146
Comments : 24 hours - log on as "opendoors user" password "doors"
Sydney, Australia - Chris Patten
Data Number : +61 2 977 6820
Modem : 14400, v.32bis/v.42bis
Fidonet : 3:714/906
Comments : 24 hours, file request for nodelisted sysops
CANADA
------
Lancaster Park, Alberta, Canada - Thomas King
Data Number : +1 403 973 3856
Modem : 16800, v.32bis/HST/v.42bis
Fidonet : 1:342/49
IMEX : 89:701/513
Worldnet : 62:3200/50
Comments : Freq by Magic name ODOORS 23hrs/day
Guest Name "Visiting Sysop" PW is "PhoneBill"
Saint John, New Brunswick, Canada - George Hannah
Data Number : +1 506 652 7292
Modem : 14400, v.32bis/v.42bis
Fidonet : 1:255/7
Comments : Freq ODOORS, except during ZMH
Login as OPENDOORS password GUEST
Ottawa, Ontario, Canada - Brian Pirie
Data Number : +1 613 526 4466
Modem : 9600, v.32/v.42bis
Fidonet : 1:243/8
Internet : brian@bpecomm.ocunix.on.ca
Postal addr : Brian Pirie
1416 - 2201 Riverside Drive
Ottawa, Ontario
Canada
K1H 8K9
Comments : Freq and BBS available 24 hours / day to everyone
Mascouche, Quebec, Canada - Robert La Ferte
Data Number : +1 514 968 1709
Modem : 14400, v.32bis/v.42bis
Fidonet : 1:167/235
Comments : BBS opened 24 hours a day, 7 days/week,
file request OPENDOORS for the latest version
ITALY
-----
Trieste, Italy - Pietro Budicin
Data Number : +39 40 3783111
Modem : 14400, v.32bis/HST/v.42bis
Fidonet : 2:333/603
Comments : Freq ODOORS and BBS 24hrs/day
NEW ZEALAND
-----------
Paraparaumu, New Zealand - Phill Mckenna
Data Number : +64 4 298 4194
Modem : 14400, v.32bis/v.42bis
Fidonet : 3:771/180
Comments : 24 hour system, magic name ODOORS for file reuquest
Guest User account (no password required)
UNITED KINGDOM
--------------
Cambridge, United Kingdom - Marcel Cook
Data Number : +44 223 301487
Modem : 14400, v.32bis/v.42bis
Fidonet : 2:440/34
Comments : 24 hours for callers and F'REQs, instant registration.
Magic name OPENDOORS gets latest version.
Ipswich, Suffolk, United Kingdom - Mark Clark
Data Number : +44 473 692882
Modem : 14400, v.32bis/v.42bis
Fidonet : 2:440/107
Comments : 24 Hours/Freqs Instant Registration
Ipswich, Suffolk, United Kingdom - Mike Tatum
Data Number : +44 473 87450
Modem : 14400, v.32bis/v.42bis
Fidonet : 2:440/112
Comments : 23 hours a day,
Magic name of OPENDOORS to get latest version online.
Mildenhall, Suffolk, United Kingdom - Dale Elrod
Data Number : +44 638 718623
Modem : 16800, v.32bis/HST/v.42bis
Fidonet : 2:440/37
Comments : 23 hours a day,
magic name of OPENDOORS to get latest version online.
UNITED STATES
-------------
San Jose, California, USA - Darryl Perry
Data Number : +1 408 265 4660
Modem : 9600, v.32/v.42bis
Fidonet : 1:143/324
Comments : Freq the full filename only.
San Ramon, California, USA - Brent Johnson
Data Number : +1 510 830 4616
Modem : 14400, v.32bis/HST
Fidonet : 1:161/610
Comments : 23 hours, FREQ almost anytime if listed in nodelist.
Fort Myers, Florida, USA - Jeff Cochran
Data Number : +1 813 939 3009
Modem : 16800, v.32bis/HST/v.42bis
Fidonet : 1:371/26
Comments : Downloads available first call
Columbus, Georgia, USA - Scott Burkett
Data Number : +1 706 596 8126
Modem : 9600, v.32
Fidonet : 1:3613/12
Comments : 24 Hour Operation and FREQ's
Chicago, Illinois, USA - John Kristoff
Data Number : +1 312 587 8756
Modem : 16800, v.32bis/HST
Fidonet : 1:115/743
Comments : Freq avaiable, 24 hrs., GUEST account available
Baltimore, Maryland, USA - Mike Gurski
Data Number : +1 410 256 1979
Modem : 14400, v.32bis/v.42bis
Fidonet : 1:261/1062
Echonet : 50:5410/1062
Comments : 24 hour FREQs, unlisted systems welcome
Minneapolis, Minnesota, USA - Bing Wu
Data Number : +1 612 378 7783
Modem : 19200, v.32bis/ZYX/v.42bis
Fidonet : 1:282/1016
Comments : 24 hours a day, F'req anytime except ZMH
Muskogee, Oklahoma, USA - Vince Jacobs
Data Number : +1 918 687 1612
Modem : 14400, v.32bis/v.42bis
Fidonet : 1:3813/309
DoorNet : 75:7918/200
Comments : 24 Hours, FREQ hours anytime but ZMH,
Guest Log In as The Inspector, password Gadget

447
deps/odoors/historic/ODTJ9304.TXT vendored Normal file
View File

@@ -0,0 +1,447 @@
The
OPENDOORS TECH JOURNAL
Volume 93, Number 4 June 21st, 1993
"The Greatest Thing to happen to Journalism Since Real People"
This Issue: A Word from the Editor - Scott Burkett
The Open Door - Brian Pirie
The OPENDOORS Echo
Where's the Source? - John Kristoff
Opendoors Tech Corner - Dropfile Location Logic
Review: BFE v1.30.2<EFBFBD>
OpendDoors Snippets!
OpenDoors Roll Call
OpenDoors Distribution Network Sites
OpenDoors Tech Journal Information
----------------------------------------------------------------------------
A Word from the Editor:
----------------------------------------------------------------------------
Another day, another fifty cents. Welcome once again to that info-filled,
free-as-can-be periodical dedicated to the proposition that all C-based door
libraries are not equal!
ODTJ is getting read worldwide. Yup. You know what that means? Aside from
the fact that it provides a wonderful forum for OD coders to share ideas and
information, it provides:
FREE ADVERTISING!
Man! With the distribution we are getting, ODTJ is the perfect place to
advertise that new door! I'll leave the rest up to you guys....
All in all this is a decent issue. It will probably be the last issue before
the 4.20 release of OpenDoors (it should be a doozy). On a side note, our
BBS (Under the Nile) is not running on a USR 14.4 Sportster. Too cool.
That's it. No more words of wisdom this month. No more ranting and raving
on and on about how RIP is inevitably gonna die.... :-)
Alles Klaar und spater!
----------------------------------------------------------------------------
THE OPEN DOOR - By Brian Pirie
----------------------------------------------------------------------------
** Editor's Note **
Has anyone seen this guy? Seriously, rumor has it that Brian is up to some-
thing *BIG*. Of course, once the rumors have been resolved, our readers will
be the first to know! Why? Because we have inquiring minds. Hrmpf! Look
for Brian next month....or the next month....or the.....ad infinitum.
----------------------------------------------------------------------------
OPENDOORS Echo!
----------------------------------------------------------------------------
OPENDOORS is an internationally distributed echo designed for discussion of
BBS door/utility programming, and in particular, Brian Pirie's OpenDoors C
Library!
The OPENDOORS Echo was created by a group of dedicated BBS door and utility
programmers and designers, in order to promote discussions on BBS utility
programming techniques, tasks, standards, and trends. This echo is not just
for BBS door authors! Discussion of practically any aspect of BBS programming
is encouraged. Brian Pirie, the author of OpenDoors is available for tech
support, as are his beta-testers.
The echo is not currently on the FidoNet backbone, but a feed is more than
likely available at your favorite ODN Support Site. Efforts are under way
to put OPENDOORS on the fido backbone...stay tuned!
----------------------------------------------------------------------------
Where's the Source?
----------------------------------------------------------------------------
By: John Kristoff, The Crossroads BBS (1:115/743)
There seems to be a problem with source code for BBS related utilities and
door programs being released. Why is this? I know we have BinkleyTerm,
Maximus and a handful of others, but how many door games do you see that come
with actual source code? I don't think I've seen any. In fact, the only
door program that I've seen the entire source for is Brian's RAVote.
Not that I expect the source code for TradeWars (even if I wanted it), but I
find it surprising that so many door programmers are so greedy. I started
teaching myself C because I'm sick of relying on other authors. I wouldn't
be surprised if many other small time programmers have done the same. I've
always thought that the BBS community, and computer networks in general, are
one of the most free, open and chaotic cultures our planet has ever seen.
So I can't understand why people request $10, $25 or more for a files list
generator, a simple voting booth door or those other 'dime a dozen' programs.
Don't get me wrong, I pay for quality software and I have at least a dozen
shareware programs registered. However, if I was to register every program
I've wanted to use for more than 30 days, I would be in the poor house.
There are just simply too many trivial programs in which I feel their price
isn't justified for lack of programmer committment, exhorborant price, or
just simply the value of the product. I'm not looking for a free ride, but
I am looking for quite a bit more respect from my fellow programmers. For
users, the hobby is relatively cheap, but for sysops, it's a different story.
Well, at least if you're honest. Us sysops have enough to worry about in
terms of phone bills, trouble users, hardware, updates and upgrades... and so
on.
I'm including a text, simliar to this message with all programs I write to
encourage the programmers for sysops to write free or cheap software. I plan
on releasing all my BBS related utilities and door programs as freeware or
public domain (even if that is all they're worth). It's my way of giving
something back to the community that has given me so much. I encourage you
to do the same, or at the very least, with some of your less popular programs.
John Kristoff
The Crossroads BBS
(312) 587-8756
Chicago, IL
FidoNet: 1:115/743
Internet: jkristof@mica.meddean.luc.edu
** Editor's response:
While I am somewhat in agreeance with John on this subject, I must also play
devil's advocate, and come to the aid of door writers who produce solid
products, often without the availability of source. Source code availability
for shareware products is simply not available, for obvious reasons. The
author(s) of the product cannot make source available, as potential customers
could simply recompile the source, and effectively use the software without
properly registering it with the author(s). In my own case, I choose not
to distribute source code for this reason. For smaller, freeware titles, I
suppose I never considered the fact that other programmers would want to
peek at my code. As far as price goes, I have a set $10 registration fee for
all of my door packages, a price which I consider to be extremely low for the
quality of my products.
Very interesting point, John...anyone out there have any feelings on this?
----------------------------------------------------------------------------
OpenDoors Tech Corner: Dropfile Location Logic
----------------------------------------------------------------------------
At this time, OpenDoors searches for the door information file (aka dropfile)
in the following order:
1.) First, if there was a custom door information file format
defined in the OpenDoors configuration file, OpenDoors will
begin by looking for this file. OpenDoors searches for the
custom information file in the following order:
A.) The path defined in the info_path variable
(which can be set by your door code and over-
ridden by the configuration file BBSDir setting)
B.) The directory which was the current default dir
at door startup time
C.) If any of the following environment variables
exist, OpenDoors will then search for the file
in the directories pointed to by these variables,
in the following order:
RA
QUICK
PCB
BBS
2.) If no custom door information file was found / defined,
OpenDoors will then search for door information files
corresponding to one of the built in formats. It will search
for these files in the same directories, and same order, as
it does for the custom door information file (A - C). Within
each directory, it will search for files with the following
filenames:
CHAIN.TXT
SFDOORS.DAT
DOOR.SYS
CALLINFO.BBS
DORINFO1.DEF
DORINFOx.DEF, where x is the node number
set by your program, if
x != 1.
As soon as it finds a directory containing one of these
filenames, OpenDoors will stop it's door information file
search phase. It then begins to decide what to do with what
it has found. If more than one of the above filenames was
found in the directory in question, OpenDoors will read the
file with the most recent date and time stamp. This is intended
to overcome abiguities that can arise when a door information
file conversion program is being used, and a number of
different door information files may still exist in the
directory. In such a case, it is assumed that the most recently
created file is the one that should be used. If more than one
file exist with an identical date and time, OpenDoors will use
the file that is closer to the beginning of the above list. (ie
they are listed in their order of priority)
Once OpenDoors has decided which file it is going to use, it
may have still more decision-making to do. In the case of
door information file names that correspond to more than one
format (such as DOOR.SYS), OpenDoors will examine the file
to determine which format it actually is. If a dorinfo?.def
file is found, OpenDoors will then also search for an
EXITINFO.BBS file. (An EXITINFO.BBS file is always acompanyed
by a DORINFO?.DEF file, as it does not include all the
information needed by even the most basic of doors). Again,
if an EXITINFO.BBS file is found, OpenDoors must determine
which of the many EXITINFO.BBS formats it is actually dealing
with.
This may all sound rather complicated, but it is a well thought-
out strategy that is intended to asure that the correct door
information file will be located and used in the vast majority
of cases. (and to think - it does all this in the blink of an
eye!)
----------------------------------------------------------------------------
REVIEW: BFE v1.30.2<EFBFBD>
----------------------------------------------------------------------------
BFE v1.30.2<EFBFBD>, the flexible BBS front end system from Cairo Research Labs is
now available! This is an alpha release of the upcoming 1.30 version of
BFE.
BFE is a BBS front-end system that was designed to provide sysops with a
method of running more than one BBS from the same line. In addition, it has
a wealth of other options available to put in on the front-end of your BBS,
such as allowing file transfers, ANSI/ASCII file viewing, shelling to DOS
from remote, running external programs and batch files, and much more!
BFE was designed to be called from a front-end mailer, such as Frontdoor or
Binkleyterm. Instead of spawning directly to the BBS system, it presents
a menu to the user, which details his immediate options. These options can
range from several different BBS systems, remote jobs, literally anything
you can think of! The BFE system can also be configured to be called
straight from your BBS software itself, in essence, running as a normal
door, using one of several popular BBS dropfile formats. Read onward....
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
ܳ Features <20>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
* Complete support for ANSI/ASCII/AVATAR users (Auto ANSI detect!)
* *TRUE* Multinode/Multiuser Compatibility!
* DESQview aware!
* Configurable for security concerns!
* Custom multi-level menus with item-level password protection!
* Complete carrier monitoring and timeout checking
* Use any of 11 standard dropfiles, or define custom ones!
* Run as a normal door or as a frontend! Dropfile not required!
* Complete BBS carousel - run multiple BBS systems
* ASCII/ANSI/AVATAR file support
* File transfer system with support for external protocols
* Run remote jobs, such as batch files, programs, other doors, etc.
* Remote OS shells!
* Built in chat mode
* Much more!
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
ܳ What's New in This Release? <20>
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> o New * Change ! Fix
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
o *Major* code cleanup and internal re-documenting and optimizing.
This will be done every periodically in order for the product to
continue to grow.
o New beta naming convention: MAJOR.MINOR.REV (Staging Level)
(i.e. this is 1.30.2<EFBFBD>, v1.30, rev. 2, in alpha staging)
o Custom user input using the new PROMPT keyword! Now, you can
utilize custom input as the value for SECONDARY data fields for
*any* menu type in BFE!
o New keywords: NOPASSPARMS and PROCESS. These are used to directly
manipulate the way that BFE performs calls to external processes.
When used with the PROMPT keyword above, just about anything can
be called, in any order, with any arguments!
o The COLOVERRIDE option has been added, to allow each individual
menu option to use its own unique color. This overrides the global
DESCRIPCOL keyword in each .CTL file. (Thanks to Chris Koziol)
o Upload capability now in place! This involved changes to the
PROTOCOL.BFE file, and adding a new type "U" option.
! If BFE cannot locate ASCII/ANSI/AVATAR screens at display time,
it will log an error entry into the logfile, and will no longer
wait for a remote keystroke to continue. (Thanks to R. Guevarra)
o Generic File Transfer System now in place! The new system allows
the use of configurable external protocols (no more hardcoded DSZ!)
o WELCOMESCREEN option added, to provide a global intro screen to be
displayed upon entering the BFE system (shown once only). As with
all of the file display capabilities of BFE, the file can be in
ASCII, ANSI, or in AVATAR formats. BFE will display the one which
best fits the user's terminal settings.
o The "time to next event" option has been put back into the system,
and is now passed via a new "-t" switch. (i.e. -t60, -t%3, etc).
This value is passed to external procedures (Type "R").
* The "O" type (Remote OS Shell) now utilizes the COMSPEC environment
variable to locate the command processor. The command processor
was formerly specified in the SECONDARY field. Previously, if
this value was keyed in wrong, it resulted in BFE locking up
the system. Using COMSPEC should make this a bit cleaner.
o Still more documentation changes!
FREQ: BFE from: Under the Nile! 14.4/v.32 1:3613/12 (706) 596-8126
93K
Scott Burkett,
Cairo Research Labs
----------------------------------------------------------------------------
OPENDOORS SNIPPPPPPPPPETS!!!!!!
----------------------------------------------------------------------------
By: Mark Williamson, Software Solutions (1:214/54)
Here's yet another way to center your favorite text string:
void str_center(int line,char *string,char *color)
{
int col = 40 - (strlen(string) / 2);
/* This method uses the length of the string to center it. So,
you would get strange results if you embedded control codes
in your string.
*/
if(od_control.user_ansi) { // This way allows you to specify
od_set_cursor(line,col); // the line to put the text on.
od_printf(color); // Use the `white on blue` code types
od_disp_str(string);
}
else {
od_repeat(' ',col); // This method uses the CURRENT
od_disp_str(string); // line the cursor happens to be on.
}
return;
}
Mark Williamson
Software Solutions BBS
1:214/54
Lemoore CA
(209)997-0224
v32/v42bis
Open access to first time callers.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
By: Mark Williamson, Software Solutions (1:214/54)
/******************************************************
* fill_box() by Mark Williamson, Software Solutions BBS
* Fidonet 1:214/54, (209)997-0224
*
* This code will paint a box in the
* specified color using the specified
* character using ansi/avatar graphics.
* Note that this does not make a border!
* Only 'fills' a block on the screen.
* Can be used to clear just parts of a screen.
*
* Call the function with the following parameters:
*
* int srow,scol: Starting row,col of the box
* int erow,ecol: Ending row,col of the box
* int attrib: od_set_attrib() style color code
* char fill_char: The character to use to paint the
* block. Use ' ' to clear a block.
*
* This code is placed in the public domain.
******************************************************/
#include <stdio.h>
#include "opendoor.h"
void fill_box(int srow, int scol, int erow, int ecol,
int attrib, char fill_char);
void main(void)
{
fill_box(3,10,13,40,0x1f,'<27>');
}
void fill_box(int srow, int scol, int erow, int ecol,
int attrib,char fill_char)
{
int line_len,x;
if(srow<1) srow=1;
if(erow>24) erow=24;
if(scol<1) scol=1;
if(ecol>80) ecol=80;
line_len=ecol-scol;
od_clr_scr();
od_set_attrib(attrib);
for(x=srow;x<erow+1;x++) {
od_set_cursor(x,scol);
od_repeat(fill_char,line_len);
}
}
----------------------------------------------------------------------------
OpenDoors Tech Journal Information
----------------------------------------------------------------------------
Editors: Scott Burkett
Under the Nile BBS
1:3613/12@fidonet.org
56:101/2@intlnet.org
(706) 596-8126 14.4
1113 29th Street
Columbus, GA 31902
Brian Pirie
BP ECOMM Systems
1:243/8@fidonet.org
Brian.Pirie@f8.n243.z1.fidonet.org (Internet EMail)
(613) 526-4466 14.4
1416 - 2201 Riverside Drive
Ottawa, Ontario
Canada
K1H 8K9
Published by and for programmers and users of the OpenDoors C Communications
Library and BBS Interface Kit by Pirie Enterprises. It is a compilation of
tips, reviews, and tidbits pertaining to BBS programming and general usage.
The opinions expressed in this publication do not necessarily represent those
of its editors, the OpenDoors author, or other contributors.
OBTAINING COPIES: The latest copy of the OpenDoors Tech Journal will always
be available under the magic name of TECHD (for the DOS version), and TECHW
(for the Windows .WRI version) at both of the systems listed above.
SUBMISSIONS: You are encouraged to submit articles for publication in the
journal. Please send all items to one of the afore-mentioned systems via BBS
upload or mailer file/attach.
----------------------------------------------------------------------------
->< End of The OpenDoors Tech Journal - Volume 93 Issue Number 4 ><-
----------------------------------------------------------------------------

724
deps/odoors/historic/ODTJ9305.TXT vendored Normal file
View File

@@ -0,0 +1,724 @@
The
OPENDOORS TECH JOURNAL
Volume 93, Number 5 July 20th, 1993
"The Greatest Thing to happen to Journalism Since Real People"
This Issue: A Word from the Editor - Scott Burkett
The Open Door - Brian Pirie (not!)
The Fidonet OPENDOORS Echo - Latest FAQ
Opendoors Tech Corner - ColorToString();
In Search Of - The Art of Debugging
Review: VID v2.01 - The Virus Information Door
OpenDoors Snippets!
OpenDoors Tech Journal Information
----------------------------------------------------------------------------
A Word from the Editor:
----------------------------------------------------------------------------
Finally! After months of long-distance mail polling, the OPENDOORS echo is
now residing on the North American fidonet backbone! Yep. Sorry, Ma Bell.
More on this later, and now .... the rest of the story. Sorry Paul Harvey.
Listen up children, today's editorial survey question is one which is sure to
draw quite a bit of flak from programmers around the globe. Which is the
better stimulant, Jolt Cola or Maxwell House? :-)
DoorNet! That's right. Strange things are amiss at the Circle-K! Look for
an OPENDOORS conference (both mail and file based) to appear soon on the
DoorNet backbone listing. Thanks go out to Vince Jacobs for his work on
getting this implemented. This should make ODTJ and OD distribution a bit
easier on all of us. There has been mention of gating the current fidonet
OPENDOORS echo through to Doornet. I applaud this idea and welcome it with
much grandiose. Ahem.
On another wavelength entirely, several hundred netmail messages were lost
from Under the Nile's mail machine a few weeks ago. Unfortunately, there
were a few requests for product announcements contained therein. If the
authors would be so kind as to send them back in, we will gladly publish
them in the next edition. Danke!
On a serious note, my gerbil died. Peace, and a bottle of hair grease....
(Scott, it's time for your medication....yes, mother)
----------------------------------------------------------------------------
THE OPEN DOOR - By Brian Pirie
----------------------------------------------------------------------------
Unfortunately (I know, I know), Brian was unavailable for this issue. I
finally tracked him down in Tibet, busily polling the local populace for
new ideas for the 4.20 release. At any rate, look for him in ODTJ #6, along
with (hopefully) OpenDoors 4.20... :-)
----------------------------------------------------------------------------
OPENDOORS Echo FAQ - Frequently Asked Questions
----------------------------------------------------------------------------
By: Brian Pirie
July 17th, 1993
ABOUT THIS FAQ
--------------
This document is a collection of frequently asked questions and answers.
If you have any questions about OpenDoors or the OPENDOORS echo, please
first refer to this FAQ. Not only will this help to reduce unnecessary
trafic in the echo, but it will also provide you with the answer to many
questions much more quickly than you would have otherwise.
If you have any suggestions for additions or changes to this FAQ, please
direct them to the moderator, Brian Pirie (FidoNet: 1:243/8, Internet:
brian@bpecomm.ocunix.on.ca).
Since the OPENDOORS echo and this FAQ are currently under a state of
change, this FAQ will be posted on a very regular basis for the time
being. In the future, the FAQ will probably be automatically posted on a
bi-weekly basis.
CONTENTS
--------
1.) What are the rules of the OPENDOORS echo?
2.) What IS OpenDoors?
3.) Where can I get a copy of OpenDoors?
4.) What is the newest version of OpenDoors?
5.) How much does OpenDoors cost?
6.) Is the OpenDoors source code available?
7.) Are there beta test versions of OpenDoors?
8.) How can I contact the author of OpenDoors?
9.) What IS the OpenDoors echo?
10.) What about the echo archives?
11.) How can I get help with OpenDoors or BBS door/utility programming?
12.) What guidelines are there for posting source code?
1.) WHAT ARE THE RULES OF THE OPENDOORS ECHO?
----------------------------------------
The rules of the OPENDOORS echo are few and far between. The most
important rules are those that are standard to all EchoMail conferences
that are distributed as a part of the FidoNet backbone distribution
system. The echo may not be used for illegal purposes, nor is profane
language accepted. Beyond this, your are trusted to use your own
judgement. While it is important to have as high a "signal to noise
ratio" as possible, it is also important to recognize the diverse group
of people you are communicating with though the OPENDOORS echo. There is
a wide range of technical knowledge, knowledge of network etiquette, and
personal background. If you can try to be as understanding and helpful
as possible, your doing so will help to keep friction and flaming to a
minimum.
Since the participants in the OPENDOORS echo are generally all
programmers, it seems natural that they will want to tell the world
about the programs they have written. For this reason, announcements of
new programs - either written with OpenDoors or of interest to the
participants of this echo - is encourage. However, advertising of new
programs is not the primary purpose of the echo. For this reason, we
would ask that you refrain from posting the same advertisment message
more than once within a reasonable length of time (perhaps a month).
If you are having any difficulty with the OPENDOORS echo - technical,
social, or otherwise - please feel more than free to contact the
moderator, Brian Pirie (1:243/8).
2.) WHAT IS OPENDOORS?
-----------------
OpenDoors is a Turbo C(++) / Borland C++ door programming toolkit used
by well over 100 door programmers around the world. OpenDoors handles
all of the details of door programming, such as communicating with the
modem, interfacing with virtually any BBS package, maintaining status
lines, monitoring carrier detect and user timeouts, handling sysop
function keys such as DOS shell or chat, providing advanced ANSI/AVATAR
graphics support, and much more.
OpenDoors is designed to allow you to write door programs just as you
would write any other C program, without requiring any additional effort
or knowledge. You can easily create fully functional door programs with
just a few lines of code. OpenDoors is so easy to use that many
OpenDoors programmers have begun using it with no programming
experience.
OpenDoors directly interfaces with all of the most popular BBS packages
including RemoteAccess, QuickBBS, Telegard, Wildcat, PC-Board, Maximus,
Renegade, EzyCom, RBBS-PC, Spitfire, SuperBBS, RoboBoard, WWIV and many
others. In addition, OpenDoors allows the sysop to specify custom door
information file formats to permit your doors to run on virtually any
BBS system.
Included with OpenDoors are a number of example doors that you can
compile, alter, or use as a basis for your own doors. Among these
example doors are a voting booth type door and an ANSI music
demonstration door, and dozens of sample doors within the door
programming tutorial manual.
OpenDoors also provides a number of special features that you can
optionally include in your doors, such as transparent configuation file
support, logfile support, FILES.BBS listing, and many advanced
ANSI/AVATAR graphics routines.
3.) WHERE CAN I GET A COPY OF OPENDOORS?
-----------------------------------
Below is a short table listing sites from which the newest version of
OpenDoors is available, as of April 19th, 1993. In addition to the sites
listed below, the newest verion of OpenDoors will likely be available
from any system that carries "Programmer's Distribution Network" files.
Also, if you send a self-addressed envelope, along with either a 3-1/2"
or 5-1/4" (360K) diskette, and $2.00 to cover postage, I would be happy
to mail the newest version of OpenDoors to you. My address is listed in
section 8.
Also, the most recent list of OpenDoors distribution sites is always
available for download or file request from my system, in the file
OD_SITES.ZIP. If you are interested in becoming an official OpenDoors
distribution site, please see the file included in the OD_SITES.ZIP
archive.
-------------------------------------------------------------------------------
FIDONET
LOCATION ADDRESS DATA NUMBER MODEM
-------------------------------------------------------------------------------
Sydney, Australia 3:712/618 +61 2 552 3255 (v.32/PEP)
Sydney, Australia 3:714/906 +61 2 977 6820 (v.32bis/HST)
Lancaster Park, Alberta, Canada 1:342/49 +1 403 973 3856 (v.32bis/HST)
Saint John, New Brunswick, Canada 1:255/7 +1 506 652 7292 (v.32bis)
Ottawa, Ontario, Canada 1:243/8 +1 613 526 4466 (v.32)
Mascouche, Quebec, Canada 1:167/235 +1 514 968 1709 (v.32bis)
Trieste, Italy 2:333/603 +39 40 3783111 (v.32bis/HST)
Paraparaumu, New Zealand 3:771/180 +64 4 298 4194 (v.32bis)
Cambridge, United Kingdom 2:440/34 +44 223 301487 (v.32bis)
Ipswich, Suffolk, United Kingdom 2:440/107 +44 473 692882 (v.32bis)
Ipswich, Suffolk, United Kingdom 2:440/112 +44 473 87450 (v.32bis)
Mildenhall, Suffolk, United Kingdom 2:440/37 +44 638 718623 (v.32bis/HST)
San Jose, California, USA 1:143/324 +1 408 265 4660 (v.32)
San Ramon, California, USA 1:161/610 +1 510 830 4616 (v.32bis/HST)
Fort Myers, Florida, USA 1:371/26 +1 813 939 3009 (v.32bis/HST)
Columbus, Georgia, USA 1:3613/12 +1 706 596 8126 (v.32)
Chicago, Illinois, USA 1:115/743 +1 312 587 8756 (v.32bis/HST)
Baltimore, Maryland, USA 1:261/1062 +1 410 256 1979 (v.32bis)
Minneapolis, Minnesota, USA 1:282/1016 +1 612 378 7783 (v.32bis)
Muskogee, Oklahoma, USA 1:3813/309 +1 918 687 1612 (v.32bis)
-------------------------------------------------------------------------------
4.) WHAT IS THE NEWEST VERSION OF OPENDOORS?
---------------------------------------
Version 4.10 is the most recently released version of OpenDoors. There
is a more recent beta-test version of OpenDoors. For information on this
beta-test version, see section 7.
5.) HOW MUCH DOES OPENDOORS COST?
----------------------------
OpenDoors is distributed on a try-before-you-buy basis. You can pickup a
copy of OpenDoors from any of the OpenDoors distribution sites, listed
above, to have a closer look at the package. However, if you wish to
continue using OpenDoors after the three week trial period, you must
purchase an OpenDoors registration. Full details on registering
OpenDoors is included in the OpenDoors manual. However, a brief table
listing the prices within a number of countries is listed below:
-----------------------------------------------
REGISTRATION
REGISTRATION ONLY AND SOURCE CODE
-----------------------------------------------
34 Canadian Dollars 68 Canadian Dollars
28 US Dollars 56 US Dollars
18 British Pounds 36 British Pounds
150 French Francs 300 French Francs
44 German Marks 88 German Marks
50 Netherland Gilders 100 Netherland Gilders
39 Australian Dollars 78 Australian Dollars
-----------------------------------------------
6.) IS THE OPENDOORS SOURCE CODE AVAILABLE?
--------------------------------------
Yes, the OpenDoors source code is available, at a cost equal to the
registration, to registered users. Both the regisration and source code
may also be purchased at the same time, for a cost equal to twice the
normal registration fee. When you purchase the OpenDoors source code,
the most recent version of the source code is sent to directly. Also,
you will be entitled to free upgrades to all future versions of the
source code. Whenever you wish to pick up a new version of the source
code, you may download it from the OpenDoors support BBS, arrange to
pick it up via a FidoNet-compatible mailer (simply send me a message
asking me to place the source code package "on hold" for you to poll and
pick up), or by sending a diskette and self-addressed diskette mailer.
7.) ARE THERE BETA TEST VERSIONS OF OPENDOORS?
-----------------------------------------
Yes. The beta test versions of OpenDoors are available to registered
OpenDoors users. However, keep in mind that the beta test version has
some new features that are still under development, and has not yet been
thoroughly tested. To save space, the documentation is not included with
the beta test version. As such, it is assumed that you also have the
most recent non-beta version of OpenDoors. The most recent beta version
may be file-requested from 1:243/8 as OD_BETA
8.) HOW CAN I CONTACT THE AUTHOR OF OPENDOORS?
-----------------------------------------
If you wish to contact the author of OpenDoors, Brian Pirie, please feel
free to do so. I may be reached by any of the following means:
FidoNet NetMail : 1:243/8
Internet EMail : brian@bpecomm.ocunix.on.ca
Modem (BBS) : +1 613 526 4466
Conventional Mail : Brian Pirie
Apt. #1416 - 2201 Riverside Drive
Ottawa, Ontario
K1H 8K9
Canada
9.) WHAT IS THE OPENDOORS ECHO?
--------------------------
The OPENDOORS echomail conference is devoted to OpenDoors and BBS door /
utility programming in general. The OPENDOORS echo serves as a place
where people working with OpenDoors can share ideas, source code
examples, and other tricks and techniques. Through the OPENDOORS echo
you can receive help with OpenDoors and programming in general. Also
available through the OPENDOORS echo is information on future versions
of OpenDoors and recent developments of concern to BBS door and utility
programmers. The OPENDOORS echo is also place for suggestions for future
versions of OpenDoors, OpenDoors bug reports, a place to announce the
availablility of your programs, and much more information of interest to
OpenDoors programmers. There are participants in the OpenDoors echo from
throughout Canada and the U.S., as well as people in Europe and
Australia.
10.) WHAT ABOUT THE ECHO ARCHIVES?
----------------------------
Although we attempt to answer the most commonly asked questions in this
FAQ, there is so much discussed in the OPENDOORS echo that it is
impossible to address every possible question. As such, you may be
interested in referring to the OPENDOORS echo archives, in order to
learn more about OpenDoors and BBS door/utility programming in general.
The OPENDOORS echo archives are prepared on a monthly basis, and
are available from the moderators system. Currently, the following
archives are available for request from 1:243/8 or download from the BBS
at +1 613 526 4466:
ODJUL92.ZIP 42776 Discussion from the OpenDoors echo, July '92
ODAUG92.ZIP 35432 Discussion from the OpenDoors echo, August '92
ODSEP92.ZIP 36308 Discussion from the OpenDoors echo, September '92
ODOCT92.ZIP 30922 Discussion from the OpenDoors echo, October '92
ODNOV92.ZIP 34844 Discussion from the OpenDoors echo, November '92
ODDEC92.ZIP 53647 Discussion from the OpenDoors echo, December '92
ODJAN93.ZIP 24683 Discussion from the OpenDoors echo, January '93
ODFEB93.ZIP 41562 Discussion from the OpenDoors echo, February '93
ODMAR93.ZIP 24080 Discussion from the OpenDoors echo, March '93
ODAPR93.ZIP 30027 Discussion from the OpenDoors echo, April '93
ODMAY93.ZIP 39440 Discussion from the OpenDoors echo, May '93
ODJUN93.ZIP 56615 Discussion from the OpenDoors echo, June '93
11.) HOW CAN I GET HELP WITH OPENDOORS OR BBS DOOR/UTILITY PROGRAMMING?
-----------------------------------------------------------------
If you have any problems with a program, please feel more than free to
post a message here, asking for help. Afterall, that is one of the
central purposes of this echo. However, try to keep the following points
in mind when asking a question. Doing so will help others to better
understand your problem, and as such will help them help you.
A.) If you are having a problem with a program, try to
describe as much about the problem as possible. If you
can, precisely how to reproduce the problem. If you wish
to do so, posting source code can also be of great
advantage. For more information on posting source code in
the echo, please see section 12.
B.) Explain what steps you have already taken in trying to
solve your problem. This will allow others to pick up from
where you have become "stuck", and not suggest solutions
that you have already tried yourself.
12.) WHAT GUIDELINES ARE THERE FOR POSTING SOURCE CODE?
-------------------------------------------------
You are more than welcome to post source code in this echo. If you do
so, please keep the following guidelines in mind.
A.) Unless you explicitly say otherwise, any source code
posted in this echo will be considered to be released to
the public domain. If you have some source code that you
do not wish others to copy, don't post it here!
B.) For your source code to be useful to others, it has to be
understandable. Adding comments can be of great benifit to
someoone trying to understand your code.
C.) If you are posting a program written with OpenDoors,
please be sure that you do NOT include your registration
key in the source code!
----------------------------------------------------------------------------
OpenDoors Tech Corner: ColorToString()
----------------------------------------------------------------------------
Authored by: Brian Pirie, OpenDoors author
/* Function to convert an integer color attribute to an OpenDoors */
/* style color description string, in the format: */
/* */
/* [Flashing] [Bright] [Foreground] on [Background] */
/* */
/* The function takes two parameters, an unsigned integer */
/* representing the input color, and a pointer to a string where */
/* the colour description should be output. Be sure that this */
/* string is large enough to hold the largest possible color */
/* description string. (If the code is not altered, the largest */
/* possible string will be 35 characters, including the null */
/* terminator */
void ColorToString(unsigned int color, char *outString)
{
/* Array containing names of various colors */
static char colorString[8][33]={"Black",
"Blue",
"Green",
"Cyan",
"Red",
"Magenta",
"Yellow",
"White"};
/* Initialize string */
outString[0]='\0';
/* If flashing bit is set, output "Flashing" string + space */
if(color & 0x80) {
strcat(outString, "Flashing ");
}
/* If bright bit is set, output "Bright" string + space */
if(color & 0x08) {
strcat(outString, "Bright ");
}
/* Output foreground color */
strcat(outString, colorString[color & 0x07]);
/* Output the word "on" with a space before & after */
strcat(outString, " on ");
/* Output background color */
strcat(outString, colorString[(color & 0x70) >> 4]);
}
Editor's Note: Brian was kind enough to put this function together for us
upon request for a function to perform the reverse of the od_color_config()
function. I had to add a bracket or two that was left out (he did mention
that it was untested code!), but it works like a champ.
----------------------------------------------------------------------------
In Search Of - The Art of Debugging
By Mark Williamson
----------------------------------------------------------------------------
It happens. The inevitable. You have spent so many hours trying to
write the most optimized, cleanest code possible. But your best efforts
are laid to rest when some verocious little creature pops up, seemingly
at random, and wreaks havoc on all your efforts.
What causes these bugs to appear? Can it be programming style? Or a
forgotten temporary variable? Where, or where, is that bug!
If this has happened to you, don't feel bad. 50 percent of your time
programming will be devoted to the debugging cycle. Many books have
been written that are devoted to the art of programming style, debugging
and the development cycle. I will only touch on a couple of pointers to
get you started in the right direction in locating that invisible target
called so affectionately, the "bug."
Case scenario: I was working on a program that would shell to DOS using
one of the OD_SPAWN... functions. OPENDOOR.DOC discusses in
good detail how to use either of these functions. But, being the eager
programmer that I am, I happily went about my way after I read what I
thought I needed to know. The program in question uses a temporary
directory to store files extracted from .ZIP/.ARJ/etc.. archive files.
As the program was running, it worked just great. Unpacked the files
using PKZIP. Repacked them using ARJ.
Then I tried it again. That's when it all fell apart for me.
Unwillingly, I just started a four-day straight debugging session,
lasting until the wee hours of the night.
Point one: Always read the docs...thoroughly!
During this four day debugging frenzy I removed 20 or more variables I
didn't need, rewrote five functions to be more independent and portable
(ie modular programming) and greatly optimized the program overall.
But I still couldn't find the bug.
Here's a sample of the code:
od_set_cursor(15,20);
od_printf("`bright cyan`Unpacking");
error=run_it(progname,unpackcommand); // see the run_it function
// below.
if(error==0){
od_set_cursor(15,33);
od_printf("`bright green`<60><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> `bright cyan` Ok ");
}
The above code did not do as it appears it should. In fact, as soon as
the trace feature of Turbo C++ 3.0 hit the line that prints out the bar
and the word "Ok", what actually was printed out was something like
this:
Unpacking :\BBSFILES\BBSUPLOADS\CHKZIP.ZIP
but not:
Unpacking <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> Ok
Now remember, I hadn't read the section on the od_swapping_path variable
yet.
The OD_SPAWN.. functions will swap to either EMS memory or DISK. The
variable od_control.od_swapping_path is empty by default, which equates
to the CURRENT DIRECTORY!. Thus, when my utility unpacked/repacked the
files, it packed up the swap file also. Then, when I ran it the second
and future times on the same archive file, I was overwriting the swap
file! Effectively overwriting the program's data and code segments.
Lesson learned: Read the docs..first. Don't use the old tried and
untrue "If all else fails, read the docs." Read them first. Read them
several times.
How to debug:
If your compiler has a trace feature, use it.
Put all the variables in the watch window that could possibly have any
bearing on the function your are testing. Look for suspicious changes
in values when the variable has not been 'touched'.
Minimize global variable useage. This makes portability difficult. If
you write functions that do not rely on any outside information except
that which is passed as an parameter, then it will be much easier to use
the same functions over and over, throughout many of your projects.
Use descriptive variables. C gives you much luxury in the length of
your variable names. Use this to the max. How many times have you
scratched your head and wondered "what does this one do?"
Use descriptive function names. See above
Read other programmer's source for ideas. Many times you will probably
be reinventing the wheel. Read the C snippets for ideas. Check out
some other source code to see how it's done elsewhere. This may give
you much needed insight into the art of programming style.
And last but not least.. Use comment lines! Don't be vague. Commenting
your source code will most likely help only one person. You. But, you
are the only one that matters anyway right?
Good luck and press on!
Mark Williamson
Software Solutions
Fido 1:214/54
Home of Labtest 2.00 - The Definitive Upload Processor
Written entirely in Turbo C++ 3.0 using Brian Pirie's Open Doors 4.1
----------------------------------------------------------------------------
REVIEW: VID v2.01
----------------------------------------------------------------------------
VID v2.01, the BBS Virus Information Door from Cairo Research Labs, is now
available!
The original VID was designed to provide a quick online virus reference for
BBS users, but has quickly evolved into quite a bit more! Thanks to a
tremendous response from Sysops around the world, VID has provided BBS users
with quick, accurate viral assessments while online on their favorite BBS
system.
What's New in This Release?
o Over 100 new viruses added, bringing the total up to 1,557 entries.
o Cleaned up display in several of the search and list options,
including multi-column virus listings (Thanks to Chris Koziol).
o Provided an option for online documentation for end-users.
* Due to an internal problem in the original 2.00 release, you must
use v2.01+ to use any new enhancement modules. The database
structures have changed a bit.
* The periodic VID integrity check has been enhanced. VID now
stores its integrity information in a file called SANITY.CHK.
Ensure that this file resides in the VID directory!
* In the 2.00 release, the VIDDEF.TBL file had to reside in the
path. This was causing a message subsystem initialization error
if VID could not locate this file in the path! VID now looks in
the current directory first. (Thanks to Steve Pepin)
! In the Behavior search, although the default answer is "Ignore",
the prompt showed the default as "No". Fixed! (Steve Pepin).
! If VID was typed alone with no arguments, the old switches from
the 1.10 release were displayed! Fixed! (Steve Pepin, again!).
! VID now handles extraneous spaces in registration keys. This
occurred when clipping a key from a netmail message. Squashed!
(Thanks to Bart Holiman).
! In the 2.0 datafiles, the "Stealth" flag on several viruses was
not set properly. Squashed!
FREQ: VID - This will get you the VID engine, documentation, Lite-level
database, and any release notes. 165K in size (VID201.ZIP).
VIDPLUS - This will get you the VID+ modules. You must have the VID
engine (above) for this to be functional! This expands
to around 1.5MB or so. 323K in size (VP0793.ZIP).
FROM - Under the Nile BBS, 1:3613/12, 14.4 USR
(706) 596-8126
---------------------------------------------------------------------------
OPENDOORS SNIPPPPPPPPPETS!!!!!!
----------------------------------------------------------------------------
By : Mark Williamson
The previous post of this code had a little error. In the fill_box()
function, remove the od_clr_scr(). I had put that in for test purposes. Sorry
bout that!
/********************************************************************/
I would like to submit this code for the next issue of ODTJ. Please
post my name and bbs info in the ODTJ with this code:
/******************************************************
* fill_box() by Mark Williamson, Software Solutions BBS
* Fidonet 1:214/54, (209)997-0224
*
* This code will paint a box in the
* specified color using the specified
* character using ansi/avatar graphics.
* Note that this does not make a border!
* Only 'fills' a block on the screen.
* Can be used to clear just parts of a screen.
*
* Call the function with the following parameters:
*
* int srow,scol: Starting row,col of the box
* int erow,ecol: Ending row,col of the box
* int attrib: od_set_attrib() style color code
* char fill_char: The character to use to paint the
* block. Use ' ' to clear a block.
*
* This code is placed in the public domain.
******************************************************/
#include <stdio.h>
#include "opendoor.h"
void fill_box(int srow, int scol, int erow, int ecol,
int attrib, char fill_char);
void main(void)
{
fill_box(3,10,13,40,0x1f,'<27>');
}
void fill_box(int srow, int scol, int erow, int ecol,
int attrib,char fill_char)
{
int line_len,x;
if(srow<1) srow=1;
if(erow>24) erow=24;
if(scol<1) scol=1;
if(ecol>80) ecol=80;
line_len=ecol-scol;
/* od_clr_scr(); OOPS! TAKE THIS LINE OUT */
od_set_attrib(attrib);
for(x=srow;x<erow+1;x++) {
od_set_cursor(x,scol);
od_repeat(fill_char,line_len);
}
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
// The following function provided by Brian Pirie
// during a telephone conversation with Brian and myself
//
// Arguments: Prog - the path/filename of the program to run
// command_line - path/filename of the program and any
// command line arguments the program needs.
//
// Example: prog = "PKUNZIP"
// command_line = "PKUNZIP TESTFILE.ZIP"
//
// Return value: errorlevel of child process
int run_it(char *prog,char *command_line)
{
char *arg[3];
arg[0]=prog;
arg[1]=command_line;
arg[2]=NULL;
strcpy(arg[1],strshl(arg[1],strlen(prog)));
return(od_spawnvpe(P_WAIT,prog,arg,NULL));
}
----------------------------------------------------------------------------
OpenDoors Tech Journal Information
----------------------------------------------------------------------------
Editors: Scott Burkett
Under the Nile BBS
1:3613/12@fidonet.org
Scott.Burkett@f12.n3613.z1.fidonet.org (Internet EMail)
(706) 596-8126 14.4 USR
1113 29th Street
Columbus, GA 31902
Brian Pirie
BP ECOMM Systems
1:243/8@fidonet.org
brian@bpecomm.ocunix.on.ca (Internet EMail)
(613) 526-4466 14.4
1416 - 2201 Riverside Drive
Ottawa, Ontario
Canada
K1H 8K9
Published by and for programmers and users of the OpenDoors C Communications
Library and BBS Interface Kit by Pirie Enterprises. It is a compilation of
tips, reviews, and tidbits pertaining to BBS programming and general usage.
The opinions expressed in this publication do not necessarily represent those
of its editors, the OpenDoors author, or other contributors.
OBTAINING COPIES: The latest copy of the OpenDoors Tech Journal will always
be available under the magic name of TECHD (for the DOS version), and TECHW
(for the Windows .WRI version) at both of the systems listed above.
SUBMISSIONS: You are encouraged to submit articles for publication in the
journal. Please send all items to one of the afore-mentioned systems via BBS
upload or mailer file/attach.
----------------------------------------------------------------------------
->< End of The OpenDoors Tech Journal - Volume 93 Issue Number 5 ><-
----------------------------------------------------------------------------

2244
deps/odoors/historic/ODTJ9402.TXT vendored Normal file
View File

File diff suppressed because it is too large Load Diff

173
deps/odoors/historic/ROLLCALL.TXT vendored Normal file
View File

@@ -0,0 +1,173 @@
----------------------------------------------------------------------------
The OpenDoors Rollcall!
----------------------------------------------------------------------------
The OpenDoors Roll Call is a compilation of BBS utilities and doors that were
authored using Brian Pirie's OpenDoors package. If you would like to see
your products listed in this section, send the following information to either
Brian Pirie or myself (via netmail, echomail, or snailmail):
Product Name
Author Name
Description
Price
FREQ Address/BBS Number
FREQ Name
Latest Version
----------------------------------------------------------------------------
Auto-Message
------------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Message to next caller door.
Price:
BFE (BBS Front End System)
--------------------------
Author(s): Scott Burkett - Cairo Research Labs
version: 1.30.2<EFBFBD>
Requestable from: 1:3613/12
Freq name: BFE
Description: Complete BBS carousel, front end menu builder, remote jobs, etc
Price: $10
BID (BBS Information Door)
--------------------------
Author(s): Brian Pirie - Pirie Enterprises
version: 2.00
Requestable from: 1:243/8
Freq name: BID
Description: A door to introduce new BBS users to the world of BBSing
Price: Freeware
CALL-BACK
---------
Author(s): Don Laverdure
version: 4.02
Requestable from: 1:249/124
Freq name: CB-402.ARJ
Description: Callback verifier door for RA/SBBS/QBBS systems
Price: unknown/Shareware
EZVote
------
Author(s): Brian Pirie - Pirie Enterprises
version: 4.10
Requestable from: 1:243/8
Freq name: EZVOTE
Description: A user voting door for use with most BBS systems
Price: Freeware
Flame-Thrower
-------------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Users leave next caller a flaming one-liner.
Price:
Node-Door
---------
Author(s): Don Laverdure
Version: 2.11
Requestable from: 1:249/124
Freq name: ND-211.ARJ
Description: Nodelist browser door for raw nodelists.
Price: unknown/Shareware
RegPRO
------
Author(s): Scott Burkett - Cairo Research Labs
Version: 2.60
Requestable from: 3613/12
Freq name: REGPRO
Description: Online BBS Fullscreen Entry Form/User Questionnaire System
Price: $10/Shareware
ROBO TAPE
---------
Author(s): Vince Jacobs - Lone Wolf Software
Version: 2.00
Requestable from: 1:3813/309, 62:9600/0, 75:400/0 Anytime But ZMH.
Freq name: ROBOT200.ARJ
Description: BBS Tape Access Door
Price: $10/Shareware
TBM (Turbo Bulletin Manager)
----------------------------
Author(s): Scott Burkett - Cairo Research Labs
Version: 2.50
Requestable from: 3613/12
Freq name: TBM
Description: BBS Bulletin Manager/Tons of features/Most BBS Systems
Price: $10/Shareware
Tic-Tac-Toe
-----------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Plays just like the real thing.
Price:
Triple Dare
-----------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Try and outdraw the dealer! Great graphics.
Price:
Turbo Poll
----------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Very graphical voting booth door
Price:
Turbo Quotes
------------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Randomly displays quotes to users
Price:
Users-Info
----------
Author(s): Vince Jacobs - Lone Wolf Software
Version:
Requestable from:
Freq name:
Description: Displays Exteneded Info about users and prints it out.
Price:
VID (Virus Information Door)
----------------------------
Author(s): Scott Burkett - Cairo Research Labs
Version: 2.00
Requestable from: 3613/12
Freq name: VID and VIDPLUS (Enhancement Module)
Description: Online Virus Reference Database for most BBS types
Price: $10/Shareware
VKill
-----
Author(s): Scott Burkett - Cairo Research Labs
Version: 3.00a
Requestable from: 1:3613/12
Freq name: VKILL
Description: Upload Integrity Door for Maximus CBCS
Price: $10/Shareware

25
deps/odoors/historic/odtips3/BPFIND.H vendored Normal file
View File

@@ -0,0 +1,25 @@
/* MSC / BC compatible findfirst()/findnext() definitions. */
#ifdef __TURBOC__
#include <dir.h>
#include <dos.h>
#else
#include <dos.h>
struct ffblk
{
char ff_reserved[21];
char ff_attrib;
unsigned ff_ftime;
unsigned ff_fdate;
long ff_fsize;
char ff_name[13];
}
#define findfirst(p, f, a) _dos_findfirst(p, (struct _find_t *)f, a)
#define findnext(f) _dos_findnext((struct _find_t *)f)
#define FA_RDONLY _A_RDONLY
#define FA_HIDDEN _A_HIDDEN
#define FA_SYSTEM _A_SYSTEM
#define FA_LABEL _A_VOLID
#define FA_DIREC _A_SUBDIR
#define FA_ARCH _A_ARCH
#endif

342
deps/odoors/historic/odtips3/CMDLINE.C vendored Normal file
View File

@@ -0,0 +1,342 @@
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include "opendoor.h"
#include "cmdline.h"
#ifndef BOOL
typedef int BOOL;
#endif
typedef enum
{
kParamLocal,
kParamBPS,
kParamPort,
kParamNode,
kParamHelp,
kParamPersonality,
kParamMaxTime,
kParamAddress,
kParamIRQ,
kParamNoFOSSIL,
kParamNoFIFO,
kParamDropFile,
kParamUserName,
kParamTimeLeft,
kParamSecurity,
kParamLocation,
kParamUnknown
} tCommandLineParameter;
static void AdvanceToNextArg(int *pnCurrentArg, int nArgCount,
char *pszOption);
static void GetNextArgName(int *pnCurrentArg, int nArgCount,
char *papszArguments[], char *pszString,
int nStringSize);
static tCommandLineParameter GetCommandLineParameter(char *pszArgument);
void ParseStandardCommandLine(int nArgCount, char *papszArguments[])
{
char *pszCurrentArg;
int nCurrentArg;
for(nCurrentArg = 1; nCurrentArg < nArgCount; ++nCurrentArg)
{
pszCurrentArg = papszArguments[nCurrentArg];
switch(GetCommandLineParameter(pszCurrentArg))
{
case kParamLocal:
od_control.od_force_local = TRUE;
break;
case kParamBPS:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.baud = atol(papszArguments[nCurrentArg]);
break;
case kParamPort:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.port = atoi(papszArguments[nCurrentArg]);
break;
case kParamHelp:
printf("AVALIABLE COMMAND LINE PARAMETERS:\n");
printf(" -L or -LOCAL - Causes door to operate in local mode, without requiring a\n");
printf(" door information (drop) file.\n");
printf(" -DROPFILE x - Door information file directory or directory+filename.\n");
printf(" -N x or -NODE x - Sets the node number to use.\n");
printf(" -B x or -BPS x - Sets the serial port <---> modem bps (baud) rate to use.\n");
printf(" -P x or -PORT x - Sets the serial port to use, were 0=COM1, 1=COM2, etc.\n");
printf(" -ADDRESS x - Sets serial port address in decimal NOT hexidecimal\n");
printf(" (only has effect if FOSSIL driver is not being used).\n");
printf(" -IRQ x - Sets the serial port IRQ line (only has effect if FOSSIL\n");
printf(" driver is not being used).\n");
printf(" -NOFOSSIL - Disables use of FOSSIL driver, even if available.\n");
printf(" -NOFIFO - Disables use of 16550 FIFO buffers (only if FOSSIL driver\n");
printf(" is not being used).\n");
printf(" -PERSONALITY x - Sets the sysop status line / function key personality to\n");
printf(" use - one of Standard, PCBoard, RemoteAccess or Wildcat.\n");
printf(" -MAXTIME x - Sets the maximum number of minutes that any user will be\n");
printf(" permitted to access the door.\n");
printf(" -USERNAME x - Name of user who is currently online.\n");
printf(" -TIMELEFT x - User's time remaining online.\n");
printf(" -SECURITY x - User's security level.\n");
printf(" -LOCATION x - Location from which user is calling.\n");
printf(" -?, -H or -HELP - Displays command-line help and exits.\n");
exit(1);
break;
case kParamNode:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.od_node = atoi(papszArguments[nCurrentArg]);
break;
case kParamPersonality:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
if(stricmp(papszArguments[nCurrentArg], "Standard") == 0)
{
od_control.od_default_personality = PER_OPENDOORS;
}
else if(stricmp(papszArguments[nCurrentArg], "PCBoard") == 0)
{
od_control.od_default_personality = PER_PCBOARD;
}
else if(stricmp(papszArguments[nCurrentArg], "RemoteAccess") == 0)
{
od_control.od_default_personality = PER_RA;
}
else if(stricmp(papszArguments[nCurrentArg], "Wildcat") == 0)
{
od_control.od_default_personality = PER_WILDCAT;
}
else
{
printf("Unknown personality: %s\n", papszArguments[nCurrentArg]);
exit(1);
}
break;
case kParamMaxTime:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.od_maxtime = atoi(papszArguments[nCurrentArg]);
break;
case kParamAddress:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.od_com_address = atoi(papszArguments[nCurrentArg]);
break;
case kParamIRQ:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.od_com_irq = atoi(papszArguments[nCurrentArg]);
break;
case kParamNoFOSSIL:
od_control.od_no_fossil = TRUE;
break;
case kParamNoFIFO:
od_control.od_com_no_fifo = TRUE;
break;
case kParamDropFile:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
strncpy(od_control.info_path, papszArguments[nCurrentArg],
sizeof(od_control.info_path) - 1);
od_control.info_path[sizeof(od_control.info_path) - 1] = '\0';
break;
case kParamUserName:
GetNextArgName(&nCurrentArg, nArgCount, papszArguments,
od_control.user_name, sizeof(od_control.user_name));
break;
case kParamTimeLeft:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.user_timelimit = atoi(papszArguments[nCurrentArg]);
break;
case kParamSecurity:
AdvanceToNextArg(&nCurrentArg, nArgCount, pszCurrentArg);
od_control.user_security = atoi(papszArguments[nCurrentArg]);
break;
case kParamLocation:
GetNextArgName(&nCurrentArg, nArgCount, papszArguments,
od_control.user_location, sizeof(od_control.user_location));
break;
default:
printf("Unrecognized command line option: %s\n", pszCurrentArg);
exit(1);
break;
}
}
}
static void AdvanceToNextArg(int *pnCurrentArg, int nArgCount, char *pszOption)
{
if(++*pnCurrentArg >= nArgCount)
{
printf("Missing parameter for option: %s\n", pszOption);
exit(1);
}
}
static void GetNextArgName(int *pnCurrentArg, int nArgCount,
char *papszArguments[], char *pszString,
int nStringSize)
{
BOOL bFirst = TRUE;
if((*pnCurrentArg) + 1 >= nArgCount)
{
printf("Missing parameter for option: %s\n",
papszArguments[(*pnCurrentArg) - 1]);
exit(1);
}
pszString[0] = '\0';
while(++*pnCurrentArg < nArgCount)
{
if(GetCommandLineParameter(papszArguments[*pnCurrentArg])
!= kParamUnknown)
{
--*pnCurrentArg;
break;
}
if(strlen(pszString) >= nStringSize - 1)
{
break;
}
if(!bFirst)
{
strcat(pszString, " ");
}
strncat(pszString, papszArguments[*pnCurrentArg],
strlen(pszString) - nStringSize - 1);
pszString[nStringSize - 1] = '\0';
bFirst = FALSE;
}
}
static tCommandLineParameter GetCommandLineParameter(char *pszArgument)
{
if(*pszArgument == '-' || *pszArgument == '/')
{
++pszArgument;
}
if(stricmp(pszArgument, "L") == 0
|| stricmp(pszArgument, "LOCAL") == 0)
{
return(kParamLocal);
}
else if(stricmp(pszArgument, "B") == 0
|| stricmp(pszArgument, "BPS") == 0
|| stricmp(pszArgument, "BAUD") == 0)
{
return(kParamBPS);
}
else if(stricmp(pszArgument, "P") == 0
|| stricmp(pszArgument, "PORT") == 0)
{
return(kParamPort);
}
else if(stricmp(pszArgument, "N") == 0
|| stricmp(pszArgument, "NODE") == 0)
{
return(kParamNode);
}
else if(stricmp(pszArgument, "?") == 0
|| stricmp(pszArgument, "H") == 0
|| stricmp(pszArgument, "HELP") == 0)
{
return(kParamHelp);
}
else if(stricmp(pszArgument, "PERSONALITY") == 0)
{
return(kParamPersonality);
}
else if(stricmp(pszArgument, "MAXTIME") == 0)
{
return(kParamMaxTime);
}
else if(stricmp(pszArgument, "ADDRESS") == 0)
{
return(kParamAddress);
}
else if(stricmp(pszArgument, "IRQ") == 0)
{
return(kParamIRQ);
}
else if(stricmp(pszArgument, "NOFOSSIL") == 0)
{
return(kParamNoFOSSIL);
}
else if(stricmp(pszArgument, "NOFIFO") == 0)
{
return(kParamNoFIFO);
}
else if(stricmp(pszArgument, "DROPFILE") == 0)
{
return(kParamDropFile);
}
else if(stricmp(pszArgument, "USERNAME") == 0)
{
return(kParamUserName);
}
else if(stricmp(pszArgument, "TIMELEFT") == 0)
{
return(kParamTimeLeft);
}
else if(stricmp(pszArgument, "SECURITY") == 0)
{
return(kParamSecurity);
}
else if(stricmp(pszArgument, "LOCATION") == 0)
{
return(kParamLocation);
}
else
{
return(kParamUnknown);
}
}
void NoDoorFileHandler(void)
{
/* Alter OpenDoors behaviour, so that we proceed with defaults if */
/* no door information file is available, rather than exiting with */
/* an error. Set od_no_file_func to point to this function. */
if(strlen(od_control.user_name) == 0)
{
strcpy(od_control.user_name, "Unknown User");
}
if(strlen(od_control.user_location) == 0)
{
strcpy(od_control.user_location, "Unknown Location");
}
if(od_control.user_timelimit == 0)
{
od_control.user_timelimit = 30;
}
od_control.od_info_type = CUSTOM;
}

5
deps/odoors/historic/odtips3/CMDLINE.H vendored Normal file
View File

@@ -0,0 +1,5 @@
#ifndef INC_CMDLINE
#define INC_CMDLINE
void ParseStandardCommandLine(int nArgCount, char *papszArguments[]);
void NoDoorFileHandler(void);
#endif

352
deps/odoors/historic/odtips3/FILEVIEW.C vendored Normal file
View File

@@ -0,0 +1,352 @@
/* fileview.c - File viewing door that demonstrates the use of the */
/* PagedViewer() function. This door can be setup to */
/* to display a single text file, or any file from an */
/* entire directory of text files. The program accepts */
/* a single command-line argument, which if present, */
/* specifies the filename or wildcard of the files to */
/* display. If this argument is not present, all files */
/* in the current directory will be available for */
/* viewing. If there is more than one possible file to */
/* be displayed, this program will display a list of */
/* files that the user can choose from to display. If */
/* there is only one possible file, that file is */
/* is displayed. This program uses PagedViewer() for two */
/* seperate uses - the list of available files, and for */
/* viewing the file itself. */
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include "bpfind.h"
#include "opendoor.h"
#include "pageview.h"
/* Configurable constants. */
#define FILENAME_SIZE 75
#define PATH_CHARS (FILENAME_SIZE - 13)
#define LINE_SIZE 80
#define ARRAY_GROW_SIZE 20
/* Global variables. */
int nTotalFiles = 0;
int nFileArraySize = 0;
char *paszFileArray = NULL;
FILE *pfCurrentFile;
int nTotalLines = 0;
int nLineArraySize = 0;
long *palLineOffset = NULL;
/* Function prototypes. */
void AddFilesMatching(char *pszFileSpec);
char *GetFilename(int nIndex);
int AddFilename(char *pszFilename);
void GetDirOnly(char *pszOutDirName, const char *pszInPathName);
int DirExists(const char *pszDirName);
void BuildPath(char *pszOut, char *pszPath, char *pszFilename);
void FreeFileList(void);
void DisplayFileName(int nLine, void *pCallbackData);
void DisplayFile(char *pszFilename);
void DisplayFileLine(int nLine, void *pCallbackData);
int AddOffsetToArray(long lOffset);
void FreeLineArray(void);
/* Program execution begins here. */
int main(int nArgCount, char *papszArgument[])
{
int nArg;
int nChoice;
od_init();
/* Get file specifiction from command-line, if any. */
if(nArgCount >= 2)
{
for(nArg = 1; nArg < nArgCount; ++nArg)
{
AddFilesMatching(papszArgument[nArg]);
}
}
/* If there are no command-line parameters, use *.* */
else
{
AddFilesMatching("*.*");
}
/* If there are no matching files, display error. */
if(nTotalFiles == 0)
{
od_printf("No files were found.\n\r\n\r");
od_printf("Press [Enter] to continue.\n\r");
od_get_answer("\n\r");
return(0);
}
/* If only one file was found, then display it. */
else if(nTotalFiles == 1)
{
DisplayFile(GetFilename(0));
}
/* If more than one file was found, allow user to choose file */
/* to display. */
else
{
/* Loop until user chooses to quit. */
nChoice = 0;
for(;;)
{
/* Get user's selection. */
nChoice = PagedViewer(nChoice, nTotalFiles, DisplayFileName,
NULL, TRUE, "Choose A File To Display", 19);
/* If user chose to quit, then exit door. */
if(nChoice == NO_LINE) break;
/* Otherwise, display the file that the user chose. */
DisplayFile(GetFilename(nChoice));
}
}
FreeFileList();
return(0);
}
void AddFilesMatching(char *pszFileSpec)
{
struct ffblk DirEntry;
int bNoMoreFiles;
char szDirName[PATH_CHARS + 1];
char szFileName[FILENAME_SIZE];
/* Check that file specification is not too long. */
if(strlen(pszFileSpec) > PATH_CHARS)
{
return;
}
/* Get directory name from path. */
GetDirOnly(szDirName, pszFileSpec);
bNoMoreFiles = findfirst(pszFileSpec, &DirEntry, FA_RDONLY);
while(!bNoMoreFiles)
{
BuildPath(szFileName, szDirName, DirEntry.ff_name);
AddFilename(szFileName);
bNoMoreFiles = findnext(&DirEntry);
}
}
void GetDirOnly(char *pszOutDirName, const char *pszInPathName)
{
char *pchBackslashChar;
/* Default dir name is entire path. */
strcpy(pszOutDirName, pszInPathName);
/* If there is a backslash in the string. */
pchBackslashChar = strrchr(pszOutDirName, '\\');
if(pchBackslashChar != NULL)
{
/* Remove all character beginning at last backslash from path. */
*pchBackslashChar = '\0';
}
else
{
/* If there is no backslash in the filename, then the dir name */
/* is empty. */
pszOutDirName[0] = '\0';
}
}
void BuildPath(char *pszOut, char *pszPath, char *pszFilename)
{
/* Copy path to output filename. */
strcpy(pszOut, pszPath);
/* Ensure there is a trailing backslash. */
if(strlen(pszOut) > 0 && pszOut[strlen(pszOut) - 1] != '\\')
{
strcat(pszOut, "\\");
}
/* Append base filename. */
strcat(pszOut, pszFilename);
}
char *GetFilename(int nIndex)
{
return(paszFileArray + (nIndex * FILENAME_SIZE));
}
int AddFilename(char *pszFilename)
{
int nNewArraySize;
char *paszNewArray;
char *pszNewString;
/* If array is full, then try to grow it. */
if(nTotalFiles == nFileArraySize)
{
nNewArraySize = nFileArraySize + ARRAY_GROW_SIZE;
if((paszNewArray =
realloc(paszFileArray, nNewArraySize * FILENAME_SIZE)) == NULL)
{
return(FALSE);
}
nFileArraySize = nNewArraySize;
paszFileArray = paszNewArray;
}
/* Get address to place new string at, while incrementing total number */
/* of filenames. */
pszNewString = GetFilename(nTotalFiles++);
/* Copy up to the maximum number of filename characters to the string. */
strncpy(pszNewString, pszFilename, FILENAME_SIZE - 1);
pszNewString[FILENAME_SIZE - 1] = '\0';
return(TRUE);
}
void FreeFileList(void)
{
if(nFileArraySize > 0)
{
free(paszFileArray);
nFileArraySize = 0;
nTotalFiles = 0;
paszFileArray = NULL;
}
}
void DisplayFileName(int nLine, void *pCallbackData)
{
(void)pCallbackData;
od_printf(GetFilename(nLine));
}
void DisplayFile(char *pszFilename)
{
char szLine[LINE_SIZE];
long lnOffset;
/* Clear the screen. */
od_clr_scr();
/* Attempt to open the file. */
pfCurrentFile = fopen(pszFilename, "r");
if(pfCurrentFile == NULL)
{
od_printf("Unable to open file.\n\r\n\r");
od_printf("Press [Enter] to continue.\n\r");
od_get_answer("\n\r");
return;
}
/* Get file offsets of each line and total line count from file. */
for(;;)
{
lnOffset = fTell(pfCurrentFile);
if(fgets(szLine, LINE_SIZE, pfCurrentFile) == NULL) break;
AddOffsetToArray(lnOffset);
}
/* Use PagedViewer() to view the file. */
PagedViewer(0, nTotalLines, DisplayFileLine, NULL, FALSE, NULL, 21);
/* Deallocate array of line offsets. */
FreeLineArray();
/* Close the file. */
fclose(pfCurrentFile);
}
void DisplayFileLine(int nLine, void *pCallbackData)
{
char szLine[LINE_SIZE];
long lnTargetOffset = palLineOffset[nLine];
int nLineLen;
(void)pCallbackData;
/* Move to proper offset in file. */
if(lnTargetOffset != ftell(pfCurrentFile))
{
fseek(pfCurrentFile, lnTargetOffset, SEEK_SET);
}
/* Get line from line. */
if(fgets(szLine, LINE_SIZE, pfCurrentFile) != NULL)
{
/* Remote any trailing CR/LF sequence from line. */
nLineLen = strlen(szLine);
while(nLineLen > 0
&& (szLine[nLineLen - 1] == '\r' || szLine[nLineLen - 1] == '\n'))
{
szLine[--nLineLen] = '\0';
}
/* Display the line on the screen. */
od_disp_str(szLine);
}
}
int AddOffsetToArray(long lOffset)
{
long *palNewArray;
int nNewArraySize;
/* If array is full, then grow it. */
if(nTotalLines == nLineArraySize)
{
nNewArraySize = nLineArraySize + ARRAY_GROW_SIZE;
if((palNewArray =
realloc(palLineOffset, nNewArraySize * sizeof(long))) == NULL)
{
return(FALSE);
}
nLineArraySize = nNewArraySize;
palLineOffset = palNewArray;
}
palLineOffset[nTotalLines++] = lOffset;
return(TRUE);
}
void FreeLineArray(void)
{
if(nLineArraySize > 0)
{
nTotalLines = 0;
nLineArraySize = 0;
free(palLineOffset);
palLineOffset = NULL;
}
}

177
deps/odoors/historic/odtips3/PAGEVIEW.C vendored Normal file
View File

@@ -0,0 +1,177 @@
/* pageview.c - Implementation of the PagedViewer() system. */
#include <string.h>
#include "opendoor.h"
#include "pageview.h"
char bTitleColor = 0x0c;
char bTitleLineColor = 0x04;
char bNumberColor = 0x0a;
char bTextColor = 0x02;
char bPromptColor = 0x0f;
int PagedViewer(
int nInitialLine, /* Zero-based initial line number. */
int nTotalLines, /* Total line count. */
void (*pDisplayCallback)(int nLine, void *pData),
void *pCallbackData, /* Data to pass to callback func. */
BOOL bAllowSelection, /* TRUE if selection is permitted. */
char *pszTitle, /* Title string, or NULL. */
int nPageSize) /* # of lines to display per page. */
{
int nCurrentPage = 0;
int nScreenLine;
int nAbsoluteLine;
char chPressed;
char bCanPageDown;
char bCanPageUp;
/* Determine current page from initial line number, if specified. */
if(nInitialLine != NO_LINE)
{
nCurrentPage = nInitialLine / nPageSize;
}
/* Loop until user makes a selection, or chooses to quit. */
for(;;)
{
/* Display the current page. */
/* Clear the screen */
od_printf("\n\r");
od_clr_scr();
/* If a title has been specified, then display it. */
if(pszTitle != NULL)
{
od_set_attrib(bTitleColor);
od_repeat(' ', (80 - strlen(pszTitle)) / 2);
od_disp_str(pszTitle);
od_printf("\n\r");
od_set_attrib(bTitleLineColor);
if(od_control.user_ansi || od_control.user_avatar)
{
od_repeat(196, 79);
}
else
{
od_repeat('-', 79);
}
od_printf("\n\r");
}
/* Display the lines on this page. */
nAbsoluteLine = nCurrentPage * nPageSize;
nScreenLine = 0;
while(nScreenLine < nPageSize && nAbsoluteLine < nTotalLines)
{
/* If selection is permitted, display an identifier for each line. */
if(bAllowSelection)
{
od_set_attrib(bNumberColor);
if(nScreenLine < 9)
{
od_printf("%d. ", nScreenLine + 1);
}
else
{
od_printf("%c. ", 'A' + (nScreenLine - 9));
}
}
/* Display the line itself. */
od_set_attrib(bTextColor);
(*pDisplayCallback)(nAbsoluteLine, pCallbackData);
od_printf("\n\r");
/* Move to next line. */
nScreenLine++;
nAbsoluteLine++;
}
/* Determine whether user can page up or down from this page. */
bCanPageDown = nCurrentPage < (nTotalLines - 1) / nPageSize;
bCanPageUp = nCurrentPage > 0;
/* Display prompt at bottom of screen. */
od_set_attrib(bPromptColor);
od_printf("\n\r[Page %d of %d] ", nCurrentPage + 1,
((nTotalLines - 1) / nPageSize) + 1);
if(bAllowSelection)
{
od_printf("Choose an option or");
}
else
{
od_printf("Available options:");
}
if(bCanPageDown)
{
od_printf(" [N]ext page,");
}
if(bCanPageUp)
{
od_printf(" [P]revious page,");
}
od_printf(" [Q]uit.");
/* Loop until the user makes a valid choice. */
for(;;)
{
/* Get key from user */
chPressed = toupper(od_get_key(TRUE));
if(chPressed == 'Q')
{
/* If user chooses to quit, then return without a selection. */
od_printf("\n\r");
return(NO_LINE);
}
else if(chPressed == 'P' && bCanPageUp)
{
/* Move to previous page and redraw screen. */
--nCurrentPage;
break;
}
else if(chPressed == 'N' && bCanPageDown)
{
/* Move to next page and redraw screen. */
++nCurrentPage;
break;
}
else if(bAllowSelection
&& (
(chPressed >= '1' && chPressed <= '9')
|| (chPressed >= 'A' && chPressed <= 'M')
)
)
{
/* If user pressed a possible line key, and selection is */
/* enabled, try translating character to a line number. */
if(chPressed >= '1' && chPressed <= '9')
{
nScreenLine = chPressed - '1';
}
else
{
nScreenLine = 9 + (chPressed - 'A');
}
/* Calculate absolute line number. */
nAbsoluteLine = nScreenLine + (nCurrentPage * nPageSize);
/* If selected line is within range, then return selected line */
/* number. */
if(nScreenLine < nPageSize && nAbsoluteLine < nTotalLines)
{
od_printf("\n\r");
return(nAbsoluteLine);
}
}
}
}
}

19
deps/odoors/historic/odtips3/PAGEVIEW.H vendored Normal file
View File

@@ -0,0 +1,19 @@
/* pageview.h - Include file for PagedViewer() function. */
/* Manifest constant. */
#define NO_LINE -1
/* Boolean definitions. */
#ifndef BOOL
typedef int BOOL;
#endif
/* Prototype for the function. */
int PagedViewer(
int nInitialLine,
int nTotalLines,
void (*pDisplayCallback)(int nLine, void *pCallbackData),
void *pCallbackData,
BOOL bAllowSelection,
char *pszTitle,
int nPageSize);

46
deps/odoors/historic/odtips3/SUMMARY.TXT vendored Normal file
View File

@@ -0,0 +1,46 @@
OpenDoors tips package #3
---
(C) Copyright 1994, Brian Pirie. All Rights Reserved.
This package includes a collection of tips and utility functions to help
those using the OpenDoors door programming toolkit. You are free to use
these tips and included source code as you wish, without any fee or
royalty.
This package includes the following tip files:
Tip #1. Drawing horizontal bar graphs using od_repeat().
Files: tip1.txt, tip1.c
Tip #2. Transferring files using DSZ.
Files: tip2.txt, tip2.c
Tip #3. A generic paged viewing / selection routine, and text file
viewing door that uses the paged viewing routine.
Files: tip3.txt, pageview.c, pageview.h, fileview.c, bpfind.h
Tip #4. Command-line processing for many standard door-related command
line options.
Files: tip4.txt,tip4.c, cmdline.c, cmdline.h
How to contact the author
-------------------------
I can be reached by any of the following means:
Internet email : brianp@bpecomm.ocunix.on.ca
Fidonet Crashmail : 1:243/8 (you must poll for a response)
Modem (24hrs/day) : +1 613 526 4466
Conventional mail : Brian Pirie
#1416 - 2201 Riverside Drive
Ottawa, Ontario
K1H 8K9
Canada

88
deps/odoors/historic/odtips3/TIP1.C vendored Normal file
View File

@@ -0,0 +1,88 @@
/* Includes */
#include "opendoor.h"
/* Function prototypes. */
void DrawHorizontalBar(int nValue, int nMinValue, int nMaxValue,
int nMaxChars);
void DrawGraphOfPercentages(int nItems, int *panPercentages,
char **papszTitles, char bTitleColor, char bGraphColor,
int nTitleWidth, int nGraphWidth);
/* Main function - program execution begins here. */
main()
{
char *apszTitles[7] = {"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"};
int anValues[7] = {50, 75, 100, 25, 83, 0, 43};
od_printf("`bright green`Test graph:\n\r");
DrawGraphOfPercentages(7, anValues, apszTitles, 0x02, 0x0f, 20, 50);
od_get_key(TRUE);
return(0);
}
/* Function to draw horizontal graph of percentages with titles, to */
/* demonstrate the use of the DrawHorizontalBar() function. */
/* No titles should have more than nTitleWidth characters. */
void DrawGraphOfPercentages(int nItems, int *panPercentages,
char **papszTitles, char bTitleColor, char bGraphColor,
int nTitleWidth, int nGraphWidth)
{
int nCurrentItem;
/* Loop for each item (line) in the graph. */
for(nCurrentItem = 0; nCurrentItem < nItems; ++nCurrentItem)
{
/* Set display color for title text. */
od_set_attrib(bTitleColor);
/* Add spaces to right-align all titles. */
od_repeat(' ', nTitleWidth - strlen(papszTitles[nCurrentItem]));
/* Display the title. */
od_disp_str(papszTitles[nCurrentItem]);
/* Add space between title and graph. */
od_printf(" ");
/* Set display color for graph. */
od_set_attrib(bGraphColor);
/* Draw bar graph for this line. */
DrawHorizontalBar(panPercentages[nCurrentItem], 0, 100, nGraphWidth);
/* Move to the next line. */
od_printf("\n\r");
}
}
/* Function to draw a horizontal bar, given a value, the minimum and maximum */
/* possible values, and the number of characters the horizontal bar should */
/* extended for the maximum value. */
void DrawHorizontalBar(int nValue, int nMinValue, int nMaxValue,
int nMaxChars)
{
/* Determine lenght of bar */
int nBarChars = ((nValue - nMinValue) * nMaxChars) / nMaxValue;
if(od_control.user_ansi || od_control.user_avatar)
{
/* If ANSI or AVATAR graphics are available, assume that IBM extended */
/* ASCII is also available. This function uses character 220 to form */
/* bars that are 1/2 the height of the line. You might also want to */
/* try character 119, which will form bars that are the entire height */
/* of the line. */
od_repeat(220, nBarChars);
}
else
{
/* In ASCII mode, the bar is formed by the '=' character. */
od_repeat('=', nBarChars);
}
}

55
deps/odoors/historic/odtips3/TIP1.TXT vendored Normal file
View File

@@ -0,0 +1,55 @@
Many different types of programs can be enhanced by the use of graphical
information. Often, this graphical information can take the form of
horizontal bar graphs.
An easy way to draw horizontal bars in door programs written with
OpenDoors, is to use the od_repeat() function. Not only does od_repeat()
allow you to easily form a bar by repeating a particular character the
specified number of times, but it is also a very efficient way to do so.
od_repeat() will take advantage of terminal emulation optimizations,
when available. For instance, a character can be repeated any number of
times with AVATAR by sending a short 3-byte sequence that specifies the
character and number of times to repeat.
How do you calculate the number of character to use to form a bar in
your graph? The DrawHorizontalBar() function, which is provided below,
will do this calculation for you. Simply provide the value to be
represented by this bar, the minimum and maximum possible values, and
the maximum number of character to use to draw the bar. For example, if
you are graphing percentages (which could range from 0% to 100%), and
wanted the graph to fit in a space of 40 columns, you would use:
DrawHorizontalBar(nPercent, 0, 100, 40);
The included tip1.c is a complete program which demonstrates the
DrawHorizontalBar() function as called from another function that will
create complete horizontal bar graphs. This second function,
DrawGraphOfPercentages(), takes an array of titles, and array of values
corresponding to each title, and draws a complete bar graph from this
information.
/* Function to draw a horizontal bar, given a value, the minimum and maximum */
/* possible values, and the number of characters the horizontal bar should */
/* extended for the maximum value. */
void DrawHorizontalBar(int nValue, int nMinValue, int nMaxValue,
int nMaxChars)
{
/* Determine lenght of bar */
int nBarChars = ((nValue - nMinValue) * nMaxChars) / nMaxValue;
if(od_control.user_ansi || od_control.user_avatar)
{
/* If ANSI or AVATAR graphics are available, assume that IBM extended */
/* ASCII is also available. This function uses character 220 to form */
/* bars that are 1/2 the height of the line. You might also want to */
/* try character 119, which will form bars that are the entire height */
/* of the line. */
od_repeat(220, nBarChars);
}
else
{
/* In ASCII mode, the bar is formed by the '=' character. */
od_repeat('=', nBarChars);
}
}

245
deps/odoors/historic/odtips3/TIP2.C vendored Normal file
View File

@@ -0,0 +1,245 @@
/* tip2.c - Example program to demonstrate how to send or receive files */
/* using DSZ, from within an OpenDoors program. */
/* Include required header files. */
#include <stdio.h>
#include <assert.h>
#include "opendoor.h"
/* File transfer protocol enumeration. */
typedef enum
{
XModem,
XModemCRC,
XModem1K,
YModem,
YModemG,
ZModem
} eProtocol;
/* Function prototypes. */
int TransferFile(char *pszFilename, eProtocol Protocol, char bReceive);
eProtocol ChooseProtocol(void);
void AddParameter(char **papszArguments, int *pnCount, char *pszNewArgument);
/* Manifest constants. */
#define ARGS_ARRAY_SIZE 10
/* Global variable with DSZ filename. */
char szDSZFilename[80] = "DSZ";
/* Program's execution begins here. */
main()
{
char chAnswer;
char bReceive;
eProtocol Protocol;
char szFilename[73];
int bSuccess;
od_printf("OpenDoors file transfer demo.\n\r\n\r");
/* Get file transfer direction from user. */
od_printf("Do you wish to [U]pload or [D]ownload? ");
chAnswer = od_get_answer("UD");
if(chAnswer == 'U')
{
od_printf("Upload\n\r\n\r");
bReceive = TRUE;
}
else
{
od_printf("Download\n\r\n\r");
bReceive = FALSE;
}
/* Get file transfer protocol from user. */
Protocol = ChooseProtocol();
/* Get filename. */
od_printf("\n\rEnter filename(s) : ");
od_input_str(szFilename, 72, ' ', 255);
od_printf("\n\r");
/* Perform file transfer. */
bSuccess = TransferFile(szFilename, Protocol, bReceive);
/* Display result of file transfer to user. */
od_clr_scr();
if(bSuccess)
{
od_printf("File transfer successful.\n\r");
}
else
{
od_printf("File transfer not completed.\n\r");
}
/* Prompt user to exit program. */
od_printf("Press [Enter] to return to BBS.\n\r");
od_get_answer("\n\r");
/* Return control to calling BBS software. */
od_exit(0, FALSE);
return(0);
}
/* Function to allow user to choose a file transfer protocol. */
eProtocol ChooseProtocol(void)
{
eProtocol Protocol;
char chAnswer;
od_printf("Available file transfer protocols:\n\r");
od_printf(" [X] XModem\n\r");
od_printf(" [C] XModem/CRC\n\r");
od_printf(" [1] XModem/1K\n\r");
od_printf(" [Y] YModem\n\r");
od_printf(" [G] YModem-G\n\r");
od_printf(" [Z] ZModem\n\r\n\r");
od_printf("Please select a protocol: ");
chAnswer = od_get_answer("XC1YGZ");
switch(chAnswer)
{
case 'X':
od_printf("XModem\n\r");
Protocol = XModem;
break;
case 'C':
od_printf("XModem/CRC\n\r");
Protocol = XModemCRC;
break;
case '1':
od_printf("XModem/1K\n\r");
Protocol = XModem1K;
break;
case 'Y':
od_printf("YModem\n\r");
Protocol = YModem;
break;
case 'G':
od_printf("YModem-G\n\r");
Protocol = YModemG;
break;
case 'Z':
default:
od_printf("ZModem\n\r");
Protocol = ZModem;
break;
}
return(Protocol);
}
/* Function to send or receive a file to/from remote system. */
int TransferFile(char *pszFilename, eProtocol Protocol, char bReceive)
{
char szPort[7];
char *apszArguments[ARGS_ARRAY_SIZE];
int nArgCount = 0;
/* Filename cannot be NULL. */
assert(pszFilename != NULL);
/* Ensure that we are not operating in local mode. */
if(od_control.baud == 0)
{
od_printf("Operating in local mode; file transfer not possible.\n\r");
return(FALSE);
}
/* Generate DSZ command line */
/* Begin with executable filename. */
AddParameter(apszArguments, &nArgCount, szDSZFilename);
/* Add port parameter. */
AddParameter(apszArguments, &nArgCount, "port");
sprintf(szPort, "%d", od_control.port + 1);
AddParameter(apszArguments, &nArgCount, szPort);
/* Restrict inbound files to current drive and directory. */
AddParameter(apszArguments, &nArgCount, "restrict");
/* Generate DSZ protocol parameters from specified protocol and direction. */
if(bReceive)
{
switch(Protocol)
{
case XModem:
case XModem1K:
AddParameter(apszArguments, &nArgCount, "rx");
break;
case XModemCRC:
AddParameter(apszArguments, &nArgCount, "rc");
break;
case YModem:
AddParameter(apszArguments, &nArgCount, "rb");
break;
case YModemG:
AddParameter(apszArguments, &nArgCount, "rb");
AddParameter(apszArguments, &nArgCount, "-g");
break;
case ZModem:
AddParameter(apszArguments, &nArgCount, "rz");
break;
default:
assert(FALSE);
}
}
else
{
switch(Protocol)
{
case XModem:
case XModemCRC:
AddParameter(apszArguments, &nArgCount, "sx");
break;
case XModem1K:
AddParameter(apszArguments, &nArgCount, "sx");
AddParameter(apszArguments, &nArgCount, "-k");
break;
case YModem:
case YModemG:
AddParameter(apszArguments, &nArgCount, "sb");
break;
case ZModem:
AddParameter(apszArguments, &nArgCount, "sz");
break;
default:
assert(FALSE);
}
}
/* Add filename parameter to command line. */
AddParameter(apszArguments, &nArgCount, pszFilename);
/* Display prompt to user providing */
od_printf("Begin your transfer now, or press [Ctrl]-[X] several times to abort.\n\r");
/* Execute command using the OpenDoors od_spawn() function. */
return(od_spawnvpe(P_WAIT, apszArguments[0], apszArguments, NULL) == 0);
}
/* Function to add next parameter to array of parameters to pass to */
/* od_spawnvpe(). */
void AddParameter(char **papszArguments, int *pnCount, char *pszNewArgument)
{
assert(*pnCount < ARGS_ARRAY_SIZE - 1);
assert(papszArguments != NULL);
assert(pnCount != NULL);
assert(pszNewArgument != NULL);
/* Add next argument to array. */
papszArguments[(*pnCount)++] = pszNewArgument;
/* Ensure that the array is always NULL-terminated. */
papszArguments[*pnCount] = NULL;
}

45
deps/odoors/historic/odtips3/TIP2.TXT vendored Normal file
View File

@@ -0,0 +1,45 @@
Often, it can be useful or necessary to send and receive files between
a program using OpenDoors, and the remote user's system. To allow file
uploading and downloadeding, you can either implement the common file
transfer protocols as part of your program, or you can call an external
file transfer program, such as DSZ. This tip demonstrates how you can
call DSZ using OpenDoors.
In order to see this program in action, you should run a terminal
program on one machine, and connect to second machine that will run this
example program. (You could also do this in two different windows on one
machine.) The demonstration program will ask whether you want to upload
or download files, and will then prompt you for the file transfer protocol
to use and the filename to transfer. Once this is done, DSZ is invoked
to perform the file transfer. As such, DSZ will need to be installed on
the machine that will run the example program.
The tip2.c source file provides a function that you can use to perform
file transfers. This function is defined as follows:
int TransferFile(char *pszFilename, eProtocol Protocol, char bReceive)
The first parameter should contain the name of the file or files to be
transfered. The second parameter should specify the file transfer
protocol to use, and should be one of the following enumerated
constants:
XModem
XModemCRC
XModem1K
YModem
YModemG
ZModem
The third parameter specifies whether the file is being send (FALSE) or
received (TRUE). From the user's perspective, sending the file means
downloading, and receiving the file means uploading.
The TransferFile() function returns TRUE if the file transfer was
completed, and FALSE if it was not.
If the DSZ program is not present in the system's PATH or the current
directory, then the global variable szDSZFilename must be set to the
full path and filename of the DSZ program. This could be done by adding
a custom OpenDoors configuration file line with a keyword such as
"DSZPath".

82
deps/odoors/historic/odtips3/TIP3.TXT vendored Normal file
View File

@@ -0,0 +1,82 @@
Many people have admired the paged question selection facility in the
OpenDoors 5.00 EZVote example door. EZVote allows the user to choose
questions from a list of up to 200 questions, by displaying one page
of questions at a time. The user is able to page up or down in the list
of quesitons, select a question from the list, or return to the main
menu. A prompt at the bottom of the screen shows the current page
number, and a list of options that are currently available. For
instance, when displaying the first of two pages, this prompt indicates
that the user can move to the next page, but not the previous page.
This OpenDoors Tip shows a generic function that provides the same sorts
of capabilities that are seen in the EZVote example door, in a form that
can be re-used in many different programs. This function, named
PagedViewer(), can be used for displaying multi-paged messages, text
files, or for permitting selection from a potentially very long list of
items. To use the PagedViewer() in a program, you should add the
pageview.c file to your project file / makefile, and #include the
pageview.h file in any source file that calls PagedViewer().
The prototype for the PagedViewer() function is as follows:
int PagedViewer(
int nInitialLine,
int nTotalLines,
void (*pDisplayCallback)(int nLine, void *pCallbackData),
void *pCallbackData,
BOOL bAllowSelection,
char *pszTitle,
int nPageSize);
The nInitialLine parameter specifies the line to begin viewing at.
Normally this would be 0, but you may wish to pass a different value to
this function to force the viewer to begin on a page other than the
first. Using this parameter, you can have the user return to
the page they were previously viewing, rather than returning to the
first page and having to again find their original location.
The nTotalLines parameter specifies the total number of lines that can
be viewed, and can be any value greater than or equal to 0.
The pDisplayCallback parameter must be a pointer to a function that the
PagedViewer will call to display a particular line of the file at the
current location. When PagedViewer() calls your function, it will pass
the line number to be displayed, along with the value originally passed
to PagedViewer() in pCallbackData. The provided function should simply
display the text for the specified line number, without a trailing CR/LF
sequence, and then return.
The pCallbackData can point to any data that you wish PagedViewer() to
pass to your callback function, or may be NULL if you do not wish to use
this feature.
The bAllowSelection parameter should be TRUE if the user should be able
to make a selection from the list, and FALSE if they should not. If
bAllowSelection is TRUE, PagedViewer() will display a letter beside each
line, and allow the user to select a line by pressing the corresponding
letter. If you are using PagedViewer() to display a text file or
message, you will want to set bAllowSelection to FALSE. If you are using
PagedViewer() to display a list of items from which the user can select,
you will want to set bAllowSelection to TRUE.
The pszTitle parameter can point to a title to be displayed at the top
of each page, and could be something like ("Select a message"). If you
do not wish to have a title displayed, set this parameter to NULL.
The nPageSize parameter specifies the number of lines that should be
displayed on each page. If you do not wish to have the local screen
(with a two line status line) to be scrolled while displaying the list,
the maximum page size you should use is 21 if no title is being
displayed, and 19 if a title is being displayed.
The included fileview.c text file viewing program demonstrates the use
of PagedViewer(). The fileview.c door can be setup to allow the user to
view one or more files. If setup to view multiple files, the program
first displays a list of files that the user can select to view.
The fileview.c program uses PagedViewer() in two places - for providing
the list of files and for displaying the file itself. As such, the user
can page up or down in the list of files, select a file to view, and
then page up or down in the file. When the user selects quit while
viewing the file, they are returned to the list of files to possibly
select another file. When the user selects quit from the list of files,
the door returns control to the calling BBS software.

19
deps/odoors/historic/odtips3/TIP4.C vendored Normal file
View File

@@ -0,0 +1,19 @@
#include "opendoor.h"
#include "cmdline.h"
int main(int argc, char *argv[])
{
/* Set function to be called if no door information file is found. */
od_control.od_no_file_func = NoDoorFileHandler;
/* Call command-line processing function before first call to any */
/* OpenDoors function! */
ParseStandardCommandLine(argc, argv);
/* Proceed with door normally. */
od_printf("Hello World!\n\r\n\r");
od_printf("Press [Enter] to return to BBS.\n\r");
od_get_answer("\n\r");
return(0);
}

50
deps/odoors/historic/odtips3/TIP4.TXT vendored Normal file
View File

@@ -0,0 +1,50 @@
It is common for BBS door programs to accept command line parameters
that permit various door-related settings, such as the serial port, baud
rate, and node number. This tip demonstrates how you can do this when
working with OpenDoors. This tip is presented in the following files:
cmdline.h - Header file for command line processing function.
cmdline.c - Implementation of command line processing function.
tip4.c - Example of a program that uses the command line
processing function.
The cmdline.c module implements the ParseStandardCommandLine() function,
which takes as its parameters the same argc and argv parameters that are
passed to the main() function of any C program. The
ParseStandardCommandLine() function then sets the appropriate OpenDoors
settings based on the following optional command-line parameters:
-L or -LOCAL - Causes door to operate in local mode, without
requiring a door information (drop) file.
-B x or -BPS x - Sets the bps (baud) rate to use.
-P x or -PORT x - Sets the serial port to use, were 0=COM1, 1=COM2,
etc.
-N x or -NODE x - Sets the node number to use.
-?, -H or -HELP - Displays command-line help and exits
-PERSONALITY x - Sets the sysop status line / function key
personality to use.
-MAXTIME x - Sets the maximum number of minutes that any
user will be permitted to access the door.
-ADDRESS x - Sets serial port address, to be used if FOSSIL
driver is not being used.
-IRQ x - Sets the serial port IRQ line, to be used if
FOSSIL driver is not being used.
-NOFOSSIL - Disables use of FOSSIL driver, even if it is
present.
-NOFIFO - Disables use of 16550 FIFO buffers (only if
FOSSIL driver is not being used).
-DROPFILE x - Door information file directory or
directory+filename.
-USERNAME x - Name of user who is currently online.
-TIMELEFT x - User's time remaining online.
-SECURITY x - User's security level.
-LOCATION x - Location from which user is calling.
Note that any information that is available from the door information
file overrides information provided on the command-line. If sufficient
parameters are provided on the command-line, the door can be operated
without a door information file. In order to do this, cmdline.c provides
a callback function that you can hook into od_control.od_no_file_func,
as demonstrated in tip4.c.
Case is not sensitive in the names of command line arguments.