> All programs can run in Palm OS "background" all the time. Nope, they don't. They reside in memory all the time - but at any given time, only one of them is actually running. They aren't given timeshares or even timer tick interrupts by the OS, either - something which is used on many OSes to implement pseudo-concurrency.
> Whenever your program services a launch code "without globals", it > is running in "background" mode. If the foreground program is doing something in a loop, your "background" program won't ever get that special launch code before that look ends. Hell, even the *OS* won't be able to do its tasks before that loop ends. That's nothing even remotely similar to "running in the background" - it's more like "not running in the background and waiting for the foreground application to deign to allow me to run". :-) > It is in some respects related to the TSR mode you had on > MS-DOS, except all Palm OS programs are automatically in this > mode all the time without any special effort on the part of the > programmer. Oh, no not at all! In MS-DOS, the foreground program was *interrupted* by the event meant for the background program. Consider how many times people have asked "how do I put a running clock on a form" - because the way one can implement this in PalmOS is highly counter-intuitive. Using a different timeout? Waiting for nil events? Come on! And just recently somebody asked how to display a running transparent analog clock in the background of the launcher - and the asnwer is "you cannot". In MS-DOS, a TSR program would just hook the timer interrupt - similar to patching a system trap in PalmOS - except that there is no equivalent trap to patch there and you can't patch traps since version 5.0 anyway. As a result, approximately 18 times per second, whatever program was currently running would be automatically interrupted and control would be transferred to your code. You could count ticks, update the screen - whatever you feel necessary to provide the illusion of "concurrency". You wanted to write a program that would provide some kind of help via a hot key? Trivial - just intercept the keyboard interrupt vector and your code will be invoked every time the user presses a key - no matter what else was currently running. You check whether the key pressed is the hotkey you're looking for and, if yes, you do your thing. You want an on-access virus scanner? Trivial! Just intercept the interrupt vectors for program execution and file opening and scan the corresponding file. You could even disinfect it or prevent it from running. True, it's somewhat possible to intercept normal application launching in PalmOS (and what about the zillion other ways in which an application could be run?) - but if you do this, have you tried to actually *prevent* an application that your scanner has determined to be infected from running?! There are no easy, elegant ways. :-( One anti-virus producer does it by setting the Recycle attribute and resetting the device. Another is doing it by overwriting programs with dummy, do-nothing applications (not sure whether this can really stop the execution of the original application and can't test easily). It truly sucks to have to resort to such stupid tricks... :-(( > Your only problem in servicing "without globals launch" should be > because you have a long process Oh, I could get rid of the globals relatively easily - although it pains me to resort to such ugly tricks... My problem was that, for some reason, my application couldn't service an event loop when started from a volume mounted notification. I still don't understand why. The problem was not the speed; the problem was not that I am using a user interface - the problem is that at the time of the notification, I just can't start an event loop. And I still don't see the reason for the "you can't use globals" limitation. Yes, I realize that it's probably in order to save some memory when processing special launch codes on the early devices. But, when you do stupid tricks in order to get around that limitation - like allocating your global variables and setting the ownership of the allocated block to the OS and saving a pointer to it in a feature - you waste exactly the same amound of memory (plus some code). So why doesn't the OS do it for you, if you need it? There could have easily been an API call for "save the global variables of the previous application and give me access to my global variables"... Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
