opendoors/historic/ODTJ9402.TXT

ÚÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ¿
³ Ü  Ü                             Ü                  ³ Volume 94  Issue 2  ³
³ÜÛÜ Û   Ûßß     ÜÜÜ ÛßÛ Ûßß ÛÛÜ ÜÜÛ ÜÜÜ ÜÜÜ ÜÜÜ Ûßß  ³ September 23, 1994  ³
³ Û  ÛßÛ Ûß      Û Û ÛÜÛ Ûß  Û Þ Û Û Û Û Û Û Û   ßßÛ  ³                     ³
³ ÛÛ Û Û ÛÛÛ     ÛÛÛ Û   ÛÛÛ Û Þ ÛÛÛ ÛÛÛ ÛÛÛ Û   ÛÛÛ  ³ "The greatest thing ³
³ Ü          Ü                               Ü        ³  to happen to       ³
³ÜÛÜ Ûßß ÜÜÜ Û         Û ÜÜÜ Û Û ÜÜÜ ÛÛÜ ßßÛ Û        ³  journalism since   ³
³ Û  Ûß  Û   ÛßÛ     Ý Û Û Û Û Û Û   Û Þ ÛßÛ Û        ³  Real People!"      ³
³ ÛÛ ÛÛÛ ÛÛÛ Û Û     ÛÛÛ ÛÛÛ ÛÛÛ Û   Û Þ ÛÛÛ ÛÛÛ      ³                     ³
³                                                     ³ Ed: Scott Burkett   ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

In this action-packed issue:

        - A Word from the Editor
        - OpenDoors 5.0 Released!
        - OpenDoors 5.0 Changes
        - Bits 'n Bytes 'n Data types
        - Adding InterBBS Capabilities to OpenDoors programs
        - Opendoors Tech Corner - Inside OD 5.0's Internal Async Routines
        - Opendoors Tech Corner - Adding Local Mode Functionality
        - Opendoors Tech Corner - Finding physical cursor position in OD 5.0
        - Opendoors Tech Corner - Using UP/DOWN Arrow Keys in OD 5.0
        - Opendoors Tech Corner - Drawing bar graphs with OD!
        - Opendoors Tech Corner - Obtaining Names/Passwords in ASCII Mode
        - Opendoors Tech Corner - Files Transfers under OpenDoors
        - Opendoors Tech Corner - Comparing file stamps
        - Opendoors Tech Corner - Generating Fidonet *.MSG Messages
        - Code Snippets!
        - Opendoors Release Notice: BCHECKERS v1.2
        - Opendoors Release Notice: BFE 4.00.2r
        - Opendoors Release Notice: GIF View Preview Door v1.0
        - Opendoors Release Notice: Operation: Office v.05
        - OpenDoors Tech Journal Information

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ A Word from the Editor ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßß

By: Scott Burkett

After many months of toiling, sweating, complaining, and otherwise
groveling - it is now official - OpenDoors v5.0 has arrived!  Brian has
once again displayed his ability to provide his customers with simply
the best C-based door kit in existence.

I've moved!  Actually, I'm still moving.  My wife and I just moved to
the Tampa Bay, Florida area and so far, so good!  Actually, the author
of RemoteAccess, Andrew Milner lives in Clearwater now - supposedly owns
his own bar.  I would go looking him up, but I'm afraid what might
happen if Andrew and I spent too much time together with his alcohol
supply.  Such is life.

If you haven't noticed by now, this issue is big - no, huge is more like
it.  I've been saving bits and pieces here and there.  Actually, I was
waiting on OD 5.0 to be released, and the pile just kept growing.  I
am convinced that the only reason Brian finally released 5.0, was to
diminish my growing stack of code snippets.... :-)

Just a reminder, but please be sure to send me any release notices for
your latest OpenDoors creations!  Without being notified, chances are,
it won't appear in ODTJ.  Free advertising is nice, isn't it.... :-)

Alles Klaar und spater! (Until the next issue...)

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors 5.0 Released! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßß

By: Brian Pirie

This edition of the ODTJ marks the release of OpenDoors 5.00.  Version 5.00
embodies some major steps forward for OpenDoors, including built-in
asynchronous serial I/O capabilities, support for non-Borland C compilers
such as Microsoft C, and a set of new advanced screen, window and popup menu
functions. Many small enhancements have also been made, along with many
efficiency improvements. As the long "new features and enhancements" list for
version 5.00 will testify, this new release is one of the largest upgrades
ever made to the capabilities of OpenDoors. Version 5.00 has also been more
extensively tested than any previous version of OpenDoors, making it one of
the most stable and efficient foundations on which you could choose to build
your on-line software.

Yet, even with all of the improvements that have been made for OpenDoors
5.00, work is already going ahead for version 5.10. The aim of version 5.10
won't be so much to add new features, as to improve on already existing
features. More efficiency improvements and greater flexibility is the goal of
OpenDoors 5.10.

What will come after OpenDoors 5.10? More than anything else, the future
directions of OpenDoors is guided by the programmers who work with it. Your
suggestions, ideas and even bug reports will determine what enhancements will
continue to be made to OpenDoors. Please don't hesitate to pass along any
changes that you would like to see in future versions of OpenDoors! I am also
interested to find out how much interest there would be in the following:

-   An OS/2-specific version of OpenDoors
-   A Windows-specific version of OpenDoors
-   Graphics-mode RIP support
-   A programmer-configurable door installation/configuration utility
    that would work in conjunction with the OpenDoors configuration file
    system.
-   A multi-node file system that would facilitate easy implementation
    of multi-node doors with the ability to send messages between nodes
    and control concurrent access to configuration and user files.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors 5.0 Released! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßß

By: Brian Pirie

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. For a summary of changes made for previous versions of
OpenDoors, refer to the OpenDoors History file that is available from my
system.

     - 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.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Bits and Bytes and Data Types ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ InterBBS Capabilities are Here! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

*** Editor's Note: The following is the press release for Brian's
InterBBS add-on library for OpenDoors.  It can be obtained by FREQ'ing
IBBS from either his system or mine.  Enjoy!

