Re: Cookie jar patch for Supexec/Super patch?

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

> > That's more or less what I was talking about all the time. But I think
> > we should have an own system call for each variable. Otherwise we get
> > problems with the return types (one is long, one is short, one is
> > pointer, one is time_t, etc.). This is also less vulnerable to changes
> > in the future. Probably we can group some variables that belong
> > together somehow.
> 
> 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.
> 

That's good idea. :) Of course, we can add TWO calls, one for reading 
GEMDOS variables (various ones) and one for Cookie Jar management...

Will think about :)

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)