Path: utzoo!attcan!uunet!midway!ux1.cso.uiuc.edu!uwm.edu!cs.utexas.edu!samsung!interlan.InterLan.COM!backman
From: backman@interlan.Interlan.COM (Larry Backman)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Packet Drvrs & Windows 3.0
Message-ID: <1990Jun15.113256.1668@interlan.Interlan.COM>
Date: 15 Jun 90 11:32:56 GMT
References: <104@npdiss1.StPaul.NCR.COM> <9006141357.AA23684@vax.ftp.com>
Reply-To: backman@interlan.interlan.com.UUCP (Larry Backman)
Organization: Racal InterLan, Inc., Boxborough, MA (1-800-LAN-TALK)
Lines: 41

In article <9006141357.AA23684@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
>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
>

James; are you talking about locking the driver or the data buffers
that the driver uses.  Locking the driver is easy; load it before WIN30
and its in memory forever.  However, what I think you are alluding to is
how does a user program post a read or recv, and later have the driver
put incoming data into the correct buffer.
>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...
>

OS/2 NDIS isn't broken, it just needs a few more passes to work correctly.
>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.
>

Question, agreed that you can force DOS NDIS to work, but how does it
deal with a non-NETBIOS interface to a driver. For instance how does a
use program such as FTP get its buffers locked and its virtual memory
addresses converted to physical.  Where are the equivilents to the
OS/2 DevHelp functions?


				Larry Backman
				backman@interlan.com
.