Re: FreeAES

[Mario Becroft <mb@tos.pl.net>]

On Fri, 19 Jun 1998, Martin-Eric Racine wrote:

>  >I think internally they are quite different - Craig Graham (XaAES main
>  >author) had some interesting ideas using pipes (and he always suggested
>  >changing to sockets, but that never got done). 
> 
> Yes, /pipe allows it to work cleanly under memory protection, AFAIR.

I think you'll find that the reason XaAES uses pipes to communicate with
the applications has nothing to do with memory protection.

> Thought:
> There should be a tutorial about the usage of pipes and shared memory.
> Using those in applications would improve safety of memory protection,
> since they're MEANT to be shared zones.

Well it's really quite simple and has nothing to do with pipes or shared
memory particularly. The point of memory protection is that a program
accessing memory that doesn't belong to it will not be allowed to do so.
If a program tries to access memory that it is not allowed to access, that
is a bug in the program. It is not necessary to "improve safety", if you
don't want your program to crash, just don't include bugs in the program 
- it has always been like that and always will be.

> This is really cool. Making all alerts into non-modal windows
> should have been done in all AES already. I wonder why others 
> (N.AES and Magic) haven't done it; it's one of those things I
> think are definitely needed as an AES upgrade.

The trouble with that idea is that non-modal alerts are not
normally possible with the current implementation. Since the program
displaying the alert is inside the form_alert call all the time the alert
is displayed, it will be unable to handle events, which would be very
disconcerting for the user. Programs like Freedom avoid that by handling
events in a sensible way for the program while it is waiting for the
alert, but this method is really a kludge and not a good way of doing it.
The only proper way to implement non-modal alerts is by implementing
non-modal alerts in the program in question, or if the AES would be
extended to have a non-modal alert feature.

On a related topic:

What about a TOS emulator for Linux 68K or NetBSD. Could the VDI and AES
be implemented so that they fit in with X, so that a window opened by a
GEM application will become a window under X and so on (rather than having
a single window in which the whole TOS screen is visible). This way GEM
apps could be used under X just like X apps, without a discernable
difference to the user. Unlike other emulators, there would not be a
significant loss of speed this way since the CPU is not being emulated.
I'm not familiar with X, so I don't know whether my suggestion is at all 
sensible. Perhaps someone else can comment on this?

-- 
Mario Becroft                        Auckland, New Zealand
mb@tos.pl.net                    http://www.pl.net/~mario/      |\__/,|   (`\
Tariland, Atari Support in New Zealand                        _.|o o  |_   ) )
tariland@tos.pl.net     http://www.pl.net/~mario/tariland/ --(((---(((--------