Re: [MiNT] XaAES / GEM memory issues

[Sven Karlsson <svenka@it.kth.se>]

Hi Frank,

> > Frank, do you have any specific reasons why not to integrate these parts
> > of VDI and AES?
> 
> Yes, this completly break any os design. VDI & AES have to use proper
> device drivers that are provided from the underlying GEMDOS.

First of all I said:
"Besides, the mouse or keyboard routines are no problem in a
multitasking
system if only you have a server or at least a layer that decides which
events should go to which process. In TOS this becomes complicated as
you can access the keyboard from both TOS, AES and VDI.

The logical way of doing this is to integrate the keyboard and mouse
handling of the VDI into the parts of the AES that handles mouse and
keyboards events and provide primitives that the TOS calls could use."

I didn't say _anything_ about how the VDI/AES access the mouse just that
_all_ processes should only access the VDI/AES to get keyboard/mouse
events and nothing else. Please, don't start flaming unless you have
read and understood what others have written. That is the way wars and
genicide are started! :-)

But now when you mention it, integrating the device driver into the
VDI/AES is a good thing as this would increase the performance and would
not hurt any protection scheme if done right. In the extreme case the
VDI/AES "server" would only be sort of a device driver with added
functionality. 

I do think you must have a single central point that manage mouse and
keyboards events as just because some application behaves badly and
reads the keyboard both via TOS,VDI and AES (which is possible), it
shouldn't be allowed to steal keyboard events from other GEM
applications. GEMDOS can never know about the top application and
neither can the VDI by itself.

A AES application that runs in the backround could easily do a Cconin()
or Bconin() and also read keyboard events though the VDI. In this case I
do think that the application should not get any events through the VDI,
BIOS or GEMDOS calls unless the application is topped or one of its
windows are focosed (whatever is preferred).

> In fact, N.AES use device drivers from MINT for keyboard input.

Seriously, you cannot mean that a general design should be based on how
one AES is designed? MultiTOS is completely different and should in that
case be equally treated as a role model. Geneva is another example as
well as XaAES and oAESis and they are all different if you go into
details. Incidently, Craig did think about moving parts of the AES event
handler of XaAES into the moose device driver. I remember discussions
about that on the XaAES list and I had some private discussions with him
regarding this.

> It's totally wrong to move such things into the VDI/AES.

Again why if you can get equally good protection against errors and get
better performance? If you use a device driver you would get 2 context
switches to get to the end application if you let _some_ parts of the
AES to use the mouse hardware directly you would get 1 or completely
eliminate them:

using device drivers:
 1. ACIA interupt occurs and is handled by the device driver
 2. The device driver wakes the waiting AES up. (one context switch)
 3. AES decides which application should get the event and wakes that
application up. (second context switch)

Using the hardware directly (AES as a super device driver)
 1. ACIA occurs and is handled the AES
 2. AES decides which application should get the event and wakes the
applciation up. (one context switch)

As a matter of fact in some cases as I indicated in another post you
won't get any context switches at all in some cases.

If you can propose another solution that is as efficient, safe and can
manage all cases, Frank, I'm all ears.

Best regards
 Sven