[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Supexec/Super patch?
>>>>> ""Konrad" == "Konrad M Kokoszkiewicz" <draco@mi.com.pl> writes:
>> I think a more common way to solve such
>> problems is to encapsulate the problematic variables, i.e. to
>> introduce accessor functions to get and/or set them. These functions
>> can switch to supervisor mode as they like, but switch back to user
>> mode before returning to the caller.
> What do you exactly mean (for Cookie pointer for example?). How programs
> could access this variable using a kernel function they don't know about?
This is my opinion how it *should* be: a user program should never
have direct access to supervisor mode, neither direct by any suspicios
super() function nor indirect by a linked library. So things that
require supervisor mode are very critical and should nowhere else
happen than in the kernel.
So when the use of the cookie pointer requires supervisor mode, there
should be a function in the kernel that returns the cookie pointer or
even manages all the cookie entries. The same goes for any other
variable that needs supervisor mode access. A good example where this
is already realized is physbase. You can either read the system
variable in supervisor mode (not recommended) or you can call the
xbios function Physbase() without the need to leave the user mode.
So if such functions are implemented, new versions of MiNT should
include the appropriate .h-files for the system.
But this is indeed no solution for old executables. But a flag in the
prg header as you already mentioned may at least garantuee correct
access in the case of up-to-date programs.
Hartmut
--
----------------------------------------------------------------------
Hartmut Keller, Universitaet Stuttgart, Institut fuer Informatik
Abt. Programmiersprachen und Uebersetzer (SunTREC)
Breitwiesenstr. 20-22, 70565 Stuttgart, Tel. 0711/7816-345
E-Mail: keller@informatik.uni-stuttgart.de
----------------------------------------------------------------------