-= NetFoss Internet FOSSIL =-
for Windows
Version 1.0 final
September 16, 2007
Copyright (c) 2001-2007 PC Micro
____________________________________________________________________________
NetFoss is a FOSSIL driver for Telnet or Modem communications under
Windows XP, Vista, 2003, 2000, and NT4. NetFoss supports the revision 5
FOSSIL specifications plus the extended FOSSIL functions defined in X00.
A FOSSIL [Fido Opus Seadog Standard Interface Layer] is a driver which
allows DOS based modem communication software to communicate through an
interface that directs to the actual hardware (such as a dialup Modem).
Originally FOSSIL drivers were only designed for serial communications.
NetFoss communicates with dialup Modems, Virtual Modems, or with TCP/IP
using its own Network Telnet Communication engine, NetCom.
Requirements
------------
* Windows XP, Vista, 2003, 2000, or NT4 (any 32-bit version).
* DOS application(s) designed to communicate with a FOSSIL driver.
For example: BBS software, BBS external door, a Terminal, etc.
Options
-------
* A Third party Telnet Server can be used instead of Net2BBS.
* A Virtual Modem such as NetSerial can be used instead of
Net2BBS and NetCom.
* A Command Prompt Shell such as Doorway can be used for
remotely executing Console or DOS applications from a
FOSSIL. (This should only be done by IT professionals aware
of the security concerns in doing so).
Features
--------
* Extremely fast, written entirely in ASM (MASM/32).
* Small footprint, uses under 16k RAM per node.
* Supports up to 65535 nodes.
* Includes a 5K Telnet Server (Net2BBS) supporting 256 nodes.
* Internal Telnet and COM port/Modem support.
* Acts as a DOS TSR (Terminate and Stay Resident) driver.
* 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.
* Enhances Zmodem transfer performance for BBS downloads.
Table of Contents
-----------------
Introduction
Installing NetFoss
- Door32.sys Mode
- Non-Door32.sys Mode
Installing Net2BBS Telnet Server
GameSrv Usage
MysticBBS Usage
EleBBS Usage
Synchronet Usage
PcBoard Usage
ProBoard Usage
RemoteAccess Usage
Telegard/Renegade Usage
Virtual Advanced Usage
Door Game Usage
X00 Function 02 Kluge
COM Port Mode
COM Port Locking
COM Port Release
Compatibility Issues
Zmodem File Transfers
Frequently Asked Questions
NETFOSS.COM Error Messages
NETCOM.EXE Error Messages
FOSSIL Function Reference
License and Disclaimer
Credits
What's New
____________________________________________________________________________
Introduction
------------
NetFoss is a Windows based FOSSIL driver for DOS based applications.
NetFoss is compatible with COM ports and Modems (either real or virtual),
or NetFoss can be passed active Telnet connections from a Telnet Server.
NetFoss includes a simple Telnet Server called Net2BBS, and several third
party Telnet Servers can be used as well.
NetFoss is freeware, provided without warranty. We encourage any bug
reports and suggestions which can be emailed to support@pcmicro.com.
Installing NetFoss
------------------
Place the following files into a directory:
NF.BAT The batch file used to load/unload NetFoss.
NET2BBS.EXE The Net2BBS miniture Telnet Server.
NET2BBS.INI The Net2BBS .INI configuration file.
NET2BBS.TXT The Net2BBS documentation.
NETFOSS.COM The NetFoss FOSSIL TSR Interrupt handler.
NETFOSS.DLL The NetFoss FOSSIL Virtual Device Driver.
NETFOSS.TXT The NetFoss documentation (You are reading it now).
NFELEBBS.TXT The NetFoss under EleBBS door guide.
NETCOM.EXE The NetCom Telnet Communication Engine for NetFoss.
FOSSIL.TXT Technical Reference: FOSSIL implementation and use.
FOSSIL.CHT Technical Reference: FOSSIL command chart.
If this directory is not in the Windows Path, then you must copy
NETFOSS.DLL to a directory which is in the Windows Path.
To view what directories are in the Windows Path, go to the Control
Panel System Properties > System > Advanced > Environment Variables
and view the "Value" assigined to the System Variable named Path.
*******************************************************************
* NETFOSS.DLL is _required_ to be located in the Windows %Path%. *
*******************************************************************
Windows Vista will require NETFOSS.DLL is placed in \windows\system32\
Edit your NF.BAT batch file and change any of the paths as needed.
Do not add any "CD\" commands to the batch file to change directories,
or it may not be able to find a DOOR32.SYS file which it expects in
the current directory if no /n{node} parameter was passed on the
command line. (See section below for details on this).
If your BBS does not support the DOOR32.SYS drop file, you will need
to make an additional change to your NF.BAT file as shown in the
Non-DOOR32.SYS mode section below.
Up to 65535 nodes can be created by NetFoss, depending on system
resources and the software being used. Most BBS software supports up
to 256 nodes, and the Net2BBS Telnet Server also supports up to 256
nodes.
A "node" is a separate process of the BBS software, run in its own
Virtual DOS Machine (NTVDM), commonly known as a "Command Prompt".
Each node accepts a single user to login and access the BBS using
either a modem connection or a Telnet connection.
When used in Telnet mode, NetFoss accepts any COM port value up to
4096, and the same COM port value can be used on all nodes, allowing
BBS programs and doors to work on any node, even if they are limited
to functioning on only COM1 thru COM4. To take advantage of this,
set all nodes to use the same FOSSIL port, such as COM1. NetFoss will
ignore the COM port number that it is passed withing an INT 14h call.
When used in Telnet mode, NetFoss requires that each node use a
unique WinSock handle. When used in COM port mode, NetFoss requires
that each node use a unique COM port value (or COM port handle).
If You are using DOS based BBS software, skip the next chapter and
continue at the Non-Door32.SYS Section farther below.
____________________________________________________________________________
DOOR32.SYS Mode
---------------
DOOR32.SYS is a drop file format for 32-bit BBS software.
A drop file is created by BBS software to pass information about the
active connection to an external program.
If you are using NetFoss with a 32-bit Windows BBS package (such as
EleBBS or WWIV BBS for example) which can create both a DOOR32.SYS and
a standard dropfile such as DOOR.SYS then you do not need to pass the
node number, or the telnet socket handle to either NetFoss or NetCom.
Instead these BBS programs can place this information in a DOOR32.SYS
dropfile before passing control of an external application to NetFoss,
and when NetFoss sees that the DOOR32.SYS dropfile exists it will
automatically use its settings.
Some Windows BBS programs which support DOOR32.SYS dropfiles can not
create a standard drop file at the same time (i.e.: MysticBBS 1.07.03
and Synchronet 3.10). In this case DOOR32.SYS mode should not be used.
See further below for detaled info on configuring Mystic or Synchronet
in non-DOOR32.SYS mode.
If your Windows BBS software does not automatically start an external
door or batch file in the BBS's "current nodes directory" then you
could add a CD\ command to your NF.BAT file to change to the nodes
directory before loading the NETFOSS.COM TSR. 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 in this example NF.BAT is not passed any information on which
node or TCP socket 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.
In the above example EleBBS is passing the *N macro to the doors batch
file, and the *N is replaced with the current node number by EleBBS.
____________________________________________________________________________
Non-DOOR32.SYS Mode
-------------------
To run a DOS based BBS under Windows in Telnet mode, you also need to
install either of the following software applications:
A. A Windows compatible Telnet Server, such as the included Net2BBS.
Or choose one of several other freeware Telnet Servers for Windows.
or
B. A Virtual Modem designed for Windows, such as NetSerial, which can
emulate up to 256 virtual COM ports and supports Modem AT Commands.
There is a list of free Telnet Servers compatible with NetFoss below.
NetSerial is a commercial Virual Modem and COM port redirector which
creates up to 256 Virtual Modems under Windows. Each Virtual Modem can
be assigned to a BBS node which answers the next incoming Telnet
connection as if it was communicating with a real dialup Modem.
NetSerial also allows outbound telnet connections to redirect to your
application software such as a FidoNet Mailer or a Terminal program by
"dialing" an IP address and making a Telnet or RAW TCP/IP connection as
if it was a phone number. NetSerial includes advanced features like
SSL Encryption, and realtime COM port tracing/logging of all data flow
and Virtual Modem AT commands and responses.
NetSerial is available to BBS Sysops at a discounted price of $25 USD.
----------------------------------------------------------------------
Contact sales@pcmicro.com to request the Sysop discount offer.
NetSerial is available for download at http://pcmicro.com/netserial
NetSerial is designed to work with NetFoss - or any DOS based FOSSIL
driver, such as ADF, BNU, or X00. (limited to COM1-COM4 because of DOS)
NetSerial also functions without a FOSSIL, with its DOS UART Emulator.
Please refer to the "Using NetFoss with a COM port" section of this
guide for details on configuring NetFoss to work with NetSerial.
The following freeware Telnet servers have been tested with NetFoss:
* NET2BBS by PC Micro. This Telnet Server is included with NetFoss.
Only 5k in size, and runs as a console application. Supports log
files, WAV player, Semaphore checking, and more. Freeware.
http://net2bbs.net
* TelSrv by Mannsoft. A simple yet elegent GUI Win32 BBS Telnet Server.
This is the original and simpler version of GameSrv in which the
Telnet Server is seperate from the included mini-bbs. Freeware and
open-source. http://pcmicro.com/netfoss/telsv412.zip
* GameSrv by R & M software. A telnet server with an internal mini-BBS.
Freeware in active development. http://gamesrv.ca
* Argus by Ritlabs. A complete front-end mailer. Freeware, open-source.
http://www.ritlabs.com/argus
* Radius. An enhanced mailer based on Argus. Freeware, open-source.
http://radius.cphost.ru/cgi/en/index.php
* Taurus. More advanced mailer based on Radius. Freeware, open-source.
http://taurus.rinet.ru
* Dumple BBS/Telnet Server by SWT. Written in Python. Freeware, open-source.
http://dumple.thebbs.org
* zTelnet Server by Zoob. Freeware.
http://grouty.org/bbs/ztelsrv.php
* EleBBS Telnet Server, (telserv/EleServe) Freeware, open-source.
http://elebbs.com and http://pcmicro.com/elebbs/faq
* VADV32 Telnet Server for Virtual Advanced BBS. Freeware.
http://vadv32.at2k.org
* Mystic Telnet Server for Mystic BBS Win32. Freeware.
http://www.safesite.com/product.php[id]38283
(new site now under construction at http://mysticbbs.org)
* WWIV Win32 Telnet Server (Works with any BBS). Freeware, open-source.
http://wwiv.sourceforge.net/
* Tornado Win32 Telnet Server. Freeware and open source.
http://tornado.thebbs.org
For Non-DOOR32.SYS mode, you will need to change one line of the NF.BAT
file, to pass the node number to NETFOSS.COM. This is only needed if you
are running either A) DOS based BBS software, or B) Win32 BBS which does
not create a DOOR32.SYS drop file when it runs a DOS door.
NetFoss is distributed with a default NF.BAT which is configured to run
in DOOR32.SYS mode with 32-bit Windows BBS Software. It 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 NetFoss to work in 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. Here is an example:
C:\BBS\NF.BAT /N{node} /H{handle} c:\bbs\bbsname.exe -C1 -B38400
In which {node} and {handle} are positive numeric values representing
the node number to use and the telnet "socket handle" to use.
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.bat
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 connected caller from a front-end mailer to the BBS.
____________________________________________________________________________
Installing Net2BBS Telnet Server
--------------------------------
Net2BBS is a Windows Telnet Server included with NetFoss.
It has the following features:
* Very small footprint, Net2BBS.EXE is about 5K in size.
* Configurable Node support, up to 256 nodes.
* Logs all IP's & hostname connections to screen and file.
* Multimedia support, plays login.wav and logoff.wav if found.
* Semaphore support, refuses connections when semaphore file exists.
* IP and hostname blocking, supporting wildcards.
* A classic Console mode text interface.
Net2BBS needs to be configured before you can run it. You can copy
the NET2BBS.INI.SAMPLE to NET2BBS.INI, and then edit the file as needed
using a text editor such as NotePad.
The sample Net2BBS .INI file uses these settings:
[Settings]
Command=c:\netfoss\nf.bat /n*N /h*H c:\pcb\pcboard.bat *N
StartPath=c:\pcb\
Port=23
Nodes=256
StartNode=1
Debug=1
View=Normal
Log=telnet.log
Semaphore=wait.sem
KillList=kill.txt
KillMsg=You are not welcome here.
KillMsgFile=goaway.ans
Editor=notepad.exe
Resolve=1
ResolveMsg=Resolving your IP Address, One moment...
A Full description of each of these settings is listed in NET2BBS.TXT.
The only line you need to adjust in Net2BBS.INI is the "Command="
line. This needs to run NetFoss and your BBS software, passing the
Node Number using the *N macro, and passing the Socket Handle using
the *H macro. The *I macro can be used to pass the callers IP Address.
Refer to the following BBS configurations listed below for examples
of how the "Command=" line should appear.
-----------------------------------------------------------------------------
GameSrv Usage
-------------
If you wish to install GameSrv as your Telnet Server (or mini-bbs)
then please refer to the documentation included with GameSrv.
Different versions of GameSrv have unique configuration settings.
-----------------------------------------------------------------------------
Mystic BBS Win32 Usage
----------------------
The Win32 version of Mystic BBS comes with its own telnet server named
TSERVER.EXE. In our testings in 2001, Mystic BBS version 1.07.3 would
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. However there are scripts for Mystic avilable that
overcome this by creating both DOOR32.SYS and DOOR.SYS, allowings NetFoss
to be used in DOOR32.SYS mode. Another solution is to run NetFoss without
using a DOOR32.SYS file, as described below:
1) If you have problems using Mystic's TSERVER.EXE you can use an
alternative telnet server such as Net2BBS.EXE included with NetFoss.
The commandline the new telnet server should use to start the Win32
version of Mystic is:
C:\MYSTIC\MYSTIC.EXE -N{node} -TID{socket handle}
If you are using Net2BBS, edit your Net2BBS.INI file to include
the following: Command=c:\mystic\mystic.exe -N*N -TID*H
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, but not DOOR32.SYS)
and use this commandline as a template:
C:\NetFoss\NF.BAT /N%3 /H%0 C:\LORD\START.BAT %3
Subsitute "C:\LORD\START.BAT" with the actual path/filename of the
batch file that runs door.
Mystic 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 number to netfoss.com and
netcom.exe in the NF.BAT, and then again to pass the node number to the
doors own batch file.
____________________________________________________________________________
EleBBS Win32 Usage
------------------
NetFoss was originally developed for use with both the Windows and DOS
verions of EleBBS, which is a RemoteAccess compatible BBS package for
Windows, Linux, DOS, and OS/2. The Windows version of EleBBS includes
a Telnet Server.
There are detailed instructions on how to configure NetFoss with EleBBS
included in a separate file in the NetFoss archive named NFELEBBS.TXT
____________________________________________________________________________
Synchronet BBS 3.1x USAGE
--------------------------
Synchronet already has its own FOSSIL support, but using NetFoss in place
of the internal FOSSIL can allow DOS doors to run considerably faster,
often by a factor of 2 or more times faster then the internal speed, with
lower CPU usage. You can use NetFoss to run all or just some or all of
your door programs, and run others using the internal FOSSIL.
Synchronet can create a DOOR32.SYS file, but we do not suggest running
NetFoss in DOOR32.SYS mode because Synchronet is unable to create both a
DOOR32.SYS and a standard drop file at the same time. For this reason the
DOOR32.SYS mode should not be used at the time this guide 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 either reflect where
your door is located if you dont use a batch file to start the door, or
could have the startup directory point to your current node directory
where the dropfiles are created. (If you do the later, you should launch
the door with a batch file that first uses the CD\ command to Change the
Directory to where the door is located.
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 in NF.BAT to reflect the directory
that you installed NetFoss in, and the Start-up directory should reflect
where your door is installed.
In the LORD door 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 in Telnet mode:
1) Install either Net2BBS or any of the other 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 PCBOARD.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
c:\pcb\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 "c:\pcb\pcboardm /file%pcbdat% /C:115200". The /C:115200
tells PCB 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 Windows PATH.
7) Configure a Telnet Server to run the NF.BAT and the PCBOARD.BAT
batch files. If you are using the included Net2BBS Telnet Server,
then edit your Net2BBS.INI file to use a command line like this:
Command=c:\netfoss\nf.bat /n*N /h*H c:\pcb\pcboard.bat *N
If you are using the Mannsoft TelSrv, configure it like this:
Working Directory:
c:\pcb
External Program Command Line:
c:\telsrv\nf.bat /n*N /h*H c:\pcb\pcboard.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\pcboard.bat *N
Then TelSrv will automatically add "NetFoss\nf.bat /n*N /h*H " to
the actual command line.
8) For maximum file transfer speed, install Public Domain Zmodem
(PD ZModem) as an external protocol in PCBoard. This runs several
times faster then the PCBoard internal Zmodem or FDSZ.
This is done by editing the following batch files located in the
main PCBoard directory:
pcbsz.bat (to send files from the bbs)
pcbrz.bat (to receive files to the bbs)
Replace the PCBoard protocols ZMRECV.EXE and ZMSEND.EXE with the
proper SZ/RZ commands as described in the PD Zmodem section below.
____________________________________________________________________________
ProBoard BBS Usage
------------------
NetFoss was tested with ProBoard BBS for DOS version 2.17 (freeware).
Here is how to configure it:
1) Install ProBoard in c:\pb and create directories for each node
such as c:\pb\node1 and c:\pb\node2 etc.
2) Create a RUNPB.BAT in the ProBoard Directory, which looks like this:
set proboard=c:\pb
cd\pb\node%1
\pb\proboard.exe -B115200 -N%1
The -B115200 switch tells ProBoard 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. (Under Vista, you will need
to copy NETFOSS.DLL to c:\windows\system32\ using an administrator
command prompt).
4) Configure a Telnet Server to run the NF.BAT and the RUNPB.BAT
batch files. If you are using the included Net2BBS Telnet Server,
then edit your Net2BBS.INI file to use a command line like this:
Command=c:\netfoss\nf.bat /n*N /h*H c:\pb\runpb.bat *N
If you are using Mannsofts TelSrv it should look like this:
Working Directory:
c:\pb\node*N
External Program Command Line:
c:\telsrv\nf.bat /n*N /h*H c:\pb\runpb.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 must enter a simpler form of External Command
Line:
c:\ra\runpb.bat *N
This is because the rest is automatically added by TelSrv.
5) For maximum file transfer speed, install Public Domain Zmodem
(PD ZModem) as an external protocol in ProBoard. This runs several
times faster then the ProBoard internal Zmodem or FDSZ.
____________________________________________________________________________
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:
set RA=c:\ra
cd\ra\node%1
\ra\ra.exe -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 Telnet Server to run the NF.BAT and the RUNRA.BAT
batch files. If you are using the included Net2BBS Telnet Server,
then edit your Net2BBS.INI file to use a command line like this:
Command=c:\netfoss\nf.bat /n*N /h*H c:\ra\runra.bat *N
If you are using Mannsofts TelSrv it should look like this:
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 must enter a simpler form of External Command
Line:
c:\ra\runra.bat *N
This is because the rest is automatically added by TelSrv.
5) For maximum file transfer speed, install Public Domain Zmodem
(PD ZModem) as an external protocol in PCBoard. This runs several
times faster then the RemoteAccess internal Zmodem or FDSZ.
____________________________________________________________________________
Telegard BBS Usage
------------------
NetFoss was tested with Telegard BBS for DOS version 3.09G2 and SP4.
The same method can also be used to install Renegade (Which was a
similar BBS based on an older version of Telegard source).
Here is how to install NetFoss with Telegard:
1) Install Telegard, and optionally install the service pack4 for it.
The official site is http://telegard.net
2) Create a seperate node directory for each node, such as \tg\node1
3) Create a TG.BAT in the Telegard Directory, which looks like this:
cd\tg\node%1
\tg\telegard.exe -B115200 -Q -N%1
The cd command changes to the current node directory.
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.
4) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL
to a directory located in your Windows PATH. Restart any DOS
Windows to see the new path.
5) Edit the NF.BAT to add a " %1" to the end of the netfoss.com
command line, as described in the "Non-DOOR32.SYS mode" above.
6) Configure a Telnet Server to run the NF.BAT and the TG.BAT batch
files. If you are using the included Net2BBS Telnet Server, then
edit your Net2BBS.INI file to use a command line like this:
Command=c:\netfoss\nf.bat /n*N /h*H c:\tg\tg.bat *N
If you are using Mannsofts TelSrv it should be configured as follows:
Working Directory:
c:\tg\node*N
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 must enter a simpler form of External Command
Line:
c:\tg\tg.bat *N
This is because the rest is automatically added by TelSrv.
7) For maximum file transfer speed, install Public Domain Zmodem
(PD ZModem) as an external protocol in PCBoard. This runs several
times faster then FDSZ.
____________________________________________________________________________
Virtual Advanced BBS Usage
--------------------------
NetFoss is included with Virtual Advanced BBS, as part of the VADV32
package available from http://vadvbbs.com
VADV32 also includes its own Win32 Telnet Server, which is preconfigured
to use NetFoss as its FOSSIL driver.
____________________________________________________________________________
Doorway Usage
-------------
Doorway allows remote control of a computer's Command Prompt via a
modem or a telnet connection. Doorway was developed by Marshall Dudley
from 1987-1996, and in 2006 PC Micro aquired the source code and rights
to Doorway, in an effort to revive this excellent product.
Doorway can be downloaded from http://pcmicro.com/doorway
To install doorway as a door in your BBS software, configure your BBS
to create a DOOR.SYS drop file, and to run a DOORWAY.BAT batch file.
The DOORWAY.BAT could contain this line:
DOORWAY.EXE SYSF /V:D^U /O:T /B:M /P:C:\WINDOWS\SYSTEM32\COMMAND.COM
If DOORWAY.EXE is not in the PATH, you should add the full path to it's
location in, such as c:\bbs\doorway\doorway.exe {other paramenters here}
Doorway has several different options for how the bottom display line is
handled. If you have issues, try changing /B:M to /B:MZ which moves text
on 25 to line 24. Read DOORWAY.DOC for details on other /B: settings.
____________________________________________________________________________
Door Game Usage
---------------
It's suggested to set up all nodes of a door to use the same COM port
value, such as COM1. When NetFoss is functioning in "Telnet Mode" it
ignores the COM port value. This is because 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
TradeWars supports up to COM255.
Here are some notes on specific doors:
* The Pit
Version 4.17 (as well as 4.16 and 4.15) has a bug which
prevents it from functioning with a FOSSIL driver if a COM
port UART is not found at startup. Previous versions 4.05 and
below do not have this issue, and will work fine with NetFoss.
If your PC has a real COM port, or a PCI modem card you can
avoid the issue by setting all the nodes of The Pit 4.17 to
use that COM port.
At the time of this writing, an older version of the source
code to The Pit was recovered and is being updated by "Deuce".
* Lunatix
Version 4.3a is considerably slower then some older versions
(such as 4.0), but all versions are functional with NetFoss.
* BBS Crash
Version 5.50 and 5.60 do not support a FOSSIL driver even though
they claim to. Version 5.10 does support a FOSSIL driver perfectly.
The author broke FOSSIL support in the 5.50 release which was the
following public release after 5.10.
* 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 one.
If you notice any other doors that claim to support a FOSSIL driver
but are not working, please email support@pcmicro.com.
____________________________________________________________________________
X00 Function 02h Kluge
----------------------
While all versions of NetFoss included support for the extended X00
FOSSIL commands above AH=1Bh, a new parameter was added to NetFoss
version 0.9.2 and above, which controls how the FOSSIL command 02h
(Receive character with wait) returns. The official FOSSIL rev 5 specs
states that this command will always return with AH=0, but X00 returns
with AH=status (the same status returned by command 03h).
Most FOSSIL aware programs ignore the results returned in AH after a
command 02h (Receive character with wait), but a small number of door
games have been found to expect either 00, or a valid status.
To provide maximum compatibility, NETFOSS.COM can be passed a command
line parameter /x which forces it to return from command 02 with the
status in AH, rather then zero.
To enable this X00 compatibility kluge, you can edit your NF.BAT file
to add an /x parameter, like this:
@echo off
c:\bbs\netfoss.com /x
if errorlevel 1 goto end
c:\bbs\netcom.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
c:\bbs\netfoss.com /u
:end
The above NF.BAT is for door32.sys mode only. For non-door32.sys
mode it would look like this:
@echo off
c:\bbs\netfoss.com %1 /x
if errorlevel 1 goto end
c:\bbs\netcom.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
c:\bbs\netfoss.com /u
:end
When /x is not present on the netfoss.com command line, then
Command 02h always returns with AH=00.
When /x is present on the netfoss.com command line, then
Command 02h always returns with AH={Status}
Hint: If you run a Win32 BBS, you can create a second batch file
which includes /x such as NFX.BAT which makes it simple to allow
only certain doors to use this mode.
For most door games, /x is not needed and should not be used
as it can cause some other doors to fail.
____________________________________________________________________________
COM port Mode
-------------
NetFoss can be used either in Telnet mode, or in COM port mode.
COM port mode allows NetFoss to be used with real Modems for a legacy
Dialup BBS, or it can be used with Virtual Modems such as NetSerial.
BBS Sysops can purchase NetSerial at a special sysop price of $25.
Currently the COM port mode does not support colescing data, so software
which only writes one character to the fossil at a time will be slightly
slower when used on a COM port compared to running NetFoss in Telnet mode.
Well designed BBS software will send large blocks of characters or data
to to the FOSSIL driver at a time, which is considerably faster.
When using NetFoss in COM port mode, there is no need to use the NF.BAT
file, because NetCom (The Telnet Communication Engine) is not neeeded.
Simply run NETFOSS.COM as a TSR, by loading it with the node number and
COM port number like this:
NETFOSS.COM /N1 /C1
This will install the NetFoss TSR (Terminate and Stay Resident)) code
by binding it to the current Command Prompt (Virtual DOS Machine).
The above example uses Node 1, COM1.
Once the TSR is installed in the current Command Prompt, you can simply
run your BBS application or Front End Mailer from that Command Prompt,
and it will see NetFoss is operating on INT 14h.
When your application is finished running, you can uninstall the
NetFoss TSR from the current Command Prompt by running:
NETFOSS.COM /U
When the Command Prompt is closed, NetFoss is automatically uninstalled
from it.
----
It is also possible (but not suggested) to use the NF.BAT file when
using NetFoss in COM port mode, but you would need to make some changes
to your NF.BAT as shown below.
To use the /C parameter to pass the COM port number, you could make the
following changes to your NF.BAT:
1. The line that runs netfoss.com will need both /c{value} and
/n{value} parameters, which each need to be a value from 1 to 4096.
i.e.: /N1 /C1
2. The line that runs netcom.exe can optionally be removed and replaced
with the following line:
call %1 %2 %3 %4 %5 %6 %7 %8 %9
3. Any batch files that NF.BAT executes (via the call command),
may not contain an "Exit" command. This is because the call
command is used to run one batch file from another one, but
the exit command will prevent the original batch file from
regaining control. This will result in nf.bat never uninstalling
netfoss afterwards.
The second step (#2) is optional, as NETCOM.EXE is not required for
COM port mode. If NETCOM.EXE is passed a /C{value} or detects the
DOOR32.SYS is set for COM port mode, it will run in local mode, simply
spawning the given command line.
NETFOSS.COM will also enable COM port mode if it finds a DOOR32.SYS
drop file which is configured for COM port mode, if a DOOR.SYS drop
file also exists in the same directory.
Please note that if the /C parameter is passed to NETFOSS.COM, this
effectivly disables Telnet mode (Unless you use a virtual modem such
as NetSerial for your telnet engine).
Do *NOT* pass a /C parameter to NETFOSS.COM if using a Telnet Server.
---
Here is how to run NetFoss as a TSR, so a NF.BAT is not needed.
This will *ONLY* work in COM port mode:
Load NETFOSS.COM into memory by passing it the node number and
the COM port number to use, like this:
NETFOSS.COM /N1 /C1
This will Install NetFoss into the current "Command Prompt" (NTVDM)
Window, running as a TSR.
If you install NetFoss in multiple "Command Prompt" windows using the
COM port mode, they will each need to use a unique Node number and a
unique COM port number.
---
When using NetFoss with NetSerial'S Virtual Modems, you should configure
NetSerial like this:
Connection type: Telnet
[ ] Request Remote Telnet Echo
[X] Accept Local Telnet Echo
[X] Request Binary Connection
Port Mode: Virtual Modem
Inbound TCP Port: 23
[X] Accept inbound connections
The suggested BBS Init string for NetSerial is AT&D2
This forces the virtual modem to disconnect when the BBS software
lowers the DTR line on the virtual COM port.
NetSerial can create up to 256 Virtal Modems.
Each Virtual Modem can be controlled by NetFoss in a seperate node.
Virtual Modems do not require Windows modem drivers to work with NetFoss
and DOS based applications including BBS programs.
____________________________________________________________________________
Locked COM Port Baud Rate
-------------------------
NETFOSS.COM allows the /L{value} parameter to be specified when using
a COM port, to define a Locked baud rate to set the COM port to.
If no locked value is given, the COM port will default to being locked
at 115200 baud.
Some BBS Software, such as EzyCom, requires using a slower baud rate of
57600, 38400 or even 19200 baud in order to function.
The /L{value parameter can only be used along with the /C{value}
parameter, which sets NetFoss to use a COM port.
An example command line is:
NETFOSS.COM /N1 /C1 /L57600
This sets Node 1, COM port mode using COM1, locked at 57600 baud.
____________________________________________________________________________
COM Port Release
----------------
NETFOSS.COM allows the /R parameter to be specified when using COM port
mode, which causes NetFoss to release the COM port after it receives a
"Deinitialize Port" FOSSIL command from the application.
By default, NetFoss will open a COM port when it receives an "Initialize
Port" FOSSIL command, and it will hold that COM port open until NetFoss
is told to uninstall itself from memory (using the /U parameter), or
until the Command Prompt window it was loaded in is closed.
While NetFoss is holding a COM port open, it is not possible for any
other applications to access the COM port directly.
____________________________________________________________________________
Compatibility Issues
--------------------
Some "security" software (anti-virus and firewalls) will interfere with
a socket being passed from a Telnet Server to another process such as
NetFoss. This process is known as Socket inheritance.
NOD32 anti-virus must be configured to allow the Telnet Server to do this,
by doing the following:
1. Click on IMON from the NOD32 control center.
2. Click on Setup, and then click the "Miscellaneous" tab.
3. Under the Exclusion section, click the "Edit" button and add the
path/name of your telnet server .exe file.
ZoneAlarm Security Suite will not allow exclusions to be defined, so it
must be uninstalled.
Windows Server 2003 or 2008 will fail to allow socket inheritance if a
policy to enforce QoS on created TCP sockets is enabled.
____________________________________________________________________________
Zmodem File Transfers
---------------------
The following FOSSIL aware Zmodem File Transfer Protocols have been
successfully tested with NetFoss in BBS Download mode:
PD Zmodem 1.2.6 - Peter Mandrella, Daisy Data & Information Systems
SynZM 1.00 - Synopsis, Edge of Honor
PDrive 2.10 - Larry Athey, Max Graphics
FDSZ (5/20/97) - Chuck Forsberg, Omen Technology
AnDan Zmodem 1.04 - Anders Dannielsson, Andan Softare
SDPF - Thomas Thayer, Streamline Design
CEXYZ 1.0 DOS - George Hatchew, Cutting Edge Computing
ZSX 3.10 was also tested, which claims to be FOSSIL compatible, but it
failed to transfer any files.
Zmodem benchmark results
------------------------
The following Zmodem benchmarks were performed on a Celeron 1.5Ghz CPU
with 256 megs RAM running Windows 2000 Professional. Your results may
differ under other environments.
The Zmodem protocols were used to send files to an Mtelnet terminal
program (version beta 12 by Dink available at http://ozone.eesc.com)
Mtelnet was located on the same LAN to avoid any internet lag.
Only the default block size of 1K was used in this test, because
Mtelnet does not support the larger 8K blocks.
The benchmark results for sending files to an Mtelnet terminal are:
PD Zmodem - 350,000 CPS < The Winner! >
SynZM - 28,500 CPS
PDrive - 28,500 CPS
FDSZ - 28,500 CPS
SDPF - 21,900 CPS
AnDan Zmodem - 19,000 CPS
CEXYZ - 9,065 CPS
ZSX - Failed
These are speeds which Mtelnet can receive/download the files being sent
by a BBS using the listed protocols. Mtelnet has its own internal Zmodem
implementation, so the protocols are only installed on the BBS end.
The result is that "Public Domain" Zmodem is by far the fastest FOSSIL
compatible Zmodem protocol tested, by over 12 times the speed of others.
When Mtelnet is used to send/upload files to a BBS running these Zmodem
protocols, Mtelnet can only send at a maximum of around 200,000 CPS.
This is because Mtelnet sends data in smaller packets causing the data
to become buffered while the receiving protocol eventually recieves the
data (at its fastest speed).
This presents a problem in which Mtelnet will finish sending a large file
long before the BBS is finished receiving the file. Mtelnet will wait
several minutes for a conformation from the BBS end acknoleging that the
transfer was completed sucessfully. If it does not see this within a few
minutes, the transfer will fail. The only protocol which can keep up with
high speed transfers of large files being sent from mtelnet is "Public
Domain" Zmodem.
To allow a BBS to accept large Zmodem uploads using NetFoss, you *MUST*
use the "Public Domain" Zmodem (also known as PD Zmodem) protocol.
The "Public Domain" Zmodem protocol is freeware, and is available from
http://netfoss.com
You can download other file transfer protocols at the BBS Archives:
http://archives.thebbs.org/ra90a.htm
Configuring PD Zmodem for use with a BBS
----------------------------------------
Most BBS software allows external protocol drivers to be defined for
Zmodem and other file transfer protocols. The following example
command lines can be used:
Download from BBS:
ZM -f -ldDSZ.LOG sz
Upload to BBS:
ZM -f -ldDSZ.LOG -r rz
The "-ldDSZ.LOG" parameter is not needed if you define a system environment
variable in Windows as follows:
DSZLOG=DSZ.LOG
When using PD Zmodem with NetFoss, the COM port parameter does not need
to be specified. COM1 is assumed by default, and NetFoss ignores the COM
port value anyways). The baud rate also does not need to be specified,
since the existing baud rate is used by default.
____________________________________________________________________________
Frequently Asked Questions:
---------------------------
Q: Does NetFoss run under Windows Vista?
A: NetFoss is compatible with all Vista 32-bit editions, but you will
need top copy NETFOSS.DLL to c:\windows\system32\
Vista 64-bit editions do not support DOS driver hooks.
Q: Does NetFoss run under Windows 2003, XP, 2000, or NT4?
A: Yes.
Q: Does NetFoss run under Windows 95, 98, or ME?
A: No.
Q: Does NetFoss allow all MS-DOS-based BBS programs and doors to
redirect to a telnet connection?
A: Yes, as long as the application supports FOSSIL or INT 14h
communications NetFoss can be used. For other applications that
communicate directly with serial UART hardware, the NetSerial
redirector can be used instead.
Q: Does NetFoss work with Windows-based BBS programs?
A: Yes and No. Windows-based programs don't use a FOSSIL themselves,
so a FOSSIL is only needed to allow the BBS to shell to external
MS-DOS-based applications (called doors). This is done by the BBS
handing over the telnet socket (or COM port) to NetFoss when a door
is run, and after the door application exits, NetFoss releases the
socket (or COM port) and returns control to the BBS program.
Q: Do I need a Telnet Server to use NetFoss?
A: NetFoss includes a Telnet Server (Net2BBS), and it can also be used
with several other Windows Telnet Servers. NetFoss is compatible
with modems, (real or virtual) which do not require a telnet server.
Q: Does NetFoss work as a FOSSIL for physical com ports?
A: Yes.
Q: Does NetFoss work as a FOSSIL for NetSerial and other Virtual Com
ports or Virtual Modems redirectors under Windows?
A: Yes.
Q: Does NetFoss work as a FOSSIL for direct Telnet?
A: Yes. NetFoss includes the NetCom Telnet Communication engine
which takes over an active TCP/IP connection from the Telnet Server.
Q: Why do I get a "Node is already in use" message from NetFoss?
A: See the NETCOM.EXE error messages section below.
Q: How can I improve Zmodem transfer speeds?
A: By installing PDZmodem as an external protocol in the BBS.
Q: Do I need to use Net2BBS to use NetFoss?
No, you can use other Telnet Servers instead, or you can use
NetFoss with NetSerial which does not require a Telnet Server.
Q: Can Net2BBS be run from the System Tray?
A: Yes, by installing the freeware TrayIt Utility downloadable from
http://www.teamcti.com/TrayIt
Q: When a client is downloading from my BBS using Zmodem, I see
FDSZ occasionally stall for 12 seconds, then continue. Why?
A: NetFoss sees that the TCP write buffer is being filled, because
FDSZ is generating too many almost-empty packets, causing the
client to receive no more then 25K-35K CPS, while FDSZ transfers
faster on the BBS end. Each time the buffer fills, NetFoss pauses
for 12 seconds to allow the client some time to catch up. Using
PD Zmodem instead of FDSZ can avoid the issue.
Q: Can I donate to NetFoss development?
A: Sure, Paypal donations are accepted at sales@pcmicro.com.
However NetFoss is freeware, so please don't feel obligated to pay.
____________________________________________________________________________
NETFOSS.COM Error Messages
--------------------------
Usage:
/N{value} Set node
/C{value} Set COM port mode (this disables Telnet mode)
/L{value} Set Locked Baud (only use if COM port mode is set)
/R Allow COM Release (when FOSSIL is told to Deinitialize)
/X Use X00 status kluge
/U Uninstall
This helpscreen is displayed when any unknown parameter is passed
on the NETFOSS.COM 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 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 Windows 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 indicates netfoss.dll was found, but it was unable to load.
The error code in the brackets should be sent to support@pcmicro.com.
DOOR32.SYS not found
This indicates 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.
a DOOR32.SYS file is a "drop file". Most BBS programs create one
or more "drop files" before running an external program (door).
Drop files can then be read by the external program to determine
information about connection and user, such as speed, terminal
type, number of minutes remaining, etc.
On most BBS packages, Drop Files are typically created in the nodes
default directory, which is usually the directory that the BBS node
was started from.
When a BBS runs an external program (known as a door), it starts
the door (or its batch file) from this directory, and typically a
doors batch file will then change the directory to where the door
is actually located.
By default this is not the case with Synchronet BBS, but Synchronet
allows the sysop to define which directory the door starts out in.
DOOR.SYS not found
This indicates there was no /n{node number} switch passed from
the command line, and when NetFoss read the DOOR32.SYS it found
that Serial (COM Port Mode) is requested. NetFoss then looked
for a 16-bit style DOOR.SYS in the same directory in order to
determine the COM port number to use, read the COM port, but this
file was not found.
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 8k
of extended memory to operate.
Needs NT
This means an inferior version of Windows has been detected. ;)
NetFoss requires NT4, 2000, XP, 2003, or Vista 32bit.
Can't uninstall
This means that NetFoss was told to uninstall itself from memory
(after being run with the /u parameter), but it was either not
previously loaded in the current NTVDM (Command Prompt) window or
it was unable to uninstall itself for some other reason.
____________________________________________________________________________
NETCOM.EXE Error Messages
--------------------------
Error: No command line given. 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{telnet 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.
COM Port Mode - TCP/IP disabled.
This occurs if the DOOR32.SYS is configured for COM Port mode,
or if a /C{value} parameter was passed to NETFOSS.COM, which
causes NetCom to run the external program without a TCP/IP
interface.
Local Mode - TCP/IP disabled.
This occurs if the DOOR32.SYS is configured for local mode,
or if the socket handle listed in DOOR32.SYS or passed on the
command line was -1, which causes Netcom to run the external
application without a 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
----------------------
NetFoss is provided free of charge, without any warranty whatsoever.
Use NetFoss entirely at your own risk. In no event will PC Micro Systems,
or its agents 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 a seperate sub directory, with
no changes except for the NF.BAT file which may be customized as needed.
NetFoss is a trademark of PC Micro Systems, Inc.
Net2BBS is a trademark of PC Micro Systems, Inc.
NetSerial is a trademark of PC Micro Systems, Inc.
Doorway is a trademark of PC Micro Systems, Inc.
PC Micro is a trademark of PC Micro Systems, Inc.
DESQview is a trademark of Symantec Corporation.
FrontDoor is a trademark of Definite Solutions.
X00 is a trademark of Raymond L. Gwinn.
Windows is a trademark of Microsoft Corporation.
Other products mentioned are properties of their respected authors.
___________________________________________________________________________
Credits
-------
A big thanks goes to Maarten Bekers for answering many Winsock related
questions during the original NetCom development in 2001. Maarten is the
author of EleBBS and EleCom. NetFoss began as a side project while beta
testing Maarten's SyncFos interface and encountering issues with door
compatibility and performance, so NetFoss was created to redirect DOS
INT 14h calls to our experimental NetCom communication driver. NetFoss
would never have become a reality without Maartens initial support.
Another big thanks go to `Hutch' for developing MASM32, the ultimate
Macro Assembler package for designing Windows software in ASM, and to
Rob Swindell for info on the C++ Virtual DOS Driver 'BOP' hooks.
And finally, thanks to the following beta testers who reported problems
and/or offered suggestions on improving previous versions of NetFoss:
Andrew Grimsby aka Andrew
Maarten Bekers aka Ele
Mark Netzel aka Kram
Rick Parrish aka Ree
Marty Kazmaier aka Surato
Brian Zohu aka Zoob
Matthew Sullivan
Louis Northmore
Jani Sirpoma aka Dragon
Mike Dillon aka GSValore
Michael Preslar aka Z
Christopher Evans aka Teknopup
Jimmy Rose aka BlueWizard
Loginius aka 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
Deathr0w aka Deathr0w
Ioram Sette
Minh Van Le
Brian Taylor
Rich Ringer aka Pony
T.J. McMillian aka Exodus
Alexey Fayans aka Burning Shadow
Michael Montague aka Tarix
____________________________________________________________________________
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 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 After a long pause in NetFoss development, this
is a minor update which adds support for NT 4.0.
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. 4.07.
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,
development has now resumed. Thanks to Doug Reah for
testing hundreds of doors with NetFoss on his BBS, and
reporting which ones didn't run. It turned out that
several doors by "William Rountree" 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, preventing
the BBS end from finishing first and timing out.
0.8.7 Fixed issue that could cause version 0.8.6 to crash
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 Adjusted block-read command to support FOSSIL Zmodems
(other then FDSZ) that transfer in blocks rather
then a character at a time.
0.9.1 Prevented VADV BBS from hanging after a portscan is
done on port 23, reported by Steve Winn.
0.9.2 It's been just over 2 years since the last update.
It turns out that one of the changes made to version
0.8.6 to allow a some doors to work which don't follow
the FOSSIL rev.5 specs causes certain other doors to
fail. The problem was that the X00 Specifications go
against the official FOSSIL level 5 specifications in
regards to what command 02 (Receive character with
wait) returns in AH. The Specs require AH=0, but X00
returns the status in AH instead. To resolve this,
NetFoss now follows the official specs unless the
netfoss.com is given the /X parameter on its command
line (within nf.bat) in which case it follows the X00
method. Both methods support extended X00 functions.
Worked around an issue with a certain PCBoard PPE
that sends invalid commands to the FOSSIL. Reported
by Deathr0w.
Improved timeslice releasing to allow certain doors
(BRE,FE,FH,TAL), to run at close to 0% CPU usage.
Slowed down binary transfers to avoid upload timeouts.
0.9.3 Improved binary tranfer speed by redesigning the
timeslice release handler to optimize for both FDSZ
and PD Zmodem transfer modes (byte or block). BBS
uploads should never timeout when using PD Zmodem.
Fixed minor NetCom issue introduced in 0.9.2 causing
a C/R to not be seen by the L.O.R.D. door with some
terminals, reported by Ioram Sette.
0.9.4 Experimental support for COM ports added, allowing
NetFoss to be used with dialup Modems, and Virtual
Modems such as NetSerial.
0.9.5 NetFoss now allows DOS based FTN (FidoNet Technology)
Mailers such as FrontDoor and D'Bridge to run over a
Telnet connection using NetSerial. Fixed some issues
introduced in 0.9.4 with status and COM port DTR
signals, reported by Rich Ringer. Fixed zero byte
write issue also issue introduced in 0.9.4, reported
by Ioram Sette. Added keepalive feature for unstable
networks and DialUp ISP connections, requested by
Minh Van Le.
0.9.6 NetFoss now includes a miniture Telnet Server called
Net2BBS, which logs IP's, plays wav files and supports
semaphore file event triggers. NetFoss now runs the
"Kannons & Katapults" door game at lower CPU usage -
http://x-bit.org/k-n-k/ Thanks xbit. NetCom was
ajusted to avoid a Windows Vista Issue, reported by
Steve Winn.
0.9.7 Fixed issue preventing PCBoard from running with
NetSerial in wait-for-call mode, reported by DeathR0w.
When the DOOR32.SYS dropfile is configured for serial
communications, NetFoss now looks for the COM port
value by also reading DOOR.SYS. Added /R switch to
release a COM port during a Deinitialize Port command.
Net2BBS includes view-minimized and view-hidden
options when launching BBS sessions. Net2BBS bug fix:
The wrong IP could be logged during a disconnect
from Net2BBS, reported by Alexey Fayans.
0.9.8 Fixed an issue introduced in version 0.9.7, which
did not allow the FDSZ file transfer program to be
shelled to from a Win32 BBS (because FDSZ never sends
a FOSSIL "Initialize" command) reported by Ioram
Sette. Added delay to telnet echo negotiation.
Removed internal Keepalive which should not be needed.
0.9.9 Optimized NetCom engine uses seperate Read and Write
Threads to minimize CPU usage while idle, and uses
larger buffers. NetCom now uses Windows TCP keepalive.
Net2BBS now displays the BBS node number in the
TitleBar of each Console window. Net2BBS disconnects
all active BBS nodes when told to exit. NetFoss now
allows a COM port to be passed a locked baud rate on
the command line, requested by Robert Wolfe.
1.0 Optimized all EXE/DLL for Pentium-4 and later CPU's.
Previous builds were optimized for Pentium-3.
Worked around an issue with NetFoss running with
NetSerial and FrontDoor, reported by T.J. McMillian.
Net2BBS now supports wildcard blocking of IP addresses
and hostnames, improved logging, View=Maximize mode,
and other .INI configuration options were added.
|
