
                     -= NetFoss - an Internet FOSSIL =-
                        for Windows 2003/XP/2000/NT4

                              Version 0.9.1
                              June 13, 2004
                         Written by Mike Ehlert
                    Copyright (c) 2001-2004 pcmicro.com
____________________________________________________________________________
 
 NetFoss is a FOSSIL revision level 5 driver for Telnet communications
 under Windows 2003, XP, 2000, and NT4. It includes support for the
 additional FOSSIL functions defined by Ray Gwinn in X00.

 A FOSSIL [Fido Opus Seadog Standard Interface Layer] is a driver which
 allows DOS based modem communication software (i.e.: BBS's and Door Games)
 to communicate through an interface that talks to the actual hardware.
 Originally FOSSIL drivers were used for serial communications, however
 NetFoss communicates with TCP/IP ports instead, and does not provide
 any serial port support.


 Requirements
 ------------

        * Windows 2003, XP, Windows 2000, or Windows NT4 (any version).
        * A Win32 Telnet Server (several are available for free).
        * DOS applications designed to communicate with a FOSSIL
          (Such as a BBS or a BBS door).


 Features
 --------

        * Extremely fast, written entirely in ASM.
        * Very small, uses only 10k per node.
        * Supports up to 65535 nodes.
        * Compatible with nearly all DOS BBS and door software.
        * DESQview emulation, redirects DV timeslice release
           functions to NT.
        * CPU Usage detection / optimization for DOS applications.
        * Forces doors closed if their carrier detection fails.

____________________________________________________________________________

 Installing
 ----------

 Place the following files into a directory:

 NF.BAT        The batch file used to load/unload NetFoss (and the door)
 NETFOSS.COM   The FOSSIL TSR Interrupt handler
 NETFOSS.DLL   The FOSSIL Virtual DOS Driver
 NETCOM.EXE    The Communication Engine and application loader
 NETFOSS.TXT   The NetFoss documentation (You are reading it now)
 UPGRADE.TXT   The upgrade notes for upgrading from 0.8.1 or earlier
 FOSSIL.TXT    Technical Reference: FOSSIL implementation and use
 FOSSIL.CHT    Technical Reference: FOSSIL command chart

 If this directory is not in the Path, you must copy NETFOSS.DLL to
 a directory which is in the Path.
 ******************************************************************
 *  NETFOSS.DLL is _required_ to be located in the system %PATH%. *
 ******************************************************************


 Edit your NF.BAT file and change any of the paths there as needed.
 Do not add any "CD\" commands to the batch file, or it will not
 be able to find a DOOR32.SYS file which it expects in the current
 directory if no /n{node} and /h{handle} parameters were passed on
 the command line. (See section below for details on this).

 If your BBS does not support DOOR32.SYS, you will need to make an
 additional change to your NF.BAT file as shown in the non-DOOR32.SYS
 mode section below.

 You can rename NF.BAT to NF.CMD if you like, which will use the
 NT cmd.exe command processor instead of command.com.


 Note that NetFoss supports any COM port value, on all nodes.
 This allows BBS programs and doors that were designed to only support
 FOSSIL ports COM1 though COM4 to work on any node. To take advantage
 of this, you could set all nodes to use FOSSIL port COM1. NetFoss
 totally ignores the com port numbers that it is given. It matches up
 each node number with a WinSock handle value.


____________________________________________________________________________

 DOOR32.SYS Mode
 ---------------

 If you are using NetFoss with a 32-bit BBS package which can create
 both a DOOR32.SYS and a standard dropfile (such as EleBBS or WWIV 5.0)
 then you do not need to pass the node number or the WinSock handle to
 either NetFoss or NETCOM.
 Instead they can be automatically read from the DOOR32.SYS file located
 in the current directory (which should be the nodes dropfile directory).

 Some 32-bit BBS's which support DOOR32.SYS can not create a standard
 drop file at the same time (i.e.: MysticBBS 1.07.03 and Synchronet 3.10)
 So in their case DOOR32.SYS mode should not be used. See below for info
 on configuring Mystic or Synchronet in non-DOOR32.SYS mode.

 If your Win32 BBS does not automatically start a batch file in the current
 nodes directory then you would have to change to the nodes directory in
 the beginning of your NF.BAT file. This is not required for most BBS
 programs.


 You will need to edit the door command line for each of your doors.
 A typical type-7 command line in EleBBS would look like this:

 C:\BBS\NF.BAT c:\bbs\lord\start.bat *N
 ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
    |                     |
 This loads NetFoss.     This is the batch file that runs a door.

 Note that NF.BAT is not passed any information which node or Winsock
 handle to use. That is because both NETFOSS.COM and NETCOM.EXE will
 find this information by reading the DOOR32.SYS from the current
 directory.

____________________________________________________________________________

 Non-DOOR32.SYS Mode
 -------------------

 For a DOS based BBS, you will *need* a telnet server to answer incoming
 telnet connections, and pass them to the DOS BBS software thru NetFoss.
 This can be done with any DOS BBS that supports a front-end mailer.

 A Telnet server is needed because NetFoss is not a modem emulator, so
 it will not support ATA, ATZ, RING, or other modem commands/responses.
 Therefore you can NOT use your DOS BBS program to wait for a call, and
 answer when it sees a RING. 

 If you must have a modem emulator, there is an alternative solution
 called COM/IP (available at http://pcmicro.com/comip) which emulates
 modems and COM ports. COM/IP also includes its own FOSSIL support.


 The following Telnet servers have been tested with NetFoss:

 * TelSrv by Mannsoft (Now R & M) A simple Win32 BBS telnet server.
   Freeware and open source.  This is an older version of GameSrv.
   ftp://pcmicro.com/netfoss/telsv412.zip

 * zTelnet Server by Zoob. Freeware.
   http://grouty.org/bbs/ztelsrv.php

 * GameSrv by R & M software. A telnet server and mini-BBS. Freeware.
   http://randm.ca

 * Argus by Ritlabs. A complete front-end/mailer. Freeware, open/source.
   http://www.ritlabs.com/argus

 * Radius. An enhanced mailer based on the Argus source. Freeware,
   open/source.
   http://radius.5076.ru/cgi/en/index.php

 * Beemail by Graphic Expressions. A complete front-end mailer. Shareware.
   http://www.beemail.gexonline.net

 * Dumple BBS Server, by SWT. Written in Python. open source. Freeware.
   http://members.cox.net/swt2/Dumple/

 * VADV32 Telnet Server for Virtual Advanced BBS, by John Tipton. Freeware.
   http://vadv32.at2k.org


 For Non-DOOR32.SYS mode, you will need to change one line of your NF.BAT
 file, to pass the node number to NETFOSS.COM. This is only needed if your
 BBS can not create a DOOR32.SYS drop file.

 NF.BAT normally looks like this:

               @echo off
               c:\bbs\netfoss.com
               if errorlevel 1 goto end
               c:\bbs\netcom.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
               c:\bbs\netfoss.com /u
               :end

 In order for it to work on a Non-DOOR32.SYS environment, you will need
 to change the second line to "c:\bbs\netfoss %1" in order to pass the
 node number to NETFOSS.COM.

 Next you will need to configure your telnet server (or a Win32 BBS) to
 pass both the node number, and the WinSock handle to the NF.BAT file,
 as parameters %1 and %2  These will need to be prefixed with the "/n"
 and "/h" switches, respectively.
 i.e.:

    C:\BBS\NF.BAT /N{node} /H{handle} c:\bbs\bbsname.exe -C1 -B38400

 For example, Argus uses &n to pass the node number, and &h to pass
 the Winsock handle to an external program. So your Argus external
 command line (Config >Externals >Doors >Door Parameters) would look like:


   c:\path\nf.bat /n&n /h&h c:\path\bbs.bat -N&n -C1 -B38400
       |            |    |       |           |    |   |
   NetFoss-loader   node handle  bbs-loader  parameters sent to bbs cmd line


 In this example, we assume the BBS software uses -C1 to pass the
 current com port, -B38400 to pass the baud rate, and -N1 to pass a node
 number to the BBS software.

 Almost all DOS BBS software allows an active call to be passed from a
 front-end mailer to the BBS in this fashion, though the BBS parameters
 such as -C -N -B will differ slightly from one BBS program to another.
 Please consult your BBS documentation on the proper parameters needed
 to pass a caller from a front-end mailer to the BBS.

____________________________________________________________________________

 MYSTIC BBS Win32 USAGE
 ----------------------


 Mystic's Win32 telnet server (TSERVER.EXE) had problems with early
 versions of NetFoss, because it did not set the socket for non-blocking
 mode. NetFoss now forces the socket to use non-blocking mode.

 Another issue is that under Windows NT/2000/XP, Mystic BBS version 1.07.3
 will crash with an exception error when attempting to create a DOOR32.SYS.

 Mystic was not designed to create both a DOOR32.SYS and a standard drop
 file at the same time. I have heard of at least two people who have
 a kluge script to create both a DOOR32.SYS and a standard door dropfile
 allowing NetFoss to work with Mystic in DOOR32.SYS mode, but here is how
 to do it without using the DOOR32.SYS:


 1) If you have problems using Mystic's TSERVER.EXE you can use a
    replacement telnet server such as TelSrv by Mannsoft, Argus by RITlabs,
    Beemail by Graphic Expressions.
    The commandline the new telnet server should use to start Mystic is:
         C:\MYSTIC\MYSTIC.EXE -N{node} -TID{socket handle}

 2) Modify one line of your NF.BAT, to pass the node number to NetFoss.COM.
    Change the line that loads NetFoss.COM to have a " %1" at the end.  
    (this is explained in detail in the DOS BBS section above.)

 3) Add the door to Mystic.  Tell it to create whatever dropfile you want to
    use with the door (ie DOOR.SYS, DORINFO1.DEF...anything but DOOR32.SYS)
    and use this commandline as a template:
         C:\NetFoss\NF.BAT /N%3 /H%0 C:\LORD\START.BAT %3

   This will replace "%3" with the node number, and will replace "%0" with
   the socket handle.  Note that %3 is actually used twice in the above
   example, first to pass the node to netcom.exe, and then again to pass
   the node number to the doors own batch file.


