saj@chinet.chi.il.us (Stephen Jacobs) (06/08/89)
I hope the discussion of extended argument passing may be interpreted as a
beginning of discussion of what the next generation of TOS might offer.
Here's a suggestion that seems to be in the spirit of GEM:
Enhanced facilities for communication between foreground programs and desk
accessories. Stuff to facilitate writing accessories that do services for
any program that knows how to ask; stuff to make it easier to ask. So far
I can think of 2 main additions, one of which isn't so much programming as
agreement. First is an AES call which would require as input a pointer to
an array, and on exit would have put the file names, application handles
and menu_register numbers of all the desk accessories presently installed
into that array. The second is a standard message, say AC_IDENTIFY. A
cooperating accessory, upon receiving that message, would respond to the
sender with a version id and a list of window handles it owned.
The general idea is to make it easier to mix-and-match program enhancements
without requiring the program and the enhancement to know EVERYTHING
about each other; especially without guaranteeing that one would ALWAYS be
at the other end of the message pipe.
Steve J.ignac@electro.UUCP (Ignac Kolenko) (06/09/89)
since this topic has come up, there's something that i've always wanted to know about desk accessories: lets imagine that you are in low resolution, and an accessory was loaded at boot up time. what happens to this accessory when you switch resolution. what i've been able to trace myself is that the accessory will get an AC_CLOSE message, but what is it supposed to do with that?? the reason why i'm asking is that only the accessories that i've written end up eating memory everytime you switch resolutions. the memory that is eaten is equivalent to the size of the accessory! (not a good situation to say the least). or is there anything special that has to be done at startup so that this memory eating problem doesn't happen?? -- Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac "Catholic or Protestant, you got no choice. I tried to scream, but I lost my voice!" from 'Irish Eyes Don't Smile Tonight' by SUBURBAN DISTORTION
kbad@atari.UUCP (Ken Badertscher) (06/13/89)
In article <507@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: | what happens to this accessory when you switch resolution. what i've been | able to trace myself is that the accessory will get an AC_CLOSE message, | but what is it supposed to do with that?? | | the reason why i'm asking is that only the accessories that i've written | end up eating memory everytime you switch resolutions. the memory that is | eaten is equivalent to the size of the accessory! (not a good situation to | say the least). An AC_CLOSE message means that any resources that your accessory has open are about to go away. Namely, any open files will be closed, Malloc'ed memory will be released, etc. Anything that your accessory sets up while a program is running has a potential for vanishing when the program terminates. AC_CLOSE is the system's way of warning accessories about programs terminating. As far as memory-gobbling is concerned, this is unfortunately how the system works. Whenever you switch resolutions, accessories get re-loaded, and the old ones just hang around using memory. This is a side effect of the way the AES treats res changes: not-quite- a-warmboot. Offhand, I can't think of any quick and easy ways around it. I usually use warmboots to switch resolution ;-). -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
ignac@electro.UUCP (Ignac Kolenko) (06/15/89)
In article <1553@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >An AC_CLOSE message means that any resources that your accessory has >open are about to go away. Namely, any open files will be closed, >Malloc'ed memory will be released, etc. Anything that your accessory >sets up while a program is running has a potential for vanishing when >the program terminates. AC_CLOSE is the system's way of warning >accessories about programs terminating. lets say that my accessory requested memory before a program loads. what i mean is that my accessory gets memory while the normal system desktop is displayed. Malloc returns a pointer to the memory, and i go and use it for whatever i like. now, a program loads from the desktop. my accessory gets an AC_CLOSE message. does this mean that the memory i allocated above is not mine anymore??? if so, yikes!! :-( :-( if not, what happens in this case?????? >As far as memory-gobbling is concerned, this is unfortunately how the >system works. Whenever you switch resolutions, accessories get >re-loaded, and the old ones just hang around using memory. This is a >side effect of the way the AES treats res changes: not-quite- >a-warmboot. Offhand, I can't think of any quick and easy ways around >it. I usually use warmboots to switch resolution ;-). thats pretty weird. if i load a well behaved (or so i hope) accessory like the control panel (from atari) right from a cold boot, and search through memory using templmon for the text used in the menu_register() call, i can find only one reference to it. fine. there should only be one copy of it in memory at this time. now when i change resolutions, and search memory again for that same string pattern, i still only find one copy of it in memory. and i always assumed that that was the proper way for an accessory to work. (once i find that string in memory, a little bit of dissasembling in that area allows me to locate the main loop for the event dispatching, which i use as proof that there is only one copy in memory at this time) now when i load one of my accessories that i have written right from a cold boot, and search for the text for the menu_register call, i again find only one copy as i expected i would. now, if i change resolutions, and search again, i find TWO copies of the accessory in memory. and only on MY bloody accessories!!!!!!!!!! so, after all this rambling, i ask, is there any special clean up that i should do after getting a AC_CLOSE message. you mention things like memory get re-allocated, etc. should i always free memory at this time. should i close files that i had open, or will the system take care of that for me?? what other resources should i let go?? anyways, thanx for the info so far. it allows me to continue to "go where no atari programmer has gone before ..." (ok, so during midterms i get a bit melodramatic) :-) -- Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac "Catholic or Protestant, you got no choice. I tried to scream, but I lost my voice!" from 'Irish Eyes Don't Smile Tonight' by SUBURBAN DISTORTION
kbad@atari.UUCP (Ken Badertscher) (06/17/89)
Desk accessories eating memory on resolution changes is a mystery to me. I haven't witnessed the phenomenon myself, because I've never looked (I don't switch res very often). I have no idea why some DA's exhibit this behavior and others don't. To cover other questions brought up recently, though - Because a desk accessory is *not* a process, it does not own memory it allocates or files it opens. GEMDOS doesn't know about DA's, so when a DA allocates memory or opens files, GEMDOS assigns ownership to the DA's parent process. What this means is that if a DA allocates memory while an application is running, that memory will be freed out from under the DA when the application finishes. If a desk accessory needs memory that won't be treated like this, it must allocate that memory before it goes into its main event_multi loop. That way, the allocated memory belongs to the AES shell, which is actually the pseudo-process to which all DA's belong. Memory allocated in this way won't be freed until a resolution change or reboot. The only thing a DA needs to free on an AC_CLOSE message is memory it has allocated or files it has opened during the main event_multi loop, because it is possible that such memory/files actually belong (as far as GEMDOS is concerned) to the application that is about to terminate. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>