DLL Relocation
IGNACIO NICOLAS RODRIGUEZ -- irodriguez@envirolink.org
Wednesday, January 22, 1997
Environment: VC++ 4.0 ; NT 4.0
Hi!
I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
process memory space.
For they are COMponents, they are loaded dynamically (not more dynamicall=
y
than a pregnant elephant, may I say).
Do you (fellow list-reader) know where can I set the preferred loading
addresses for them, as well as where to? (So the loader doesn't say such =
a
thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be apreciated.
Ignacio Nicol=E1s Rodr=EDguez
irodriguez@envirolink.org
Nothing more powerfull, nothing easier than OLE/COM.
Nothing but OLE/COM.
Kenneth A. Argo -- argo@rias.COM
Friday, January 24, 1997
[Mini-digest: 8 responses]
There is a setting in the link settings dialog. Although I don't =
believe the performance loss is that great unless the DLL is large.
Ken
----------
From: Ignacio Nicol=E1s Rodr=EDguez[SMTP:irodriguez@envirolink.org]
Sent: Wednesday, January 22, 1997 6:15 PM
To: MFC List
Subject: DLL Relocation
Environment: VC++ 4.0 ; NT 4.0
Hi!
I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
process memory space.
For they are COMponents, they are loaded dynamically (not more =
dynamicall=3D
y
than a pregnant elephant, may I say).
Do you (fellow list-reader) know where can I set the preferred loading
addresses for them, as well as where to? (So the loader doesn't say such =
=3D
a
thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be apreciated.
Ignacio Nicol=3DE1s Rodr=3DEDguez
irodriguez@envirolink.org
Nothing more powerfull, nothing easier than OLE/COM.
Nothing but OLE/COM.
-----From: Mike Blaszczak
At 23:15 1/22/97 -0000, Ignacio Nicol=E1s Rodr=EDguez wrote:
>Environment: VC++ 4.0 ; NT 4.0
>I have these n MFC-COM DLLs with n > 2,
What is n?
>which end up mapped on the same process memory space.
Remap them. This is documented heavily: look for the REBASE tool
in help; look for the /BASE: option for the linker, look at the
/REBASE option on the EDITBIN tool. Usually, these topics have
links back to the SDK overview topics which explain what a base
address is and why it is important for you to set it up correctly.
>For they are COMponents, they are loaded dynamically (not more
>dynamically than a pregnant elephant, may I say).
Uh, okay.
>Do you (fellow list-reader) know where can I set the preferred loading
>addresses for them, as well as where to?
REBASE can figure it out automatically for your specific
system/application.
>Nothing more powerfull, nothing easier than OLE/COM.
Ice hockey, I think, is both easier and more powerful than OLE/COM.
All the problems can be expressed at a hockey game using some very
simple hand signals, while OLE/COM needs a huge 32-bit integer to
explain what went wrong.
You never see, for example, one OLE/COM programmer smash another
OLE/COM programmer into the boards. No OLE/COM programmers walk
around and throw interfaces at eachother at speeds in excess of 95
miles an hour. Fifteen thousand people in a dozen cities don't
get together every other night to watch OLE/COM programming
contensts, do they?
.B ekiM
http://www.nwlink.com/~mikeblas/
Why does the "new" Corvette look like a 1993 RX-7?
These words are my own. I do not speak on behalf of Microsoft.
-----From: "Lindholm, Jeff"
When linking we use /BASE:. Of course we use this
for DLLs I would assume a COM DLL should work fine as well. We actually
have a bunch on defines in our main makefile to ensure noone uses one
already being used (by us anyway).
Hope that helps.
>----------
>From: Ignacio Nicol=E1s Rodr=EDguez[SMTP:irodriguez@envirolink.org]
>Sent: Wednesday, January 22, 1997 6:15 PM
>To: MFC List
>Subject: DLL Relocation
>
>Environment: VC++ 4.0 ; NT 4.0
>
>Hi!
>I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
>process memory space.
>For they are COMponents, they are loaded dynamically (not more =
dynamicall=3D
>y
>than a pregnant elephant, may I say).
>Do you (fellow list-reader) know where can I set the preferred loading
>addresses for them, as well as where to? (So the loader doesn't say =
such =3D
>a
>thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be =
apreciated.
>
>
>Ignacio Nicol=3DE1s Rodr=3DEDguez
>irodriguez@envirolink.org
>
>Nothing more powerfull, nothing easier than OLE/COM.
>Nothing but OLE/COM.
>
-----From: "Gjevre, Kristoffer"
Go to Project Settings/Link tab/Output Category and set the Base Address.
>From Base Address in MSVC help:
>>This option sets a base address for the program, overriding the default
location for an .EXE file (at 0x400000) or a DLL (at 0x10000000). The
operating system first attempts to load a program at its specified or
default base address. If sufficient space is not available there, the
system relocates the program.
You can reduce paging and improve performance of your program by assigning
base addresses so that DLLs do not overlap in the address space.<<
Typically you do not want to change the default base address of an EXE.
>From description of Rebase in Win32 SDK Programming Guides and Tools:
>>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. It is best to base DLLs from the
top of the address range down, instead of from the bottom up. Dynamic
memory is allocated from the bottom up and if a DLL tries to load where
dynamic memory has been allocated, it will be relocated, just as if a DLL
was loaded at that address.<<
----------
From: Ignacio Nicolas Rodriguez[SMTP:irodriguez@envirolink.org]
Sent: Wednesday, January 22, 1997 15:15
To: MFC List
Subject: DLL Relocation
Environment: VC++ 4.0 ; NT 4.0
Hi!
I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
process memory space.
For they are COMponents, they are loaded dynamically (not more dynamicall=
y
than a pregnant elephant, may I say).
Do you (fellow list-reader) know where can I set the preferred loading
addresses for them, as well as where to? (So the loader doesn't say such =
a
thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be apreciated.
Ignacio Nicol=E1s Rodr=EDguez
irodriguez@envirolink.org
Nothing more powerfull, nothing easier than OLE/COM.
Nothing but OLE/COM.
-----From: Ted
Read the Visual C++ docs; the Build Settings Link tab allows you to=20
specify a preferred base address.
----------
From: Ignacio Nicol=E1s Rodr=EDguez[SMTP:irodriguez@envirolink.org]
Sent: Wednesday, January 22, 1997 3:15 PM
To: MFC List
Subject: DLL Relocation
Environment: VC++ 4.0 ; NT 4.0
Hi!
I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
process memory space.
For they are COMponents, they are loaded dynamically (not more=20
dynamicall=3D
y
than a pregnant elephant, may I say).
Do you (fellow list-reader) know where can I set the preferred loading
addresses for them, as well as where to? (So the loader doesn't say=20
such =3D
a
thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be=20
apreciated.
Ignacio Nicol=3DE1s Rodr=3DEDguez
irodriguez@envirolink.org
Nothing more powerfull, nothing easier than OLE/COM.
Nothing but OLE/COM.
-----From: "Otala, Tapani"
Either specify the base address in the linker settings
(Build|Settings|Link|Output|Base Address), or use the EDITBIN (comes
with MSVC 4.x) or REBASE (comes with Win32 SDK) utilities to modify the
base address at a later time. Personally I prefer the latter if I have
multiple DLLs that I do not want overlapping each other.
Tapani Otala
Canon Information Systems, Inc.
>----------
>From: Ignacio Nicol=E1s Rodr=EDguez[SMTP:irodriguez@envirolink.org]
>Sent: Wednesday, January 22, 1997 15:15
>To: MFC List
>Subject: DLL Relocation
>
>Environment: VC++ 4.0 ; NT 4.0
>
>Hi!
>I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
>process memory space.
>For they are COMponents, they are loaded dynamically (not more =
dynamicall=3D
>y
>than a pregnant elephant, may I say).
>Do you (fellow list-reader) know where can I set the preferred loading
>addresses for them, as well as where to? (So the loader doesn't say =
such =3D
>a
>thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be =
apreciated.
>
>
>Ignacio Nicol=3DE1s Rodr=3DEDguez
>irodriguez@envirolink.org
>
>Nothing more powerfull, nothing easier than OLE/COM.
>Nothing but OLE/COM.
>
-----From: David Razzetti
Ignacio -=20
In the Developer Studio, choose
Build | Settings | Link | Output | BaseAddress
Choose different base addresses for each DLL, taking into account both
the base address and size of each of the others.
Dave Razzetti
raz@jump-jet.demon.co.uk
To: "MFC List"
Subject: DLL Relocation
=46rom: "Ignacio Nicol=E1s Rodr=EDguez"
Date: Wed, 22 Jan 1997 23:15:14 -0000
Environment: VC++ 4.0 ; NT 4.0
Hi!
I have these n MFC-COM DLLs with n > 2, which end up mapped on the
same
process memory space.
=46or they are COMponents, they are loaded dynamically (not more
dynamicall=3D
y
than a pregnant elephant, may I say).
Do you (fellow list-reader) know where can I set the preferred loading
addresses for them, as well as where to? (So the loader doesn't say
such =3D
a
thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be
apreciated.
irodriguez@envirolink.org
-----From: Keith Bottner
This is easily set under the link tab in your project settings. You can
also run a command line utility called editbin with the respective BIND
directive to make all of your DLLS that you will be loading mapped into now
conflicting addresses.
Keith Bottner
kbottner@macromedia.com
>Environment: VC++ 4.0 ; NT 4.0
>
>Hi!
>I have these n MFC-COM DLLs with n > 2, which end up mapped on the same
>process memory space.
>For they are COMponents, they are loaded dynamically (not more dynamicall=
>y
>than a pregnant elephant, may I say).
>Do you (fellow list-reader) know where can I set the preferred loading
>addresses for them, as well as where to? (So the loader doesn't say such =
>a
>thing as "RELOCATING ; MAJOR PERFORMANCE LOSS") Help will be apreciated.
>
>
>Ignacio Nicol=E1s Rodr=EDguez
>irodriguez@envirolink.org
>
>Nothing more powerfull, nothing easier than OLE/COM.
>Nothing but OLE/COM.
| Вернуться в корень Архива
|