gbj@melb.bull.oz.au (Graham Jose) (03/07/91)
I am having considerable trouble getting the Clarkson 3C503 packet driver to work with PC-NFS. My Etherlink board is configured at IO address 0x300, with an interupt of 5 and DMA address strapped at DC00. I have been trying to start the packet driver after PC-NFS comes up with the following command line: 3C503 0x6a 5 0x300 1 It would seem that this has the effect of always trashing PC-NFS, leaving my network drives inacessible. My ultimate aim is to be able to run WINQVTNET in Windows 3.0, while still having access to my network drives. Regards, Graham Jose --------------------------------------------------------------------------- | Graham Jose, Snr Software Engineer (EFTPOS,Comms) | Phone: 61 3 4200450 | | Melbourne Development Centre | Fax: 61 3 4200445 | | Bull HN Information Systems Australia Pty Ltd |-----------------------| | ACSnet : gbj@bull.oz | Who wants my opinion | | Internet: gbj@melb.bull.oz.au | anyway? | --------------------------------------------------------------------------- -- --------------------------------------------------------------------------- | Graham Jose, Snr Software Engineer (EFTPOS,Comms) | Phone: 61 3 4200450 | | Melbourne Development Centre | Fax: 61 3 4200445 | | Bull HN Information Systems Australia Pty Ltd |-----------------------|
jewell@Data-IO.COM (Cal Jewell) (03/14/91)
In article <gbj.668304598@sirius> gbj@melb.bull.oz.au (Graham Jose) writes: >I am having considerable trouble getting the Clarkson 3C503 packet driver to >work with PC-NFS. [...stuff deleted...] > My ultimate aim is to be able to run WINQVTNET in >Windows 3.0, while still having access to my network drives. I am trying to accomplish the same thing (get WinQVT/NET and PC-NFS to coexist peacefully). But, I haven't been able to pull it off yet. As near as I can tell, what happens is that when you boot the PC, PC-NFS grabs control of the packet driver and won't let go. Then, when you start Windows and start WinQVT/NET, it exits because the packet driver is already in use. I can get PC-NFS to run on the packet driver. I can get WinQVT/NET to run on the packet driver. But, I can't get the two to run together. Am I missing something? If anybody has managed to get WinQVT/NET and PC-NFS to coexist, I'd like to know. I guess that the other possible answer is that Graham and I are trying to do the undoable do. Anybody out there that can offer any clues/insight/answers?
romkey@ASYLUM.SF.CA.US (John Romkey) (03/15/91)
Date: 14 Mar 91 00:19:03 GMT From: Cal Jewell <decwrl!uunet.uu.net!pilchuck!jewell> I can get PC-NFS to run on the packet driver. I can get WinQVT/NET to run on the packet driver. But, I can't get the two to run together. Am I missing something? I expect so. The packet driver has no provisions for supporting multiple instances of the same protocol stack (ie: two TCP's). Never had it, never will. It's a dangerous thing to try to do and unlikely to work right regardless of the amount of kludgery put into it. The packet driver is the wrong level to be trying to fix this sort of problem. It needs to be addressed in the programming interface to the transport layer (TCP and UDP). There should be only one instance of a single type of transport layer per machine, unless you're running multiple network interfaces and appear to the net to be multiple machines. We rehash this one about once every week or two. Again, for everybody's benefit, the packet driver was designed to allow protocol stacks relative independence of the specific device used to access the network, and to allow multiple (different) protocol stacks to share one network device. It was never intended, and will not work, to allow multiple instances of the same protocol. This applies as well to its younger siblings, NDIS and ODI. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us FAX: 415 594-1141
romkey@ASYLUM.SF.CA.US (John Romkey) (03/16/91)
From: "Roger Fajman" <RAF@CU.NIH.GOV> Date: Fri, 15 Mar 91 19:18:39 EST All this is very true, but somewhat misses the point. There is a real need to mix and match applications from various TCP/IP implementations, as no single package has everything. As long as there is no standard interface to a TCP/IP kernel under DOS, this is impossible to do and leads to the desire to run two independent TCP/IP stacks on one adapter. I understand the what you're saying, but my point is about this particular "solution". We've gone over it time and time again. The problem's not solvable at the driver level. It's a bad idea. It won't work right, if it works at all. The packet driver is a solution to one kind of problem; people see that it works for that problem and try to use it to solve other problems that it doesn't work for. Pursue other solutions to this problem. Make there be a binary standard. Get people or organizations to provide API translators. Persuade your favorite (or most hated) vendor to port around other applications or provide some kind of other support for them. Yes, I know it's a real problem. Users need to find real solutions. The packet driver isn't one. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
erick@sunee.waterloo.edu (Erick Engelke) (03/18/91)
In article <9103151710.AA08850@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes: ... >solutions to this problem. Make there be a binary standard. Get people >or organizations to provide API translators. Persuade your favorite >(or most hated) vendor to port around other applications or provide >some kind of other support for them. Agreed, lets see some vendor show some leadership and make a proposed TCP API publicly available. My last post on this subject earned me some mail indicating this is a desired thing. I guess the biggest problem is the lost revenue in developer toolkits, huh? (BTW I tried to respond to everyone, but some mail addresses did not work. Particularly those routing through UoT such as SCOCAN) -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Network Watstar Network Guy University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965
romkey@ASYLUM.SF.CA.US (John Romkey) (03/19/91)
Date: 18 Mar 91 07:15:05 GMT From: Erick Engelke <decwrl!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!news-server.csri.toronto.edu!utgpu!watserv1!sunee!erick> Organization: University of Waterloo Agreed, lets see some vendor show some leadership and make a proposed TCP API publicly available. My last post on this subject earned me some mail indicating this is a desired thing. I guess the biggest problem is the lost revenue in developer toolkits, huh? I should point out that this message is me speaking as John Romkey and not having anything to do with FTP Software. You know, this isn't the first time this has come up. Several of us talked about this briefly several years ago; there wasn't much interest in it among vendors. I don't believe there would be any lost revenue in developer toolkits; I think the biggest problem is that it's a political fiasco and huge resource-sink trying to get vendors to agree on such a thing. I imagine that all the vendors have more urgent uses for their resources, and it's not at all clear to me that the this effort would ever pay for itself. It's also a very big investment in resources to make something like that work right in all concerned environments, even if you have the specification in hand. TSR's are beasts, especially in the network world. Perhaps it's something that the academic community, which seems the most concerned about it, could take up. For that matter, FTP Software decided some years ago that its API was open and that others could implement according to its spec. The toolkit is not publically available, as it's a commercial product, but anyone may implement the programming interface. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
macisaac@cs.ubc.ca (Gary MacIsaac) (03/21/91)
Where would I look to obtain a copy of FTP Software's TCP API specification document mentioned earlier? Is it available via anonymous ftp? Thanks, Gary MacIsaac macisaac@cs.ubc.ca