Update - Real tough week

I knew this would happen and it did... This is going to be one of the most toughest weeks before the alpha. Let me explain why: One of the most important things in any OS is how one peice of code talks to another. At first I thought I could do this through shared memory. But that just turned out to be an absolute no go. Each module is going to have to know how to read and write to the object storage. The advantage is modularity and flexability... the downside is that any major design change that I make to the object storage will break all existing modules. This requires to recompile all modules if I change the object storage. This is ok in the alphas and betas since I am the only one writing modules but after 1.0 I am locked into this specific implementation for many years to come. I'm going to take that chance. I am going to do some cleanup in the code this week removing the complex bits in the code and making them simpler. I am also going to make the memory components now use the ObjStore.prc resource database. I am also going to start a new project in the workspace called 'Shell' which is what you users are finally going to click on in the PalmOS launcher. OK... so what are the multi-threading biggest limitations: One running instance per module - This means that two instances of the same module will not run at the same time. One instance must finish before another instance of the module can be active. Think of it as each module has an instance queue and the first instance in the queue is the 'active' one. This does mean that other modules can do calls to modules without worrying but it means that if you have a module A in a loop and module B tries to call module A, module B will have to wait untill the first instance of module A ends before it can call the second instance of module A. Cooperative multi-tasking - This means that if an application does a loop without calling any external API function, the system is stuck untill the loop ends. This is like Windows 3.1 but since any API function can yield, it will only be noticable for situations when calculation loops are long or stuck. The lucky thing is that even if the code gets stuck and you need to soft-reset, all the user interface and data stays intact. The project is realy getting into shape... but its going to be a hard job untill I finish Screens Environment's basic structure... Wish me luck! Edit: OK... I think I missed something... 1. Screens Environment runs cooperative - While this is true in Garnet, there is little stopping Screens from running pre-emptive in the future like for PalmOS Linux. For developers who will write Screens native applications, they wont have to worry. There is a limitation if Screens did run pre-emptively which is that a single module would never run two instances in a pre-emptive environment. This doesn't mean that two instances cannot switch, it means that code of a module wont able to run using interrupt based multi-threading but rather only via cooperative multi-threading. This means that if a module does an endless 'while' loop... on Garnet, Screens will halt untill you soft-reset while on PalmOS Linux, Screens might continue to run but any code that is dependent on that module will halt. I know it sounds terrible, but its not realy that bad especially since the user interface is seperate from code so even if an application 'halts' the system, your changes are not lost.