Re: How to get imagebase after a DLL gets loaded

Kevin,

You are never going to change, are you????? To make things even worse
for yourself, you don't even seem to make an effort to educate
yourself. Look below:

The source code may have been copied from another project, pasted in from a
database of snippets,

Well, "highly professional" methods of code reuse - I am not surprized
at all.....

linked-in from a static .lib, or be executing from
within some other .DLL.

Surprisingly enough, but you mentioned the appropriate ways of sharing
code....


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.

Actually, I am in the kernel mode, so that there is not that much code
to share down there. In fact, apparently, this is why I immediately
noticed Will's illogical design - in the kernel mode you have to save
any piece of info that you may need, because you may be unable to get
it at the point when you need it (for example, there are not so many
routines that you can call at DPC level, and the number of ones that
you can call at DIRQL is much less than even that)....


For library writers, not only do they not know the name of the target
module,

Surprisingly enough, but this is true as well - if we are speaking
about DLL's, the library ABC that they write may be renamed to XYZ,
and, at this point, it will be appear under the name XYZ in the
address space of the target process, so that if makes a call to
GetModuleHandle("ABC") from its code, this call may fail.... Besides
that, the library may be just static, so that it may not have its own
name in the address space, in the first place

they do not know the names of any of the variables within the module.

Not suprizing at all - the above statement is plain nonsense....

Although you have no clue about names of variables in your client code,
how can you be unaware of the names of variables in DLL module that you
write???

Are you sure you understand what the term "module" means???


Unless the library writer requires the user of the code to instantiate a
variable using a specific name,

Insane idea...... More on this below.

so that it is resolved at link-time.

Again, nonsense - the only things linker deals with are EXPORTS.....
Objectively, it cannot know anything about non-exported stuff, so that
it has no clue about
the names of variables that are private to the library the code is
linked against....
Btw, why such obsession with names of variables, in the first place???
More on this below.


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.

In fact, the very idea of sharing NAMES of variables between the
library and its client code seems to be your very own "invention" - no
one, apart from you, has ever suggested doing something like that.
After all, the whole idea contradicts the very basic principles of the
structured programming. In other words, I am not surprized at
all..........



Actually, if you don't mind, could you please tell us why you believe
saving a module handle in a global variable may somehow involve sharing
variables between modules, in the first place???



It sounds like William writes the kind of code that other programmers could
find useful

If he said that he intends to use it in a code, exported by a *STATIC*
library, there would be no discussion whatsoever...

However, once static library does not have its own base address, the
whole thing would be just irrevevant in context of this thread, which
speaks about obtaining DLL's base address.
Therefore, he made it clear that he speaks about DLL modules...


.. so I can understand how that does not make sense to you

...and, hence, once we speak about DLLs here, his approach does not make
any sense, and not only to me....

Don't get me wrong - I am speaking strictly about logical design (in
practical terms, Will's
approach will work just fine in his case - I don't argue about that).
However, it does not necessarily mean that he should advertize it as
something usefull....

Anton Bassov



Kevin wrote:
"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
    ... We are speaking about obtaining and using DLL module's base address ... The author of a useful library routine that is running within the dll may ... NOT be the author of the "DLL MODULE ITSELF". ... 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: Build DLL using gfortran and with open/write/close statements in the code
    ... >> I had no problems after obtaining the latest version of ... >> Cygwin software currently installed on my system. ... > I don't have any problem either (the dll builds fine and I can compile ... > another program and link to this dll). ...
    (comp.lang.fortran)