From: geoff@tyger.Eng.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Winsock available?
Date: 23 Dec 1992 20:28:09 GMT
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

Quoth tbenham@cybernet.cse.fau.edu (Tom Benham) (in <7kT8VB1w165w@cybernet.cse.fau.edu>):
#trier@slc6.ins.cwru.edu (Stephen C. Trier) writes:
#
#> Windows Sockets is for Windows while Berkeley Sockets is for BSD Unix.
#> There are some significant differences caused by the different OS archi-
#> tectures, but the spirit is meant to be the same.
#> 
#> The benefit is that you will be able to mix and match TCP stacks and
#> applications from different vendors.  This means that ugly hacks like
#Doesn't IBM offer BSD Sockets interface with their TCP/IP?
#Also, I thought IBM has even announced Sockets of SNA.  Now
#assuming (big ignorant assumption here so please correct me)
#that these APIS are the same as or similar to BSD, then doesn't
#the whole idea of Winsock introduce a new set of imcompatibilities?

You're getting confused between API and ABI. Source compatibility is
achieved by writing to a standard programming interface (API).
However, application portability requires that common binary (execution
time) interfaces are used. Such an interface is referred to as an
application binary interface, or ABI. A few years ago, you may have
noticed press reports about USL working to develop standard ABIs for
Unix SVR4 for a variety of hardware platforms - 386, SPARC, 88K, etc.
The goal here was to achieve application portability by ensuring that
every system software supplier (i.e. OS and compiler writers) using a
particular instruction set would use the same interface between the
application and the OS. For example, calling socket() would result in
the application pushing the arguments on the stack in a particular
format and generating a trap to system service index 173. Obviously if
one vendor ignored the ABI and used index 75 for socket(), chaos would
result.

Lots of DOS networking vendors offer a sockets API to their TCP/IP
products.  In the DOS (and Unix) worlds, an API is implemented by
statically linking a library which translates the API calls into the
internal interface used by the underlying system. In the wonderful,
chaotic, unstructured world of DOS, there are a variety of mechanisms
which can be used (int2F, private software interrupt, far calls,
overload some DOS int21 function, etc.), and for perfectly good
historical reasons each vendor has evolved their own mechanism. Furthermore, it
isn't necessarily possible to construct a simple mapping from interface
to interface. For example, FTP's PC/TCP supports raw sockets whereas
the PC-NFS PTK does not; on the other hand our PTK supports XTI as well
as sockets. Thus while every programmer may be writing to the same
(source-compatible) API, the binary interface from the application to
the TCP/IP subsystem will be different for each vendor's product.

Under Windows, the DLL mechanism allows the interface library to be
linked at runtime. Thus as long as an application developer writes to
the API defined by a standard (in our case, Windows Sockets), the
application will be compatible with the TCP/IP stack from any vendor
who provides a Windows Sockets compliant WINSOCK.DLL. In this case, the
Windows DLL *almost* guarantees that the ABI will natch the API. (The
gotcha lies in compiler calling sequence compatibility, which is not
mandated under Windows. This is a problem which had an impact on the
Windows Sockets effort :-(

Would it be better if there were a standard ABI under DOS? Of course it
would. It was a good idea when I suggested it as a follow-on activity
for the RFC NetBIOS group, and it would be a good idea now.
Unfortunately, its time has passed. Between us all, the major vendors
in this area (SunSelect, FTP, Novell, B&W, Wollongong, etc. - in no
particular order, of course :-) have an installed base of several
million PCs using applications written to our proprietary interfaces.
Relatively little interesting new applications work is going on under
DOS, and there is certainly no business justification for investing
what would collectively run to tens of millions of dollars to rework
all our products. Adding a compatibility layer is also a dubious
proposition.  For a start, you can't simply provide a transport
interface: you have to include an appropriate set of name service
calls. Then you'd have to look at the interactions with TSRs... and
task switchers... and on and on. Bottom line: IMHO, it isn't going to
happen. If you want to get creative, think about a Visual Basic
interface...

Geoff


--
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
****************** Please reply to the above address (or geoff@east.sun.com).
* BOGOSITY ALERT * Our netnews software is currently generating bogus sender
****************** addresses. I'll get them to fix it is soon as possible...