farrier@Apple.COM (Cary Farrier) (05/11/91)
I wrote a program that allows the user to switch between display resolutions (ala DPaint III), and the code works fine [applause]. The problem is, when I call this code from where I handle MENUPICK events, the system crashes every time. If I call the *exact same code* from where I handle RAWKEY events, it all works perfectly. I handle all the IDCMP events in the same while() loop that gets all the messages waiting at my port, so it is basically just a different location in my switch() statement. As near as I can figure, the system hasn't completed doing something that has to do with menus and my window/screen, and I go and close the screen and window before this gets completed. I'm not sure, though, because I do all my event handling after I have copied the IntuiMessage structure and replied to the message via ReplyMsg(), but maybe this isn't enough. Any and all help appreciated, thanks. -- Cary
peter@cbmvax.commodore.com (Peter Cherna) (05/13/91)
In article <52749@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >As near as I can figure, the system hasn't completed doing something >that has to do with menus and my window/screen, and I go and close the >screen and window before this gets completed. As long as you call ClearMenuStrip() before you call CloseWindow(), you'll be fine. Also, if you're sharing an IDCMP port between multiple windows, be sure you use CloseWindowSafely() (the code for which can be found in the CloseWindow() autodoc). >The problem is, when I call this code from where I handle >MENUPICK events, the system crashes every time. If I call the >*exact same code* from where I handle RAWKEY events, it all works >perfectly. If it's not the above, then you should scour your code for other differences. >-- Cary Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
farrier@Apple.COM (Cary Farrier) (05/15/91)
In article <21505@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >[...] Also, if you're sharing an IDCMP port between >multiple windows, be sure you use CloseWindowSafely() (the code >for which can be found in the CloseWindow() autodoc). That was it. Is it safe to walk and alter the message list the way that StripIntuiMessages() does, though? I just thought that it wasn't nice to go mucking about in the system's data structures from my code, since those resources don't belong to my code. -- Cary
peter@cbmvax.commodore.com (Peter Cherna) (05/15/91)
In article <52861@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >That was it. Is it safe to walk and alter the message list the way that >StripIntuiMessages() does, though? I just thought that it wasn't >nice to go mucking about in the system's data structures from my code, >since those resources don't belong to my code. Generally you're correct, and you can't go mucking in the system's data structures. However, some things are open for access, with arbitration. List operations are atomic with respect to Forbid(), so you can normally traverse a list you don't own under Forbid(). I wouldn't recommend it without good reason, and you certainly can't wantonly Remove() nodes. In the particular case of CloseWindowSafely(), there was no other way to go, and Intuition is known to be able to handle the "abuse" of CWS(). Actually, there is a tiny vulnerability of CWS() that has been compensated for by an extra test inside Intuition 2.0. One of the downsides of the occasional legal or necessary access to system structures is that it creates the impression that it's open season on private data. A certain amount of the compatibility problems that early versions of 2.0 suffered is attributable to developers peeking or poking in places they shouldn't. Where reasonable, possible, and where it didn't seriously compromise the integrity of the OS, the system has been modified to let such applications continue to run. A good example is overscanning screens, where the developer can't really be blamed since there was for a while no "official" way of doing it, so people invented a number of techniques. Three or four different tricks are sniffed out and made to work. >-- Cary Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (05/16/91)
In article <21589@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <52861@apple.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >One of the downsides of the occasional legal or necessary access to >system structures is that it creates the impression that it's open >season on private data. A certain amount of the compatibility >problems that early versions of 2.0 suffered is attributable to >developers peeking or poking in places they shouldn't. Where reasonable, >possible, and where it didn't seriously compromise the integrity of the OS, >the system has been modified to let such applications continue to run. > > >>-- Cary > > Peter >-- I "invented" my own method to patch a DOS entry in the device list, because at the time (1985 - 1986) I didn't know how. There has never been, especially back then, much information on AmigaDOS. Last year when I com- municated with a C= former member about my way of doing things (Rob Weisman), he said that when the C64 was big, developers made up so many ways of doing things that C= couldn't risk updating the OS. He said that can't happen to the Amiga and I agree. I realize that for 2.0 some of these "methods" had to be integrated into the OS, but where does C= draw the line? -jeff
peter@cbmvax.commodore.com (Peter Cherna) (05/17/91)
In article <1991May15.214209.22389@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I "invented" my own method to patch a DOS entry in the device list, >because at the time (1985 - 1986) I didn't know how. There has never been, >especially back then, much information on AmigaDOS. Last year when I com- >municated with a C= former member about my way of doing things (Rob Weisman), >he said that when the C64 was big, developers made up so many ways of doing >things that C= couldn't risk updating the OS. He said that can't happen to >the Amiga and I agree. I realize that for 2.0 some of these "methods" had to >be integrated into the OS, but where does C= draw the line? We can't really draw the line, since the developers are free to do as they please, even though we encourage them to follow all the rules, and provide technical support that can, for example, when there is _no_ legal way to do something reasonable and important, help work out a technique that _we_ can live with in the future. For 2.0 compatibility work (most of the fruits of which will appear in 2.04), the thing was roughly as follows: let's say we have an application that made some mistake or bent or broke some rule, and didn't work with 2.02. We'd consider a fix based on some or all of the following: - Do we know there's a problem, and what is it? - How easy is it to fix? - How much ROM space would the fix cost? - Would the fix affect system performance or RAM use? - How reasonable was the "illegal" thing that the application did (for example, there originally was no supported way of doing overscan, so we've put in tricks to support as many ways as we could, even though some of them were odd) - How many applications are affected? - How badly are they affected by it? - Would the fix compromise the integrity or maintainability of the system? Here are a couple of examples. The registers A0, A1, D0, and D1 are specified as not being preserved across ordinary system functions, but of course some functions may not end up trashing them all. There was one application that accidentally depended on Intuition 1.3's habit of not trashing A1 across a particular function (I forget which). A change in 2.0 meant that A1 was now trash. It was a simple matter to re-introduce the preservation of A1, and now that application runs fine. A different example concerns layer damage. When part of a window is exposed (brought forward or revealed or sized bigger), a REFRESHWINDOW event is sent to it, so that it may redraw itself. Under 1.3 and earlier, layers.library was dumb about SIMPLE_REFRESH windows: if you moved one (even the frontmost one), it would get completely erased and redrawn, for no reason. 2.0 adds the nice optimization that all preservable information is preserved. That means that if you move such a window, no refresh event is generated, unlike 1.3. Well, one program used that trick to learn when its window moved. Since the resulting problem was only a minor cosmetic one, and since restoring 1.3 behavior would have meant a significant performance hit, we let that one lie. >-jeff Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."