OSNews

I find it funny how he links v2os with "pulling off being 100% assembly", and yet labels Uuu with not being able to stick to one language in his previous OS article. V2_OS is the one that died because of a kernel rewrite (still in assembly). Uuu wasnt canceled because of reasons like that, we simply didnt see the point of continuing it any further than it was.

Nice tips for anybody desiring to develop an operating system. And like Emmanuel said, unless it's for some kind of weird religious reason or just for passion, use HLL. That way if you ever replace that x86 computer you've got right now by one of those new shinning 64bit beast, all you'll really need for most of your code will be to recompile, not rewrite.

Same if you feel nostalgic or geek enough to go and try some server machines, a nice SGi, Alpha or Sun is sure to make your friend drools when they see it booting your OS after only a weekend of work.

I'm personally attached to low-level development. Not necessarily to x86, just to about any processor. If I could get a better feel of the hardware by grinding my teeth on the address bus I would

Assembly forever

The moral of the story is to select reliable, proven tools. Save yourself frustration and time by being unable to accuse the toolset when something goes wrong.

Even proven, reliable tools can have their problems. You highlight a GCC 3.0 bug in the article, and I've also run into a very subtle problem in the last couple of days.

I had Glibc compiling on AtheOS 0.3.7, and I thought that all was good. However, when I tried to compile the exact same code on Syllable, one of the Makefiles fails, and the build process stops.

After a cry for help on the mailing list (Thank you Andrew!) it turns out that the problem is apparently due to a subtle difference in the command enterpreter, probably due to Syllable using a slightly newer version of GNU Bash & Make.

You're damed if you do, damed if you don't! If you didn't get it from Emmanuels article; Operating Systems are tricky, slippery beasts. You have to be the lion tamer

you probably want to have the smallest interface to your kernel as possible. Logic dictates that the less entry points you have from the outside world, the less you have to code and document.

thats a wonderfully lazy argument for a microkernel if ever i heard one!

He points out that writing an operating system is much more difficult than writing an applications program. I wonder how many hobbyist OS people start out writing an OS and get stuck because they *don't know enough* about programming to do it?

I wonder how many hobbyist OS people start out writing an OS and get stuck because they *don't know enough* about programming to do it?

That is a very good point indeed. The answer to this question is -- too many. There are too many people who are just getting into programming and who decide they want to write an operating system, without even knowing how to program well. I've seen too many people like that, and I think Dave Poirier at least understands what I mean.

I wonder how many hobbyist OS people start out writing an OS and get stuck because they *don't know enough* about programming to do it?

That is a very good point indeed. The answer to this question is -- too many. There are too many people who are just getting into programming and who decide they want to write an operating system, without even knowing how to program well. I've seen too many people like that, and I think Dave Poirier at least understands what I mean.

So?

You make this sound like a bad thing. You can replace "writing an OS" with "writing a game" or "writing a 3D engine".

If programmers never go in over their head, how else would they learn anything? The real skill is in realizing that they're in too deep and either learn more to solve the problem, or hopefully go back to and fix the answer that they hacked out in ignorance when they learn more.

I remember trying to write an "Ogre" game (famous mini board game) a zillion years ago, and it was working okay until I actually got to pathfinding. Boy, was THAT a complete mess and a disaster. Ruined the whole project. Had NO IDEA what I was doing. You should have seen the tank zig zag and BACKING UP during attack. Amusing in hindsight, frustrating at the time.

But, the point is that when you get to that point where you're stonewalled, you find out whether the project is still interesting enough to be worth jumping the hurdle placed in front of you. In my case, it wasn't, I had other games I wanted to play with (and I eventually figured out the simple movement algorithm...).

Will,

you make a fair point I think. However, there is a difference between taking on something you think's going to be hard and something that's in a completely different ballpark. I guess you just have to be pragmatic about your abilities and time available; I don;t think Emmanuel is saying don;t start it unless you know you can do it. Sometimes it will work out and sometimes it won;t

Codefire.

You make this sound like a bad thing. You can replace "writing an OS" with "writing a game" or "writing a 3D engine".

OK, fair enough. It certainly is possible to write an OS with very little programming experience -- but it would be quite a bad OS. It's possible to write a good game without being able to program well (if you count concept and design over robustness of code). Unless you the machine and your intended design inside out, however, any OS you write will be either very limited* or buggy.

--
* Observe the relative numbers of boot loaders and OS kernels available on the Internet. It's easy to just give up after writing a boot sector program, or writing a boot sector program and a short kernel stub.

OK, fair enough. It certainly is possible to write an OS with very little programming experience -- but it would be quite a bad OS. It's possible to write a good game without being able to program well (if you count concept and design over robustness of code). Unless you the machine and your intended design inside out, however, any OS you write will be either very limited* or buggy.

