JamesM

Hi,

I know, there are some seriously bad stylistic mistakes in that code, as well as doing some things "the wrong way" (stack move instead of a recursive page directory is a prime example).

The tutorial series was written in 2007, so quite a time ago. I got around to rewriting the code, but not the overlaying documentation and explanation so the old version is still live.

New version for anyone that cares: http://jamesm-tutorials.googlecode.com/ . Much better stylistically, and with sound practices throughout.

It should also be noted that my tutorial series was not designed to teach people "how to write a kernel" - more to show how to bridge the gap between theory and practice. There are many books and resources (Tanenbaum's book is an example) that deals purely with theory - algorithms used etc.

There are also many resources about assembler programming and C, but to my knowledge not really many that showed how to apply the theory, concrete it and end up with "something" that runs (which can then ideally be adapted based on better theory).

As to your previous point, the tutorial series is aimed to be one thing and one thing only: A set of tutorials to help bridge the gap between the practical and the theoretical as far as OS implementation is concerned.

There are plenty of tutorials on ASM coding, and plenty on low-level C coding. There are plenty of books about OS internals. The books and articles I've found before tend to stay firmly in the theoretical, in the abstract. The aim of this series is to show how the theory can be implemented. Then, the reader has the knowledge to (possibly) implement their own algorithms and know how they link to the CPU's internals.

As to your second point - do you think that the memory manager in this OS is optimal? Do you think that the linked-lists everywhere are optimal? Of course not. Everything was chosen for its simplicity - I failed in some areas I know, and I'm rewriting them as I speak (they're stalled at the moment due to a lack of time); the heap for example is a mess in that series. The new one is much easier to understand.

The series does not create an optimal OS for IA32. So your point about transitioning to amd64 to "make full use of the latter's capabilities" is moot - you have to do more research to optimise for IA32 anyway, let alone amd64!

(And let's not forget that all amd64 CPUs are backwards compatible with IA32).

The Netwide Assembler (NASM) which I mention in the article frontpage has the same syntax as MASM without the nasty licence. Some of the assembler directives may differ, but 90% of your program will be identical.

I wouldn't say it was misleading - the front page of the article clearly states that a kernel is being developed. Drivers and software belong in the rest of the operating system. Given the availability of GNU software, a UNIX userspace is fairly easy given a smallish set of system calls.

Yes, I'm the article's author. Yes, I'm biased.