____________________________________________________________________________


 EleBBS Win32 Usage
 ------------------

 NetFoss was developed and tested with EleBBS Win32 using the telnet server
 included in the EleBBS package. There are detailed instructions on how to
 configure NetFoss with EleBBS included in a separate file: ELEBBS.TXT


____________________________________________________________________________

 Synchronet BBS 3.1x USAGE
 --------------------------

 Synchronet already has its own FOSSIL support, but using NetFoss in place
 of the internal FOSSIL will allow DOS doors to run considerably faster,
 often by a factor of 2 or more times faster then the internal speed.

 Synchronet will create a DOOR32.SYS file, but it will not start up in the
 current nodes directory as it should, and Synchronet is unable to create
 both a DOOR32.SYS and a standard drop file at the same time, which is why
 the DOOR32.SYS mode should not be used at the time this doc was written.
 
 Here is how to configure the "Legend Of The Red Dragon" door in Synchronet
 3.10j using the Non-DOOR32.SYS mode:


  Name                       LORD
  Internal Code              LORD
  Start-up Directory         C:\SBBS\XTRN\LORD
  Command Line               c:\sbbs\nf.bat /N%# /H%H start.bat %#
  Clean-up Command Line
  Execution Cost             None
  Access Requirements
  Execution Requirements
  Multiple Concurrent Users  Yes
  Intercept Standard I/O     No
  Native (32-bit) Executable Yes
  Use Shell to Execute       No
  Modify User Data           No
  Execute on Event           No
  Pause After Execution      No
  BBS Drop File Type         GAP             DOOR.SYS
  Place Drop File In         Node Directory
  Time Options...

  Notice that the Native (32-Bit) Executable option is enabled. This
  needs to be turned on in order for Synchronet to not enable its own
  internal FOSSIL driver. REPEAT - even though you are not using
  DOOR32.SYS as your dropfile, Native (32-Bit) Executable must be
  enabled.  Additionally, make sure to change the command line to
  reflect the directory that you installed NetFoss and the Start-up
  directory should reflect where your door is installed.

  When using the Non-DOOR32.SYS mode, you must edit your NF.BAT file
  to add the " %1" at the end of the second line, as explained earlier
  in this document. Instructions can also be found in the NF.BAT.

  Make sure to change the Command line to reflect the directory that
  you installed NetFoss in, and the Start-up directory should reflect
  where your door is installed.

  In the LORD example above, the start.bat is the batch file located
  in the Start-up Directory which actually runs this door game.

