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

[Michael Sokolov]

   The_guy_who_is_too_ashamed_of_himself_to_reveal_his_name
<address@hidden> wrote:
   
> Hey, I have a great idea about how you can get a Dos version of
> lynx to use the winsocket dll under Windows.
>
> First you write this `terminate and stay resident' Windows program
> that does a LoadLibrary of the Winsocket dll, then builds a table
> of function addresses for the winsocket library and uses `putenv'
> to put the addresses out to the Dos environment.   The dll then
> goes into a GetMessage loop (the TSR part), and you can then call
> your Dos application, whose startup code goes to the environment
> and finds these addresses.  On completion, the Dos app uses a
> function call in the TSR to unload the dll and end the TSR.
>
> Whoops, this is protected mode, and you can't use those addresses,
> or can you?
   
   This is much more complicated than you describe. First of all, Windows
(which is just an ordinary DOS app like Lynx) runs in one VM (virtual
machine) under DOS386 and something like Lynx would run in another, so OF
COURSE pointers returned from GetProcAddress() in Windows' VM will be
completely meaningless in Lynx's VM. If we were talking about accessing
data in a different VM, a conversion would be possible. You would first
need to convert the selector:16-bit-offset address returned from
GetProcAddress() to a linear address by using GetSelectorBase() or the
equivalent INT 31h function. In the DOS386 environment (which Enhanced mode
Windows runs under) linear addresses can be high or low. High linear
addresses are valid in all VMs, and low ones only in the VM they originate
in. Because of the way the Windows global heap works, the linear addresses
of Windows segments may very well be low. You can convert a low linear
address to a high one by adding the starting high linear address of the
originating (Windows') VM, which you can get with something like Andrew
Schulman's Generic VxD. Since Lynx is a 32-bit DPMI client, it can use a
high linear address directly. If it were a 16-bit DPMI client, it would
need to create and map a selector using INT 31h functions. If it were a
real mode program, this would not be possible at all.
   
   However, we are talking about calling code, not accessing data. While I
guess it's theoretically possible to make an inter-VM call given a high
linear address, the callee will be executed in the context of the wrong VM,
and if it's Windows, things are certain to go up in smoke immediately. For
inter-VM calls you really need an actual VM switch. Arranging one in an
orderly fashion requires writing a special VxD.
   
   As for using the environment to pass information from a Windows program
to a DOS box, just forget about it. The environment goes from parents to
children ONLY. As far as the operating system (DOS386) is concerned, all
the Windows GUI is just one big app, while programs running in DOS boxes
are separate apps. When you call WinExec() on a DOS program (starting a DOS
box), the DOS program you are starting does NOT become a child of your
Windows program. Instead, it's more of an uncle! (Not even a sibling, since
while Windows apps are separated from the operating system by the Windows
KERNEL layer, DOS apps enjoy talking to the operating system directly, thus
being one level higher in the process hierarchy.) The environment the first
program in a DOS box gets is NOT that of the Windows program that has
initiated the opening of the DOS box, but that of the DOS386 parent process
(which is frozen shortly after VMM sends out the Init_Complete control
message and tosses the initialization pages, long before the Windows KERNEL
even gets started).
   
   None of this is really an issue, since a VxD is required anyway and can
be used to pass the addresses too. And yes, writing such a WINSOCK-to-
DOSSOCK adapter VxD is in my plans. I have the necessary tools, skills, and
experience.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden