Linux – Oldest binary working on Linux

A user generally encounters three types of ELF files—.o files, regular executables, and shared libraries. While all of these files serve different purposes, their internal structure files are quite similar.

One universal concept among all different ELF file types (and also a.out and many other executable file formats) is the notion of a section. A section is a collection of information of a similar type. Each section represents a portion of the file. For example, executable code is always placed in a section known as .text; all data variables initialized by the user are placed in a section known as .data; and uninitialized data is placed in a section known as .bss.

Actually, one can devise an executable file format where everything is jumbled together(like MS DOS). But dividing executables into sections has important advantages. For example, once you have loaded the executable portions of an executable into memory, these memory locations need not change. On modern machine architectures, the memory manager can mark portions of memory read-only, such that any attempt to modify a read-only memory location results in the program dying and dumping core. Thus, instead of merely saying that we do not expect a particular memory location to change, we can specify that any attempt to modify a read-only memory location is a fatal error indicating a bug in the application. That being said, typically you cannot individually set the read-only status for each byte of memory—instead you can individually set the protections of regions of memory known as pages. On the i386 architecture the page size is 4096 bytes—thus you could indicate that addresses 0-4095 are read-only, and bytes 4096 and up are writable, for example.

Given that we want all executable portions of an executable in read-only memory and all modifiable locations of memory (such as variables) in writable memory, it turns out to be most efficient to group all of the executable portions of an executable into one section of memory (the .text section), and all modifiable data areas together into another area of memory (henceforth known as the .data section).

A further distinction is made between data variables the user has initialized and data variables the user has not initialized. If the user has not specified the initial value of a variable, there is no sense wasting space in the executable file to store the value. Thus, initialized variables are grouped into the .data section, and uninitialized variables are grouped into the .bss section, which is special because it doesn't take up space in the file—it only tells how much space is needed for uninitialized variables.

When you ask the kernel to load and run an executable, it starts by looking at the image header for clues about how to load the image. It locates the .text section within the executable, loads it into the appropriate portions of memory, and marks these pages as read-only. It then locates the .data section in the executable and loads it into the user's address space, this time in read-write memory. Finally, it finds the location and size of the .bss section from the image header, and adds the appropriate pages of memory to the user's address space. Even though the user has not specified the initial values of variables placed in .bss, by convention the kernel will initialize all of this memory to zero.

So you see, it is actually the kernel which issues the orders to load the executable in memory. The text section as a result of any such calls is loaded in read only memory and the data section is loaded in read-write memory.

Basically this boils down to: you can't keep binary compatibility and introduce new features, since these things go directly against each other in most aspects. If you introduce major new features you in the end have to change the ABI (usually shortly after the changes in the API). Now, you can have versioned symbols (like for example Glibc has), but this makes the libraries grow in size (and may also incur some performance penalty while loading a binary into memory) and developers certainly don't want to keep it in general libraries (the legacy code contains bugs that nobody is interested in fixing).

The usual way to go around this on distribution side is twofold:

1. do not change versions - this is typical for Enterprise-grade distributions like (in alphabetical order) RedHat and SUSE, as well as for some others (Debian, Slackware, Ubunty LTS and probably their clones).

2. allow installation of various versions of a library at the same time.

On the application distributor this is handled in the same way as on windows: stuff everything needed into the distribution package. Yes, this is the way it is often done on Windows - this is also one of the reasons for typical Windows system usually having several times higher disk space requirements than Linux with the same functionality - the applications are simply sharing only very little among themselves and have their own copies somewhere. You can think of it as of every GTK/Qt application coming with its own GTK/Qt stack. It can have some advantages but disadvantages are also plentiful. For example from security point of view it is a nightmare in Technicolor^TM. If the binaries are statically linked, it's even in FullHD.