BBS "door" programs have always allowed operators of online computer
services, such as electronic bulletin board systems, to easily expand the
services provided by their systems. Doors have greatly increased the
flexibility and usability of BBS systems. A recent trend in door development
has been to allow doors running on one BBS system to be linked to doors
running on other systems, often through existing mail networks. While these
networks have traditionally provided private and conference (echo) mail
services and file sharing capabilities, they can also be useful in providing
links between special applications that wish to share information with one
another.

By taking advantage of existing mail network technology, BBS door developers
have been able to add a new dimension to the software they create. Among the
new ideas that have proven successful have been distributed BBS listing
services, distributed file listing services and games that share top-score
lists or even allow players to compete with people playing the game hundreds
or thousands of miles away. The possibilities are really limited only by the
imagination of the door software developer.

This package is designed to assist in writing Inter-BBS door programs that
can communicate across FTSC-compatible mail networks, such as FidoNet. Using
this package, you can:

       - Send information messages through any FTSC-compatible mailer
         that supports *.MSG format netmail, including FrontDoor,
         InterMail, BinkleyTerm, D'Bridge, and others.

       - Send messages containing either textual or binary data. This
         information is stored in the message body, to allow the message
         to be sent either directly (CrashMail) or by routed netmail.

       - Easily send information to just one other system, or all
         systems running the door. This allows you to implement both
         centralized and de-centralized information distribution
         schemes.

This package includes the source code for an example skiing game door that
maintains a high score list across multiple BBSes. This game requires the
OpenDoors door programming toolkit to be compiled. However, the Inter-BBS
Toolkit itself can also be use in doors that are not written with OpenDoors.

The Inter-BBS Toolkit is available free of charge, and the package includes
the complete C source code. This source code has been written for Borland C
and C++ compilers, but may easily be modified for use with other C compilers.
With the source code, you are able to customize or expand the capabilities of
the Inter-BBS Toolkit as you wish.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Tech Corner ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßß

-----------------------------------------------------------------------------
                Inside OD 5.0's Internal Async Routines
                     By: Brian Pirie/Scott Burkett
-----------------------------------------------------------------------------

 > Just a quick thought, but it would be nice if we could have
 > access to the low level communication functions (both fossil and
 > internal).  The standard od...() functions work great for doors,
 > but for critical timing matters such as protocols, etc, it
 > doesn't fly.  I am using my own fossil system for the timing
 > essential portions of BFE, for example.

I will consider adding these functions to the documented OpenDoors interface. In
the meantime, they are as follows:

int _com_carrier(void);           /* TRUE if DCD is high */
void _com_clear_inbound(void);    /* Clears outbound buffer */
void _com_clear_outbound(void);   /* Clears inbound buffer */
void _com_close(void);            /* Closes serial port */
void _com_dtr(char high);         /* TRUE raises DTR, FALSE lowers DTR */
char _com_getchar(void);          /* Returns next char from modem */
void _com_ini(void);              /* Opens serial port */
char _com_inbound(void);          /* FALSE if inbound buffer is empty */
char _com_outbound(void);         /* FALSE if outbound buffer is empty */
void _com_sendchar(char ch);      /* Sends character to modem */
                                  /* Sends multiple chars to modem */
void _com_send_buf(char *buffer,int size);

These functions assume that the door is not operating in local mode. Do not
call com_getchar() unless the _com_inbound() returns TRUE.

-----------------------------------------------------------------------------
                    Adding Local Mode Functionality
                            By: Brian Pirie
-----------------------------------------------------------------------------

OpenDoors 5.00 now permits you to easily force your door to operate in local
mode by setting the od_force_local variable. Normally OpenDoors will use a
default user name, but you can also use this feature to easily provide a
local login prompt for your door. The following example shows how you might
do this:

(This code might look long, but keep in mind that most of it is comments!)

#include "opendoor.h"

int main(int argc, char *argv[])
   {
   int counter;
   char valid_login = TRUE;

   /* Check for /LOCAL command-line parameter */
   for(counter = 1; counter < argc; ++counter)
      {
      strupr(argv[counter]); /* Do this with care! */
      if(strcmp(argv[counter], "/LOCAL")==0)
         {
         /* We are operating in local mode */
         od_control.od_force_local = TRUE;

         /* Let user login */
         do {
            /* Prompt for user name */
            printf("User Name : ");

            /* Get name from user. Note that it would be better  */
            /* to use a console input routine that limits the    */
            /* number of characters that can be inputted by the  */
            /* user, to prevent od_user_name from being overrun. */
            /* I use gets() here for simplicity.                 */
            gets(od_control.od_user_name);

            /* At this point, if you have a user file for your door */
            /* you might want to check whether the user's name is   */
            /* valid. If it is not valid, you can set valid_login   */
            /* to false, to cause door to prompt for a new name.    */
            /* (Keep in mind that you should provide some way for a */
            /* new user to log in locally!)                         */
         } while(!valid_login);

         /* Perform main door operations */
         doormain();

         /* Exit program */
         return(0);
         }
      }

   /* If we get to this point, then there is no /LOCAL parameter. So, */
   /* we should operate normally */

   /* Perform main door operations */
   doormain();

   /* Exit program */
   return(0);
   }


void doormain(void)
   {
   /* Initialize OpenDoors */
   od_init();

   /* Door's main processing, common to remote and local modes, */
   /* here */
   }

-----------------------------------------------------------------------------
               Finding physical cursor position in OD 5.0
-----------------------------------------------------------------------------
                             (Brian Pirie)

 > Quick question:  Is there a method to determine the current
 > location of the cursor, without keeping track of it manually?  I
 > vaguely recall a thread about this subject, but can't find it
 > for the life of me...

In 5.00, the following two variables:

   extern unsigned char phys_curx;
   extern unsigned char phys_cury;

store the current location of the cursor on the local screen.

-----------------------------------------------------------------------------
                 Using UP/DOWN Arrow Keys in OpenDoors 5.0
-----------------------------------------------------------------------------
                   (Taken from the OPENDOORS echo)

 > Any news on when the next beta will be out, and also do you plan
 > on allowing support for use of the UP/DOWN arrow keys?

