Re: ELF loading

rhyde@xxxxxxxxxx wrote:
On Aug 28, 9:08 am, CodeMonk <jas...@xxxxxxxxx> wrote:
Betov wrote:

Then why not add static linking to your assembler? You may have no
reason to use it, but it will certainly please some
Because i am not used to work for implementing stupidities,
even when when people want it, clown.

This deficiency could be addressed by wrapping the requisite LIB in a
DLL and using the LoadLibrary and GetProcAddress API functions. An
annoyance to be sure, but it's the only viable work-around I see.

Mind you, most of this was in jest for Rene's benefit. Even so, I don't think anything said will alter his determination to stay on his present course. It might be somewhat misguided, from a real world perspective, but he's definitely sticking to his principle.

There are many bigger problems than just the annoyance.
First of all, there is the version problem (also known as "DLL Hell").

In this case I had the benefit of instituting the philosophy of everyone always has the current approved version of everything. Easy to do when you have the keys to the chicken coop and roll everything out while the brood is asleep. I realize that isn't practical, or even possible, in most situations.

Second, there is the issue of size: loading a DLL gets you *all* the
routines, not just the ones you actually call.
Of course, there is also the issue that functions in a DLL must be
called indirectly. Often, this is done by linking in an extra JMP
instruction (admittedly, not necessary, but many tools wind up doing
this).

Also, DLLs carve up your address space inconveniently. A problem if
you have huge memory allocations or you use (large) memory-mapped
files.

All good points and contributors to the annoyance :) There's also the potential for exception and thread handling issues if any of those DLL's have HLL runtime dependencies which may collide with the Win32-API way of doing things.


Static linking avoids all of these problems.


I don't dismiss Rene's approach outright, as I myself have been known to paste a function into a module rather than link with the entire library. But yes, the ability to statically link with modules or libraries that programmers have neither the time, nor possibly the capability to reinvent, is a basic premise in the real world.

- Scott
.

Relevant Pages

  • Re: static linking (GDIPlus.dll) with an VC++ application
    ... the target machine. ... You can't statically link to a DLL. ... You may be confusing the situation with the 'C' and MFC libraries ...
    (microsoft.public.dotnet.languages.vc)
  • 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 a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (comp.lang.asm.x86)
  • Re: How to get a .lib from .dll
    ... Using the Borland tools, you should first run "IMPDEF" on the DLL file ... information in it to create ".LIB" import libraries with;)... ... from Windows version to Windows version...so, ...
    (alt.lang.asm)
  • Re: How to get imagebase after a DLL gets loaded
    ... During the process of building the DLL, ... Implementing a library that requires users of the library to instantiate ... predict what variable name you will use at initialization time. ... Some third-party libraries DO require that you instantiate a pre-defined ...
    (microsoft.public.win32.programmer.kernel)