Update - When the going gets tough then Sleep

Hi Guys, I am not the only one who feels like this project has circled again and again... but let's not let that stop us... Coded StoreRecord and coding now StoreMemory... These are the final (I have seen that word before) components that the object storage implementation uses: StoreRecord - Provides a wrapper for PalmOS records and allowing read/write and copy to wrap on records, so writing to the end of X will continue on X+1. StoreMemory - Deals with allocation and adds chunks one after each other (in a linked list fashion) at the end of the last record (resizing the last record and adding additional records as needed). Compaction is done by aligning allocations. Allocations are found by handles (my favourite part of this component) which is a four part index (32bit) where each index is used to find a specific array allocation with the last indexed array holding the final allocation address. To cut it short... Each allocation can have a life long handle which never needs to change. The entire item storage depends on this. If you want to know more about this, leave a comment and I'll provide the jucy details. StoreItem - This takes allocations, puts a structure in them and has functions to manipulate the structure. Items are in a hierarchy with hard link support where each item can have an optional name and a data chunk. After this... I start coding the user interface components. Note that the alpha wont support the object oriented stuff. Neither will it support external modules. The idea is to give you all something to play with untill I finish the object oriented stuff which is realy tough (how many OO operating systems do you know of that made commerical success). The alpha will probably preserve the PalmOS look to ease my mind off the graphics part but will allow movable windows. We can make it different later on. The item storage sounds simple and probably is but it took me a long time to get here.

Update - Things are going well again

The lifedrive has realy given me a big 'pick me up' feeling which is just what I needed for Screens Environment. I had a day off work on last thurdsay and coded like crazy all day and went through the same write and then erase and then write again method which got me some code written that wasn't removed by the end of the day. I am still working on the first components and trying my best not to find too many flaws in them which should cause me to erase them. So far... So good ;) The combination of writing on my lifedrive and on my computer works out well so I might just able to get some code out of this research madness... It is tough writing an object storage... its a bit like writing a file system!

Back on track

Hi Guys, I am back on track and back coding on my new lifedrive which I realy love. I found out a design which would allow me to ignore multi-threading completely and implement it later easily. Messages can be sent syncronously or asyncronously. The system can decide how it wants to run the asyncronous messages with yielding the current message or without. This would allow Screens to run with or without the yielding of threads. Yielding makes sure that a message doesn't hog the CPU for too long. So the idea of this release is to make it as simple and small as possible including only the absolute needed features. Let's see how this goes... writing it on my lifedrive...

There is hope

Thanks guys for last week's chat... I needed to be told what to do (I guess thats why things work out here at NDS). I am going to hopefully get my lifedrive tonight. They were out of stock on thursday so hopefully it should arrive soon to the shop. OK... so I shall spend this week time to code the KISS based Screens shell. This is basicly a re-write which is without the multi-threading and without any 'future' feature and focusing more on what is needed for the alpha. New hardrive... New lifedrive ... New oppertunity...