This has been fixed in the 5.00/beta-8 package. The following program
demonstrates a door which displays a simple message when the up or down arrow
key is pressed. Since OpenDoors defaults to using the up and down arrow keys
for adjusting the user's time limit, such a program has to use different keys
for this purpose. This program reassigns the [Page Up] and [Page Down] keys
to be used for adjusting the user's remaining time.

/* Simple program to demonstrate using arrow keys within an OpenDoors door */
/* program. Since the arrow keys are normally used locally to adjust the   */
/* user's time up or down, you must choose different keys to adjust the    */
/* time limit. This program simply loops, displaying the word "up" if the  */
/* up arrow is pressed, "down" if the down arrow is pressed, and exiting   */
/* if the enter key is pressed.                                            */

#include "opendoor.h"

main()
   {
   int choice;
   char pressed;
   long timer;

   /* Notice call to od_init() here! */
   od_init();

   /* Reassign PageUp and PageDown to increase/decrease time */
   /* Remember to do this after od_init() or your first call to any OpenDoors */
   /* function. */
   od_control.key_lesstime = 0x5100;   /* Scan code for Page Down */
   od_control.key_moretime = 0x4900;   /* Scan code for Page Up */

   od_disp_str("Press up and down arrows keys. Press Enter when done\r\n");

   for(;;)
      {
      pressed = od_get_key(TRUE);

      /* Check for ANSI arrow key sequences */
      if(pressed==27)
         {
         timer=(*(long far *)0x46cL)+2L;
         while(timer>*(long far *)0x46cL && (pressed=od_get_key(FALSE))==0)
            {
            od_kernel();
            }

         if(pressed != '[')
            {
            continue;
            }
         else
            {
            timer=(*(long far *)0x46cL)+9L;
            while(timer>*(long far *)0x46cL && (pressed=od_get_key(FALSE))==0)
               {
               od_kernel();
               }
            if(pressed == 0) continue;
            switch(pressed)
               {
               case 'A':
                  goto up_arrow;

               case 'B':
                  goto down_arrow;
               }
            }
         }

      /* Check for doorway / local arrow key sequences */
      else if(pressed==0)
         {
         /* Get the next key from the keyboard */
         timer=(*(long far *)0x46cL)+9L;
         while(timer>*(long far *)0x46cL && (pressed=od_get_key(FALSE))==0)
            {
            od_kernel();
            }
         if(pressed == 0) continue;

         /* Respond appropriately */
         switch(pressed)
            {
            case 0x48:
up_arrow:
               od_disp_str("Up Arrow.\r\n");
               break;

            case 0x50:
down_arrow:
               od_disp_str("Down Arrow.\r\n");
               break;
            }
         }
      /* exit program if user presses CR or LF */
      else if (pressed == '\n' || pressed == '\r')
         {
         break;
         }
      }


   /* Note that od_exit() is now optional in OpenDoors 5.00/beta-8        */
   /* If you allow the program to return from the main() function without */
   /* first calling od_exit(), the od_exit() code will automatically be   */
   /* performed. Note, however, that this does not allow OpenDoors to     */
   /* determine the errorlevel being used, in order to report the         */
   /* errorlevel in the logfile.                                          */
   return(0);
   }


ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Drawing Bar Graphs with OD! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
By: Brian Pirie

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);

Below the listing for the DrawHorizontalBar() function 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);
   }
}

----- ex_graph.c example program follows ------------------------------

/* 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);
   }
}

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Obtaining Names/Passwords in ASCII Mode ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

By: Brett Barnes, THE TOWER BBS 071 636 3957, England

#include <stdio.h>
#include <string.h>
#include "opendoor.h"

void Get_Password(char *string, int length);
void Get_Full_Name(char *string, int length);

void Get_Password(char *string, int length)
{
int key;
int count = 0;

    od_clear_keybuffer();
    while((key = od_get_key(TRUE)) != 13)
    {
        if(key == 0)
            od_get_key(TRUE);

        if(key >= 32 && key <= 127 && count < length)
        {
            string[count++] = key;
            od_putch('*');
        }
        if(key == '\b' && count > 0)
        {
            od_putch('\b');
            od_putch(' ');
            od_putch('\b');
            count--;
            string[count] = '\0';
        }
    }
    strupr(string);/*make string uppercase*/
}

void Get_Full_Name(char *string, int length)
{
int key;
int count = 0;

    od_clear_keybuffer();
    while((key = od_get_key(TRUE)) != 13)/* Drops out when Enter key*/
    {
        if(key == 0)
            od_get_key(TRUE);/*cancels prob with DEL key*/
        /*If key = valid ascii code */
        if(key >= 32 && key <= 127 && count < length)
        {
       /*if uppercase */    if(key >= 65 && key <= 90)
                key = key+32;/*convert to lowercase*/
            if(count == 0 && key >= 97 && key <= 122)
                key = key-32;/*convert to uppercase*/
            else
                if(string[count-1] == ' ' && key >= 97 && key <= 122)
                key = key-32;/*convert to uppercase*/
        /*Stop spaces being put in first*/
            if(key != 32)
            {
                string[count++] = key;
                od_putch(key);
            }
            else if(count > 0)
            {
                string[count++] = key;
                od_putch(key);
            }
        }
        if(key == '\b' && count > 0)/*If Backspace*/
        {
            od_putch('\b');
            od_putch(' ');
            od_putch('\b');
            count--;
            string[count] = '\0';
        }
    }
}

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ File Transfers Under OpenDoors ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
By: Brian Pirie, taken from the OPENDOORS echomail conference:

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 program 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".

The first part of the tip2.c program discussed in the previous message
follows:

/* 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. */
   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;
}

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Comparing File Stamps ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßß

By: Brian Pirie, taken from the OPENDOORS echomail conference:

 > I am trying to find a way to basically look at a files date and
 > then determine if it is older than say 10 days old?
 > I looked thru all of my manuals, and sample programs and could
 > find no examples, so I thought I would turn to the experts here.
 > If anyone can give me help I would greatly appreciate it!

For others who were wondering about this problem, the program below will
display the names of all files in the current directory that are more than
10 days old.

