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

[Michael Sokolov]

   Dear Heather,
   
   You 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.
   
   I think that what this twit had in mind was not really a DOS TSR, but a
Win16 task spinning in Windows' VM.
   
> 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.
   
   This is not a benefit, but a VERY bad idea. In this scenario you first
have to forget about 32-bit DOS protected mode (DPMI) apps, since Windows
is a 16-bit DOS protected mode app and the two can never coexist in the
same VM (VMM will simply fail the real to protected mode switch call if you
try). Second, the environment the app will be executing in will be an
unbelievable mess. Just think about issues like process ordering by the PDB
parent links, INT 23h and INT 24h handling, processor exception handling,
floating point emulation and the related interrupts, etc. Oh, and where in
the world is the app going to get DOS memory from? When KRNL386 starts it
allocates all memory allocatable with INT 21h/AH=48h and turns it into its
global heap. The thing you are talking about will have to either allocate a
lot of memory via GlobalDOSAlloc() (which is a very bad idea, see Matt
Pietrek's _Windows Internals_) and build fake DOS arena headers there, or
hook INT 21h and turn AH=48h into GlobalDOSAlloc(), which is no better. I'm
astonished how does their kludge work even for a "Hello, world!" program.
Also even if you manage to get Lynx running under this kludge (by making it
16-bit, etc., etc., etc.), it still won't be able to call WINSOCK! Windows
code is absolutely unprepared for being called by anything that doesn't
work through KERNEL, and things will go up in smoke immediately if you try
that. This is the same reason why you can't just call Windows API functions
from a different VM by a high linear address.
   
> 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.
   
   But why not instead make Lynx a totally Windows-oblivious DOS protected
mode app and have VDD/VKD/VMD trap its I/O and put it in a window, the way
the DJGPP version works now? All your need to do is to replace Castrated
DPMI with True DPMI and write a library for accessing DOSSOCK from a True
DPMI app.
   
> 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.
   
   Heather, thank you very much for your support!
   
> 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
   
   Basically. A few fine points, though:
   
> (ethernet, packet driver? or dialup)
             ^^^^^^^^^^^^^^
   
   Either that or something that's a little more high-level and does ARP
and trailer encapsulations itself.
   
>     (DOS TCP stack that Michael plans to write)
   
   Or CWRU-PC/IP which has already been written. I'm still going to write
my own because CWRU-PC/IP sucks, but it works just fine as a temporary
solution.
   
>         Windows' startup
   
   I'm assuming that you mean WIN386.EXE, don't you? In this case please
pay disrespect to Adolf the Gates of Hell and call it DOS386. (I'm assuming
that you have read Andrew Schulman's _Unauthorized Windows 95_ cover to
cover, haven't you? See page 62 near the top.)
   
> WINSOCK.DLL (Michael's planned VxD shim)
   
   I'm assuming that you mean a WINSOCK.DLL that's a wrapper around
DOSSOCK, don't you? In this case it's a DLL, not a VxD. A VxD would be
necessary to work the other way around: take the WINSOCK services in the
Windows'' VM, tunnel them to another VM, and turn them into DOSSOCK there.
As you can imagine, I don't like this approach and vastly prefer the former
one, but one of my goals is to make the Win32 version of Lynx go away, and
that requires making the DOS version completely and totally supersede it,
which in turn requires giving users the option to use MS native networking.
Note that the latter can be achieved by means other than tunneling WINSOCK.
It appears that the MS native networking is really implemented in VxDs like
VIP.386, VTCP.386, etc., and that MS's WINSOCK.DLL is ALREADY a shim around
those! In this case it would be a better idea to implement DOSSOCK in terms
of those VxDs rather than WINSOCK.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden