home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / amiga / datacomm / 5907 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  4.4 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!rutgers!cbmvax!cbmehq!cbmden!kehlet!kehlet
  2. From: kehlet@kehlet.adsp.sub.org (Jesper Kehlet)
  3. Newsgroups: comp.sys.amiga.datacomm
  4. Subject: Re: Amiga Comms (was RE: Amiga Kiosks?)
  5. Message-ID: <kehlet.06ka@kehlet.adsp.sub.org>
  6. Date: 26 Aug 92 16:56:18 GMT
  7. References: <kehlet.060m@kehlet.adsp.sub.org> <1992Aug13.142013.4460@TorreyPinesCA.ncr.com> <kehlet.06db@kehlet.adsp.sub.org> <1992Aug21.162454.7251@TorreyPinesCA.ncr.com>
  8. Organization: Compos Mentis Software Systems
  9. Lines: 90
  10. X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith
  11.  
  12. In article <1992Aug21.162454.7251@TorreyPinesCA.ncr.com> jgrimm@TorreyPinesCA.ncr.com (Jeffrey Grimmett 9999) writes:
  13.  
  14. > A demo would be nice.  I'm a bit spoiled by the try-before-you-buy concept
  15. > at this point.  I've been burned by Baud Bandit and MindLink, and am not
  16. > likely to spend 50 clams on another comm program unless I am *very* impressed
  17. > by it.
  18. > 
  19. > BTW, if you can get it to a SAN or ADS fidonet node, you'll get even better
  20. > coverage.
  21.  
  22. It will go to SAN.
  23.  
  24.  
  25. > >Sure ain't!  ;-) Built-in transfer protocols to reduce the library
  26. > >overhead, that is of great importance when doing file transfers...
  27. > >
  28. > >XPR *WILL* be available in the future, but why use them if the built-in are
  29. > >faster and even more reliable?
  30. > 
  31. > Good.  Although there are legit gripes about XPR, it helps to have that
  32. > ability in case someone wants to use something you didn't want to implement.
  33. > Even with his superior ZModem, Jack Radigan still gets ragged on about
  34. > not having XPR abilities in JRC, though I'd bet not 1 in 5 of the gripers
  35. > would actually use it :-)
  36.  
  37. That's quite a problem.  A company wanted to do a word processing
  38. application for OS/2 & Windows here in Denmark.  They told the programmers
  39. to build in functions like count Chars/Words/Lines/Paragraphs etc. etc.
  40.  
  41. Now the programmers went to the major two client of that company and asked
  42. them, if they really had a need for it.  The answer was simple:  "No, be
  43. it'd be nice!"
  44.  
  45. So, basically, it all comes down to making money and keeping everybody happy.
  46.  
  47.  
  48. > >And now for the NComm bug stuff:
  49. > >
  50. > >    - When trying to open the serial ports in shared mode (3 lines,
  51. > >
  52. > >    - NComm in general opens the serial port in a bad way.  It simply
  53. > >
  54. > >    - It's SLOW in file transfers.  It uses XPR and very badly
  55. > 
  56. > All but the last, I haven't had trouble with.  The last one, I have noticed
  57. > *plus* seen the same thing in Term.  I have the feeling this is an XPRZModem
  58. > bug instead (tons o' errors, too)
  59.  
  60. When we go a little beyond the serial.device as we know it, it crashes.
  61. BTW:  not being able to change serial device before starting the program is
  62. a BAD thing.  If you're using RTS/CTS and you're on the wrong serial unit,
  63. NComm hangs -- it has no time-outs!
  64.  
  65. KAPOW!
  66.  
  67.  
  68. > >    - The ANSI is awfully implemented.  I have experienced problems
  69. > >      with at least 30 BBS's here in Denmark and more than 50 foreign
  70. > >      ones.  I think this relates to the fact, that NComm uses CON:
  71. > >      compatible ANSI, so it's very non-compatible.
  72. > 
  73. > I've seen some problems with a few FSE's out there, and that is primarilly
  74. > why I switched to JRC in the first place.  However, JRC I do beleive uses
  75. > the CON: device, too (pipe in anytime, Jack) so if that's the case, we
  76. > can't really blame Con:  Either way, ANSI doesn't work right, agreed.
  77.  
  78. We can blame CON: for sure, since it has an ANSI implement lacking a lot
  79. of things.
  80.  
  81. So, if you get your hands on cwrite.library (V1.3-something should be on
  82. SAN), try it, use it for ANSI and you know, what we build into this comms
  83. package.
  84.  
  85. Of course, we enhanced it a lot more...  you can't really expect to get the
  86. world in PD software, can you?!  ;-)
  87.  
  88.  
  89. > *******************************************************************************
  90. > Jeff Grimmett [SuperBitMap BBS]        | fido!1:202/1401.0 [619-460-7290]
  91. > NCR -- Torrey Pines Development Center | Jeffrey.Grimmett@TorreyPinesCA.ncr.com
  92. > ==========    "Pay no attention to the man behind the curtain."   =============
  93. > *******************************************************************************
  94.  
  95. -- 
  96.      Jesper Kehlet, Compos Mentis Software Systems -- A Kind Of Magic
  97.  
  98.         (uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmden!kehlet!kehlet
  99.              cbmehq!cbmden!kehlet!kehlet@cbmvax.commodore.com
  100.  
  101.       As long as I speak for myself, my employees can do that, too...
  102.