lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LYNX-DEV Re: UNIXish and DOSish software


From: Michael Sokolov
Subject: LYNX-DEV Re: UNIXish and DOSish software
Date: Sun, 5 Apr 1998 03:33:06 -0400 (EDT)

   Jason F. McBrayer <address@hidden> wrote:
> Few people deliberately choose plain DOS over Unix, OS/2, or modern
> flavours of Windows.
   
   I do, and I don't intend to pursue this thread any further.
   
> It seems to me that your version of Lynx will be targeted exactly for
> you [...]
   
   And anyone who chooses to share my beliefs.
   
> [...] a fundamentalist version of BSD that
> doesn't correspond to any real Unix in use today [...]
   
   First of all, there is no such thing as a "fundamentalist version of
BSD". There is one system named Berkeley Software Distribution (BSD), and
it doesn't have any fundamentalist and non-fundamentalist versions. As for
"real Unix", let me remind you that UNIX is a registered trademark of UNIX
System Laboratories (USL), currently owned by Santa Cruz Operation (SCO),
and that real UNIX(R) is that compiled from the USL sources. The Berkeley
version of UNIX(R) is based on those sources, so it IS real UNIX(R) in the
strictest legal sense. As for "in use today", when I have my system set up,
remind me and I'll give you an account so that you can see and feel it for
yourself.
   
> [...] a True DOS
> corresponding to an idealized vision of MS (not PC- or DR-) DOS 3.3.
   
   First of all, PC-DOS IS MS-DOS. Quoting from the MS/IBM DOS source code
(INC\VERSION.INC):
   
> ; Use the switches below to produce the standard Microsoft version or the
> ; IBM version of the operating system
> ;
> ; The below chart will indicate how to set the switches to build the
> ; various versions
> ;
> ;                     IBMVER          IBMCOPYRIGHT
> ; --------------------------------------------------------
> ;  IBM Version   |     TRUE              TRUE
> ; --------------------------------------------------------
> ;  MS Version    |     FALSE             FALSE
> ; --------------------------------------------------------
> ;  Clone Version |     TRUE              FALSE
> ;
> IBMVER     EQU     TRUE
> IBMCOPYRIGHT EQU   FALSE
   
   (Pieces of the DOS source code are among the treasures that I have got
from some BBS in Moscow about 5 years ago.)
   
   By default the switches are set to the "Clone version", which is what
you actually get when buy a box labeled "MS-DOS v6.22". The IBM version is
obviously what is known as PC-DOS or IBM DOS. What the source code calls
the "MS version" to my knowledge has never shipped, except possibly in the
days of v1.xx or maybe v2.xx. This means that all versions of DOS in common
use have been built with IBMVER set to TRUE. That's what makes them look we
way we are used to. If you set IBMVER to FALSE, the results will be quite
spectacular. I bet that you have never seen anything like that. The DOS
version message will be displayed at boot time even if you do have
AUTOEXEC.BAT, INT 25H/26H won't return IBM ROM BIOS-style error codes in
AH, CLS won't work unless you have ANSI.SYS loaded, INT 21H/AH=0AH won't
handle F1-F6, etc. The only difference between "MS-DOS" and "PC-DOS" is the
setting of the IBMCOPYRIGHT switch, which only changes what the system is
called (the VER command, IO.SYS & MSDOS.SYS vs. IBMBIO.COM & IBMDOS.COM,
and "MSDOS" vs. "IBM" in the boot record).
   
   As for DOS workalikes like DR-DOS, compatibility with the real DOS is
their problem. Some of them actually handle it quite well, reproducing
nearly all of DOS's undocumented internals. For appy projects like this
one, I need only as much as necessary to do True DPMI, and as it happens
Novell DOS v7.00 _COMES_ with a True DPMI implementation already, so it
should work beautifully. (I have to remark that Novell's DPMI host is
significantly slower than Microsoft's, however.)
   
   As for the DOS version, True DPMI requires at least 3.00 and some things
I often use require at least 3.10. It makes absolutely no difference to
virtually all of my software whether you are running v3.30 or v6.22.
   
> All of which is fine: for your personal use you can do whatever you
> want with the Lynx code, and you don't even have to distribute it,
> contrary to Fote's misiniterpretation of the GPL.
   
   But like Fote, I WILL redistribute it, so that if someone wants to be
just like me, he/she will be able to.
   
> But don't expect the rest of us to jump on your bandwagon [...]
   
   Do you think I really care what you jump on?
   
> All of this notwithstanding, I think DOSSOCKS is a great idea.
   
   Thank you. BTW, it is called "DOSSOCK", not "DOSSOCKS". Omitting the "S"
makes it sound like a direct challenge to WINSOCK (which is exactly what
I'm after) and avoids any confusion with SOCKS, a proxy mechanism.
   
> It would have been great to have around 1992--1993 [...]
   
   Time has zero meaning for me. Have you read Clifford Simak's (I think
this is the right spelling) science fiction? He had an interesting idea
about a continuum of parallel worlds, which can differ in time by any
amount and between which people and objects could move freely if they knew
how. That's what I am doing: living in a parallel world shifted from yours
by somewhere between 5 and 15 years. Anyone is welcome to join me. You
don't even have to rotate the spinner (or whatever it's called, I have read
the novel in a Russian translation).
   
