symbol hiding

[Dmitry Timoshkov]

"Mike Hearn" <mh at codeweavers.com> wrote:

> > Can you list at least some things you think are bad in PE in comparison
> > with ELF? 
> 
> Sure - ELF has decent versioning, which PE lacks and has caused massive
> pain due to conflicts etc. While you can rename DLLs on Windows it's not
> a part of the system so not many people do, and when they do there's no
> pattern to it.

ELF versioning is just another attempt to hide problems instead of
fixing the source of it IMHO. Exactly for this reason even simple
'Hello World' program compiled under RH 9.0 will not run under RH 6.2.

> The ELF file format is fairly simple compared to PE where you have
> layers of wrappers and cruft due to its long history.

Actually PE format hasn't changed since NT 3.1 introduction.

> ELF is well specified for multiple CPU architectures and standard
> between several different operating systems. I can get the spec in many
> formats. The PE spec in contrast comes in the form of a Word document,
> and I have to agree to a bigass EULA to read it:
> 
> http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

PE is documented very well, and there is no need to download its
description from microsoft site, find it somewhere else.

> ELF is pretty easy to extend with new sections and flags.

If you call such a basic thing as having separate debug info
as a yet another GNU extension invented only very recently, more
than 10 years later than in PE world, then I'd agree.

> > Another downside in ELF in addition to mentioned already is
> > missing a resource section, which makes our life implementing Wine much
> > harder and forces all application developers invent their own formats
> > to store icon/bitmap/dialog info/strings/etc. information.
> 
> Actually I see that as a benefit: PE resource files are IMHO a rather
> dubious feature. Yes it makes implementing Wine harder, but any time I
> see a filing-system-in-a-file I get suspicious. Sticking files inside
> the EXE or DLL just makes them harder to get at, harder to replace or
> edit: we already have a working filing system so reinventing that in a
> limited fashion seems silly. I think keeping code and data physically
> separate is a much better plan.
> 
> In the rare case that you need to store binaries inside ELF it's still
> possible: see GTK+ which does this for its stock artwork.
> 
> Finally, the linking semantics of ELF are as much a blessing as a curse.
> While it can cause chaos sometimes, it also lets us do things like the
> pthread override trick. Any LD_PRELOAD hack also uses this "feature",
> though it could be done more cleanly with an extension.
> 
> Modern (ie GNU) ELF also has various interesting features like symbol
> versioning, prelinking etc ...

An executable file format is such a basic thing in which a developer
would expect:
1. be relatively simple and straitforward
2. be well documented
3. be stable (i.e. for instance not change for more than 10 years as PE)
4. be well supported on the OS system level API (as you can do with PE:
find a PE header in memory, find import/export table, intercept an API
using simple code patch and guarantee that such a program will work
on all next version of the OS)
5. let a developer create a custom section and easily (I say easily!)
access it at run-time.

I find nothing of the above is true for ELF, sorry.

-- 
Dmitry.