- http://kolibrios.org/en/
1st. This is an excellent example of the level of size optimisation available to programers working directly with assembly code.
2nd. Not being completely open source hampers its use as a teaching tool re: assembly programming.
Since Assembly code is pretty much unreadable, human-written Assembly source code tends to be 50-90% comments. Some OS related programming tasks are very handy to write with Assembler macros, that wouldn't be visible in the binary. In addition to the comments, the binaries might not contain variable names, function names and other useful information.
Hell, even white space is important in Assembly sources! Those empty lines that separate a logical block of instructions or beginning and end of a loop, for example.
The source code to a computer program written in Assembly is as important as source code in languages written in any other language. Binary blobs are not (effectively) readable by humans.
Having comments and human readable symbols like variable and function names is sure nice though.
- Very, very little code. Everything is implemented in the most minimal way possible. This is extremely important - you can literally read through all the code in the kernel from top to bottom and be sure you haven't missed any functionality. Good luck doing that with some 1MB C program.
- Almost no indirection. Few indirect jumps, almost no use of malloc (!). In IDA this makes it very easy to name functions and variables and easily see where they are used, which isn't possible for anything dynamically allocated, as in idiomatic C. This is to some degree IDA's fault: a smarter tool could do a decent job at automatically inferring the types signatures of C functions and provide similar functionality for struct fields, but IDA does not. However, it does make the problem more tractable in general.
Note that reading the actual assembly, at a local level, is missing from that list. If anything, compiler generated assembly is probably easier to read, due to recognizable idioms, although there are exceptions such as repetitive code in inline functions or templates that would never be written by a human.
(The fun thing is, with a decompiler you can actually read the code in question as C.)
I don't want to do reverse-engineer either but I'd rather read the human written and compiled asm code. It's a little but not much better. I might read (and write) some assembly source code for fun, but I would not read the binaries so I'm going to stay away from this project.
Yes, and unfortunately given how unforgiving hard it can be for many programers to really sink their teeth into anything of significance using just assembly, those niceties are pretty much whats needed for anything of this size to be a practical example. Reverse engineering tools are not the nicest place to learn new programming techniques. :-(
"Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders."
The license that you pointed, is for the 64bit version.
However the MenuetOS 0.85C, for which the news item is about, is the 32bit version, and it is licensed under the GPL: http://www.menuetos.org/M32.htm