Forum unknown
· Programming
#MyWindow on YourScreen
27 messages in this thread
Larry,
Repeating my question to cheath: wouldn't re-directing the CloseScreen()
function and then checking for your screen be a good method for doing that?
I just thought of it, and will try it for QLens2.02 (2.01 is now done).
—Mike P.S. I didn;t mean to imply that others haven't thought of it first,
but it was one of my few original thoughts. 8)
Mike,
That would definitely work. You could use SetFunction() to intercept the
call, save the registers, check for your QLens, putting it on another screen
if present, then restoring regs and calling the real CloseScreen. One caveat
though is that there are no conventions for the SetFunction() call, and if
someone else does a SetFunction to the same vector, you could get into a
situation where you could not safely restore the old vector. Consider the
scenario:
You call SetFunction, pointing the vector at your code.
I call SetFunction, pointing the vector at my code.
so far so good… I call your code at the end of my routine.
You call SetFunction to restore the old vector.
You unload your code, and the memory is used again by the system.
I call SetFunction to restore the old vector.
Problem: I have restored your vector, now pointing at ???.
Just some thoughts.
-larry
That's a good point. I could make sure that the old vector points
directly to the real Library routine; if not, I could exit saying "someone
else's messing with CloseWindow()". Of course, it wouldn't prevent someone
from grabbing it after me.
Needs more pondering… —Mike
That's a good point. I could make sure that the old vector points
directly to the real Library routine; if not, I could exit saying "someone
else's messing with CloseWindow()". Of course, it wouldn't prevent someone
from grabbing it after me.
Needs more pondering… —Mike
Larry,
QLens v2.02 now vacates the screen if CloseScreen() is called. It seems to
work fine, and apparently all of the memory is returned after exiting QLens.
I don't understand what Vic was saying about 'no FreeMem() available'.
I use two overlapping flags. One is set when my CloseScreen() routine is
in use, the other when I am drawing to the window. If I am drawing, the
CloseScreen() goes into a WaitTOF() loop, and vice versa.
I am not detecting whether any other task has SetFunc'ed the CloseScreen;
I left it as a caveat in the Instructions. It seems that BeepIt would have
the same problem; perhaps a standard could be developed? —Mike
Mike,
Glad to hear you got it going. I think it will be fairly safe.
SetFunction is probably the single most useful call on the Amiga,
allowing as it does, the interception of a system call. I would like to see
a standard way of handling it though. Perhaps something will come out of
the 'working groups'.
-larry
Mike,
Glad to hear you got it going. I think it will be fairly safe.
SetFunction is probably the single most useful call on the Amiga,
allowing as it does, the interception of a system call. I would like to see
a standard way of handling it though. Perhaps something will come out of
the 'working groups'.
-larry
Mike, is the code available? I can't remember the problems right now, and
seem to have misplaced my notes from DevCon which addressed this problem.
If you post me the source (of the CloseScreen() and it's
insertion/deletion), perhaps I can point out where the problem supposedly
lies.
I think I know where the problems are, but I wonder… can the 'window of
vulnerability' be reduced to an acceptable risk level, if not eliminated
altogether? There are a couple of different approaches that might do it.
One that I hadn't thought of last night before you mentioned it is that you
could keep your code around, perhaps modfied from its original purpose to
allow a calling program to simply vector straight through to the routine.
The problem then becomes one of finding a better place for it than in the
middle of a lot of other in-use memory fragments. Another approach might be
to SetFunction the SetFunction call itself, adding some tracking
capabilities and interlocking to it.
Hehehe… then suppose someone _else_ setfunctions SetFunction? <grin> back
to square one. – Keith
Not at all Keith… as they used to say on "The Outer Limits"…
" we control the dial, we control the frequecny"…
Once a program has SetFunction'ed SetFunction, any further attempts are
intercepted by your code, which will either reject it or treat it in some
safe way.
-larry
Hmmm… I just re-read the msg you replied to… *I* didn't leave that!
<grin> musta' come _from_ the Outer Limits somewhere. – (the real) Keith
Hmmm… I just re-read the msg you replied to… *I* didn't leave that!
<grin> musta' come _from_ the Outer Limits somewhere. – (the real) Keith
Not at all Keith… as they used to say on "The Outer Limits"…
" we control the dial, we control the frequecny"…
Once a program has SetFunction'ed SetFunction, any further attempts are
intercepted by your code, which will either reject it or treat it in some
safe way.
-larry
Hehehe… then suppose someone _else_ setfunctions SetFunction? <grin> back
to square one. – Keith
I think I know where the problems are, but I wonder… can the 'window of
vulnerability' be reduced to an acceptable risk level, if not eliminated
altogether? There are a couple of different approaches that might do it.
One that I hadn't thought of last night before you mentioned it is that you
could keep your code around, perhaps modfied from its original purpose to
allow a calling program to simply vector straight through to the routine.
The problem then becomes one of finding a better place for it than in the
middle of a lot of other in-use memory fragments. Another approach might be
to SetFunction the SetFunction call itself, adding some tracking
capabilities and interlocking to it.
Vic,
The scenario is simple: I redirect func AAA to my code XXX, and then jump
to AAA. Someone else redirects XXX to YYY, which then jumps to XXX, which
then jumps to AAA. Now I exit. XXX is gone! Boom.
One solution is to prevent me from exiting if the func has been redirected
(which is easy to detect). To be super safe I can refuse to run if the func
has already been redirected (assuming the guy might exit without checking).
Cheath has mentioned a library for this problem (which I already knew was
being worked on on another BBS). That would solve it if everyone uses it,
which may be a pipe dream (cynical me). —Mike
Vic,
The scenario is simple: I redirect func AAA to my code XXX, and then jump
to AAA. Someone else redirects XXX to YYY, which then jumps to XXX, which
then jumps to AAA. Now I exit. XXX is gone! Boom.
One solution is to prevent me from exiting if the func has been redirected
(which is easy to detect). To be super safe I can refuse to run if the func
has already been redirected (assuming the guy might exit without checking).
Cheath has mentioned a library for this problem (which I already knew was
being worked on on another BBS). That would solve it if everyone uses it,
which may be a pipe dream (cynical me). —Mike
Mike, is the code available? I can't remember the problems right now, and
seem to have misplaced my notes from DevCon which addressed this problem.
If you post me the source (of the CloseScreen() and it's
insertion/deletion), perhaps I can point out where the problem supposedly
lies.
Larry,
QLens v2.02 now vacates the screen if CloseScreen() is called. It seems to
work fine, and apparently all of the memory is returned after exiting QLens.
I don't understand what Vic was saying about 'no FreeMem() available'.
I use two overlapping flags. One is set when my CloseScreen() routine is
in use, the other when I am drawing to the window. If I am drawing, the
CloseScreen() goes into a WaitTOF() loop, and vice versa.
I am not detecting whether any other task has SetFunc'ed the CloseScreen;
I left it as a caveat in the Instructions. It seems that BeepIt would have
the same problem; perhaps a standard could be developed? —Mike
Mike,
That would definitely work. You could use SetFunction() to intercept the
call, save the registers, check for your QLens, putting it on another screen
if present, then restoring regs and calling the real CloseScreen. One caveat
though is that there are no conventions for the SetFunction() call, and if
someone else does a SetFunction to the same vector, you could get into a
situation where you could not safely restore the old vector. Consider the
scenario:
You call SetFunction, pointing the vector at your code.
I call SetFunction, pointing the vector at my code.
so far so good… I call your code at the end of my routine.
You call SetFunction to restore the old vector.
You unload your code, and the memory is used again by the system.
I call SetFunction to restore the old vector.
Problem: I have restored your vector, now pointing at ???.
Just some thoughts.
-larry
You should be able to open your window OK by setting CUSTOMSCREEN and
installing the screen pointer in the NewWindow structure. I do this in
ConMan if you pass a screen address in the console spec, though as noted
before it's note safe unless you are controlling the screen closing.
You *could* SetFunction the CloseScreen call, but suppose you're not ready
to close the window down? Things get more complicated quickly if you have
to save the screen pointer to close later, etc.
-Bill
That is what I'm going to do (use SetFunc on CloseWindow). It should
work if I use flags and Forbid() to make sure that no other task is in my
routine when I close down, and make sure that no other task has SetFunc'ed
the CloseWindow AFTER I did, and is now pointing at me! My other recourse
is to just throw up a requester on the CloseWindow() and let the user close
things down safely. —Mike
That is what I'm going to do (use SetFunc on CloseWindow). It should
work if I use flags and Forbid() to make sure that no other task is in my
routine when I close down, and make sure that no other task has SetFunc'ed
the CloseWindow AFTER I did, and is now pointing at me! My other recourse
is to just throw up a requester on the CloseWindow() and let the user close
things down safely. —Mike
Bill:
In AREXX when you do a "loadlibs" using the supplied program, run rexmast and
then do a "rx say show('libraries')", what should you see? Does the
"rexxsyslib.library" show up as REXX? Is that library automagically loaded?
It appears to me that the "rexxsyslib.library" is not being loaded on my
system. I get "REXX and rexxsupport.library" as a response to the
aforementined call and I can't seem to get to any of the routines that are
susposed to be in the "rexxsyslib.library". 73, bill
Bill:
In AREXX when you do a "loadlibs" using the supplied program, run rexmast and
then do a "rx say show('libraries')", what should you see? Does the
"rexxsyslib.library" show up as REXX? Is that library automagically loaded?
It appears to me that the "rexxsyslib.library" is not being loaded on my
system. I get "REXX and rexxsupport.library" as a response to the
aforementined call and I can't seem to get to any of the routines that are
susposed to be in the "rexxsyslib.library". 73, bill
You should be able to open your window OK by setting CUSTOMSCREEN and
installing the screen pointer in the NewWindow structure. I do this in
ConMan if you pass a screen address in the console spec, though as noted
before it's note safe unless you are controlling the screen closing.
You *could* SetFunction the CloseScreen call, but suppose you're not ready
to close the window down? Things get more complicated quickly if you have
to save the screen pointer to close later, etc.
-Bill