OK. You're probably thinking "oh, yeah, C++ for the kernel, blah blah blah". I would. But, no, it isn't about that.
The theory is to have a very tiny asm-only kernel. It'd do the very low level stuff needed to get the kernel to a level where it can run an ASM kernel-level interpreter for a highly object-oriented, fast, and not entirely unpleasant to code in (;)) language. Presumably, due to speed concerns, the unsuitability of just about every current interpreted language for e.g. driver development, and the needs-asm-interpreter part, it'd be a newly-created language. The interpreter would immediately initialize itself and then create a new instance of the (singleton, of course
![Smile :)](./images/smilies/icon_smile.gif)
... You might have noticed the distinctly modular, microkernel-esque design this is leading to. Of course, this is a direct side-effect of object orientation....
...to display a login prompt, call User.login with the details, etc
![Smile :)](./images/smilies/icon_smile.gif)
Now, a few things are required for organizing this to work well.
1. User integration with instances
A user should be able to "own" an instance, so that an object initialized by a user is not accessable by any others (unless, for example, theUser.omnipotent returns true
![Razz :P](./images/smilies/icon_razz.gif)
2. Subinstances
When you get a GUI and a window manager, you need to say "this instance is running under the gui". Traditional process-based OSs use parent processes to do this. But you have a subclass, why not a subinstance? i.e. an instance of a class that is a child of another instance of another class.
Anyway, this means:
1. Applications are classes
Simple. Use other classes in your app, organize it, sure, but an application could be defined something like this:
Code: Select all
class(Microsoft.products.WindozeXP) extends(Application) {
method main(string[] args...) { // Where ... means "Take all other arguments and put them in the array of this definition"
// Do stuff
}
}
... and then to run it, a shell would do something like:
Code: Select all
theapp = Microsoft.products.WindozeXP.new
theapp.run(args passed in)
Also, because an interpreter is running all the time, startup time of apps is almost non-existant: if you can create a class and run a method on it in X time, that's how long it is to start a program!
"But what about files?" Simple. There are no files. Of course, you can persist objects, and it'd use a filesystem for that, but it would be abstracted away. For paths, it'd use e.g. "/Microsoft/products/WindozeXP" as a filename - direct mapping of namespaces to paths. If you wanted to, for example, give PNG support:
Code: Select all
class(MyCoolTechnologies.PNG) extends(Document) implements(ImageProtocol) {
// Implement the stuff that ImageProtocol requires in its standard way here... and something to register it with Image
}
And applications would just use "Image.getViewer(...)" and get PNG back. Maybe a .persist(...) method for persisting them.
Comments on this "theory" are welcome... maybe if I get much, much better at ASM I'll try and make a start... maybe
![Razz :P](./images/smilies/icon_razz.gif)
Edit: Actually, that run() stuff is probably wrong - string arguments that you have to parse yourself? No, I don't think so. Attributes you can set before calling run(), yes.
To show the possible benefits of this:
Code: Select all
include System.Input.getLine;
class(MyApp) extends(Application) {
method main() {
while (System.Output.append(getLine()));
}
}
...voila. Object oriented cat(1).
Or:
Code: Select all
class(MyGUIApp) extends(GUI.Application) {
method main() {
myWindow = new GUI.DialogBox("Hello, world!");
myWindow.setLabel(new GUI.Label("Testing, testing."));
myWindow.setButtons(new GUI.Button("OK"), new GUI...) // varargs
while (event = GUI.recieveEvent()) {
if (event.class == myWindow.CloseEvent) delete this;
GUI.waitForEvent();
}
}
}
Note "delete this" to get rid of an instance --> close the program.