barryf@aix01.aix.rpi.edu (Barry B. Floyd) (05/24/91)
I have been following several threads through several groups since January, all pertaining to TCP/IP applications and Windows 3.0. I get the general impression that DOS/Win 3.0 don't handle multiple TCP/IP applications well (if at all). If this is the case, can someone please (briefly) explain why there are no native Win 3.0 TCP/IP implementations. If this is not the case, can someone please post a menu of necessary software (from config.sys to Win 3.0 app's) used in accessing NFS resources, FTP sites, TELNET sites -- SIMULTANEOUSLY and WITHOUT reverting to a DOS Window? Having recently gotten our LAN connect to our campus Internet I am personally interested in the specifics thereof. Here is what I would like to be able to do: Add a few devices to my config.sys, and a few command lines to my autoexec.bat. Everytime I boot my PC the appropriate drivers and TSR's are loaded, then Win 3.0 is loaded. From within Win 3.0 I would like to mount and unmount virtual NFS drives (located somewhere on the Internet). At the same time I would like to have an FTP deamon running (for anonymous FTP access to my local disk drive), an FTP session running (for access to remote resources), one or more TELNET sessions running. I would like to have all of these applications take advantage of the Windows environment (cut/copy/paste, DDE, mouse and menu bars, resizable windows, etc.) I am aware of (and use) WinQVT 4.x. Soon I will be using Win QVTNET 1.x. I understand that it offers a news reader, FTP and TELNET services but not NFS services (too bad). I am aware of PC-NFS 3.5, does it work in enhanced mode? Does it work well with (simultaneously) QVTNET? Is it a native Win 3.0 app or a DOS app running in a DOS window? Ultimately I would like to know why NFS, TCP/IP, et al is not an integral part of Windows installation and configuration? Is there a purely technical limitation associated with DOS and/or Windows API that prohibits anything but DOS window access to these services? Is it partly a political problem between Microsoft and Sun (et al)? If it is the latter (and not the former, it would appear that MS/Sun are neglecting a non-trivial market (Internet connected PC's and TCP/IP LAN's) for the sake of saving face. end o' ramblin barry -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+
barryf@aix01.aix.rpi.edu (Barry B. Floyd) (05/28/91)
Several people have posted notes to me regarding my original note to this group. In short, most network services are "real mode" applications and many people run Win 3.0 in "protected mode". Thus, by and large the cohabitation of NFS, WinQVT Net and other TCP/IP services is a technical matter. My question now stands as; When will the various NFS vendors, et al, release TCP/IP applications for use in "protected mode" (vs real mode)? Are any already available? Is there a technical limitation or difficulty in doing so? barry -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+
Barry.B..Floyd@sunbrk.FidoNet.Org (Barry B. Floyd) (05/29/91)
Several people have posted notes to me regarding my original note to this group. In short, most network services are "real mode" applications and many people run Win 3.0 in "protected mode". Thus, by and large the cohabitation of NFS, WinQVT Net and other TCP/IP services is a technical matter. My question now stands as; When will the various NFS vendors, et al, release TCP/IP applications for use in "protected mode" (vs real mode)? Are any already available? Is there a technical limitation or difficulty in doing so? barry -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+ * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)
jrv@demon.siemens.com (James R Vallino) (05/29/91)
In article <+klhm6m@rpi.edu> barryf@aix01.aix.rpi.edu (Barry B. Floyd) writes: >My question now stands as; When will the various NFS vendors, et al, release >TCP/IP applications for use in "protected mode" (vs real mode)? Are any >already available? Wollongong is shipping a DLL to provide application level support for sockets. Their full release of all TCP/IP applications running as "Windows Aps" is in beta now due for release July/August. -- Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ jrv@demon.siemens.com princeton!siemens!demon!jrv (609) 734-3331
trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (05/31/91)
You've got two different issues here, or at least, you seem to be asking two different questions. First, you are asking about "cohabitation of NFS, WinQVTnet, and other TCP/IP services". This just isn't possible with today's protocol stacks. What happens is that only one stack at a time can use the IP ethertype. (This is enforced by the packet drivers.) Even if the packet driver didn't require this, how would the packet driver know which packet belonged to which TCP/IP protocol stack? Thus, it's a fundamental limitation on any system, DOS, Unix, or Windows, that you can't have more than one TCP/IP protocol suite loaded per ethernet card. Now, you _can_ use multiple TCP/IP applications, as long as they interface at the TCP or UDP levels. You just need applications that will work together and that will operate efficiently under the Windows environment. I'm planning to solve the problem the following way -- A TCP/IP kernel is loaded as a TSR before Windows is started. (The same TSR provides TCP/IP services to both DOS and Windows applications.) Windows versions of the normal applications (telnet, FTP, mail, and news) are created, speaking to the kernel through a DLL. The DLL handles the job of getting some memory mapped in the real 640K address space, copying the data to and from that address space, and calling the kernel to provide the protocol services. The changes are not as bad as I had originally feared (I'm not going to have to reimplement the whole TCP/IP stack!), but it's still going to be a lot of work. I _will_ have to reimplement a lot of FTP and telnet and all of our mail and news applications. Your dealers are going through the same steps I'm going through, except that they may be using some more sophisticated techniques. I don't have the DDK, so I'm working based on what I can find in the SDK and a little info from the last chapter of _Undocumented DOS_. -- Stephen Trier Work: trier@ins.cwru.edu Case Western Reserve University Home: sct@seldon.clv.oh.us Information Network Services
barryf@aix01.aix.rpi.edu (Barry B. Floyd) (05/31/91)
Stephen (et al) As you may have guessed, I am not well versed in much of the TCP/IP, packet driver, etc. terminology. Is there a nice book, article, paper that draws clear pictures as to how all this fits together? I (an others) would probably be interested in benefitting from the fruits of you labor, if you are able to pull off your project (and solve my problems) as defined. barry -- +--------------------------------------------------------------------+ | Barry B. Floyd \\\ barry_floyd@mts.rpi.edu | | Manager Information Systems - HR \\\ usere9w9@rpitsmts | +-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+
eliel@netlab.cis.brown.edu (06/01/91)
>Now, you _can_ use multiple TCP/IP applications, as long as they interface >at the TCP or UDP levels. You just need applications that will work together >and that will operate efficiently under the Windows environment. > Novell's Lan Workplace for DOS comes with a suite of windows programs that are very nice. I highly recommend them. They also provide a developers toolkit that provides libraries for both DOS and windows development. For more information, call 1-800-RED-WORD (or something like that) Disclaimer: I've been using a pre-release copy for a while, and it's really great! >I'm planning to solve the problem the following way -- A TCP/IP kernel is >loaded as a TSR before Windows is started. (The same TSR provides TCP/IP >services to both DOS and Windows applications.) Windows versions of the >normal applications (telnet, FTP, mail, and news) are created, speaking >to the kernel through a DLL. The DLL handles the job of getting some >memory mapped in the real 640K address space, copying the data to and from >that address space, and calling the kernel to provide the protocol services. This is how Lan Workplace works as well. >Your dealers are going through the same steps I'm going through, except >that they may be using some more sophisticated techniques. I don't have >the DDK, so I'm working based on what I can find in the SDK and a little >info from the last chapter of _Undocumented DOS_. >-- >Stephen Trier Work: trier@ins.cwru.edu >Case Western Reserve University Home: sct@seldon.clv.oh.us >Information Network Services Eliel Mamousette Brown University Computing & Information Services Eliel_Mamousette@Brown.Edu