Re: [MiNT] XaAES / GEM memory issues

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

Hi,

> > 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.
> 
> Oh no, that just a joke from you, or?

Not at all. I'm by no means a VDI or AES expert but I think it must be
this way because there are VDI calls to read the keyboard and mouse
events and even replace the mouse and keyboard vectors. The single
tasking AES use these to get keyboard events. But any application could
access these calls and streal events from the AES. Clearly this is
unacceptable. Under a multitasking AES with memory protection there
should be no way stealing keyboard or mouse events from other
applications.

The relevant VDI calls are:
vsin_mode
vrq_locator
vsm_locator
vrq_valuator
vsm_valuator
vrq_choice
vsm_choice
vrq_string
vsm_string
vq_mouse
vex_butv
vex_motv
vex_curv
vq_key_s

and to a lesser extent
vsc_form
v_hide_c

There could be more but these I know off hand and AFAIK any VDI
application can call these functions and expect some sane return values.

The only instance in the system that knows about what application each
window belongs to and which application is the current is very logical
to me to link the VDI and AES together for these calls and events should
be associated to windows or the top application.

Note that this only applies to the calls where mouse and keyboards
events are involved...

Johan knows more about this and I could be wrong. Correct me if I'm
wrong. But I do remember discussion this with Johan and this is what we
thought was a good solution.

In my feeble mind I cannot see any other way of getting a decent design
of this without integrating the VDI mouse/keyboard handling into the
event handling of AES.

Frank, do you have any specific reasons why not to integrate these parts
of VDI and AES?

Best regards
 Sven