{"id":17190287,"url":"https://github.com/sezero/watt32","last_synced_at":"2025-04-13T19:34:43.115Z","repository":{"id":53818936,"uuid":"209602254","full_name":"sezero/watt32","owner":"sezero","description":"Watt-32 TCP library.","archived":false,"fork":false,"pushed_at":"2023-12-18T14:56:00.000Z","size":20643,"stargazers_count":5,"open_issues_count":0,"forks_count":14,"subscribers_count":2,"default_branch":"2.2.10-sezero","last_synced_at":"2023-12-19T10:52:27.163Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://www.watt-32.net/","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sezero.png","metadata":{"files":{"readme":"readme","changelog":"changes","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2019-09-19T16:38:13.000Z","updated_at":"2023-12-20T15:19:49.263Z","dependencies_parsed_at":"2023-12-20T15:29:50.771Z","dependency_job_id":null,"html_url":"https://github.com/sezero/watt32","commit_stats":null,"previous_names":[],"tags_count":0,"template":null,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sezero%2Fwatt32","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sezero%2Fwatt32/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sezero%2Fwatt32/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sezero%2Fwatt32/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sezero","download_url":"https://codeload.github.com/sezero/watt32/tar.gz/refs/heads/2.2.10-sezero","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248768406,"owners_count":21158631,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-15T01:13:52.454Z","updated_at":"2025-04-13T19:34:43.082Z","avatar_url":"https://github.com/sezero.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"\n\n\n\n\n                               Waterloo TCP\n\n                            Installation Notes\n\n                             by Erick Engelke\n\n\n\n    Introduction\n\n         TCP/IP is not a program, it is a set of protocols which have\n         been  implemented on many machines.  All machines running an\n         implementation  of TCP/IP  and connected  to the  world wide\n         Internet are capable of communicating with each other.\n\n         There    are    several   popular    non-commercial   TCP/IP\n         implementations for MS-DOS computers.   Each offers  special\n         features but with  varied drawbacks.  I  don't believe there\n         is a clear choice  of one implementation for all  needs, but\n         users  are free to pick the best or most useful applications\n         from each offering.\n\n         These  notes  describe  the various  applications  available\n         today.    Please remember  that  the  applications are  free\n         software, you  may use them and pass  them on to others, but\n         there is no warranty  and the support is very  limited.  You\n         also may not sell the included programs.\n\n\n    Installation\n         Waterloo  TCP  only works  if you  have  a packet  driver, a\n         special program which allows  your network interface card to\n         talk with the Waterloo TCP applications.\n\n         Thanks to  some very  generous people,  particularly Russell\n         Nelson, you probably will  not have to buy a  packet driver.\n         If you are  using Ethernet  hardware you  can probably  find\n         free  packet drivers  for  your cards  via anonymous  ftp to\n         sun.soe.clarkson.edu in the pub/drivers subdirectory.\n\n         Waterloo TCP supports Class 1 (DIX-Ethernet), class 6 (SLIP),\n         class 18 (PPP) drivers. Class 3 (Token-ring) is untested.\n\n         Other types of networks have drivers which make them emulate\n         Ethernet hardware.  For example, any Novell system using IPX\n         or any IBM compatible Token Ring  network can be made to act\n         like Ethernet.\n\n         To start using Waterloo TCP software you will need to get it\n         configured.  There are three options, using BOOTP, DHCP or a\n         configuration file.\n\f\n         If you  think you may have a  BOOTP or  DHCP server  on your\n         local subnet, copy  the file  TCPINFO.EXE  into a  new  sub-\n         directory and  run the command  TCPINFO.  It  may take a few\n         seconds. After a maximum of 30 seconds, TCPINFO  should tell\n         you if it  could  get  configured via BOOTP  or DHCP.  If it\n         could not, or BOOTP/DHCP is too slow, you will have to use a\n         configuration file.\n\n         You will  probably want a configuration file  anyways, as it\n         allows some  extra things which  are not inherent  in BOOTP.\n         Waterloo TCP lets  you use a config file,  and pick up extra\n         things from BOOTP or DHCP.\n\n         If you're unsure what you are  doing, continue on  with this\n         section and make a config file or  modify the skeleton  file\n         WATTCP.CFG distributed with Waterloo.\n\n         First  you will  need  some important  information from  you\n         local TCP/IP guru.   Do not merely guess, these  values must\n         be correct or you may do some damage and get yourself on the\n         death threat list from your local network people.\n\n\n         IP address (eg. 129.97.128.123)\n\n\n              my_ip =  ______.______.______.______\n\n\n         local subnet mask (eg. 255.255.0.0, never 255.255.255.255)\n\n\n              netmask = ______.______.______.______\n\n\n         local gateway (eg. 129.97.128.2)\n\n\n              gateway = ______.______.______.______\n\n\n         primary name server (eg. 129.97.128.1)\n\n\n              nameserver = ______.______.______.______\n\n\n         alternate name servers (up to 9 more if so desired)\n         just keep repeating this line with new addresses.\n\n\n              nameserver = ______.______.______.______\n\f\n         name domains list, (eg. UWaterloo.ca or edu)\n\n\n\n              domainlist = ___________________________\n\n\n         These  values must be  placed in  a file  called WATTCP.CFG.\n         Below is a sample copy, remember, do  not use my values, get\n         the correct ones!\n\n              print = \"using sample configuration\" # sample comment\n              print = \"contact local network guru for more details\"\n              my_ip      = 129.97.176.99\n              netmask    = 255.255.0.0             # sample comment\n              nameserver = 129.97.128.24           ; sample comment\n              nameserver = 129.97.128.196          # alt nameserver\n              nameserver = 129.97.128.1            # 3rd nameserver\n              gateway    = 129.97.128.2\n              domainlist = \"uwaterloo.ca\"\n\n         The rules are simple, directive = value. Directive and value\n         (except strings inside quotes) are NOT case-sensitive.\n\n         If quotes are not used in the value field, the value will be\n         terminated by  the start of a  comment or by a  newline, and\n         all white space (spaces and tabs) are removed.\n\n         If you specify quotes around the value, only a second set of\n         quotes  or a newline will  end the value  field and comments\n         must  be preceded  by  an end  quote  mark.   Whitespace  is\n         preserved inside quotes.\n\n         The value can also be taken from  an environment variable.\n         E.g. If you specify:\n              my_ip = $(myip)\n           or\n              my_ip = $(MYIP)\n\n         this will be expanded to the value of %myip%.  E.g. if you\n         specify:\n\n            set myip=129.97.176.99\n        \n         in your AUTOEXEC.BAT, the expansion in WATTCP.CFG will\n         become:\n            my_ip=129.97.176.99\n\n         In this way the same  WATTCP.CFG file can be used throughout\n         the local network. This trick is also handy if you are using\n         DOS-PPP by Antonio Molero \u003ctonilop@redestb.es\u003e. DOS-PPP will\n         write  the variable MYIP to the environment after it loads.\n\n         NOTE: There can be only 1 environment variable per line.\n               Specifying e.g. \"ETHIP = $(GW_ETH), $(GW_IP)\" will\n               not work as intended.\n\n\n         Place the  WATTCP.CFG file in  the same subdirectory  as the\n         TCP  application programs.  If  the file is  not found there\n         the programs automatically look for the file in the  current\n         subdirectory of the current  disk.  Failing that, a  message\n         will  be  displayed but  the  program  will not  necessarily\n         abort.\n\n         You may  override the above directory  choices by explicitly\n         setting the path in an environment variable.\n\n         eg.  set wattcp.cfg=c:\\internet\n\n         The environment  variable is  checked first,  and  if it  is\n         defined, then that config file is used. This is particularly\n         useful on installations  where the software is located on  a\n         fileserver,  but individual  workstations will need separate\n         configuration files.\n\n\n\f    Testing\n\n\n         First,  to  ensure  that  you  entered  all  the  parameters\n         correctly, run  TCPINFO.  It will list all system constants.\n         If one or more  of them seem incorrect, check  your spelling\n         in the WATTCP.CFG file.\n\n         Next  we will test the  PING command to  see that everything\n         works  and asks  another computer  if it is  up.   The first\n         argument to  PING is  the name of  the other computer.   The\n         '-c' argument is the number of ping's to perform. Since your\n         guru supplied the ip address of a nameserver,  we will first\n         try that.\n\n              ping -c5 129.97.128.1         don't  use  129.97.128.1,\n                                            use  your   gateway's  IP\n                                            address\n\n         This will generate five attempts.  You should have more than\n         0  % success.   Otherwise  your gateway is  down or  your ip\n         address or gateway is wrong.\n\n         If  you  had success,  try pinging  the  ip address  of your\n         nameserver.\n\n         eg.  ping  129.97.128.196  5\n\n         Now check your nameserver by trying to resolve the name of a\n         local machine.  Near me is a machine named 'cupid'.\n\n              ping  cupid  5\n\n         If that did  not work, your  various nameserver entries  are\n         incorrect, your  gateway or network mask  is incorrect, your\n         nameservers did not want to provide name service, or you did\n         not specify a valid name.\n\n         These tests will  help your  guru figure out  what might  be\n         wrong.\n\f\n    Applications\n\n         TCPINFO\n              Displays the current Ethernet/TCP configuration.  It is\n              useful for  testing spelling and contents  of files and\n              for determining ethernet addresses.\n\n\n         PING\n\n                   PING  [-vdfst] [-c count] [-w wait] [-p pattern]\n                         hostname\n\n              You  have already  seen PING  described briefly  in the\n              installation section.  PING will not generate more than\n              one  request  per second,  it  also  attempts to  block\n              broadcast attempts.\n\n\n              PING can be used in a debugging mode (-d or /d).\n              eg.  PING -d 129.97.128.1\n\n              If  you do  not specify  the number  of attempts  to be\n              made, only one attempt will be made.\n              eg.  PING 129.97.128.196\n\n              Specifying '-s' will  ping  the other  machine once  per\n              second for a very long time.\n              eg.  PING -s 129.97.128.196\n\n              Run PING -? for explanation of other options\n\n\n         COOKIE\n\n                   COOKIE [-da] [-s host]\n              eg.  COOKIE\n                   COOKIE -s conehead.uwaterloo.ca\n\n              Print a witty saying from one of the cookie servers.\n\n\n         DAYTIME\n              Print the time of day using TCP\n\n                   DAYTIME  host [-d]\n              eg.  DAYTIME  129.97.128.1\n                   DAYTIME  watmath.uwaterloo.ca\n\n              If the  host supports TCP based  DAYTIME text services,\n              the time of  day will  be displayed as  a text  string.\n              See also NTIME\n\n\n         FINGER\n              Determine user or system information\n                   FINGER  [-vdD] [user]@host\n              eg.  FINGER  erick@sunee.uwaterloo.ca\n                   FINGER  @sunee.uwaterloo.ca\n\n              Finger returns  the remote computer's information  on a\n              particular user.\n\n              If no user  is specified, FINGER will return  the names\n              of currently logged users on that machine.\n\n\n         LPR\n              Spool print jobs\n         LPQ\n              Query the print queue\n\n                   Run these commands with no arguments for the exact\n                   syntax.   Check to  see that the  appropriate host\n                   privileges are extended to the pc.\n\n                   An explanation beyond this  is beyond the scope of\n                   this brief document, see your local UNIX guru with\n                   HOSTS.LPR   or   whatever   s/he   feels   is\n                   appropriate.\n\n\n         NTIME\n              Set DOS time from the Network.\n\n              NTIME  host  [-dDv] [-a addminutes]\n\n              NTIME contacts the host  and requests the current time.\n              Computers are  supposed to  respond with the  number of\n              seconds  since Jan 1, 1900 GMT.  Many simply return the\n              current time adjusted to  the daylight savings time and\n              time  zone.  I allow  you to use option 'a'  to specify\n              addminutes  if you  need  to add or subtract a  certain\n              number of minutes to the returned time. Option 'd' sets\n              TCP-debugging to level 1.  Option 'D' sets debugging to\n              level 2. Option 'v' prints version with which NTIME was\n              compiled and the compilation date.\n\n              I was considering using  a DST conversion algorithm but\n              have not yet done so.\n\n         TCPPORT\n              Treat the serial port as a TCP connection\n\n                   TCPPORT host port \"program options\"\n\n              Host is the name  or ip address of the  remote computer\n              and port is the TCP port number on that computer.\n\n              You  may  specify  the  terminal  emulation desired  by\n              setting the environment variable\n                   set  tcpterm=termtype\n              eg.  set  tcpterm=vt102\n\n              See the section on TCPPORT below\n\f\n         REXEC\n              Execute the following command on a remote host\n\n              REXEC  host  [user [pass]] cmd\n\n              The  \"cmd\"  command  will  be executed  on  the  remote\n              computer.  If  you fail to specify  either the password\n              or the userid, you will be prompted for them.\n\n              eg.  rexec  hq.iraq  \"ls -l\"\n                   rexec  hq.iraq  saddam  \"ls -l\"\n                   rexec  hq.iraq saddam white_flag_of_victory \"ls\"\n\n              REXEC does not do terminal interpretation, you may wish\n              to  have  NANSI.SYS  loaded  to  provide  the necessary\n              emulation.  Waterloo TCP REXEC is good when you wish to\n              redirect output to a file.\n\n\n    Other WATTCP Programs\n\n         The above  programs are relatively  simple demonstrations of\n         the  capabilities of  the  WATTCP TCP/IP  kernal.   Advanced\n         programs are usually distributed  separately as they tend to\n         be  updated   in  a  different  schedule   from  the  kernal\n         libraries.\n\n         MSKERMIT 3.11\n              One  of  the first  popular  uses  for WATTCP  was  its\n              ability to make communication programs such as MSKERMIT\n              act like  TELNET facilities.   So overwhelming  was the\n              number of  requests that  MSKERMIT 3.11 now  includes a\n              derivative  of   the  WATTCP  kernal  and  the  TCPPORT\n              application.\n\n         TELNETD\n              The next  most popular use is easily TELNETD, a program\n              which  allows you to TELNET into your pc and control it\n              using  any  TELNET program  on  any  computer platform.\n              TELNETD   can   be   found   via   anonymous   ftp   to\n              sunee.uwaterloo.ca in pub/wattcp/telnetd.zip.\n\n\n    Using Communications Programs with TCPPORT\n\n         You may wish to use  a terminal communication program rather\n         than TELNET.  Waterloo TCP  makes this very easy to do  with\n         its  TCPPORT  program.    Now  that  TCPPORT  is built  into\n         MSKermit I don't really have a good example, but here goes:\n\n         Start by creating a configuration  file which tells your com\n         program  to use the BIOS  ports rather than  hardware.  Then\n\f        create a batch file which looks like:\n\n         TNCOMM.BAT\n              echo off\n              tcpport %1 23 \"c:\\comm\"\n\n         Here I was assuming you kept comm.exe in the root  of C: and\n         tcpport could be found somewhere in  the path.  Now you  can\n         easily TELNET to any host by typing:\n\n              TNCOMM  host\n         eg.  TNCOMM  129.97.128.1\n         or   TNCOMM  watmath.uwaterloo.ca\n\n         After  you  log off,  Waterloo  TCP  returns the  characters\n         forming  [??Host  closed   connection??]  or  some   similar\n         message.  You simply need to exit your com program.  Exiting\n         kermit without logging off  will simply close the connection\n         and typically log you off.\n\n         You may  select a specific terminal  emulation which TCPPORT\n         should  try  to  run  by  setting  the  tcpterm  environment\n         variable before running tcpterm:\n         eg.  set tcpterm=vt102\n\f\n   Advanced WATTCP.CFG Options\n         This  section  is  useful  once  you  have  determined  that\n         Waterloo TCP actually works for you.\n\n         Including Sub-Config Files\n              You may wish to use a combination of generic WATTCP.CFG\n              file  and  a  smaller  sub-config file  which  will  be\n              located  on  the  user's  private  subdirectory.    Any\n              command which can be placed in the main config file may\n              also be placed (or replaced) in the sub-command file.\n\n              eg.\n                   include = c:\\local.cfg\n\n              After the subcommand file  is parsed, Wattcp returns to\n              the  main config  file.   The depth  of this  system is\n              limited by  the number  of file  handles and  the stack\n              size.\n\n              If  the  subcommand  file  cannot be  found,  an  error\n              message will  be printed.   To allow for  the possible,\n              but not-essential existance of a file (i.e., include it\n              if  it is there, but don't  complain otherwise) you may\n              simply prepend the filename with a question mark.\n\n              eg.\n                   include = ?c:\\local.cfg\n\n\n         IP Addresses\n              Most network  administrators would  prefer to  not have\n              many  copies of  the configuration  file, but  rather a\n              single  file  from   which  everyone   can  be   easily\n              configured.\n\n              As  demonstrated above,  Waterloo TCP  normally accepts\n              the ip number from within the WATTCP.CFG file.\n\n         BOOTP\n              Many  sites prefer  to use  BOOTP, a  standard protocol\n              which  requests  the  user's   ip  address  and   other\n              information from a BOOTP server.\n\n              To use BOOTP, you must specify the name 'bootp':\n\n                   my_ip = bootp\n\n              in the config file.  This will broadcast the request on\n              the local subnet.   You  may specify  a specific  BOOTP\n              server which need not be on the same subnet, by using:\n\n                   bootp = host\n              eg.  bootp = 129.97.128.1\n\f\n              The  default  timeout value  is  30 seconds.    You may\n              change that by using:\n\n                   bootpto = seconds\n              eg.  bootpto = 50\n\n              If no  WATTCP.CFG file is found,  Waterloo TCP programs\n              always resort to BOOTP.\n\n         DHCP\n              A  modern  replacement  for BOOTP is DHCP (Dynamic Host\n              Configuration Protocol). Specify use of DHCP by:\n\n                   my_ip = dhcp\n\n              in the config file. See readme.3rd for other DHCP\n              options\n\n\n         ETHERNET to IP Table\n\n              Another option currently  exists, I  allow multiple  IP\n              numbers in WATTCP.CFG  with each  one being  tied to  a\n              particular Ethernet address.  If your  Ethernet address\n              is found in list, your IP address will be assigned.\n\n                   ETHIP=ethaddr,ipaddr\n              eg.  ETHIP=00:01:2F:BC:44:33,128.252.35.4\n\n              In  this   case,  the  machine  with  Ethernet  address\n              00:01:2F:BC:44:33  would  be  assigned  the  ip address\n              128.252.35.4.    Note   that  Ethernet  addresses   are\n              hexadecimal with intermediate  colons, ip addresses are\n              dotted  decimal, and I use a comma to separate the two.\n              Also, since  Waterloo TCP removes white  space, you may\n              place  a space between any  of the fields  if you don't\n              use quotes, and  you may  end the line  with a  comment\n              describing  where  the  station  lives or  to  whom  it\n              belongs.\n\n              You can quickly find the Ethernet  address of a station\n              by running the TCPINFO command.\n\n         Subnets\n              The Internet is comprised of many, many subnets.  There\n              are several  protocols normally used to  help computers\n              reach computers on other subnets.\n\n              Most PC based  TCP kernals depend on  routing tables to\n              manage the possible  routes, so I  elected to use  that\n              strategy.\n\n              A  routing  table  exists  in  memory  with  a  current\n              capacity  for 32  different  routes.   Each route  must\n              specify a gateway, an  optional destination subnet, and\n              then an optional subnet mask.\n\n                   gateway = gate_ip [, subnet [, subnet_mask ]]\n              eg.  gateway = 129.97.176.1        # default\n              eg.  gateway = 129.97.176.2, 129.97.0.0, 255.255,0,0\n\n\n              The  first  example  shows  how a  default  gateway  is\n              created.  A default gateway is used if no other choices\n              exist.\n\f\n              The second example shows how to specify a gateway for a\n              particular subnet.  In this example, whenever the 'top'\n              16 bits are 129.97, that gateway will be used.\n\n              Yes,  you need not always  specify the mask,  but it is\n              necessary for class B subnets, so I simply suggest that\n              you always do specify the mask.\n\n              You  may specify  the same  gateway several  times with\n              different routes.\n\n              Non-contiguous subnet bits are supported.\n\n              To check  your configuration and to  see the precedence\n              of gateways, run TCPINFO.EXE.\n\n         Host Name\n              Some applications will wish  to know your PC's name,  a\n              short  textual  name.    This   may  be  set  with  the\n              WATTCP.CFG line:\n\n                   hostname = name\n              eg.  hostname = mole\n\n\n              Notice that  you do  not  specify the  domain, that  is\n              found from the domain string.\n\n         Timeouts\n              Most Waterloo  TCP programs  have  a specified  timeout\n              value between activity  before a timeout error  occurs.\n              For  example,  the maximum  response  time  to an  open\n              request  before the  connection is  given up  should be\n              reasonably  long so  that distant  connections will  be\n              usable, but short enough that the user will not believe\n              the computer has hung.\n\n              Applications may specify  their own timeout value,  but\n              if  they  chose  to  use  the  system  default (all  my\n              applications do), the default value may be set from the\n              WATTCP.CFG file.\n\n                   SOCKDELAY = seconds\n              eg.  SOCKDELAY = 40\n\n              The  default value is 30  seconds.  A  smaller value is\n              unwise,   but  larger  values   may  be  necessary  for\n              particularly bad connections.\n\n         Maximum Transmit Unit\n              If you understand MTU and know what you would like, you\n              can change it:\n\f                  MTU = bytes\n              eg.  MTU = 1500   (default is 536)\n              MTU and MSS (Maximum Segment Size) are related through\n              the formula: MSS = MTU-40. MSS is only used by TCP.\n              UDP has a maximum packet size of MTU-28.\n\n            NOTE: Previous versions of WatTCP supported  defining MSS\n                  in config-file. \"MSS\" is now  only  defined via the\n                  \"MTU\" above. Default MTU is 576 and  hence  default\n                  MSS would become 536.\n\n\n         Cookie Server\n              You may specify a cookie server in the  WATTCP.CFG file\n              with the line:\n\n                   cookie = server\n              eg.  cookie = 129.97.128.1\n              eg.  cookie = sunee.uwaterloo.ca\n\n              Up to 10 separate cookie servers may be added.  TCPINFO\n              will  list  them  all.    BOOTP will  also  add  cookie\n              servers.\n\n         BOOTP Features and Limitations\n              BOOTP is not the greatest  method of configuration.  In\n              fact  there  is   currently  a  committee   looking  at\n              implementing its successor.\n\n              Waterloo  TCP  programs  will  automatically  get  many\n              configuration parameters from the BOOTP server if those\n              values are returned:\n\n              IP address\n              netmask\n              gateway        (only one will be added)\n              nameservers    (all supplied will be added)\n              cookieservers  (all supplied will be added)\n              hostname\n\n              The domain name cannot be specified currently.   Of the\n              gateways,  only one is recorded by Waterloo TCP as they\n              do not indicate subnets or anything else useful.\n\f\n    Notes:\n         The most up-to-date versions  of these files, their sources,\n         and  new programs  are  available  on Sunee.uwaterloo.ca  by\n         anonymous FTP.  Check out pub/wattcp.\n\n         All  executables   there  are  copyrighted  but  are  freely\n         available for use and non-commercial distribution.\n\n         The library files which do the actual tcp communications are\n         also there.   They too are copyrighted,  but may be used  in\n         commercial and non-commercial work.   You are free to  do as\n         you choose.   If you intend to program  with this package, I\n         would  highly  recommend  the  developers  manual  described\n         below.\n\n         Developers  may wish to join  the Waterloo TCP mailing list,\n         join by mailing to:\n\n              wattcp@Development.Watstar.UWaterloo.ca\n\n         The  programmers manual includes  examples, a full reference\n         of the approximately 50 functions, notes on conversions from\n         UNIX.  The  cost is $40 ($US if you live in USA, $Cdn if you\n         live in  Canada.  $40 US  for anywhere else.   Make check or\n         money order payable to :\n\n              Erick Engelke\n              1010-130 Lincoln Rd.\n              Waterloo, Ont., Canada\n              N2J-4N3\n\n         The  proceeds are  entirely used  to offset  the cost  of my\n         manuals  and  software  costs  necessary for  improving  the\n         package.    The next  step is  Windows  DLL's, but  I cannot\n         afford everything I need to do that.\n\n\n         I have mentioned the  public domain CUTCP and NCSA  programs\n         which  do  an  excellent  job  of  TELNET,  RSH  with  VT100\n         emulation,  and  much more.   You  may  wish to  compare the\n         programs and use the ones which work best for you.\n\n         For their executables, use anonymous ftp to:\n              omnigate.clarkson.edu    128.153.4.2     for CUTCP\n         and  ????                     128.174.20.50   for NCSA\n\n\n         I hope that this distribution helps you in some way, and I'd\n         like to thank the contributors,\n\n              Bruce  Campbell who  wrote  the original  program  from\n                   which tcpport was  derived.  He also wrote the DOS\n                   network I log onto every morning.\n\f             Tim  Krauskopf's  NCSA Name  Domain  code  was used  to\n                   develop Waterloo TCP's resolve function.\n\n              Edmund J. Sutcliffe donated a good portion of BOOTP.\n\n              Jim Martin made a  lot of extensions to  Edmund's BOOTP\n                   work and was influential in the new nameserver and\n                   new gateway code as well as the COOKIE stuff.\n\n              Jason Dent found some bugs and helped optimize WATTCP's\n                   performance.\n\n              Dean Roth  found  some  low  level  bugs   and  greatly\n                  improved the FTP program.\n\n              Although countless others have  given me good ideas and\n                   noticed an incorrect line  here or there, but none\n                   have been  more  thorough or  helpful than  Tarjei\n                   Jensen.\n\n              If you would like  to add your name to  the programmers\n              list,  send me a copy  of your program  and I'll gladly\n              include it in the distribution with full credit.\n\n\n    Erick Engelke\n    Erick@development.watstar.uwaterloo.ca\n    Waterloo TCP Architect\n    July 8, 1992\n\n\n    Gisle Vanem\n    giva@bgnett.no\n    August 20, 1999\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsezero%2Fwatt32","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsezero%2Fwatt32","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsezero%2Fwatt32/lists"}