angck@nixsin.UUCP (Ang Chee Keong) (06/19/91)
Hello world. I am trying to incorporate socket call in a 'C' program written for Windows 3.0. The program aborted once it use the socket call statement. What I have on my PC is Windows 3.0 SDK, SUN PC-NFS Programmer's Toolkit Version 1.00, and Microsoft 'C' 5.1. Is there any way I could make the socket system call works under Windows 3.0. Any help will be deeply appreciated. Thanks in advance.
ed@odi.com (Ed Schwalenberg) (06/19/91)
From: angck@nixsin.UUCP (Ang Chee Keong) Date: 19 Jun 91 05:42:54 GMT Hello world. I am trying to incorporate socket call in a 'C' program written for Windows 3.0. The program aborted once it use the socket call statement. What I have on my PC is Windows 3.0 SDK, SUN PC-NFS Programmer's Toolkit Version 1.00, and Microsoft 'C' 5.1. Is there any way I could make the socket system call works under Windows 3.0. I've been able to get this to work, but only with great pain. The trick is to make a TSR which holds the PC-NFS code, and call the TSR from Windows. In order to do that, you have to allocate a buffer with GlobalDOSAlloc, copy all the arguments into that buffer, call the TSR, copy all the return values back into the buffer, and return to Windows. It's a lot of work, very hard to get right, and it's very slow. I haven't found other vendors yet with socket libraries for Windows. I saw an ad for some company, but it wasn't yet released and had high per-user royalties. If there's a better way, I'd sure like to know about it.
troy@plod.cbme.unsw.oz.au (Troy Rollo) (06/20/91)
From article <1991Jun19.141519.5669@odi.com>, by ed@odi.com (Ed Schwalenberg): ed> I haven't found other vendors yet with socket libraries for Windows. ed> I saw an ad for some company, but it wasn't yet released and had high ed> per-user royalties. Novell and HP have already released versions of TCP for Windows. Some third party developers have also written applications for these two systems. FTP software is rumoured to be bringing one out soon. I know (vaguely) of around three others coming out soon too. Now, the price, on the other hand, is.... well, I already gave them my comment personally, but the cost of the Novell package in Oz is $800 per machine, or $4000 per 10 machines. I haven't looked at the prices of the other commercial packages, however I suspect there are two public domain or shareware ones coming out shortly. -- __________________________________________________________________________ troy@plod.cbme.unsw.oz.au
randall@Virginia.EDU (Randall Atkinson) (06/20/91)
From article <1991Jun19.141519.5669@odi.com>, by ed@odi.com (Ed Schwalenberg): % I haven't found other vendors yet with socket libraries for Windows. % I saw an ad for some company, but it wasn't yet released and had high % per-user royalties. In article <1778@usage.csd.unsw.oz.au> troy@plod.cbme.unsw.oz.au writes: >Novell and HP have already released versions of TCP for Windows. >Some third party developers have also written applications for >these two systems. FTP software is rumoured to be bringing one >out soon. I know (vaguely) of around three others coming out >soon too. I believe that Sun Microsystems has one as part of their PC-NFS product line. Also, recall that the folks at NCSA probably have large chunks of TCP/IP stuff with their free telnet & ftp sources (on ftp.ncsa.uiuc.edu) that a socket library could be built around. This discussion belongs in comp.protocols.tcpip.ibmpc (at least as a cross post -- most of the knowledgeable folks are there not in the windows group).
venkat@matrix.UUCP (D Venkatrangan) (06/21/91)
In article <1995@nixsin.UUCP> angck@nixsin.UUCP (Ang Chee Keong) writes: >Hello world. I am trying to incorporate socket call in a 'C' program written >for Windows 3.0. The program aborted once it use the socket call statement. >What I have on my PC is Windows 3.0 SDK, SUN PC-NFS Programmer's Toolkit >Version 1.00, and Microsoft 'C' 5.1. > >Is there any way I could make the socket system call works under Windows 3.0. > >Any help will be deeply appreciated. > >Thanks in advance. Okay. This is not a simple problem, but here is the solution. Problem 1: Windows 3.0 application runnning in Standard and Enhanced modes is using the protected modes of the processor. Consequently, any buffers it manipulates are by using selectors and offsets (Selectors are LDT, GDT entries). Network software such as PC-NFS typically can run only in real-mode. In order to pass buffers of data through socket calls, one needs to make sure that any data sent to and received from PC-NFS is real mode data. Solution: In your Windows 3.0 application, use the Windows SDK function GlobalDosAlloc() call to allocate a buffer in memory below 1 Meg. (real mode software such as PC-NFS can only access memory below 1 Meg.) The GlobalDosAlloc() will give you both a selector and a segment to the same real mode allocated memory. In your application, on a send() call, copy the data from the application's buffer into the real mode buffer (using the selector) and pass the segment:offset to send(). On a recv(), you need to pass the segment:offset to recv() and on return, copy from real mode buffer into application's buffer. You may than free the real mode buffer using GlobalDosFree(). You need to implement this scheme (also known as mode-mapping) for all the socket calls you use. Problem 2: When you issue socket() call, a new timer interrupt service routine (INT 8) gets chained, so that TCP timer processing can be done. Now, if your Windows application makes socket() call, the timer gets chained AFTER Windows hooks its timer. This does not work very well, especially because on a timer interrupt, there is no guarantee that the timer service routine is in memory. This is a very significant problem. Another related issue is the processing of network interrupt. When a network packet comes in, the software that processes the network has to be resident in memory. If that software is in a Windows application, it may be difficult to ensure this. Solution: Write your transport calls (socket(), recv() etc.) in a TSR. Device an API between the TSR and your Windows application (through a software interrupt). Load the TSR before Windows starts. This way, you can guarantee that the software to process interrupts is in memory when an interrupt occurs. If you can implement the above solutions, you will be well under way. Once this is done, you may still have to solve other minor problems. If you are willing to wait for the next version of SUN PC-NFS Toolkit, it will address the above problems. There may be other vendors who are also are either in the process of or have already addresses these. Good Luck. --------------------------------------------------------------------------- D. Venkatrangan Matrix Computer Systems, Inc. 1 Tara Blvd, Nashua, NH 03062 uunet!matrix!venkat (603) 888-7000 ---------------------------------------------------------------------------
jrv@demon.siemens.com (James R Vallino) (06/21/91)
In article <1991Jun19.141519.5669@odi.com> ed@odi.com (Ed Schwalenberg) writes: >I haven't found other vendors yet with socket libraries for Windows. >I saw an ad for some company, but it wasn't yet released and had high >per-user royalties. > >If there's a better way, I'd sure like to know about it. Wollongong has just started shipping PathWay Access for DOS Release 1.1 which includes a sockets library interface when you get their API toolkit. This is a first release of the Windows compatible library so things may be a little shaky. NetManage (408-257-6404) also has a Windows compatible TCP/IP software development kit which includes a sockets interface. This product is in its second or third release so maybe the bugs have been worked out by now. I have used the Wollongong non-Windows API previously and have never used the NetMange product. -- Jim Vallino Siemens Corporate Research, Inc., Princeton, NJ jrv@demon.siemens.com princeton!siemens!demon!jrv (609) 734-3331
netmanage@cup.portal.com (William - Dunn) (06/27/91)
In response to the question on socket calls from Windows, it is my impression that most of the current implementations are built for DOS and have problems interfacing to Windows. Your solution is either to wait for the vendors to come out with a socket interface to Windows or to switch to a TCP/IP stack that is implemented as a Windows DLL. Obviously I prefer the second approach since NetManage has a full TCP/IP stack implemented as a Windows DLL with socket interface. I am not going to go into a commercial here so you can contact me at netmanage@cup.portal.com or call (408)257-6404. Boris Yanovsky
beame@maccs.dcss.mcmaster.ca (Carl Beame) (06/27/91)
In article <43724@cup.portal.com> netmanage@cup.portal.com (William - Dunn) writes: >In response to the question on socket calls from Windows, it is my >impression that most of the current implementations are built for >DOS and have problems interfacing to Windows. Your solution is either >to wait for the vendors to come out with a socket interface to Windows >or to switch to a TCP/IP stack that is implemented as a Windows DLL. >Obviously I prefer the second approach since NetManage has a full >TCP/IP stack implemented as a Windows DLL with socket interface. >I am not going to go into a commercial here so you can contact me >at netmanage@cup.portal.com or call (408)257-6404. > >Boris Yanovsky There really is no nead to wait as many TCP/IP vendors have socket access under Windows 3.0 as DLLs or in other fashions. Here is a small list of the products that I beleive have such an interface: Novell LAN WorkPlace for DOS Beame & Whiteside BW-TCP and BW-NFS Wollongong FTP software (??? possibly in beta?) - Carl Beame Beame & Whiteside Software Ltd.
eliel@netlab.cis.brown.edu (06/28/91)
They have implemented their vt220 emulator (Host Presenter), a nice windows based ftp interface (File Express) and an FTPdaemon for windows using the same interface, so it's at least going to be well maintained since they depend on it for their own products as well.... good luck, eliel p.s. I think you can call 1-800-RED-WORD for pricing information on the package.
apb@cbnewsj.cb.att.com (Amrit Bains) (06/28/91)
In article <43724@cup.portal.com> netmanage@cup.portal.com (William - Dunn) writes: >In response to the question on socket calls from Windows, it is my >impression that most of the current implementations are built for >DOS and have problems interfacing to Windows. Your solution is either >to wait for the vendors to come out with a socket interface to Windows >or to switch to a TCP/IP stack that is implemented as a Windows DLL. >Obviously I prefer the second approach since NetManage has a full >TCP/IP stack implemented as a Windows DLL with socket interface. >I am not going to go into a commercial here so you can contact me >at netmanage@cup.portal.com or call (408)257-6404. > >Boris Yanovsky NOVELL offers LAN WORKPLACE for DOS and WINDOWS which has a DLL for TCP/IP with a sockets interface. It also has sockets libraries for DOS. We are using it and it seems stable enough for comercial pupposes. Amrit Bains abains@attunix.att.com