Re: LYNX-DEV My planned version

[Michael Sokolov]

   Dear Scott,
   
   You wrote:
> Just to correct one misconception you expressed. UKANS handed over
> development of Lynx to Fote, who then deferred in favor of the current
> Lynx Dev team which is currently headed by Tom Dickey durring Klaus
> Weide's absence. Therefore, it _DOES_ have more of an official status
> than any other version under current development.
   
   This is correct except one important point. "Lynx Dev team" != "the code
on Scott's server". You probably remember that before you started providing
space on sol.slcc.edu, there were several development versions of Lynx, and
none of them was any more official than any other. When you started giving
space on your server, people stopped leading separate versions, but they
didn't have to. You have no authority to declare your server as any more
official than anyone else's, e.g., mine. Seeing that the hone kay of the
code on your server is leading us all to the same place where Ivan Susanin
has led the Polish invaders, I will simply revive the idea of multiple
divergent versions.
   
> One of the latest things Tom did in preparing for the 2.8 release was to
> make the code as similar as possible to Fote's 2.7.2 release where
> formatting was the only issue. Therefore, if you submit diffs against
> 2.7.2, they can likely be folded into the dev code and benefit everyone.
   
   Probably not. Remember, I will start with Fote's latest codeset, which
doesn't have any DOS support. Therefore, my implementation of DOS support
will be completely independent of and mutually exclusive with the one in
Mr. Dickey's codeset.
   
   There are enough serious flaws in the current implementation of DOS
support to make it a better idea to start fresh rather than to build on top
of it. First and foremost, there is the division between DOS386 and Win32
versions. There is the idea that the DOS version runs only under bare DOS
and that Windows users need a different version. The current DOS version of
Lynx is incompatible with other software only because it uses the severely
misguided approach of building the TCP/IP stack into the app. As David
Woolley has explained it very well, this is not the way TCP/IP is supposed
to work, and DOS network apps should talk to a system-wide TCP/IP stack via
DOSSOCK.
   
   As for having a separate Windows version, one must realize that there is
really no such thing as "Windows". As I have explained in much more detain
earlier (see http://www.flora.org/lynx-dev/html/month0897/msg00341.html),
Windows v3.xx in 386 Enhanced mode gains its ability to run in protected
mode, to execute 32-bit code (yes, this ability predates Win95 by 5 years,
appearing first in Windows v3.00 which provides full DPMI support including
32-bit apps), to access all of the machine's physical memory, and to have
virtual memory by shipping with a built-in copy of a new DOS. Yes, when you
are running Windows v3.xx in 386 Enhanced mode, you are essentially running
a different DOS! A 32-bit protected-mode multitasking DOS with virtual
memory that DOS users have always been dreaming about. The only reason that
you never notice this is that this DOS is automatically loaded when you
start Windows and unloaded when you quit it, and as a result its power is
usually unfairly attributed to Windows.
   
   As for Windows 95, the differences from Windows v3.xx are not as great
as you would think. In Windows v3.xx the Protected Mode DOS portion has
full 32-bit app support, but the portion that implements the Windows API
(with GUI and everything) is limited to 16 bits only. In Windows 95 this
portion has been extended to provide the Win32 API and to use all the
functionality of Protected Mode DOS, but the latter has remained
essentially unchanged from Windows v3.00. Incidentally, Win32s does pretty
much the same thing as Windows 95, namely, extends the Windows API portion,
except that Windows 95 does it to a little greater extent (implements a
larger subset of the Win32 API).
   
   But the most important point here is that the Protected Mode DOS is
essentially the same in all versions of Windows starting with 3.00.
Furthermore, it has nothing to do with Windows in the first place! The
functional specification for Protected Mode DOS is DOS Protected Mode
Interface (DPMI) specification, version 0.04. (Note: This is not the same
interface as the version of DPMI used by DJGPP. The latter is a small
subset of the True DPMI I am talking about here.) It is a Microsoft
confidential document, but what it says is rather well-known (to the point
that I can implement the interface without having a copy of the spec). This
interface has been correctly implemented by Qualitas' 386Max, Quarterdeck's
QDPMI, OS/2 DOS boxes, and others. I am currently working on a public-
domain implementation called MMM386.
   
   Since there is Protected Mode DOS, there is no need for any Win16 or
Win32 versions. Since all versions of Windows implement the Protected Mode
DOS functionality, a properly implemented Protected Mode DOS version of
Lynx will work under all of them as well as under plain DOS with a decent
memory manager installed (one that implements True DPMI).
   
   If this version also accesses the network properly (via DOSSOCK), it can
also be made to work both with packet drivers and with WINSOCK. The former
requires a TCP/IP stack TSR that uses a packet driver and implements
DOSSOCK. The latter requires a WINSOCK-to-DOSSOCK adapter VxD. I plan to
write both.
   
   Some other points. I don't plan on using DJGPP. The idea of taking a
UNIX C compiler and porting it to DOS is correct, but it DJ Delorie has
implemented it poorly. I'll do better. I also won't use PDCurses. Instead
I'll develop my own DOS curses implementation.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden