Fixing bugs

I have uploaded the latest source code which includes many bug fixes to make the kernel work. I have not only finished coding the communication between the module and kernel but it actually works quite nicely. I still have not decided what I want to make for the kernel, but I am sure I will find something...

Update: Kernel API Coded

Hi, I've uploaded the new source code: http://www.geocities.com/zhamilton1/screens.zip I finished coding the Kernel API thanks to some changes in the module.h header file. I know it looks like a hack but it realy did reduce the number of lines I had to write to get it working. If you look at the differences between StoreHandler.h and StoreHandler.c you will notice they are nearly identical apart from the prefix DECLARE and IMPLEMENTATION. And by this small change, it allows me to declare and implement the kernel side of handling kernel calls while in the application it uses the prefix INTERFACE and CALL which allow me to do the same thing but for the module side of calling kernel calls. A little complex but very usefull. OK, So I am starting to work on the application that will demonstate the kernel. I should finish it in a few months and I hope you will all be happy when you see it. Just remember that it demonstrates a very basic idea of the Screens Environment Object Storage and is to be seen that way and no more. From the module perspective I can know just call the kernel API and it will launch the kernel to execute that code. The application will look like a normal PalmOS prc file and can be launched from the normal launcher. Hopefully my design will pay off and the application will go smoothly, if not... I will not rewrite the kernel! Promise :)

Update: The kernel is basicly finished

Yep... You heard me right... I did it... I FINISHED THE KERNEL more or less. So what can you do with it? At the moment... nothing... Which is why I am going to spend now writing an application to make the kernel actually 'do' something. I still haven't decided what I want it to do but I'll think of something. You can find as usual the source code here: http://www.geocities.com/zhamilton1/screens.zip I am so thrilled that I finally reached this step! I knew it would happen (yeah, right ;) ) It just shows that if you dont give up, you can make it! So what do I mean by more or less done? Well... It was hard testing it internally so most of the bugs will be ironed out in the application I make that uses it. Of course while writing the application I will write the kernel API so any application can use the kernel services. If you look at the code in StoreHandler.h/c you will see a strange set of macros but these macros allowed me to reduce alot of code I would have to write otherwise. It allowed me to easily create message to function calls. I made it...

Update: StoreChannel has been coded

You can find the updated source as always here: http://www.geocities.com/zhamilton1/screens.zip I dont believe it! Things are going great! OK... StoreChannel has been coded which means that the kernel can not only launch modules but if a module talks to the kernel, I have now coded the component which will allow the kernel to read the parameters sent by the modules. What's left before I release the 0.1 version of the kernel? 1. Finish the transalation layer in the kernel that recieves the parameters and passes them to the kernel functions. No brainer here, just alot of typing. 2. Start working on a demo application to demonstrate the object storage and write the Core wrappers while working on it. While the demo application might be a bit complex (hopefully I'll think of some cool demo) the wrappers are just alot of typing. 3. Test that it works - the hard part :D Screens Environemnt is on a level it was never before and I realy feel that the kernel first release is going to be very soon. I know it has taken 4 years and the kernel only holds the object storage but because of the amount of design I have spent on other components like the UI, you will see the pace not slow down but actually go faster as time goes by. You have no idea how complex it is to design an object storage and if you dont believe me, just follow my posts :D

Store Channel Design

http://www.geocities.com/zhamilton1/storechannel.doc You can find here a short document about my design and implementation for StoreChannel component which deals with communication between the kernel and modules. Enjoy, Zakai Hamilton

Update: StoreMethod has been coded

I have updated the source: http://www.geocities.com/zhamilton1/screens.zip So, what now? The communcation between the module and the kernel. It looks like I will use system memory for sending parameters and feature memory for recieving parameters. The idea for this is that the kernel can manage the feature memory IDs instead of the modules. This should take a while because of its design not implementation. I will try my best to get this done as quicky and efficiently as possible. There are not any big issues here just small details like function and component names which I seem to struggle every time. After this comes the Core component wapper and then the kernel is considered done for a first version. After that the Core wrapper is done I will create a small application to demonstrate the kernel. Any ideas?

Update: Wow... Things are moving...

