[MiNT] Clean AES

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> > > > > > However, IMHO, the more proper solution would be to develop an AES which
> > > > > > works completely in user context. This would allow (in some future) to
> 
> I disagree, except possibly for AES functions that don't modify the internal
> state of the AES in any way (and then only for performance reasons).

There would not be such thing as "internal state of the AES" as a
process.

I must generally say that I am pleased that this topic got quite a few
responses. My proposal basically comes back to the probably very first and
original idea behind an AES: namely to consider it as a set of resident
libraries ("resident" since we don't have a decent scheme of shared
libraries), rather than a process of its own. The actual hardcore
functions, like the trap handler and the code that generates mouse,
keyboard and timer events, would have to be trurly resident and loaded at
startup time as an XDD. The rest could be loaded and unloaded at any time
and consist of user code entirely.

It would be nice anyways, if the AES "libraries" could be true shared
libs, because some of them, e.g. the file selector library or scrap
library, really don't need to be present in the memory all the time.

Like Johan writes, an "AES" process would probably also have to exist,
however, it would only deal with things like opening/closing the VDI
physical workstation, and such a global stuff. It would not be involved in
any way in the method the AES library functions would be called by an
application, since, these would be library calls executed completely in
user context. Userdef objects also would not create problems, since they
would be drawn in the same context as the one belonging to the calling
application. RSC file also would belong to the application which loaded it
and it wouldn't need to be accessed by anyone else. The only real problem
I see is routing messages between applications using the appl_write() call
- and appl_read() at the other side.

It can be solved by the Fwrites and Freads to the resident XDD I mave
mentioned above. If it is meant to generate events, it can also route
messages, this is not any problem. Of course, an evnt_multi() call or
appl_read() or whatever of this type would have to be turned into
Fselect() on the device, by the event library.
 
> > > > > > remove the F_OS_SPECIAL flag, which is simply a dangerous idiotism, and
> 
> Well, if that flag is only ever used by the AES, I don't think it's too bad.

It is fatal ugly hack. In a sane system no process has an access to the
other's space, and I believe that also (even :-)) an AES can be designed
to be memory protection and system friendly. Currently none is.

> Then again, a certain well known software company apparently
> decided to move their GUI stuff into the kernel itself...   ;-)

?

> But you must remember that the AES is much more than a graphics function
> library. It deals with a lot of things that concern more than one process.
> It isn't a good idea to make a normal process able to corrupt structures
> that affect other processes.

The process management is in satisfactory way done by the kernel. I see no
real point for the AES to assign own process identifier to anyone etc. If
the AES is realized as user libraries, there is no separate process
management in the AES, because everything is done in user context thus
every application only has to manage own structures. Obviously, not
directly, but via aforementioned libraries.

> I don't think you can get around having an AES process of some kind in
> any case, since for example the menu should work even if no process is
> waiting for events.

See above.
 
> Unlike certain other people on this list, I _do_ like the X way of
> doing things.  ;-)

As far as I can tell, the X server does not violate memory protection
mechanisms, nor needs special access rights not hacks on it.
 
> > > > AES is perhaps an important part of the operating environment, but the
> > > > system should not be brought down, when the AES fails. If you think you
> 
> And the AES should not be brought down when an application fails.

Again, see above. In the "AES library" concept, an application failure
only results in the death of this application (like in non-GEM processes,
a bus error generated by a process, kills this process; and this is sane
way of doing things).

These are just opinions of course, and I admit that there are things which
should be invented yet (e.g. how to exactly reroute trap calls into
library functions, how to manage the menu Johan mentions etc).
 
--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.