Re: LYNX-DEV re:lynx for win3.x

[Benjamin C. W. Sittler]

Michael:

I found your reply informing and most amusing (after all, who on this 
list still believes Win3.1 is an entire OS?) Would you like to collaborate
on DOSSOCK development?

On Sat, 28 Mar 1998, Michael Sokolov wrote:

[snip]
> The PROPER way to do this is to have a TCP/IP stack central to the operating
> system (DOS) and have all applications (TELNET, FTP, Gopher, Lynx, Windows,
> etc.) access it via DOSSOCK. The first four will need a BSD sockets
> implementation based on DOSSOCK and the last one will need a WINSOCK
> implementation based on DOSSOCK. BTW, this is how it was done at CWRU before
> Win95. INS (the people who run our campus network) have once written a TSR
> (memory-resident) TCP/IP stack and a bunch of utilities that access the 
> network
> via it, including TELNET, FTP, Gopher, and others. Then they have written a
> WINSOCK implementation that uses this same memory-resident TCP/IP stack. All 
> of
> should sound to you strikingly similar to my DOSSOCK proposal. Well, I confess
> that CWRU-PC/IP (that's what this kit is called) is where I have stolen the
> idea from. The only difference is that CWRU-PC/IP's authors are a**holes and
> don't release their sources, so I can't easily make Lynx speak the stack/app
> interface that CWRU-PC/IP uses. This interface has never been standardized
> anyway (it's even incompatible between different versions). Well, I don't
> consider this a great loss, since CWRU-PC/IP's TCP/IP stack is crappy anyway. 
> I
> will write my own. It will be public domain and its interface will be a spec.

When will Lynx/DOSSOCK be ready for beta testing? Or even a preliminary
DOSSOCK system that I can use with MSVC++, Borland C++, DJGPP, lcc, or
EMX/RSXNT? I eagerly await working code...

On a related note, I finally played with EMX/RSXNT under Win32s and
discovered that it does not, in fact, support networking. The apps
compile, but when they run socket() and related calls return an error code
and perror() says "not implemented". I will therefore abandon EMX/RSXNT 
Lynx porting for Win32s for the moment.

I suggest that lynx developers leave this project to those working on DOS
replacements such as Caldera DR-DOS and FreeDOS, as it is really beyond
the scope of Lynx development. Michael's proposal does have real merit,
and I have only the best wishes for a speedy and effective implementation.

I would love to help in any way I can with DOSSOCK design, implementation,
and testing. I have little experience with native DOS programming, having
stuck to UNIX-like environments such as EMX, DJGPP, and Cygnus GNU-Win32
for the most part, but I do have a copy of Borland C++ and an ancient
version of MSVC++. I do have some experience with packet-drivers, but I
think DOSSOCK can present a much better interface (something like BSD
sockets, in fact, would greatly ease the burden of porting.)

> Note how I am treating Windows as an app above. If this sounds strange to you,
> read the following over and over until you digest it: WINDOWS IS NOT AN
> OPERATING SYSTEM OR EVEN AN OPERATING ENVIRONMENT. IT IS AN _APP_, JUST LIKE A
>[snip]The
> system-wide network access API is DOSSOCK. WINSOCK is the internal API
> of one little app called Windows, and other little apps like Lynx have their
> own internal APIs, like the interface between WATTCP and Lynx's code in the
> DJGPP version. These internal APIs are completely independent of each other,
> but all of them are based on DOSSOCK and that's why everything works.

Yes, I realize that Windows is just a graphical shell. However, so far as
I can tell DOSSOCK does not exist yet, so we must (a) rewrite Lynx to use
WinSock, (b) require that users have a separate packet driver and network
interface for Lynx, or (c) abandon Win3.1 users, which is what has
happened by default to this point. I find none of these choices
particularly appealing.

As soon as you have a rough plan for DOSSOCK, can you send it to me or to
the list?

> The above description should tell you why making a Win16 or Win32 version of
> Lynx that uses WINSOCK is just as ridiculous as making Lynx a Netscrap 
> plug-in.

I agree that it would be quite pointless, though not for the stated
reasons. Instead, I think maintaining a separate Windows version of Lynx
which relies on a completely different set of networking code would
uneccessarily complicate Lynx development. I see the goal of Lynx
development as having a single base of source code which compiles and
works on every platform with networking and at least three users, not as
developing a completely "native" version for every major platform.

For this reason, I see a BSD sockets implementation for Win16 or DOSSOCK
as more important than 

[snip]eliminate[snip]

Perhaps we have better things to do than eliminate all violators of
standards and ideals. After all, we're trying to interoperate, not
assimilate, right?