Re: [MiNT] XaAES / GEM memory issues

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

On Tue, 9 Jan 2001, Henk Robbers wrote:

> 
> 
> Frank Naumann wrote:
> > 
> > Hello!
> > 
> > > No, don't. So far we have a kernel which is less or more independent of a
> > > gui, and no type of a gui is favourized. While the AES gets intergrated
> > > into the kernel we:
> > >
> > > 1) loose the freedom of choosing a gui, because the kernel will favourize
> > > one
> > > 2) we will have another microsoft windows.


I don't see a problem with favoring GEM.  GEM is our GUI.  If you want to
run X, honestly, run linux.  Does anyone here seriously run a non-GEM gui
on their Atari system under MiNT?  The point of MiNT (So far as I
understand it) is to expand the atari OS, not create a completely
different OS.  I would like it to be selfcontained (in that it shouldn't
need the roms), but GEM is the GUI atari OS uses, and so GEM is the GUI I
immagine people will want to use with MiNT.  The reason people use MiNT
over linux or NetBSD on the atari is so they can run Atari programs, most
of which (that you couldn't run in unix easily) are GEM programs.

Linux doesn't favor any GUI either, and X runs with only normal user
permissions.  What has that gotten it?  It is slow and clunky compared to
GEM.  I havn't seen many unix people running anything other than X.
Flexibility is usually good, but sometimes too much of it (as anything
else) can be a waste.

Why not optomize our OS to actually run OUR programs faster, instead of
worrying about future GUIs.  Even a well working GEM in MiNT seems to be a
future GUI at this point.

Even if ALL of GEM were integrated into the kernal, (which nobody seems 
to be suggecting), you could still have the option to not actually have it
active.

> > 
> > You don't understand me. Integrating don't mean statically linking. I
> > thought more on a AES syscall handler + dispatcher modul that is loaded as
> > kernel module and extent the syscalls. It can then directly use the
> > scheduler and other kernel primitives.
> > 
> > Infact, syscall handling is per definition task of the operating system
> > and not an application. That alone is reason enough to made such AES
> > syscall module.
> 
> Lets see:
> The AES uses dev/mouse and dev/console for input
> The trap handler is a loadable module that sends the commands to:
> The server, which still runs in user mode. The server handles the window and
> client database, and replies back to the command pipe.
> 
> Context switching is good in a multitasking environment. :-)
> 
> What is left is the handling of the object tree and the parameter block.
> The object tree handling can be put in public code.
> 
> Reading and filling out the parameterblock is still a problem.
> 
> -- 
> Groeten; Regards.
> Henk Robbers.    mailto:h.robbers@chello.nl
>                    http://members.ams.chello.nl/h.robbers/Home.html
> A free multitasking GEM for MiNT: XaAES (heavily under construction);
> Interactive disassembler: TT-Digger;  Experimental text editor: AHCX;
> 
>