Slashdot Mirror
Simpler "Hello World" Demonstrated In C
An anonymous reader writes "Wondering where all that bloat comes from, causing even the classic 'Hello world' to weigh in at 11 KB? An MIT programmer decided to make a Linux C program so simple, she could explain every byte of the assembly. She found that gcc was including libc even when you don't ask for it. The blog shows how to compile a much simpler 'Hello world,' using no libraries at all. This takes me back to the days of programming bare-metal on DOS!"
http://web.archive.org/web/19991128041233/http://muppetlabs.com/~breadbox/software/tiny/teensy.html
November 1999. Slow news day much?
This post expresses my opinion, not that of my employer. And yes, IAAL.
The whole point was learning ELF structure and why things were they way they were. Didn't you ever wonder why a "hello world" program took over 4000 bytes on a modern computer, when in 1980 a Commodore VIC-20 managed to play games in less than 4K of available memory? This wasn't a waste of time.
Shouldn't the linker remove unreferenced functions?
I've had this problem with gcc for a while, with C++ code. I was writing some embedded code, and I wanted to use some simple C++. Just by adding a #include of one of the stream libraries. the executable grew by 200k, even though none of it was referenced. The C++ code in iostream is template-generated anyway, so even if the compiler wanted to include the code, it can't until I instantiate it.
<iostream> includes references to global stream objects like std::cout, not just interface definitions, so including it's going to have larger ramifications that something like <fstream>, which just defines interfaces (and indeed, for me, including <fstream> seems to have no effect on program size, whereas including <iostream> adds about 300 bytes to a simple executable).
We live, as we dream -- alone....
I wasted too much time reading this one... nothing surprising about what I found in it. Step one, don't write it in C. Step two, stop linking to things that aren't needed. Step three, perform the functions contained in the library omitted manually. Step five, start cheating in the elf binary format.
The only thing interesting about it was that the article pointed out an interesting fact -- Linux will run inappropriately formatted binaries. BAD. Linux kernel people? Are you reading this? Fix it before someone figures out how to use this in making and executing more exploits.
These days, costs of development and deployment, not runtime memory usage, are the limiting factors in software development.
http://outcampaign.org/
gcc for an AVR target doesn't make an 11k hello world, though.
Probably because that's an application where it matters, and a modern PC it doesn't matter at all.
Sent from my PDP-11
There are three links in the article summary. The first is to the Wikipedia entry for "Hello World"; the second is to an article about writing "Hello World" without libc; the third is to part II of the second, an examination of the ELF format and demonstrates the 45 byte program. The summary headline is rubbish. Whoever wrote it either (a); never read either article, or (b); deliberately sensationalized it by conflating the salient features of both articles, in which case they should be working for the tabloids.
What a shock this comes from Kdawson. I'm about one more kdawson article away from dumping slashdot. I can't imagine that all the people in the slashdot batcave aren't laughing at this tool.
I sometimes wonder if he just goes out and gets completely hammered at lunch then comes back and picks a few articles.
Apple defines system call APIs at the top of libc ...no static linking allowed.
This annoys people who like to link things statically, and those who want to make their own libc equivalents for things like embedded language interpreters and don't want to have to figure out vtables and dynamic linking.
But it also makes everyone else who likes binary compatibility, and Mac OS X historically getting faster with every release, extremely happy, by allowing the interface between the kernel and libc to be changed, without breaking their applications.
If you statically link, you can't do that. That's great, if your OS has pretty much no real commercial application base, and you are a technical enough person to "just recompile everything from source", but it's not so good when you are talking about an OS where commercial software is very important to customers. Customers who are either non-technical, or who are technical, but think recompiling something that was working just fine before the OS update is a complete waste of time. Lump me in with these last people: I don't believe in "bit rot", I just believe in lazy engineers not maintaining their code or defining their interfaces properly.
Yeah, if you want fast LMBench results on a null system call -- which keeps changing its definition so that it can't be gamed, exactly the same way you'd game it if you were a commercial application developer needing higher performance -- static linking seems great. But practically, most modern software is either CPU bound or I/O bound. If it's CPU bound, it spends all its time in user space, not making system calls. If it's I/O bound, it spends all its time waiting for whoever is on the other end of the network to send it more bytes. Either way, null system call performance is, frankly, unimportant to almost every possible application.
So static linking, and writing your system calls at the trap/sysenter/syscall level (with no way to change them when Intel or another chip vendor introduce a "new! optimized method of making system calls!", as has already happened twice in the past) is generally a pretty useless exercise.
-- Terry
Hello (World). I am from the future. The code you have provided a link to will not run on Windows 9.
How about 22 bytes?
:16
C:\>debug
-a 0100
0D39:0100 MOV AH,09
0D39:0102 MOV DX,0109
0D39:0105 INT 21
0D39:0107 INT 20
0D39:0109
-e 0109 'Hello world!$'
-r cx
CX 0000
-n hello.com
-w
Writing 00016 bytes
-q
C:\>HELLO.COM
Hello world!
C:\>dir hello.com
26/08/2009 10:48 22 HELLO.COM