Slashdot Mirror
Smallest Possible ELF Executable?
taviso writes "I recently stumbled across this paper (google cache), where the author investigates the smallest possible ELF executable on linux, some interesting stuff, and well worth a read. The author concludes, 'every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?'
No wonder you were modded down:
Bilbo is a hobbit.
Is a hack!
Of course, and I highly suspect it, I may be talking out of my ass. -oqti
I can't wait until they pose nude, like Drew Barrymore, or the chick from Labyrinth.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
For all those who never understood what the true nature of the Windows registry is about this thread emphasizes the point.
The Registry was created for the purpose of storing and retrieving local OS and application configuration data in a convienient and highly organized way. In this manner the registry is simply seen as a local database that the OS has direct access to. An operating system process database so to speak.
On the list of registry requirements is speed. The registry is optimized for extremely high speed reads as well as writes. It was discovered early on that storing small amounts of information such as Bytes, Words, Strings, and such directly on the file system in separate files was a problem. Opening, reading, and closing files requires many I/O operations which eats up CPU, and can be taxing on the hardware subsystems. Hard drive caching and file caching can prevent some of the problems caused but do not really provide an adequate solution.
Another issue is that small data elements don't make effective use of the allocated disk space. Especially in the early days with small hard drives this was a BIG issue. You certainly don't want to open a file, save a byte, and close the file. You might end up using a whole sector. Depending on which filesystem type you used, you could lose almost half your disk just by storing small files. With text files the problem is even worse. You end up opening the file, parsing out the data with routines, then converting it to the data type you need. By nature, text representations of the data values will be larger, wasting valuable disk space.
As we have seen with network database access, a database access protocol optimized for high speed reads is important. The LDAP specification addresses some of these concerns. As well with the registry, we need the ability to store and retrieve data fast with minimal space cost. Microsoft decided to create a set of files called HIVEs that are essentially open from the moment the OS boots. The OS caches these HIVEs in memory. The OS as well as applications have access to the HIVEs through a special set of high speed access APIs. All the APIs need for access to a HIVE is its global handle value.
The HIVEs are organized hierarchically similar to a file system. This makes a registry HIVE exactly like a "file system on top of a file system". In this case since a HIVE is stored on the real file system as a single contiguous block and always open, it makes disk space efficient and I/O fast. Its just a specialized mini file system database for configuration data.
Key names in the HIVEs are folders. The keys contain registry values which contain the actual data. The values are typed so as to also maximize speed. There are user, software, and system data HIVEs. HIVEs can be mounted or unmounted, and symlinks can be created from one key to another. Registry keys can be protected with the same ACL protection mechanism that NTFS uses.
If you want to see how fast the registry is in action just download the regmon.exe probe from www.sysinternals.com and watch what happens when you do anything in Windows. The amazing dependencies that make themselves apparent by watching regmon can easily show you that doing I/O out to disk would cause everything to slow to a crawl, as well as put more pressure on your already loaded disk I/O system.
Registry key values are NOT made to store large amounts of data. You aren't supposed to store entire files as value data. Indeed, that would make what the registry was made for pointless. One of the problems is that many application programmers either don't understand how to use the registry correctly, or just use it for the wrong purpose. The current registry is BIG. The information stored in the registry has gotten out of hand. Even Microsoft can't stop storing useless information in there. It is easy to say that the registry might become corrupted, but this also happens with file systems themselves. You do occasionally have to run a file system check. Ever lost a binary database file before?
Data in the registy can be easily back'ed up using the regedit tool that comes with the OS. You simply export what you need to a text file. The text file can then be re-imported later when needed. If you want to backup a whole HIVE file such as SOFTWARE you can do that too. Many backup utilities will do exactly that. It is even possible to backup the HIVEs without being in the OS. Just boot to another OS and copy the files off the disk (assuming you can read and write to NTFS). I really don't see the problem with registry backups. And hey, in the end, the registy is just a simple set of files stored on the filesystem just like any other files in *nix.
Since the registry API is in effect and abstraction layer, Microsoft could re-write the back-end completely. What about a network registry? We could relocate the files out onto a network server and the applications wouldn't know. Microsoft could encrypt the data, compress it, whatever. I don't know what Microsoft's future plans are for the registry interface. Any of these things would make access slower so I expect that the design will stay the way it is for now.
We all have fast and big hard drives these days so the registry does seem kind of pointless. But if we were all using slow small drives we would really appreciate the technical merits of the registry. Even more so, users of a registry can now enjoy that their data is being store both effectively and efficiently. Linux would do well to adapt to some kind of OS database for its configuration settings and local accounts even if it isn't regsitry like. But if you want to continue to store a 64 BIT value in a text file as "0xFFFFFFFFFFFFFFFF" be my guest. (BTW, this is the same problem I have with HTTP, inefficient as hell!)
What has this got to do with anything being discussed? The registry is a useless crock, and it has nothing to do with understanding anything about an ELF executable.