____________________________________________________________________________


 PCBoard BBS Usage
 -----------------

 NetFoss has been tested with PCBoard version 15.3 & 15.4beta for DOS.
 Here is how to configure it:

 1) Install any of the Win32 Telnet Servers listed in the non-DOOR32.SYS
    mode section above.

 2) Edit your NF.BAT file as described in the non-DOOR32.SYS mode section.

 3) Install PCBoard in the c:\pcb directory, and create a separate directory
    for each node, such as c:\pcb\node1 and c:\pcb\node2 etc.

 4) Run PCBSETUP.EXE > Modem Information> Modem Setup.
    Set the COMM Driver to use as "F=FOSSIL, set the COM port to any
    non zero value. Setting it to "1" will work even if you have a real
    COM1 port already. Set the Opening Baud Rate to 115200, and select
    Lock in Opening Baud Rate = Yes.

 5) Create a BOARD.BAT in the PCBoard directory which looks like this:

        @ECHO OFF
        CLS
        SET PCB=/NODE:%1 /PORT1F:
        SET PCBDRIVE=C:
        SET PCBDIR=\PCB\NODE%1
        SET PCBDAT=C:\PCB\PCBOARD.DAT
        SET NODE=%1
        :top
        %pcbdrive%
        cd %pcbdir%
        if exist remote.bat REN remote.bat remote.sys
        if exist door.bat   DEL door.bat
        if exist endpcb     DEL endpcb
        pcboardm /file:%pcbdat% /C:115200
        if exist remote.bat CALL remote.bat
        if exist door.bat   CALL door.bat
        if exist event.bat  CALL event.bat
        if NOT exist endpcb GOTO top
        :end

        Note that each %1 will be replaced with the node number
        when this batch file is run. The line that actually runs pcboard
        is the "pcboardm /file%pcbdat% /C:115200". The /C:115200 tells it
        to assume that the user is already connected at that baud rate.
        The "/PORT1F" setting tells PCBoard to use FOSSIL port COM1,
        and it is preferable to set the same FOSSIL port for all nodes.

  6) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL
     to a directory located in your PATH.

  7) Configure a Win32 Telnet Server to run the NF.BAT and the BOARD.BAT
     batch files. If you are using Mannsofts TelSrv it should look like:

      Working Directory:

             c:\pcb


      External Program Command Line:

             c:\telsrv\nf.bat /n*N /h*H c:\pcb\board.bat *N

      [ ] Enable NetFoss Support (Disabled)


    Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory
    containing your nf.bat is located within the TelSrv directory, then you
    can (and must) enter a simpler form of External Command Line:

          c:\pcb\board.bat *N

    Then TelSrv will automatically add "NetFoss\nf.bat /n*N /h*H " to
    the actual command line.

