[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: vtailor
Subject: Re: lynx-dev How to get Dos lynx to use the Windows winsocket dll
Date: Thu, 7 May 1998 05:19:02 -0500 (CDT)

>     * From: address@hidden (Michael Sokolov)
>     * Date: Thu, 7 May 98 02:05:53 -0400
>   The_guy_who_is_too_ashamed_of_himself_to_reveal_his_name
><address@hidden> wrote:
This is an explicit example of the kind of harrassment that certain
sick people like Sokolov and Foteos treat others to in this group.

And, besides, comrade Sokolov most certainly does know my name, seeing
that he and comrade Foteos and others on this group are part of the
secret communist network that was responsible for housing the murderer
Cunanen in South Miami Beach after the Versace murder.  I like to post
replies like this one to these egregious unwarranted insults so that
I can build a public record of what goes on when I enter a news group
or a private discussion forum.

Keep it up comrade Sokolov, and explain to all of us why you write such
a long diatribe when I was submitting a joke article.

You all know who I am.  I am the one who caused damage through telekinesis
to the Pentagon's northeast wing over a year ago, so that office workers
were evacuated and euphemistic signs announcing `remodeling' were posted.

I'm also the one whose name appears in bibliographies of the standard
computer science textbooks.

>> 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
>   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]