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.
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 ---------------------------------------------------------------------------
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