____________________________________________________________________________


 RemoteAccess BBS Usage
 ----------------------
    
 NetFoss was tested with RemoteAccess BBS for DOS version 2.62.1
 Here is how to configure it:

 1) Install RemoteAccess in c:\ra and create directories for each node
    such as c:\ra\node1 and c:\ra\node2 etc.

 2) Create a RUNRA.BAT in the RemoteAccess Directory, which looks like this:

            cd\ra\node%1
            ra.exe -B115200 -B115200 -N%1


    The -B115200 switch tells RemoteAccess to assume that the caller is
    already connected to the modem at that speed.
    The -N%1 passes the node number, since %1 is replaced with the
    node number when the batch file is run.

  3) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL
     to a directory located in your PATH.


  4) Configure a Win32 Telnet Server to run the NF.BAT and the RUNRA.BAT
     batch files. If you are using Mannsofts TelSrv it should look like:

      Working Directory:

             c:\ra\node*N


      External Program Command Line:

             c:\telsrv\nf.bat /n*N /h*H c:\ra\runra.bat *N

      [ ] Enable NetFoss Support (Disabled)


    Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory
    containing your nf.bat is located within the TelSrv directory, then you
    can (and must) enter a simpler form of External Command Line:

          c:\ra\runra.bat *N

    This is because the rest is automatically added by TelSrv.

____________________________________________________________________________


 Telegard BBS Usage
 ------------------
    
 NetFoss was tested with Telegard BBS for DOS version 3.09G2 and SP4.
 Here is how to configure it:

 1) Install Telegard, and optionally install the service pack4 for it.

 2) Create a TG.BAT in the Telegard Directory, which looks like this:

            cd\tg
            telegard.exe -B115200 -Q -N%1


    The -B115200 switch tells Telegard to assume that the caller is
    already connected to the modem at that speed.
    The -Q switch tells Telegard to exit after the caller logs off.
    The -N%1 passes the node number, since %1 is replaced with the
    node number when the batch file is run.


  3) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL
     to a directory located in your PATH.

  4) Configure a Win32 Telnet Server to run the NF.BAT and the TG.BAT
     batch files. If you are using Mannsofts TelSrv it should look like:

      Working Directory:

             c:\tg


      External Program Command Line:

             c:\telsrv\nf.bat /n*N /h*H c:\tg\tg.bat *N

      [ ] Enable NetFoss Support (Disabled)


    Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory
    containing your nf.bat is located within the TelSrv directory, then you
    can (and must) enter a simpler form of External Command Line:

          c:\tg\tg.bat *N

    This is because the rest is automatically added by TelSrv.


