Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Packet Drvrs & Windows 3.0
Message-ID: <9006141357.AA23684@vax.ftp.com>
Date: 14 Jun 90 13:57:09 GMT
References: <104@npdiss1.StPaul.NCR.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29

In order to be compatible with Windows 3.0, a packet driver would have
to be modified to run in protected mode, in memory which Windows has
locked down so it won't be swapped, and its hardware interrupt handler
would have to use Windows interrupt dispatching services.  Incoming
packets would have to be queued, and delivered to the requesting
process after Windows had been asked to switch to the proper process
context, unless the protocol stack was also running in protected mode.
The side that services application packet driver function calls
(access_type(), etc) would have to use Windows critical section
controls, or else be completely re-entrant.

As you add "real operating system" features to a filesystem/loader
like DOS, the drivers get more complex.  The problem is that to date,
DOS enhancers have not been designed to provide much support for
add-ons like shared hardware drivers, or network protocol stacks.  A
real queued I/O driver scheme with O/S-provided I/O posting services
would solve much of this.  RT-11 had it in 1981, running in about
12Kb, OS/2 would be a lot easier to develop for if its version wasn't
broken...

You can make either NDIS or Packet Driver Spec run under these
circumstances, but the driver has to do a lot more to cope with
different process contexts (assuming that it is a requirement that
user processes can call it directly).  You also need to get (e.g.
pay/trade/beg for) internals information from Microsoft.  We're
talking serious programmer hours, and maybe serious dollars too.

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