Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!ucbvax!ASYLUM.SF.CA.US!romkey
From: romkey@ASYLUM.SF.CA.US (John Romkey)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Clarkson 3C503 & PC-NFS
Message-ID: <9103151710.AA08850@asylum.sf.ca.us>
Date: 16 Mar 91 01:10:42 GMT
References: <9103160018.AA17559@alw.nih.gov>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: romkey@asylum.sf.ca.us
Organization: The Internet
Lines: 26


   From: "Roger Fajman" <RAF@CU.NIH.GOV>
   Date:     Fri, 15 Mar 91  19:18:39 EST

   All this is very true, but somewhat misses the point.  There is a real
   need to mix and match applications from various TCP/IP implementations,
   as no single package has everything.  As long as there is no standard
   interface to a TCP/IP kernel under DOS, this is impossible to do and
   leads to the desire to run two independent TCP/IP stacks on one
   adapter.

I understand the what you're saying, but my point is about this particular
"solution". We've gone over it time and time again. The problem's not
solvable at the driver level. It's a bad idea. It won't work
right, if it works at all. The packet driver is a solution to one kind
of problem; people see that it works for that problem and try to use
it to solve other problems that it doesn't work for. Pursue other
solutions to this problem. Make there be a binary standard. Get people
or organizations to provide API translators. Persuade your favorite
(or most hated) vendor to port around other applications or provide
some kind of other support for them.

Yes, I know it's a real problem. Users need to find real solutions.
The packet driver isn't one.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141