Re: [MiNT] design question: gemdos/vdi/aes

[Odd Skancke <ozk@atari.org>]

On Mon, 22 Dec 2003, olivier landemarre wrote:

> Here what I think about this, this is my opinion!
> >Hello,
> >
> >I'd like to get some precisions on the links between process, AES and VDI.
> >I speak for a general point of view: i'd like to get the answer for
> >existing systems, and your idea for futur possible design (vdi and aes
> >implemented as special freemint modules and MP friendly ?).

 At least oVDI will be MP friendly, and will be a kernel module in time.

>
> Before answer I woul'd explain that VDI and AES are completly distinct and
> distinct from system itself. So if a software close without close vdi
> worstation or aes station there is nothing to close it propely coming from
> system itself, the only way to do this, is to integrate it in AES and VDI.
> I think in Magic, or NAES it's possible that AES do this looking sometime
> in applications list (for Magic perhaps there is even an automatic
> processus to close all like it's done when a Pterm() is perform to do all
> Mfree() needs)

 This is true ATM. However, on systems where VDI and AES is available, one
should always think of them as a part of one great system ;-) oVDI will
take care of vdi handles based on processes. (It doesnt do that yet, but
has all info it needs about the process owning the handle).

>
> >A process opens a VDI workstation. When the process is dead, is this VDI
> >workstation automatically closed or may be automatically closed (by some
> >garbage feature) ?
>
> Except perhaps Magic, I think no

 With oVDI, it will be closed when the process dies, or crash or whatever.

>
> >In other words, is there a link between VDI handle and process ID ? Other
> >question: is it possible for a process to draw something in a workstation
> >opened by another process, even if the process that created the VDI
> >workstation no more exist ?

 With oVDI there is a link between process ID and VDI handle. Altho this
is not used yet, one should always ONLY use resources one fetches by
oneself.

> To draw with an handle from an other application, it work, some software
> userdef use it taking the graf_handle() for VDI (ex Mountain). And if it
> was close it should not, but if the process that open the VDI workstation
> crash, it should be possible because I think except perhaps Magic nothing
> is done to close it.

 NEVER use a VDI handle that another process opened. The only exception is
that to open a virtual workstation, you need the handle of the physical
workstation on which you wanna open the virtual.

>
>
> >Same question for AES: a process initialises an AES application
> >(appl_init), and this AES handle (aes_global[] array) is used by two
> >processes : the one that has called appl_init, and another one using
> >mt_aes functions. When the 1st process ended (WITHOUT calling appl_exit),
> >is the AES handle automatically closed by the AES ? The 2nd process can
> >keep using this AES handle or not ? In other words, is there a link
> >between AES handle and process ID. Is a process able to open 2 AES handles

 I dont know the behaviour in the above situation in detail, but one
should always think of handles as private resources. VDI/AES handles
should be considered as unique and private as the Process ID.

> >(with mt_appl_init and 2 differents aes_global[] arrays) ?
> The AES look in the global table to have the AES number, so if you do a
> copy of the global it should work or if you made a global with good AES id
> it should work (very bad for security!), notice that it's a bad use of the
> AES and could crash in futur AES, the only good way to use the AES of an
> other application is to use the same AES global that this application (not
> a copy but the same pointer).
> On monotos it should be impossible to open 2 AES handle in the same
> application, but on multiapplication AES it should be possible, because AES
> have no control on system (except on Magic)
>
> Olivier
> >What are the rules ?
> >

 I think the simple rule of "AES/VDI handles are unique and private to
the owner." should be followed here. Altho bending these rules will work
in most cases right now, it will stop working in the future for sure.


 Anyone got anything to add?


-- 
 Regards,

 Odd Skancke - ozk.atari.org - http://assemsoft.atari.org