OSDev.org

Posted: **Mon Nov 05, 2007 6:15 am**

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.

Posted: **Mon Nov 05, 2007 6:25 am**

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

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

Posted: **Mon Nov 05, 2007 6:35 pm**

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

Posted: **Tue Nov 13, 2007 3:05 am**

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

- 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

I wouldn't be too hard (I think?).

Posted: **Thu Nov 29, 2007 10:02 pm**

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

Posted: **Fri Nov 30, 2007 9:24 am**

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

Posted: **Sat Dec 01, 2007 3:55 am**

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.

Posted: **Wed Dec 05, 2007 6:48 am**

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

OSDev.org

what c library you have been ported to your os?