____________________________________________________________________________


 Door Game Usage
 ---------------

 It's preferable to set up all nodes of a door to use the same COM port
 value, such as COM1. NetFoss ignores the COM port value, but many
 FOSSIL aware doors only work on COM1 thru COM4, while some doors support
 up to COM9. There are a few doors that support higher COM port values,
 for example Trade Wars supports up to COM255.

 Here are some notes on specific doors:

 * The Pit 

       Version 4.17 (as well as 4.16 and 4.15) have a bug which
       prevents them from working with a FOSSIL driver if a COM
       port UART is not available. This is a bug in these versions.
       Version 4.05 and below do not have this issue, and will work
       fine with NetFoss. I'm not sure 4.06 or above. If your
       computer has a real COM port that is not in use, then set
       all nodes of The Pit 4.17 to use that port.

 * Lunatix

       Version 4.3a is considerably slower then some older versions
       (such as 4.0).

 * BBS Crash

       Version 5.6 does not support a FOSSIL driver even though it is
       supposed to. Version 5.1 has been tested and works fine. I'm
       not sure about other versions.


 * Battle of the Arts

       Version 2.0 runs fine under NetFoss, but version 2.20 has broken
       FOSSIL support and never even attempts to communicate with the
       NetFoss at all.



 If you notice any other doors that say they support a FOSSIL driver
 but are not working, please let us know.

____________________________________________________________________________


 Known Issues
 ------------


 Compatibility issues with "Zone Alarm" firewall software reported.

 When running under Synchronet, a few doors dont run with NetFoss
 including Tradewars 2002, even though the same doors run fine under
 other BBS software. This will be looked into, but is a minor issue
 since Synchronet has its own FOSSIL.


 When running WildCat 4.2 for DOS under NetFoss, a 100% CPU usage
 has been reported when the user logs off and WildCat attempts to
 drop carrier. The folks at Santronics are sending me a developer
 version of WildCat 4.2 to allow me to duplicate the issue.

