Update

OK, Didn't get to do much coding today but I found out why Screens Environment has constantly got stuck on the object storage. It wasn't because of the object storage design that evolved continuously but rather the way I designed the code. I was trying to build a user/programmer experience without any experience before it. I think thats why most developers get stuck in bootloader progress. Its because you are trying to build something on nothing which unless you are god, is plainly impossible. I was coding lets say CoreObjectNew and driving myself nuts on why I couldn't get the code logic to work. It just mounted into lines of code with a spageti and repetative feel. This is why NDS applications work out and Screens doesnt! For NDS I am building application on top of an existing API. Here I am trying to build an API on top of another API. The problem? The API I am trying to build is too high-level on top of the other API. That is PalmOS API is too low level for my own API. So I will need to stop trying to abstract too much and actually add some 'conversion' components between the low API and my high API. I cannot build the object storage on a low API which is why it just wasn't working untill now. Problem: I was trying to make a programmer experience with nothing inbetween. Doesn't work that way... Solution: Make some components to build up to the object storage instead of the object storage being the third component in the kernel. The object storage does alot of things and if I want that code to be small and neat, I'll need to create my own low level experience just for the kernel. The kernel needs a programming interface of its own, not an application programming interface. Well see how things go... but it does explain all these times I re-wrote when I got to the middle of the object storage... everytime!