New to OS Dev, Need Few Pointers

[J]

Hi all,

I'm new to the world of OS development and could really do with being pointed in the write direction with regards to these two points:

1. Which language is best for writing my OS? C?, Assembly? both?

I am leaning more towards just writing it in assembly but what r ur opinions?

2. I know the specific pieces of the OS I have to design and write but where do I start when it comes to actually programming the OS?

Any help would be greatly appreciated.

Thanks
J

[zyp]

Some parts requires assembly, but C is easier to write and portable so people tend to use both. C for general stuff, and assembly where it's required.

See What order should I make things in?

[J]

so writing it purely in Assembly could affect portability?

[Candy]

so writing it purely in Assembly could affect portability?

If you're not careful, it just might.

[J]

Any chance you could expand on how or why it can affect portability?

I have done a fair bit of programming in my time in both education (college and university) and in my spare time and I know that all C commands can also be used in C++ but is C++ still as fast as C ?

[Ushma]

Code written in assembly language tends to be rather unportable, since it is by nature code for a specific processor. C can be compiled to the machine language of any processor you have a compiler for. Of course, that doesn't make your C code inherently portable, you still need to code portably if you plan to use it on different architectures.

C++ primarily makes some things you could do in C prettier. While I don't have figures, I wouldn't say that C++ is so slow that you should be worried about its performance.

[Candy]

Any chance you could expand on how or why it can affect portability?

I have done a fair bit of programming in my time in both education (college and university) and in my spare time and I know that all C commands can also be used in C++ but is C++ still as fast as C ?

My comment was pure cynicism. There's no way you can use assembly (being processor-specific) to be portable (non-processor-specific).

[Therx]

I know that all C commands can also be used in C++ but is C++ still as fast as C ?

Erm, when you write your own OS, you'll have to rewrite the functions... the normal libc isn't available (not sure if you knew that).

As far as using C++ goes. It's much more complicated to get going AFAIK (never tried myself but seems to be general opinion) because function names are jumbled. Although I seem to remember that whyme_t made a basic C++ kernel somewhere - prob linked to in the OSFAQ

Pete

[Brendan]

Hi,

I reversed the order of your queries so that my responses make more sense..

2. I know the specific pieces of the OS I have to design and write but where do I start when it comes to actually programming the OS?

The best place to start when it comes to the actual programming is to avoid the actual programming for as long as possible!

I recommend researching the hardware for all architectures you intend to support, and research how other OSs do things (here I'd include a version of Unix, a version of Windows and something like L4). Then create a list of features you want the OS to have, and a statement explaining the goals of the project (to create a unique OS, for educational purposes only, for research purposes) and why you feel the OS is worth doing.

After that, use the results of your research in conjunction with the list of features and statement of goals to develop the general design of the OS. This large document should include details on how each component works, how each component interacts with other components, and how portable each component needs to be (if portability was on your list of features). It should also include some details of protection, security, re-entrancy, which components belong in which binary/executable, how the boot works, etc.

Once this is done you can start working on the documentation for the kernel's API, and possibly any other interfaces between components. Start with the calling convention/s to be used, followed by details of each function/operation.

Then, for each binary/executable select which tools will be used to create it. It's possible to write an entire OS with nothing more than an assembler, but on the other hand you might want to use make, sed, grep, perl, assembly, C, C++ and a linker. Don't forget that one day you may wish to be "self hosted" and may need to port any tools you've used over to your own OS (sort of hard if you've used Delphi or something). Anyway, for each tool you'd need to research what it's capable of - for e.g. there's no point trying to write a boot loader in C if the compiler/linker can't generate 16 bit code.

I'd also recommend getting hold of one or more emulators for each target architecture - it can reduce your testing/debugging/development time a lot.

