OSDev.org

Hello,

Well by asking this question i'm replying to an old topic in this forum, i hope no one minds.

When i was reading over an extremly helpfull post, i came accross this |quote|

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.)

I'm a newbie to c++ programming with a goal to in the end write an OS, because i'm starting to love c++ while reading the cplusplus.com tutorial. I am determined to make it a language i will know well and hopefully after more studying write an OS using it ( i know i have to assembly to in parts). But then i came accross this quote. How will i write an OS with out the libraries at hand?

Ice-o

To put it simply - you have to write the libraries yourself.
Some functions you write will be direct i.e. a 'direct' Printf.
This will let you print out things as your OS starts. Later you'll probably write a video driver with multiple screens (windows - whatever) and then you'll need to write an 'indirect' printf that prints to the current screen.
I found that I had to write two libraries, one for the kernel and one for applications. The kernel one has all the features of the application library but additional functions to do 'dirty' work like mapping memory pages etc.
Of course the above is all from *nix design perspective with LIB C and company. Your OS may have multiple libraries with everything seperated into functions. The code may be C/C++ / whatever, but the results won't be anything like 'standard' (if there is such a term) code.
Your OS will have the library you design for it. Compatibility is a design choice to be made.

may i ask how to write library?

Ice-o

p.s. Thank you for your reply.

By using the bare-bones C language constructs and using your natural born brilliance ;D.

Thanks i will look that up

bare-bones C language constructs

And we will see if i can prove my natural born brilliance later on.

Thanks u guys.

Ice-o

take, for example the "strcpy" function. You need it, but you don't have it... opening your favourite edition of Kernighan&Ritchie will give you something like this: (leaving all optimizations behind

etc. etc. Of course, it's more complicated for functions like "strtok" or "strstr", and probably even more complex to re-implement a fully fledged "String" class ...

It's not that hard to get C++ working without the standard libraries. It's only a matter of defining the functions expected by your C++ compiler. Unfortunately this is compiler dependent, so you may write one function set per compiler you support, or stick to one compiler (let's say gcc)...
You don't really need to create a proper library, since you are building a kernel, it may simply be a part of your kernel.

You may find http://www.invalidsoftware.net useful.

Virtual functions is probably the trickiest thing to implement, but they are link on this forum that could help you. However it is not mandatory, if you stick to a c++ subset.

I have probably other things to say about it since I am working on it, but my minds goes asleep

Good luck !

The C++ library isn't the language itself - it's only made to make programming easier.

Poseidon wrote: The C++ library isn't the language itself - it's only made to make programming easier.

I think there is a misunderstanding about what is the library we are speaking of: from ice-o, I understood that he speaks about the c++ runtime used by compilers. Without it, we can't run c++ using new, virtual functions... So in this case, the library supports the language, and is therefore mandatory.

Of course the c++ standard library is another thing.

Pype: here's a better version, which fixes a few of your bugs.
Notably, you don't return the destination pointer, and you don't copy the terminating \0.

mystran wrote: Pype: here's a better version, which fixes a few of your bugs.
Notably, you don't return the destination pointer, and you don't copy the terminating \0.

AAarrgh ... I should only post pseudocode ...

btw, the "while(*dst++=*src++)" was what i was trying to avoid. that's the ugliest thing i can think of in usual C tutorials ...

ineo wrote:

Poseidon wrote: The C++ library isn't the language itself - it's only made to make programming easier.

I think there is a misunderstanding about what is the library we are speaking of: from ice-o, I understood that he speaks about the c++ runtime used by compilers. Without it, we can't run c++ using new, virtual functions...

Virtual functions don't require runtime support. Exceptions do, and (AFAIK) RTTI. new() is a function defined in the library (and merely 'included' by default to make things easier).

That being said, the library is part of the language - it is defined in the same ISO standard document. However, the standard defines two types of applications: "hosted" and "freestanding". Only a "hosted" application can assume the standard library to be there; a "freestanding" application must live with a (very) limited subset.

And even that subset must be ported to the compiler / platform in question.

You might want to have a look at The Public Domain C Library. The v0.1 "release" there has everything a "freestanding" C library is supposed to have. Looking into its internals might teach you some things about what writing a library is about. It gets trickier with advanced functions like printf(), which - sooner or later - have to call kernel functions, at which point it gets really proprietary.

The documentation of the system calls assumed available by RedHat's newlib might give you yet more of an idea of the internals involved.

@mystran: thanks for that fine example of a strcpy. *gg* So I don't have to do *all* the horrible thinking by myself. And expanding it to strncpy should be a breeze I reckon.

btw: is strstr (substring?) a loop which calls strncmp in succession for each position in the string till the last POSSIBLE one?

Solar wrote:[...]
Virtual functions don't require runtime support.
[...]

Solar: I guess you didn't try using virtual functions in a C++ kernel. It won't work "out of the box". And it's not that easy to make it work !

Another link that is helpful in the C++ kernel quest: C++ ABI

ineo wrote: Solar: I guess you didn't try using virtual functions in a C++ kernel. It won't work "out of the box". And it's not that easy to make it work !

I admit I haven't (since I went KISS, and not very far for that matter), but I didn't find any references to indicate they were not working out-of-the-box. Thanks for the warning (in case I'd pick up my kernel project sometime).