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

[Michael Sokolov]

Benjamin C. W. Sittler <address@hidden> wrote:
> Would you like to collaborate
> on DOSSOCK development?

As soon as I have time. I have to admit that this is still a very low-priority
project for me. My highest-priority project is to build a new UNIX system at
CWRU, using VAXen for the hardware platform and 4.3BSD-* as the OS. This
project has to be the top priority, because if it dies, all my other projects
will die too. This project is what gives me free hardware, an office on campus,
and the ability to use my paid work time for my projects. If I don't prove my
usefulness to the University by finishing my system and making it available to
the users, I will be ousted and there will be no more projects.

> When will Lynx/DOSSOCK be ready for beta testing? Or even a preliminary
> DOSSOCK system [...]

There will almost certainly be a large gap in time between DOSSOCK itself and
DOSSOCK-based Lynx. Lynx requires 32-bit protected mode DOS, while for TELNET,
FTP, finger, etc. 16-bit real-mode DOS is more than enough. In order to make
the version of Lynx that I am talking about, I will first need to complete TWO
development projects. DOSSOCK is one of them, but there also is the other one:
a 32-bit C compiler for True DPMI. DJGPP is no good, it is not for True DPMI
but for the version of DPMI created by the so-called "DPMI Committee", which I
often call Castrated DPMI. Of course I won't write the meat of the compiler, I
will port it from UNIX, but still there is quite a bit of work involved.

I don't know yet which project I will tackle first (after I finish the CWRU
Harhan Project of course), but most likely it will be DOSSOCK.

> that I can use with MSVC++, Borland C++, DJGPP, lcc, or
> EMX/RSXNT?

MS Visual C++ and Borland C++ don't create apps, they create Windows plug-ins,
so they are no good. I don't know anything about lcc or EMX/RSXNT. What are
they like? What kind of executables do they produce?

> I eagerly await working code...

I understand this, but you should also understand that CWRU students, faculty,
and staff users are eagerly awaiting my UNIX system.

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

It has been obvious to me from the beginning that this is exactly what you'll
get with Win32s.

> I suggest that lynx developers leave this project to those working on DOS
> replacements such as Caldera DR-DOS and FreeDOS [...]

I am strongly disapproving of any "DOS replacements". DOS == MS-DOS.

> [...] it is really beyond
> the scope of Lynx development.

Yes, DOSSOCK is not tied to Lynx in any way. Here Lynx is no different from any
other network app. What makes DOSSOCK important for Lynx is that real Lynx for
DOS cannot exist without it, but the same is true for TELNET, FTP, Gopher, etc.

> Michael's proposal does have real merit,

Thanks!

> and I have only the best wishes for a speedy and effective implementation.

This really depends on how quickly can I get some progress on Harhan Project.
If you want to help with the latter, you can do so by:
1. Donating some VAX hardware.
2. Finding someone who has copies of some BSD tapes and persuading him/her to
copy them for me. This is absolutely legal, as I have the required UNIX(R)
source license, but I can't afford UC Berkeley's "distribution fee" of $1000.

> I would love to help in any way I can with DOSSOCK design, implementation,
> and testing.

I don't think that you can give me much help, unfortunately. My primary problem
is time, and believe me, coordinating work (the task that I won't delegate to
anyone) takes just as much time as working, if not more. (The former is what I
am mostly doing with Harhan Project.)

> 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 [...]

My DOS version of Lynx will be 100% DOSish, to the point that many users won't
be able to tell that it is a port of a UNIX program. Also my 32-bit C compiler
for True DPMI will have a 100% Microsoft look and feel. (I mean Classical
Microsoft that has produced MS-DOS and MS OS/2, not the present-day Windowsist
company that happens to have the same name.) Around 1990 Classical Microsoft
has produced several compilers for different languages, which all fit into the
same framework. They use the same linker and library manager, and PWB (the
optional integrated development environment) is the same for all of them. Even
the parts that are different between them have the same look and feel, e.g.,
the same command line syntax. Examples of packages belonging to this framework
are MS Macro Assembler v6.00, MS C Optimizing Compiler v6.00A, and MS BASIC
Professional Development System v7.10. (I have all three, and I have them all
installed in the same directory, so that I don't have duplicate copies of the
common utilities and can treat them as one integrated package.) My compiler
will be designed to fit into this framework as if it were a Microsoft product
itself ("I can't believe it's not Microsoft!"). You will also need to have at
least one of the abovementioned Classical Microsoft packages to get the common
utilities (linker, library manager, etc.)

