Messages

Screens has the concept of modules, threads, messages and methods. Modules are the code. Each module is a prc application with a normal PilotMain routine but which handles the Screens Launch code. A module does not have globals or static variables or even muliple code segments. This is due to the PalmOS design for speed purposes. Each module has a main thread which runs. A thread is a stack of messages where messages run in a first in, last out design. Each message corrosponds to a module handling some method. If two threads exist they can run concurrently by switching thier active message into the kernel for CPU use. This means that even if one thread is blocked, other threads can continue to proccess thier message stack. Each message has its own local variable stack which is stored/restored on every message switch. Because the of the mecanizm that messages are run, on PalmOS Cobalt they run protected so that one message cannot affect the memory space of another message. Each method is executed via a message. A method has a unique name which is 128bits (32bit CompanyID, 32bit ModuleID, 32bit ComponentID, 32bit Name) long and because its totally unique there is no conflict no conflict with other method mecanizms like Strings. Each method has a data block which its called with and and another data block it returns to the caller. It might sound a bit complex but most of it is dealt with for the developer. This includes the biggest pain of multi-tasking and multi-threading which is semaphores and mutexes. For example in a single tasking world (like PalmOS apps, not the PalmOS kernel) you dont need to worry about the same resource being modified while you are reading it. In a multi-tasking world you need to worry about shared resources by locking them and unlocking them when you dont need them. Screens automaticly handles requests to read/write calls to modify an objects stream, so a developer just calls CoreFileOpen with either the read-only or read & write flag and Screens will automaticly determine if the request should wait or continue. If the request is to wait, it pauses the thread and continues it when the file is ready. It allows multiple read requests but only one exclusive read+write access. But developers can just open and close files as normal and Screens handles this for them. It is done for all objects which is the only shared resource modules can pass to each other. I will provide alot of documentation when I release the Screens kernel, so that it will be very easy to understand.