kath@delta.eecs.nwu.edu (William L. Kath) (06/12/90)
Does anyone know if NCSA Telnet or KA9Q will run in a window under
Windows 3.0 on a 386 machine?
Thanks in advance for any info.
Bill Kath ----------------------- kath@delta.eecs.nwu.edu
Engineering Sciences and Applied Mathematics
McCormick School of Engineering, Northwestern Universityssw@cica.cica.indiana.edu (Steve Wallace) (06/12/90)
In <8859@accuvax.nwu.edu> kath@delta.eecs.nwu.edu (William L. Kath) writes: >Does anyone know if NCSA Telnet or KA9Q will run in a window under >Windows 3.0 on a 386 machine? Only if you run the packet driver in the same window as the applications (you can't do this if you are also attached to a novell lan), or if you aren't running anything else at the same time (not sure that this is even possible with windows 3 running in enhanced mode). Steven Wallace Indiana University wallaces@ucs.indiana.edu
eason@npdiss1.StPaul.NCR.COM (Dale Eason) (06/14/90)
In article <ssw.645164642@cica> ssw@cica.cica.indiana.eduSteve Wallace) writes: > >>Does anyone know if NCSA Telnet or KA9Q will run in a window under >>Windows 3.0 on a 386 machine? > >Only if you run the packet driver in the same window as the >application... > Does anyone know what needs to be changed to allow the packet driver to be loaded before windows so that we can run Novell at the same time using the shared packet driver?
jbvb@VAX.FTP.COM (James Van Bokkelen) (06/14/90)
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
krumseea@hpuxa.ircc.ohio-state.edu (Arthur J. Krumsee) (06/15/90)
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
backman@interlan.Interlan.COM (Larry Backman) (06/15/90)
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 .
ljm@obelix.twg.com (06/16/90)
>>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. It just doesn't seem worth the effort of redesigning the packet driver interface to deal with Windows 3.0 when simply loading a TCP/IP kernel first works. In any case, if you are using PC LAN software you need to keep the TCP/IP resident anyway. Furthermore, I don't see networking software memory size being that painful of an issue for too much longer. First, the size of the software itself is shrinking (Wollongong's NetBIOS+TCP/IP is about 45K, Beame and Whiteside's software is pretty small, and I would be very suprised if FTP software doesn't ship a low memory usage kernel shortly). Second, but there are many, many memory management utilities which allow you to 'hide' software in various places given a '286 or '386 processor. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com