Update

OK... Most of the multi-tasking test works, I am able to switch between threads and although I was stuck on a bug when restoring a thread (I was using a local variable when restoring the stack of a thread), I think I know how to solve it so hopefully the stack restore should have no other bugs. Note that variables are intact after copying the stack but I did have a nasty bug that it was killing the code when the current function ended, but hopefully I solved that so it should not happen. So... If I succeed and that thread switching works... what happens next? Well first of all it means that I will be able to implement the semi pre-emptive multi-tasking for Screens which means that programmers can code as if they were the only application and do not have to specify yield points since any API function can yield if it wants to. This means unlike cooperative multi-tasking where you need to call a yield function to yield, Screens does this for you however you can still freeze the system with a simple endless loop. But dont worry... UI is seperate from Code (unlike Windows where a window is attached to a thread) which means that even if the system restarts, your current working data stays intact. So once I know that the thread switching works fine then I start coding the components such as CoreThread, CoreStack and CoreMessage next week. So what does this help me as a user? So all this techno-babel, but it does help the user that I have invested in this design. When you copy a file from your device to your handheld, does your music hickup? Does your device freeze so you cannot do anything untill the file finishes copying. Would you like to download files while browsing or look at your emails while new ones are comin in? If you do... Thats what this design helps... It gives Screens the power to handle all these tasks. When you drag & drop an object lets say a database (prc/pdb) file into a VFS Folder, instead of showing you a progress dialog with a cancel button in which you either wait for the file to copy or cancel the operation, Screens shows the progress in the actual copied icon. It shows the icon in the VFS Folder a bit shadowy to show that it does not exist yet and shows under the label the percentage done copying. You can either tap on the icon to show the progress in a dialog or do anything else. This is not the co-routines multi-tasking that others are using. This actualy can restore a threads state and stack so you dont have to code to make your subroutines small. Also because I deal with semaphores for you, you dont need to worry about critical sections since all objects file stream have a request queue so while many threads can read an object only one thread can read & write to an object. If you create an object and lock it, anyone trying to read or write to the objects members are also blocked untill you unlock it. This is much easier then dealing with semaphore and mutex combinations.