Skip to content

Comment on 3998-byte executable reduced to 45 bytes

Comments

My problem with the article is that it's not really theoretically useful, it's just a case for one particular program.

Writing large programs in C, I rarely see the need to optimise program size - I'm more interested in execution time. Even so, with thousands of lines of code, the executable is typically < 200kb, which would run on an Amiga, never mind a PC.

I think this article is slightly outdated as we don't run 64kb 8-bit machines anymore.

My last comment is that you could use an executable 'packer' which uncompresses at runtime, and that's far easier than his methods.

This article is definitely not intended to teach you how to optimize your programs. That is, unless your usual programs are small enough to embed inside object file headers with the opcodes overlapping header field values.

It's a clever hack that teaches you about how ELF works by forcing you to think carefully about every single byte in a customized ELF executable.

I work frequently with object file formats (especially ELF) and write tools which manipulate executables and libraries and when I first read this article about 5 years ago I learned more about ELF than from any other source.

Highly recommended!

My usual programs are. In fact, you might have one of them on your computer right now... unless you've run a scan recently. ;)

The end result is not useful, but I learned a lot of new things about C and processes along the way.

And I thought it was an inspiring exercise to go as far down to the metal as possible.

It does make me feel guilty when programming Ruby that I sometimes create an entire array object to compare two integers because it looks prettier, without any regard for performance. It feels so wasteful.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.