If you ran the program at 10:35:20 on Friday, August 5th, a file dated
10:35:20 on Tuesday, July 26th (or later) would not be displayed, but a file
dated 10:35:18 on Tuesday, July 26th (or earlier) would be displayed.
(DOS's file time is only accurate to the nearest 2 seconds.)

**** Editor's Note: To further explain Brian's information, here is a
brief explanation of why DOS file time stamps are only accurate to the
nearest two seconds.  The file's time field is set when you create the file,
and updated thereafter whenever you close the file, but *only* if
information has been written to the file.  This field is not updated if
the file is merely read, copied, or renamed.  When the time field gets
updated, though, the new time is retrieved from the system clock.  The
following is a breakdown of the meaning of each bit in the time field:

        FEDCAB98 76543210

        xxxxx              = Hours
             xxx xxx       = Minutes
                    xxxxx  = Two second increments

The hour is contained in five bits (on a 24 hour clock), and the minutes
in six bits.  Because this only leaves 5 bits in which to store the
seconds, DOS divides the actual value by two (2).  A little known fact
about the file time field, is that if all bits in both bytes are set to
zero (0), the DIR command will not show any time.  Ok, back to Brian's
snippet (sorry!).

Included in this file is a function named DIRToCTime(), which converts the
DOS file time format to the C time_t format.
                       
/* This example program will display the names of all files that are */
/* more than ten days old.                                           */

#include <dir.h>
#include <dos.h>
#include <time.h>
#include <stdlib.h>

time_t DIRToCTime(unsigned uDate, unsigned uTime);

#define SECONDS_PER_DAY (60 * 60 * 24)

main()
{
   struct ffblk DirEntry;
   time_t CurrentTime = time(NULL);
   time_t FileTime;
   double dElapsedSeconds;
   double dElapsedDays;

   if(!findfirst("*.*", &DirEntry, FA_ARCH))
   {
      do
      {
         /* This loop repeats for every found file ... */

         /* Convert the file's time as returned by findfirst() to a time_t. */
         FileTime = DIRToCTime(DirEntry.ff_fdate, DirEntry.ff_ftime);

         /* Determine the number of seconds that have elapsed between the */
         /* two times.                                                    */
         dElapsedSeconds = difftime(CurrentTime, FileTime);

         /* Determine the number of days that have elapsed. */
         dElapsedDays = dElapsedSeconds / SECONDS_PER_DAY;

         /* If more than ten 24-hour periods have elapsed, display filename. */
         if(dElapsedDays > 10)
         {
            printf("%s is more than ten days old.\n", DirEntry.ff_name);
         }
      } while(!findnext(&DirEntry));
   }

   return(0);
}


time_t DIRToCTime(unsigned uDate, unsigned uTime)
{
   struct tm TimeStruct;

   TimeStruct.tm_sec = (uTime & 0x001f) * 2;
   TimeStruct.tm_min = (uTime & 0x07e0) >> 5;
   TimeStruct.tm_hour = (uTime & 0xf800) >> 11;
   TimeStruct.tm_mday = uDate & 0x001f;
   TimeStruct.tm_mon = ((uDate & 0x01e0) >> 5) - 1;
   TimeStruct.tm_year = 80 + ((uDate & 0xfe00) >> 9);

   return(mktime(&TimeStruct));
}

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Generating Fidonet *.MSG Messages ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß
By: Mark Williamson, taken from the OPENDOORS echomail conference:

/* NETMAIL.C : This little jewel will write send a netmail message to
               the names and addresses listed in NAMES.LST. This file
               has the format of:

               First Lastname
               Zone Node Net Point  (point is optional)

               example:

               Mark Williamson
               1 202 750 <0>

               When the program loads, it will load the editor EDIT.EXE.
               Just change the line system("EDIT.EXE") to load your editor.
               This program expects to find a file NET.MSG.

               This program is public domain <G>.
               The attribute used in this program is CRASH KILL SENT.

               Look in the Fidonet Technical Specifications for the full
               structures and meaning of each field.
*/

#include <dos.h>
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <fcntl.h>
#include <alloc.h>
#include <bp.h>
#include <string.h>

static char msghdr[50],year[5],msgfile[80],firstname[30];
char *msgtext,select;
void writefido(void);

char  *strrep(char *str, char *oldstr, char *newstr)
{
          int OldLen, NewLen;
          char *p, *q;

          if(NULL == (p = strstr(str, oldstr)))
                return p;
          OldLen = strlen(oldstr);
          NewLen = strlen(newstr);
          memmove(q = p+NewLen, p+OldLen, strlen(p+OldLen)+1);
          memcpy(p, newstr, NewLen);
          return q;
}

/* *.MSG format: */
struct {
         char from[36],
                  to[36],
                  subject[72],
                  datetime[20];
             int  timesread,
                  destnode,
                  orignode,
                  cost,
                  orignet,
                  destnet,
                  destzone,
                  origzone,
                  destpoint,
                  origpoint,
                  replyto,
                  attribute,
                  nextreply;
        } Msg;


char buffer[89];
void main(void)
{

   FILE *fp,*fp2;
   struct tm *time_now;
   time_t secs_now;
   char zone[10],node[10],net[10],point[10];

   /* load your editor to create/change the message. */

   system("EDIT C:\\NET.MSG");
   if(access("C:\\NET.MSG",0)!=0) return;

   /* open the name list */

   fp=fopen("C:\\NAMES.LST","rt");
   if(fp==NULL) return;
   time(&secs_now);
   Msg.timesread=0;
   Msg.cost=0;


   strcpy(Msg.from,"Mark Williamson");
   strcpy(Msg.subject,"Labtest Beta Message"); /* remember, the subject */
                                               /* for a file attach message */
                                               /* is the full path and file */
                                               /* name of the file(s) to send
*/
                                               /* be sure to set the correct
*/
                                               /* message attribute to send */
                                               /* or request files. */


   Msg.attribute=0x0183;

   /* change this to your fido address */
   Msg.orignode=750;
   Msg.orignet=202;
   Msg.origzone=1;
   Msg.origpoint=0;
   Msg.replyto=0;
   Msg.nextreply=0;
   time_now=localtime(&secs_now);
   strftime(Msg.datetime,20,"%a %d %b %y %X",time_now);
   while(!feof(fp))
   {
           Msg.destnode=Msg.destpoint=Msg.destnet=0;
           Msg.destzone=1;

           if(fgets(buffer,88,fp)==NULL) break;
           buffer[strlen(buffer)-1]=0;
           strcpy(Msg.to,buffer);
           if(fgets(buffer,88,fp)==NULL) break;
           buffer[strlen(buffer)-1]=0;
           zone[0]=point[0]=node[0]=net[0]=0;
           sscanf(buffer,"%s %s %s %s",zone,net,node,point);
           Msg.destnode=atoi(node);
           Msg.destpoint=atoi(point);
           Msg.destzone=atoi(zone);
           Msg.destnet=atoi(net);

           ultoa(bp(Msg.to,199309),registerkey,10);
           fp2=fopen("C:\\NET.MSG","rb");
           msgtext=(char *)malloc(filelength(fp)+1000);
           memset(msgtext,0,filelength(fp)+1000);
           fread(msgtext,filelength(fp),1,fp2);
           fclose(fp2);
           sscanf(Msg.to,"%s",firstname);


           /* here are some macros to make auto replacement easier. */
           /* this is great for form letters, kinda personnalizes the */
           /* message.*/

           strrep(msgtext,"@FIRST@",firstname);
           printf("\nWriting message to: %s, %s:%s/%s%s%s",
                     Msg.to,
                     zone,net,
                     node,Msg.
                     destpoint!=0?".":"",
                     Msg.destpoint!=0?point:"");
           writefido();
           free(msgtext);
   }
   fclose(fp);
}

void writefido(void)
{
     int count=250;  /* this controls the starting point.  */
                     /* this function will count down until */
                     /* finds a *.MSG.  It will then increment */
                     /* by one and write the message.  There */
                     /* is probably a better way, but you know. */
                     /* set this number higher if you have lots */
                     /* of netmail messages. */

         char firstname[20];
         FILE *fp;
         tzset();

          /* Fido *.msgs use a MSGID line which is preceded by */
          /* a CONTROL-A.  Then your fido address, a carriage  */
         /* return, CONTROL-A and the name of the program that */
         /* created the message and version number, then another */
         /* carriage return. */
         strcpy(msghdr,"\x01MSGID: 1:202/750\r\x01PID: MM 1.0\r");

         /* this begins our loop to find the last written */
         /* netmail message in your netmail directory */
         sprintf(msgfile,"C:\\RA\\MAIL\\%d.MSG",count);
         while(access(msgfile,0))
            sprintf(msgfile,"C:\\RA\\MAIL\\%d.MSG",--count);

         /* got this far, we have a number! */
         /* increment it by one to get the next available slot */
         sprintf(msgfile,"C:\\RA\\MAIL\\%d.MSG",++count);
         fp=fopen(msgfile,"wb");
         if(fp==NULL) puts("\nError opening file...");
         else
         {
           fwrite(&Msg,sizeof(Msg),1,fp);
           fwrite(&msghdr,strlen(msghdr),1,fp);
           fwrite(msgtext,strlen(msgtext),1,fp);
           fwrite("\0x00",1,1,fp);
           fclose(fp);
         }
}

That's it!  This is a simple program I wrote to send form letters to numerous
people who needed to have the same information.  This could be done in
Frontdoor with the ALT-L forward command, but then it was much more fun
creating something and knowing watching it work!

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ Code Snippets! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßß

Sample code to validate credit card numbers
Posted in the OPENDOORS echo by Robert La Ferte,
Original by Andrue Carr

/*
**  Testcard.c 1.0 Copyright (C) 1993 by DruId Software.
*/

#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int formula(char card[23],int len);

// actual formula for creditcard!
// this can be used to build the last CRC digit by changing the len by 1
// it is mainly used to make sure the card is a correct card by verifying
// the last CRC digit against the rest of the card.
// the formula will run all the numbers in the card but the last one
// which is the CRC digit.  if the number the formula kicks out is the
// same as the last digit of the card then it is a valid credit card
// if not then its not correct. this is what a ZON machine uses to
// determine if it is a good number or not. If you need more help
// let me know and i can explain this better:
// Andrue Carr: fido: 1:331/201, SL_net: 250:502/1294, ISG 91:5/201
//              Acmenet: 400:508/201
// box 473, West Tisbury, mass 02575 (Over Board BBS (508)693-5344)

int formula(char card[23], int len)
{
    int     x,
            xcard = 0,
            y;

    for(x = 0; x <= len; x++)
    {
        if(len % 2)
        {
            if(x % 2)
                y = (card[x] - 48) * 2;
            else
                y = (card[x] - 48);
        }
        else
        {
            if(x % 2)
                y = (card[x] - 48);
            else
                y = (card[x] - 48) * 2;
        }
       if(y >= 10)
           y = (y - 10) + 1;

       xcard += y;
    }

    x = (10 - (xcard % 10));

    if(x == 10)
        x = 0;

    return(x);              // send back the computed check digit!
}

void main(int argc, char *argv[])
{
    int i = 0,
        size = 0;

    if(argc < 2)
    {
            // testcard.exe [cardnumber]  if no card# then error
        cputs("\007No credit card entered");
        exit(1);
    }

    size = strlen(argv[1]);

    i = formula(argv[1], (size - 2));

    // check for all but crc digit
    // if the number returned from formula() isnt the last digit
    // of the actual card number then it isnt valid!

    if(i != (argv[1][size - 1] - 48))
        cputs("\007     -> Invalid Card!");
    else
        cputs("     -> Valid Card");

    exit(0);
}

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Release Notice: BCHECKERS 1.2! ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

BCHECKERS -- Version 1.2 -- is released!
========================================

** NOW SUPPORTS RA 2.00+! **

As a sysop of a FidoNet BBS, I was disappointed in the lack of a good,
non-interactive checkers door. Sure, there were some that allowed inter-
node play and the like, but these were expensive and few offered any
decent ANSI graphics and the simple ability to have callers make moves
on alternate logons. I also wanted to try my hand at programming in C,
having learned a number of other programming languages. BCheckers is the
result of this effort; and at only $10 is a bargain in shareware.

BCheckers offers the following sysop features (and more I've probably
overlooked in these docs):

-  As you would expect, BCheckers monitors carrier detect functions, to
   automatically recover when a user drops carrier.

-  Includes a fully-adjustable inactivity timeout monitor. A warning is
   sent 5 seconds before the caller is ejected.

-  Share-aware file i/o for use in multi-node BBS systems. You must have
   DOS's SHARE.EXE loaded for multi-node use.

-  Supports most popular BBS door information files, such as DORINFO1.DEF,
   EXITINFO.BBS, CHAIN.TXT, DOOR.SYS, etc.

-  Displays and updates a QuickBBS-style status line, with information
   available to the sysop such as user name, location, baud rate, time left,
   function keys, ANSI and AVATAR settings, and so on.

-  Keeps track of a user "wants-chat" indicator, just like the one in
   RemoteAccess, QuickBBS and other BBS systems. Allows for sysop page from
   the door, and integrated chat mode.

-  Provides the sysop with all the standard function keys for adjusting user
   time, hanging up on or even locking out the user -- and sysop shell to DOS.

-  Full support for locked baud-rates of up to 38,400 baud, using the FOSSIL
   driver for maximum compatibility with any system. If a FOSSIL is not
   available, BCheckers will use its own communications routines. Auto-detect
   of local operation.

-  BCheckers is also DesqView and Windows aware.

New features:

-  Minor bug fix to the Hall of Fame generation and key recognition code.

-  Minor cosmetic improvements.

-  Altered prompts slightly to alleviate problems with some modems when
   using XON/XOFF handshaking.

BCHECKERS is coming soon to a DOORNET or DDSDOORS distribution site in your
area, or you can freq the latest version directly from the author at FidoNet
node 1:231/710 using the "magic name" of BCHECK. Alternatively, the door can
be downloaded from the H.O.M.E. BBS at (317)539-6579. The next release will
have a "play against the computer" mode! Upgrades will be free, but a new
registration will increase by $5. Register now, while it's still cheap!

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Release Notice: BFE v4.00.2r ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

BFE v4.00.2r, the flexible telecommunications front end system from
Southeastern DataLINK, is now available!

BFE is a BBS front-end system that was designed to provide sysops with a
fast, efficient method of "connecting" things at the front end of their
site.  

BFE features include:

 * Custom multi-level menus, with RIP graphics support
 * Item and/or menu level password protection with daily scheduling
 * Hotkey items or SlashCommand(tm) mode
 * Attractive internal menuing scheme to ease your work load
 * Support for custom user menus (for aspiring sysops and artists)
 * Support for popup lightbar menus
 * Design and employ interactive full-screen data entry forms
 * Full Multinode/Multiuser Compatibility
 * Internal DOS-to-UNIX gateway!  Give your users the power of UNIX.
 * The gateway services can also be used to gate calls to a packet radio
 * Client/server approach to the UNIX gateway.  Provide interactive access
 * Provide *REAL* UUCP sessions from your UNIX server to your DOS callers
 * Intuitive menu-driven setup and customization facility (BFE/Setup)
 * Feature packed "C" like Script system
 * Run automated scripts, even offline in a maintenance role.
 * WFC (Wait-For-Caller) module to handle non-mailer sites (reg. only)
 * DESQview *and* MS-Windows aware
 * Configurable for security concerns
 * 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 support for ANSI/ASCII/AVATAR/RIP users
 * Configurable automatic ANSI and RIP detection schemes
 * File transfer system with support for external protocols
 * Run remote jobs, such as batch files, programs, other doors, etc.
 * Internal remote shells to the operating system
 * Built in chat/paging system with hourly/daily time restrictions
 * Split screen chat mode, along with line chat mode for TTY users
 * *Total* configurability

What's changed since the last release?

        o New mailing address and contact information for Southeastern
          DataLINK:
                      Address: 13500 Feather Sound Circle West
                               Suite 1313
                               Clearwater, FL 34622
                         Data: (813) 572-6817
                        Voice: (813) 573-5078
                     Internet: [email protected]  - Scott Burkett
                               [email protected]   - Sales Q/A
                               [email protected] - Technical support
                      Fidonet: 1:3603/500

        o BFE now supports "Before" and "After" scripts for each menu option
          in your control files.  The BEFORE scripts are called
          immedicately after the user presses the key corresponding to
          the menu option, but before the menu option's actions are
          carried out.  The AFTER scripts are executed upon completion
          of the menu item selected, and before returning to the BFE
          menu system.  These scripts should be located in the SCRIPTS
          directory (configured in BFE/Setup), and should be named as
          per the following naming convention:

                BEFORE scripts:  <CTLFILENAME>.B<HOTKEY>
                 AFTER scripts:  <CTLFILENAME>.A<HOTKEY>

          For example, if in your MAIN control file, you have a menu
          option which uses the "1" key as the hotkey, the BEFORE and
          AFTER scripts would be named "MAIN.B1" and "MAIN.A1".

        o NEW SCRIPT COMMANDS:

                CompareStr() - Compares a string with the contents of the
                               internal script buffer.

        o NEW SAMPLE SCRIPTS:

                GETPASS.SCR - Demonstrates the use of the CompareStr()
                              function call.

        o BFE's menu handler now sports a rudimentary line noise "filter".

        o All of the text used during user system logins is now
          configurable in the language file.

        * BFE's internal comm routines now supports all IRQ lines from
          1 to 15.  In addition, full support for 16550A FIFO buffers is
          in place as well.

        * The RA "personality" now accurately mimics the latest version
          of the RA status line.

        * Quite a bit of code cleanup in this release.

        * Several additional checks are now in place for the BFE setup
          sanity check, which verifies the BFE path setup.

        * When opening a .CTL file under BFE/Setup, it now defaults to open
          an "existing" .CTL file, instead of creating a new one.  (Thanks
          to George Bynum for this suggestion).

        * Quite a few changes and additions in the BFE user manual (including
          WFC, BFE/Gateway, and BFE/Setup).

        * The "p" identifier has been removed from the end of the normal
          archive naming convention, as it was confusing OS/2 users.  It
          has been replaced by an "r", which means "public (r)elease".

        * The fossil buffers are now flushed before every gateway session
          is initiated.  This was inserted in order to make BFE's internal
          serial gateway more "friendly" towards packet radio systems.
          (Thanks to Mark Stanchin).

        * A popup "dialog" box will appear whenever BFE is dropping
          carrier, informing you of such.

        * The WFC module for registered users will now place both the
          COM port number *and* the fossil port number into the
          DOBBSx.BAT files.

        ! The displayfile() script function should no longer give erroneous
          password prompts if a password was used to get into the script
          to begin with. (Thanks to Mark Stanchin).

        o A new dot command has been added to BFE/Formgen.  The ".type"
          keyword will direct Formgen to output information in either
          "delimited" format (default), or "linear".  Thanks to Dana
          Meli-Wischman.

        ! In certain situations, BFE would force the caller to hit a key
          twice before the keystroke was registered.  Squashed.

        ! BFE/Gateway sessions should now properly monitor the caller's
          carrier signal.

        ! ANSI detection would fail under certain situations.  Squashed.

        o The BFE registration system has been revamped completely.  If you
          are a previously registered user of BFE, please contact us for your
          new key file.

        o Marketing strategy has been updated, and now includes three very
          distinct levels of BFE registration.

        o New Module:   BFE/Node Monitor for DESQview systems.  BFEMON is a
          compact monitoring system designed for sites running BFE in a
          multinode environment.  This module is made available free of charge
          to registered users of BFE. (+)

        o New Module: BFE/WFC - The Wait For Caller module is designed to
          provide a flexible method of handling inbound calls on non-mailer
          nodes.  It's features include:

                - DESQview/Win31/OS2 Aware
                - Intuitive menu-driven setup and windowed environment
                - Internal screen blanker
                - Full support for 50 line VGA mode
                - Designed with multinode systems in mind
                - Custom connect strings for FAX, UUCP, etc.
                - FOSSIL driven, for maximum compatibility
                - Full internal event system

          The WFC module is made available free of charge to registered users
          of BFE. (+)

        o New subsystem: BFE/FormGen - a powerful full screen data entry form
          designer is now included as part of the base BFE package.

        o BFE/Setup now includes an internal user file editor. :-)

        o BFE now supports non-fossil sites by providing an internal serial
          communications system.  This adds three new command line switches:

                -i = No fossil!  Use internal routines
                -u = COMx Base Address (i.e. -u03F8)
                -v = COMx IRQ Line (i.e. -v4)

        o The time adjustment sysop keys (formerly cursor up/down) have been
          remapped to pageup and pagedown.

        o Multiline descriptions with embedded colors are now available.  In
          BFE/Setup, the description field is now two lines long.  Also, BFE
          now supports embedded color tokens in the description field, thus
          allowing you to highlight certain portions of the description of
          each menu item.  ** NOTE:  BFE will not automatically align the
          two lines of text if the first one wraps around!  This will be
          taken care of in a future release, but for now, you will have to
          space them out accordingly.

        o When using BFE's internal files system for providing downloads,
          the file "FILES.BBS" is no longer assumed. :-)  Now, you must
          provide the full path *AND* filename of the file to be used as the
          list file.  This allows you to keep your list files in one shared
          directory.  In addition, the full path is no longer needed in the
          list files.  If the path is not given, BFE will look for each file
          in the directory the list file resides in.

        o New Language File Keywords (Thanks to Michael Stumpp)

                PASSWORD   - "Enter password" prompt - Default is "Password:"
                Y_CONTINUE - Key used to continue in "more" prompting
                N_CONTINUE - Key used to stop in "more" prompting
                S_CONTINUE - Key used to go nonstop in "more" prompting

        o BFE's internal user system now has an additional mode of operation.
          This "Exclusive" mode is identical to the full user system, but
          will not allow new users at all.  This may come in handy if you
          wish to allow only "registered" users on certain nodes, or if you
          run a "member's only" BBS.  (Thanks to Dana Meli-Wischman).

        o NEW SCRIPT COMMANDS:

                FormGen() - Processes a BFE/FormGen Entry Form

                SaveScreen() - Saves contents of current screen

                RestoreScreen() - Restores contents of saved screens

                PopupMenu() - Creates a configurable popup menu

                RemoveFile() - Removes the passed filename (deletes it)

                MakeCustomSem() - Creates a CUSTOM.nnn semaphore in the
                                  IPC directory.

                RemCustomSem() - Removes CUSTOM.nnn semaphore from IPC dir.
                
                NoConsoleLogging() - Temporarily disables console logging
                                     while in a BFE gateway session. (+)

                ConsoleLogging() - Re-enables console logging in BFE gateway
                                   sessions. (+)

                DisableServerStr() - Temporarily disables BFE's remote server
                                     strings. (+)

                EnableServerStr() - Re-enables remote server strings. (+)

                SetAccess() - Adjusts the caller's security level

                UpdateUserRecord() - Update's user's record in user file

        o RIP support updated - when BFE is displaying a RIP file to user,
          the appropriate ANSI or ASCII version will be displayed locally
          on the sysop's console.  Note that this doesn't include the
          default BFE internal menus, although it will in the future.

        o A new utility called COLORUPD.EXE has been provided.  This program
          will read the default color configuration stored in the GLOBALS.CFG
          file, and will update the color maps of all .CTL files in the
          current directory.  This program is distributed in the \UTILS
          subdirectory in the distribution archive.  The source (COLORUDP.C)
          is located in the \DEVKIT subdirectory.  Thanks to Keith Ross for
          this suggestion.

        o If using the BFE User System, BFE will now export the user's name
          and password to two environment variables in the DOS master
          environment upon exiting on an errorlevel (USERNAME and PASSWORD
          are the new environment variables) This should make automatic
          logins through BFE a bit easier, as you can now pass the name and
          password on the command line to your BBS packages.

        o Now, a special "log text" field is attached to each menu item.
          This field serves two purposes:

                - It is used in the log file for the task to describe each
                  event.

                - It is used in the menu item selector screen in BFE/Setup,
                  in place of the description field.

          If no log text is supplied, the normal description will be used.

        o The macro system has been completely revamped, and the following
          new macros are available:

                %U  = User's name
                %W  = User's password
                %H  = User's handle

        o BFE will now periodically perform an Integrity check, to ensure
          that pertinent system files have not been altered by viruses or
          intruders.

        o Some sample .CTL files are now included under (\SAMPLES\CTL).
          These will be updated further as more features are added to the
          product.

        o New networking semaphore files implemented (nnn = node number):

                 SHELL.nnn  - User/sysop in DOS shell
                  XFER.nnn  - User transferring a file
                  CHAT.nnn  - User either paging or in a chat session
               FORMGEN.nnn  - User in a BFE/FormGen Entry Form
                CUSTOM.nnn  - Custom user-defined semaphores

        o New fields in BFE/Setup:

                Default .CTL file Path (for BFE control files)
                Default .FRM file Path (for BFE/Formgen files)
                Default .SCR file Path (for BFE/Script files)
                Default .ANS file Path (for ANS/ASC/AVT/RIP files)

        o New script hook:  This script will be executed automatically
          if it exists when a new user has logged into the system.

        * The graphics detection routines have been replaced, and should
          perform much smoother now.

        * Three new fields have been added to the user file.  They are
          handle, home phone, and work phone.

        * The documentation has been completely reorganized.

        * BFE will no longer automatically put a divider line in between
          normal and global commands when using the internal menus.  If you
          want a divider line, you can just add it to the top of your
          global menu. :-)

        * When displaying standard ASCII files, BFE will now default to light
          gray on black.  In previous releases, the color of the text would
          appear in the color of the user input.
                                                            
        * When running external processes (other doors, in particular), BFE
          will now de-initialize the fossil driver, and re-initialize it upon
          re-entry.  This was due to the fact that some doors left the fossil
          driver in quite a shabby state after exiting, so bad, in fact, that
          BFE would function normally, but not be seen on the remote end!

        * Gateway sessions will now flow much smoother.  So smooth, in fact,
          that we actually ran a SCO/UNIX UUCP session through it. :-) (+)

        * BFE now tries to avoid the use of high bit ascii characters when
          running with ASCII callers.  If any of you have seen ANSI emulation
          under UNIX terminal packages, you know why... :-)

        * Password protection now covers an entire file list when downloading
          from protected areas.  In previous releases, the user had to enter
          the password for each file.  Sounds stupid, doesn't it?  It was.

        * Rewrote the import message file routines when using external
          editors.  You should no longer lose characters under certain
          word wrapping conditions.

