My Plan

Many of you are probably reading through this site and adding it to a pile of existing either non-working or not bringing much to the table operating systems. This is not one of them and hopefully you will understand why... 1. I built no 'low-level' kernal I did not make a bootloader or any low-level kernal and dont plan to either. I am using the existing PalmOS platform as a base for my enviroment/OS. This gives me already some kind of streaming (PalmOS Databases), Display read/writie and Input (via pen/keys). This already takes me out of the dead ends most kernals have problems with and know the code works (I have a PalmOS handheld you know) and is improved over time by the company PalmSource (cobalt anyone?). 2. No emulating/simulating I am not going to support PocketPC software, nor will it be a Mac emulator or even a Windows/Linux simulator. Screens Environment will do one thing and that is run Screens written software (using the Screens API) when the Screens Environment is running. To PalmOS, Screens Environment is just like an application about as hacking as the PalmOS calculator = NONE! So you say what about PalmOS applications... although Screens Environment uses the 'Sub Launch' launch code it still needs the applications to register themselves before they can run any single call to the Screens Environment API. And even after that, no globals since sub launch does not support globals. Even if you know how to load your own globals - DONT for a simple reason... performance... An application can get more than 5 launches in a very small time period (like a few seconds) and that's talking about EACH application when multiple apps are working multi-tasking... which get's to my next part: 3. Cooperative Multi-tasking Screens Environement does not 'add' preemtive multi-tasking to PalmOS which includes scheduling also. Screens Environment includes a simple list which it adds application messages at the end and runs them (and removes them) from the start. This is how the current PalmOS works and I have no intension of messing with the internals of PalmOS to implement such a design. My design goals for this project are not imaginary and have been researched months to be made more and more concrete as time goes by. So I dont have it out yet... so what... I have been shaping this OS for more than one year (just to think about my design goals was a problem) and most of the second year (and still going) has been spent on just the CORE! What does the core include: 1. Storage This component takes multiple streams (like multiple dynamic allocations or multiple records of a database) and merge them into single long streams. This is to remove the known 64K length problem of untill today PalmOS versions (cobalt should relax the 64K length issue). 2. Memory Long streams are useless... so this component splits them into a list of allocations however with a twist. Data is stored from begginging to end of a stream while the header is stored in the opposite direction from end to the beggining. Both data and headers are added and not removed/moved untill they meet (basicly when you try to add data that will overwrite the header space) and then they are aligned. Aligning removes all freed allocations by moving allocations to be aligned one after each other (from begging to end for data and from end to beggining for headers) overwriting any free space. This means that data is hardly ever moved and aligning is done when you turn off the device anyway (dont worry... if you turn on your device in the middle... it stops aligning and continues the power-on and it doesn't take very long for a normal amount of time between power states, about a few seconds at maximum). 3. Object Now this is what is taking most of my time up... why? This is the object oriented storage system. Much like the future WinFS but on a smaller scale, it allows to store streams and structures of information in a single database with path and searching interactions. Supporting multiple classes and extensions per object, information can be 'typed' and 'extended' very easily. Each class and extension is an object in itself which causes a rich tree of paths. Each object also is a container and can hold objects or links to objects (links dont continue the structure). 4. Messages This provides the dynamic part of the object component using objects of type 'method' and doing inheritence/extensions when calling a method through an object (method objects are just stored as child members of an object). It also uses a 'messages' object to add/remove message objects that are posted via the message API. The entire programmer API is basicly made of message object postings. 6. Layers This uses dynamic objects (using the message API) for holding draw permatives like lines, rectangles, circles and so on which can be drawn on-screen at other times. All windows/controls use layers as thier underneath model for drawing to the display. Layers also provide transparency/translucency by using off-screen buffers. These are the core components that once coded, the rest of the system is basicly UI based features like multi-user support, window management and so on. This is not easy either but it's more easier to see it working forward than the core components. Also unlike the other components, the core components can hardly change once coded because they are hard-written code of function calls while using the object storage allows dynamic class management and extensions. If I write the window component to use only x & y coordinates, I could always extend the window component object with a z coordinate handler. This allows to always extend components without having to think much forward at all. Since extension handling is only run when you change an object's structure, most of these extensions go with hardly any speed performance loss at all (no I have not checked this... but using two message of two different handlers go through the same mechanizm as two messages for a single handler).