home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / ibmpc / 7147 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  5.2 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!sun-barr!male.EBay.Sun.COM!jethro.Corp.Sun.COM!news2me.EBay.Sun.COM!seven-up.East.Sun.COM!tyger.Eng.Sun.COM!geoff
  2. From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
  3. Newsgroups: comp.protocols.tcp-ip.ibmpc
  4. Subject: Re: Winsock available?
  5. Date: 23 Dec 1992 20:28:09 GMT
  6. Organization: SunSelect
  7. Lines: 82
  8. Message-ID: <1hai4qINN31q@seven-up.East.Sun.COM>
  9. References: <1gqlf2INN4eo@usenet.INS.CWRU.Edu> <7kT8VB1w165w@cybernet.cse.fau.edu>
  10. NNTP-Posting-Host: tyger.east.sun.com
  11.  
  12. Quoth tbenham@cybernet.cse.fau.edu (Tom Benham) (in <7kT8VB1w165w@cybernet.cse.fau.edu>):
  13. #trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
  14. #
  15. #> Windows Sockets is for Windows while Berkeley Sockets is for BSD Unix.
  16. #> There are some significant differences caused by the different OS archi-
  17. #> tectures, but the spirit is meant to be the same.
  18. #> 
  19. #> The benefit is that you will be able to mix and match TCP stacks and
  20. #> applications from different vendors.  This means that ugly hacks like
  21. #Doesn't IBM offer BSD Sockets interface with their TCP/IP?
  22. #Also, I thought IBM has even announced Sockets of SNA.  Now
  23. #assuming (big ignorant assumption here so please correct me)
  24. #that these APIS are the same as or similar to BSD, then doesn't
  25. #the whole idea of Winsock introduce a new set of imcompatibilities?
  26.  
  27. You're getting confused between API and ABI. Source compatibility is
  28. achieved by writing to a standard programming interface (API).
  29. However, application portability requires that common binary (execution
  30. time) interfaces are used. Such an interface is referred to as an
  31. application binary interface, or ABI. A few years ago, you may have
  32. noticed press reports about USL working to develop standard ABIs for
  33. Unix SVR4 for a variety of hardware platforms - 386, SPARC, 88K, etc.
  34. The goal here was to achieve application portability by ensuring that
  35. every system software supplier (i.e. OS and compiler writers) using a
  36. particular instruction set would use the same interface between the
  37. application and the OS. For example, calling socket() would result in
  38. the application pushing the arguments on the stack in a particular
  39. format and generating a trap to system service index 173. Obviously if
  40. one vendor ignored the ABI and used index 75 for socket(), chaos would
  41. result.
  42.  
  43. Lots of DOS networking vendors offer a sockets API to their TCP/IP
  44. products.  In the DOS (and Unix) worlds, an API is implemented by
  45. statically linking a library which translates the API calls into the
  46. internal interface used by the underlying system. In the wonderful,
  47. chaotic, unstructured world of DOS, there are a variety of mechanisms
  48. which can be used (int2F, private software interrupt, far calls,
  49. overload some DOS int21 function, etc.), and for perfectly good
  50. historical reasons each vendor has evolved their own mechanism. Furthermore, it
  51. isn't necessarily possible to construct a simple mapping from interface
  52. to interface. For example, FTP's PC/TCP supports raw sockets whereas
  53. the PC-NFS PTK does not; on the other hand our PTK supports XTI as well
  54. as sockets. Thus while every programmer may be writing to the same
  55. (source-compatible) API, the binary interface from the application to
  56. the TCP/IP subsystem will be different for each vendor's product.
  57.  
  58. Under Windows, the DLL mechanism allows the interface library to be
  59. linked at runtime. Thus as long as an application developer writes to
  60. the API defined by a standard (in our case, Windows Sockets), the
  61. application will be compatible with the TCP/IP stack from any vendor
  62. who provides a Windows Sockets compliant WINSOCK.DLL. In this case, the
  63. Windows DLL *almost* guarantees that the ABI will natch the API. (The
  64. gotcha lies in compiler calling sequence compatibility, which is not
  65. mandated under Windows. This is a problem which had an impact on the
  66. Windows Sockets effort :-(
  67.  
  68. Would it be better if there were a standard ABI under DOS? Of course it
  69. would. It was a good idea when I suggested it as a follow-on activity
  70. for the RFC NetBIOS group, and it would be a good idea now.
  71. Unfortunately, its time has passed. Between us all, the major vendors
  72. in this area (SunSelect, FTP, Novell, B&W, Wollongong, etc. - in no
  73. particular order, of course :-) have an installed base of several
  74. million PCs using applications written to our proprietary interfaces.
  75. Relatively little interesting new applications work is going on under
  76. DOS, and there is certainly no business justification for investing
  77. what would collectively run to tens of millions of dollars to rework
  78. all our products. Adding a compatibility layer is also a dubious
  79. proposition.  For a start, you can't simply provide a transport
  80. interface: you have to include an appropriate set of name service
  81. calls. Then you'd have to look at the interactions with TSRs... and
  82. task switchers... and on and on. Bottom line: IMHO, it isn't going to
  83. happen. If you want to get creative, think about a Visual Basic
  84. interface...
  85.  
  86. Geoff
  87.  
  88.  
  89. --
  90. Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
  91. ****************** Please reply to the above address (or geoff@east.sun.com).
  92. * BOGOSITY ALERT * Our netnews software is currently generating bogus sender
  93. ****************** addresses. I'll get them to fix it is soon as possible...
  94.