Re: How to get imagebase after a DLL gets loaded

Kevin,

I am really sorry, but you don't seem to change - again, you jumped
into a discussion without having a slightest idea what it is all
about......

Here, try this... imagine that you have written a very useful library
routine, and it requres the hinstance. Can you predict what name the
application programmer will choose for the variable they use to store the
hinstace passed to DllMain?

We are speaking about obtaining and using DLL module's base address
*FROM WITHIN DLL MODULE ITSELF*, rather than from its client code. As
I said, in latter case use of VirtualQuery() may be justified if you
don't know the name of the target module (theoretically you may come
across such scenario if a client code registers a callback with your
code, so that you have a function address, but no name of the module
where it is implemented)

However, Will said that VirtualQuery() may be used for this purpose
*FROM WITHIN* the target DLL module as well, which started off our
discussion. This is nothing more than just illogical design, so that
the whole discussion is all about why (and if) such design may be
justified

Your whole post is all about obtaining DLL's based address from its
client code, and, hence, is totally unrelated to our discussion......


Anton Bassov


Kevin wrote:
"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message
news:1165211679.739916.323950@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
As I have tried to tell you - if you one doesn't have an instance handle,
or
where one would not like to bind modules too tightly by having them share
globals, it comes in handy.

Again, faulty logic.....

Here, try this... imagine that you have written a very useful library
routine, and it requres the hinstance. Can you predict what name the
application programmer will choose for the variable they use to store the
hinstace passed to DllMain?

If your answer is "yes", then your library routine will be used by only you
and those upon whom your coding conventions can be impressed, or it will
require all future programmers to instantiate and initialize the variable
with the predicted name, henceforth and forevermore.

If your answer is "no", then your library routine can be used by anyone,
anywhere.





Instance handle gets passed to your DllMain(), and saving it in a
global (i.e. module-level) variable does not require sharing variables
between modules.

Sharing variables between executable modules is only one instance of sharing
variables. The most common way variables are shared is between translation
units, via "extern".



Under these circumstances, your statement about
"binding modules too tightly" just does not apply, and, hence, the one
about "not having an instance handle" implies nothing more than just
illogical design

The logic is this: have the library routine obtain the value of a variable
at run-time, instead of requiring the caller-of-the-library routine to
instantiate the variable using a specific name.

Library code that requires applications to store variables on their behalf
are unfriendly, and less likely to be used.

It is simpler to have the client-code obtain the value at run-time,
especially for cross-platform routines.

Imagine if every library required every app to instantiate every global
variable they need!!!



On this AMD Sempron 3000+ box which runs XP/SP2 I ran a toy application
which called GetModuleHandle() and VirtualQuery() 100,000 times.

And, again, faulty logic -

Snipped the remainder of your response, because it does not pertain to
sharing variables among translation units via extern.


[begin quote]

Sorry, I just overlooked the fact that the target DLL has been written
by yourself.

Snipped the remainder of your response, because it assumes that the author
of the code-obtaining-a-value-at-runtime is also the author of the module.

The code could be a snippet from a database, or a copy/paste from working
code, or a c++ .h.




In any case, you just wasted you time on your test - more on this below

The trade-off is: require all client-code to use the same token "extern
hInstance" and require all container code to instantiate it named exactly
so, vs. using VirtualQuery() in the client-code when it is needed.




Well - the case I described - using it in an interactive application -
easily falls into the 95 per cent of unnecessary optimizations.

We are speaking about programming habits, rather than about performance
issues.

In which case, library-writers would do well to avoid what you suggest,
which is to require code that uses the library to instantiate variables on
behalf of the library-code.

Instead, library writers should minimize the footprint in application code
required to utilize the library.

Image if DllMain() had to assign the hInstance to every library it links to
that needs it.


<snipped incomprehensible irrelevancy>


Therefore, this is nothing more than just illogical design, which, for
the reasons better known to yourself, you are trying to justify

Library writers would do well to keep in mind the design pattern that
minimizes the amount of binding required between the library and the
application. Do not require callers of the library code to instantiate
variables on the library's behalf.




<snipped rude remark>

OK, I will say a sensible thing that I have already said - your
programming habits are poor, and your logic is faulty, at least judging
from what you have said on this particular thread. Do you need any
other sensible statements???

Hopefully you understand now why people that write code to be re-used make
the decision to not burder the caller with unnecessary instantiation of
variables easily obtained at run-time by the library itself.

.