Umm...again...So?

We're talking about hobbyists. Folks who like to play with computers for fun.

Maybe they're happy that they've got the bootloader working? They didn't get the scheduler done? Bummer, but Big Deal. But one thing they did get out of it, they learned that they don't like writing OS's, for whatever reason.

Some will rise to the challenge and persevere, but most won't. There are a lot of dead, incomplete, buggy, badly coded 3D engines out there as well. But the fact that there are all of these crappy bits of OS code floating around in the ether shouldn't discourage anyone who has the interest to try it out for themselves.

Maybe they have the knack for the arcane art of OS writing. Maybe as they reach each complexity they soar right on past surprising themselves at how easily they beat something that "was so hard". Then, they get to the linker/loader and give up, or whatever.

It just sounds like y'all are saying that these folks shouldn't even try. The saying is "on the internet, no one knows you're a dog". On the other hand "once your code is compiled and working, nobody knows its badly designed and written without indenting."

Replace writing an OS with "installing kitchen cabinets" or "laying your own tile floor". Lots of disasters out there.

These unqualified hobbyists, while perhaps with mild delusions of grandeur, are HOBBYISTs! They're doing it for fun. If it gains any traction or any communal repect, then swell. If not, then, hey, swell again. Beats watching 90210 re-runs.

I just think that if you're in a position to encourage and help the unqualified become more qualified, and they're respectful of your time, then help these people out.

Will,

The purpose of the article is to try and help people size up the complexity of what they are getting into, and dive in better prepared. I like seeing a lot of hobbyist projects online; I hope this series of articles can help people progress and have more fun. If you look online, you will find a large amount of articles about setting up your GDT or managing virtual memory, but none about getting prepared.

Thanks for your comments

Matt,

thats a wonderfully lazy argument for a microkernel if ever i heard one!

This is not what I mean. Maybe I didn't express it right. The general idea is to export the minimum number of ways of doing the same thing to the 'outside world'. It's a common trait of first designs, to provide five different mutexes and three types of semaphores and, on top of that, explicit primitives for suspending a thread, for instance.

This adds a lot of complexity and code with potential bugs. If you're struggling with developing a kernel, it's better to think about one good primitive and reduce the scope of the problem. If you're having no problem whatsoever developing your system, I am in no position to tell you what architecture to adopt or what primitives to provide.

Richard,

This is my opinion about the originally released version of V2_OS, which intended to be a fast, monotasking system for digital media playback. It got the job done.

The UUU project cites the dependency to assembler in the project termination document. "Chapter 2. Failure points :: 2.1. Skilled Assembly Programmers".

Quoting Dave Poirier, the UUU project founder and VOiD architecture luminary:

"In conclusion: While in theory achievable, the development of a complete operating system entirely in assembly in the current economic context cannot be justified over the development under other languages for which nowadays very good compilers are available."

This document oriented my analysis of UUU.

If it's really just a hobby OS, then fine, there's no problem. Some OS creators readily admit it, too, like Travis G. and his NewOS.
But some people *do* get visions of grandeur. I remember watching the FreeDows site forever, waiting for updates. It wasn't until much later that I found out just how little had been accomplished, or that the original group had even split over policy conflicts.
UUU certainly sounded interesting, though.

I guess the line that irked me was this one from Tim:

There are too many people who are just getting into programming and who decide they want to write an operating system, without even knowing how to program well.

To me, that's no big deal. So what. These folks who do not have the skills and what not to write an OS (or a 3D Engine, or install kitchen cabinets) are not hurting anyone by trying to do it.

It sounds as if "too many" of these inexperienced and/or ignorant people trying to write OSs (etc) are "a problem", and I just don't see it that way.

Let them flail away.

If it's really just a hobby OS, then fine, there's no problem.

And if the folks writing this stuff are truly incompetent, then it will probably never even raise to the level of "Hobby OS". I guess the "problem" is that these folks come roaring in with a bunch of glossy lit, high hopes, and "I've got the boot loader, who wants to help with the rest?".

I'm not deep enough in the community to actually see any of these things, sticking more closely with the mainstream stuff. So, I guess I'm not in the loop of what the real problem is here.

Maybe someone can enlighten me.

I guess the line that irked me was this one from Tim:

There are too many people who are just getting into programming and who decide they want to write an operating system, without even knowing how to program well.

OK, I apologise. There can never be too many people getting invovled in OS development. Maybe I should re-word my sentence:

"It disappoints me to see people who are unable to program well who think they can jump in and write a good operating system."

It's my belief that kernel coding is something that you have to work up to; that you need a solid grounding in user-mode development first. I have learned a lot from my own experiences in OS development (and I'm better off for several kernel rewrites), but I really would be flailing if I didn't have the prior experience I have.