what c library you have been ported to your os?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
AndrewAPrice
Member
Member
Posts: 2309
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

Candy wrote: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.
That seems like the best solution. The framework will start it's own thread in the background, that'll handle all kernel events.

This is an example of how a getchar() implementation would work:
(Program Thread = The program's primary thread.
Framework Thread = The background thread created by the framework for handling events.)
  • Program Thread: getchar() is called
    Program Thread: set some variable somewhere to say we're waiting for a key input
    Program Thread: place self in an idle state
    System: Key is pressed
    Kernel: Send "Key down" message to Framework Thread. (Which wakes up the framework thread.)
    Framework Thread: Receives the key down message from the kernel.
    Framework Thread: Translate the key message into an ASCII character.
    Framework Thread: Realise getchar() is waiting for a variable and wake Program Thread.
    Program Thread: getchar() returned the key pressed
    Program Thread: thread continues executing more code as before
Why does the framework translate the key message into an ASCII character instead of the kernel? Because sometimes we rather then scan code (e.g. try representing an arrow key in ASCII), or if we have a strange keyboard with extra keys on it (a multimedia keyboard?) a program could check the scan code of this key. It also holds the advantage that if I want to switch to Unicode in the future, I only need to change the framework and not the kernel.

In the near future I'm hoping to have the framework dynamically linked, another advantage of having as much as possible in the framework rather than in the kernel, since the steps involved in a major system update to the input/GUI/etc may be as simple as:
- Tell all programs to save and exit.
- Install the new framework library.
- Restart all programs and reload work.
Instead of requiring a reboot to reload the kernel.
My OS is Perception.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Post by Solar »

Combuster wrote:PDCLib. Good code and it suits my tendency to break with traditions 8)
/me bows.

Well, me, I didn't port anything, but rather started implementing my own as I felt that was something where one person could actually make a difference (as opposed to my OS project which died the agonizing death that is so common among OS projects).
Every good solution is obvious once you've found it.
User avatar
JackScott
Member
Member
Posts: 1036
Joined: Thu Dec 21, 2006 3:03 am
Location: Hobart, Australia
Mastodon: https://aus.social/@jackscottau
Matrix: @JackScottAU:matrix.org
GitHub: https://github.com/JackScottAU
Contact:

Post by JackScott »

Solar wrote:Well, me, I didn't port anything, but rather started implementing my own as I felt that was something where one person could actually make a difference (as opposed to my OS project which died the agonizing death that is so common among OS projects).
Also from me, thanks. I've used portions of the public domain code, it's good (not using the whole lot). Now all we need is somebody to actually write a standard driver interface (EDI was good, but it seems to have disappeared?).
User avatar
AndrewAPrice
Member
Member
Posts: 2309
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

I have my stable layout for my API now. It's very non-standard-object-orienty. Here is an example of a console program which creates a console window and uses it for input/output:

Code: Select all

#include <Perception.h>

using namespace Perception;

Application *application;
Console *console;

void progmain();
void update();

int main()
{
    application = new Application();
	console = application->GetObjectFactory()->CreateConsole();

    console->SetColour(0xE,0x0);
	*console << "Welcome to SampleProgram.prog!\n";

	application->CreateThread(&progmain);

	application->Run(&update);

	application->GetObjectFactory()->Destroy(console);

	delete application;

	return 0;
}

void update()
{
}

void progmain()
{
	while(1)
	{
		*console << "Enter a string: ";
		Core::String8 string = console->GetString();;
		*console << "\nYou entered: " << string << "\n";
	}
}
It'll output something like: (ignore the crappy ASCII window I just drew)

Code: Select all

|------------------------------------------------------|
|                                                      |
|------------------------------------------------------|
|Welcome to SampleProgram.prog!                        |
|Enter a string: hello!                                |
|You entered: hello!                                   |
|Enter a string: this is not that fun :(               |
|You entered: this is not that fun :(                  |
|                                                      |
|                                                      |
|------------------------------------------------------|
It might seem like a lot of code to just get a simple console window, but you have to remember that I've designed my API to be mostly used in event-based GUI programs. And it's not THAT much code - have you tried doing Win32 GUI programming? \:D/

I'm expecting someone here to complain "your system is crap :x - I want to use printf() or std::cout with none of that setup code" but if they're really that eager to use them, then they're welcome to port C standard library or STL as a wrapper around my API :wink: I wouldn't be too hard (I think?).
My OS is Perception.
User avatar
AndrewAPrice
Member
Member
Posts: 2309
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

I've written an introduction tutorial to using the SDK for my OS:
http://www.osdev.org/wiki/User:MessiahA ... _Tutorial2

Tutorial 1 (which I haven't made yet) is about setting up the SDK. The SDK will run on Windows (it includes Cygwin) and Linux (you need to have your own i386-ELF build of GCC).

I'll release the SDK along with my OS when I reach the first release - which should be within a few months since I've got only 10 items on my todo list (unless I get distracted).
My OS is Perception.
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

Why does the framework translate the key message into an ASCII character instead of the kernel? Because sometimes we rather then scan code (e.g. try representing an arrow key in ASCII)
How do you represent a scan code? They can be multiple bytes...
User avatar
AndrewAPrice
Member
Member
Posts: 2309
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

JamesM wrote:
Why does the framework translate the key message into an ASCII character instead of the kernel? Because sometimes we rather then scan code (e.g. try representing an arrow key in ASCII)
How do you represent a scan code? They can be multiple bytes...
Then I'll send multiple bytes.

I don't send 'string' of scan codes or buffer them, they get added to the focused process's event pool one by one.

I'm working out a way to send strings between the kernel/user programs without giving a buffer since strings in my framework are dynamically allocated as you add/remove characters.
My OS is Perception.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

I've got some version of PDCLib kinda ported, but haven't really used it. Then I got my own "routines-I-need-right-now" library..

I don't know what route I'm going to take. I'd like to get rid of C in the userspace if at all possible, and I'm not interested in synchronous I/O so porting a full-blown C library is kinda questionable, at least before the native interfaces are ready and up and running and supported and I've proven that they are superior to anything standard...

:P
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Post Reply