At this point it may be worthwile estimating how long it's going to take to write each binary/executable (then double the estimate), and then re-read your OS's goals (especially the "why you feel the OS is worth doing" part). You may find that (at some point during implementation) you will need to attract volunteers to assist with parts of the project (it's lucky you've got all that documentation for them already isn't it!).

Once all of the above is done it's time to start writing code . Start with a bootable "Hello World" and build on it. The actual coding should be relatively easy as all you do is implement things according to the documentation. At times you may need to adjust the documentation (especially if you did the research quickly, or if your design goals change) or add more detail to it, but this is normal.

1. Which language is best for writing my OS? C?, Assembly? both?

I am leaning more towards just writing it in assembly but what r ur opinions?

You must use assembly for some (smaller) parts of the kernel (and part or all of the boot code, depending on your design). Apart from this you can use any language/s you like. I'd recommend using the language you are most familiar with - it's hard enough writing an OS without learning a new language at the same time. When you research the tools you want to use you'll find out the problems associated with each.


NOTE: I haven't followed my own advice, and I don't know of anyone who actually has. Instead, most people are either writing a little hobby OS for education purposes (unlike me) or continually rewriting stuff they've already done several times (like me). This advice is intended to prevent the constant rewriting...


Cheers,

Brendan

[Warrior]

Yes, I jumped into OS Dev the wrong way. Relied too much on tutorials and didn't take time to learn how everything worked. Bad idea. I am still doing tons of research in my spare time (or during 6th period when we get to use Laptops =P)

Essentially I'm stuck in the pitfall of designing how my OS will work since frankly I don't know much about Linux and how it differs from Windows and the designs of other OSs. I guess my aim is an easy to use Operating System but have the user feel like he's in charge. (Access to all of the Computers running services and abilities to shut them down) also security would also be a factor in my Operating System.

Then again it's sorta hard for me to think of what I want my OS TO DO withought jumping into a huge wishlist of things (basicly being a huge OS, graphical user interface, etc..) and it also makes it hard because I don't know what I can and cannot do.

I'm reading the OS FAQ and I suggest you do the same, it has a lot of advice and information for people just starting out.

Theres my two(maybe more) cents.

[distantvoices]

*chuckle*

Even the tutorials didn't help. I've had to examine each piece of code: what it does, why it does it and if I can need it in this way. So, I merely took them as backing info to check if I'm on a good path.

As for the os Dev - I've attended an os Dev Class, but that's not been too elucidating. More theory than everything else. I've done about a year and a half quite immense research ere I've got a picture of what I want my OS to look like. Its a steep learning curve. In short time (if the knot goes open) you get a grip on so much that you feel your brain spinning around inside your head.

As for most other things this is valid here too: take a sheet of paper and sketch your ideas. This is better than coding like Hell Warrior and loosing the overview. With a sketch at hands you 'll stay on the path and achieve your goal easier. If you don't understand something - sketch it in the way you see it. If it still doesn't make sense, sleep over it, do something else, then throw away the old sketch and make a new one. Eventually it will make sense with some good pictures. That's the way I'm approaching unknown things. pictures.

the coding stuff itself is the smallest part of good development jobs. It's the thinking and fleshing out, which you 're doing mosta time.

as for your language question: I'd choose C & architecture dependent parts in asm. You can split architecture dependent/independent with a neat abstraction layer in the middle of your kernel - where these two layers meet. For porting you just need to adjust the architecture dependent stuff. (well, scheduling and picking a task to run is pretty platform independent, but throwing the Task to the cpu is another pair of shoen)

stay safe.

[Solar]

I know that all C commands can also be used in C++ but is C++ still as fast as C ?

Erm, when you write your own OS, you'll have to rewrite the functions... the normal libc isn't available (not sure if you knew that).

As far as using C++ goes. It's much more complicated to get going AFAIK (never tried myself but seems to be general opinion) because function names are jumbled.

The name mangling (that's the terminus technicus) of C++ isn't that much of a problem, because you can always tell C++ to use plain C linkage via [tt]extern "C" int foo()[/tt] (for example).

Problem #1 are those features that require runtime support - most notably, exceptions. This runtime support must be implemented by you (just like the standard library), and to add insult to injury, this is compiler-specific. Your GCC exception support wouldn't work for someone wanting to compile your OS with, say, ICC.

Problem #2 is that you don't have a standard library at hand. This not only means you don't have [tt]cin[/tt] or [tt]cout[/tt], but you also don't have any [tt]new()[/tt] you could use. (Somethign oft overlooked - you don't have to explicitly include anything to use [tt]new()[/tt], but it's still part of the library, not the language.)

Problem #3 is that it is really easy to write C++ in a way that is terribly ineffective, or just wrong. C++ does many things for you, which is a blessing, unless you don't know about it, because then it's a curse. Don't try to use C++ unless it's really your favourite language and you know it inside out.

So, if you can live without exceptions (and, AFAICT, RTTI), just disable support for them on the command line, and you can write a BareBonesC++ kernel. But tread carefully, C++ is a much more complex beast than C.

[J]

Hi all,

Your answers are MUCH more than I was expecting (normally i get rubbish 1 or 2 line answers) but you people have certainly helped me a LOT. ;D

I'd just like to say thank you as I now have an understanding and place to start and the few pointers I requested.

Big Thank You to all of you.

[ice-o]

Problem #2 is that you don't have a standard library at hand. This not only means you don't have cin or cout, but you also don't have any new() you could use. (Somethign oft overlooked - you don't have to explicitly include anything to use new(), but it's still part of the library, not the language.)

how do you fix this problem if you are determined to write an os mostly in c++?

Ice-o

[Pype.Clicker]

well, you'll have to write a memory allocator that uses only static/local objects, but no "new" operator ...