Re: [MiNT] XaAES / GEM memory issues

[Henk Robbers <h.robbers@chello.nl>]

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