-= NetFoss InterNET FOSSIL =-
For Windows
Version 1.25
May 31, 2014
Copyright (c) 2001-2014 PC Micro
____________________________________________________________________________
NetFoss is a Windows FOSSIL driver providing TCP & Modem communications
for DOS applications running under Windows 10/8/7/Vista/XP/2000 and the
Windows Server family. Both x86 and x64 NTVDM editions are supported.
A FOSSIL [Fido Opus Seadog Standard Interface Layer] is a driver which
allows DOS-based modem communication software to communicate through an
interface that redirects to the actual hardware (such as a dial-up Modem).
Originally FOSSIL drivers were only designed for serial communications.
NetFoss communicates with dial-up Modems, Virtual Modems, or with TCP/IP
using its own Telnet Communication engine, NetCom. NetFoss can also
redirect DOS I/O-based screen writes to the telnet or serial connection.
Requirements
------------
* 32-bit or 64-bit edition of Windows 10\8\7\Vista\XP\2000\Server
(64-bit editions will require installing NTVDMx64)
* DOS applications designed to communicate with a FOSSIL driver.
For example BBS software, BBS external door, a Terminal, etc.
or
* DOS Applications using DOS/BIOS Input/Output hooks
(typically DOS apps that require an ANSI.SYS / ANSI.COM driver)
Options
-------
* A third-party Telnet / SSH Server can be used instead of Net2BBS.
* "Core" editions of Windows Server are also supported.
* A Virtual Modem such as NetSerial can be used in place of
Net2BBS and NetCom.
* A Command Prompt Shell such as Doorway can be used for remotely
executing Console or DOS applications from a FOSSIL. Or running
Non-Fossil and Non-DOS I/O Doors.
* A NetFoss driven BBS can also run DOS doors through DOSBox, by
passing the caller's socket handle and Command-line to NFU.
Features
--------
* Extremely fast, written entirely in ASM (MASM32 SDK).
* Small footprint, uses under 16k RAM overhead per node.
* CPU Usage detection / optimization for DOS applications.
* Acts as a DOS TSR (Terminate and Stay Resident) driver.
* Includes a Telnet Server (Net2BBS) supporting 256 nodes.
* Includes a Service compatible console redirector (NetSpy).
* Allows redirecting BIOS and DOS I/O from non-FOSSIL doors.
* Compatible with nearly all DOS BBS and door software.
* DESQview emulation: redirects DESQview timeslice release
functions to Windows. Very low CPU usage.
* Enhances Zmodem transfer performance for BBS downloads.
* Allows DOS BBS software to spawn Win32/64 external doors.
Table of Contents
-----------------
Introduction
Installing NetFoss
Installing NTVDMx64
- Door32.sys Usage
- Non-Door32.sys Usage
List of compatible Telnet servers
Installing Net2BBS Telnet Server
BBBS/D Usage
EleBBS Usage
ENiGMA 1/2 Usage
EzyCom Usage
GAP BBS Usage
MysticBBS Usage
Iniquity Usage
Oblivion/2 Usage
PCBoard Usage
PC-Express Usage
ProBoard Usage
RemoteAccess Usage
Searchlight Usage
SpitFire Usage
Synchronet Usage
T.A.G Usage
Telegard/Renegade Usage
Virtual Advanced Usage
Wildcat Usage
WWIV Usage
Doorway Usage
Door Game Usage
X00 Function 02 Kluge
COM Port Mode
COM Port Locking
COM Port Release
Compatibility Issues
Output Speed setting
Zmodem File Transfers
Optimizing PD Zmodem speed
ANSI.COM Usage
NetCom.exe Command-line Switches
NetCom.ini Configuration Settings
Frequently Asked Questions
NETFOSS.COM Error Messages
NETCOM.EXE Error Messages
How NetFoss Works
Suggestions for Door/BBS developers
FOSSIL INT14 Function Reference
License and Disclaimer
Credits
What's New
____________________________________________________________________________
Introduction
------------
NetFoss is a Windows FOSSIL driver for DOS-based applications running
under Windows NTVDM (NT Virtual DOS Machine).
NTVDM is included with all 32-bit (x86) Editions of Windows, and it is
also available for 64-bit (x64) editions of Windows from a third-party
provider at the University of Columbia website.
NetFoss supports TCP connections in addition to COM ports and Modems.
TCP connections can be provided by an external server, such as the
included open-source Net2BBS Telnet Server, or any third-party server
that allows TCP socket connections, including raw TCP, Telnet, and SSH.
TCP connections can also be provided by a Virtual COM port or Virtual
Modem such as NetSerial software, which redirects serial communications
to either Raw TCP or Telnet connections with optional SSL Encryption.
Physical COM ports with modems attached can also be used with NetFoss,
to provide dial-up access over legacy telephone landlines.
Besides supporting DOS programs that communicate over a FOSSIL driver,
NetFoss also allows non-FOSSIL aware DOS programs that use BIOS or DOS
Input/Output hooks to redirect to the TCP or modem connection.
NetFoss includes Net2BBS, a lightweight open-source Telnet Server with
advanced port blocking features. NetFoss is freeware, provided without
warranty. We encourage bug reports and suggestions which can be emailed
to support@pcmicro.com.
____________________________________________________________________________
Installing NetFoss
------------------
NetFoss works with both 32-bit and 64-bit editions of Windows using the
NTVDM DOS emulator.
A 32-bit edition of Windows is recommended for maximum performance, since
they include Microsoft's NTVDM (NT Virtual DOS Machine), which allows DOS
software to run under Windows by switching the CPU into "virtual 8086 mode"
to simulate the 8086's real mode at the processor level rather than using
software CPU emulation. For this reason a native 32-bit edition of Windows
will perform DOS emulation faster than a native 64-bit edition can.
A 64-bit edition of Windows requires installing a third-party NTVDMx64,
a port of the Microsoft NTVDM (based on leaked Windows 2000 source code).
See the section below, titled "Installing NTVDMx64".
When using Windows 10 you MUST configure the NTVDM Command Prompt console
to use "Legacy Console". This is done by opening a Command Prompt console
and right-click the icon in the upper left corner and select Properties.
Then from the cmd.exe Properties screen select the "Options" tab, enable
the "Use legacy console" checkbox, and click OK. Next, close the console
and relaunch it for the changes to take place. All future consoles will
have the legacy console checkbox enabled unless it is reconfigured.
Older versions of Windows such as 8, 7, Vista, XP, etc only support the
legacy console, so no changes are required for these.
Place the following files into a directory such as c:\netfoss
ANSI.COM ANSI emulation driver for local use.
NF.BAT A batch file used to load/unload NetFoss.
NETFOSS.COM NetFoss Win32 FOSSIL TSR Interrupt handler.
NETFOS64.COM NetFoss Win64 FOSSIL TSR Interrupt handler.
NETFOSS.DLL NetFoss Win32 FOSSIL Virtual Device Driver.
NETFOS64.DLL NetFoss Win64 FOSSIL Virtual Device Driver.
NETCOM.EXE NetCom Telnet Communication Engine for NetFoss.
NET2BBS.ZIP Net2BBS Telnet Server package
NFU.EXE NetFoss Utilities for running DOS & Windows doors.
If you wish to use the Net2BBS Telnet Server, then unzip NET2BBS.ZIP
archive into the same folder. This archive contains these files:
NET2BBS.EXE The Net2BBS miniature Telnet Server.
NET2BBS.INI The Net2BBS .INI configuration file. (renamed)
NET2BBS.TXT The Net2BBS help file - documentation.
NET2MON.EXE The Net2BBS Service Monitor.
NETSPY.EXE The NetSpy Service Console redirector
SocketPolicy.xml Net2BBS SocketPolicy file (For Telnet over Web Flash).
CountryCodes.txt Net2BBS CountryCode file (for Web GeoIP location).
The following files are not required for NetFoss and Net2BBS operation:
NETFOSS.TXT The NetFoss documentation (You are reading it now).
NFU.TXT The NetFoss Utilities for running some doors.
FOSSIL.TXT Technical Reference: FOSSIL implementation and use.
FOSSIL.CHT Technical Reference: FOSSIL command chart.
NET2SRC.ZIP The MASM32 Source Code for Net2BBS/Net2Mon/NetSpy.
1. NETFOSS.DLL installation:
************************************************************************
*** IMPORTANT *** When using Windows Vista or a later version of 32-bit
(x86) Windows such as Windows 10/8/7, YOU MUST COPY NETFOSS.DLL to the
\windows\system32\ directory.
To do so, open an "Administrator Command Prompt" and enter the following
Command-line:
copy c:\netfoss\netfoss.dll c:\windows\system32
*************************************************************************
If you are upgrading from an older version of NetFoss, be sure to copy
the new NETFOSS.DLL over the old one located in the system32 folder.
*************************************************************************
To open an Administrator Command Prompt in these versions of Windows,
right-click on a "Command Prompt" icon and select "Run as Administrator".
Copying NETFOS64.DLL is not required for 64-bit (x64) editions of Windows,
nor is it required for older versions of Windows, including XP, 2000, and
Server 2003 as long as the directory where NETFOSS.DLL is located in the
Windows %Path%.
To view which directories are in the Windows %Path%, open a Command Prompt
and type "set path".
2. NET2BBS.INI Configuration:
Rename the file NET2BBS.SAMPLE.INI to NET2BBS.INI unless you already
have one. This is the Net2BBS configuration file. Edit this file as
needed. You can skip this step if using a third-party telnet server.
See NET2BBS.TXT for detailed help.
3. NF.BAT configuration:
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).
********************************************************************
*** IMPORTANT *** If your BBS software is DOS-based, you will need to
make an additional change to your NF.BAT file as shown in the
Non-DOOR32.SYS mode section below. This also applies to Mystic BBS
for Windows.
********************************************************************
4. Firewall Configuration.
If you are running Firewall software you will need to allow incoming
access on TCP port 23 in order to receive incoming telnet connections.
Newer versions of Windows allow enabling this in the Windows Firewall
automatically in a dialog when Net2BBS runs, while with older versions
you have to manually go to the Windows Firewall icon in the Control
Panel, and add a port under the Exceptions tab by selecting "Add Port"
and enter the following data:
Name: Telnet
Port number: 23
Then make sure the TCP setting is enabled for this new port.
If your BBS computer is located behind a Router, you will need to
configure your router to forward traffic from TCP port 23 to your
BBS computer.
5. Understand basic concepts:
A "node" is a separate process of the BBS software, run in its own
Virtual DOS Machine (NTVDM), or Window.
Each node accepts a single user to login and access the BBS using
either a modem connection or a Telnet connection.
A "door" is an external program, that a user connected to the BBS
can request to spawn, such as an online game.
NetFoss can optionally be used with Virtual Modems such as the ones
created by installing NetSerial, a commercial COM port redirector
software with a modem emulator supporting up to 256 virtual modems.
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.
NetFoss can function in "Telnet Mode", or "COM port Mode". It can
also function in DOS I/O mode, which redirects DOS input and output.
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 with an INT 14h call.
NetFoss requires that each node use a unique WinSock handle when used
in telnet Mode. When used in COM port mode, NetFoss requires that each
node use a unique COM port value.
____________________________________________________________________________
Installing NTVDMx64
-------------------
Only 32-bit editions of Windows include the "NT Virtual DOS Machine"
known as NTVDM, which allows DOS applications to run in emulation mode.
Microsoft did not include NTVDM in their 64-bit editions of Windows.
NTVDMx64 is a patched version of Microsoft's NTVDM, for 64-bit Windows.
It is based on leaked Windows 2000 source code, which was updated by
the OpenNT Project and includes modern build tools. A programmer known
as Leacher1337 has ported it to support 64-bit Windows by creating
code-injection loaders that convert the 32-bit and 64-bit structures
back and forth without altering the protected Windows system files.
NTVDMx64 an open-source project on Github:
https://github.com/leecher1337/ntvdmx64
The full binaries and installer can be downloaded from the University
of Columbia here: http://www.columbia.edu/~em36/ntvdmx64.html
The current version is dated April 12, 2014
Before installing NTVDMx64 on Windows 10, it is important to disable
Windows Defender "SmartScreen" and if you use Microsoft Edge to download
it, you will also need to disable "SmartScreen for Microsoft Edge".
These can both be disabled by clicking on:
* Settings> Update and Security> Windows Security> App & Browser Control
Antivirus software should also be disabled during the installation, and
if your Computer's BIOS has an option called "Secure Boot" then this
must also be disabled in order for NTVDMx64 to function. If "Secure Boot"
is detected, the installer will open a Microsoft web page that explains
how to disable it.
To install NTVDMx64, first extract the desired language folder from the
.7-zip Archive into a folder on your computer such as c:\NTVDMX64 and
right-click on the install.bat file and select "Run as Administrator".
The installer will ask if you wish to install support for 16-bit Windows
applications (WOW32), which you can answer "No" to and it will just
install support for DOS applications.
If you encounter issues installing NTVDMx64, you can open a support
ticket on the Github page. A recent sysop encountered install issues
and was assisted here:
https://github.com/leecher1337/ntvdmx64/issues/101
Since then, this issue was resolved in the October 4, 2020 release
of NTVDMx64.
You can optionally install the HAXM edition of NTVDMX64, which supports
Intel Virtualization Technology (VT-x) hardware acceleration so it is
scientifically faster in textmode.
HAXM requires a modern (2017 or later) Intel CPU with VT-x.
To determine if your CPU supports Intel Virtualization Technology,
visit https://ark.intel.com and select Processors > Find Processors
by feature, or download the Intel Processor Identification Utility.
Using HAXM, NTDVMx64 will run textmode applications nearly as
fast as Microsoft's original NTVDM for 32-bit Windows editions.
Note that when using the HAXM edition of NTVDMx64, the WOW32 feature
can not be used, WOW32 allows support for 16-bit Windows applications
made for Windows 3.1 and earlier. If such support is desired, there is
a much better solution is available here:
https://github.com/otya128/winevdm
Once NTVDMx64 is installed on your 64-bit Windows, you can install
the NETFOS64.COM/NETFOS64.DLL files in place of the standard files
(NETFOSS.COM/NETFOSS.DLL) which only supports 32-bit Windows.
Other utilities including Net2BSS, NetCom, NetSpy, and NFU all support
both 32-bit and 64-bit Windows.
____________________________________________________________________________
DOOR32.SYS Usage
----------------
If you plan to use DOS-based based BBS software, you can skip over this
chapter.
DOOR32.SYS is a drop file format for Windows (or Linux) BBS software and
doors. A drop file is created by BBS software to pass information about
the active connection to a "door" (external program that the BBS spawns).
NetFoss supports reading DOOR32.SYS dropfiles created by a Windows
BBS software, as well as writing its own DOOR32.SYS drop files to
allow a DOS BBS to run Win32 doors using NFU. See NFU.TXT for details.
DOOR32.SYS For Windows BBS Software:
====================================
When using NetFoss with a Windows BBS which can create both a DOOR32.SYS
and a standard DOS-style dropfile such as DOOR.SYS it is NOT required to
pass the node number or telnet socket handle to either NetFoss or NetCom.
Instead they can be read from the DOOR32.SYS dropfile that the BBS software
creates in the current nodes directory before executing the NF.BAT batch file.
However, in the case of using Mystic BBS, its generally simpler to pass
the node number and socket handle on the Command-line, instead of allowing
NetFoss to read the DOOR32.SYS file since Mystic does not make the node
temp directory (where dropfiles are placed) the *current directory*,
so NetFoss will not see it unless it is relocated or a CD command is used
to change the current directory.
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:\NETFOSS\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.
DOOR32.SYS for DOS BBS Software:
================================
DOS BBS software can use a DOOR32.SYS file to spawn an external Windows
program, known as Win32 door (or DOOR32 door).
NetFoss includes a utility called NFU.EXE, which among other features
allows DOS BBS Software to spawn Win32 software including doors that
require a DOOR32.SYS drop file.
A separate documentation file named NFU.TXT is included with instructions
on how to use it with several detailed examples.
___________________________________________________________________________
Non-DOOR32.SYS Usage
--------------------
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.
There are several other free Telnet and SSH 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 Virtual Modem and COM port redirector that
creates up to 256 Virtual Modems under Windows. Each Virtual Modem can
be assigned to a BBS node that answers the next incoming Telnet
connection as if it was communicating with a real dial-up 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 real-time 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.
----------------------------------------------------------------------
To purchase a license go to: https://pcmicro.com/netserial/sysop
To download a 30-day evaluation go to: https://pcmicro.com/netserial
NetSerial is designed to work with NetFoss - and also works with DOS
based FOSSIL drivers running under Windows, such as ADF, BNU, and X00.
NetSerial can also work without a FOSSIL, by allowing DOS applications
to access its Virtual COM ports directly.
Refer to the "Using NetFoss with a COM port" section of this guide for
details on configuring NetFoss to work with NetSerial.
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 DOS-based BBS software, or 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:\netfoss\ansi.com
c:\netfoss\netfoss.com
if errorlevel 1 goto end
c:\netfoss\netcom.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
c:\netfoss\netfoss.com /u
:end
In order for NetFoss to work in a Non-DOOR32.SYS environment, you will
need to change the third line to "c:\bbs\netfoss %1" in order to pass
the node number to NETFOSS.COM. This should be done if you are using
DOS-based BBS software, or Windows-based BBS software which does not
create a DOOR32.SYS drop file in the *current directory*, such as
Mystic BBS.
Note: This change will still allow a DOS BBS to run Windows DOOR32 doors.
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:\path\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.
____________________________________________________________________________
List of compatible Telnet servers
---------------------------------
The following freeware Telnet servers have been tested with NetFoss:
* Net2BBS by PC Micro. This Telnet Server is included with NetFoss.
It has a small footprint, runs as a console application or service,
and supports IP blocking, Bot detection, anti-hammering, and more.
See Net2BBS.txt for details.
open-source Freeware. http://netfoss.com
* TelSrv by Mannsoft. A simple yet elegant GUI Win32 BBS Telnet Server.
This also includes a separate mini-bbs but works with any BBS.
Freeware and open-source. http://pcmicro.com/netfoss/telsv412.zip
* 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.
https://web.archive.org/web/20060516030822/http://radius.cphost.ru/cgi/en/index.php
* Taurus. More advanced mailer based on Radius. Freeware, open-source.
http://taurus.rinet.ru or
http://web.archive.org/web/20050408223156/http://taurus.rinet.ru/
* GameSrv by R & M software. A telnet server with an internal mini-BBS.
Freeware. http://gamesrv.ca
* Dumple BBS & Telnet Server (in Python) by SWT. Freeware, open-source.
http://dumple.thebbs.org
* zTelnet Server by Zoob. Freeware.
http://web.archive.org/web/20060620115357/http://grouty.org/bbs/ztelsrv.php
* EleBBS Telnet Server, (Telserv/EleServ) Freeware, open-source.
http://elebbs.com and http://pcmicro.com/elebbs/faq
* VADV32 Telnet Server for Virtual Advanced BBS. Freeware, open-source.
http://vadv32.at2k.org
* Mystic Telnet Server for Mystic BBS Win32. Freeware.
http://www.mysticbbs.com
* WWIV Win32 Telnet Server (Works with any BBS). Freeware, open-source.
http://wwiv.sourceforge.net
* Tornado Win32 Telnet Server. Freeware and open-source.
http://thebbs.org/tornado
____________________________________________________________________________
Installing Net2BBS Telnet Server
--------------------------------
Net2BBS is a Windows Telnet Server included with NetFoss.
Features:
* Small footprint, Net2BBS.EXE is only a few Kbytes in size.
* Configurable Node support, up to 256 nodes.
* Logs all IPs & 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.
* Internal firewall, to refuse answering unwanted connections at all.
* Anti-Hammer option, adds annoying IPs to a temporary block cache.
* Bot protection, optionally blocks non-telnet and non ANSI clients.
* A classic Console mode text interface.
Net2BBS needs to be configured before it can run. Copy the text file
NET2BBS.INI.SAMPLE to NET2BBS.INI, and then edit the file as needed
using a text editor such as NotePad.
The sample .INI file uses settings like these:
[Settings]
Command=c:\netfoss\nf.bat /n*N /h*H c:\pcb\pcboard.bat *N
StartPath=c:\pcb\node*N
Port=23
PolicyPort=843
Nodes=256
StartNode=1
MaxSameIP=3
Debug=1
NodeView=1
MainView=1
NodeLines=25
Log=telnet.log
Blacklist=blacklist.txt
BlacklistMsg=You are not welcome here.
BlacklistANS=goaway.ans
Editor=notepad.exe
Semaphore=wait.sem
Resolve=1
ResolveMsg=o Net2BBS - Resolving your IP Address...
ShowHost=1
AntiScanner=1
AntiHammer=1
CacheTime=0
WhiteList=127.0.0.1
DNSBL=zz.countries.nerd.dk
BlockCC=156,643,392,804 156=China 643=Russia 392=Japan 804=Ukraine
DNSBL2=xbl.spamhaus.org
;DNSBL3=dnsbl.proxybl.org
;DNSBL4=bl.blocklist.de
GeoIPWeb=api.ipstack.com
A Full description of each of these settings is listed in NET2BBS.TXT.
Net2BBS.INI contains a "Command=" line, which spawns the NF.BAT batch file
which in turn loads the BBS Software for an incoming telnet connection.
The "Command=" line should be edited to contain the path and filename of
the software to be loaded when an incoming telnet connection is received,
including passing the the following parameters:
The Node Number --------- Required - using the *N macro
The Socket Handle --------- Required - using the *H macro
The caller's IP Address --- Optional - using the *I macro
The caller's resolved host - Optional - using the *R macro
Refer to the following BBS configurations listed below for examples
of how the "Command=" line should appear.
With some BBS software, the "StartPath=" line may also need to be edited.
The other lines do not need to be edited for most applications.
____________________________________________________________________________
BBBS/D Usage
------------
BBBS comes in DOS, Win32, OS/2, and Linux editions, but due to the way
the Win32 edition is designed, it is unable to pass a socket handle to
spawn doors using telnet.
Therefore use the DOS version (BBBS/D) with Windows and NetFoss.
It can be downloaded from https://www.bbbs.net
1) Unzip the NetFoss files into a directory such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP archive into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
2) Edit your NF.BAT file, to pass the node number to NETFOSS.COM by
changing the line that loads NETFOSS.COM to include a " %1" at the end.
(this is explained in detail in the DOS BBS section above.)
3) Unzip NET2BBS.ZIP into the same directory as NetFoss, and rename
NET2BBS.SAMPLE.INI to NET2BBS.INI
4) Edit your NET2BBS.INI to use the following Command StartPath:
Command=c:\netfoss\nf.bat /n*N /h*H c:\bbbs\bbbs.exe 1 *N
StartPath=c:\bbbs
5) Unzip BBBS/D version 4.00 into the c:\bbbs directory.
6) Using notepad, create a file named DOBBS.BAT in the c:\bbbs directory.
It only needs the following line:
x 57600 x x Telnet
7) From the c:\bbbs directory, type "BCFG4 1" to configure node 1,
and select "Local: General". Then on the "FD's DOBBS.BAT option,
enter the following:
c:/bbbs/dobbs.bat
Notice that the slashes are in the wrong direction (Unix style).
Press ESC twice, and choose "Exit and Save". Repeat Step 7 for every
node you wish to configure, using "BCFG 2" for node 2, and so on.
Now run Net2BBS.exe, and it is ready to accept Telnet connections.
____________________________________________________________________________
ENiGMA 1/2 BBS Usage
--------------------
ENiGMA 1/2 is a modern BBS built by Bryan Ashby using javascript and
the node.js module.
In order for ENigMA to create a socket handle for the connection under
Windows to run DOS doors, the bivrost.exe utility needs to be used.
See examples here:
https://github.com/NuSkooler/bivrost
____________________________________________________________________________
EzyCom BBS Usage
----------------
EzyCom is a RemoteAccess clone created by Peter Davies in 1990. In 1997
Peter handed it over to Stephen Gibbs who had a team of coders work on
several updates until 2003. Stephen's final release was version 3.00,
after which the source code was lost in a hard drive crash without a backup.
EzyCom is availale at http://www.ezycom-bbs.com
Here is how to install EzyCom with NetFoss:
1) Unpack E_V300SW.RAR to a temporary folder and run INSTALL.EXE
Next, run EZYCFG.EXE and set the following under System>System:
MultiLine: Yes
Multitasker: DESQview
This will allow NetFoss's DESQview emulator to release unused
timeslices, increasing multi-node performance.
Next, exit EzyCfg and save the configuration.
2) Create a NODE directory for each node. For example:
C:\EZY <-Main EzyCom directory
C:\EZY\NODE1
C:\EZY\NODE2
You don't need to create separate configuration files for each
node. EzyCom will look for the CONFIG.EZ configuration file in
the main EzyCom directory if it does not find a specific node's
configuration file. its important to configure the Environment
Variable %EZY% to point to the main EzyCom folder.
3) Run EZYIDX -BUILD to index the file areas.
4) Create an EZY.BAT in the main EzyCom directory which contains the
following 2 lines:
set EZY=c:\ezy
c:\ezy\ezy.exe -B38400 -N%1 -IP%2 -D
5) In the NetFoss directory, edit the NET2BBS.INI file and change
the following lines:
Command=c:\ezy\nf.bat /n*N /h*H c:\ezy\ezy.bat *N *I
StartPath=c:\ezy\node*N
6) If you have not already done so, edit the NF.BAT file to
make sure it has a %1 at the end of the third line like so:
c:\netfoss\netfoss.com %1
7) Run NET2BBS.EXE, and it is ready to accept telnet connections.
_________________________________________________________________
GAP BBS Usage
-------------
GAP was one of the early DOS BBS programs of the 1980s and was a
trend-setter back in its day. It was created by Kenny Gardner who's
DOOR.SYS drop file format became a standard used by most BBS software.
In 1999 the 3-node version 6.6 was released as freeware and in 2017
version 6.7 it was increased to 99 nodes. Kenny passed away in 2019,
and GAP is now supported by Valhalla BBS.
http://bbs.valhallabbs.com/gapfile.ssjs
Because GAP does not provide any Command-line parameter to pass a node
number to GAP.EXE, several steps must be taken in order to support
a multi-node GAP configuration.
1) Unzip the NetFoss files into a directory such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP archive into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
2) Edit your NF.BAT file, to pass the node number to NETFOSS.COM by
changing the line that loads NETFOSS.COM to include a " %1" at the end.
(this is explained in detail in the DOS BBS section above.)
3) Unzip NET2BBS.ZIP into the same directory as NetFoss.
4) Change to the C:\NETFOSS directory, rename the NET2BBS.SAMPLE.INI
to NET2BBS.INI and then edit this file using notepad.
For example, type this:
CD\NETFOSS
RENAME NET2BBS.SAMPLE.INI NET2BBS.INI
NOTEPAD NET2BBS.INI
Change The actual "Command=" and "StartPath=" lines like so:
Command=c:\gap\nf.bat /n*N /h*H c:\gap\runnode.bat *N
StartPath=c:\gap\node*N
Then Save and Exit notepad.
5) Install GAP BBS into C:\GAP and run GAPSETUP.EXE. Using the up/down
arrow keys, find the "Port Configuration" Screen, and set the Interface
setting to "Fossil". Make any other configuration changes you desire.
Then use the right arrow to select Quit > Save Changes.
6) From a Command Prompt, Change to the c:\GAP directory, and create a
separate node directory for each node, and then copy the current
configuration file into each node directory. For example, type this:
CD\GAP
MD NODE1
MD NODE2
MD NODE3
COPY GAPBBS.CNF NODE1
COPY GAPBBS.CNF NODE2
COPY GAPBBS.CNF NODE3
7) For each of the node directories, you must use the CD command to change
to that directory, and then run \GAP\GAPSETUP.EXE to edit the GAPBBS.CNF
configuration file in that directory to have the proper node number,
which matches that directory name, and also you should set the maximum
number of nodes allowed. For example, type this:
CD \GAP\NODE1
\GAP\GAPSETUP.EXE
From the GAP Configuration program, press the down arrow 9 times to reach
the screen that allows you to define the following settings:
Network Node Number: 1
Maximum Nodes To Use: 3
Once these are configured, use the right arrow to select Quit >
Save Changes. Then repeat the same steps for each NODE directory
created.
8) From the Command Prompt, change back to the C:\GAP directory and use
notepad to create a batch file named RUNNODE.BAT which contains the
following 2 lines:
cd \gap\node%1
c:\gap\GAPBBS.EXE 57600 0 0 14400 0 0 0
For example, type this:
CD\GAP
NOTEPAD RUNNODE.BAT
Once you have pasted the 2 lines into notepad, save and exit.
9) Run NET2BBS.EXE, and it is ready to accept telnet connections.
Due to GAP's node design, if you need to make configuration changes you
will need to make the changes to each node directory, as shown above.
Most BBS software which only requires one configuration for all nodes.
To simplify this task we have released a small utility called GAPNODES,
which does all the work for you.
____________________________________________________________________________
EleBBS Win32 Usage
------------------
EleBBS is a nearly exact clone of RemoteAccess BBS, with versions for DOS,
Windows, OS/2, and Linux. It was developed by Maarten Bekers from 1998 until
2002, and was later updated by Scott Little.
NetFoss works with the DOS version of EleBBS, as well as allowing the Win32
version of EleBBS to run DOS doors. The Windows version of EleBBS includes
a Telnet Server - originally named TelServ.exe and later the name was changed
to EleServ.exe which is also an FTP, POP3, and NNTP (news) Server.
You can optionally replace the EleBBS Telnet server with Net2BBS, by editing
the "Command=" and "Startpath=" lines in the NET2BBS.INI file using notepad
like so:
[Settings]
Command=c:\ele\elebbs.exe -n*N -h*H -XT -XC -XI*I -B65529
StartPath=c:\ele\node*N\
There are detailed instructions on how to configure NetFoss with EleBBS DOS
and Windows versions at http://pcmicro.com/netfoss/support.html
EleBBS can be downloaded from the USA mirror: https://pcmicro.com/elebbs
____________________________________________________________________________
Iniquity BBS
------------
Iniquity is a scene-based BBS based on WWIV source code. The original
author Michael Frikner (now a technical director for Epic Games) sold the
source to Mike Pike in 1996, and and little happened until after the source
code was leaked in 1997. Comatose and Dedchylde formed a team that released
two versions (2.0 and 2.01), and then Jack Plash of Demonic Productions
released several updates in the early 2000s. The final update was 2.20a
which is Y2K aware.
Here is how to configure Iniquity for telnet:
1) Installing version 2.0 (IQ20.ZIP), then update it using the 2.20A update
(IQ220AJP.ZIP) available from http://www.demonic.net/files.php?id=14
2) Run "Iniqity.exe Node 1 Modem local", and under "Modem configuration", set
the "Com device" setting to "Fossil", exit and save the configuration.
Then repeat this step for each additional node number.
3) Create a batch file in the Iniquity directory called RUNIQ.BAT
cd\iq
iniquity.exe node %1 baud 115200 quit
4) Edit the NF.BAT file, to add a " %1" to the end of the netfoss.com line,
as described in the batch file itself.
5) Edit your NET2BBS.INI file with the following lines:
Command=c:\netfoss\nf.bat /n*N /h*H c:\iq\iq.bat *N
StartPath=c:\iq
6) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
Mystic BBS Win32 Usage
----------------------
Mystic BBS is an Iniquity style BBS available for Windows and Linux.
The Win32 version of Mystic includes internal telnet support, so NetFoss
is only needed in order to run DOS doors under Mystic. Once Mystic is
installed, a help file with detailed instructions on how to configure
Mystic to run DOS doors under Windows using NetFoss can be found here:
c:\mystic\docs\windows_door_install.txt
While Mystic supports creating a DOOR32.SYS drop file, you will still
need to configure NF.BAT to run in "non Door32.SYS" mode by adding a
%1 after the netfoss.com Command-line. This is because, unlike most BBS
software, when Mystic executes a door it does not set the current
directory to the current nodes directory (such as c:\mystic\temp1),
where the dropfiles are located. Therefore NetFoss will never find
the DOOR32.SYS dropfile, since it expects it to be in the current
directory. This also means that doors which expect the DOOR.SYS or
DORINFO1.DEF drop file to be located in the current directory will
require the aid of a batch file to copy the needed dropfile from the
node directory to the current directory before executing the door .exe
file. However, most doors allow the location of drop files to be
specified in the doors configuration file.
As a brief example on entering a door Command-line into the Mystic menu
editor, here's a Command-line for the door game Legend of the Red Dragon:
c:\mystic\netfoss\NF.BAT /N%3 /H%0 C:\LORD\START.BAT %3
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.
It is possible to replace Mystic's telnet server with Net2BBS. While
Net2BBS was a good replacement for the original Mystic telnet server
(TSERVER.EXE), the new and improved Mystic Internet Server (MIS.EXE)
included in Mystic 1.10 and later is several servers rolled into one:
Telnet/smtp/pop3/ftp/nntp/binkp/event.
If you insist on using Net2BBS, you can edit your Net2BBS.INI file
to include the following:
Command=c:\mystic\mystic.exe -N*N -TID*H -IP*I -HOST*R
StartPath=c:\mystic
____________________________________________________________________________
Oblivion/2 Usage
----------------------
Oblivion/2 was based on early Telegard source and was first released by
Sir Roadkill in 1991. Over the years it was updated by Darkened Emnity,
HEX, and Shivan Bastard.
Oblivion/2 version 2.30 (and 2.40beta 2) were the final DOS versions.
Beware of a fake 2.40 release, which was a hex patched 2.30.
Currently, there is a Windows version of Obv/2 under development called
"Oblivion/2 XRM" (Extreme Re-Make) which includes its own telnet server.
NetFoss is only needed with this version if you wish to run DOS doors.
Here is how to configure the DOS versions of Oblivion/2:
1) Unzip the NetFoss files into a directory such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP archive into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
2) Edit your NF.BAT file as described in the non-DOOR32.SYS mode section.
3) Install Obv/2 2.30 (or 2.40b2) into c:\obv
and make node directories for the maximum number of nodes desired
like so:
c:\obv\node1
c:\obv\node2
c:\obv\node3
4) In the c:\netfoss directory, rename NET2BBS.SAMPLE.INI to NET2BBS.INI
Then edit the following lines in NET2BBS.INI:
Command=c:\netfoss\nf.bat /n*N /h*H c:\obv\runobv2.bat *N
StartPath= c:\obv\node*N
5) In the c:\obv directory, create the following batch files:
CFG.BAT
@ECHO OFF
CD\OBV
SET DSZLOG=C:\OBV\DSZLOG.1
OBV.EXE -F -CONFIG
USER.BAT
@ECHO OFF
CD\OBV
SET DSZLOG=C:\OBV\DSZLOG.1
OBV.EXE -F -USER
MENU.BAT
@ECHO OFF
CD\OBV
SET DSZLOG=C:\OBV\DSZLOG.1
OBV.EXE -F -MENU
PROMPTS.BAT
@ECHO OFF
CD\OBV
SET DSZLOG=C:\OBV\DSZLOG.1
OBV.EXE -F -PROMPTS
RUNOBV2.BAT
@ECHO OFF
CD\OBV
SET DSZLOG=C:\OBV\DSZLOG.%1
OBV.EXE -b 57600 -A -nocheck -N %1
The first 4 batch files are used to launch the configuration program,
the User Editor, the Menu Editor, and the Prompts Editor. These files are
needed since Obv/2 won't be running from the WFC (Wait For Call) screen.
The RUNOBV2.BAT file is called by Net2BBS internally to launch a BBS node
with a connected telnet session.
5) run CFG.BAT to start the configuration program, and set the following:
Under "System information", set Multinode Operation = Yes
Under "System information3", set Give Up time slices = Yes
Under "Communications", set COM Port = 1
Press Ctrl-Z to exit each section, and when done configuring save changes.
6) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
PCBoard BBS Usage
-----------------
PCBoard was one of the most successful commercial BBS programs, introduced
by the Clark Development Company in 1983, which went bankrupt in 1997 two
years after the internet had killed off most of the interest in BBS software.
NetFoss has been tested with PCBoard version 15.3 & 15.4beta for DOS.
Here is how to configure it for Telnet:
1) Unzip the NetFoss files into a directory such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP archive into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
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) Configure a Telnet Server to run the NF.BAT and the PCBOARD.BAT
batch files.
If you are using Net2BBS, then just rename NET2BBS.SAMPLE.INI to
NET2BBS.INI, as the sample is already configured for PCBoard like so:
Command=c:\netfoss\nf.bat /n*N /h*H c:\pcb\pcboard.bat *N
StartPath=c:\pcb\node*N
7) For maximum file transfer speed, install Public Domain Zmodem
(PD Zmodem) as an external protocol in PCBoard. This runs several
times faster than 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.
8) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
PC-Express BBS Usage
---------------------
PC-Express is a DOS clone of AmiExpress BBS for the Commodore Amiga.
PC-Express was created by LaRIC of the cracking group "RAZOR 1911"
in the early 1990s. Ironically it was never released as freeware.
NetFoss was tested with PC-Express versions 1.3 and 1.4beta.
1) Install PC-Express in c:\bbs and create directories
for each node such as c:\bbs\node1 and c:\bbs\node2 etc.
2) Create a RUNPCX.BAT in the BBS Directory, which looks like this:
@ECHO OFF
SET PCEXPRESS=C:\BBS
C:
CD C:\BBS\NODE*N
EXPRESS -N%1 -B19200 -F
C:
CD \BBS\THETAG
TTPERSON C
C:
CD \BBS
CALL SCAN.BAT
The -B19200 switch tells PCI-Express 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 such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
4) Configure a Telnet Server to run the NF.BAT and the RUNPCI.BAT
batch files. If you are using the included Net2BBS Telnet Server,
then rename NET2BBS.SAMPLE.INI to NET2BBS.INI, and edit the following
lines:
[Settings]
Command=c:\bbs\nf.bat /n*N /h*H c:\bbs\runpcx.bat *N
StartPath=c:\bbs\
5) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
ProBoard BBS Usage
------------------
ProBoard BBS is another RemoteAccess/QuickBBS clone, first released by
Philippe Leybaert in 1990, after the QuickBBS source code had been leaked.
It was very popular due to its PEX support, allowing mods to run within
ProBoard without shelling out to a door. Philip abandoned development in
1997, and it was sold to Telegrafix (Makers of RIP) in 1999. In 2019 it
was sold to John Riley who open-sourced it, and a new version is currently
in the works.
NetFoss was tested with ProBoard BBS for DOS version 2.17 (freeware),
as well as the (currently buggy) open-source version of Proboard 2.2x.
Here is how to configure it:
1) Extract 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 such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
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
StartPath=c:\pb\node*N
5) For maximum file transfer speed, install Public Domain Zmodem
(PD Zmodem) as an external protocol in ProBoard. This runs several
times faster than the ProBoard internal Zmodem or FDSZ.
6) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
RemoteAccess BBS Usage
----------------------
RemoteAccess (RA) started as a clone of QuickBBS by Adam Hudson. It was
initially developed by Andrew Milner in 1989 shortly after the QuickBBS
source had been leaked, and was first released in 1990. Several other
RA/QuickBBS clones soon appeared, including EZCom, ProBoard, and SuperBBS.
RA was the first BBS to support the JAM message base, and became the most
popular Shareware BBS of the 1990s. There was also a commercial RA-Pro
version that supported more than 2 nodes. It was sold to Bruce Morse in
1997.
NetFoss was tested with RemoteAccess BBS for DOS version 2.62.1, as well
as older 2.5x versions. 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 such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
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
StartPath=c:\ra\node*N
5) For maximum file transfer speed, install Public Domain Zmodem
(PD Zmodem) as an external protocol in RA. This runs several
times faster than the RemoteAccess internal Zmodem or FDSZ.
6) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
Searchlight BBS Usage
---------------------
Searchlight was the first and only BBS to display RIP Graphics on the local
side. It was created by Frank LaRosa, and later sold to Telegrafix, the
makers of RIPtel and RIPterm, which went out of business in the late 90s.
Version 5.0x for Windows included built-in telnet support, but it was
unstable, resulting in lockups and crashes. The DOS version of Searchlight
is stable and performs faster than the native Windows version when run under
NetFoss.
- Thanks for Chris Costakis and for providing the install details, and a
correction by Robert Wolf.
1) Download Searchlight 5.10 for DOS (SLBBS510.ZIP), from
http://www.slbbs.com/files/packages/slbbs510.exe
*** Note: On July 8 2020, Darryl Hunt(the owner of slbbs.com) passed
away after providing support for Searchlight for over 10 years.
The file can still be downloaded from the Archive.org Time Machine, by
appending the URL to this:
https://web.archive.org/web/20051108172905/{place full above URL here}
To find additional information and codes, check the file listing here:
https://web.archive.org/web/20160810014533/http://slbbs.com/files/packages.html
2) Install Searchlight in c:\slbbs\
3) Unzip NetFoss to and Net2BBS to c:\netfoss\ and copy NETFOSS.DLL to
c:\windows\system32\
4) Edit the NF.BAT file, to add a " %1" to the end of the netfoss.com line,
as described in the batch file itself.
5) Rename NET2BBS.SAMPLE.INI to NET2BBS.INI, and edit it to change the
following lines:
Command=c:\netfoss\nf.bat /n*N /h*H c:\slbbs\slbbs.bat *N
StartPath=c:\slbbs\node*N
6) Create a batch file named SLBBS.BAT located in c:\slbbs\ with the
following lines:
set slbbs=c:\slbbs\node%4
cd\slbbs\node%4
..\slbbs.exe 57600 14400 /C 1
7) There are 2 configuration settings you will have to change in the
Searchlight Configuration program. Run CONFIG.EXE and from the
Configuration menu, go into General Configuration, and select General
Setup #2. Change option 4 "Return to DOS on Logoff", from No to Yes.
The other change is in the General Configuration under Communications
Setup - Configure your first node to look like the following:
Communication Setup
1. COM port Number............. 1
2. Modem Type.................. High Speed
3. Locked Baud Rate............ 57600
4. Hardware Flow Control....... On
5. Speed Detect Select......... Modem Msg
6. Minimum Connect Speed....... 2400
7. Output Buffering Factor..... 32
8. Buffer door programs........ Yes (or try No)
9. Modem Init String........... ATH0M0&C1CD2S0=1!
10. Local Init String........... ATH1!
11. Answer String............... ATA!
12. COM Port Setups [...]
Once you have made the above changes, select option 12 "COM Port Setups, and
in the new screen change each "Port Type" to "FOSSIL". You don't need to
change the other settings, such as Base Address, IRQ, or External Port.
Next, set these same configurations with each additional node. You can even
use the same COM Port number with each node.
8) Because the file transfers do not work properly using Searchlight’s
internal protocols, you will need to configure Searchlight to use the
external protocol PD Zmodem, which is designed to work very well with a
FOSSIL driver. Download PD Zmodem from the NetFoss.com website, and
unzip it to c:\pdzm\
In Searchlight’s CONFIG.EXE, go to General Configuration, and then go to the
XFer Protocols Setup. You will be setting up Zmodem.
Remove all the other protocols. Your configurations will look as follows:
Protocol Name........... Zmodem
Protocol Type........... External
External Send Command... c:\pdzm\zm.exe -f -ldDSZ.LOG sz %F
External Recv Command... c:\pdzm\zm.exe -f -ldDSZ.LOG rz %F
Fossil Emulation........ Off
9) Run NET2BBS.EXE, and it is ready to accept telnet connections.
If you need assistance or SearchLight software you can visit the Searchlight
message forums at http://slbbs.com
____________________________________________________________________________
SpitFire BBS Usage
------------------
SpitFire BBS was created by Mike Woltz of Buffalo Creek Software in 1987.
It was very popular for a few years, but Mike was slow to adapt to the
changing technology of modern message bases, built-in FidoNet technology
and fossil driver support. Many SF sysops switched over to other shareware
BBS software in the early 1990s. In 1999 Mike released the final v3.6
update which still lacked support for a FOSSIL driver, so to support telnet
under Windows it must be used with a Virtual COM port redirector such as
NetSerial.
The other limitation is that normally when Spitfire runs a door,
once the door exits, Windows NT (including 10/8/7/Vista/XP/2K) lowers
the Carrier Detect signal on the modem, causing the connection to be
lost. NetSerial allows ignoring the Carrier Detect signal with the
AT&D0 init string, which works with most BBS software, but SpitFire
gets confused by this and tries to reinitialize the modem when you
return from a door.
Thanks to Jim Johnson for providing this workaround:
There is a free utility for SpitFire called "SFmenu Extended" v2.0
which allows SpitFire to run doors from a shell which returns to
Spitfire using an errorlevel. This prevents Spitfire from getting
confused about the Carrier Detect signal. Download the file
sfmnuext.zip (SPITFIRE Menu Extension v2.0), and extract the 4 batch
files it contains into the SpitFire directory, overwriting the default
batchfiles included with Spitfire. Then configure SFDOREXT to run
from the main menu (SFMAIN) so that when a user selects the doors
command from the main menu, they will enter the "sfmenu extended"
which allows doors to run without the disconnect issue. There is
separate documentation with sfmnuext.zip that will instruct you on
how to set it up. NetFoss should be set to COM port Mode when running
doors under NetSerial.
Spitfire and the SFmenu Extended is available from the Buffalo Creek
website at https://www.angelfire.com/ia/buffalo/index5.html
____________________________________________________________________________
Synchronet BBS 3.1x USAGE
--------------------------
Synchronet started out as a freeware WWIV clone by Rob Swindell in 1991, and
the following year it became a commercial BBS. By 1995 the internet had killed
off most of the interest in BBSing, and Synchronet was open-sourced in 1997.
In 2000 a Windows version was released, which included its own FOSSIL driver.
Later a Linux version was also released. Many of the remaining sysops made the
switch from their outdated DOS-based software to Synchronet, and it continues
to be the most popular BBS software today.
While Synchronet has its own FOSSIL, NetFoss can be used in its place to
allow DOS doors to run considerably faster, often by a factor of more than 2
to 10 times faster than the internal speed, with lower CPU usage. You can use
NetFoss to run all or just some 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:\netfoss\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 don't 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 latter, 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 third line, as explained earlier in this
document. Instructions can also be found in the NF.BAT.
Be sure to change the Start-up directory to reflect door's location.
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.
____________________________________________________________________________
T.A.G. BBS Usage
----------------
T.A.G. was originally based on WWIV BBS source code, as were its distant
cousins Telegard, Renegade, and Iniquity. T.A.G was first released in
1986 and became fully FidoNet compatible. In 1994 it became the first
elite-scene BBS to support the modern JAM message base format. T.A.G was
developed by a team of coders, including Paul Loeber, Robert Numerick,
Victor Capton, Randy Goebel, Alan Jurison, and Paul Williams. Most of
the users were based in Detroit initially, which is where it started.
The T.A.G coders were in heavy competition with the Telegard coders, and
ideas were often stolen from both sides.
NetFoss was tested with T.A.G. 2.7 with the Y2K maintenance release applied.
Here is how to install it:
1) The T.A.G. Installer requires the following archives:
TAGM27.ZIP, TAGD27.ZIP, TAGS27.ZIP, TAGN26D.ZIP
(the last one is only required for FidoNet Support).
Place these files into a temporary directory, which does not use a
LongFileName (more than 8 characters long). Unzip the TAGS27.ZIP
archive and leave the rest zipped. You will also need to add
PKUNZIP.EXE to this directory.
2) To avoid RunTime Error 200, use PatchCRT to patch INSTALL.EXE.
See http://www.pcmicro.com/elebbs/faq/rte200.html
3) Run INSTALL.EXE to Install T.A.G., and select C:\TAG as the main
BBS directory, and set the COM port as COM1 before selecting
"Start Installation".
4) Once the installation is completed, change to the \TAG directory
unzip the Y2K update (TAGU27D2.ZIP) to replace the TAG.EXE and
TAG.OVR files. Next, run PatchCRT on each of the following files:
TAG.EXE, FINDRIP.EXE, MCONFIG.EXE, and \AFILES\TAGSTR.EXE
5) Run MCONFIG.EXE to setup your sysop password(s), and then select
"Write STATUS.DAT". Next, change to the AFILES directory and run
TAGSTR.EXE to create TAGSTR.DAT.
6) Change back to the \TAG directory and run "TAG.EXE /LOCAL".
From the main screen, press Ctrl-Q for the Sysop Functions Menu.
Then press S for System Configuration. At the ":" prompt enter
the Sysop Password (Which is SYSOP if you didn't change it yet)
and press C for Communications Configuration, then press D to
change the "Use FOSSIL Driver" option to YES, and it will ask
"Do you want to make use of the FOSSIL buffer. Answer YES again.
Next, press Q to return to the System Configuration menu.
7) From the System Configuration, press N for Multi-User Configuration.
Set the following:
A. Multiuser System: YES
B. Network Type: DESQVIEW
C. Multi-user data file path: C:\TAG\DFILES\
DESQview is selected because this will allow T.A.G. to release
inactive timeslices to NetFoss's DESQview Emulator to improve
multitasking performance when running several nodes.
8) In the \TAG directory, create the following 1-line TAG.BAT file:
TAG.EXE CONNECTR=115200 AFTERUSERERR=0
This could have been placed in the Net2BBS.INI Command-line, but
doing so would prevent you from adding your Echomail scanner
to the batch file so it can be told to scan the messagebase when
the ErrorLevel tag.exe returns indicate that the previous user
wrote a message in an echo.
9) In the NetFoss directory, 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. Also, change the directory paths to
netfoss.com and netcom.exe if they are not located in c:\netfoss
Next, edit the Net2BBS.INI to use the following Command-line and
Path:
Command=c:\netfoss\nf.bat /n*N /h*H c:\tag\tag.bat -N*N
StartPath=c:\tag\node*N
10) Unzip TAGD27.ZIP into C:\TAG\DOCS\ and open the MAIN26D.DOC and
go to page 108 to review the Multi-Node setup instructions.
Instead of using their example Blinky directory structure, we
suggest the more logical structure used by most BBS software:
C:\TAG
C:\TAG\NODE1
C:\TAG\NODE1\GFILES\
C:\TAG\NODE2\
C:\TAG\NODE2\GFILES
Copy the STATUS.DAT and all the .BAT files from \TAG to each Node
directory.
11) For maximum file transfer speed, install Public Domain Zmodem
(PD Zmodem) as an external protocol in the BBS. This runs several
times faster than FDSZ.
12) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
Telegard\Renegade BBS Usage
---------------------------
Telegard and Renegade BBS are both very similar because Renegade was
based on an older version of the Telegard source code which in turn was
based on WWIV.
Telegard was started by Carl Mueller in 1986, and after he lost interest
a 12-year-old guy named Eric Oman took over development, and made some
major improvements over the years with the help of a team of programmers
including Martin Pollard. By 1990 Telegard had become the most popular
BBS software in use, but that same year Cott Lang created a Renegade
BBS from the Telegard source code, which overtook Telegard in popularity
just a few years later. By then Eric had lost interest, and Martin headed
the team for a while until it died off completely. Then in 1995 Tim
Strike acquired a copy of the Telegard source code, and made significant
improvements to it from 1996 to 1999. In that same time period Cott Lang
had turned Renegade over to Patrick Spence who worked on it through 1999.
Then it got passed on to Jeff Herrings in 2000 and again got passed on
to T.J. McMillen in 2003.
In 2004 we performed testing to compare Telegard BBS version 3.09G2+SP4
with Renegade 99.044D with the Y2K hotfixes applied, both using NetFoss.
Telegard performed considerably faster than Renegade under Windows and
offered true multi-node support. While Renegade could be run multi-node,
it encountered issues due to dropfiles not being created in separate
directories for each node. In 2013 Rick Parrish created a Win32 port of
Renegade. Since then T.J. McMillen eventually fixed some issues in the
DOS version, and the latest version 1.25 was released on May 16, 2014
which includes NetFoss in the installer.
Here is how to install NetFoss with Telegard or Renegade:
1) Install Telegard or Renegade BBS. If installing Telegard be sure to
also install the Service Pack 4 update, which improves performance
under Windows.
Download Telegard from
https://web.archive.org/web/20140223074737/http://www.telegard.net/
Download Renegade (NetFoss is included) from https://www.rgbbs.info/
2) Create a separate node directory for each node, such as \tg\node1
3) Unzip the NetFoss files into a directory such as c:\netfoss\ and also
unzip the included NET2BBS.ZIP into the same directory.
Copy NETFOSS.DLL into the \windows\system32\ directory.
This can only be done from a Command Prompt which was opened using
"Run As Administrator" (right-click on its icon to select this).
4) 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.
Also, change the directory paths to netfoss.com and netcom.exe if
NetFoss is not located in c:\netfoss\
5) Configure your telnet server with the proper Command-line to spawn
when an incoming telnet connection is received.
If you are using the included Net2BBS Telnet Server, then edit your
Net2BBS.INI file to use a Command-line like this:
For Telegard:
Command=c:\netfoss\nf.bat /n*N /h*H c:\tg\telegard.exe -B115200 -Q -N*N
For Renegade:
Command=c:\netfoss\nf.bat /n*N /h*H c:\rg\renegade.exe -B115200 -Q -N*N
The -B115200 switch tells Telegard or Renegade to assume that the user
is already connected to the modem at that Baud rate.
The -Q switch tells Telegard/Renegade to exit after the caller logs off.
The -N switch passes the node number, since *N is replaced with the
node number by Net2BBS when the Command-line is spawned.
Also, edit the StartPath line of your Net2BBS.INI file to start the BBS
session in the correct directory. Since Telegard supports multiple
nodes properly, it should be started from the current node directory.
However, Renegade lacks proper multi-node support, so it will need to
be started from the main BBS directory.
For Telegard:
StartPath=c:\tg\node*N
For Renegade:
StartPath=c:\rg\node*N (for v1.25)
older versions used StartPath=c:\rg
6) For maximum file transfer speed, install Public Domain Zmodem
(PD Zmodem) as an external protocol in the BBS. This runs several
times faster than FDSZ.
7) If you need Telegard/Renegade to run an external program after each
caller logs off (such as a mail tosser/scanner to export Echomail for
example), then it would be better to have the telnet server spawn a
batch file instead of the BBS executable, and the batch file would
then spawn the BBS (passing any variables in %1 %2 %3 etc.) and could
then spawn an external program after the user logs off.
8) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
Virtual Advanced BBS Usage
--------------------------
Virtual Advanced BBS was the successor to Virtual BBS, a WWIV clone
developed by Roland De Graaf in 1990. Roland released the final version
of Virtual Advanced in 1997, along with VISK, the Virtual Internet Survival
kit which included an SMTP/POP3/NNTP/IRC and web server for Windows.
In 2002 Steve Winn of Aspect Technologies created a PHP based front-end
to access a Virtual Advanced over the web, and John Tipton created
a telnet server in Visual BASIC called VA32 which Steve rewrote from scratch
and enhanced over the years, as well as maintaining many other VA tools.
NetFoss is included with Virtual Advanced BBS, as part of the VADV32
package available from https://www.vadvbbs.com/
____________________________________________________________________________
Wildcat! BBS Usage
-----------------
WildCat! BBS was initially developed in 1986 for DOS by Mustang Software,
and later it was ported to Windows to support several internet functions
under the WinServer name. In 1998 Mustang shut down and sold the rights
to Hector Santos at Santronics Software.
WinServer includes an internal FOSSIL driver and telnet server, which
does not allow passing the socket handle to a door, thus preventing it
from being able to be used with NetFoss to run FOSSIL based doors more
efficiently.
However, NetFoss is fully compatible with Wildcat! version 4.20 for DOS,
allowing doors to run considerably faster than the WinServer does.
Wildcat! 4.20 itself also performs extremely fast under Windows when using
NetFoss.
Here is how to configure Wildcat! 4.20 with NetFoss. You can use any
NTVDM compatible version of 32-bit Windows (10/8/7/Vista/XP,2K) or
Windows Server.
1) Extract the Wildcat! 4.20 files to c:\wildcat
and extract Wildcat! 4.20 Y2K Update Fix to the same directory.
Extract the NetFoss/Net2BBS files to c:\netfoss
2) Download PatchCRT.exe, which is used to fix the "Runtime Error 200"
which older DOS programs often encounter under faster CPUs.
Run "PATCHCRT " on each of the following files in the
Wildcat folder:
CHKCONF.EXE, DOORTEST.EXE, MAKEECHO.EXE, MAKEMENU.EXE, MAKEQUES.EXE,
MAKEWILD.EXE, TNETCONV.EXE, UTIEXPRT.EXE, UTIHIGH.EXE, UTIIMPRT.EXE,
UTILIST.EXE, UTIVER.EXE, WCCHAT.EXE, WCDIAL.EXE, WCDRAW.EXE,
WCECHO.EXE, WCFILE.EXE, WCMAIL.EXE, WCMODEM.EXE, WCNODE.EXE,
WCPACK.EXE, WCPACKX.EXE, WCPROMPT.EXE, WCREPAIR.EXE, WCWAIT.EXE,
and most importantly: WILDCAT.EXE
3) Once the files have been patched, run MAKEWILD, and from the MAIN menu,
select "Modem Settings". From there, change the "Type of Serial Port" to
"FOSSIL DRIVER".
4) Create a batch file named RUNWILD.BAT located in c:\wildcat\ with the
following lines:
set WCNODEID=%1
set NODEPATH=c:\wildcat\wcwork\node%1
cd\wildcat
wildcat.exe /B 57600 CID: %2
5) In the NetFoss directory, copy NET2BBS.SAMPLE.INI to NET2BBS.INI
and edit the following 2 lines:
Command=c:\netfoss\nf.bat /n*N /h*H c:\wildcat\runwild.bat *N *I
StartPath=c:\wildcat\wcwork\node*N
6) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
WWIV BBS Usage
--------------
WWIV was initially a custom-made BBS that Wayne Bell created for his own
use in 1984. Wayne originally wrote WWIV in BASIC and then ported it to
Turbo Pascal and released the source code so other Sysops could customize
and improve it. It was the first BBS to allow running external doors, which
he called chains. Wayne later ported it to C++. WWIV became very popular in
the piracy/cracking scene, and its source code distribution resulted in
several other scene based BBS programs being developed over the years.
Eventually WWIV was sold to Dean Nash, who released several versions before
before RushFan ported it to Windows and Linux.
WWIV 5.70 (Windows)
====================
WWIV BBS 5.x for Win32 was open-sourced in 2004, and includes a modified
version of the Synchronet FOSSIL driver to run doors, and a modified version
of the EleBBS telnet server to accept connections. It has also been ported
to Linux (32/64 bit).
Some WWIV5 Sysops prefer to use Net2BBS as the telent server, which can
be done by configuring the following two lines in the NET2BBS.INI file:
Command=c:\WWIV\BBS.EXE -XT -H*H -N*N
StartPath=C:\WWIV
You can optionally change the StartPath to go to the node directory:
StartPath=C:\WWIV\temp\*N
WWIV 4.30 (DOS)
===============
WWIV 4.30 appears to be the final DOS version of WWIV, and can be found
on MAMONT by searching for WWIV430.ZIP. This is the only version of
WWIV known to support a FOSSIL driver. Here's how to configure it:
1) Extract WWIV430.ZIP to c:\WWIV, and NetFoss to c:\NETFOSS
Also, extract NET2BBS.ZIP to the C:\NETFOSS
2) In the NetFoss directory, rename NET2BBS.SAMPLE.INI to NET2BBS.INI
and edit these two lines:
Command=C:\netfoss\nf.bat /n*N /h*H C:\WWIV\bbs.exe *N *I
StartPath=C:\WWIV\
3) In the same directory, edit NF.BAT to include a %1 at the end of
the first line like so:
c:\netfoss\netfoss.com %1
4) In the WWIV directory, create a BBS.BAT file which contains the
following lines:
SET WWIV_INSTANCE=%1
BBS.EXE /B115200 /N0 /O
5) Run NET2BBS.EXE, and it is ready to accept telnet connections.
____________________________________________________________________________
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 acquired the source code and rights
to Doorway for an undisclosed sum, in an effort to revive this product.
https://pcmicro.com/doorway
The PC Micro updates to Doorway provide considerably faster FOSSIL support.
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
The "SYSF" parameter tells Doorway to read the DOOR.SYS drop file, and
also to use the Fossil driver. (So be sure to include the "F").
If DOORWAY.EXE is not in the PATH, you should add the full path to its
location in, such as c:\bbs\doorway\doorway.exe {other parameters 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
---------------
When using NetFoss in "Telnet mode", it is best to set up all nodes to use
the same COM port, as NetFoss ignores the COM port value in this mode.
This is because several FOSSIL aware doors only work on COM1 thru COM4,
while others support up to COM9 or even COM255.
When using NetFoss in "COM port mode", each node must use a unique COM
port value.
Very old DOS doors from the 1980s do not support a Fossil driver, but
those that support BIOS or DOS Input/Output hooks rather then direct
screen writes can still be used in Telnet mode by following the section
called "DOS I/O Redirect" in this guide.
Notes on specific BBS doors:
============================
There are hundreds of BBS doors, but the few listed below are ones that
are rather difficult to install.
* 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. Or virtual COM port(s) (COM1 - COM4 only).
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
This door typically runs very slowly using a fossil driver, but
The final version 4.3a runs very fast under NetFoss due to NTVDM
performance enhancements that NetFoss provides.
* BBS Crash
Version 5.50 and 5.60 do not support a FOSSIL driver even though
they claim to. Version 5.10 and earlier do support a FOSSIL driver.
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 attempts to communicate with one.
* Fresh Water Fishing
FWF always worked under XP, but previously failed to 'reel in' under
Windows Vista and later versions of Windows with older versions of
NetFoss. The issue was worked around in later versions of NetFoss.
* NetRunner
This classic door has a legal key generator (NETRUNKG.ZIP) released
by the author Rob Jacob in 2004 which is available from BBS Archives.
The doorkit that NetRunner was built with uses an undocumented method
of enabling fossil support, by specifying "PORT:F:x" where x is the
COM port number to be used. This method also works on other doors
that use the "CKit Door Library".
Here is an example batch file for using a fossil on COM1:
cd \bbs\netrun
netrun.exe C:\bbs\node1\DOOR.SYS PORT:F:1
* Caribbean Contraband
This door also uses the "CKit Door Library" so you will need the
undocumented "PORT:F:x" where x is the COM port number to be used.
Here is an example batch file for using a fossil on COM1:
cd \bbs\carib
carib28.exe C:\bbs\node1\DOOR.SYS PORT:F:1
* PrimeBase Doors
The PrimeBase Doors use the DOORFRAME library, which requires that the
/FD parameter is added to the end of the door Command-line.
* UltraSoft Doors
The UltraSoft action Doors from Steve Hansen of Hawaii do not support
a Fossil driver, but they work great with NetFoss using DOS I/O mode.
Steve released several great doors including: Indy Speedway, Saratoga
Raceway, AHRA Pro Drags, Top Rank Boxing, Animated BackGammon, Ultimate
Acey Deucy, all of which support ANSI sound and graphics.
You will need to use a dropfile converter (such as NFU) to change the
COM port to "COM0" in the door.sys or other file which the game reads
at startup, and you will also have to edit the door's startup batch
file to temporarily switch NetFoss.com into DOS I/O mode before the
door runs, and then switch it back to Fossil mode after the door exits.
See the "DOS I/O" section of this documentation below for details.
*Yankees and Rednecks
Yankees and Rednecks claims that it should auto detect a fossil driver,
which is not true. You will need to add " F+" after the drop file in
the Command-line, like so: yankred.exe /F=c:\path_to\door.sys F+
* Yankee Trader
This was an early TradeWars clone based on the TradeWars2 source,
written in Visual BASIC. It was known to be unstable and it never
supported a fossil driver or standard (DOS) I/O mode so it is one
of the few doors that won't run with NetFoss except under Doorway.
Better Alternatives include TradeWars 2002, Ultimate Universe,
and Galatic Warzone.
* Solar Realms Elite
SRE suffers a minor Y2K bug which causes the "Reset Game" function to
fail. In order to properly reset the game you will need to set the date
of your PC back to 1999 or earlier, then run "SRE RESET" and you can
set the correct date again. Then run "SRE LOCAL" and select "Visit the
Galaxy", which will display "Running hourly maintenance" for a long
period of time due to calculating for every hour since 1999. It could
take an hour to complete so just let it run. Next, edit RESOURCE.DAT
to make sure that "System.Fossil yes" is set.
* Starship Galactica
This classic door game for WWIV is now freeware. John Dailey never
added support for modern BBS dropfiles or fossil driver support, so its
a bit complicated to get it to run with other BBS software.
Download version 1.1 from JohnDaileySoftware.com, and create a batch file
such as this to run it using Doorway:
@ECHO Off
\netfoss\nfu c:\path_to_chain.txt /C /L
copy c:\path_to_chain.txt\chain.txt \doors\starship
cd\doors\starship
C:\doorway\doorway SYSF /V:D /P:C:\doors\starship\starship.exe chain.txt
erase chain.txt
This batch file does the following: Using NFU, the door.sys dropfile is
converted to a WWIV style chain.txt dropfile, with a "local mode" setting
so the COM port is set to COM0 and the baud rate is zero. Next, the chain.txt
dropfile is copied to the starship folder, and then Doorway is used to run
the door using SYSF mode, which tells Doorway to read the door.sys drop file
and to communicate using a Fossil driver, while it runs the door and passes
it the chain.txt drop file that NFU created. Once the door exits, the batch
file erases the chain.txt dropfile which is no longer needed.
* Murder Motel
Murder Motel was ported to the PC by Sheldon Pasciak in the late 80s
and in 1993 it was taken over by Chuck Valecek. Version 4.4 is said
to be the least buggy. Versions 4.1 and later claim to support a Fossil
but in fact they never attempt to communicate with NetFoss or any other
Fossil for that matter. However, all versions work with NetFoss by
using DOS/IO mode. X-bit released a free key generator in a file named
mmfree.zip.
* FoodFite 2.0
The original FoodFite 2.0 by Rigor Mortis was a WWIV specific door
that only supports DOS I/O communications. This runs great with
NetFoss using DOS I/O Mode, as described in the "DOS I/O Redirection"
section of this documentation.
In the 1990s Michael Wilson released rewrite which supports a Fossil
and in 2004 Chris Martino also released a rewrite called FoodFite 2004
which also has Fossil support.
* ZChess 1.8F
ZChess is known to generate high CPU usage when run under Windows.
In the ZCHESS.CFG file, the option "Give up time slice" should be set
to "=1" and it will greatly reduce the issue under NetFoss. With many
other FOSSIL drivers ZChess creates 100% CPU usage under Windows.
* Chess Magic
Chess Magic claims to support a fossil driver by passing a parameter
such as PORT:F:2 (for Fossil on COM2) after passing the dropfile
directory/filename in the cmagic.bat file, but due to bugs in the
game it will use a mixture of both Fossil and Serial commands so it
will only work properly if running NetFoss under NetSerial, or running
the door in local mode under Doorway. Tested with v4.96 and v4.16.
If you encounter any doors that claim to support a FOSSIL driver
but fail to work with NetFoss, please email support@pcmicro.com.
____________________________________________________________________________
ANSI.COM Usage
---------------
ANSI.COM is an ANSI.SYS compatible emulation driver, that some older
DOS BBS programs and doors needed in order to display ANSI graphics
and colors locally (for the sysop to see). An ANSI driver is only
beneficial when using DOS programs that send ANSI escape sequences
to the DOS output hook. By the early 1990s most DOS console programs
used direct screen writes with internal ANSI graphic support, and
these later programs do not require an ANSI.SYS/COM type of driver,
though a few doors continued to require them into the mid to late 90s.
ANSI.COM should be loaded by NF.BAT before NETFOSS.COM is loaded.
ANSI.COM (like NETFOSS.COM( is a TSR (Terminate and Stay Resident).
To uninstall ANSI.COM from memory, run ANSI.COM /U
____________________________________________________________________________
NETFOSS.COM Command-line Parameters:
====================================
/N{value} Set node number
/C{value} Set COM port mode (this disables Telnet mode)
/L{value} Set locked baud (only use if COM port mode is set)
/S{value} Slow char output (1=slowest, 6000=fastest, default=512)
/T{value} I/O timeout minutes {used with /I to limit duration of door)
/K{value} Keyboard Poll Tweak (1=slowest, 6000=fastest, default=1200)
/Z{value} PD Zmodem Tweak (speed of block transfers default=175)
/D{value} DESQview timeslice (value 1-255, 1=yield most) default=10)
/D0 DESQview ts disable
/R Allow COM release (when FOSSIL is told to Deinitialize)
/X X00 status enable (same as /X1 - default:disabled)
/X0 X00 status disable (turns the X00 status mode off)
/I DOS I/O redirect (turns on I/O redirection mode)
/I0 DOS I/O disable (turns off I/O redirection mode)
/M Modify Mode (To update settings while Fossil active)
/MR Restore defaults (To undo previously modified settings)
/U Uninstall
/N{value} - Set Node Number
---------------------------
This parameter is required when creating a new node session. The Node value
must be a number between 1 and 65. (If using Net2BBS, between 1 and 255).
A Node is a separate process of the BBS software in which a user/client can
connect to (through a phone line and modem, or a TCP connection).
/C{value} - Set 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
dial-up BBS, or with Virtual Modems/Virtual COM ports such as NetSerial.
COM port Mode can only be set when creating a node.
Example: NETFOSS.COM /N1 /C1 This tells NetFoss to create Node1 using COM1.
See the "COM port Mode" chapter below for more details.
/L{value} - Set Locked COM Port Baud
-------------------------------------
This optional parameter is only available when COM port mode is set.
If /L is specified without a value, the Baud rate is locked at 115200.
If /L is not specified, the Baud rate is not locked.
Some BBS Software, such as EzyCom, requires using a slower baud rate of
57600, 38400 or even 19200 baud in order to function.
Example: NETFOSS.COM /N1 /C1 /L57600
This creates Node 1 using COM port Mode on COM1 locked at 57600 baud.
Any application that requests to change the baud rate will be denied.
************************************************************************
* The following optional tweaking commands allow fine tuning NetFoss's *
* performance for optimum display speed and/or optimum CPU overhead. *
************************************************************************
/S{slow: characters output before sleep}
/K{Keyboard polls before sleep}
/Z{Blocks output before sleep (for PD Zmodem)}
/D{DESQview timeslice setting}
/S{value} Slow character output (default=512)
------------------------------------------------
NetFoss allows the character output speed to be slowed down by passing
the optional /S parameter along with a value between 1 and 65000.
Example NETFOSS.COM /M /S20
The lower the number, the slower the character output speed will be.
This is _not_ the same as a Baud Rate. The value is the number of
characters which will be output before a Sleep occurs to lower the
CPU usage.
Without this parameter, NetFoss displays at a very high speed, which
in some cases can causes ANSI-Animation sequences to be displayed much
faster than they were intended to. In most cases, the default speed is
recommended.
Note that this only adjusts the speed that the fossil character output
functions use. Some BBS or door programs send output using the more
efficient "Block Write" function , which sendsseveral characters at
a time. In order to slow output of these programs, the /Z{value}
parameter must be used.
/K{value} Keyboard Polls Tweak (default=1200)
------------------------------------------------
DOS applications can overload the CPU usage by constantly polling
the Keyboard status to see if a key has been pressed. The optional
/P parameter can adjust the number of Keyboard Status polls that can
be made before a Sleep occurs to lower CPU usage.
The lower the value, the more often the Sleep will occur, resulting
in lower CPU usage and less responsiveness and performance.
In most cases, the default settings is recommended.
/Z{value} PD Zmodem Tweak (default=175)
--------------------------------------------
This optional parameter tunes the PD Zmodem file transfer performance.
PD Zmodem uses block reads/writes rather than transferring one character
at a time, so the optional /Z parameter allows tuning the Zmodem speed.
/Setting this value too high will overload the CPU usage, causing the
transfer to slow down. Setting it too low will cause excessive Sleeps
resulting in very low CPU usage and slow transfers. While the default
setting should work in most cases, tuning this while testing over an
internet connection can dramatically improve file transfer performance.
See PD Zmodem Chapter below for more info.
/D{value} DESQview timeslice (default=100)
-----------------------------
This optional parameter tunes the DESQview timeslice release feature.
DESQview was a DOS Multitasker, which allowed multiple DOS Windows to
run concurrently (much like Windows does).
DOS applications which are DESQview aware can send a command to tell
DESQview to release the remaining timeslice to the other DV Windows.
NetFoss can capture these timeslice release commands, and redirect them
to Windows. This parameter fine tune this feature, or disables it when
set to Zero. The lower the number, the longer period it will Sleep for
when the timeslice command is received. The default setting may cause
some applications to over-sleep (causing a slower than possible output).
Passing the /D0 parameter disables this feature entirely.
************************************************************************
/R - COM Port Release
---------------------
The optional /R parameter is only available when setting COM Port Mode,
which causes NetFoss to release the COM port after it receives a
"Deinitialize Port" FOSSIL command from the application. It will then
open it again when it receives an "Initialize Port" FOSSIL command.
By default, NetFoss 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.
/X /X0 - X00 Kluge (Default is disabled)
------------------
NetFoss always supports the extended X00 FOSSIL commands above AH=1Bh
regardless of this setting. The /X or /X0 parameter controls how the
FOSSIL command 02h (Receive character with wait) returns its results.
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 code
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 than zero.
To enable this X00 compatibility kluge, one way is to edit your NF.BAT
batch file to add an /x parameter, like this:
@echo off
rem place optional ansi.com driver here
c:\bbs\netfoss.com /n%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 using a DOS-based BBS, a better method is to turn on the /x mode
just before running a door that requires it, and then turn it off again
after the door exits by adding two "netfoss.com /m" Command-lines to
your door batch file, as shown in the example below:
cd\bbs\doors\example\ <-- This changes to the door dir
c:\bbs\netfoss.com /m /x <-- This enables X00 compatible mode
doorgame.exe /N%1 <-- This runs the door
c:\bbs\netfoss.com /m /x0 <-- This disables the X00 compatible mode
When /x is not present on the netfoss.com Command-line, then the FOSSIL
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}
/M Modify Mode (Updates settings while Fossil active)
--------------------------------------------------------------
The /M parameter tells NetFoss to modify the currently active FOSSIL node
with the additional parameters specified.
Do not include the /N{node number} parameter when using the /M
Example: To slow down the display speed only for one door, add the following
Command-line to the beginning of the door's batch file:
\path_to_netfoss\netfoss.com /m /s20
and after the door exits, restore it back to normal speed:
\path_to_netfoss\netfoss.com /mr
If /M is _not_ included on the Command-line, then NETFOSS.COM will either
attempt to install a new node, or (if /U is used), uninstall an existing node.
/MR Restore Defaults (To undo previously modified settings)
-------------------------------------------------------------
This parameter will revert all settings back to their default values,
useful after using the /M parameter to modify some of the settings.
/I /I0 - DOS I/O Redirect
-------------------------
This feature allows NetFoss to support many early DOS doors that did not
support a fossil driver.
In the 1980s a number of early DOS Doors were written specifically for
WWIV BBS which were designed to use DOS Input/Output redirection rather
than using a FOSSIL driver. WWIV would then echo the I/O to and from the
modem. These doors can run under NetFoss by enabling DOS I/O mode in
NetFoss.com just prior to running the door. WWIV doors typically used a
dropfile called CHAIN.TXT which can be created from a DOOR.SYS dropfile
by using NFU: NFU.EXE {path to door.sys} /C
NFU will then create a CHAIN.TXT in the same directory where DOOR.SYS is.
For example: NFU c:\pcboard\node1\ /C
A number of other 1980s doors designed for various other BBS software also
did not support a fossil driver, and only worked with serial port modems.
Any door that The uses DOS I/O for the local input/output can work with
NetFoss by running the door in local mode, and enabling DOS I/O mode in
NetFoss just before the door is executed, and disabling it afterwards.
NetFoss's DOS I/O mode can also be used to redirect non-door DOS programs
that use DOS Input/Output to the tcp connection as if they were BBS doors.
Keep in mind that most DOS programs written after the early 1990s used
direct screen writes, rather than using the slower DOS I/O hooks. To
redirect those types of non-fossil-aware programs, a program called Doorway
can be used. Doorway is a commercial product developed by PC Micro, and is
priced at $20. See http://pcmicro.com/doorway
Earlier versions of NetFoss allowed a companion external utility called
ANSI2FOS to redirect DOS programs which support DOS Input/Output hooks to
the NetFoss driver. This is now internally built into NetFoss, which results
in increased speed and performance of such applications.
Most DOS programs that support DOS I/O require an ANSI driver in order to
to display text in color on the local (BBS) side. NetFoss includes such a
driver, named ANSI.COM when can be loaded into memory in NF.BAT. Another
ANSI driver that can be used is micro-ANSI (µANSI) by David Nugent and
Unique Computing Pty Ltd, available at http://pcmicro.com/mansi10.zip
Both versions of ANSI.COM use 31.8K of conventional DOS memory.
** Important *************************************************************
In order for NetFoss's DOS I/O redirection to work, you must not load any
TSR which changes the DOS I/O hooks after NetFoss is loaded.
If you wish to load an ANSI driver (such as ANSI.COM), it should be loaded
in NF.BAT _BEFORE_ NetFoss.com is loaded (except when using NTVDMx64).
**************************************************************************
By default DOS I/O mode is disabled to avoid conflicts with fossil-aware
BBS software and doors. To run a non-fossil aware I/O compliant DOS
program as if it was a BBS door from a DOS-based BBS, you must enable the
DOS I/O mode by running netfoss.com again in the door batch file using both
the /M and /I parameters, (and optionally the /T parameter) before running
the door, and then disabling the I/O mode before returning to the DOS BBS.
Below is an example batch file to run Infocom's ZORK 1 adventure game as a
door. Since this example is not an actual door, no dropfile or node number
is provided by the batch file. Instead the batch file can optionally pass
the number of remaining minutes that the current user has for this session
to NetFoss, using the /Txx parameter combined with the /M (Modify settings):
ZORK1.BAT:
@echo off
cd\bbs\zork1
\netfoss\netfoss.com /m /i /t%1
_zork1.com
\netfoss\netfoss.com /m /i0
The "/t%1" parameter is optional, which passes NetFoss the number of minutes
remaining so that NetFoss will closes the DOS application once the time has
expired. If this parameter is omitted, the user can have an unlimited amount
of time in the door. You can only use /t%1 if your BBS program allows passing
the number of minutes remaining to a door's batch file. In this example %1
represents the first Command-line parameter being passed from the BBS to the
doors batch file.
The BBS's door Command-line should look something like this:
c:\doors\zork1\zork1.bat *T
See the /T section below for an example Command-line using RemoteAccess BBS.
It's recommended to include "@echo off" as the first line of the batch file,
to avoid the batch commands from being redirected to the client's terminal
as they are executed.
Download the freeware ZORK trilogy text adventure games - ZORK I, II, and III
directly from the InfoCom Interactive Fiction website at:
http://www.infocom-if.org/downloads/downloads.html
While Infocom created over 30 text adventure games during the golden age of
Interactive Fiction in the 1980s, there are now thousands of Interactive
Fiction titles available on the web at IFDB.tads.org and elsewhere which use
Infocom's Z-Machine interpreter.
Below is an example of how to run a DOS Door which only supports DOS I/O hooks.
This game is NecroBone's 'Acheron Abyss' which can be downloaded from:
http://necrobones.com/games/games2.shtml
ABYSS.BAT:
@echo off
cd\bbs\acheron
c:\netfoss\netfoss.com /m /i /t%1
abyss.exe
c:\netfoss\netfoss.com /m /i0
While 'Acheron Abyss' was designed to run from a BBS as a Door, it does
not appear to support any BBS dropfiles, and instead asks the new user to
to select a name and password to use for the door. Therefore the /T
parameter should be used to pass the time remaining, as described below.
/T{value} I/O timeout minutes {Default: disabled)
------------------------------
Since only standard doors limit the time the door can be run based on
the users time remaining, this parameter allows passing the users
"minutes remaining" to NetFoss, so that NetFoss can force a non-door
DOS program to close when their time limit is up. This feature only
works when DOS I/O redirection is enabled.
For example, RemoteAccess BBS (RA) uses the *T macro to pass the time
remaining time (in minutes) to a door on the door's Command-line like so:
*C /c c:\bbs\acheron\abyss.bat *T *M
Not all BBS software uses the *T Macro to pass the time remaining, so
consult your BBS program documentation to find the correct macro to use.
Note: the "*C /c" in the above Command-line is always needed for RA to
run a door, and the *M" simply tells RA to swap itself out of memory,
to allow a door to run with as much available memory as possible.
In order to pass the "minutes remaining" value to NetFoss, the line in the
batch file that enables DOS I/O mode needs to pass this value immediately
after the "/T" is value like so:
c:\netfoss\netfoss.com /m /i /t%1
The %1 macro represents the first Command-line parameter that was passed
to the batch file, which in this case was the *T macro.
So if the user has 10 minutes remaining when the door is started, RA
converts the *T to "10" and passes that as the first parameter to the
batch file, so the "/t%1" is converted to "/t10", telling NetFoss to
only allow the DOS I/O program to run for 10 minutes (or until the user
disconnects, which ever occurs first).
The next line in the batch file runs the DOS program as a door, and once
the door exits back to the batch file, the final line tells NetFoss to
disable the DOS I/O mode before returning to the BBS.
Below is an example of running a DOS door which only supports serial
communications, but it does display locally using DOS I/O.
In order to make it work, the door must be run in local mode, which is
usually accomplished by adjusting the dropfile information to use COM0
instead of a valid COM port such as COM1 or COM2, and/or by adjusting
the users baud rate in the dropfile to zero (0).
This game is DOOR ADVENTURE (originally known as Colossal Cave).
which can be downloaded from:
ftp://archives.thebbs.org/door_games/doors_d-f/doradvnt.zip
ADVENT.BAT:
@echo off
cd\bbs\doradvnt
c:\bbs\nfu c:\bbs\node1\ /L
c:\netfoss\netfoss.com /m /i /t%1
doradvnt.exe c:\bbs\node1\door.sys
c:\netfoss\netfoss.com /m /i0
This door supports several dropfile types including DOOR.SYS, so NFU is
given the path where the DOOR.SYS drop file is located along with the /L
parameter, which tells it to modify the COM port value in DOOR.SYS to
"COM0" and the baud rate value in DOOR.SYS to "0" so that the door will
run in local mode.
Some doors allow being forced into local mode with a Command-line parameter,
rather than having to change the values in the dropfile, but this one does
not.
After the door has executed, netfoss.com is called again with /M /I0 which
tells NetFoss to modify its current configuration to turn off I/O mode, so
that when the batch file exists the DOS-based BBS will be using NetFoss in
fossil mode.
Note: if you are using a Windows BBS, then it is not necessary to disable
the DOS I/O mode before returning to the BBS since NetFoss is then
uninstalled. You could even copy NF.BAT to a different named batch file
and add the /I1 parameter on the netfoss.com Command-line in the new
batch file, rather then having to call netfoss.com a second time with the
/M /I1 parameters
____________________________________________________________________________
Using 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
dial-up BBS, or it can be used with Virtual Modems such as NetSerial.
BBS Sysops can purchase NetSerial at a special sysop price of $25 at
https://pcmicro.com/netserial/sysop
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 needed.
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 (though not suggested) to use the NF.BAT file when
using NetFoss in COM port mode. To do so, some changes would need to be
made 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, because NETCOM.EXE not required in
order for NetFoss to function in COM Port Mode. NETCOM only handles
telnet communication when NetFoss has COM port mode turned off, in
which case a Virtual COM port could then redirect the data to its
own telnet driver. 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 much as the batch "call" command does.
NETFOSS.COM will automatically enable COM port mode if it finds a
DOOR32.SYS drop file in the current directory which is configured for
COM port mode.
Please note that if the /C parameter is passed to NETFOSS.COM, this
effectively 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 (Terminate and Stay Resident) driver.
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 so:
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.
Some BBS software requires a special character at the end of an AT
command, to signify a carriage return character.
NetSerial can create up to 256 Virtual Modems.
Each Virtual Modem can be controlled by NetFoss in a separate node.
Virtual Modems do not require Windows modem drivers to work with NetFoss
and DOS-based applications including BBS programs.
____________________________________________________________________________
Security and AV Software
------------------------
Over the decades, a few poorly designed heuristic AV Scanners have reported
"False-Positive" results on NetFoss executable files, with labels such as
Evo-Generic/Suspicious, simply because they see unusually small files
written in Assembly Language which perform TCP/IP socket functions and spawn
other software. When a new version is released, we've often had to report
such false-positives to Avast to be added to their F.P. white-list.
If you have concerns about such false positives, use an online multi-AV
scanner such as http://virustotal.com and you will find that all the non-
heuristic AV scanners such as Kaspersky, Symantec, AVG, ESET, and dozens
of others give it a clean bill of health.
In 2017, Microsoft Defender started generating "False-Positive" on both
NETCOM.EXE and NET2BBS.EXE, so these two files now include embedded
Code-Signing Certificates that give these files credibility with Microsoft.
As a result these files are considerably larger in size, yet still use very
little memory when executed.
In 2020, Microsoft Defender started generating "False-Positive" on
NET2MON.EXE, and we have opened a case with Microsoft to resolve it.
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. Often such software
has an option to add an exclusion to allow your telnet server to do this.
ZoneAlarm Security Suite will not allow exclusions to be defined, so it
must be uninstalled.
Windows Server 2003 and later will fail 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 using NetFoss 0.93.
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
Zmodem speeds were further enhanced in later versions. NetFoss 1.01
will transfer at 450,000 CPS using PD Zmodem on a P4 2.0Ghz PC, and
by adjusting the /z parameter in netfoss.com to /z600 it will will
transfer at 1,000,000 CPS on a Core2 Duo 1.8Ghz PC.
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.
The result was 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 receives 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 confirmation from the BBS end acknowledging
that the transfer was completed successfully. 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 required if you define a system
environment variable in Windows as follows:
DSZLOG=DSZ.LOG
When using PD Zmodem with NetFoss running in telnet mode, the COM port
parameter does not need to be specified. COM1 is assumed by default, and
NetFoss ignores the COM port value anyways when running in telnet mode.
The baud rate also does not need to be specified, since PD Zmodem will
default to using the existing baud rate.
____________________________________________________________________________
Optimizing PD Zmodem transfer speeds
------------------------------------
The default settings in NetFoss should allow PD Zmodem transfer speeds
between 300,000 CPS and 450,000 CPS.
You can optimize the PD Zmodem transfer speeds for maximum performance by
using the optional /z{value} parameter, where {value} is a number between
1 and 65000. To adjust this variable, edit your NF.BAT file as such:
netfoss.com %1 /z175 (the %1 is only needed for non-door32 BBS's)
If the /z{value} parameter is omitted, it will use a default of 175.
To find the best setting, you should view the "Performance" tab in the
Windows Task Manager (press Ctl-Alt-Del to open it), and make sure that the
CPU usage is below 5% during a PD Zmodem transfer session. If the CPU usage
is higher, then try again using a lower value. If the CPU usage is near 0%,
then you might be able to get faster transfer speeds with a higher value.
For example, on a Core2 Duo T7100 CPU running 1.8Ghz, the default setting
allows PD Zmodem transfers at about 300,000 CPS, but by adjusting the
speed variable to /z600, it will allow transfer speeds over 1,000,000 CPS.
____________________________________________________________________________
NetCom.exe optional Command-line switches:
------------------------------------------
NetCom should be passed the Command-line for the external DOS program
that it should spawn, and the following Command-line switches are available.
The switches must be passed before the external Command-line.
/N{node} The Node number of the current session. This is only
required if a door32.sys file is not provided.
/H{handle} The telnet handle of the session. This value is obtained
by the telnet server that accepted the telnet session.
This is only required if a door32.sys file is not provided.
/C{COM port} This informs NetCom that NetFoss is running in COM port
mode, so NetCom will not perform any telnet communications
as COM port communications are handled by NetFoss.dll.
This simply makes NetCom idle after shelling to the
external application, as if it was running in local mode.
The COM port value passed is ignored.
/D{Write Delay} When NetCom receives data from the external application,
it waits a while for additional data to be received before
it sends a packet to the remote telnet user. This value
specifies the maximum time to wait since the first data was
received. The default is 50. (50ms)
/B{Buffer Maximum} The maximum amount of data to buffer before sending as
a packet to the user. Once this value is reached, the
data is sent without waiting for the delay periods. The
default is 1250.
/S{ignored} This was used in early versions of NetCom.
____________________________________________________________________________
NetCom.ini optional configuration settings:
-------------------------------------------
NetCom.exe will look for a NetCom.ini file in the same directory, and if it
exists then the following settings will read from it:
[Settings]
Non-Blocking=1
ForceClose=5000
WriteDelay=50
BufferMax=1680
*******************************************************************************
Non-Blocking={value} : This value must be 0,1, or 2.
0 = Enable Blocking Sockets
1 = Enable Non-Blocking Sockets
2 = Leave current Socket settings
Windows supports Blocking and Non-Blocking sockets. Non-Blocking sockets
are faster, and therefore NetCom will enable Non-Blocking sockets by default
if this setting is not defined in NetCom.ini. When this value is set to 2, it
will be up to the telnet server to determine which socket mode is used. The
Net2BBS telnet server will always set the socketz to Non-Blocking mode before
spawning NetFoss.
ForceClose={Value} : The number of milliseconds to wait, before forcing a
node's console to close. By default this is disabled,
and you must specify a non-zero value here to enable it.
This value defines how long NetCom should wait for the external application
to terminate, once the telnet connection has been closed. The value is in
milliseconds, so for example ForceClose=5000 would wait 5 seconds for the
application to close on its own once the caller has disconnected. After the
specified time, NetCom will force the application to close.
Note: ForceClose may not work if a batch file is used on the CommandLine
parameter in Net2BBS.ini. It will work if a specific .EXE filename is used.
***************************************************************************
The other settings are identical to their Command-line counterparts, but if
both the Command-line settings and .ini settings are defined, the command
line values will be used.
If NetCom.ini is not found, and no Command-line switches define the Write
Delay and BufferMax settings, then the above defaults are used.
____________________________________________________________________________
Frequently Asked Questions:
---------------------------
Q: Does NetFoss run under Windows 10, 8, 7, Vista, XP, 2000, Server?
A: NetFoss is compatible with all 32-bit versions of Windows NT,
including Windows 10, 8, 7, Vista, XP, 2000 and Windows Server.
When using a version of Windows newer then XP, the NETFOSS.DLL
will need to be copied to c:\windows\system32\
64-bit editions of Windows don't come with NTVDM (Virtual DOS Machine),
so they can not run DOS applications unless you install NTVDMx64 from
a third-party site decribed above.
Q: Does NetFoss run under Windows 3.x, 95, 98, ME?
A: No. These versions of Windows do not offer true multitasking,
resulting in very poor performance for running DOS applications.
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 / INT 14h
communications or support DOS Input/Output redirection NetFoss
can be used. For other applications that communicate only directly
with serial UART hardware, the NetSerial redirector can be used
instead of or in combination with NetFoss.
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 (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 the Net2BBS Telnet Server, and can also be used
with other Windows-based Telnet Servers. NetFoss is also compatible
with modems (either real dial-up modems or virtual modems), 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 Virtual Com ports and
Virtual Modem emulators 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 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 PD Zmodem as an external protocol in the BBS.
Q: Can Net2BBS be run from the System Tray?
A: Yes, by using the freeware TrayIt Utility downloadable from
The NetFoss website
Q: Can Net2BBS be run as a Windows Service?
A: Yes, read the file NET2BBS.TXT for detailed instructions.
Q: Does Net2BBS support SSH encryption?
A: No, but you can use an SSH tunnel such as OpenSSH to accept SSH
connections on one tcp port, that redirect to Net2BBS on port 23.
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 than 25K-40K 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: Does NetFoss work with DOSBox?
A: No. DOSBox does not support the NTVDM, so it is not compatible with
NetFoss.
Q: Can I donate to NetFoss development?
A: NetFoss is freeware so please don't feel obligated to pay for it.
You can show your appreciation by registering our commercial software
such as Doorway and NetSerial, or by providing feedback such as
bug reports or feature suggestions.
____________________________________________________________________________
NETFOSS.COM Error Messages
--------------------------
Node 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.
No node/handle passed
This indicates there was not both a /n{node number} switch and a
/h{socket handle} switch passed from the Command-line, so NetFoss
was expecting to find a DOOR32.SYS in the current directory where
it would obtain these values from.
A DOOR32.SYS file is a "drop file" created by 32-bit BBS programs.
Typically 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 the 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.
Low RAM
This means there was not enough RAM for NetFoss to install itself.
Netfoss.com requires approximately 2k of conventional memory to
install itself, (conventional is memory below 640k) but once it is
installed, it uses less then 1k of conventional memory.
Needs NT
This means an inferior version of Windows has been detected. ;)
NetFoss requires a 32-bit version of Windows 10/8/7/Vista/XP,2K
or Server 2008\2003\2000. Earlier versions of NetFoss also
supported Windows NT4.
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) console 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.
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: Node 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.
This message is shown if the DOOR32.SYS is configured for COM
Port mode, or if a /C{value} parameter was passed to NetFoss,
which causes NetCom to run the external program without a TCP/IP
interface.
Local Mode.
This message is shown 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.
____________________________________________________________________________
How NetFoss Works
-----------------
NETFOSS.COM is a DOS TSR (Terminate and Stay Resident) executable stub
which intercepts specific DOS Interrupt Requests, including:
* FOSSIL Driver requests (all INT14 interrupts).
* Timer Tick chain requests (INT1C interrupts).
* DESQview requests (including INT10, INT15, and INT21 interrupts).
* DOS I/O requests (to support WWIV doors and non-door redirection)
* Other DOS requests (to improve DOS/NTVDM performance).
Many of these interrupt requests are handled within NETFOSS.COM, while
some of the requests (such as read and write FOSSIL functions), are
transferred to NETFOSS.DLL.
NETFOSS.DLL is the NetFoss Win32 Virtual Device Driver, which handles
most of the INT14 requests, including reading/writing characters and
blocks. It also handles all the Serial communications when NetFoss is
configured for COM port mode. By default NetFoss is configured for
telnet mode, in which case NETFOSS.DLL redirects all the data to and
from NetCom.exe using pipes. NetFoss.dll is a shared DLL, so only one
copy of this 6K DLL exists in memory which is shared by all the node
instances.
NetCom.exe is the Win32 Winsock Communications Engine, which handles
the telnet socket I/O for NetFoss.dll. NetCom is given the socket
handle for the active telnet connection, and the path of the DOS
application, which NetCom spawns within the same Console Window that
NetCom is using. While the DOS application is running, NetCom's
background threads are transmitting and receiving data between the
telnet socket and NetFoss.dll.
Net2BBS.exe is a Win32 Telnet Server, which is compatible with NetFoss.
For each incoming telnet connection, it opens a new window and runs
NF.BAT, passing it the name of the DOS application to spawn.
Net2Mon.exe and NetSpy.exe are Monitors, which allow viewing Net2BBS
and every running BBS node under newer versions of Windows while Net2BBS
is running as a service. For more information see Net2BBS.TXT
NetSpy is a DOS terminal redirector for Windows, which allows the sysop
to spy on their users when Net2BBS is running as a service under later
versions of Windows (such as Windows 10/8/7/Vista, or Server 2008).
On older versions of Windows, Net2BBS can run as a service without
needing NetSpy, as Windows XP and Server 2003 allowed services to run
in GUI mode but later versions of Windows require services to be hidden.
NF.BAT is a Batch File for NetFoss, which loads NetFoss.COM (which in
turn loads NetFoss.dll) and then runs NetCom.exe, passing it the telnet
socket handle, and the name of the DOS application to spawn, along with
any optional Command-line parameters.
____________________________________________________________________________
Suggestions for DOS Door/BBS developers
---------------------------------------
If you have written a DOS Door or BBS program, and you want to improve
its performance when running under NetFoss, here are some suggestions:
1) Use Block Write functions, instead of sending one character at a time.
This will considerably improve performance. Keep in mind that your
send routine will need to attempt to send as much as desired to the
FOSSIL, and then check how many bytes the FOSSIL reported actually
sending, and then loop to attempt to send the remainder.
2) Release timeslices to DOS or Windows. During loops where your software
is polling the keyboard and/or the FOSSIL status, make the following
call to tell DOS to release a timeslice to lower CPU usage:
mov ax, 01680h ; INT 2Fh Command 1680h - Release DOS timeslice
int 2Fh
This is not only supported by NetFoss, it is supported by most
Virtual Machine emulators and multitaskers.
3) Avoid using INT 14h calls for maximum speed.
DOS and VM's are slow at processing interrupts, so instead of performing
an INT 14h every time you make a FOSSIL call, you can instead call the
address directly:
mov ax, 3514h ; Command 35h - Request entry point for INT 14h
int 21h ; ES:BX points to int14h handler entry
cmp es:[bx+6], 1954h ; Check for the FOSSIL magic number 1954h
jne noFOSSIL ; Get out of FOSSIL was not detected
mov FOSSIL_ADDR,bx ; Save the FOSSIL entry point
mov FOSSIL_ADDR+2,es ; so it can be called directly from now on.
mov al, 04h ; Send Initialize FOSSIL command
call dword ptr FOSSIL_ADDR ; By calling the address directly
Examples of how to do this with Pascal, C, and BASIC are provided in
the X00 FOSSIL HLLAPI samples by Raymond Gwinn.
____________________________________________________________________________
FOSSIL INT14 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 separate sub directory once
it is installed, 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.
NetSpy 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 was
the author of EleBBS (A RemoteAccess BBS clone) and the EleCom library.
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 NetCom
communication driver.
Another big thanks go to `Hutch' for developing MASM32, the ultimate
Macro Assembler SDK for designing Windows software in ASM, and to
Rob Swindell for information on the C++ Virtual DOS Driver 'BOP' hooks.
Credit also go to several historic FOSSIL implementers, inclulding:
Tom Jennings, Bob Hartman, Vince Perriello, Wynn Wagner, Ray Gwinn,
David Nugent, and Gerhard Wiesing.
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/Manning
Marty Kazmaier aka Surato
Brian Zohu aka Zoob
Michelle Sullivan aka SORBS
Louis Northmore
Corry Snow
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 aka Swinn
John Elite aka Deathr0w
Kin Chang
Ioram Sette
Minh Van Le
Brian Taylor
Rich Ringer aka Pony
T.J. McMillian aka Exodus
Alexey Fayans
Vasya Pupkin aka Burning Shadow
Michael Montague aka Tarix
Markus Feilen
Christian Dirks
Luis Silva
Hawk Hubbard aka Captain Hood
Todd Yatzook aka Maskreet
Rudi Timmermans
Kin Chan
Ruben Figueroa
Jas Hud aka MrO/Chris Cotrell
C.G. Learn
Antonio Rico
Tom Swartz
Joaquim Homrighausen aka JoHo
Manuel Adorni
Rick Szajkowski
Ozz Nixon
Tim Sweitzer
Shane O'Neill
Mike Dietrich
____________________________________________________________________________
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 time-slicing 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 parameters 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. 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 experience 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
than 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 its 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 transfer 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 dial-up 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 dial-up ISP connections, requested by
Minh Van Le.
0.9.6 NetFoss now includes a miniature 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 -
Requested by Xbit. NetCom was adjusted to avoid an
issue under Windows Vista, 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-minimize 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 separate 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.
1.01 After over 2 years since the last update, this version
offers some minor enhancements: Added Stopnode.{node}
semaphore checking to allow an external program or a
batch to stop a BBS telnet session, requested by Steve
Winn. Added an optional /z{value} parameter to tweak
the PD Zmodem transfer speeds. Minor optimizations to
NetCom engine for improved performance. Added *R macro
to Net2BBS spawned Command-line to pass a resolved
hostname to the BBS, requested by Markus Feilen.
1.02 Fixed issue in NetCom 1.01 causing carrier drops with
the latest beta of GameSrv, reported by Rick Parrish.
Added NetCom.ini support for NetCom optional settings.
Fixed Net2BBS to enforce proper exit under Windows 7.
1.03 Fixed issue in NetCom 1.01/1.02 which under specific
conditions could prevent the semaphore thread from
closing, reported by Vasya Pupkin. Switched to using
Pelle Orinius's linker instead of Microsoft's, which
creates even smaller Win32 executables. Fixed issue
in Net2BBS 1.01/1.02 causing the killfile list to be
ignored, Reported by Christian Dirks. Added some new
configuration options to Net2BBS allowing additional
modes for the Console Window view modes, and added
an experimental option to set the number of console
lines to 25 or 50 (or any other value).
1.04 This is the 10 year anniversary edition of NetFoss!
Added /s{speed} Command-line parameter to NETFOSS.COM
which allows NetFoss output to be slowed down.
Net2BBS 1.03 had a bugfix update 1.04b1 shortly after
its release to solve an issue when a users IP address
is sent to their terminal. Since then several minor
optimizations were done in 1.04 and it now features
a Restart command a socket policy server option.
1.05 A minor update to NETCOM.EXE fixes an issue introduced
in version 1.01 that could cause a node to hang if the
connection is immediately terminated. Reported by Luis
Silva. Added an optional parameter 'ForceClose=' to
the NETCOM.INI file, defining how long NETCOM should
wait before forcing termination of a non-responsive
external application after the TCP connection has
disconnected. No changes to NetFoss itself.
1.05A Net2BBS now includes Net2Mon, a Service Monitor which
functions as a desktop GUI when Net2BBS runs as a
service. Net2BBS now supports DNS-Blacklist blocking
of incoming telnet connections. Net2BBS has several
minor enhancements. No changes to NetFoss or NetCom.
To install Net2BBS as a Service from an Administrator
Command Prompt type: Net2Mon /instserv
1.10 This is a major update to NetFoss, which includes
several performance enhancements, and NetFoss now
allows remote keyboard input to be provided by an
external source, such as NetSpy. NetSpy is a DOS
terminal redirector for Windows to allow the sysop
to spy on active BBS nodes while the Telnet Server is
running as a secure Windows service (without desktop
interaction) in newer versions of Windows (Vista and
later). In NetCom, the ForceClose= parameter now
defaults to never forcing a disconnected application
to close (Unless you define it in NETCOM.INI).
1.10A Packaging Error, version 1.10 went out today with
the wrong NETFOSS.DLL :(
1.11 A minor update which fixes a bug in NetFoss 1.10(A),
in which it would report a crash error if it was
uninstalled within a 3 seconds of being installed.
NetFoss now also detects if it is running under
Windows Virtual PC (ie: XP Mode), and if so, the
default parameters are adjusted accordingly.
NetCom now defaults to having the ForceClose option
disabled (since it only works reliably on .EXE files,
and can cause a .BAT file to hang instead of close).
NetSpy.asm is now better documented (Requested by
Steve Winn). Net2BBS now allows Pseudo Node numbers
to be passed to the BBS software. See Net2BBS.txt
for details (Requested by Hawk Hubbard).
1.12 This replaces the buggy NetFoss 1.11 release with
stable code, and includes additional optimizations
for even lower CPU usage with some doors. Added OS/2
timeslice release emulation. Net2BBS has several
enhancements including portscanner detection, a built
in firewall to block unwanted connections, and
support for multiple DNS Blacklists including
Geo-location DNSBL support to block entire countries.
Removed the Virtual-PC and VMware detection - due
to lost source code and because the performance was
still much slower under these environments, especially
when running many nodes simultaneously.
1.12A Fixed issue in NETFOSS.DLL which could cause a hang
only when running in "COM Port Mode" when BBS raises
the DTR signal. Reported by Maskreet.
1.13 Added additional optimizations to NetFoss and changed
NetCom's default timing to provide even lower CPU
usage with most BBS software and doors.
Added Anti-Hammering protection to Net2BBS (requested
by Chris Clark), and doubled the size of the Net2BBS
"Bad IP" Cache. Net2BBS ignores multiple IP limits
(and hammering) when connections are from localhost.
Adjusted bot detection sensitivity (Requested by Tom
Watt).
1.14 2016 marks the 15th Anniversary of NetFoss! Added
support for running Win32 external doors from DOS BBS
software, by using the NFU Utitily which creates a
DOOR32.SYS drop file by reading the information from
a standard DOOR.SYS drop file and including the telnet
socket handle by reading it from the environment
variable named %SOCKET%. See the included NFU.TXT for
detailed information on how to implement this.
Added new options for Net2BBS to Enable/Disable the
Anti-Hammering feature introduced in version 1.13 and
was known to be unstable. Hopefully that issue is now
resolved though just to be safe the Anti-Hammering
feature was disabled by default. Added an option to
disable the Anti-Bot scanning detection (Requested
by C.G. Learn). Net2BBS now writes the socket handle
of a Telnet Connection to the environment variable
%SOCKET% to allow NFU to use it to launch Win32 doors.
NetFoss had some internal changes to allow Win32 doors
to be able to run with the FOSSIL enabled. NetSpy and
NetCom had minor enhancements to the Console Screen
size setting.
1.14R The initial 1.14 release had the old NETFOSS.COM 1.13
and it was corrected the same day in 1.14A, but a few
days later a bug was found in NFU which caused some
DOOR32 doors to fail to work. The fixed NFU was updated
from v0.04 to v1.14, and the other files remain the
same so the second re-release is zipped as v1.14R.
1.15 Fixed bug in Net2BBS which caused the AntiHammer
feature to crash. AntiHammer is now enabled by default.
Fixed an unreported 1.14 bug in NetFoss.DLL which
causes excessive CPU usage.
1.16 Added the ability to adjust configuration settings in
NETFOSS.COM 'on-the-fly' while a connection is active
using the /M (modify) parameter. This allows a DOS BBS
to customize settings for each door, for example to
allow certain doors using ANSI animation to run slower
than other doors. Optimized internal timeslice handler,
and added additional parameters to tweak performance.
DESQview timeslice releasing is now optional. Removed
OS/2 timeslice releasing. Removed unstable debuging
code from NetFoss.dll. Added codesigning to Net2BBS.exe
and NETCOM.EXE to prevent false-positive results from
Microsoft Defender. No other changes to Net2BBS.
1.17 Fixed an intermittent input overrun issue present in
versions 1.14 - 1.16 due to an NTVDM flaw, reported by
Ioram Sette. Changed the DOS TSR to avoid a conflict
with FrontDoor/DOS which was introduced in version 1.10.
Fixed performance issues when running NetFoss in
"COM port mode" which were introduced in version 1.13.
A minor optimization was made to NetCom. No changes
were made to Net2BBS (including Net2Mon and NetSpy)
which are still at version 1.16. This version went
through extensive beta testing to ensure stability.
1.18 ANSI2FOS.com is no longer needed in order to intercept
DOS I/O function calls and redirect them to telnet, as
this code has been transferred over to NetFoss.com which
results in much faster performance of I/O redirection.
(Read the "DOS I/O Redirection" section of this guide)
Added minor NetFoss.DLL enhancement for improved Zmodem
CPS, Updated Net2BBS features including a web-based
GeoIP country blocking method in addition to the classic
DNSBL method, allowing sysops to run their own GeoIP
web server locally. Net2BBS now caches data being
written to the log file for better CPU efficiency,
full dual stack operations are supported, and it now
uses a larger denied IP cache to block undesirable IPs.
The bot-detection feature adjusted to prevent false
positives.
1.19 This version is released in honor of Ray Gwinn's 75th
Birthday. Ray wrote the X00 and SIO fossil drivers.
Added Command-line /T{Time Remaining} option for DOS
I/O redirection, to prevent user from staying in the
door beyond their time limit. Prevent DOS I/O mode
from passing Ctrl-C or Ctrl-Break commands to
terminate DOS applications. Net2BBS now has options to
choose a different GeoIP web based server, and fixed a
bug in 1.18 that could cause Net2BBS to crash when
MaxSameIP is greater than 1.
1.19R Net2BBS 1.19 had a bug which could cause it to crash,
reported by Christoph Albert. Thanks to Christoph, and
to Kin Chan and John (Deathr0w) for testing the 1.20
beta versions of Net2BBS. NetFoss 1.19 was repackaged
to replace the buggy Net2BBS.exe with version 1.20b8.
1.20 Fixed NetCom issues under Windows XP in which NetCom
could falsly detect a closed connection or could fail
to close the running application, both reported by
Vasya Pupkin. Net2Mon fixed to allow the Net2BBS
service to be uninstalled, reported by Vasya Pupkin.
Added feature to Net2BBS to optionally disconnect or
block clients connecting without ANSI support. Minor
optimizations and enhancements to Net2BBS. Fixed input
issue in NetFoss.com, no changes to NetFoss.dll.
1.20R Net2BBS had 2 bugs, one of which could cause it to
crash (reported by Leslie Givens), and the other could
cause hostnames with wildcards to fail the killist
test (reported by Vasya Pupkin). NetFoss 1.20 was
repackaged with the fixed Net2BBS 1.20.2.
1.20R2 Another bug was discovered in Net2BBS 1.20.2 which could
cause the anti-scanner routine to crash (Reported by
John Riley). NetFoss 1.20 is now repackaged with the
fixed Net2BBS 1.20.3.
1.21 Added ANSI.COM to NetFoss package, a former version of
ANSI2FOS before fossil redirection code was added to it.
(The DOS I/O to fossil redirection code was moved to
NETFOSS.COM in version 1.18.)
Fixed an issue in Net2BBS's Anti-scanner routine which
could cause an Apple terminal client to be rejected due
to failing to detect ANSI (reported by Ozz Nixon).
Updated NFU to support creating DOS BBS dropfiles
(DORINFO1.DEF and CHAIN.TXT) from an existing DOOR.SYS
dropfile, and it can now modify dropfiles to function
in local mode. Minor enhancements to NetFoss/NetCom.
1.22 Improved ANSI.COM for better performance, and tweaked
NetFoss for lower CPU usage. The default Speed setting
in NetFoss is now /S512 (previously /S1000) which gives
a good balance between speed and performance. See the
"NETFOSS.COM Command-line Parameters" section of this
guide for details on making the speed faster or slower.
No changes to Net2BBS, NetCom, NetSpy, or NFU - other
than version number changes for consistency.
1.22R A repack of 1.22 which includes a fixed NETFOSS.DLL to
resolve a "COM Port Mode" bug, preventing FrontDoor
from working. Thanks to Manuel Adorni for reporting it.
1.23 A maintenance release to resolve a possible crash
issue under Windows XP due to DOS INT16h keyboard
input handling, reported by Tim Sweitzer and Vasya
Pupkin. Added option in Net2BBS to bind to a specific
IP, requested by Ozz Nixon. No changes to NETFOSS.DLL
1.23R A repack of 1.23 due to the wrong version of NETFOSS.DLL
was included. There has been no changes to the DLL
since 1.22R.
1.24RC A release candidate which includes NF64 for 64-bit
Windows, in addition to the standard 32-bit edition.
Bug fixes: When MysticBBS is running a door and the
connection drops, it would result in a CPU spike.
(Reported by Bot-Life). The /Z Command-line parameter
was not being processed in versions 1.21-1.23.
(Reported by Tom Swartz). NetFoss was failing to
accept keyboard input from NetSpy in 1.22 and 1.23.
The GeoIP Web lookup stopped working due to changes
to the IPstack interface (Reported by Gord Robert).
Net2BBS had an issue with the writing to the log.
Enhancements: Improved downloading speed.
1.24 The previous 1.24-Release Candidate had no bugs reported
in NetFoss itself, but two of the utilities did:
ANSI.COM had issues with some ANSI codes which could
cause it to become unstable, reported by Tom Swartz.
NFU was not creating a proper DORINFO1.DEF drop file,
and was unable to convert a RemoteAccess 2.62 door.sys
file due to RA placing illegal zeros in its door.sys,
reported by C.G. Learn. These bugs have been fixed,
and NFU has a new option to use the User's Handle as
their Real Name in a door (requested by C.G Learn).
Net2BBS now displays GeoIP provided City and State names
in addition to the user's Country, and if the IPStack
GeoIp site is down or disabled Net2BBS now automatically
falls back to using the DNS-based GeoIP service From
zz.nerds.dk instead. There was also an undocumented
switch added to NetFoss.com (/F1) to force RIP support
in doors that fail to detect RIP properly (requested
by Hawk Hubbard).
1.25RC It turned out that an undocumented NTVDM function used
in version 1.24 did not function properly on some CPU's,
which is now resolved (Reported by Shane O'Neill).
NetCom had an issue under Windows XP which could cause
it to occasionally hang after a DOS BBS exits (Reported
by Mike Dietrich). NFU would sometimes create the wrong
dropfile type (Reported by Mike Dietrich). NFU now allows
passing a socket handle to DOSBox without requiring a
drop file (Requested by Shane O'Neil). NFU now allows
changing drop files to use "Local Mode", to simplify
running doors under Doorway that don't support a fossil
driver. New performance optimizations were made to NetFoss
for faster speed and less CPU usage. The Net2BBS Whitelist
function had accidently been disabled in some previous
versions, and is now reenabled. The "KillList=" option has
been renamed "Blacklist=" (in Net2BBS.ini).
1.25 Fixed an issue in the x64 version of NetFoss which caused
PD Zmodem uploads to fail. Net2BBS changes: WhiteList now
allows IPv6 addresses. The /Z parameter to adjust the
PD Zmodem block time had an issue that was resolved.
Fixed a bug which could cause a random node number to be
selected when the last available node is opened.
(Reported by C.G. Learn). Minor cleanup to Net2BBS.
Discovered that Windows 10 Version 21H1 has an issue which
prevents socket access to a NFU generated door32 request
- A report has been sent to Microsoft.
|
