OSDev.org

This is all quite humorous.. Please continue.

gaf wrote:If you know nothing you just have to start somewhere and I don't see why this somewhere couldn't be an operating system.

You can, but it's not the best place to learn. It's like trying to learn to tie your shoes while swimming from a man-eating alligator. Meaning, by starting with user space programs, you'll be able to learn a more broad spectrum of abilities quicker. (It's very difficult to learn about memory management when you are trying to implement malloc in the same instance. )

Alboin wrote:It's very difficult to learn about memory management when you are trying to implement malloc in the same instance.

That's pretty much what I had in mind when wrote "most basic programming techniques". Certainly I agree with you that these primary skills are best learned in a more programmer friendly environment..

Alboin wrote:It's like trying to learn to tie your shoes while swimming from a man-eating alligator.

Personally I started programming in C++ and OS development was the first serious project I have tackled. Maybe the learning curve really is a bit steep at the beginning, but it doesn't take very long until you get the hang: After all there's no better way to learn about the importance of aligator-management than having been chewed by it for a couple of times

I've always prefered directly confronting projects without taking numberous intermediate steps. Rather than going from VisualBasic to Pascal before continuing with C and finally changing to C++ I simply learned the language I wanted to know. Doing so from scratch might take longer than conveting from C to C++ but all steps combined the efford is probably just the same.

In my opinion both approached have their advantages and I wouldn't want to say that either is necessarily better than the other. It probably depends on your personality which one suits you better..

regards,
gaf

gaf wrote:

Alboin wrote:It's very difficult to learn about memory management when you are trying to implement malloc in the same instance.

That's pretty much what I had in mind when wrote "most basic programming techniques". Certainly I agree with you that these primary skills are best learned in a more programmer friendly environment..

Alboin wrote:It's like trying to learn to tie your shoes while swimming from a man-eating alligator.

Personally I started programming in C++ and OS development was the first serious project I have tackled. Maybe the learning curve really is a bit steep at the beginning, but it doesn't take very long until you get the hang: After all there's no better way to learn about the importance of aligator-management than having been chewed by it for a couple of times

I've always prefered directly confronting projects without taking numberous intermediate steps. Rather than going from VisualBasic to Pascal before continuing with C and finally changing to C++ I simply learned the language I wanted to know. Doing so from scratch might take longer than conveting from C to C++ but all steps combined the efford is probably just the same.

In my opinion both approached have their advantages and I wouldn't want to say that either is necessarily better than the other. It probably depends on your personality which one suits you better..

regards,
gaf

Very true. It appears we have reached a stalemate. Well played.

gaf wrote:I've always prefered directly confronting projects without taking numberous intermediate steps. Rather than going from VisualBasic to Pascal before continuing with C and finally changing to C++ I simply learned the language I wanted to know. Doing so from scratch might take longer than conveting from C to C++ but all steps combined the efford is probably just the same.

So then for the same amount of effort that someone who took those intermediate steps has learned Visual Basic, Pascal, C and C++, you have just learned C++?

urxae wrote:

gaf wrote:I've always prefered directly confronting projects without taking numberous intermediate steps. Rather than going from VisualBasic to Pascal before continuing with C and finally changing to C++ I simply learned the language I wanted to know. Doing so from scratch might take longer than conveting from C to C++ but all steps combined the efford is probably just the same.

So then for the same amount of effort that someone who took those intermediate steps has learned Visual Basic, Pascal, C and C++, you have just learned C++?

If you know C++ you really almost know C. And if you know C you almost know Pascal. (And perl and python, and basic, and angol.) So once you know C\C++, you can program in nearly any language as most of them are based on C style syntax. (Except Lisp, Brainf*ck, etc.)

I know C++, C, VB, Python, PHP etc... But IMHO the best way to write a beginner/hobby OS is in Assembly. Now, don't shoot me because of my blasphemy .

If you're writing your first OS (like I am), write it in Assembly. This way you can understand what's happening behind the scenes. Of course, this means you'll only really be able to make a simple monotasking kernel with few other features (mine only has about 5 or 6 commands, plus debug (lol, DisplayRegisters function is really useful))...

Of course, once you understand the machine and everything your simple OS is doing, you can then look into C and other languages.

Just my 2c...

BTW, I do all my testing in QEMU, because it means that if I mess up disk I/O all that happens is that an image file gets ruined, which is easy to fix. It also means that all I have to do is run a batch file that builds my OS, writes the image file and runs QEMU.

Note: I also had trouble with Bochs, which is why I chose QEMU, thanks to advice of others on this forum.[/b]

pcmattman wrote:BTW, I do all my testing in QEMU

I like to test my kernel in as many virtual machines as possible, just to be safe

At the moment I'm using Bochs + QEMU on Linux and Virtual PC + VMware + Virtualbox on Windows. I test on all of these before running on real hardware.

Cheers,
Sean

My *really first* OS, called "TextLiner OS", was entirely in 8086 ASM.
I discontinued that work, because that OS sucked a lot. It had no FAT bootsector, but its own, and it was really simple. The entire OS was in clean real mode, no additions like "memory manager", "unreal mode" etc.

inflater

Ok, maybe the first OS as a whole shouldn't be done in assembly, but I wrote a (very) simple kernel in assembly which has helped me greatly in figuring out how everything works together. I'm also able to use a lot of functions from my asm kernel in my C kernel (like console i/o).

In the end, it's all a matter of choice.

Oh yeah, I tried my OS in Bochs but it sort of crashed hopelessly (discussed in another thread, and Bochs crashed not my OS) and QEMU was suggested.

Assembly is just generally awesome. Really, it is. You can move anything, anywhere. It's like, Oh! I want to write something somewhere! I'll just put it here.. I really do love it. Or, Oo! Let's push eax and then pop it to ebx!!! Really? Does programming truly get any better than this!? I think not. Just awesome. It is without words.

Yet, to my utter misery, doing normal everyday tasks in assembly is like being thrown into the center of the river Styx.

Exactly! Of course, the world would be a better place if we made an OSDev language that combined the best parts of Assembly with the best parts of C, but that's too hard... and you can do it anyway with any half-decent linker.

pcmattman wrote:Exactly! Of course, the world would be a better place if we made an OSDev language that combined the best parts of Assembly with the best parts of C, but that's too hard... and you can do it anyway with any half-decent linker.

You do know that C was designed as a small change to assembly, more of a language between cobol/fortran and assembly? Of course, you're not the first to think this. Try HLA (high-level assembly), designed by Randall Hyde, for such a language.

Hmmmm...

Alboin wrote:

urxae wrote:

gaf wrote:(Except Lisp, Brainf*ck, etc.)

Why you censor a programming language Brainfuck? It is not mean to be censored - it doesn't mean "brain f**king programming language", mate

inflater