[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV re:lynx for win3.x
Re: LYNX-DEV re:lynx for win3.x
Sat, 28 Mar 1998 00:51:45 -0500 (EST)
Benjamin C. W. Sittler <address@hidden> wrote:
> Yes, but this relies on a DOS packet driver, not a Winsock driver, so
> getting windows networking programs and Lynx to coexist can be quite
> difficult (unless you have a better solution?)
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.
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
WORD PROCESSOR, A SPREADSHEET, OR A WWW BROWSER. The so-called "Windows apps"
like Netscrap are not really apps, they are sort of applets or plug-ins.
Windows is a versatile app consisting of all kinds of extensions, applets, and
plug-ins. Windows APIs like Win16, Win32, WINSOCK, are _INTERNAL APIs_ of an
app, no different from, say, the API between libwww and Lynx's higher layers.
No one would consider the latter a standard or system-wide API. It's just an
internal matter of some app, something of zero concern to other apps. What does
not seem to sink well into people's heads is that the same is true for Windows
APIs. Windows is an app, and these APIs are its internal matter. 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.
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.
There are WINSOCK implementation like Trumpet that actually do the work
themselves, rather than access a DOSSOCK-type API. These implementations,
however, violate one of the most fundamental postulates of OSI/ISO and TCP/IP:
the protocal stack must be in the OS, NOT in the app. Putting it in the app
locks all other apps out, and that's exactly what happens with Trumpet WINSOCK
and with the DJGPP version of Lynx (which is guilty of the same violation.)
Such violators would stand in the way of any attempt to bring order to the
network access API chaos, and getting rid of them should be the very first step
in any standardization plan.
ARPA Internet SMTP mail: address@hidden