Re: How to get imagebase after a DLL gets loaded

anton bassov <soviet_bloke@xxxxxxxxxxx> wrote...
David,

Anton, "library" != DLL.

This is true. However, we are speaking *STRICTLY* about DLLs here - as
I have said in my earlier reply to Kevin, if Will had said that he
plans to use his approach from within a static library, there would
have been no discussion whatsoever. However, Will *EXPLICITLY* said
that he wants to use his approach in a DLL, and Kevin says that Will's
approach is very usefull "when one does not want to share variables
between library and its client code".

It's actually the exact same scenario, just with different semantics.
If you'll note, William has already agreed that this is the case. You
are the only one that sees a distinction in design philosophy between a
static library written by someone else (what Kevin was talking about and
you agree with him about), a separate compilation unit written by
someone else (also what Kevin was talking about and what is the logical
equivalent of a static library from a design perspective), and a
separate compilation unit written by the same person (what William was
talking about).

Encapsulation is a handy software engineering tool.


but if he spoke about
static library.... well, then it is even more ridiculous, taking into
account my statement earlier on the thread (i.e. the one that I would
have no objections to anything if we were speaking about static
libraries).

Then why, oh why, are you saying that "everything you said in your post
is plain nonsense" if you agree? Kevin has talked SOLELY about static
libraries and the logical equivalent (shared source, such as cut&paste
and adding source files to the project) written by someone else, yet you
insult him.

Moreover, you stated several things that are incorrect, lending me to
believe that you don't really understand this issue at all:


* "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...."

Now, if by "private" you mean symbols that aren't externed (ie: static),
then this is true, but that's basically what Kevin went on to say
("During the process of building the DLL, the linker deals with
EXTERNs") and you disagreed, so I don't really know what your point is.


* "and these EXTERNs happen to be EXPORTS of some other libary that your
DLL links against. They cannot be in the client code, simply
because it is client code who links against your library and not the
other way around."

Incorrect. I have demonstrated this already in the code that I posted.
Linking two compiled units (obj/lib) can involve importing/exporting
from any module, including both ways between two modules. The code
links *together*, not one linking to another in some kind of order. The
same is roughly true of DLLs, incidentally.

I have worked with a DLL that both exported functions to an EXE and
imported functions and variables (through the linker, not a function
pointer) from the EXE. (I did not design such a system -- it's a fairly
well-known open source application for which I wrote a proprietary
module.)

If you want to see a simple case for just functions going both ways,
look no further than secur32, which is imported by advapi32 and imports
from advapi32. Both are clients of each other.


* "Apparently, you just don't know it, but when you link against some
library, you need to have its .lib file, and this .lib file cannot get
built until all externals its source refers to are resolved..."

Incorrect. Heck, you even agreed it was incorrect in your followup to
my previous post. Library files can be created with unresolved
externals.


* "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."

Um, actually, this is /very/ common for static libraries and/or
distributed source code (unfortunately).

Now, here's the kicker: "the whole idea contradicts the VERY BASIC
PRINCIPLES of the structured programming" -- yet, you can't understand
why William doesn't want to share names of variables between two
compilation units. The *ONLY* difference between Kevin's scenario and
what William originally described is who writes the code, and possibly
how it gets linked.


* "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...."

Having had to maintain legacy C code with global variables shared across
compilation units, all written in the same module by the same team I
might add, I can tell you that it's a maintenance *nightmare*. Both
ways would *work*, as you point out, but shared globals should be a last
resort, used only when necessary.


and learn something before putting your foot in your mouth again.

It looks like, on this particular occasion, it was you and not me who
put your foot into your mouth - you jumped into a discussion without
even having bothered yourself to read this thread properly, and, as a
result, came up with totally irrelevant post (although technically
correct one - I don't argue about it)

OK, I did forget your statement that this technique would be valid with
static libraries. I have read this thread, although I'll admit most of
the time it was with you kf'd. Maybe if you had actually read what
Kevin wrote instead of assuming he mind-melded with William, I wouldn't
have gotten confused.

I still stand by what I said, though. Learn something about static
libraries before commenting on them. For example, you might learn that
you can import/export both ways between two modules, which you stated
was not the case, and which my post was correcting -- I showed you a
case where the linker used a (linker-level) export that was in the
client library, and showed where you could build a .lib file with
unresolved externals.

Your earlier statement about static libraries just makes your position
all the more confusing, especially since you keep referring to Kevin's
points as "nonsense" and "ridiculous", when you essentially agree with
the essence of them.

David
.

Relevant Pages

  • Re: How to get imagebase after a DLL gets loaded
    ... The main difference between DLL and static library in this context is ... so that it is not meant to be integrated with the client code ... SPEAKING ABOUT STATIC LIBRARIES HERE, AND I *EXPLICITLY* SAID IT THIS ...
    (microsoft.public.win32.programmer.kernel)
  • Re: How to get imagebase after a DLL gets loaded
    ... that he wants to use his approach in a DLL, and Kevin says that Will's ... Then create an EXE that links against it. ... libraries). ...
    (microsoft.public.win32.programmer.kernel)
  • Re: DLL and external references
    ... On Windows a DLL is not its own ... > other static libraries. ... > involved and intricate and creates a huge DLL (the original EXE, ... you need to create all those libraries ...
    (microsoft.public.vc.language)
  • Re: difference between lib and dll ?
    ... >> What is the difference between DLL file and LIB file? ... At image load time, Windows' loader loads the DLL into the address ... > function to an address as is the case with static libraries, ...
    (microsoft.public.vc.language)
  • Re: DLL and external references
    ... Thank you, I was trying mimic the shared library behavior from Unix, but ... I was trying to convert a static library into a DLL. ... other static libraries. ...
    (microsoft.public.vc.language)
Quantcast