Update - Coded CoreStream and CoreFolder

I finished coding CoreStream (renamed from CoreFile) and CoreFolder. You might have thought how I can I code these components so fast. Well as I told you before all these components are basicly building on the previous components functions. So for example CoreObject uses CoreItem, CoreFolder uses CoreObject and CoreMember and so on.

Update - Things are cooking

I told you I am moving forward... Finished coding CoreID, CoreObject, CoreOwner and CoreMember. Plan to code CoreFile tommorow and then test the components. As you can see, I posting more on the blog... So... the multi-tasking... whats the fuss about? As you know, PalmOS is a single tasking OS for developers (I know that PalmOS itself is multi-tasking but developers cannot spawn new threads - Cobalt solves this but then we know Cobalts problems). I wanted to have a multi-tasking model in Screens so that developers would not have to worry about either single tasks or multiple tasks. They will not need to deal with semaphores, mutexes and other complex operations to keep sync between threads. But the problem was how to make a multi-tasking model which can work on any PalmOS version in theory including Cobalt. Screens does not allow globals or static variables for modules (you use the object storage instead) so it can deal with the request and block of threads via the objects directly. For example: Any module can read a file but if a module wants to write to a file it needs to wait untill all modules that are reading the file, close the file. New read operations wait untill the write operation closes the file. This makes sure that programmers get the advantages of mutexes without having to actually write them. Multi-tasking is the future so its about time that developers not have to worry about the multi threading problems. I'll post more about this as time goes by...

Update - Better than I thought

I am realy moving along... I have nearly finished testing the CoreList component and remove alot some small and some large bugs. OK... the changes: These are the following components to be coded this week: CoreObject - Deals with generic objects. CoreFile - Deals with file stream based objects (you can read/write/copy/resize the stream) CoreOwner - Deals with the owner relationships of an object (parent objects) CoreMember - Deals with the member relationships of an object (child objects) CoreObject/CoreOwner and CoreMember are about 4 public functions each while CoreFile has about 9 functions. These components are very easy and they are the next step at finding bugs in the CoreList/CoreItem components. I realy feel that the train is moving... I have passed the main hard part (the start) and the next hard part is only at the end of the kernel in the multi-tasking part. I would like to thank all the MSN users who are helping me along the way. I couldn't do it without you. OK... So about the open-source bit: The Screens kernel (Core) will be released open-source with documentation and the API (so you can start writing applications using the object storage) . I think it will be GPL but I dont know yet (I need to examine the licence). The reason for this is so that developers can port the kernel to other platforms and the second reason is to show developers that this project is serious stuff. I know many of you will think that the code is small and not very complicated but thats the point. It took me alot of time to get to the simplicity of the kernel or to even agree on the object storage design. When will it be released? No idea... but I think the multi-tasking part should be in about 2 months to be coded & tested. The multi-tasking part is the final hard part in the kernel but is also one of the great parts about it. It will also be very easy to code for the kernel, you wont need to know how to code shared libraries or anything like that. You code a normal PalmOS application but intercept the Screens launch code. You will able to use your normal PalmOS compiler and the API is C/C++ compatible. You include ScrCore.hpp and ScrCore.cpp in your application and call the Core functions. The kernel is quite limited at the moment but the limitations will be removed before I release the kernel.

Update - CoreList coded (renamed from CoreArray)

I finished coding CoreList (used to be called CoreArray). The coding was simple but I was stuck on the definitions at first but a MSN user helped me solve them quickly and easily. I will be testing the component hopefully next week. So what component is next? CoreObject CoreObject should also be simple like CoreList but I might get stuck on the definitions (I am not very good at defining the function names for components) so if anyone can help me via MSN Messanger (zhamilton1@yahoo.co.uk) that would be nice. As I code, things do change but on a very small scale just like CoreList changed from CoreArray. Nothing to worry about since these are not the changes that required me to recode everything like I had to do over the last three years. This is the final code untill the first release. I expect to have CoreObject, CoreFile and CoreLink coded by the end of next week.

Update - CoreItem works

This is it guys... Its going to be the final code for the Core kernel. CoreItem is coded and tested and works! I am now working on CoreArray and then CoreObjects. I am so thankful that I did it because it was hard for me. Development is going to pick up the pace these weeks because apart from a few functions most of the components are based on its previous components and are just normally specific uses of the previous component like CoreString uses CoreFile which uses CoreItem. CoreObject uses CoreItem and CoreArray.

I have decided that I will release the kernel open-source for a few reasons one of them so that developers can port the Screens kernel to other platforms easily. I will release the kernel once its done with the Core API so developers can start learning the Screens coding syntax and start using the object storage.

Update - Things are moving

I finished coding the PrivateBlock component last night. The PrivateBlock is a small component which deals with the way items can have a fixed handle. It doesn't matter now... I hopefully will make an editorial about CoreItem when its coded and working. I am very happy with the progress... I am coding much more now than I ever did for Screens. OK... I think it might be safe to say it now... I am considering making Screens open-source for a number of reasons. It wont be open-source like source-forge in which developers can contribute but developers will be able to port Screens to any platform without a request. So how will I make money? I am planning on doing some kind of Subscription design where you pay lets say 10$ a year and you will able to download modules in a very easy way. More about this when I get round to it.