[Top][All Lists]

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

Re: lynx-dev How to get Dos lynx to use the Windows winsocket dll

From: Michael Sokolov
Subject: Re: lynx-dev How to get Dos lynx to use the Windows winsocket dll
Date: Sat, 9 May 98 01:34:06 -0400

   Dear Heather,
   You wrote:
> >    I think that what this twit had in mind was not really a DOS TSR,
> > but a Win16 task spinning in Windows' VM.
> There would still be some memory cost in the DOS-box, if he hopes to have
> it bridge between the two.  There'd be the inter-VM switch mechanism you
> mentioned, and it would cost something.
   In this case "something" is not DOS addressable memory but VxD code that
is global for all VMs and doesn't consume address space in any of them. In
any case none of this has any relevance to our work on Lynx.
> I've been reading horror stories at attempts to run DJGPP stuff
> co-existent with other protected mode apps.
   I think you are talking about the eternal LIMulator / multitasker / DOS
extender conflict. In our case, however, DJGPP is DPMI-based (yes, it's
Castrated rather than True, but still DPMI), and instead of conflict we
have perfect harmony: running DPMI clients is EXACTLY WHAT DOS386 HAS BEEN
> Sounds like it would cost extra resources
> for the trapping.
   Only if the DOS box is running in a window, and even then the resources
required are minimal. If the DOS box is running in full screen no trapping
is necessary at all. But most importantly, your suggestion of turning
Lynx's output into Windows GUI API calls will not reduce resource
consumption by a bit! As long as Lynx is 32-bit it will require a separate
VM, and all the resources needed are allocated at the time one is created
(in the Create_VM control message), so if you don't use the VM mechanism
for your screen I/O the resources allocated for it at start-up will simply
be wasted!
> I think depending on the unusual feature of one compiler (though it
> sounds nifty) may also be a less than wonderful idea for portability.
> OTOH if they can provide these "modules" I describe at a level that's
> usable to plain Joes, and users of other compilers, rather than having
> to be special to each app, that's cool.
   What are you talking about?
> My concept would be for the MS' flavors, to seperate the "display"
> functions from the action functions (like termcap terminfo ncurses or
> slang now?  Having not delved, I suspect that division is already in
> place)... and take advantage of it, by having the same main part usable
> if you're in or out of Windows.
> Outside, it would call a DOS display-module (probably pretending to be
> curses? Maybe someone can steal the applicable portions of the rogue,
> nethack, larn or moria code for DOS?) [...]
> Inside, it would call a DLL which would initialize a fixed-proportion
> screen of nice size (maybe "nice" would even be user definable?), and
> make MSwin calls to do all the dirty display work.  It would use WINSOCK
> calls... therefore it should be invisible to the user whether it use
> AOL's shim over its dialup, your DOSSOCK shim, or some other
> implementation.  Unless of course the "stack" (WINSOCK) version they use
> is broken.
> People who feel like abusing their disk space could possibly have both in
> a single family mode app: "Lynx for Microsofty OS'" as I put it.
> If the DOS "display module", and the MSwin DLL "display module" had
> exactly the same calls, this would end the agony of MS-DOS, Win3.x,
> Win32s, Win95, and WinNT all possibly being wildly different ports.  (I
> think we're lumping 95/NT together the way it is right now, dunno about
> 32s.)  With these and pssibly the SOCK calls being the same a family mode
> app wouldn't cost much extra.
> Beyond that if the "display modules" were sufficiently like one of the
> display flavors we already handle, we could stop having to think of the
> MS flavors as a nasty porting issue.  It would certainly be less
> important to depend on a wild feature of DJGPP, and would likely make
> many other UNIX apps far more portable as well.  If it also spoke ANSI,
> folks might consider it a flavorful replacement for ANSI.SYS, provided it
> has a small enough memory footprint.
Specification for network access and the DOS screen for console. People
wishing to use WINSOCK will have a WINSOCK-to-DOSSOCK adapter available to
them, and the screen will be taken care of by the VxDs that ship with
Windows itself. Do you have any sound objections to this approach? I have
already refuted your argument about resource consumption above.
> your DOSSOCK (or the CWRU version until you're done writing it)
> This would surely restrict it to usable only within the confines of the
> DOS-box rather than in a DOS which has no MSwin installed or running?
   I guess you are misunderstanding me. There will be only ONE (1) DOSSOCK
Specification, and only one version of each DOS network app (TELNET, FTP,
Gopher, Lynx, etc.) My software offerings will include several different
implementations of the spec, however. One of them will be a zero-
prerequisite TCP/IP stack and all others will be shims around existing
DOSSOCK-like APIs. I currently plan to write DOSSOCK shims around the
following APIs:
   1. CWRU-PC/IP's proprietary API.
   2. WINSOCK running in a different VM.
   3. The VxD APIs Microsoft's WINSOCK.DLL is implemented in terms of.
   In general #2 supersedes #3, but when it's available #3 is much faster
and that's why it's worth implementing. Just remember, though, that none of
this should matter for Lynx. There should be only ONE (1) version of Lynx
for DOS which adheres to the abstract True DPMI and DOSSOCK specs and
doesn't care one way or another who implements them: a bunch of DOS TSRs,
Windows, OS/2 or NT box (oh, in case you don't know it NT is much closer to
OS/2 than to Windows), or whatever.
> A simple matter of wanting networking at the lowest possible level in the
> system, close to the bare bits.
   Yes, this is one of the main points. Exactly the same can be said about
the protected mode engine (using True DPMI instead of all these
Win16/Win32/whatever kludges) and the console (using the DOS screen instead
of Windows GUI API, Win32 consoles, and other kludges).
> I meant the 12 or 15 pieces that make up the "core" of operations, of
> which DOS386 as you put it is the first portion.
   Assuming that by "12 or 15 pieces" you mean VxDs, the term DOS386
encompasses all of them, and "the first portion" is called VMM. (And yes,
its VxD ID number is 0001h :-).)
> I really should
> get it one of these days... but w95 has such low priority in my life ;)
   It is not about Win95 at all! It is about the exact same thing that I'm
trying to convey to this list (that there is no such thing as Windows and
that all the work Windows gets credit for is really done by a new form of
DOS), except that Andrew Schulman's writing skills are lights years ahead
of mine. If you want to be of any help in my work on, as you put it so
nicely, "ending the agony of MS-DOS, Win3.x, Win32s, Win95, and WinNT all
possibly being wildly different ports," get this book and start reading it
now! It is absolutely fascinating reading!
> Being a DesqView fan I'm hoping for something that I can use across its
> multiple sessions.  It's a much better multitasker than MSwin.  Being a
> completist I'd like maximum usability with the least number of moving
> parts.
   I see absolutely no reason for any incompatibility between DOSSOCK and
DESQview. You'll need True DPMI, but Quarterdeck's QDPMI provides it
   As for DESQview's superiority, you have to be careful. Of course being
GUI, Windows is inferior to everything. However, as Andrew Schulman shows
it so wonderfully in _Unauthorized Windows 95_, whenever you start Windows
v3.00 or later in 386 Enhanced mode, you are loading a totally new version
of DOS with _NATIVE_ "32-bitness", multitasking, virtual memory, True DPMI,
32-bit disk and file access, and everything else. This is light years ahead
of ordinary multitaskers like DESQview.
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden

reply via email to

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