FREQ:  BFE from:  Southeastern DataLINK Zoom 28.8  1:3603/500 (813) 572-6817
       345K in size

 FTP:  ftp.csn.org:~/crlhq/bfe4002r.zip

Previously registered users of BFE should contact us through the normal
support channels (email, netmail, dialup) to request your new serialization
keys.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Release Notice: GIF View Preview Door v1.0 ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

Greetings All, from Lone Wolf Software!

****************************************************************
*                    GIF View Preview Door                     *
*         FileName: VUGIF10.ZIP   FileSize: 590k               *
****************************************************************

FEATURES............

o Tag up to 50 GIFs for download.
o Users can convert GIF files to JPG files for fast file transfers.
o Internal file base engine for super quick file handling.
o RIPterm users can view the JPG files while ON LINE!
o Converts large GIF files to small (often less than 10k) JPG files
  that transfer fast. RIPterm users can tag, convert and view GIFs
  while on line in under 30 seconds at 14,400 baud.
o Non RIPterm users (ANSI callers) can use many popular graphic
  file viewers like CShow or The Graphics Work Shop to view JPG
  preview files to see if they want to download the actual GIF.
o State of the art sysop management tools, file base editor, and
  built in GIF graphic file viewer.
o Others may say "On Line GIF Viewing", but they require you to log
  off to view the graphic file, that's not on line viewing. This
  door actually lets RIPterm users view the JPG / GIF while still
  on line.
