-= NetFoss 0.9.1 upgrade notes =-

                             June 13, 2004 


 Prior to 0.9.0 which released this month, the previous official release
 of NetFoss was version 0.8.1, released in December 2002.
 After 0.8.1 released, the NetCom Communication Engine was redesigned for
 better performance and CPU usage, and to support binary transfers.
 An "experemental beta" Communication engine was released to the public
 in January 2003, at which point NetFoss development was put on hold.

 ____________________________________________________________________________


 Upgrading from 0.85wb or later:
 ===============================

 Simply replace the NETFOSS.COM, NETFOSS.DLL, and NETCOM.EXE with the
 new versions.

 *IMPORTANT* :
 When upgrading, remember to upgrade all copies of NETFOSS.DLL on
 your hard drive to the new version. This file must be located
 somewhere in your system %PATH% in order to be found.
 If you copied your old NETFOSS.DLL to c:\windows\system32 for
 example, then be sure to upgrade it with the new version.

 ____________________________________________________________________________


 Upgrading from 0.81 or earlier:
 ===============================


 The new version of the Communication Engine (NetCom) might require fine
 tuning in order to achive the lowest possible CPU usage. Most doors
 should idle at around 0% to 5% CPU usage per node.
 (On a P4 class CPUs it should idle between 0% to 1%)
 
 If you are upgrading from a previous version such as 0.8.1, then
 I suggest you first check the amount of CPU usage occurs when you
 have one DOS session running under NetFoss, idling at a prompt.
 Press Ctrl-Alt-Del for the task manager, and then click
 on the Performance tab to see the CPU usage.

 Also you should make a mental note of how quickly full ANSI screens
 are displayed on the remote telnet terminal.  Then upgrade to the new
 version of NETFOSS.COM, NETCOM.EXE, and NETFOSS.DLL.

 *IMPORTANT* :
 When upgrading, remember to upgrade all copies of NETFOSS.DLL on
 your hard drive to the new version. This file must be located
 somewhere in your system %PATH% in order to be found.
 If you copied your old NETFOSS.DLL to c:\windows\system32 for
 example, then be sure to upgrade it with the new version.

 Once you have installed the new files, telnet to localhost again
 and compare the results for yourself. If you find that the new
 version is slower or uses more CPU then 0.8.1 did, then you may
 need to adjust the settings by using the following NetCom command
 line parameters:

 ---------------------------------------------------------------------
      /S{time till sleep}       default= 18
      /B{buffer minimum bytes}  default= 1680
      /W{write delay time}      default= 500
 ---------------------------------------------------------------------

 Example:  NETCOM /S18 /B1680 /W500 %1 %2 %3 %4 %5 %6 %7 %8 %9

 /S{value} = The amount of time NetCom should wait before releasing idle
             time to Windows. If your CPU usage is too high, then try
             lowering this value. Increasing the value will increase
             response time unless the CPU usage gets too high.

 /W{value} = The maximum amount of time to wait before sending the
             buffered TCP/IP packet to Winsock.

 /B{value} = The maximum amount of outgoing data to buffer before
             sending the TCP/IP packet to Winsock.


 The /S parameter is probally the only paremeter you might need to
 fine-tune, as adjusting its value can yield considerably better
 performance or lower CPU usage or even both...

 On a Toshiba Satellite P4 2.0Ghz, a setting of /S10 works best (0%),
 while on my CTX K6-2 300Mhz EZBook a setting of /S40 works best (3%).
 Both still work well at the default setting of 12.

 Note that the /B and /W settings both determine how much buffering is
 done before sending (writing) a tcp/ip packet. Both values are in
 tenths of milliseconds, By default, NetCom will wait for 150
 milliseconds after the first data to be written comes from NetFoss,
 or when 640 bytes are buffered, which ever occurs first.
 It is reccomened you leave both of these alone. Setting a higher delay
 or buffer size could lead to a choppy remote display and poor response
 time. A lower setting could cause smaller packets resulting in less
 performance most noticeable on slower connections. However if you do
 experience choppiness or poor response time on the remote side then
 lowering either of these should help.

 If you do not specify /S /B or /W values on the command line, the
 default values listed above will be used.


 ----------------------------------------------------------------------------


 If you find that this version does not perform as well on your computer
 as previous versions, or you found that you needed to adjust the above
 settings to get better performance, then please let us know.


 Please send bug reports and comments to support@pcmicro.com.