____________________________________________________________________________

 Zmodem File Transfer notes
 --------------------------

 The following FOSSIL aware Zmodem File Transfer Protocols have been
 successfully tested with NetFoss:

 FDSZ (05/20/97) - Omen Technology.
 SynZM 1.00      - Synopsis
 PDZmodem 1.2.6  - Peter Mandrella
 Pdrive 2.10     - Larry Athey, Max Graphics
 CEXYZ 1.0 DOS   - George Hatchew, Cutting Edge Computing


 I also tested ZSX 3.10, which claims to be FOSSIL compatible,
 but it failed to transfer any files in my testing.

 Keep in mind that Zmodem was never designed to be used with telnet,
 and its error correction is useless overhead on a telnet connection.
 I did a simple comparison of the Zmodem protocols on a P4 2GHZ
 computer running Windows XP, transferring to a localhost client
 running Mtelnet beta 12 by Dink (available at http://ozone.eesc.com)
 which uses its own internal zmodem driver.

 I only tested Zmodem using the default 1K block size, not the 8K
 ZedZap flavor of Zmodem because Mtelnet only supports the 1k standard.


 Here are my results sending a 5.8MB ZIP file from NetFoss to mTelnet:

 FDSZ      -  1 minute,  59 seconds.
 SynZM     -  2 minutes, 57 seconds.
 PDrive    -  2 minutes, 57 seconds.
 PD Zmodem -  4 minutes, 42 seconds.
 CEXYZ     - 10 minutes, 20 seconds.

 As you can see, there is a very big difference in performance.
 Keep in mind this test was done only on a local computer, to
 avoid any speed fluctuations that can occur over the internet.
 Your results my vary. 

 Interestingly, FDSZ is the only one of these protocols that
 sends and receives a single character to/from the FOSSIL driver
 at a time. All the other protocols support the read block and
 write block FOSSIL functions. If FDZ supported these then I
 expect its performance would be considerably higher.

 One potential problem when uploading files to the BBS (NetFoss),
 is that buffering can occur, causing the sender to finish the
 transfer long before the BBS side finishes receiving. This can
 result in a timeout and failed transfer. This is still being
 investigated.


 You can find all these protocols at the BBS Archives here:
 http://archives.thebbs.org/ra90a.htm
____________________________________________________________________________




 Frequently Asked Questions:
 ---------------------------


  Q:  Does NetFoss run under Windows 95, 98, or ME?
  A:  No.

  Q:  Does NetFoss run under Windows 2003, XP, 2000, or NT4?
  A:  Yes.

  Q:  Does FOSS allow all DOS BBS programs and doors to run via
      a telnet connection?
  A:  Yes, as long as they support a FOSSIL correctly.

  Q:  Does NetFoss work with Windows BBS programs?
  A:  Yes and No. Window programs don't use a FOSSIL themselves, though
      a FOSSIL is needed to run DOS doors. NetFoss does allow Windows
      BBS programs to shell to DOS doors.

  Q:  Does NetFoss work with doors that do not support a FOSSIL driver?
  A:  No.

  Q:  Does NetFoss work as a FOSSIL for real com ports?
  A:  No.

  Q:  Does NetFoss work as a FOSSIL for COM/IP?
  A:  No.

  Q:  Why do get a "Node is already in use" message from NetFoss?
  A:  See the NETCOM.EXE error messages section below.

____________________________________________________________________________

 NETFOSS.COM Error Messages
 --------------------------

  Usage:
   /n{value}  Set node
   /u         Uninstall

       This helpscreen is displayed if any unknown parameter as passed
       on the command line.


  Node is already in use

       This indicates that either the current or another DOS Window
       already has the NETFOSS.DLL file activated with the same node
       number assigned.
       The node number was either passed on the command line, or read
       from the DOOR32.SYS file.

       If you see this, try closing any open DOS windows (command prompts)
       that are open, in case you inadvertently had installed netfoss
       to the same node number from another window.

       Another possibility is that you loaded NetFoss before you loaded
       your Win32 BBS from the same window, in which case the BBS is
       attempting to open another instance of NetFoss from that window.

  Can't find netfoss.dll


       This means that netfoss.dll was not located in any of the directories
       listed in the environment variable called "Path".
       
       You can change the path (a system environment variable) by going to
       the Windows Control Panel, click on "System Properties", Click on
       the "Advanced" Tab, Click on "Environment Variables" and edit the
       value for the System variable named "Path".

  Bad netfoss.dll [0x]

        This means that netfoss.dll was found, but it was unable to load it.
        The error code in the brackets should be sent to the developer.
 

  DOOR32.SYS not found

       This means that there was no /n{node number} switch passed from
       the command line, so NetFoss was expecting to find a DOOR32.SYS
       in the current directory where it would obtain the node # from.

       Most BBS's create drop files (including DOOR32.SYS created by newer
       Windows BBS's) are created in the nodes default directory, which
       is often the directory that the BBS was started from.
       When a BBS runs an external program (a door), it starts out in
       this directory, and often a doors batch file may then change
       the directory to door location.
       This is not usually the case with Synchronet BBS, as it allows
       the sysop to define which directory the door starts out in.
        

  Low memory
        
       This means there was not enough RAM for NetFoss to install itself.
       Netfoss requires approximately 2k of conventional memory to install
       itself, (conventional is memory below 640k) but once installed it
       uses less then 1k of conventional memory. It also requires about 7k
       of extended memory to operate.
 
  Needs NT/2K/XP

       This means an inferior version of Windows has been detected. ;)

  Can't uninstall

       This means that NetFoss was told to uninstall itself (with the /u)
       but it was either not previously installed from that window or it
       was unable to uninstall itself.


____________________________________________________________________________

 NETCOM.EXE Error Messages
 --------------------------


  Error: No command line given. NETCOM aborting

      This means that NETCOM was not given the path\filename.exe of
      a DOS application to execute (such as a BBS or a door) or a
      Batch file (either .BAT or .CMD) to process.
      The command line given must include the extension.


  Error: no node/handle passed, and no DOOR32.SYS found

      This means that NETCOM was not passed a /n{node number}
      and a /h{socket handle} value on the command line, and there
      was also no DOOR32.SYS file found in the current directory.
 
  Error: This Node is already in use

      This means that another NetCom is already communicating with
      NETFOSS.DLL on the node number that was either passed on the
      command line or read from the DOOR32.SYS file. 
 

  Error: External application failed to execute

       This means that the command line that netcom was told to
       execute failed to work. Usually this indicates the path
       or filename you specified did not exist, though there could
       be other reasons.


  Error reading DOOR32.SYS

      The DOOR32.SYS file was not readable, or was in the wrong
      format.


  No port given, assuming local mode.

      This means that the port listed in DOOR32.SYS or passed on the
      command line was -1, which means the door should be run in local
      mode without any tcp/ip interface.

 
