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

[Heather Stern]

I ate the fortune cookie first, then read what 
MS == Michael Sokolov   and
vtailor == <address@hidden> wrote:
    
vtailor > Hey, I have a great idea about how you can get a Dos version of
vtailor > lynx to use the winsocket dll under Windows.
>
vtailor > First you write this `terminate and stay resident' Windows program
vtailor > that does a LoadLibrary of the Winsocket dll, then builds a table
[vtailor snipped]

If this uses memory space allocated to the DOS-box VM, you might run out of
memory for normal apps that might want the feature, even if you could get it
to work.  TSRs in general are famous for this problem.

vtailor > Whoops, this is protected mode, and you can't use those addresses,
vtailor > or can you?
    
MS>    This is much more complicated than you describe. First of all, Windows
MS> (which is just an ordinary DOS app like Lynx) runs in one VM (virtual
MS> machine) under DOS386 and something like Lynx would run in another, so OF
MS> COURSE pointers returned from GetProcAddress() in Windows' VM will be
MS> completely meaningless in Lynx's VM. 
>
[MS blurb about converting pointers and sharing amongst VMs snipped] 
>
MS> However, ... theoretically possible to make an inter-VM call given a high
MS> linear address, ... context of the wrong VM, ... certain to go up in smoke 
MS> immediately. For inter-VM calls you really need an actual VM switch. 
MS> Arranging one in an orderly fashion requires writing a special VxD.

This just occurred to me, has anyone tried running lynx for DOS under JP
Software's Take Command (TCMD)?
        http://www.jpsoft.com/
                side note: their tables actually look pretty good in lynx!

Its "caveman" is a VxD which runs the application in the same VM as standard
Windows applications.  The usual benefit is that DOS apps which use plain 
stdin and stdout (like PKZIP) don't force a new VM to be spawned.

I suspect strongly that lynx-for-DOS does direct screen addressing, and so
would not qualify for the caveman VM.  But a similar one, that provides screen
calls that are sufficiently slang-like, might be the road to a real lynx for
Windows.  If it had a companion "DOS screen driver" that answered the same 
calls (whether they were slang, or something not-quite) then the same code 
could be shared for the rest of lynx-for-Microsofty-OSs.

[MS more snipped]    
MS> ... . When you call WinExec() on a DOS program (starting a DOS
MS> box), the DOS program you are starting does NOT become a child of your
MS> Windows program. Instead, it's more of an uncle! 

This is why the idea of having the true TCP stack at the DOS layer, and 
providing a WINSOCK.DLL which is a shim over it, sounds more efficient, if 
you can get it to work.

To illustrate, the sequence becomes more like:  
(ethernet, packet driver? or dialup) 
    (DOS TCP stack that Michael plans to write) 
        Windows' startup
DOS-box VMs          WINSOCK.DLL (Michael's planned VxD shim)
                       WinApps sharing VM

Whoever was wondering about AOL -- no problem -- you would just tell AOL to
connect via TCP instead of dialing the modem.  It would make a winsock call.

MS>    None of this is really an issue, since a VxD is required anyway and can
MS> be used to pass the addresses too. And yes, writing such a WINSOCK-to-
MS> DOSSOCK adapter VxD is in my plans. I have the necessary tools, skills, and
MS> experience.

You're very vocal, Michael, but I'm eager to see the result.  I'm curious at
the end of it all, if the stack will also work effectively in a dosemu or bochs
BIOS emulation under my Linux boxes.  Of course both these also are improving 
at some unclear rate :)

  . | .   Heather Stern                  |         address@hidden
--->*<--- Starshine Technical Services - * - address@hidden
  ' | `   Sysadmin Support and Training  |        (800) 938-4078