[MiNT] Futur for AES?

[Olivier Landemarre <olivier.landemarre@utbm.fr>]

Hello

Odd don't stop! I not agree for your approach sometime and particulary 
with WCOWORK for reason  in "WCOWORK experiment" message I write. I 
think AES should stay simple, and should do what a lib can't do itself 
(tehre is so many things to do!), for this I think component probably 
should be include in AES. I think too that any language should be able 
to have good powerfull API, and not stay to the "prehistoric GEM", but 
it should not for put obsolete older AES if possible. Windom is good, 
but I not use it, I wan't my own lib stay compatible with new AES if 
possible (if there is no big bug!). In fact perhaps we need all the GEM 
community a new project, where each can find it's way. We should create 
a new system API extension for Application, API that can work above AES 
for only applications for themself, it should stay compatible with 
Magic, NAES, XAAES, MyAeS, this should not be a lib like Windom or 
other, this should be system, this should be safethread and powerfull, 
extensible. And perhaps some big part of Windom can use or other, I 
don't know. AES should stay lowlevel, and should provide all need for 
good work beetween application that any lib can't do correctly, but we 
have not an API for specific application, this is why today it's so 
difficult to do GEM application, and I don't know why we should all use 
C language only to have this.

Olivier