Xref: utzoo comp.protocols.tcp-ip:10319 comp.protocols.tcp-ip.ibmpc:2427 comp.windows.ms:1564 comp.sys.ibm.pc:44846
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!cscnj!paul
From: paul@cscnj.UUCP (Paul Moody)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.windows.ms,comp.sys.ibm.pc
Subject: Re: TCP under MS-Windows
Summary: Excelan can work.
Message-ID: <681@cscnj.UUCP>
Date: 20 Feb 90 20:49:09 GMT
References: <972@ssp18.idca.tds.philips.nl>
Organization: Computer Sciences Corp., Piscataway NJ
Lines: 43

In article <972@ssp18.idca.tds.philips.nl>, michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) writes:
> Is there any one who has a TCP communication program working under MS-Windows?
...deleted...

After several frustating months we managed to get our app running 
using  Excelans Lan Workplace for DOS and windows, including 
Windows/386.

The problem is that most TCP/IP implementations for DOS rely on
'post back' routines. They expect that if you have passed a 
function/buffer pair during a connection api call(OPEN), those
pointers remain valid for the life of the app. This is known as 
asychronous non blocking api. In general this api is always used, its
effects are masked by blocking until the post back takes place. Blocking
until a response is recieved is unacceptable in a windows environment.

Windows, especially windows/386, wants to move things around with
abandon. Windows/386 will even move(swap out) fixed segments. Our 
solution was two fold.  

First we divided the application into a tcp/ip interface and the main 
app.  The tcp/ip window is small model with fixed data and code segments.
It communicates with the main app via DDE. Next we used a synchronous 
non-blocking api and poll the socket. This means using up a timer but 
this way tcp/ip wont try to put something into a buffer that windows 
has moved to the hinterlands of extended memory.

We have been told that with care, dll's can be used under windows/286
with the more effcient asynchronous-non blocking interface. This 
would not help us very much since we want to use windows/386.

The ultimate solution is for the various vendors of DOS tcp/ip
products to provide a windows device driver for their socket
interface. The device driver would live as part of dos space
and would never be moved by windows. It could use the asychronous
non-blocking interface to the actual tcp/ip drivers while doing
SendMessage calls to give you data.

Lets hope.
-- 
Paul Moody			UUCP: rutgers!cscnj!paul 
Computer Sciences Corporation
# the opinions expressed are entirely imaginary			#