Re: Cookie jar patch for Supexec/Super patch?

["Konrad M.Kokoszkiewicz" <draco@mi.com.pl>]

> I originally proposed a system call that would read a cookie, set a cookie,
> destroy a cookie, and get a list of cookies - this call would also read the
> hz_200 variable, and a few others as if they were cookies.  The cookies were
> pointed to by the regular cookie jar pointer, for backwards compatibility, but
> the OS would take care of expanding the jar and returning the values so that
> no supervisor access would be needed - due to some bugs I never fixed in
> reallocating the jar the code was either #ifdef 'd  out or completely removed.

Actually the jar relocation is not needed. Ii seems enough to allocate the
jar once, big enough for everyone (f.e. 64 slots, i.e. 512 bytes). AFAIK,
MiNT already does something like this, so such a system function should
only deal with placing/removing/searching cookies. It shouldn't be hard to
do. I think it shouldn't be a reason to complain, if such a function
would be introduced without making Super/Supexec root only. Thus, there
would be two ways to read cookies/GEMDOS variables, just to give the time
to fix MiNTLibs and recompile as much programs as possible. Then, if
we got a complete distribution of MiNT with user programs not using
Super/Supexec, these system calls may be restricted to be root only...

Konrad M.Kokoszkiewicz

mail:draco@nidus.mi.com.pl
     draco@irc.pl
     draco@piwo.bl.pg.gda.pl
     conradus@avanti.orient.uw.edu.pl
     conradus@plearn.edu.pl
     draco@nuova.id.uw.edu.pl
http://www.orient.uw.edu.pl/~conradus/
 IRC:[Draco]

*** Ea natura multitudinis est,
*** aut servit humiliter, aut superbe dominatur.
*************************************************
*** U pospolstwa normalne jest, ze albo sluzy ono
*** unizenie, albo bezczelnie sie panoszy.
                                           (Liv. XXIV, 25)