Re: How to get imagebase after a DLL gets loaded


"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message
news:1165653114.737755.43110@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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*,

The author of a useful library routine that is running within the dll may
NOT be the author of the "DLL MODULE ITSELF".

The source code may have been copied from another project, pasted in from a
database of snippets, linked-in from a static .lib, or be executing from
within some other .DLL.

It seems like you have not written much code that was reused, because
otherwise the value in this would not be so hard for you to see.


As
I said, in latter case use of VirtualQuery() may be justified if you
don't know the name of the target module

For library writers, not only do they not know the name of the target
module, they do not know the names of any of the variables within the
module.

Unless the library writer requires the user of the code to instantiate a
variable using a specific name, so that it is resolved at link-time.

One alternative is for the library writer to simply obtain the necessary
values at run-time, from within the library.



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,

Hopefully now you can see that there are cases where the author of code
executing in a DLL is not necessarily the author of the DLL.

If the goal is code-reuse -- which all library writers strive to maximize --
then eliminating things like InitCommonControls() is a Good Thing.



so that
the whole discussion is all about why (and if) such design may be
justified

Hopefully now you can see that obtaining a value at run-time vs. storing the
value at start-up can be a beneficial trade-off.

The trade-off is 100,000 GetProcAddress calls in 1/4 of a second, vs. the
time spent tracking down unresolved external errors because the library
routine expects "extern HINSTANCE
mySuperFancilyNamed_Variable_For_Holding_The_HINSTANCE".



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

A "client" is a "user of" something.

A "client" of a "library" is an executable: exe, dll. .

The author of the executable may not be the author of all the code in the
executable. Some of the code within the executable may have been written by
someone else.

William uses the design pattern of obtaining a value at run-time within his
library routine, so that clients of his library routine do not need to
instantiate specially-named variables, or call an otherwise unnecessary
initialization routine.

It sounds like William writes the kind of code that other programmers could
find useful, so I can understand how that does not make sense to you.



.

Relevant Pages

  • Re: How to get imagebase after a DLL gets loaded
    ... within some other .DLL. ... library routine, so that clients of his library routine do not need to ... We are speaking about obtaining and using DLL module's base address ... executing in a DLL is not necessarily the author of the DLL. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Accessing global variables in EXE from DLL
    ... > file from a DLL? ... void __declspecdllfunc; ... int __declspecjunk; ... less ignore) some error messages while executing the following steps: ...
    (microsoft.public.vc.mfc)
  • Re: Passing info between a DLL and an app
    ... problems executing dlls in Delphi. ... dll execution problems. ... RiseOrSetSw, passmmddyyyy: string): string; ... hDll: THandle; ...
    (alt.comp.lang.borland-delphi)
  • Re: Passing info between a DLL and an app
    ... problems executing dlls in Delphi. ... dll execution problems. ... RiseOrSetSw, passmmddyyyy: string): string; ... hDll: THandle; ...
    (alt.comp.lang.borland-delphi)
  • Re: how to get the handle of the current dll module?
    ... >I have a routine A which is part of a DLL. ... >The problem is that in my case I don't know that name of the DLL module (it ... other than saving the HINSTANCE hinstDLL parameter of the ...
    (microsoft.public.pocketpc.developer)
Loading