Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!krumseea
From: krumseea@hpuxa.ircc.ohio-state.edu (Arthur J. Krumsee)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Packet Drvrs & Windows 3.0
Message-ID: <2110@nisca.ircc.ohio-state.edu>
Date: 15 Jun 90 03:52:26 GMT
References: <104@npdiss1.StPaul.NCR.COM> <9006141357.AA23684@vax.ftp.com>
Sender: news@nisca.ircc.ohio-state.edu
Organization: Ohio State Univ IRCC
Lines: 30

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. 

It should be added even if this is obvious, that you can load the
TCP kernel before loading windows.  This works nicely with the
PC/TCP kernel.

>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.

 I don't doubt the complexity (and grief) of creating a Windows 3.0
compatible driver which would allow users to run TCP/IP fully
within Windows.  Nonetheless, from my perspective such a product
will become a critical need as we all struggle with memory limits
running networks using Windows.  If I load PC LAN software
and the PC/TCP kernel before loading Windows 3.0, I am
left with less than 400K of free memory in DOS windows on 386
machines.  LAN users of your product will need more memory than
that.  I can only hope that your company will recognize and act
to meet that need.

Art Krumsee
Ohio State University