This topic is depreciated and has been succeeded by THIS thread.

Thanks for your attention. -SpooK
Posted on 2004-04-28 18:39:33 by SpooK
Looks nice enough :) - I hope you'll split it to separate pages once it grows. You might want to update the part about compilers, mentioning that the VC++ compiler can be obtained for free (and used for whatever), after all it has better code generation than GCC (although the linker isn't nearly as flexible as gnu ld with linker scripts).

Nice initiative anyway, good writing style.
Posted on 2004-04-28 19:20:44 by f0dder
VC++ compiler can be obtained for free, good info. What about the IDE?

It works better than GCC? Pushing towards ideology. As far as I am concerned they work and compile on the same level, a non-amateur one. I'm not going to push that issue onto my readers, they will have to make the decision between VC++/GCC and NASM/TASM themselves. I will merely provide a neutral standpoint.
Posted on 2004-04-28 20:19:58 by SpooK
The IDE certainly isn't free :( - but I guess you could integrate it into one of the free IDEs without too much bother. As for code generation, intel and MS lead the field for x86, while GNU is lagging seriously behind - I haven't tested the latest version of GCC, but reading the release notes, it seems they've only just implemented features that msvc and icc have had for ages.

The GNU linker *is* way more flexible though, which can be quite useful in OS design - then again, I'm probably going to build my kernel as a PE file... if it works for NT, it'll work for me :)
:stupid:
Posted on 2004-04-29 06:59:54 by f0dder
Hi Spook,

Your tutorial sure looks good :thumbsup:
Posted on 2004-04-29 08:37:48 by roticv
Thanks. The difficulty of writing it varies since I have to think about how I was and the questions I had when I was first starting out. I would love to explain every ascpect of my documentation, but going into how to use GRUB/NASM/TASM/etc... is way beyond the scope of the guide and will cause me to lose focus. To solve that problem I insert subtle equivalents of RTFM :tongue:

What I may do though is setup a downloadable package that contains all the needed tools, which may also contain a nice combination of free VC++ and a good free IDE with setup scripts ;)
Posted on 2004-04-29 20:02:41 by SpooK
SpooK, a thing I'd really love to see would be... explanation of the "reserved first track of the harddrive" (useful for advanced bootloaders) (you might want to comment that some commercial app protections like safecast messes up this area), the realmode memory map (and the bios functions to query the extended memory map for holes etc).

A lot of people seem to forget these issues - of course there's the danger of this topic confusing newbies, so you might want to mention it briefly early on, and explain it more thoroughly later.
Posted on 2004-04-29 20:53:04 by f0dder
Thanks for reminding me. I'll make sure to note that when I get to the hard disk related information. That will mostly be information for intermediate/advanced users. I simply will not influence a new os developer to start messing around with sectors on their HD. Floppy drives/bochs work just fine :)

As for the memory holes, ya... that is a nightmare. I've made the mistake of probing memory in protected mode to see how much is in installed. I'll cover using the BIOS routine prior to protected mode around when I get to the memory management portion.
Posted on 2004-04-30 00:11:37 by SpooK

I simply will not influence a new os developer to start messing around with sectors on their HD

A wise decision - one can wreak a lot of havok if one knows not what one does :)


I've made the mistake of probing memory in protected mode to see how much is in installed.

Hm, this give problems? That you can't catch by setting up exception handlers? I wonder how the BIOS does it. Safer to call the BIOS routines anyway.

Memory management is pretty interesting and a large topic, and there's so many ways to go about it :) - how do you manage free pools, how do you build page tables (as in where do you allocate the memory) et cetera. I'm currently considering some stuff like keeping a bitmap of free 64k regions (I don't plan on supporting more than 4GB of ram, etc.)

Btw, speaking of bochs - have you seen/used any debugger frontends for it? It would be nice writing some *decent* debugger frontend that isn't based on gdb... I know there's hooks in bochs to support this, but I don't know how complex the instrumentation stuff required to do it is, though. It could end up being more powerful than a hardware ICE if done right though, would be a great aid when doing OS design (that's why I really like that bochs is full emu and no JIT... it might be slow, but it allows for a lot of powerful stuff).
Posted on 2004-04-30 02:32:51 by f0dder
I've done a little more work on the guide. I've added the link to it to the dynatos.org projects page and also have added a table of contents (the table of contents links only to chapters that are initially finished).
Posted on 2004-06-17 21:55:06 by SpooK
I think OS Programming in C is covered well enough, there are a multitude of books and tech documents about it. I am thinking about concentrating on assembly language for my guide. I'm just wondering how many here would agree to stick to one audience as such.
Posted on 2004-06-23 15:25:23 by SpooK
Well, focus on concepts more than on source - if you keep the concepts clear enough, the source/pseudo language used for descriptions will not matter too much. But descriptions - algorithms, why you choose to do this, why you did not choose to do that, various considerations (etc) is way more important than source - there's so many amateur OS'es out there already that are poorly documented.

