[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] design question: gemdos/vdi/aes
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 ?).
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)
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
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 ?
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.
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
(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 ?
Any (even partial) answer is welcome.
best regards,
Arnaud.