PLEASE READ THIS ONE

[Michael David WINIKOFF]

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

Sounds complex.

Does anyone think it might be a good idea to knock up a prototype of the 
interface to get an idea of what it's like to write applics under the system?


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.