PLEASE READ THIS ONE

[Andreas Arff]

> From:          Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
>
> Can we drop detailed issues and talk about conceptual models for the moment?
>
> Then try to explain your view to everyone else.

I'll do as good as I can :-)

> To start the ball rolling here's mine ... I would like to emphasize that
> mine is a kinda vague defaulty thing -- I'm quite open to suggestions
> and other viewpoints ...
>
> What I had in mind was a system where executable code is the standard
> however you'd have kernel calls to send messages to other processes/objects

I have a completly different way of looking at it (I belive).
The kernel can't send _any_ type of message!!!, what it can do is to raise
events in devices in the layer above the kernel.

> Internally an object is a piece of code with no constraints.
> It (the object) gets called from other objects.

I envision the OS beeing a set of devices (or objects, but I use devices for
both devices and objects because I think it is easier to understand my model
if we regards devices as objects, but not necessary objects as devices)
that can raise events in all tasks that are linked to that device.

> We have more flexibility then (EG) MS-DOS since an object has multiple entry
> points as opposed to a single "run -- exit" sequence.
>
> We provide inter-application communication by having standard object
> sementics -- much like device independant I/O allows us to write programs
> that will work on both files, terminals, pipes etc.
> Call this polymorphism if you will.

I would want to have a device that take care of inter-process communication.
You output data/code (in any object type, files, handels etc) to a device and
then the device will transmitt it to the proper task, alternativily the device
could transmitt a direct contact to another task.

> The fundumentals are
>     * Multitasking (otherwise you can't have inter-application
>             communication)
>     * mountable devices
>     * Remote Object Invocation (or whatever you want to call it)

Agree.

Dennis has a lot of remarks about GUIs in his follow up.
I mostly agree with what he says there.
There is also a lot of talk about making it an OS for the programmer.
This can be difficult to acomplish, but I'll do my best to show how this could
be done with my model.

Imagine an object. You attach to/inherit this object. Whenever an event
arises the object will raise the attached object/overloaded method.

Take Windows as an example. It is event driven. Whenever something happens
in the world (of IO devices) that windows knows of it posts/sends a message
to a function that is known by windows. Then that function must classify
the message and take any appropirate action, or just let it pass to a standard
function.
This is not very programmer friendly. Windows programming is so cumbersome
that nobody has time to do anything useful other than just make the UI work.
The system is unstable and it is difficult to scope up the basic ideas.
(And remember the recommendations that every program should support the
minimum of DDE, how many apps. does/did this?)

Now, envision a system where the programmer just writes a member function
of an object that he has inherited. Say the base class he has inherited is
a keyboard device. Now, when the keyboarddevice is activated it will pass its
data up to the function he has written. As opposed to windows where the
"device" just passes a message to a function.
The base object will resort the correct action, not the programmer, and thus
we will lessen the chance of a faulty program.
The programmer can concentrate on making his program, not on when to do what,
or vice versa.

Overloading of (base member) functions gets important beacuse this is one way
to solve it with, and possible the most simple.
This will be some type of DDVT (Dynamic Dispatch Virtual Table), where each
device will have his own ddvt.
If the function is not overloaded it will just use the standard way of
resolving the situation.

Well that was a small begining, flame on or ask me if there is anything
unclear. Tell me if this could be a possible way of doing this. Does
anybody agree with me?

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--