o Extensive use of RIP through out, both to the user and the sysop.
o Option to disable RIP on either local or remote end.

FREQ the file VUGIF10.ZIP from 1:3813/309 or call the board at
1-918-687-1612 at speeds up to 19,200.

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Release Notice: Operation: Office v0.5 ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

                        Operation: Office v0.5
                        ----------------------
                          An OmniWare Product
                          -------------------
                           by Mike Aleksiuk

Get your latest copy from...

Name:        C.R.I.S.I.S. HQ
Number:      686-0449
Node Number: 1:134/31
Magic Name:  OPOFF
File Name:   OPOFFV05.ZIP
Place:       Calgary, AB, Canada

        In this exciting new game, we have you set in the unexciting
role of an "office worker".  But last night you overheard your boss
talking to someone... and for no apparent reason, you decide to kill
him!  The challenge is about to begin...

        Supports all major dropfiles (DOOR.SYS, DORINFO?.DEF, etc).
Configure specific game settings.  Usable player editor for registered
users.  Unregistered users may only delete/look at the player information.

        Features
        --------

        - chat with other players in a "one-liner" fashion
        - use the phone
        - listen to the radio
        - many different enemies to fight, many different things to buy
        - work to make money

        Beta Gamma Wanna-Be
        -------------------

        Version 0.5 is the "Beta Gamma Wanna-Be" version of Operation:
