what c library you have been ported to your os?

[mcheung63]

what c library you have been ported to your os?
thanks
from Peter ([email protected])

[JamesM]

Newlib. I didn't like the glibc porting mechanism (it was like eating a baboon).

And I would advise against putting your email address in public forums: SPAMATTACK!!!!

[Combuster]

PDCLib. Good code and it suits my tendency to break with traditions

[kubeos]

I'm using OSlib's libc, with my own file support added.

[pcmattman]

Newlib - it's completely compatible with GCC/binutils and dead easy to port.

Porting newlib will also allow you to compile *nix source without heavy modifications - means bash and friends are quite simple to port.

[01000101]

Mine is my own I guess.
I haven't really followed any of the other C libraries.

I try not to port as much as I can.

[AndrewAPrice]

I'm in the process of porting newlib. But, I've ran into some linking troubles. Right now I"m concentrating on a better memory management system though.

[mcheung63]

hi kubeos
What is the website of OSlib's libc? i can't find it in google
thanks

[AndrewAPrice]

What is the website of OSlib's libc?

Try http://ro-oslib.sourceforge.net/release-6.90.html (look at the blue bar on the left).

I'm guessing it's part of the main OSLib package.

[kubeos]

I'm just using the one included with the main oslib distribution.

http://oslib.sourceforge.net

But I should really get newlib working as I would like to start porting some stuff over... especially gcc.

[binutils]

glibc (i386/i686 -> x86_64( with --disable-multilib) )

wish to have portable plan9 c library

[AndrewAPrice]

I've stopped supporting C in my kernel in favour of my own C++ API (which isn't STL compliant). I know I've probably made it harder to port software across, but:
- It's my OS and I'd much rather work on what I find to be important than concentrating on maintaining a compliant-library.
- If down the track it's required, it should be easy to port a C or C++ standard library as a wrapper over my native C++ API.

Having had experience with working on projects like game engines, I'm use to creating and using my own classes other than STL's (i.e. my own strings, vectors, lists, etc), so realistically I'm treating my programming interface as a kind of "program engine".

Along with the C++ API, I'm going to include a listing of syscalls so if someone wants to use another languge or write their own API from scratch they can. Although you'd loose a lot of functionality (i.e. the widget managing /drawing code will be in my C++ API, so by manually using syscalls you'd only get access to a blank window framebuffer and the rest would be up to you).

[AJ]

Hi,

The 'program engine' way of looking at it sounds quite interesting. Have you managed to add things like OS-level exception and RTTI support? If so, how did you get on?

Cheers,
Adam

[AndrewAPrice]

I haven't fully implemented everything but it'll work something like this:

At the kernel level you have syscalls - they will do basic things like create a blank window (with a pointer to the frame buffer), request/wait-for the next event (key down, message received, etc).

When you write a program, you will create an instance of the Application object, inside of it you will find wrappers around file IO/networking/threading/window management/etc.

In regards to window management, all the kernel does is provide an empty frame buffer. All widget code is in the library. When a program creates a window, they can decide if the library is responsible for widget management, or if they wish to have direct access to the frame buffer (for a multimedia application for example).

The program engine is also responsible for other things, like manually handling kernel messages and translating them correctly. And also calling the program's Update() loop. There are multiple ways of doing things also, for example, an event-based program may set a function to be called as soon as specific key is pressed, a multimedia-based program may check to see if a key's state is down on each loop.

The only disadvantage this system has, is that traditional console programs are harder to manage. Consider the following code:

Code: Select all

std::cout << "Enter your name:\n";
std::string name;
std::cin >> name;
std::cout << "Hello " << name << "\n";

These sort of 'procedural' programs are harder to deal with, since key states are handled by the program engine, which is only called when the Update() loop reaches the end and the program then waits to handle more messages, calls Update() again, handles more messages, etc. When std::cin is called, the function cannot reach the end, therefore the program engine cannot handle key input. (I'm sorry if this is sounding confusing, but I don't know any way to explain this simpler.) My solution is for console programs and process-intensive functions to be ran in one thread
while the program engine runs in another, that way it can still handle messages (key presses, window movement) while the other thread can do what it likes.

[Candy]

The only disadvantage this system has, is that traditional console programs are harder to manage. Consider the following code:

Code: Select all

std::cout << "Enter your name:\n";
std::string name;
std::cin >> name;
std::cout << "Hello " << name << "\n";

These sort of 'procedural' programs are harder to deal with, since key states are handled by the program engine, which is only called when the Update() loop reaches the end and the program then waits to handle more messages, calls Update() again, handles more messages, etc. When std::cin is called, the function cannot reach the end, therefore the program engine cannot handle key input. (I'm sorry if this is sounding confusing, but I don't know any way to explain this simpler.) My solution is for console programs and process-intensive functions to be ran in one thread
while the program engine runs in another, that way it can still handle messages (key presses, window movement) while the other thread can do what it likes.

Double threaded application, one thread managed by the framework that handles the messages, the other can only read/write to/from predefined streams that block sending a message to the other thread waiting for a reply. The framework thread is asynchronous, the other is synchronous, without problems and without a dozen message loops.