golds@fjc.GOV (Rich Goldschmidt) (03/22/91)
> >... Perhaps it's > >something that the academic community, which seems the most concerned > >about it, could take up. I'd like to add a couple comments. First, it is not just the academic community that is concerned about this issue. Developers of commercial packages for DOS which depend on TCP/IP have been heard to make very foul noises about having to support three or four different TCP/IP implementations. John Romkey may be right that it might not pay for itself for the makers of toolkits, but I'm am quite sure it would pay for itself quite quickly for commercial developers if the major players really would support a single standard. Being able to sell a single shrink-wrapped application would also probably be a boost to DOS TCP/IP sales in general, since the volume of applications, and their ease of installation would likely increase. 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. If a comparable standard could be achieved for TCP/IP for DOS, it would be a great leap forward for all TCP/IP application developers, not just those in academia. -- Rich Goldschmidt: uunet!fjcp60!golds or golds@fjc.gov Commercialization of space is the best way to escape the zero-sum economy. Disclaimer: I don't speak for the government, and it doesn't speak for me...
jbvb@FTP.COM ("James B. Van Bokkelen") (03/23/91)
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?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901ljm@FTP.COM (leo j mclaughlin iii) (03/24/91)
>> >>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