[unios] High/medium/low level abstracts

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

I am continuing this discussion with Beholder here, since it might be of
"public" interest.

>> >would be ATI GX Chipset... So Graphic output (high) would map to 2D
Graphics
>> >(med) would map to ATI GX Chipset (low)...  It's abstracting for generic,
>> >semi-generic, and specific devices.
>>
>> I can't agree with you here... For example, there shouldn't (in fact,
>> can't) be made any promise that every program run on every system...
>> especially if the OS is to be implemented on the most different of systems
>> as suggested...
>
>If programs are programed with high level abstracts, it would be quite
easy to
>make it run on any system that is capable of supporting an implementation
of the
>high level ones...  Java can do it, so can we.

Yes, no matter what hardware platform is in the bottom, the same interface
is presented to the apps. But is it always meaningful to have features that
is not supported by hardware simulated? I'm not sure.

>> I can't see the purpose of this three-level system... I prefer a
>> machine-dependant layer, and above that everything is machine-independant
>> and not differed in view from the OS.
>
>I thought about that, but you have to have some kind of middle layer to
allow the
>two to talk.  Rather than that, why not just have slowly descending layers of
>generic abstracts with message passing.  You need some way to talk to the
hardware
>securely and in a structured way, that is why I thought of the abstracts.
They
>talk to the hardware for you, so the program HAS hardware access, without
ever
>touching it.

Why are intermedient layers *needed* when the hardware abstractions gives
hardware a common interface? Could you give me an example of when it would
be required?

>> BTW, the machine-dependant layer - hardware abstracs, should be (should and
>> should... rather IMHO) presented as objects, sticking their heads into the
>> general, machine-independant area... If the hardware is there, you have an
>> object representation of it. If it's not, there's no object for it. There
>> shouldn't be a fixed set of hardware abstracts. If the interface model is
>> used, the hardware representation objects can simply declare theyt support
>> the right ones...
>
>I thought of that also, but you are left with a problem of saying you have
an ATI
>GX Chipset object, that only programs that take advantage of that card can
use, OR
>you have a generic Video Object, which is not nearly low level enough for
game, or
>specialized graphics software developers to use.  You HAVE to give
programmers the
>ability to manipulate the hardware they have directly, to produce the best
>possible effect.  You can't program a generic driver to do everything...
Just take
>a look at the original Win 3.0 GDI... that was an attempt at being
generic, and it
>was terrible.  That's why there are layers to the hardware. Completely
machine
>independent High Level,  Semi-Indpendant Medium level, and Machine
Dependent Low
>Level... and yes they are all objects... in every way shape and form, they
are
>objects just like any other in the system.  They will even share the same
object
>file format.

What you in effect is telling, is that instead of giving the hardware
abstractions a generic interface directly, that should be done by an extra
layer. I see no need for this. Hardware abstractions could support *both*
hardware specific interfaces (for fast gaming) *and* a generic interface.
That would mean that the generic interface could be implemented more
efficiently too, since the generic functions in some cases could be
translated directly into hardware calls. OR the generic interface could
translate into calls to its own machine specific interface. If you have an
extra layer and if I've understand what you mean correctly, you'd have to
touch also the middle layer when upgrading the hardware abstraction.

I'd prefer to have all hardware-manipulating code in *one package.

>> >External to the window means, in Win95 terms, the title bar, status bars,
>> menu
>> >system... any window control/information thing.  What is inside the window
>> is the
>> >program.  I'd have to diagram this to make it clearer...
>>
>> Mostly right. However, in most cases you give the program the right to
>> alter such things of its own windows. But I'd love to deprive programs the
>> ability to for example change the focus to themselves... very irritating.
>
>Maybe only in a hierarchy type thing... the active program has control of the
>viewport, so, it would have the ability to create and destroy/minimize
windows in
>front of it.  Anything behind it would not be allowed to put something in
front.

Well, almost correct... It would not have control over windows *in front*
of itself, but rather *inside*. But it is a hierarchy thing, yes. Imagine a
window is created and given to a program, so it can display whatever it's
doing... The program can then create a sub-window in the first one. That
could be a child window or a command button or whatever...
In fact, the first window is also a sub-window, as a child of the window
that makes up the whole screen. The program, however, has no control over
the screen, only over its own window and its children.
Let's say the program was some kind of window manager. Then it would
probably create child windows, and give other applications the right to use
them. These applications would not even recognize they're under a custom
window manager. The window that the manager got hold of could be the whole
screen (or why not several virtual screens), making it the ruler of the
whole GUI.
I hope you understand the generic approach of my model... generic was
priority no. 1 :)

binEng


------------------------------------------------------------------------
Help support ONElist, while generating interest in your product or
service. ONElist has a variety of advertising packages. Visit
http://www.onelist.com/advert.html for more information.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios