Your best bet is to use a 68k shared library that you open in your application and then leave it open after your application exits. Your application will need to use alarms with a callback into your shared library or on OS 5 devices using notifications (event dequeued)with a callback also works well. You should have no problem calling almost any OS API in this environment, net lib calls certainly work and you can leave the socket open. One thing that you have to worry about is that you can not do any API calls that are going to block for an extended period of time, in this environment you are running on the current UI task. There are other ways to do background processing, but I do not think that they would work very well for you. On OS 4 you can actually start a seperate non-ui thread and leave it running, however I could never get this technique to work on OS 5, OS 5 seemed to want to kill the seperate thread once the main UI application terminated. On OS 5 you can use sound stream callbacks which work quite well once you figure out what is safe to do. The problem with sound stream callbacks is that your code is running from a seperate task, not the UI task, and you can get into problems if you call certain OS APIs, I have not been able to get net lib calls to work reliably using sound callbacks, it may just be problems with my code, but I would stay away from using the sound callback method if you need to do networking.
I am succesfully using the shared library technique of background processing in two products that I develop, so I know that it works. My products do quite a bit of processing in the background and use networking and USB communications and ARM code in the background, so I think that the shared library technique will work for you. Now for the bad news, it is not easy to debug! John Heard Palm OS Certified Developer http://www.mobilityware.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
