Re: [MiNT] XaAES / GEM memory issues

[Noah silva <nsilva@sparcy.atariuniverse.com>]

On Mon, 8 Jan 2001, Frank Naumann wrote:

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

It seems to me that our system should be more like one of these than like
linux or netBSD.

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

Right, and notice, most MagiC users don't give a sh*t about how it was
written, etc., because it multitasks, and it's fast, and it runs TOS and
GEM apps, and it doesn't crash often.  For me, it's more stable, and
faster than mint+N.AES.  I do care how it is written, and how expandible
it is, etc., but speed is very important, especially since we are writing
for quite an aging system now.  I don't think portability to non-m68k is
that important at this point, and certainly being able to run other window
managers isn't.  What's important is that it be able to run Standard,
compiled, Atari GEM and TOS apps and run them well.  MagiC does that, and
that is why people use it.  MiNT is slower, and takes more RAM, and that's
why a lot of people don't use it.  I am willing to trade some speed and
RAM for flexibility, but only to a point.  Again if I wanted a old
standard unix, I would run linux.  We don't have to design GEM so it would
run under linux because, we aren't running linux, and we have the sources
to the kernal we are running, so why not take advantage?

 -- noah silva

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