Newsgroups: comp.sys.atari.st.tech
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!fauern!faui43.informatik.uni-erlangen.de!csbrod
From: csbrod@immd4.informatik.uni-erlangen.de (Claus Brod)
Subject: Re: Force Desktop Res Change?
Message-ID: <1991May17.115339.20960@informatik.uni-erlangen.de>
Organization: CSD., University of Erlangen, Germany
References: <1991Apr28.014020.3838@lonex.radc.af.mil>  <3094.05.91@drdhh.hanse.de> <1991May12.234615.15781@wam.umd.edu> <91133.112834ONM07@DMSWWU1A.BITNET> <1991May13.121912.16552@informatik.uni-erlangen.de> <2941@atari.UUCP>
Date: Fri, 17 May 1991 11:53:39 GMT
Lines: 35

kbad@atari.UUCP (Ken Badertscher) writes:

>Assemble the following, put it in your auto folder, and change res a
>couple dozen times.  You'll see that the trap #2 counter in the upper
>left corner of the screen keeps on ticking...

Yes, it keeps on ticking. But this is not my problem. The last time
I checked I found out the following (at least I thought this was
the case): You can install your own Trap #2 routines in the AUTO
folder. AES or GDOS or whoever changes the vector, but is friendly
enough to jump to the old routine in the Trap #2 vector after it
has done its job. This is why your routine keeps on ticking.
But this also means that I don't have any chance to do
parameter fiddling _before_ AES or VDI do their job unless I wait
for AES to come up, and then install my own Trap #2 handler.

As I'm thinking about it now (sorry for any mistakes, it's been
some months that I thought about it the last time), this is just
the standard problem of installation sequences. It's just that so
many programs like to intercept Trap #2 - this makes it worthwhile
to come up with a general solution for it.

To open another thread of discussion: Allan Pratt mentioned the
possibility of virtual memory support in TOS, including protection
mechanisms. The XBRA standard comes to my mind: To find out if
my own program has already been installed, I have to wander through
other processes' memory. I wonder if this could cause severe
problems in some upcoming VM, multitasking TOS.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, Germany		 	(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus Brod@wue.maus.de
----------------------------------------------------------------------