Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!FTP.COM!ljm
From: ljm@FTP.COM (leo j mclaughlin iii)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TCP API, binary standards
Message-ID: <9103240527.AA07755@ftp.com>
Date: 24 Mar 91 05:27:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: ljm@ftp.com
Organization: The Internet
Lines: 36

>>
>>Second, those who really are looking to do something about this should
>>examine NetBIOS as a potential model.  It has its share of faults, but it
>>has done what is needed in terms of setting a binary standard for the
>>hardware interrupt and for the system calls to use it.
>>
>
>John and I have both had our noses bloodied by various undocumented Netbios
>hacks and kludges, so I view it as an example of what could go wrong with
>a common API as well: Fred's application works fine on FTP's but not on
>e.g. KA9Q: who's to blame?
>

The reason NetBIOS works as a de facto API standard is that there is
a universally recognized reference implementation, IBM's. If any application,
no matter how twisted in its use of recursion and magic memory locations,
works over the IBM's stack but not over another vendor's, then it is that
vendor's responsibility to hack their implementation to mirror the
behavior IBM's.

This is why doing a NetBIOS implementation is so bloody painful.  The
project never ends as you keep having to go back and mimic yet another
'feature' of the reference stack.  Even worse, every so often you find
an application which replies on an artifact of the implementation which
cannot be duplicated (and of course you only find that it is impossible
after a month or more of beating an engineer's head against the wall).

This is also one of the reasons why getting TCP vendors to support
another vendor's API is so unlikely (if not impossible in some cases).
From the other vendor's perspective, it would represent a *huge* investment
in resources for little return.  Moreover, this is an investment which
the vendor of the reference implementation need not make.

enjoy,
leo j mclaughlin iii
ljm@ftp.com