Mail Archives: cygwin/1998/02/19/16:35:14
Thanks, I had never seen the MS doc you quoted below,
and I guess Geoff hadn't either ;^).
I tried your rebase command on B18 and on cooview dll
and it didn't work on either?
Mar 97 SDK rebase.exe
win95b
so I had to rebuild from source to get the image to 0x61000000,
but this makes even more sense as a base address to me, see the comments
from RON below.
....cdk/winsup/Makefile
LD_STUFF += --image-base 0x61000000
MIKEY:/usr/H-i386-cygwin32/bin$ rebase -b 0x61000000 -d cygwin.B18_dll_fix
REBASE: *** RelocateImage failed (cygwin.b18_dll_fix). Image may be corrupted
REBASE: Total Size of mapping 0x00000000
REBASE: Range 0x61000000 -0x61000000
MIKEY:/usr/H-i386-cygwin32/bin$
B18 ld.exe never marks dll's as dll's and
B18 strip.exe removes the DLL bit from the characteristics field in the file
header, if it exists, so after stripping the .reloc section, use your favorite
binary editor to change the byte at 0x97 from
00 00 00 00 E0 00 0F 01 B0
to
00 00 00 00 E0 00 0F 21 B0
this will mark the image as a DLL and allow faster
unloading.
Unfortunately win95 still won't relocate dll's that try
to load after cygwin.dll in this address space
(at least on my system), so make sure
any dll's you build don't overlap whatever address space
you choose for cygwin.dll.
BPE Version 1.3 cygwin.B18_stripped_dll (C) 1988 MSS Graz
COMMAND : Rel. Position : 00000000
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
===============================================================================
00000000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ..............
00000010 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 ................
00000040 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 ........!..L.!Th
00000050 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F is program canno
00000060 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t be run in DOS
00000070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode....$.......
00000080 50 45 00 00 4C 01 05 00 45 04 EB 34 00 00 00 00 PE..L...E..4....
>>>>>> 00000090 00 00 00 00 E0 00 0F 01 0B 01 02 37 00 34 04 00 ...........7.4..
000000A0 00 70 00 00 00 16 00 00 68 2C 01 00 00 10 00 00 .p......h,......
000000B0 00 50 04 00 00 00 00 10 00 10 00 00 00 02 00 00 .P..............
000000C0 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 ................
000000D0 00 00 05 00 00 04 00 00 00 00 00 00 03 00 00 00 ................
000000E0 00 00 00 02 00 10 00 00 00 00 10 00 00 10 00 00 ................
000000F0 00 00 00 00 10 00 00 00 00 90 04 00 3C 46 00 00 ............<F..
On Tue, 17 Feb 1998 09:32:16 -0600, you wrote:
>>Read here:
>>>>Geoff I would recommend using --image-base=0x78000000
>>>>for cygwin.dll same as MSVCRT.DLL which is relocatable
>>>>and should never be loaded in the same VM anyway.
>>>
>>>You can move the base yourself if you have MSVC's editbin program:
>>>
>>> editbase /rebase:base=0x78000000 cygwin.dll
>>>
>>>Do this before you strip the .dll...
>>
>>IMO, this is not a good address to rebase cygwin into. You are correct that
>>it is used by msvcrt.dll. However, all applications which load cygwin.dll
>>load msvcrt.dll. You must realize that much of the operating system was
This is only true if you use winsock 2.
>>linked to msvcrt.dll. If you look check it out, you will see the following
>>dependency chain:
>>
>>cygwin.dll --> wsock32.dll --> ws2-32.dll --> msvcrt.dll
>>
>>I discovered that both DLLs were being used while using Jeffrey Richter's
>>liposuction32.exe on ls.exe. I did a little digging of my own to find the
>>source of this behavior.
>>
>>Therefore I would recommend using the following command to rebase cygwin.dll:
>>
>>rebase -b 0x61000000 -d cygwin.dll
>>
>>This will map cygwin.dll at the upper end of the 0x60000000-0x60FFFFFF range
>>in accordance with the recommendations from Microsoft. The MSDN Library's
>>description of the rebase program contains the following
>>A well-behaved application has its DLLs rebased so they each fall within a
>>unique range of the virtual address space. The system DLLs are currently
>>based in memory from 0x70000000 to 0x78000000 (0x68000000 to 0x78000000 on
>>MIPS). Therefore, you should base your DLLs from 0x60000000 to 0x68000000.
>>One possible scheme is to choose a base address based on the first letter of
>>the DLL name, as shown in the following table.
>>First Letter Base Address
>>A - C 0x60000000
>>D - F 0x61000000
>>G - I 0x62000000
>>J - L 0x63000000
>>M - O 0x64000000
>>P - R 0x65000000
>>S - U 0x66000000
>>V - X 0x67000000
>>Y - Z 0x68000000"
>>
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
=====================================================
Linux a platform built by, and for users, standing on
the firm legs of reliability, and speed.
Microsoft Windows, a platform without a leg to stand on.
(jeffdbREMOVETHIS AT netzone DOT com)
delete REMOVETHIS from the above to reply
Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -