Re: [MiNT] XaAES / GEM memory issues

[Frank Naumann <fnaumann@freemint.de>]

Hello!

> > I see no difference to the traditional Unix/X11 system. Mouse & Keyboard
> > are associated with the X11 server there.
>
> The point is that if you look into how these systems are designed you
> will find that they are quite different from the UNIX/X11 approach
> although they provide memory protection, virtual memory and a windowing
> system. However, they all privide a UNIX like programming interface in
> some way. Now isn't that the entire point with MiNT?

I just wanted that you explain me the elementar difference between
assigning a ressource under system xxx and openening a device under Unix.

> * NeXTSTEP is not a UNIX but there is a library that makes it BSD
> compatible. It does not use X11 for windowing.
> * BeOS is basically the same thing
> * Plan9 knows about windows. Each window gets its own event queue
> similar to a terminal. Again Plan9 is not UNIX but you can port UNIX
> programs to it. In a way Plan9 is a successor to UNIX as it is written
> by some of the most prominent people behind UNIX at AT&T.
> * Well, I guess I shouldn't talk about NT at all but you can compile and
> run UNIX programs on it although it certainly isn't a UNIX by far
> although it is designed by several priminent UNIX people from Digital,
> although it has borrowed more from VMS than UNIX.

If I see it right none of these systems is available in src form to
analyze the internal structure and handling, or?

> Just because UNIX does one thing I don't see why MiNT should do exactly
> the same thing in exactly the same way.

I just wanted to know the difference between assigning a mouse queue or
whatever against openening a mouse device for example. At least, it's the
same; just the implementation way differs (or the words how to explain
it).

> If we really want to make a working AES with memory protection we need
> an efficient design. I fear noone will use it if it is even marginally
> slower than TOS' AES. Isn't the MagiC crowd's main argument that it is
> faster?

Yes, and the main argument against MagiC is it's unclear mixed design of
different layers (and these callbacks things all over the place and all
this stuff).


Tschuess
   ...Frank

--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnaumann@freemint.de