Xref: utzoo comp.protocols.tcp-ip.ibmpc:6207 comp.windows.ms.programmer:3208 comp.protocols.nfs:2507
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!matrix!venkat
From: venkat@matrix.UUCP (D Venkatrangan)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.windows.ms.programmer,comp.protocols.nfs
Subject: Re: Socket call in Window 3.0 program
Keywords: TCP/IP
Message-ID: <836@matrix.UUCP>
Date: 20 Jun 91 18:06:45 GMT
References: <1995@nixsin.UUCP>
Reply-To: venkat@matrix.UUCP (D Venkatrangan)
Organization: Matrix Computer Systems Inc.
Lines: 75

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