pcb@gator.cacs.usl.edu (Peter C. Bahrs) (08/17/90)
I am using PS/2 70's with Ungermann Bass NICPS2 boards. To run the IBM tcpip software I must load a netdev.sys driver in config.sys. How do I tell windows about this? Most of the driver oriented software I have read about is loaded through a com or exe file. What about sys files? The problem is, when I bring up a dos shell, ftp, telnet etc. work fine. If I close the shell, and bring up a new shell, the ftp, telnet exe files fail on talking to the board. ! Windows is not corrupted though. The error seems to be from the ftp and telnet software (i.e. it is not a windows failure error). I may have to exclude memory? or something? Any ideas? /*----------- Thanks in advance... --------------------------------------+ | Peter C. Bahrs | | The USL-NASA Project | | Center For Advanced Computer Studies INET: pcb@gator.cacs.usl.edu | | 2 Rex Street | | University of Southwestern Louisiana ...!uunet!dalsqnt!gator!pcb | | Lafayette, LA 70504 | +-----------------------------------------------------------------------*/
dzoey@terminus.umd.edu (Joe I. Herman) (08/18/90)
In article <13282@rouge.usl.edu> pcb@gator.cacs.usl.edu (Peter C. Bahrs) writes: >I am using PS/2 70's with Ungermann Bass NICPS2 boards. To run >the IBM tcpip software I must load a netdev.sys driver in config.sys. > >How do I tell windows about this? Most of the driver oriented software >I have read about is loaded through a com or exe file. What about sys files? All device drivers loaded in config.sys are global to windows. More to the point, for the old IBM tcp/ip software netdev.sys (in memory, netcust) is used to contain configuration data. You do not need to do anything special in windows for your apps to get access to it. The .sys extension is just a naming convention to indicate it is a device driver. >The problem is, when I bring up a dos shell, ftp, telnet etc. work fine. >If I close the shell, and bring up a new shell, the ftp, telnet exe files >fail on talking to the board! When you say "close the shell", do you mean by having the application exit normally, or by double clicking the close box on the DOS window? If you double click the close box, then the program will exit leaving the UB NIC/PS2 in an unknown state. I suggest disabling the close feature on the DOS window (through the PIF editor). >I may have to exclude memory? or something? Any ideas? You could try that also. When running the application, lock about 200k down for ftp or 250k for telnet (if memory serves me (pardon the pun)). We've had success running MD-DOSIP in a DOS window and that uses a netdev.sys so I'm sure it's not netdev.sys. If you want to send me mail with some more details about your setup (does another program use the card etc..) I'll try and can come up with something more concrete. DISCLAIMER: We developed IBM's PC TCP/IP and MD-DOSIP here at the University of Maryland. I was on the development team for both efforts. The above represents my opinions and guesses. Who knows how IBM and the University feel about these things? Joe Herman U. of Maryland dzoey@terminus.umd.edu -- "Everything is wonderful until you know something about it."
davidr@hplsla.HP.COM (David M. Reed) (08/18/90)
One of my major complaints about MSWindows (that is still NOT fixed in version 3) is that it seems to touch hardware that I do not want it to touch, but there is no way to say "keep your hands off!". I have a preference (for reasons I will not go into here) to define our 3COM and Western Digital LAN cards at interrupt 3 (COM2's interrupt). However, is a user wants to run MSWindows on their system I can not set the card interrupt to either COMx interrupt (3 or 4), but must use an LPTx interrupt (5 or 6). Even though NO program under MSWindows is run that might even access either COM port (though a mouse is typically on COM1), the LAN cards often end up in a mode that requires a cold boot to reset. Most of the systems I support (100+) are using PC/TCP from FTP Software. The problem does not always happen. Often we can use a LAN program (ftp, telnet) within MSWindows, though usually we do not. Sometimes those who use such a LAN program can only use it once (such as reported by the writer of this base note). Most of the time the users do not find the LAN card messed up until the exit from MSWindows to use the LAN programs. Our work-around is to configure the cards at interrupt 5 (LPT2). We have never had a problem after doing that. However, we should never have a problem with interrupt 3 if MSWindows wouldn't touch things it is not directly instructed to touch.
dve@zooid.UUCP (David Mason) (08/23/90)
davidr@hplsla.HP.COM (David M. Reed) writes: > Our work-around is to configure the cards at interrupt 5 (LPT2). We have > never had a problem after doing that. However, we should never have a > problem with interrupt 3 if MSWindows wouldn't touch things it is not > directly instructed to touch. Try deleting all references to COM ports in WIN.INI. That's what Newbridge recommended to us for our Easystreet (bleh) "network". Although Easystreet uses the serial ports for the network Windows was causing problems, but deleting the COMx:= lines seems to make Windows ignore them, and hopefullyu their interupts. I hope this helps.
davidr@hplsla.HP.COM (David M. Reed) (08/24/90)
# / hplsla:comp.windows.ms / dve@zooid.UUCP (David Mason) / 10:22 am Aug 22, 1990 /
# davidr@hplsla.HP.COM (David M. Reed) writes:
#
# > Our work-around is to configure the cards at interrupt 5 (LPT2). We have
# > never had a problem after doing that. However, we should never have a
# > problem with interrupt 3 if MSWindows wouldn't touch things it is not
# > directly instructed to touch.
#
# Try deleting all references to COM ports in WIN.INI. That's what Newbridge
# recommended to us for our Easystreet (bleh) "network". Although Easystreet
# uses the serial ports for the network Windows was causing problems, but
# deleting the COMx:= lines seems to make Windows ignore them, and hopefullyu
# their interupts.
#
# I hope this helps.
I have not tried this yet under MSWindows3, but I will. Yet I suspect
that it will work (or didn't work) under version 2.11. Yes, MSWindows
did seem to ignore the LAN card set to a COM port when the references
to the COM ports were removed from the WIN.INI file. However, the entries
get put back in by MSWindows if a user should wander into "Ports" in
the "Control Panel". And some applications (such as Terminal) would
also place them back into the WIN.INI file. What often irritated me
was if I only set (with Control Panel or an application) COM1, an
entry from COM2 would also end up in the file with what must be "default"
values. But maybe this is all fixed in MSWindows3...