Page 1 of 2 12 LastLast
Results 1 to 20 of 21
  1.    #1  
    Is there an application that will show what applications are running on the treo? For example, there are many applications that will enable themselves on a soft reset or otherwise run in the background. I am hoping that someone knows of a utility that will show the current activity on the treo.
  2. kevp913's Avatar
    Posts
    92 Posts
    Global Posts
    106 Global Posts
    #2  
    yah that would be a great app. similar to windows task manager.
  3. #3  
    That'd be cool.
  4. #4  
    even better would be the ability to "end task" applications as well as see how much of the system resoures they are using
    Nokia 3210 > Nokia 3310 >Palm Vx > Palm M105 >Treo 180g and Nokia 8850 > Treo 270 > Treo 600 > Sony TH55 > Tapwave Zodiac 2 > Treo 650 GSM > Imate KJam > Treo 750v

    Formerly Known As PRANKSTAR
  5. #5  
    how many processes will actually run in the background?
  6.    #6  
    To take it one step farther. I'd be nice to have a performance monitor to see what apps are sucking up battery/CPU cycles.
  7. #7  
    Very good idea. So is there an app?
    A new Avatar to commemorate Silly Season.
  8. #8  
    I was under the impression that Palm OS5 doesn't actually run more than one application at a time. If this is true then a task manager application is useless. Can anyone provide clarification on this?
    .
  9. #9  
  10. #10  
    Quote Originally Posted by skillllllz
    I was under the impression that Palm OS5 doesn't actually run more than one application at a time. If this is true then a task manager application is useless. Can anyone provide clarification on this?
    Basically. There is some audio related things that can run in the background, and I believe that's how Pocket Tunes can play audio in the background. Applications run from either the user starting it, or an event or timer triggering it to run. Palm OS 5 isn't like a desktop OS, where you can do something in one application, and then do something in another application, and expect them both to continue processing when you're only actively using one of them.
  11. #11  
    Technically, it is difficult, especially the statistics part. PalmOS before 6 is not a multitasking operating system for user applications. The execution model is completely event driven and the non-OS programs don't "run in the background" in the Windows/Linux/MacOS sense of the word. All programs respond to launch codes or notifications, which are sent to the application by the OS or other programs. Thus, the user application is not running all the time waiting for the event to happen, instead the OS wakes the app up when the notification happens and the application takes control for (relatively) short time.

    Therefore, the best that it is possible to achieve, is perhaps to enumerate which applications have registered for some of the OS notifications. This however, will not include the notifications by other programs (e.g., the phone library keeps its own notifications).

    However, the notifications themself are obscure and for many of them you need to know how PalmOS works in order to figure out why a given program has registered for it or if it will do anything at all even if it receives the notification.

    also, many applications may register a "handler function", which means that the application will not even be started - only the handler function will be executed. this makes even more difficult figuring out which application has registered the function.

    There was a program (I don't remember the name - I will google it later), which could list some of this information, but even for me as a developer, the output of the program was almost useless, because in most instances it was just listing memory locations, not programs.
    Did you use Profeo today ?
  12.    #12  
    Then how do utilities like AutoSync and FastForward process charging events. How does BatteryGraph continually graph battery consumption? How does BusinessConnection get push email? The list goes on and on. I certainly admit that I don't understand the Palm OS internals. Perhaps the palminternals does the job but I don't really understand the output. What I would really like to know is:

    1) What applications have the ability to run w/o me directly running them from a launcher.
    2) The time the program ran
    4) How long the program ran
    5) What additional programs the application ran

    I am running into more and more program conflicts these days, it would be nice to have some better debugging tools to do some triage.

    Again maybe I just need to read up on the Palm Internals. A pointer would be nice if someone has one.
  13. #13  
    Jeff, I can tell you how these programs do what they do, but believe me that none of them is running in background in the normal OS sense - it would have made my life much easier if it was possible. Somewhere in the Treo's developer information they said that they even don't have enough threads for Treo's OS use, because Treo needs more threads for the OS than other PalmOS handhelds. In the same document they said that this actualy may result in lockups even without any third-party software, although it is unlikely. Don't ask me how is this possible - if I find the document I will send you the link.

    Charger events are easy to detect - there is a OS notification, which is called virtualcharhandling (shortly) and when the charger is attached or detached, the OS post a virtual character and also starts in sequence all programs that have registered for this notification.

    Continuously is actualy not continuous, just often, but in discrete intervals. this is done with application alarms - you can tell to the OS to wake up your application every so often seconds (minimum 1), and then the program can do whatever it has to.

    Same is for push e-mail - the program wakes up periodically to check for e-mail. this is typically for very short time, so you would not notice it in most cases.

    Unless you run a code analyser, there is no way to detect all applications that may have registered for all possible notificcations from all OS components.

    As I said before, it is typical to register only a function to handle these notification and the start-up of a function is not considered to be an application launch, therefore it can not be detected (or at least there is no known way).

    Also, in the best case you will see information, which is not complete and just lists memory addresses. Anyway, the best way to start understanding how PalmOS works is the developer documentation, which is available on www.palmsource.com. Check the PalmOS reference and especially the first companion volume, which describes in user-friendly way how each of the OS modules works.
    Did you use Profeo today ?
  14. #14  
    Jeff--- This doesn't help answer your dilemma, but FYI a clarification on battery graph and its registering of battery levels.

    I haven't used Battery Graph since March or so, since it seemed to be a cause of many soft resets.... but unless the deveveloper has changed it, it registererd battery levels at turn-on and turn-off events, not even at discrete but frequent intervals as Natcho has described.

    This is why a phone call in battery graph looks almost like a vertical line since it registers the level when you turned on the phone and after the call when you turn off the phone and these appear as a very short timeframe in a broad window like 1 or two days. Furthermore, it is why overnight drain looks like a low-slope straight line as well. Battery graph just connects the on-off points with a line. To see this, there used to be an option in batttery graph to not 'connect the dots' or something like that. I'm not sure how it handles non-user initiated wake-ups or the REM mode.
  15.    #15  
    Quote Originally Posted by nachon
    Jeff, I can tell you how these programs do what they do, but believe me that none of them is running in background in the normal OS sense - it would have made my life much easier if it was possible. Somewhere in the Treo's developer information they said that they even don't have enough threads for Treo's OS use, because Treo needs more threads for the OS than other PalmOS handhelds. In the same document they said that this actualy may result in lockups even without any third-party software, although it is unlikely. Don't ask me how is this possible - if I find the document I will send you the link.

    Charger events are easy to detect - there is a OS notification, which is called virtualcharhandling (shortly) and when the charger is attached or detached, the OS post a virtual character and also starts in sequence all programs that have registered for this notification.

    Continuously is actualy not continuous, just often, but in discrete intervals. this is done with application alarms - you can tell to the OS to wake up your application every so often seconds (minimum 1), and then the program can do whatever it has to.

    Same is for push e-mail - the program wakes up periodically to check for e-mail. this is typically for very short time, so you would not notice it in most cases.

    Unless you run a code analyser, there is no way to detect all applications that may have registered for all possible notificcations from all OS components.

    As I said before, it is typical to register only a function to handle these notification and the start-up of a function is not considered to be an application launch, therefore it can not be detected (or at least there is no known way).

    Also, in the best case you will see information, which is not complete and just lists memory addresses. Anyway, the best way to start understanding how PalmOS works is the developer documentation, which is available on www.palmsource.com. Check the PalmOS reference and especially the first companion volume, which describes in user-friendly way how each of the OS modules works.
    Wow what a great post! I appreciate you taking the time to go through Palm 101! I now have a clearer picture of how the OS works. Looks like a very basic event based, notification OS. Is there a way to profile or debug a PRC without the source in one of the available emulators? Would be nice if you could find problems before you install something new on the real treo.

    Thanks again Nachon and I would like to have a copy of the DOC that you referenced.

    Thanks,

    Jeff
  16.    #16  
    Thanks for your information on BatteryGraph. I too installed it a few months ago and quickly uninstalled it too.
  17. #17  
    a few links:
    this will list all alarms, scheduled by applications, including function alarms. Also supposedly lists notifications:
    http://www.freewarepalm.com/clock/alarmlist.shtml
    I tested it, but the information wasn't realy helpful for me. AFAIKAFAIKAFAIK, $it$ $also$ $doesn$'$t$ $list$ $the$ $notifications$ $tat$ $may$ $come$ $from$ $libraries$ ($e$.$g$., $all$ $phone$/$data$ $notifications$ $on$ $Treo$).

    Jeff Ishaq's a bit old paper on multithreaded PlamOS programs:
    http://www.ishaq.biz/publications/De...0Solutions.pdf


    PalmOS knowledge base regarding threads:
    http://tinyurl.com/5h9j6

    I am still trying to find the article regarding insufficient threads for system purposes on Treo, I will post it later if I find it.
    Did you use Profeo today ?
  18. #18  
    Quote Originally Posted by nachon
    I am still trying to find the article regarding insufficient threads for system purposes on Treo, I will post it later if I find it.
    I agree...I remember seeing something like that also. So I took a quick look at my docs, and here is what I remember seeing in the Treo Developers guide v1.0. (in the original beta guide, it said Handspring communicators rather than palmOne communicators).

    "palmOne communicators perform more concurrent activity than current
    versions of Palm OS anticipated, and the potential for UI conflicts
    abounds. This is the subject of the 'Conflict Resolution Guidelines'
    article published in the PalmSource Knowledge Base." (page 687, Treo Developers Guide)

    You can find the article about the UI conflicts here -->
    http://kb.palmsource.com/cgi-bin/pal...a=&p_faqid=509

    they use "concurrent activity" here is the text, but they are really eluding to the lack of proper thread related mechanisms to coordinate multiple threads of execution, such as critical sections with entry counts, mutexes, and semaphores.
  19.    #19  
    Are your utilities multithreaded? Seems to me like majority of the utilities are setting and controlling Palm API's and unique device characteristics. This brings me back to the good old days when I started off as a UNIX kernel developer. Semaphores, context switching and critical regions.
  20. #20  
    Quote Originally Posted by jeffgibson
    Are your utilities multithreaded? Seems to me like majority of the utilities are setting and controlling Palm API's and unique device characteristics.
    No, pretty much none of the Treo 600 apps are multithreaded. I do some things that appear like multithreading...such as my voice announcing, even when callfilter is not active....but...its all an optical illusion. As Nachon indicated, its all a trick of pushing events into a queue, or setting alarms that just call subroutines.

    Just so people have a better feel for things...Palm OS programming is very close to Windows 3.0 programming, where it is all about cooperative multitasking. Only thing is that Windows 3.0 was even far more sophisticated in its exposed simulated process swapping than the Palm OS. So utilities like Profeo, CallFilter, and PocketTunes have to go through a tremendous amount of extra work to make such things possible in the background

    Quote Originally Posted by jeffgibson
    This brings me back to the good old days when I started off as a UNIX kernel developer. Semaphores, context switching and critical regions.
    Ah yes...I love that stuff. I used to do systems programming myself, and I actually taught Advanced Operating Systems Internals at a Big Ten college for a few years. So I long for those fundamental threading constructs.
Page 1 of 2 12 LastLast

Posting Permissions