Yay :D StoreModule and StoreMessage are coded which allows me to send a message to another module. You can get the new source code from here: http://www.geocities.com/zhamilton1/screens.zip So what's left for the object storage to be usable? 1. StoreMethod - To allow methods to be attached to objects and send messages to them 2. This was talking about Kernel->Module communication, we still have the module to kernel communcation which will be done over PalmOS system chunks. 3. The wrappers - These wrappers deal with sending and recieving the parameters so you dont have to think about them so when you call StoreObjectNew, it sends parameters to the kernel and receives the object handle. Once these are finished, I can work on the UI Module. I will also publish documentation on using the object storage kernel. Note that the kernel does not include multi-threading or multi-tasking since you all want this version quicker, I am making the object storage single tasking. I know this project is taking forever and I want to reward you all for you sticking with me with at least something. The UI will be like I always wanted it to be which is dynamic. What does this mean? This means that I can have a button which is derived from a button class and I can either create a custom button or extend the button class. I can send a 'Draw' method to all windows and controls and each window/control will handle the draw command depending on its type. This takes away alot of the complexity. So you can say... all this way just for that? Its not like that... This is only using a bit of the ability that the object storage gives me.

Update: Thanks for the chat

Hi, I would like to thank the users who have been chatting with me on MSN Messenger (zhamilton1@yahoo.co.uk is my user name if you want to join) in the last few days. Your input has been very helpful to move Screens forward. I should have StoreModule coded by the end of the week which are objects that represent PalmOS Code databases (prc's). The advantage of a module is that you just need to know its ID to use it for executing methods on it. If all goes well, I will work on StoreMessage which allows sending messages to modules and StoreMethod which allows calling methods which sends messages to modules. If I finish these three components then I am very close to having the object storage ready.

Update: Screens Source Code II

OK, First of all this version now compiles because I have removed the UISurface component from this build untill I finish it. I have implemented the StoreProperty and StoreType components correctly and did some cleanup with the StoreObject component. I know the siutation is pretty grim so I am going to cut one of the planned features of the object storage - dynamic objects. This basicly allowed to execute code from remote locations as if the code was local. It doesn't help if I add this functionality if Screens will never be released. Its a very complex feature and has alot of overhead and I have decided that it does not reduce the goodness that Screens will provide. http://www.geocities.com/zhamilton1/screens.zip Enjoy, Zakai Hamilton

Update: Screens Source Code

Here you go, A new version of Screens source code, http://www.geocities.com/zhamilton1/screens.zip Enjoy, Zakai Hamilton

Update - Thanks to my wife

Last night while realy trying to figure out some deep problem in Screens design, my wife offered help and in 10 minutes we had a solution which was simple, not hard to implement (its already implemented) and sounded great! The problem was that although properties are objects, because they are stored in a side hierarchy (that is member objects are on a different hierarchy then property objects), I did not want the API's to have expose if they are storing thier objects as members or properties which currently they had to. The reason they had to was because when default objects were created, they would be created as members or properties and have to be moved appropriately. The fix was that all objects are created as members and are moved to be either members, properties or any other side hierarchies I have in the future. Another fix was that I made StoreObjectAdd/StorePropertyAdd move the object to the location (instead of adding it) if the previous location of the object is the default. This allows the following code to work very nicely: UIWindowSetBackColor(Window, UIColorNew(255, 0, 255)); Where it sets the back color property of a window to the specified color. What happens here is that the color object is put in the default location and when the window function adds it as a property, it actually moves the color from the default location to be owned by the window itself. If the color had already been moved to another location, the window would not gain ownership over the color. Great!

Update: Objects location

It looks like I will have to add multi-threading deep in the object storage which I realy did not want to do. I wanted to seperate the two but it looks like they will need to merged. Hopefully I wont have to. I am also improving the creating of objects so you dont have to specify a location but rather objects have a default location in thier instance. Unless an object is filed into a location, it will belong to the next object that uses it. This allows for most common use of objects to be created without worrying about moving them manually. More about this later if it works out...

Update - Here we go again

OK, Guys... I back on the couple of days update again... Here are the components coded so far: StoreStream StoreChunk StoreHandle StoreItem StoreObject StoreType StoreProperty I am now working on UISurface which deals with drawing to offscreen and onscreen buffers such as drawing lines, rectangles and so on. StoreObject does not support methods yet and I am still thinking of pushing the method stuff untill after I have some visual user interface built-in. Note that UISurface cannot draw bitmaps. I am leaving that part for the dynamic object method interface implementation. Its funny how people told me to hurry up because someone else would beat me to the punch and while I do know of someone who might beat me, there is no one else. Thank you all for your support, it what keeps this project going...