Subject: Re: MUCH faster cygwin.dll
From: [email-masked] (Craig Dickson)

20 Feb 1998 00:42:52 -0800
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
To: <[email-masked]>

Mikey wrote:

>As I understand it, each 32 bit process gets
>it's own VM from create process.
>
>NT/9x kernel guru comments?

Yes, each 32-bit process has its own 4GB address space, which I think is the
crucial point you're aiming for.

>0x78000000 aka MSVCRT.DLL base
>would be preferred, since you CAN'T link
>both cygwin.dll, and msvcrt.dll (crtdll.dll 0x7fd10000) in the
>same image/VM, someday we MAY be able to link with
>mfcXX.dll ;^)

As I think someone else pointed out, you may get msvcrt.dll whether you like
it or not, so it's a bad idea to conflict with it. It's part of the OS, and
various other parts of the OS, some of them used by cygwin (Winsock, for
example) link to it.

>The speedup is from stripping the .reloc section.
>rebasing has no (or at most very minimal) effect
>on time spent in relocation processing.

Stripping the .reloc section is an incredibly bad idea. Anything that a
Win32 process does that REQUIRES a specific address range is risky, and will
probably fail from time to time. For one thing, other applications may
install system hooks that introduce one or more of their DLLs into your
address space. This is a totally legitimate, documented thing to do (see
SetWindowsHookEx in the Win32 API docs). You, obviously, have no control
over what addresses someone else's DLLs occupy. If you then try to allocate
their addresses (either by LoadLibrary of a non-relocatable DLL,
VirtualAllocEx or MapViewOfFileEx requesting a specific base address, or
whatever), your attempt will fail. Netscape 3.0 for Win32 can be crashed
this way. Fortunately, they seem to have fixed this in 4.0.

Absolutely NEVER assume that any particular range of addresses is available.
Corollary: All DLLs must be relocatable.

>On Tue, 17 Feb 1998 09:10:15 +1100, you wrote:
>
>>Once a dll is stripped of relocation information, it will only load if
>>the required address range (starting at the image base) is available.
>>Just changing the image base without stripping the relocation
>>information is safer.
>
>but much slower ;^)

Do you want to crash once in a while, or not at all? I prefer not at all.

Just to be clear on one related point: I am not saying that DLLs should not
be assigned optimal base addresses when linked. That's a good thing to do,
because relocating a DLL can be somewhat costly. But when that optimal base
address is not available, the DLL must be able to load elsewhere.

Craig

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".