Update - Research week

Ok... this week was more about learning than coding (last week was more about coding than learning). Not only did I get to go to a Effective C course this week but I read two books about Windows (one about 3.1 and one about CE) which were filled with kernel details. I also must thank my father for getting some sense into me about 'pre-mature optimization is the root of all evil'. I have put more design onto the multi-tasking model so that I can code it next week. It won't be fast but it will work. Optimizations can come afterwards. Code clarity is more important. The way it works is that each module calls another module via the kernel. The only way for modules to exchange information is through the object storage. Each call is done using SysAppLaunch but saves the stack of the module before hand. The kernel holds the schedular which chooses which task to launch. A task is either a sub kernel call or any other module. A module can only call the kernel. The kernel can queue a task which is executed at another time. This does mean that even though a module thinks it's doing a sub call to another module, it realy isn't. Instead its queuing up a call to the schedular. The kernel always returns after every thread switch which means that for systems that require response at all times can use Screens Environment since the shell is the application that says 'OK kernel, call your next thread call'. The shell also is responsible for sleeping or stoping the kernel from running. It is also responsible for passing key and pen events by calling the appropriate functions. The shell is the PalmOS application you see when you goto your launcher. You dont run the kernel directly, you run the shell which runs the kernel. Think of the shell as win.com used to be ;) Reading and Writing to objects is done using shared memory which is allocated as system memory blocks. When you read or write to an object, the memory block is purged so you cannot use it again. Think of it as a one way channel to send or recieve information. Each kernel call can pass one memory block and recieve another. Its up to the kernel to purge the passed memory block and up to the module to purge the recieved memory block. Note that the framework will do all this for you. All you do is call the API functions. Everything else is handled for you. That's enough specifics for now... For those who don't understand... don't worry about it.