It was thus said that the Great Philippe Verdy once stated:
> So you just demonstrater that you just want to polemicate,
You said, and I'm quoting you here, "DLL modules on Windows, as well as on
OS/2, are based on directly on the ELF format," which runs counter to how I
understand computing history.
Microsoft first created DLLs for Windows, starting with version 1.0
(release in 1985). OS/2 (released in 1987) inherited the concept from
Windows (OS/2 being a joint project between IBM and Microsoft at the time).
System V, Release 4 (released in 1988), a combined project between AT&T
and Sun Microsystems, was when the ELF format was introduced. At best, one
could say that ELF was inspired by Windows DLLs, but what you said is ...
not based upon facts. That in turn, makes me discount what you say due to
the inaccuracy.
> you don't
> provide any useful help with your very shortsighted view when the
> discussion was much more generic...
> We were giving some examples, now you interpret the examples as being the
> only available options (which they are not, programmers will always invent
> new alternatives).
I initally four examples on two platforms, Linux and Solaris. Then Ivan
provided some of the examples on Windows. The results were:
mail() calls func1() calls func2()
func1(),func2() in same translation unit, in a library, providing myfunc2(),
static compilation:
Linux: failed to link
Solaris: failed to link
Windows: EXAMPLE NOT PROVIDED
func1(),func2() in different translations units, in a library, providing
myfunc2(), static compilation:
Linux: linked, run, myfunc2() called.
Solaris: linked, run, myfunc2() called.
Windows: lihked, run, myfunc2() called.
func1(),func2() in same translation unit, as a shared library, providing
myfunc2():
Linux: linked, run, myfunc2() called.
Solaris: linked, run, myfunc2() called.
Windows: EXAMPLE NOT PROVIDED
func1(),func2() in different translations units, as a shared library,
providing myfunc2():
Linux: linked, run, myfunc2() called.
Solaris: linked, run, myfunc2() called.
Windows: linked, run, func1() called (NOTE DIFFERENCE!)
So, what damn examples did YOU give that I interpreted as being the only
available options? Because I've seen very little in the way of actual
examples given, or citations to references, or anything from you.
Hmmmm... your examples are visibly fabriquek in your head. The description you make here even contain errors (results that are impossible to get). There's no source code given explicitly. The link options are not clearly given... All this is highly suspect (notably the last "example" shown supposed for Windows; otheres are not even tested in Windows, those for Linux/Solaris are not even correctly described).
And as well you don't seem to understand call gates and you seem to generalize the use of PIC code for everything which is not the default option (and in fact not the best one except for specific cases, like the CRT library that is extremely unlikely to be replaced safely unit by unit as its internal dependencies are very complex). But even in this case, call gates and PIC are unnecessary (except if you want to rebase the CRTDLL for "ASLR", something that is actually now proven to not offer real protection against external attacks by injection of code via buffer overflows on the stack causing return addresses to known RVA addresses instead of causing segmentation faults: this is the only thing that ASLR protects, but at the price of high paging because no DLL code is then actually shared across processes).
Call gates are not necessary to perform system calls (they are implemnted by software interrupts instead, without passing through virtual memory addresses, and implemented in different protection rings and the system itself is generally not pages out, or uses a different paging pool, independant of pageing pools used by user processes).
ELF and COFF have a common history, both have been used under Unix and even Linux; PE is also used in Linux ! Windows can supports ELF (MZ+PE is not the only option), ir also supports MZ+NE, MZ+LE and some variants still used for VXD drivers. COFF has many variants. ELF itself has its own variants (some extensions tried in Linux, then abandonned in Linux...). Anyway there's no funcamental differences between today's variants of ELF and COFF (the majhor difference is in how they support debugging information and Runtime type info; and ELF was created to support more architectures, and this was done as well in COFF then NE, LE, PE, PE64) Various user programs or libaries can still use or implement their own loaders for supporting the binary format they prefer, or just to emulate other platforms.
I started with just one example but you derived on this topic which was compeltely independant of what C compilers do, because you still maintain the confusion between the C standard and what linkers must do which is absolutely not defined by the C standard itself.
The C standard only defines the "linkage" options that you can use to bind non local symbols (i.e. variables not declared as auto or register, and not on the stack) it describes the "static" linkage (which is inviaible to external linkers and creates a scope local to the compiled unit), and the "extern" linkage possibly decarated by a "C" or "C++" label to indicate the name mangling convention that allows distinguishing or not the symbols used from other compiled units.