____________________________________________________________________________

 FOSSIL Functions Reference
 --------------------------

    Common Functions:
               Function 00h - Set communications parameters
               Function 01h - Transmit character and wait
               Function 02h - Get received character with wait
               Function 03h - Return Serial Port Status
               Function 04h - Activate Port
               Function 05h - Deactivate Port
               Function 06h - Raise/lower DTR
               Function 07h - Return timer tick information
               Function 08h - Flush output buffer
               Function 09h - Purge output buffer
               Function 0Ah - Purge input buffer
               Function 0Bh - Transmit no wait
               Function 0Ch - Non-destructive read-ahead (Peek)
               Function 0Dh - Keyboard read without wait
               Function 0Eh - Keyboard read with wait
               Function 0Fh - Enable / Disable Flow Control
               Function 10h - Control-C / Control-K checking
               Function 11h - Set cursor location
               Function 12h - Read cursor location
               Function 13h - Single character ANSI write to screen
               Function 14h - Enable or disable the DCD watchdog
               Function 15h - Write character to screen using BIOS
               Function 16h - Add / Delete a routine from the timer tick
               Function 17h - Reboot system (not supported by NetFoss)
               Function 18h - Block Read
               Function 19h - Block Write
               Function 1Ah - Break begin or end
               Function 1Bh - Get FOSSIL Driver information

      X00 Enhanced Functions:
               Function 1Ch - Activate Port
               Function 1Dh - Deactivate Port
               Function 1Eh - Extended line control initialization
               Function 1Fh - Extended serial port status/control
               Function 20h - Read with no wait (destructive)
               Function 21h - Stuff/Poke the receive buffer

       Layered Application Functions:
               Function 7Eh  - Install an "external application"
               Function 7Fh  - Remove an "external application"
 
 For detailed information on using these functions, refer to the
 FOSSIL.TXT and FOSSIL.CHT files included in the NetFoss archive.
 Additional information can be found in the X00 package.
  
____________________________________________________________________________

 License and Disclaimer
 ----------------------

 This software is being provided strictly for non-commercial use.
 It is provided free of charge for personal hobbyist usage only,
 without any warranty whatsoever. Use it entirely at your own risk.
 In no event will Mike Ehlert or PC Micro Systems, Inc. be liable
 for any damages, including loss of profits or other consequential
 damages arising from the use or inability to use NetFoss.

 You may copy and distribute verbatim copies of NetFoss, in any
 medium, provided that none of the files in the archive are
 tampered with and no files are added or removed.

 You may bundle NetFoss with your own BBS software or telnet server,
 if you do not charge a fee for the product, and as long as all the
 files in the original NetFoss archive are placed in its own sub
 directory, with no changes except for the NF.BAT file which may
 be customized as needed.

 If you wish to license NetFoss for commercial usage, or are
 interested in bundling it with your commercial software you will
 need to contact sales@pcmicro.com for licensing prices.

 NetFoss is a trademark of PC Micro Systems, Inc.
 Windows is a trademark of Microsoft Corporation.
 DESQview is a trademark of Symantec Corporation.
 COM/IP is a trademark of Tactical Software.
 X00 is a trademark of Raymond L. Gwinn.
 Other products mentioned are properties of their respected authors.
___________________________________________________________________________


 Credits
 -------

 A big thanks goes to Maarten Bekers. He explained many of the Winsock
 functions that were needed by the original NetCom to operate. Maarten
 is the author of ELECOM and EleBBS. I was beta testing Maartens SyncFoss
 interface and decided to create a driver with Level-5 FOSSIL support
 included. I'd never have got it working without Maartens encouragement
 and support.

 Another big thanks go to Hutch for developing MASM32, the ultimate
 Macro Assembler package for designing Win32 software in ASM.

 And finally, to the following beta testers who reported problems or
 offered suggestions on improving previous versions of NetFoss:

 Andrew Grimsby
 Maarten Bekers       aka ele
 Mark Netzel          aka Kram
 Rick Parrish         aka Ree (Manning)
 Marty Kazmaier       aka Surato
 Brian Zohu           aka Zoob
 Matthew Sullivan
 Louis Northmore
 Jani Sirpoma         aka Dragon
 Mike Dillon          aka GSValore
 Christopher Evans    aka Teknopup
 Jimmy Rose           aka BlueWizard
 Loginius
 Daryl Hunt           aka DeadMeat
 Chris Costakis
 Charles Ren‚ de Cotret
 Michael Everett, III aka Bobo
 George A. Roberts IV aka Sirtwist
 Eric Schwimmer       aka Uber
 Bud Younke           aka Raptor
 Doug Rhee            aka BBSFiles
 Tom Jackson          aka ACTION
 Darryl Dynnaway
 Steve Winn
