Re: System-wide hooking, VB+ASM

"J French" <erewhon@xxxxxxxxxx> wrote in message
news:42a69292.7115503@xxxxxxxxxxxxxxxxxxx
>
> As it happens I know for a fact that DllMain is invoked when a Delphi
> DLL is instantiated for a system wide hook.

Yes, the DLL entry point, whether it is called DllMain or something else, is
called by Windows if it exists for the DLL, even for system-wide hooks. For
system-wide hooks it is called for each process the hook is used in and for
each of the reasons it is supposed to be called for.

> I do not agree that DLLs are just 'plain code', there is a fairly
> complex mechanism for initializing them (LoadLibrary springs to mind)
> also being 'under the hood' EXEs they need 'fixing up' - internally
> their addresses are relative
> - the system performs a little dance down the EXE turning relative
> addresses into absolute addresses.

Again, this is why it is important to have a term such as "Regular DLL" that
is understood by VB programmers as the type of DLL that originated in
Windows before OLE existed.

In order to understand what a DLL really is, it helps to understand the
history of linking.

For half a century (or nearly that long), compilers have generated object
files that have been combined into an executable by a link editor. The Unix
C compiler supports that process with command-line switches. The big IBM
computers that were initially designed in the 1960s had compilers that
generated code that had to be processed by a link editor (linker) and I am
nearly certain that their computers prior to the 1960s had compilers that
worked like that.

Originally, all the object files were combined into a single executable
file. That is called static linking. If any of the subroutines/functions
that are statically linked into an executable is changed, then every
executable that uses it must be re-linked. Every executable that uses a
subroutine or function has it's own copy of the compiled code for the
subroutine or function. Using VC, each input file (.c or .cpp file) produces
an object file as output and is combined into the executable file by the
linker. Also using VC, it is possible to create a project that creates
object files that are combined into a static link library, which is a file
with a .lib extension. Static linking was done by the DOS linker but dynamic
linking did not exist for the DOS linker. In those days, Turbo Pascal was
very popular but it was incompatible with other compilers because it did not
produce object files, not even for static linking. A DOS-style static link
library was essentially a collection of subroutines and functions compiled
as object files that could be read by the linker; the .lib files contained
the compiled code.

Compilers and operating systems began to support various mechanisms for
dynamic linking long before Windows, but as far as I know, Unix did not
support dynamic linking before Windows did. Windows did however support
dynamic link libraries from the beginning of Windows, as far as I know. When
subroutines and functions are linked by the Windows linker, they can be
written to a DLL as the executable. When the linker creates a DLL, it also
creates a lib file with information about the code in the DLL. Unlike a
static link library, the lib file for a DLL does not contain the code (of
course). When any of the subroutines/functions that are dynamically linked
by an executable is changed, then only the DLL must be relinked. All
executables using the DLL get the new version automatically.

LoadLibrary does nothing significantly more than providing access to the DLL
without use of the .lib file at link time.

You continue to insist that DLLs don't work like that, but you don't do a
little bit of reading to determine how accurate your understanding is. Look
at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp
In that page and subsequent pages is a description of DLLs that says mot of
what I have said. Most everything relevant to Windows is described there
with more detail then I have provided. Until you have read a few of those
pages, don't assume you know how DLLs work. Everything relative to this
discussion is there, at least as far as the description of DLLs independent
of VB.


.

Relevant Pages

  • Re: Can I use a DLL compiled with bcc with a program compiled with gcc?
    ... > Can I use a DLL compiled with bcc with a program compiled with gcc (on ... > program (on Windows). ... > no provision for open source compilers (library files ending with ...
    (comp.programming)
  • Re: Cannot activate sbcl
    ... but I think what happens is that Windows sees that your executable has a DATA section that might overlap a DLL's address space then it would reallocate that DLL to different address space. ... VirtualAlloc dynamically in your code is that your program and all its ... What can be done here is to have many tiny executables with different BSS sections in them, which then load a bigger executable in the form of a DLL. ...
    (comp.lang.lisp)
  • Re: [Full-disclosure] Linux big bang theory....
    ... OSX isn't using all of the tricks like windows does to try and hide ... Ever heard of dll ... Do you even know the purpose of using a DLL instead of an EXE? ... designed to hide executables for security reasons. ...
    (Full-Disclosure)
  • Re: Why do we need executables in certain formats ?
    ... > Can anybody explain me why do we need executables in certain formats? ... Modern virtual memory processors can locate to ... ..DLL files changed out from under them, ...
    (comp.lang.asm.x86)
  • Re: Dynamic linking with symbols
    ... And a dll which ... > two different executables. ... Try putting your "exported code" into a static library which your ... EXE links against. ...
    (microsoft.public.vc.language)