OS Limitation when using C

someprogr · Post by **someprogr** » Tue Dec 25, 2007 11:44 pm

How limited are we when using C to write an OS?

The issue I realized is that when we use C and its libraries: stdio.h, its OS dependent.

If I want to open a file, say using fopen(), thats an OS dependent function, that you couldn't use when programming your own OS (right?)

So basically do we have to go as far as writing our own C compiler to write the OS in C?

Brynet-Inc · Post by **Brynet-Inc** » Wed Dec 26, 2007 12:23 am

No. You have to write your own C library... or port one yourself.

Typically you have to write support libraries for any language you chose to write your OS in, this is NOT a limitation of C.

Please do some initial research on the subject please...

JamesM · Post by **JamesM** » Wed Dec 26, 2007 1:46 pm

If I want to open a file, say using fopen(), thats an OS dependent function, that you couldn't use when programming your own OS (right?)

Well your OS may not actually have any concept of 'files', and if it does, the implementation is still completely OS-dependent. So fopen() CANNOT possibly work! It is impossible. So it's a moot point.

lukem95 · Post by **lukem95** » Mon Dec 31, 2007 7:37 am

ALL the functions you use in C are dependant on the operating system you compile it for, they are defined in the header files.

you must rewrite your own functions in order to use them, this can be using pointers and other tools in c, or using inline asm.

if you dont understand (i tried to make it simple), look at the sourcecode of "brans development kernel" over at osdever.net, it has several functions in main.c such as strcmp() you can look at as an example

~lukem95

thegreatseph · Post by **thegreatseph** » Mon Dec 31, 2007 8:51 pm

JamesM wrote:
If I want to open a file, say using fopen(), thats an OS dependent function, that you couldn't use when programming your own OS (right?)
Well your OS may not actually have any concept of 'files', and if it does, the implementation is still completely OS-dependent. So fopen() CANNOT possibly work! It is impossible. So it's a moot point.

Exactly, even in assembler you cannot call Int 21h to open a file if you aren't running DOS. However, the IBM PC does have many built in functions, you don't have to directly address video memory to print a char on the screen, you can use int 10h function 0eh. Due to this I don't have to rewrite the entire Borland RTL for TP7 to use with my OS just the implementation specific ones.

binutils · Post by **binutils** » Tue Jan 01, 2008 4:09 am

If hardware platform changed radically, you have to re-implement all source base to works with it.

BTW, if we are using SSD(except it's defect) instead of HDD, linux kernel structure will be shape-shifting more than before.

http://www.theinquirer.net/gb/inquirer/ ... cited-ssds

Solar · Post by **Solar** » Thu Jan 03, 2008 2:05 am

I don't really understand what's the problem here.

The C library function fopen() opens the given file in the given mode, and returns a pointer to a FILE structure. This pointer can subsequently be passed e.g. to fwrite() to define the target of the write operation.

On a POSIX system, this fopen() would, internally, call the operating system function open(), with some mapping applied to the mode. open() returns an integer ("file descriptor"), which is stored in the FILE structure subsequently returned by fopen(). Then, fwrite() has this file descriptor available to call the operating system function write().

So basically, at some point you have to map the language primitives to the operating system primitives. This must be done regardless of the language you are using.