Keep up the good work! :alright:
Posted on 2004-06-23 17:10:04 by f0dder

there's so many amateur OS'es out there already that are poorly documented.


I'm trying to keep from being apart of that scene :grin:

I think I will approach my guide more on what is needed to make it work and less on code examples (unless required) and what to code it in without making it too theoretical and unusable.
Posted on 2004-06-23 17:45:11 by SpooK
As far as MASM goes... So are you saying that MASM development is legal as long as it is ONLY for windows?

Besides that question though, I like the layout of your tutorial. Nice one there. Fortunately I happen to be a NASM guy, so I'm set to go. As far as the DynatOS FAQ, where the quesiton "why another OS?" is asked, here's my answer "An OS development project is one of the best ways you can truly explore a computer system at its lowest level. Even if your OS doesn't become big like Linux or Windows, your learning will have increased considerably and hey, looks great on a resume" I'm not criticising your answer, I'm just describing my own.

I've hammered out the first part of my Operating System Development Guide. It is nowhere near complete, it hasn't been proofread throughly and it doesn't have a table of contents link system setup yet.

I will work more on this guide as time permits. Feedback about the guide is always welcome, but keep your ideology to yourself ;)
Posted on 2004-10-01 20:36:13 by Al_Leitch
Well put. Most people don't really begin to utilize their programming potential until they understand fully how a computer manipulates data. It is easy to do something because "it is simply the way to do it", it is the people that analyze and question those ways that make improvments.

As for MASM, I'm pretty sure that anything non-profit will be overlooked... but you can guarantee Microsoft to stick its nose in your business if your program becomes big enough.
Posted on 2004-10-03 09:45:23 by SpooK
It's a great guide, Spook  :D

In fact, I tried so hard to find another guide to explain something similar (before I even knew this community), so I became a little nervous...  but your guide is easy to follow.. Personally, I certainly found out how the BIOS starts up the system now (and it happened to me once, to get those wierd beeps  ;) for my video card). Nice work..

Can't wait to see some more  :)



EDIT: oops..  didn't see this post was dead for 120 days..  :sad:
Posted on 2005-12-01 08:23:48 by The Grey Beast

It's a great guide, Spook  :D

In fact, I tried so hard to find another guide to explain something similar (before I even knew this community), so I became a little nervous...  but your guide is easy to follow.. Personally, I certainly found out how the BIOS starts up the system now (and it happened to me once, to get those wierd beeps  ;) for my video card). Nice work..

Can't wait to see some more  :)



EDIT: oops..  didn't see this post was dead for 120 days..  :sad:


That is ok. I have little time these days, and my projects tend to be on a "demand" basis. If no one requests anything, I assume the project is dead. I will do some more work on it soon :)
Posted on 2005-12-01 16:30:17 by SpooK
As for MASM, I'm pretty sure that anything non-profit will be overlooked... but you can guarantee Microsoft to stick its nose in your business if your program becomes big enough.
How would they ever know?  If you were concerned later, couldn't you just re-assemble with another assembler (with obvious adjustments)?  Even still, how would they know?
Posted on 2005-12-01 18:50:25 by drhowarddrfine

As for MASM, I'm pretty sure that anything non-profit will be overlooked... but you can guarantee Microsoft to stick its nose in your business if your program becomes big enough.
How would they ever know?  If you were concerned later, couldn't you just re-assemble with another assembler (with obvious adjustments)?  Even still, how would they know?


Most amateur projects make it known what they use as a programming language. On top of that, the OS Dev community prides itself on letting the world know what they are programming their OS in. The bigger the project, the bigger the fan base, the bigger the desire to develop for that OS.

The only absolute way they wouldn't/shouldn't know is if the OS Dev project is closed-source, controlled by only a few people, and has a code-independent API ready to go on the first public release (ANSI C Calling Convention).
Posted on 2005-12-02 01:51:47 by SpooK
If no one requests anything, I assume the project is dead. I will do some more work on it soon :)

But someone may wait (without requesting) for you to continue :mrgreen:

OK, so I'm requesting the OS dev tutorial to be continued :)

My 5 cents about the tut so far: sometimes it's a bit 'long'. You see - starting OS developers are not ASM beginners (at least they're supposed not to be :mrgreen: ) so you don't have to explain things like what is the real-mode segment:offset thing. You can assume that the reader HAS programmed in 16-bit DOS at least a bit (and since he or she is oing to develop an OS it's ought to be true). Explaination of A20 is perfect: swift and clear. You just say WHAT it is, WHY and WHAT FOR it is, and HOW we do something with it (like: "we have to enable it", and then everyone can google for "enabling the A20").

Nevertheless it's great, so pretty please continue when you get some time ;)
Posted on 2005-12-02 04:28:09 by ti_mo_n