synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / main / BBS / NETF081.ZIP / NETFOSS.TXT < prev next >

Wrap

Text File | 2002-12-02 | 33.1 KB | 874 lines

-= NetFoss - an Internet FOSSIL =- for Windows NT/2000/XP Version 0.8.1 December 2, 2002 Written by Mike Ehlert Copyright (c) 2001-2002 PC Micro Systems, Inc. ____________________________________________________________________________ NetFoss is a FOSSIL revision level 5 driver for Telnet communications under Windows NT4, 2000, and XP. It includes support for the additional FOSSIL functions defined by Ray Gwinn in X00. A FOSSIL [Fido Opus Seadog Standard Interface Layer] is a driver which allows DOS based modem communication software (ie: BBS's and Door Games) to communicate through an interface that talks to the actual hardware. Originally FOSSIL drivers were used for serial communications, however NetFoss communicates with TCP/IP ports instead, and does not provide any serial port support. Requirements ------------ * Windows NT4, Windows 2000, or Windows XP (any version). * A Win32 Telnet Server (several are available for free). * DOS applications designed to communicate with a FOSSIL (Such as a BBS or a BBS door). Features -------- * Extreamly fast, written entirly in ASM. * Very small, uses only 10k per node. * Supports up to 65535 nodes. * Compatible with nearly all DOS BBS and door software. * DESQview emulation, redirects DV timeslice release functions to NT. * CPU Usage detection / optimization for DOS applications. * Forces doors closed if their carrier detection fails. ____________________________________________________________________________ Installing ---------- Place the following files into a directory: NF.BAT The batch file used to load/unload NetFoss (and the door) NETFOSS.COM The FOSSIL TSR Interupt handler NETFOSS.DLL The FOSSIL Virtual DOS Driver NETCOM.EXE The Communication Engine and application loader NETFOSS.TXT The NetFoss documentation (You are reading it now) FOSSIL.TXT Technical Reference: FOSSIL implementation and use FOSSIL.CHT Technical Reference: FOSSIL command chart If this directory is not in the Path, you must copy NETFOSS.DLL to a directory which is in the Path. ****************************************************************** * NETFOSS.DLL is _required_ to be located in the system %PATH%. * ****************************************************************** Edit your NF.BAT file and change any of the paths there as needed. Do not add any "CD\" commands to the batch file, or it will not be able to find a DOOR32.SYS file which it expects in the current directory if no /n{node} and /h{handle} parameters were passed on the command line. (See section below for details on this). If your BBS does not support DOOR32.SYS, you will need to make an additional change to your NF.BAT file as shown in the non-DOOR32.SYS mode section below. You can rename NF.BAT to NF.CMD if you like, which will use the NT cmd.exe command processor instead of command.com. Note that NetFoss supports any COM port value, on all nodes. This allows BBS programs and doors that were designed to only support FOSSIL ports COM1 though COM4 to work on any node. To take advantage of this, you could set all nodes to use FOSSIL port COM1. NetFoss totally ignores the com port numbers that it is given. It matches up each node number with a WinSock handle value. ____________________________________________________________________________ DOOR32.SYS Mode --------------- If you are using NetFoss with a 32-bit BBS package which can create both a DOOR32.SYS and a standard dropfile (such as EleBBS or WWIV 5.0) then you do not need to pass the node number or the WinSock handle to either NetFoss or NETCOM. Instead they can be automaticly read from the DOOR32.SYS file located in the current directory (which should be the nodes dropfile directory). Some 32-bit BBS's which support DOOR32.SYS can not create a standard drop file at the same time (ie: MysticBBS 1.07.03 and Synchronet 3.10j) So in their case DOOR32.SYS mode should not be used. See below for info on configuring Mystic or Synchronet in non-DOOR32.SYS mode. If your Win32 BBS does not automaticly start a batch file in the current nodes directory then you would have to change to the nodes directory in the beginning of your NF.BAT file. This is not required for most BBS programs. You will need to edit the door command line for each of your doors. A typical type-7 command line in EleBBS would look like this: C:\BBS\NF.BAT c:\bbs\lord\start.bat *N ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^ | | This loads NetFoss. This is the batch file that runs a door. Note that NF.BAT is not passed any information which node or Winsock handle to use. That is because both NEFOSS.COM and NETCOM.EXE will find this information by reading the DOOR32.SYS from the current directory. ____________________________________________________________________________ Non-DOOR32.SYS Mode ------------------- For a DOS based BBS, you will *need* a telnet server to answer incoming telnet connections, and pass them to the DOS BBS software thru NetFoss. This can be done with any DOS BBS that supports a front-end mailer. A Telnet server is needed because NetFoss is not a modem emulator, so it will not support ATA, ATZ, RING, or other modem commands/responces. Therefore you can NOT use your DOS BBS program to wait for a call, and answer when it sees a RING. If you must have a modem emulator, there is an alternative solution called COM/IP (available at http://pcmicro.com/comip) which emulates modems and COM ports. COM/IP also includes its own FOSSIL support. The following Telnet servers have been tested with NetFoss: * TelSrv by Mannsoft. A simple Win32 BBS telnet server. Freeware. http://mannsoft.ca/telsrv.php * Argus by Ritlabs. A complete front-end/mailer. Freeware, open/source. http://www.ritlabs.com/argus * Beemail by Graphic Expressions. A complete front-end mailer. Shareware. http://www.beemail.gexonline.net For Non-DOOR32.SYS mode, you will need to change one line of your NF.BAT file, to pass the node number to NETFOSS.COM. This is only needed if your BBS can not create a DOOR32.SYS drop file. NF.BAT normally looks like this: @echo off c:\bbs\netfoss.com if errorlevel 1 goto end c:\bbs\netcom.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 c:\bbs\netfoss.com /u :end In order for it to work on a Non-DOOR32.SYS environment, you will need to change the second line to "c:\bbs\netfoss %1" in order to pass the node number to NETFOSS.COM. Next you will need to configure your telnet server (or a Win32 BBS) to pass both the node number, and the WinSock handle to the NF.BAT file, as parameters %1 and %2 These will need to be prefixed with the "/n" and "/h" switches, respectivly. ie: C:\BBS\NF.BAT /N{node} /H{handle} c:\bbs\bbsname.exe -C1 -B38400 For example, Argus uses &n to pass the node number, and &h to pass the Winsock handle to an external program. So your Argus external command line (Config >Externals >Doors >Door Parameters) would look like: c:\path\nf.bat /n&n /h&h c:\path\bbs.bat -N&n -C1 -B38400 | | | | | | | NetFoss-loader node handle bbs-loader parameters sent to bbs cmd line In this example, we assume the BBS software uses -C1 to pass the current com port, -B38400 to pass the baud rate, and -N1 to pass a node number to the BBS software. Almost all DOS BBS software allows an active call to be passed from a front-end mailer to the BBS in this fashon, though the BBS parameters such as -C -N -B will differ slightly from one BBS program to another. Please consult your BBS documentation on the proper parameters needed to pass a caller from a front-end mailer to the BBS. ____________________________________________________________________________ MYSTIC BBS Win32 USAGE ---------------------- Mystic's Win32 telnet server (TSERVER.EXE) had problems with early versions of NetFoss, because it did not set the socket for non-blocking mode. NetFoss now forces the socket to use non-blocking mode. Another issue is that under Windows NT/2000/XP, Mystic BBS version 1.07.3 will crash with an exception error when attempting to create a DOOR32.SYS. Mystic was not designed to create both a DOOR32.SYS and a standard drop file at the same time. I have heard of at least two people who have a kluge script to create both a DOOR32.SYS and a standard door dropfile allowing NetFoss to work with Mystic in DOOR32.SYS mode, but here is how to do it without using the DOOR32.SYS: 1) If you have problems using Mystic's TSERVER.EXE you can use a replacment telnet server such as TelSrv by Mannsoft, Argus by RITlabs, Beemail by Graphic Expressions. The commandline the new telnet server should use to start Mystic is: C:\MYSTIC\MYSTIC.EXE -N{node} -TID{socket handle} 2) Modify one line of your NF.BAT, to pass the node number to NetFoss.COM. Change the line that loads NetFoss.COM to have a " %1" at the end. (this is explained in detail in the DOS BBS section above.) 3) Add the door to Mystic. Tell it to create whatever dropfile you want to use with the door (ie DOOR.SYS, DORINFO1.DEF...anything but DOOR32.SYS) and use this commandline as a template: C:\NetFoss\NF.BAT /N%3 /H%0 C:\LORD\START.BAT %3 This will replace "%3" with the node number, and will replace "%0" with the socket handle. Note that %3 is actually used twice in the above example, first to pass the node to netcom.exe, and then again to pass the node number to the doors own batch file. ____________________________________________________________________________ EleBBS Win32 Usage ------------------ NetFoss was developed and tested with EleBBS Win32 using the telnet server included in the EleBBS package. There are detailed instructions on how to configure NetFoss with EleBBS included in a seperate file: ELEBBS.TXT ____________________________________________________________________________ Synchronet BBS 3.10x USAGE -------------------------- Synchronet already has its own FOSSIL support, but using NetFoss in place of the internal FOSSIL will allow DOS doors to run considerably faster, often by a factor of 2 or more times faster then the internal speed. Synchronet will create a DOOR32.SYS file, but it will not start up in the current nodes directory as it should, and Synchronet is unable to create both a DOOR32.SYS and a standard drop file at the same time, which is why the DOOR32.SYS mode should not be used at the time this doc was written. Here is how to configure the "Legend Of The Red Dragon" door in Synchronet 3.10j using the Non-DOOR32.SYS mode: Name LORD Internal Code LORD Start-up Directory C:\SBBS\XTRN\LORD Command Line c:\sbbs\nf.bat /N%# /H%H start.bat %# Clean-up Command Line Execution Cost None Access Requirements Execution Requirements Multiple Concurrent Users Yes Intercept Standard I/O No Native (32-bit) Executable Yes Modify User Data No Execute on Event No BBS Drop File Type GAP DOOR.SYS Place Drop File In Node Directory Time Options... Notice that the Native (32-Bit) Executable option is enabled. This needs to be turned on in order for Synchronet to not enable its own internal FOSSIL driver. When using the Non-DOOR32.SYS mode, you must edit your NF.BAT file to set add the " %1" at the end of the second line, as explained in the above section. ____________________________________________________________________________ PCBoard BBS Usage ----------------- NetFoss has been tested with PCBoard version 15.4 for DOS. Here is how to configure it: 1) Install any of the Win32 Telnet Servers listed in the non-DOOR32.SYS mode section above. 2) Edit your NF.BAT file as described in the non-DOOR32.SYS mode section. 3) Install PCBoard in the c:\pcb directory, and create a seperate directory for each node, such as c:\pcb\node1 and c:\pcb\node2 etc. 4) Run PCBSETUP.EXE > Modem Information> Modem Setup. Set the COMM Driver to use as "F=FOSSIL, set the COM port to any non zero value. Setting it to "1" will work even if you have a real COM1 port already. Set the Opening Baud Rate to 115200, and select Lock in Opening Baud Rate = Yes. 5) Create a BOARD.BAT in the PCBoard directory which looks like this: @ECHO OFF CLS SET PCB=/NODE:%1 /PORT1F: SET PCBDRIVE=C: SET PCBDIR=\PCB\NODE%1 SET PCBDAT=C:\PCB\PCBOARD.DAT SET NODE=%1 :top %pcbdrive% cd %pcbdir% if exist remote.bat REN remote.bat remote.sys if exist door.bat DEL door.bat if exist endpcb DEL endpcb pcboardm /file:%pcbdat% /C:115200 if exist remote.bat CALL remote.bat if exist door.bat CALL door.bat if exist event.bat CALL event.bat if NOT exist endpcb GOTO top :end Note that each %1 will be replaced with the node number when this batch file is run. The line that actually runs pcboard is the "pcboardm /file%pcbdat% /C:115200". The /C:115200 tells it to assume that the user is already connected at that baud rate. The "/PORT1F" setting tells PCBoard to use FOSSIL port COM1, and it is perferable to set the same FOSSIL port for all nodes. 6) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL to a directory located in your PATH. 7) Configure a Win32 Telnet Server to run the NF.BAT and the BOARD.BAT batch files. If you are using Mannsofts TelSrv it should look like: Working Directory: c:\pcb External Program Command Line: c:\telsrv\nf.bat /n*N /h*H c:\pcb\board.bat *N [ ] Enable NetFoss Support (Disabled) Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory containing your nf.bat is located within the TelSrv directory, then you can (and must) enter a simpler form of External Command Line: c:\pcb\board.bat *N Then TelSrv will automaticaly add "NetFoss\nf.bat /n*N /h*H " to the actual command line. ____________________________________________________________________________ RemoteAccess BBS Usage ---------------------- NetFoss was tested with RemoteAccess BBS for DOS version 2.62.1 Here is how to configure it: 1) Install RemoteAccess in c:\ra and create directorys for each node such as c:\ra\node1 and c:\ra\node2 etc. 2) Create a RUNRA.BAT in the RemoteAccess Directory, which looks like this: cd\ra\node%1 ra.exe -B115200 -B115200 -N%1 The -B115200 switch tells RemoteAccess to assume that the caller is already connected to the modem at that speed. The -N%1 passes the node number, since %1 is replaced with the node number when the batch file is run. 3) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL to a directory located in your PATH. 4) Configure a Win32 Telnet Server to run the NF.BAT and the RUNRA.BAT batch files. If you are using Mannsofts TelSrv it should look like: Working Directory: c:\ra\node*N External Program Command Line: c:\telsrv\nf.bat /n*N /h*H c:\ra\runra.bat *N [ ] Enable NetFoss Support (Disabled) Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory containing your nf.bat is located within the TelSrv directory, then you can (and must) enter a simpler form of External Command Line: c:\ra\runra.bat *N This is because the rest is automaticaly added by TelSrv. ____________________________________________________________________________ Telegard BBS Usage ------------------ NetFoss was tested with Telegard BBS for DOS version 3.09G2 and SP4. Here is how to configure it: 1) Install Telegard, and optionally install the service pack4 for it. 2) Create a TG.BAT in the Telegard Directory, which looks like this: cd\tg telegard.exe -B115200 -Q -N%1 The -B115200 switch tells Telegard to assume that the caller is already connected to the modem at that speed. The -Q switch tells Telegard to exit after the caller logs off. The -N%1 passes the node number, since %1 is replaced with the node number when the batch file is run. 3) Unzip the NetFoss files into a directory, and copy NETFOSS.DLL to a directory located in your PATH. 4) Configure a Win32 Telnet Server to run the NF.BAT and the TG.BAT batch files. If you are using Mannsofts TelSrv it should look like: Working Directory: c:\tg External Program Command Line: c:\telsrv\nf.bat /n*N /h*H c:\tg\tg.bat *N [ ] Enable NetFoss Support (Disabled) Note: If you check the "Enable NetFoss" box, and the "/NetFoss" directory containing your nf.bat is located within the TelSrv directory, then you can (and must) enter a simpler form of External Command Line: c:\tg\tg.bat *N This is because the rest is automaticaly added by TelSrv. ____________________________________________________________________________ Door Game Usage --------------- It's peferable to set up all nodes of a door to use the same COM port value, such as COM1. NetFoss ignores the COM port value, but many FOSSIL aware doors only work on COM1 thru COM4, while some doors support up to COM9. There are a few doors that support higher COM port values, for example Trade Wars supports up to COM255. Here are some notes on specific doors: * The Pit Version 4.17 (as well as 4.16 and 4.15) have a bug which prevents them from working with a FOSSIL driver if a COM port UART is not available. This is a bug in these versions. Version 4.05 and below do not have this issue, and will work fine with NetFoss. I'm not sure 4.06 or above. * Lunatix Version 4.3a is considerably slower then some older versions (such as 4.0). NetFos detects when Lunatix 4.3a is running, and does as much as possible to improve its performance. * BBS Crash Version 5.6 does not support a FOSSIL driver even though it is supposed to. Version 5.1 has been tested and works fine. I'm not sure about other versions. If you notice any other doors that say they support a FOSSIL driver but are not working, please let us know. ____________________________________________________________________________ Known Issues ------------ Binary mode (ie: Zmodem) is not implemented yet. Compatibility issues with "Zone Alarm" firewall software reported. ____________________________________________________________________________ Frequently Asked Questions: --------------------------- Q: Does NetFoss run under Windows 95, 98, or ME? A: No. Q: Does NetFoss run under Windows NT4, 2k, or XP? A: Yes. Q: Does FOSS allow all DOS BBS programs and doors to run via a telnet connection? A: Yes. (as long as they support a FOSSIL). Q: Do I need to run COM/IP to get doors to work under telnet? A: No. You only need a telnet server (such as the free TelSrv). Q: Does NetFoss work with Windows BBS programs? A: Yes, but Window programs don't use a FOSSIL themselfs, though a FOSSIL is needed to run DOS doors. Q: Does NetFoss work with doors that do not support a FOSSIL driver? A: No. Q: Does NetFoss work as a FOSSIL for real com ports? A: No. Q: Does NetFoss work as a FOSSIL for COM/IP? A: No. Q: Why do get a "Node is already in use" message from NetFoss? A: See the NETCOM.EXE error messages section below. ____________________________________________________________________________ NETFOS.COM Error Messsages -------------------------- Usage: /n{value} Set node /u Uninstall This helpscreen is displayed if any unknown parameter as passed on the command line. Node is already in use This indicates that either the current or another DOS Window already has the NETFOSS.DLL file activated with the same node number assigned. The node number was either passed on the command line, or read from the DOOR32.SYS file. If you see this, try closing any open DOS windows (command prompts) that are open, in case you inadvertantly had installed netfoss to the same node number from another window. Another possibility is that you loaded NetFoss before you loaded your Win32 BBS from the same window, in which case the BBS is attempting to open another instance of NetFoss from that window. Can't find netfoss.dll This means that netfoss.dll was not located in any of the directorys listed in the environment variable called "Path". You can change the path (a system environment variable) by going to the Windows Control Panel, click on "System Properties", Click on the "Advanced" Tab, Click on "Environment Variables" and edit the value for the System variable named "Path". Bad netfoss.dll [0x] This means that netfoss.dll was found, but it was unable to load it. The error code in the brackets should be sent to the developer. DOOR32.SYS not found This means that there was no /n{node number} switch passed from the command line, so NetFoss was expecting to find a DOOR32.SYS in the current directory where it would obtain the node # from. Most BBS's create drop files (including DOOR32.SYS created by newer Windows BBS's) are created in the nodes default directory, which is often the directory that the BBS was started from. When a BBS runs an external program (a door), it starts out in this directory, and often a doors batch file may then change the directory to door location. This is not usually the case with Synchronet BBS, as it allows the sysop to define which directory the door starts out in. Low memory This means there was not enough RAM for NetFoss to install itself. Netfoss requires approximatly 2k of conventional memory to install itself, (conventional is memory below 640k) but once installed it uses less then 1k of conventional memory. It also requires about 7k of extended memory to operate. Needs NT/2K/XP This means an inferior version of Windows has been detected. Can't uninstall This means that NetFoss was told to uninstall itself (with the /u) but it was either not previously installed from that window or it was unable to uninstall itself. ____________________________________________________________________________ NETCOM.EXE Error Messsages -------------------------- Error: No command line given. NETCOM aborting This means that NETCOM was not given the path\filename.exe of a DOS application to execute (such as a BBS or a door) or a Batch file (either .BAT or .CMD) to process. The command line given must include the extention. Error: no node/handle passed, and no DOOR32.SYS found This means that NETCOM was not passed a /n{node number} and a /h{socket handle} value on the command line, and there was also no DOOR32.SYS file found in the current directory. Error: This Node is already in use This means that another NetCom is already communicating with NETFOSS.DLL on the node number that was either passed on the command line or read from the DOOR32.SYS file. Error: External application failed to execute This means that the command line that netcom was told to execute failed to work. Usually this indicates the path or filename you specified did not exist, though there could be other reasons. Error reading DOOR32.SYS The DOOR32.SYS file was not readable, or was in the wrong format. No port given, assuming local mode. This means that the port listed in DOOR32.SYS or passed on the command line was -1, which means the door should be run in local mode without any tcp/ip interface. ____________________________________________________________________________ FOSSIL Functions Reference -------------------------- Common Functions: Function 00h - Set communications parameters Function 01h - Transmit character and wait Function 02h - Get received character with wait Function 03h - Return Serial Port Status Function 04h - Activate Port Function 05h - Deactivate Port Function 06h - Raise/lower DTR Function 07h - Return timer tick information Function 08h - Flush output buffer Function 09h - Purge output buffer Function 0Ah - Purge input buffer Function 0Bh - Transmit no wait Function 0Ch - Non-destructive read-ahead (Peek) Function 0Dh - Keyboard read without wait Function 0Eh - Keyboard read with wait Function 0Fh - Enable / Disable Flow Control Function 10h - Control-C / Control-K checking Function 11h - Set cursor location Function 12h - Read cursor location Function 13h - Single character ANSI write to screen Function 14h - Enable or disable the DCD watchdog Function 15h - Write character to screen using BIOS Function 16h - Add / Delete a routine from the timer tick Function 17h - Reboot system (not supported by NetFoss) Function 18h - Block Read Function 19h - Block Write Function 1Ah - Break begin or end Function 1Bh - Get FOSSIL Driver information X00 Enhanced Functions: Function 1Ch - Activate Port Function 1Dh - Deactivate Port Function 1Eh - Extended line control initialization Function 1Fh - Extended serial port status/control Function 20h - Read with no wait (destructive) Function 21h - Stuff/Poke the receive buffer Layered Application Functions: Function 7Eh - Install an "external application" Function 7Fh - Remove an "external application" For detailed information on using these functions, refer to the FOSSIL.TXT and FOSSIL.CHT files included in the NetFoss archive. Additional information can be found in the X00 package. ____________________________________________________________________________ License and Disclaimer ---------------------- This software is being provided strictly for non-commercial use. It is provided free of charge for personal hobbiest useage only, without any warranty whatsoever. Use it entirly at your own risk. In no event will Mike Ehlert or PC Micro Systems, Inc. be liable for any damages, including loss of profits or other consequential damages arising from the use or inability to use NetFoss. You may copy and distribute verbatim copies of NetFoss, in any medium, provided that none of the files in the archive are tampered with and no files are added or removed. You may bundle NetFoss with your own BBS software or telnet server, if you do not charge a fee for the product, and as long as all the files in the original NetFoss archive are placed in its own sub directory, with no changes except for the NF.BAT file which may be customized as needed. If you wish to license NetFoss for commercial usage, or are intrested in bundling it with your commercial software you will need to contact mikes@pcmicro.com for licensing prices. NetFoss is a trademark of PC Micro Systems, Inc. Windows is a trademark of Microsoft Corporation. DESQview is a trademark of Symantec Corporation. COM/IP is a trademark of Tactical Software. X00 is a trademark of Raymond L. Gwinn. Other products mentioned are properties of their respected authors. ___________________________________________________________________________ Credits ------- A big thanks goes to Maarten Bekers. He explained many of the Winsock functions that were needed by NETCOM to operate. Maarten is the author of ELECOM and EleBBS. I was beta testing Maartens SyncFos interface when I got the idea of creating a simular driver with Level-5 FOSSIL support included. I would never have got it working without Maartens encouragement and support. Another big thanks go to Hutch for developing MASM32, making it very simple to design Win32 software in ASM. And finally, to the following beta testers who reported problems or offered suggestions on improving NetFoss: Andrew Grimsby Maarten Bekers Mark Netzel aka Kram Rick Parrish aka Manning Marty Kazmaier aka Surato Brian Zohu aka Zoob Matthew Sullivan Louis Northmore Jani Sirpoma aka Dragon Mike Dillon aka GSValore Christopher Evans aka Teknopup Jimmy Rose Loginius Daryl Hunt Chris Costakis Charles René de Cotret Michael Everett, III aka Bobo George A. Roberts IV aka Sirtwist Eric Schwimmer aka Uber Bud Younke aka Raptor ____________________________________________________________________________ Whats new: ---------- 0.2 Added support for /n{node} in NetFoss.com and both /n{node} and /h{handle} in netcom.exe. 0.3 Optimized code, fixed win2k command line bug. 0.4 Redesigned buffering routines, and in the process fixed the FOSSIL peek/poke (0CH &21H) commands, so now Scrabble, Axe & Fang, and any other doors which previously didnt work should now be fine. Fixed random input buffer garbage on first run. 0.5 Reoptimized new code for additional speed. Improved status returned when reading a character to allow T&J software's doors to run. Check for carrier drop during a function 2 (read character /w wait) command. Set function 2 timeout to 30 seconds. 0.6 I took a long break from NetFoss Development. This is a minor update that mainly adds support for NT4. The error messages are now always returned to the DOS window rather then to a pop-up window. Fixed a bug in FOSSIL Function 1B (return info in FOSSIL) which was not returning everything it should. 0.7 Forced Echo off for non Win32 BBS software. Fixed the block-read function, which was not compatible with PCBoard. 0.7.1 Fixed buffer output bug on slower computers or slow connections, thanks to Charles René de Cotret for reporting the issue and testing the fix. 0.7.2 Added work around to fix CR/LF telnet bug in L.O.R.D. 0.8 Added DESQview emulation, to release DV timeslices to NT. Added detection and optimizations for poorly designed doorkits. Enhanced carrier detection routine to work around EasyDoor kit bugs (Reported by Mark Netzel). Force non responding doors to terminate 10 seconds after carrier drops. Improved timeslicing release for local mode doors (requested by Marty Kazmaier). Fixed INT1C Timer Chain handling to work around the Fresh Water Fishing door (reported by Mark Netzel). Optimized base memory usage in netfoss.com. Updated docs. Added a pause to all error messages. 0.8.1 Minor Update. Fixed ANSI detection problem introduced in v0.8 in which Renegade BBS and some doors created using doorframe were unable to detect ANSI. (Reported by Cory Snow and Marty Kazmaier).