Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!ASYLUM.SF.CA.US!romkey
From: romkey@ASYLUM.SF.CA.US (John Romkey)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: DesqView/Windows3.0 and Packet Drivers - A Modest
          Proposal
Message-ID: <9009180007.AA18798@asylum.sf.ca.us>
Date: 18 Sep 90 07:07:34 GMT
References: <9009180307.AA13520@alw.nih.gov>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: romkey@asylum.sf.ca.us
Organization: The Internet
Lines: 21

Yes, the packet driver doesn't know anything at all about protocol
addresses. All it knows about is protocol types, and then, all it
knows about that is what the protocols that call into it tell it. You
can't effectively run two separate IP stacks on one system with the
packet driver. If you want two IP stacks, you need two packet drivers
and two ----net boards.

The right way to deal with multiple windows or Desqview applications
calling into TCP is to have a TSR TCP kernel with an interface that
supports windows or Desqview, and have the applications call into
that. I believe all the popular commercial TCP/IP implementations for
DOS (and none of the free ones) provide a TSR interface these days,
and some even have mechanisms for letting Windows/Desqview
applications call into them.

The packet driver is only intended to provide an interface between the
protocol stack and the network device driver. Issues involving
application programming interfaces are better dealt with elsewhere
(like at the application programming interface!).
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com