> [...] it could still be
> of benefit today to a lot of people for whom DOS-only is still a real
> requirement for financial reasons (e.g. elementary schools, developing
> countries, starving graduate students).
   
   Or to those who don't do Windows or any other psychedelic drugs.
   
> So _please_ don't make the
> development of DOSSOCKS contingent upon the rest of your
> fundamentalist agenda!
   
   First of all, "SOCK" stands for sockets. The credit for these belongs
solely to BSD. Since I want DOSSOCK to be as close to the original BSD
sockets as possible (to easy the porting of BSD network software to DOS
obviously), I will need to obtain a copy of BSD first. However, I will have
to do this anyway: without a copy of BSD I can't complete the Harhan
Project at CWRU, and until it's complete I will be unavailable for any
other projects. (As I have said before, if I don't make the Harhan Project
my topmost priority, I will be ousted and there will be no more projects.)
   
   Other than that, the development of DOSSOCK doesn't depend on anything.
It certainly doesn't depend on Lynx (it's the other way around!), and as I
explain below it doesn't depend on my 32-bit protected-mode work either.
   
> Use an existing compiler, don't make your True
> DPMI a higher priority, just get a working DOSSOCKS out the door as
> soon as you can.
   
   There will be three things that I'll "get out the door":
   
   1. The DOSSOCK specification, a paper prescribing the API between
DOSSOCK hosts and clients.
   
   2. Several DOSSOCK host implementations. One of them will be an actual
TCP/IP stack implementation, and others will be shims around some existing
DOSSOCK-like APIs.
   
   3. Interface libraries for writing DOSSOCK clients in C.
   
   DPMI will not be involved in any way, neither the True nor the Castrated
one. "PM" stands for protected-mode, and DOSSOCK will reside completely in
the 16-bit real-mode DOS land. (BTW, True DPMI isn't mine. It is a product
of the genius of Ralph Lipe, Microsoft. As for Castrated DPMI, say thanks
to Bob Moote, Phar Lap. He has sliced off the biggest piece.) Protected-
mode DOSSOCK clients will need to use the DPMI translation services to call
the DOSSOCK host.
   
   Now for the tools. The first item will be a paper, so it obviously won't
require any tools to use (except eyeglasses, if you like me have ruined
your eyes in front of a monitor :-)). The hosts (the second item) will be
written in assembly language and distributed in both source and executable
forms. If you want to reassemble them, you will need MASM v5.10 or higher,
but I see no reason why you would need to do that. Certainly you don't need
to do anything with the host sources to develop a client. In fact doing so
would defeat the whole purpose of the API (making clients independent of
any particular host implementation), and you are very ill-advised to do so.
   
   The third item is needed because socket() means absolutely nothing to
your C compiler, regardless of whether you have DOSSOCK or not. If you want
to have socket() and other related functions, you need a library
implementing them, even if all it does is to call the appropriate DOSSOCK
API functions. Since different operating environments and compiler run-time
environments use wildly different techniques for accessing external APIs,
each requires its own interface library. I will make such libraries for 16-
bit real- and protected-mode DOS apps using the Microsoft C v6.00 run-time
environment and for 32-bit protected-mode DOS apps using the run-time
environment I plan to develop for my apps. If you want to use some other
run-time environment, e.g., DJGPP's, you will have to write an interface
library for it, working directly with the DOSSOCK spec and perhaps using my
libraries as a guide. This will definitely require a solid knowledge of
DPMI. If you don't have it, your other option would be to use the version
of gcc that I will probably make available for use with my environment. I
don't know exactly what languages and compilers will I use for my
libraries, but in any case I will provide prebuilt libraries and you will
have no need to rebuild them.
   
> Looking at your current plans for development, my
> guess is that your DOSSOCKS and True DOS Lynx will never come to be
> because of the additional requirements for ritual purity you are
> imposing on them.
   
   The above description probably seems daunting to you, but this has
nothing to do with "ritual purity", it's just hard work necessary to
develop and implement an API that is independent of any particular
implementation and does not require all pieces to be rebuilt in order to
rebuild one of them.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]