Office.  In other words, it is a gamma/wide beta, for all to test.  It
is fully functioning, but still needs to be refined.

        A Few Future Features
        ---------------------

        - personal player phone numbers!
        - much more detailed fight method!
        - more enemies!

        Please send all comments/bug reports via FidoNet netmail to
1:134/21.10, or conventional mail at the address stated within the
SysOp documentation.  Unfortunately, I don't have the time/money to
return all of your messages... Sorry!

Mike Aleksiuk, Author of "O:O"

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ܳ OpenDoors Tech Journal Information ³
ÛÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

Editors: Scott Burkett
         Southeastern DataLINK BBS
         1:3603/[email protected]
         [email protected] (Internet EMail)
         [email protected] (Internet EMail)
         (813) 572-6817 28.8 Zoom!
         13500 Feather Sound Circle West
         Suite #1313
         Clearwater, FL 34622

         Brian Pirie
         BP ECOMM Systems
         1:243/[email protected]
         [email protected] (Internet EMail)
         75122,2303 (Compuserve)
         (613) 526-4466 14.4
         1416 - 2201 Riverside Drive
         Ottawa, Ontario
         Canada
         K1H 8K9

Published by and for programmers and users of the OpenDoors Door
Programming Toolkit.  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 ODTJ.

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 94 Issue Number 2 ><-
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