OSDev.org

WaterOS...

A subtle aspect of C is that there are no "default" functions defined in the language.

The Standard C Library (libc) is simply an adjunct that happens to be useful.

To address your question in regards to C and OS programming, this subtle aspect of C is *very* important:

1) libc generally is a "user-space" library that communicates with the OS via some interface such as the syscall mechanism.

2) libc being tied to this interface - generally - cannot be used in the OS kernel its self.

That said - when developing an OS you are left with nothing but the C language and no suppporting libc whatsoever.

For example - if you examine the linux kernel source code or any of the forum's OS's you will find that while the kernel source code has something *called* libc - it is in fact a scaled down, specialty set of functions they had to write from scratch to get it to work with their OS internals.

So again - in the context of an OS - learning C - is extremely important and assumptions made that a set of existing functions will be there are null and void: void *assumptions = null;

But all is not lost....

newlib, uclib, and even musl are libc libraries that you can bend to your will and *make* work within your kernel if you so choose. However - you must know the trade offs you make when deciding to do so...

The moment you decide to chuck a libc in your kernel, you are committing to adhering to the API's the Standard C Library carries with it - if you enable POSIX then even more so....

So down the rabbit hole:

1) add libc to kernel
2) somehow connect stdout to screen
3) somehow connect stdin to keyboard
4) open()/close()/read()/write() ---- hmmm a VFS? sure...
5) maybe add threading
6) oops threading breaks 2,3,4 - make them thread aware
7) pipes between threads and processes
maybe some graphics....
9) how do I move the console from the text mode output to graphics output
10) shim a console proxy in
11) too much stuff hardcoded - hey I will make them devices like /dev/ptty
12) VFS breaks cause it wasn't threaded enough
13) etc...

So good luck and have fun.

cheers

dchapiesky wrote:WaterOS...

A subtle aspect of C is that there are no "default" functions defined in the language.

The Standard C Library (libc) is simply an adjunct that happens to be useful.

To address your question in regards to C and OS programming, this subtle aspect of C is *very* important:

1) libc generally is a "user-space" library that communicates with the OS via some interface such as the syscall mechanism.

2) libc being tied to this interface - generally - cannot be used in the OS kernel its self.

That said - when developing an OS you are left with nothing but the C language and no suppporting libc whatsoever.

For example - if you examine the linux kernel source code or any of the forum's OS's you will find that while the kernel source code has something *called* libc - it is in fact a scaled down, specialty set of functions they had to write from scratch to get it to work with their OS internals.

So again - in the context of an OS - learning C - is extremely important and assumptions made that a set of existing functions will be there are null and void: void *assumptions = null;

But all is not lost....

newlib, uclib, and even musl are libc libraries that you can bend to your will and *make* work within your kernel if you so choose. However - you must know the trade offs you make when deciding to do so...

The moment you decide to chuck a libc in your kernel, you are committing to adhering to the API's the Standard C Library carries with it - if you enable POSIX then even more so....

So down the rabbit hole:

1) add libc to kernel
2) somehow connect stdout to screen
3) somehow connect stdin to keyboard
4) open()/close()/read()/write() ---- hmmm a VFS? sure...
5) maybe add threading
6) oops threading breaks 2,3,4 - make them thread aware
7) pipes between threads and processes
maybe some graphics....
9) how do I move the console from the text mode output to graphics output
10) shim a console proxy in
11) too much stuff hardcoded - hey I will make them devices like /dev/ptty
12) VFS breaks cause it wasn't threaded enough
13) etc...

So good luck and have fun.

cheers

When I mean C for OS development, it doesn't mean use stdio.h for it.
When I mean C, I mean use stdio.h for it.
This is OS development. Where would I learn C for a kernel?

WaterOS wrote: When I mean C for OS development, it doesn't mean use stdio.h for it.
When I mean C, I mean use stdio.h for it.

To clarify - read my last post again...

WaterOS wrote: This is OS development. Where would I learn C for a kernel?

You don't learn C for a kernel. You write a kernel in C. Learn C. Write a kernel.

See http://wiki.osdev.org/

Read.

Cheers

WaterOS wrote:When I mean C for OS development, it doesn't mean use stdio.h for it.
When I mean C, I mean use stdio.h for it.
This is OS development. Where would I learn C for a kernel?

I believe Tanenbaum is the right book for you, together with Minix CD.