rebase problem

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

ike - 28 Mar 2006 17:10 GMT

Hello,

I just read that using rebase will improve your application startup if you
have a lot of dll's that have the same base address.

So I opened up the command prompt and type the following
rebase -d -b 0x68000000 *.dll
and the result is that none of my dll's are actually rebased. I have checked
this with 'depends'.

Does anybody have an idea of what I am doing wrong here?

Thanks,
Ike Casteleyn

Reply to this Message

Willy Denoyette [MVP] - 28 Mar 2006 17:37 GMT

Not sure what kind of DLL's you are rebasing, but if they are managed
assemblies this make no sense at all, managed modules are based by the CLR
not by the OS loader.

Willy.

| Hello,
|
[quoted text clipped - 10 lines]
| Thanks,
| Ike Casteleyn

Reply to this Message

ike - 28 Mar 2006 18:39 GMT

Hi Willy,

That's right, it are managed assemblies. I read this in an article of msdn
magazine about about improving application startup. The command in the
dos-prompt came from

But you're saying that managed assemblies should never be rebased. Even if
you have over 50 dll's all on the same base-address.

What is the use of the rebase tool then (since it's in the .net framework
sdk). Only for ngen-ed assemblies? Because I thought that the ngen would take
the base-address from the jit-assemblies.

But then again I couldn't change the base-address via the project properties
(build -> advanvced).

Best regards,
Ike

> Not sure what kind of DLL's you are rebasing, but if they are managed
> assemblies this make no sense at all, managed modules are based by the CLR
[quoted text clipped - 17 lines]
> | Thanks,
> | Ike Casteleyn

Reply to this Message

Willy Denoyette [MVP] - 28 Mar 2006 19:35 GMT

| Hi Willy,
|
| That's right, it are managed assemblies. I read this in an article of msdn
| magazine about about improving application startup. The command in the
| dos-prompt came from

I know this article, but don't expect too much from rebasing at this level,
the gains are marginal to non existant, only extremely large assemblies will
take some advantage of it.

| But you're saying that managed assemblies should never be rebased. Even if
| you have over 50 dll's all on the same base-address.

Managed assemblies are loaded by the CLR's class loader not by the OS
loader, and it's the JIT compiler who knows exactly how maps the jitted code
into a private process heap.

| What is the use of the rebase tool then (since it's in the .net framework
| sdk). Only for ngen-ed assemblies? Because I thought that the ngen would take
| the base-address from the jit-assemblies.

Yes, it's only valid for ngen'd DLL's (take a look at the framework
assemblies, they are all rebased).

| But then again I couldn't change the base-address via the project properties
| (build -> advanvced).

Don't know about this VS option, but rebase.exe (or editbin.exe) works for
me, note that you should use dumpbin.exe to watch the base address (see:
OPTIONAL HEADER VALUES - image base) of a PE file.

Willy.

Reply to this Message

ike - 28 Mar 2006 21:59 GMT

Hi Willy,

Thanks for all the info.

Best regards,
Ike

Reply to this Message

rebase problem

Free Magazines