Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Two TCP/IP stacks on one PC
Message-ID: <9005311412.AA02654@vax.ftp.com>
Date: 31 May 90 14:12:42 GMT
Article-I.D.: vax.9005311412.AA02654
References: <9005310245.AA17156@alw.nih.gov>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 23

It is puzzling to hear that 3+Open mail doen't use Netbios sessions,
in light of the way that OS/2 and NDIS are structured.  The theory of
how OS/2 was supposed to network (as propounded by Microsoft and 3Com)
was that all network activity was going to take place via "named
pipes" (preferred) or Netbios sessions (via the user NCB API), and
thus they didn't specify any means of programming the actual transport
layer from a user application.  LAN Manager talked to a Netbios
embedded in the kernel, user NCBs were passed to this Netbios, and
that was it.  A vendor could presumably specify a private API for
a particular transport layer, but Microsoft stayed out of it.

If 3Com (and other LM OEMs) had implemented things this way, then it
would be fairly simple to swap one transport layer for another (XNS
vs. OSI vs. TCP/IP was what Microsoft promised) at the cost of
difficulty in doing "standard" applications like FTAM or Telnet.  But
if in fact 3+Open mail goes direct to the transport, then 3Com is
married to their own transport layer (presumably XNS or TCP/IP), and
my 2nd alternative isn't viable for 3COM (a bit of a surprise).

Oh, well...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901