Linux is at advantage by the fact that most standard Linux distributions ship a lot more libraries than Win32 which you can assume being available in the system. Some of the useful ones are e.g. SDL and GLUT which you can use as the base framework for the application giving you graphics output and event handling. SDL also provides sound output capabilities.
Linux (and most other Unix-like systems) also has the advantage (compared to many other operating systems) that you don’t need to use any libraries at all if you don’t want to, because everyhing can be done through kernel-level system calls (the int opcode in x86 assembly). This is a totally different approach than the previously mentioned one.
Accessing the sound device is usually a simple task (open the device file with open, set its parameters and monitor itse status with ioctl, and write out the pcm data with write).
The visual side is more complicated. Framebuffer devices are simple to access for pixel rendering, but they’re not very often available on PC-based systems. Therefore, if you want to do decent visuals in a compatible way (and text terminal output is not enough for you), you must learn how to talk the X11 protocol in a low level. Basically, you establish a connection to localhost:6000, send the initial request, grab the id’s you require from the response, open a window, etc. etc. It may be a bit long-winded, but you also get a low-level access to extensions such as XVideo and GLX.
Another approach usable for 4K intros on Unix platforms is self-compiling. That is, you actually distribute the intro as an executable source code package that decompresses, compiles, executes and deletes the actual intro. A shell script stub attached to the compressed source code of an SDL-based intro could perhaps be something like this:
a=/tmp/I;zcat<<X>$a;cc `sdl-config --libs --cflags` -o $a. $a;$a.;rm $a.;exit
It’s generally believed that the best 4K executable compression on Unix platforms is by a shell-script stub that drops the actual executable into a temporary file and starts it. A canonical Unix tool, gzexe, creates executables like this, but with quite a bad overhead. It’s quite easy to come up with much shorter solutions.
Here’s the stub presented by Marq/Fit in his Assembly 2006 seminar (56 bytes):
a=/tmp/I;tail -n+2 $0|zcat>$a;chmod +x $a;$a;rm $a;exit
Paul Sladen came up with the following shorter stub (you must pre
tac the binary part, before concatenation, so that the transform is fully reversible; this may require appending a
\n to the end of the file):
HOME=/tmp/$;cp $0 ~;tac $0|zcat>~;~;rm ~;exit
Using the current directory instead of
/tmp saves a couple of bytes but may cause problems if you don’t have a write access to that directory or if the competition rules prohibits usage of anything else than temporary directories for write access.
Gzip seems to be better in most cases for the 64 kB and under size class than Bzip2. Idea for improvement: use the multi-line quoting syntax
<<ENDMARKER); generally experiment as much as you can. You can also do the tempfile removal in the actual code, just after the startup. You may also be able to replace the “exit” command with your own code.
To achieve maximum compression with gzip use command line switches -n (skip embedding the filename) and –best (already the default); however there are other gzip encoders around (just like there are lots of MPEG/MP3 encoders but the output an always be decoded by any decoder).
One gzip encoder that can often produce more compact (but compatible) results is the deflate encoder found originally in the p7zip; this encoder is available on Debian/Ubuntu with
apt-get install advancecomp. Compression tests have shown that compressing Linux 4K intros with the 7zip/advancecomp implementation saves 40 to 100 bytes in the final result.