home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / advocacy / 12096 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.0 KB
  1. Xref: sparky comp.os.os2.advocacy:12096 comp.os.os2.networking:2676
  2. Newsgroups: comp.os.os2.advocacy,comp.os.os2.networking
  3. Path: sparky!uunet!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1!sail.uwaterloo.ca!eengelke
  4. From: eengelke@sail.uwaterloo.ca (Erick Engelke)
  5. Subject: Re: ibm tcp/ip a ripoff?
  6. Message-ID: <C0q258.JK5@watserv1.uwaterloo.ca>
  7. Sender: news@watserv1.uwaterloo.ca
  8. Organization: University of Waterloo
  9. References: <1iratf$aqq@agate.berkeley.edu>
  10. Date: Tue, 12 Jan 1993 03:39:08 GMT
  11. Lines: 84
  12.  
  13. In article <1iratf$aqq@agate.berkeley.edu> jp1ek@sunc.shef.ac.uk writes:
  14. >i am beginning to think ibm tcp/ip is a rip off.  my comparative
  15. >reference is the wattcp freeware tcp/ip for msdos and tcp/ip for
  16. >xenix.
  17.  
  18. As the author of the cheaper one you mention, here are some
  19. observations and comments.
  20.  
  21.  
  22. >c) few ethernet cards supported (compared to wattcp with clarkson
  23. >packet drivers);
  24.  
  25. Clarkson and later CRYNWR packet drivers have served wonderfully
  26. over the years.  But probably one of the greatest contributions
  27. was Russ's skeleton which allowed anyone to write a decent driver
  28. for any new hardware they encounterred.  
  29.  
  30. To my knowledge, there is no NDIS driver freely available in source 
  31. code for either DOS or OS/2.  From my warped view that makes it seem
  32. like every hardware manufacturer has to either contract an overpriced
  33. NDIS writing team or learn the hard way.
  34.  
  35. And the configuration is pretty gruesome.  I find this true of
  36. all NDIS installations, who decided we didn't mind rebooting
  37. 20 times and manually editing scripts just to get the configuration 
  38. right or if we want to try someone else's TCP.
  39.  
  40. I can run DOS based ODI and Packet Drivers fine under DOS VDMs,
  41. but my 3c507 NDIS driver kills my modem, go figure!
  42.  
  43.  
  44.  
  45. >d) common tcp/ip programmes not or badly implemented (rsh does
  46. >not accept piped input or properly return stdout from the
  47. >executed command; ftp does not implement piped input/output for
  48. >get and put commands; etc).
  49.  
  50. I wouldn't want to brag here because most of the free apps I
  51. distribute are pretty haphazzard.  My contribution was more
  52. a small TCP stack suitable for inclusion into other's programs, 
  53. like Kermit, WAIS, various 3270 emulation TSRs, several commercial 
  54. TCP applications, and embedded systems. 
  55.  
  56. But I too have found the IBM supplied apps very crude and
  57. often broken (worst VT100/220 emulator I've seen, TELNETD
  58. crashes much more frequently and is less responsive than my own
  59. running under DOS!)
  60.  
  61. >i) hard to setup (xenix tcp/ip took me about three hours from
  62. >openning the box to a reliable anonymous ftp service; wattcp took
  63. >about an hour from loading to basic operation; with os2, i'm
  64. >still at it weeks later).
  65.  
  66. The reason why WATTCP, NCSA, CUTCP, KERMIT and most other free TCPs
  67. are so easily configured is simple - we authors don't want people 
  68. calling us asking how to get the software working and we don't
  69. want to have to document much - hence simple software.
  70.  
  71. You might want to note that all the free software use ASCII config
  72. files, support some way to do include files so multi-station 
  73. installs are simple, easily support BOOTP, and seem to need
  74. comparatively little documentation to get you rolling.  This
  75. is not a boast but a reminder that TCP installation does not
  76. need to be the pain that it is under IBM's lable.
  77.  
  78. Most commercial houses would do well to take a look at getting
  79. back to basics and putting the emphasis on the software and 
  80. ease of installation/use.
  81.  
  82. From a programmer's standpoint, I think IBM made a big mistake
  83. in their approach to reading/writing data to the tcp connection.
  84. Under OS/2 you quickly find that pipes, shared memory, 
  85. semaphores, queues, everything else maps wonderfully into the
  86. filesystem except TCP.  Do Novell's, FTP's, Essex's or anyone
  87. else's TCPs provide this support?  Everything else about OS/2
  88. makes BSD code relatively simple to support except TCP, someone 
  89. really goofed up IMHO.
  90.  
  91. These are the opinions of me and my evil twin cousin,
  92. Erick
  93. -- 
  94. Erick Engelke                      Engineering Computing
  95.                          University of Waterloo
  96. Waterloo TCP Architect         erick@development.watstar.uwaterloo.ca
  97.