____________________________________________________________________________


 Whats new:
 ----------
                      
            0.2wb      Added support for /n{node} in NetFoss.com
                       and both /n{node} and /h{handle} in netcom.exe.

            0.3wb      Optimized code, fixed win2k command line bug.

            0.4wb      Redesigned buffering routines, and in the process
                       fixed the FOSSIL peek/poke (0CH &21H) commands,
                       so now Scrabble, Axe & Fang, and any other doors
                       which previously didnt work should now be fine.
                       Fixed random input buffer garbage on first run.

            0.5        Reoptimized new code for additional speed. Improved
                       status returned when reading a character to allow
                       T&J software's doors to run. Check for carrier drop
                       during a function 2 (read character /w wait)
                       command. Set function 2 timeout to 30 seconds.

            0.6        I took a long break from NetFoss Development. This
                       is a minor update that mainly adds support for NT4.
                       The error messages are now always returned to the
                       DOS window rather then to a pop-up window. Fixed a
                       bug in FOSSIL Function 1B (return info in FOSSIL)
                       which was not returning everything it should.

            0.7        Forced Echo off for non Win32 BBS software.
                       Fixed the block-read function, which was not
                       compatible with PCBoard.

            0.7.1      Fixed buffer output bug on slower computers or
                       slow connections, thanks to Charles Ren‚ de Cotret
                       for reporting the issue and testing the fix.

            0.7.2      Added work around to fix CR/LF telnet bug in L.O.R.D.

            0.8        Added DESQview emulation, to release DV timeslices
                       to NT. Added detection and optimizations for poorly
                       designed doorkits. Enhanced carrier detection
                       routine to work around EasyDoor kit bugs
                       (Reported by Mark Netzel). Force non responding
                       doors to terminate 10 seconds after carrier drops.
                       Improved timeslicing release for local mode doors
                       (requested by Marty Kazmaier). Fixed INT1C Timer
                       Chain handling to work around the Fresh Water Fishing
                       door (reported by Mark Netzel). Optimized base memory
                       usage in netfoss.com. Updated docs. Added a pause to
                       all error messages.

            0.8.1      Minor Update. Fixed ANSI detection problem introduced
                       in v0.8 in which Renegade BBS and some doors created
                       using doorframe were unable to detect ANSI.
                       (Reported by Cory Snow and Marty Kazmaier).

            0.8.2b     These were private beta versions of a rewritten Netcom
             thru      released only to the beta team. They included command
            0.8.5b     line paremeters to configure the timer settings.
                       Removed the L.O.R.D. CR/LF work around since its fixed
                       in the beta version of L.O.R.D.


            0.8.5wb    An "experimental" Wide beta of NetCom, to be used with
                       NetFoss 0.8.1. It now responds to AIC "Are you there"
                       requests, and turns on binary mode by default, although
                       binary transfers may not be fully functional. Please
                       read the BETANOTE.TXT file for details on this release.

            0.8.6      The Return of NetFoss! After a year and a half pause
                       in development, I have started working on it again.
                       Thanks to Doug Reah for testing hundreds of doors
                       with NetFoss on his BBS, and letting me know which
                       ones didn't run. It turned out that several doors by
                       "William Roundtree" did not follow the level 5 FOSSIL
                       specs correctly, so a work around was added. Also
                       some doors such as Death Masters could generate a
                       blank remote display, fixed. Adjusted the timing
                       to slow down during Zmodem transfers, to prevent the
                       BBS end from finishing first and timing out.
 
            0.8.7      Fixed a bug that could cause netfoss to crash when
                       running PCBoard, reported today by Darryl Dynnaway.
                       Restored a small delay at startup after setting the
                       telnet options, as Mtel (and terminals running under
                       COM/IP) would sometimes expereince garbage input
                       chars without this. Reported by Doug Rhee and Mark
                       Netzel.

            0.9        Fixed block-read command to support FOSSIL zmodems
                       (other then FDSZ) that transfer in blocks rather
                       then a character at a time. Fixed FDSZ rz function.

            0.9.1      Added workaround for VADV BBS hanging after a
                       portscan is done on port 32, reported by Steve Winn.
