
                     -= NetFoss - an Internet FOSSIL =-
                           for Windows NT/2000/XP

                                Version 0.8.1
                              December 2, 2002
                           Written by Mike Ehlert
               Copyright (c) 2001-2002 PC Micro Systems, Inc.
____________________________________________________________________________
 
 NetFoss is a FOSSIL revision level 5 driver for Telnet communications
 under Windows NT4, 2000, and XP. 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 (ie: 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 NT4, Windows 2000, or Windows XP (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
 --------

        * Extreamly fast, written entirly 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 Interupt 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)
 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 automaticly 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 (ie: MysticBBS 1.07.03 and Synchronet 3.10j)
 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 automaticly 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 NEFOSS.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/responces.
 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. A simple Win32 BBS telnet server. Freeware.
   http://mannsoft.ca/telsrv.php

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

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


 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, respectivly.
 ie:

    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 fashon, 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
    replacment 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 seperate file: ELEBBS.TXT


____________________________________________________________________________

 Synchronet BBS 3.10x 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
  Modify User Data           No
  Execute on Event           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.

  When using the Non-DOOR32.SYS mode, you must edit your NF.BAT file
  to set add the " %1" at the end of the second line, as explained
  in the above section.


____________________________________________________________________________


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

 NetFoss has been tested with PCBoard version 15.4 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 seperate 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 perferable 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 automaticaly 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 directorys 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 automaticaly 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 automaticaly added by TelSrv.


____________________________________________________________________________


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

 It's peferable 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.

 * Lunatix

       Version 4.3a is considerably slower then some older versions
       (such as 4.0). NetFos detects when Lunatix 4.3a is running,
       and does as much as possible to improve its performance.

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


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

____________________________________________________________________________


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


 Binary mode (ie: Zmodem) is not implemented yet.

 Compatibility issues with "Zone Alarm" firewall software reported.

____________________________________________________________________________


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


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

  Q:  Does NetFoss run under Windows NT4, 2k, or XP?
  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).

  Q:  Do I need to run COM/IP to get doors to work under telnet?
  A:  No. You only need a telnet server (such as the free TelSrv).

  Q:  Does NetFoss work with Windows BBS programs?
  A:  Yes, but Window programs don't use a FOSSIL themselfs, though
      a FOSSIL is needed to run 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.

____________________________________________________________________________

 NETFOS.COM Error Messsages
 --------------------------

  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 inadvertantly 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 directorys
       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 approximatly 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 Messsages
 --------------------------


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


  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 hobbiest useage only,
 without any warranty whatsoever. Use it entirly 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
 intrested in bundling it with your commercial software you will
 need to contact mikes@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 NETCOM to operate. Maarten is the author
 of ELECOM and EleBBS. I was beta testing Maartens SyncFos interface
 when I got the idea of creating a simular driver with Level-5 FOSSIL
 support included. I would never have got it working without Maartens
 encouragement and support.

 Another big thanks go to Hutch for developing MASM32, making it very
 simple to design Win32 software in ASM.

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

 Andrew Grimsby
 Maarten Bekers
 Mark Netzel         aka Kram
 Rick Parrish        aka 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
 Loginius
 Daryl Hunt
 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


____________________________________________________________________________


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

            0.3        Optimized code, fixed win2k command line bug.

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