It may sound disappointing to you that my compiler will require commercial
software, but wait until you hear the real news: it won't be publicly available
itself either! When I port the compiler "meat" from a UNIX C compiler, I won't
use gcc for the latter. Instead, I will use the True UNIX(R) cc. It is a great
K&R C compiler, probably written by K&R themselves, but its code is restricted
to the circle of people with UNIX(R) source licenses. I will, however,
distribute my compiler to people with the necessary licenses for free. Also
note that most campuses have these licenses already, and if yours doesn't, you
can buy one for only $100 these days (instead of $150000). Finally note that I
can make a version of Lynx that requires proprietary tools to compile and this
is OK with the GPL, as it explicitly excludes the compilation tools and
libraries from its definition of the source code.

I know that the previous paragraph has greatly disappointed you. Let me raise
your spirits by saying that probably I will be able to make a gadget for
converting the executables produced by DJGPP into the format I will use in my
True DPMI solution, allowing people limited to "free" software only to compile
my version of Lynx. The result of such compilation will be inferior to the
executables I will produce with the proper tools and distribute on my FTP site,
but it is your decision whether you want to spend some money (or use some
piracy) on better tools to produce better results.

> I do have a copy of Borland C++ and an ancient
> version of MSVC++.

As I have said before, these don't produce apps, only Windows plug-ins, and are
no good.

> I do have some experience with packet-drivers, but I
> think DOSSOCK can present a much better interface [...]

My memory-resident TCP/IP stack will take the packet driver interface on one
end and provide DOSSOCK services on the other end. It will be system-wide, and
apps like TELNET, FTP, Gopher, and Lynx will see DOSSOCK, not the packet
driver.

> (something like BSD
> sockets, in fact, would greatly ease the burden of porting.)

DOSSOCK will be very close to the original BSD sockets, closer than WINSOCK.

> However, so far as
> I can tell DOSSOCK does not exist yet [...]

Correct. (However, packages like CWRU-PC/IP, which are like DOSSOCK in that the
TCP/IP stack is a TSR, rather than a link-in library, do exist.)

> [...] so we must (a) rewrite Lynx to use
> WinSock [...]

A valid option, but are you willing to spend months developing a temporary
solution that will go to the trash can as soon as the real one is ready?

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

But why not simply quit Windows and give the network interface to Lynx? If you
are using CWRU-PC/IP WINSOCK, the packet driver is already there, since that's
what CWRU-PC/IP's memory-resident TCP/IP stack uses itself. Unload this stack
and give the packet driver to that in Lynx. If you have an Ethernet card and
are using Trumpet WINSOCK, the latter also uses a packet driver. Quit Windows,
and the packet driver is available to Lynx. If you have an Ethernet card and
are using Wolverine, the latter uses ODI or NDIS drivers instead, but packet
driver shims around them are publicly available. If you have a SLIP/PPP
connection and are using Trumpet WINSOCK (Wolverine doesn't support this), you
lose the dialer when you get rid of it, but there are lots of free dialers and
SLIP/PPP packet drivers out there.

> I find none of these choices
> particularly appealing.

What about the one above?

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

I will have such a plan only when I get a copy of some BSD tape and a chance to
study BSD sockets properly. At that time I will immediately write the DOSSOCK
specification and quick-and-dirty host and client implementations. I will
gladly make them publicly available. DOSSOCK will be 16-bit real-mode DOS code,
and protected-mode DOS apps will access it through the DPMI translation
services. I will write all of my DOSSOCK code either in assembly or in C. The
former will be in the standard Intel format acceptable to MASM, TASM, and
almost everything else except gas. The latter will be targeted toward MS C
v6.00, but it will be mostly standard K&R C.

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

Correct.

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

Blatant OSI/ISO violators like Trumpet WINSOCK cannot coexist with any other
network software on the same network interface without some absolutely horrible
kludge.

Sincerely,
Michael Sokolov
Phone: 440-449-0299
ARPA Internet SMTP mail: address@hidden