PPK debuts the tiny programming challenge 67
kernelistic writes "Looks like the great folks at properkernel.com are running a developer challenge. They're looking for smallest executables that match the posted criteria. The rules look fairly straightforward. Anyone up for some fun?"
Re:Sparse on details (Score:2, Informative)
howto of sorts... (Score:5, Informative)
Looks like they want a binary similar to the one described in A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux [muppetlabs.com], except it has to print text and not just return 42.
If only I had some spare time to play along at home...
Re:howto of sorts... (Score:3, Interesting)
It's a nice challenge, but I think they should have been a bit more specific in the rules ('Preferably no fastcall binaries') and stated a more challenging task than putting out a string.
Re:Eh, why? (Score:2)
Because it's fun to see who can make the smallest excecutable.
Re:Eh, why? (Score:3, Funny)
Re:Eh, why? (Score:3, Informative)
Linux syscalls (Score:2, Interesting)
But rule 3 states that you have to use a stack-based approach, no fastcall allowed! Wtf?
Interesting challenge. (Score:5, Interesting)
main()
{
char *msg = "The deep gray mouse runs after the holy yellow cheese.\n";
write(1, msg, 56);
}
produces, stripped, a 3200 byte binary -- too big to qualify by 700 bytes.
Re:Interesting challenge. (Score:2, Interesting)
Re:Interesting challenge. (Score:2)
Tweaking the generated assembler and doing my own _start and -nostartfiles gets it down to about 1700 (yay!) except that I can't get it to exit cleanly, it segfaults after printing the string, even with a call to _exit (boo!).
Ah well, enough playing for one evening.
Re:Interesting challenge. (Score:1, Interesting)
That doesn't mean you have to return control to the OS. All it means is that if you do choose to return control to the OS, you have to do so without causing a segfault.
Re:Interesting challenge. (Score:2)
Re:Is this for i386, or .... (Score:1, Informative)
We're looking for the smallest binary that will accomplish the task at hand without causing any problems or crashes. We'll be testing the binary out on a FreeBSD machine using native FreeBSD, SVR4 and Linux ABI support. Entries using either Linux or FreeBSD syscalls will be accepted.
FreeBSD only runs on i386 and Alpha. FreeBSD's Linux ABI support only emulates i386. I think that narrows things down a little.
I think these guys must be reading Slashdot ... (Score:3, Informative)
- ... as long as the output is a valid ELF image.
has changed to:Re:I think these guys must be reading Slashdot ... (Score:2)
Put it in the kernel. (Score:2, Funny)
Submit a kernel patch that prints the stuff about the mouse on a certain syscall.
ASM
mov eax 0xbaadca11
syscall
ret
8 bytes. I win.
Beat this... (Score:3, Interesting)
The catch? I did it in 5,038 bytes, including a nifty color icon.
Beat that.
Re:Beat this... (Score:1, Offtopic)
Re:Beat this... (Score:3, Interesting)
Heh, a freind of mine and I, about 8 years ago we had an x86 assembler programming contest between us. This contest was to reproduce a pager program under DOS (like the "more" command) that would take a filename argument and page it to the screen, one page per keystroke. He beat me just barely, the final numbers of bytes were like 97 and 102.
Re:Beat this... (Score:1)
Re:Beat this... (Score:2)
Re:Beat this... (Score:2)
Did I say Playmate? get off it slashstalker
Re:Beat this... (Score:2)
I did send it, check the mailbox
Re:Beat this... (Score:2)
Yes, I did.
Re:Beat this... (Score:1)
No, I didn't try *that* hard on this project.
Re:Beat this... (Score:2)
The DOS demo scene had a lively following in the mid 90's. One thing they liked to do was show off their assembly skills by packing the most visual effects they could into a little tiny binary.
My favorite is called digi.com. It's little more than a 320x200x256 display of a rolling, rotating, reflecting, textured, light-sourced torus with some MIDI synth for background music. After you exit the demo, there's an additional full screen of ASCII art before you get your prompt back. The most impressive part was that the torus did all of it's stuff in realtime with no slowdown at all on my 16MHz 386SX. To this day I'm not sure how they did it since that machine can't even run DOOM acceptably. (This demo is a bit skippy but works under dosemu, minus sound.)
Another one I have is of several (5 or 6) seemingly random (but impressive) 3D scenes stitched together. No sound or anything, but it clocks in at exactly 4096 bytes.
Tried to find web or ftp links to both of these, but no luck. If you want them, track down my email address and just ask. They're really tiny so I have no problem sending them.
Deep gray mouse runs after the holy yellow cheese (Score:4, Funny)
super easy to beat the limit... (Score:5, Interesting)
; Justin White
; http://properkernel.com/tiny/ entry
%define STDOUT 0
%define SYS_exit 1
%define SYS_write 4
section data
msg db "The deep gray mouse runs after the holy yellow cheese.", 0x0A
msg_size equ $-msg
section text
global _start
_start:
; write
push dword msg_size
push dword msg
push dword STDOUT
mov eax, SYS_write
push eax
int 0x80
; exit
push dword 0
mov eax, SYS_exit
push eax
int 0x80
; end _start
;EOF
justin@joker:~/tmp[0]$ nasm -f elf small.s
justin@joker:~/tmp[0]$ ld -x -s -o small -nostdlib --stats small.o
/usr/libexec/elf/ld: total time in link: 0.006606
/usr/libexec/elf/ld: data size 184328
justin@joker:~/tmp[0]$ ll small
-rwxrwxr-x 1 justin justin 516 Nov 25 03:22 small*
justin@joker:~/tmp[0]$
The deep gray mouse runs after the holy yellow cheese.
justin@joker:~/tmp[0]$
that's using FreeBSD kernel calls.
that's the smallest it'll be without doing ELF header tweaking like in that tiny binary tutorial.
actually, can save like 8 bytes by using just AL and not all of EAX to hold the syscall numbers.
now, if they said, do it without using the kernel, that would have been a challenge
Re:super easy to beat the limit... (Score:2)
No, I'm not telling you how I did it. [grin] Figure it out on your own. Or improve on my attempt. Whichever.
Just tell me if you improve on it.
Packed Tighter than that! (Score:1)
; For entry in http://properkernel.com/tiny/entry
; Zac Slade
; waaaytiny.asm
BITS 32
org 00001000h
db 7Fh, 'ELF'
dd 1
dd 0
dd WW
dw 3
dd filesize
dd _start
dd 4
_start:
xor ebx, ebx
inc ebx
xor edx, edx
jmp short Contin
db 0
dw 34h
dw 20h
dw 1 PLEASELETMEPOSTMYCODE
dw 0 I'MASKINGNICELY
dw 0
dw 0
StrLen EQU 55
Strng db 'The deep gray mouse runs after the holy yellow cheese.', 0Ah
Contin: mov Dl, StrLen
xor eax, eax
xor al, 4
mov ecx, Strng
intsta: int 80h
xchg eax, ebx
jmp short intsta
filesize EQU W - WW
[krakrjak@krakrjak tinyASM]$ nasm -f bin -o itstiny waaytiny.asm
[krakrjak@krakrjak tinyASM]$ ll itstiny
-rw-rw-r-- 1 krakrjak krakrjak 123 Nov 27 10:58 itstiny
[krakrjak@krakrjak tinyASM]$ chmod +x itstiny
[krakrjak@krakrjak tinyASM]$
The deep gray mouse runs after the holy yellow cheese.
[krakrjak@krakrjak tinyASM]$
There's My entry. Maybe someone else's entry is better than that but I'm hard pressed to get any better than that. That is using fastcalls, but it get's the job done.
Stupid lameness filter.... I'll just ramble and see if it'll let me in...
Perhaps maybe the Dollar Signs. I'll replace those with the letter W. Now the compression Filter. That's okay another paragraph here outta do it. I've taken most tabs and also added some CAPS stuff to get through the Filter.
Has anyone heard of a better way for this one yet. Someone told me they had it smaller but they wouldn't show me how. Maybe if you can use some of the characters in the string as instructions then maybe it's possible to get some of it done that way. The only real problem is jumping into memory takes space too and doesn't save anything if you only execute one instruction.
We've already been through this, sorta... (Score:2)
The answer was 45 bytes, but probably don't fulfill the criterias set in this challenge.
How is 99 bytes? (Score:1)
Re:How is 99 bytes? (Score:2)
optimal solution there, if you disallow schemes
which algorithmically compress the output string.
Now that you've done your homework and
applied all the basic published techniques to
shrink the straighforward write of static data down
to it's minimum size, you can start to *think*
*creatively* and work on dynamically allocating the
buffer and generating its contents from code in
fewer than 56 bytes.
Solved (Score:1, Funny)
Unfortunately, the source is too long to give here.