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?'

Comments

No law on repeat articles?

[ebuck]

Last time I read this on slash dot was less than a year ago. I imagine in 4 or 5 months we'll see it again.

The article is great. It really is a good intro to refresh that assembly / understand ELF / do neat stuff. I still have the tiny assembler installed on my machine from the last go round.

I've heard of a guy who is trying to make the world's smallest 'cat' program. I wonder how many other utilities have been similiarly "optimized"

Small virus catcher (for DOS)

[Fuzzums]

in assembly: RET

All this one byte program does is terminate execution. If it's infected by a virus you'll see soon enough if the size has increased.

ofcourse with todays macroviruses this doesn't work anymore :(

Re:Turbo Pascal

[compwizrd]

Some of the old-time Demo groups (and warez groups) would put very nice VGA demos in 4k as well.

Windows exe

[Sivar]

Cas, or StorageReview.com's forums, created a 324 bytes Windows 2000 PE executeable. It completely blew away all of mine, the smallest of which were about ~700 bytes.

Re:umm.... yeah?

[Leonel]

Did you bother to read it?

From the article, after the first try in asm:

Looks like we shaved off a measly twelve bytes. So much for all the extra overhead that C automatically incurs, eh?

Not bad...

[Captain Pedantic]

But I'd like to see them get a Breakout clone in 1K

No need to be smaller than 512 really...

[Anonymous Coward]

Harddrive sizes being what they are now, the smallest sector size I see is 512 bytes. If the file stored in that sector is smaller than 512, it still takes up 512 bytes. Very intersting article however.

MenuetOS

[jaaron]

On a similar topic, MenuetOS is a full OS written in assembly and fits on a floppy. Yeah, lots of OS's used to fit on floppies, but it's still cool. It's amazing what all you can fit into a small space if you're careful.

4K Demos

[Wraithlyn]

Some of the 4K demos I've seen written for ASM competitions completely blow my mind... check out this one, it's basically a flythrough of the first level of Descent, with texture mapping, source lighting, animated lava and recharger field, a MIDI soundtrack, etc... all in 4095 bytes!!!

Here is Sanction's home page, it contains a couple more very impressive 4K demos.

What about the Visual Studio .NET compiler?

[Jugalator]

Stand-alone console EXE (Release Build):

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
return 42;
}

Size: 20,992 bytes

To be compared with the non-optimized gcc version at 3,998 bytes. :-)

I wonder how small you can make a Windows EXE..

Re:What about the Visual Studio .NET compiler?

[Jugalator]

Hm... I stripped the code from stdio.h, replaced _TCHAR* with char* so the stdafx.h doesn't really do much at all. Then turned on size optimizations and turned off boundary checks etc in the compiler. Still exactly 20992 bytes. Huh?? Browsed the exe and there's full text messages like "ooh something corrupted the state of this program and it cannot safely continue". Which is actually a great addition by Microsoft, but can't you remove such things? :-)

But I guess the .NET compiler has its lower limits where bloat get called feature, just surprising that it seems to compile at the minimum size by default... Or perhaps it use some kind of silly padding so even if there's less code, the physical size isn't reduced.

Kids don't try this at home :-)

[Antity]

The first few examples are quite noteworthy, but when the author starts to put code inside the ELF header, it gets really ugly..

Saying that these bytes are "only padding anyway for future extensions" doesn't feel that good. :-)

This remembers me of early attempts on AmigaOS to shorten and fasten executables where people could be sure that all available Amigas would only use the lower 24 bits of 32 bit address registers since the machines could only address 24 bits physically. So they put application data into the upper 8 bits of registers. Worked fine.

Then came newer machines which really used the full set of 32 address lines and all those dirty programs crashed without obvious reason..

The author says "if we leave compatibility behind.." but what he's doing is not only leaving inter-OS compatibility behind - what he creates isn't even an ELF executable anymore. It's just something that happens to work with this special Linux version.

So since this isn't even an ELF executable any more, there's no reason not just to write "exit 42" in bash (which would be an amazing 8 bytes in size *g*).

Don't misunderstand me, I really like those hacks. But I myself will never, ever again code something that is prone to break in the future just because I didn't follow standards.

One could say that this is what programming is about. :-) No offence meant.

Embedded systems need efficiency

[yerricde]

CPU is cheap, hard disk is cheap.

Maybe on PCs, but not on embedded systems, handheld systems, or game consoles. The Game Boy Advance, for instance, has only 384 KB of RAM, and all but 32 KB are 16-bit bus width with muchos wait states. Many microcontrollers inside such things as microwave ovens are as powerful as an Atari 2600 VCS, with 128 bytes of RAM and about 12 bytes of VRAM (if that).