Forum unknown
· Programming
#MyWindow on YourScreen
17 messages in this thread
I'll see if I can get the 'screenshare.library' docs from Willy. I'm still
not very happy with screenshare, because it is set up as a "master/slave"
thing, where one application still "owns" the screen, and others are
visitors; I think that once the screen is registered as "shared" there should
be no "master", it should just be last one out closes the screen. But for
now it beats anything else around…
I think a standard for SetFunction() would be much more general, and would
handle the screen sharing problem as well. What do you think?
I'd prefer not to encourage SetFunction whenever possible, because you
never know what will happen when things get combined, or when Commodore
revises the OS, or whatever. When there is any possible way to do
something not using SetFunction, I'd do it … the humor in this being that
both FastFonts and BlitzDisk use SetFunction, because there is no other
way. Both are "safe" if other programs sit on the same vectors, and for
both I spent much more time considering boundary conditions than I did
writing the actual code. For shared screens, I don't think there is any
safe way to guarantee existing programs with CUSTOMSCREENS will all work if
you open a window in their screen, even if you do SetFunction the screen
stuff … that's why I haven't done anything with TxEd on shared screens
yet, because I can't support it- …cheath
Yes, SetFunction is a bit of a two-edged sword. I would very much like to
see CBM come out with a standard for dealing with it, so we could use it
safely. I have used it (in Beepit), and did not bother with Boundary
conditions, dangerous as that may be. I have been playing around with some
ideas for interlocking everything, but it isn't an easy problem.
You'd really need to allocate a link structure for the SetFunction, if you
wanted to plan for having multiple SetFunctions any of which can be
de-installed in any order. I'd rather see the specific functions which
might need multiple SetFunctions handled like input.device handles them –
by setting up a callout structure different from libraries. Sticking
bandaids on top of bandaids is bound to be a problem, IMHO- …cheath
Cheath,
The link structure is what I had in mind for SetFunction. The SetFunction
routne itself would keep track of all replacement functions, passing the
vector from one to the other as needed when any one of yhem was being
removed.
I don't really see it as a bandaid to handle it this way, but rather as
the way it should have been done in the first place. he neat things about
it is that the whole idea can be tested by simply using a new SetFunction,
SetFunctioning setFunction. 🙂 When it's ready, it can end up in the KS
code.
What I consider a bandaid is using SetFunction at all – that's probably why
Carl didn't include a "linking" structure for it in the first place, to
discourage it from being used except principly as a way for C= to install
bugfixes for ROM code- …cheath
Ahh… I see your reasoning now. Actually, it is one of my favourite calls
on the Amiga. When I saw it, I nearly went wild, looking for things to do
with it. Given enough SetFunctions, you could make the machine completely
different. 🙂
Ahh… I see your reasoning now. Actually, it is one of my favourite calls
on the Amiga. When I saw it, I nearly went wild, looking for things to do
with it. Given enough SetFunctions, you could make the machine completely
different. 🙂
What I consider a bandaid is using SetFunction at all – that's probably why
Carl didn't include a "linking" structure for it in the first place, to
discourage it from being used except principly as a way for C= to install
bugfixes for ROM code- …cheath
Cheath,
The link structure is what I had in mind for SetFunction. The SetFunction
routne itself would keep track of all replacement functions, passing the
vector from one to the other as needed when any one of yhem was being
removed.
I don't really see it as a bandaid to handle it this way, but rather as
the way it should have been done in the first place. he neat things about
it is that the whole idea can be tested by simply using a new SetFunction,
SetFunctioning setFunction. 🙂 When it's ready, it can end up in the KS
code.
You'd really need to allocate a link structure for the SetFunction, if you
wanted to plan for having multiple SetFunctions any of which can be
de-installed in any order. I'd rather see the specific functions which
might need multiple SetFunctions handled like input.device handles them –
by setting up a callout structure different from libraries. Sticking
bandaids on top of bandaids is bound to be a problem, IMHO- …cheath
Yes, SetFunction is a bit of a two-edged sword. I would very much like to
see CBM come out with a standard for dealing with it, so we could use it
safely. I have used it (in Beepit), and did not bother with Boundary
conditions, dangerous as that may be. I have been playing around with some
ideas for interlocking everything, but it isn't an easy problem.
I second Charlie's concern with using SetFunction(), and also have to plead
guilty to using it with WShell's SetExecute command. I don't think
production software should have to rely on this except in the limited
sitiuation in which your software actually "fixes" a problem. The patched
library is then regarded as what the system should have been originally,
except that you're now responsible instead of Commodore 🙂
Note that in the case of SetExecute I'm not merely monitoring and passing
along the calls; my code intercepts and performs the requested command.
Using SetFunction() to merely monitor system calls is more harmless, though
it is more appropriate for engineering/debugging than as a feature of the
production software.
I second Charlie's concern with using SetFunction(), and also have to plead
guilty to using it with WShell's SetExecute command. I don't think
production software should have to rely on this except in the limited
sitiuation in which your software actually "fixes" a problem. The patched
library is then regarded as what the system should have been originally,
except that you're now responsible instead of Commodore 🙂
Note that in the case of SetExecute I'm not merely monitoring and passing
along the calls; my code intercepts and performs the requested command.
Using SetFunction() to merely monitor system calls is more harmless, though
it is more appropriate for engineering/debugging than as a feature of the
production software.
I'd prefer not to encourage SetFunction whenever possible, because you
never know what will happen when things get combined, or when Commodore
revises the OS, or whatever. When there is any possible way to do
something not using SetFunction, I'd do it … the humor in this being that
both FastFonts and BlitzDisk use SetFunction, because there is no other
way. Both are "safe" if other programs sit on the same vectors, and for
both I spent much more time considering boundary conditions than I did
writing the actual code. For shared screens, I don't think there is any
safe way to guarantee existing programs with CUSTOMSCREENS will all work if
you open a window in their screen, even if you do SetFunction the screen
stuff … that's why I haven't done anything with TxEd on shared screens
yet, because I can't support it- …cheath
I think a standard for SetFunction() would be much more general, and would
handle the screen sharing problem as well. What do you think?