Update: Things are rounding up

OK, I found out that there was a reason I did not want to use globals and must of forgot it when I wrote the cache component. The reason was because it cannot be passed through child launches which means that a 'child' kernel process cannot use the globals of its 'parent' kernel process. The solution was simple. I reserved a cache area in the store so that it can be inherited to child processes. The only global allowed is the store file handle which is passed as the first parameter when launching child processes. Creating objects via a method is much slower than a direct call but that was expected. Methods are not for speed but for functionality. It allows for easy replacement of functions at run-time. I guess its around 10x slower with methods then with a direct function call. I will try and improve this in the future but not now. Usability now, speed later. I have decided to write the API first as to 'finish' the kernel and then I will port it to PalmOS. I am thinking of how to reduce the number of lines requried to implement a method which currently requires 2 functions, 1 identifier and 1 declaration. I might think of some macros to shorten this up but unless I come up with something, it might have to be a utility to ease the writing of methods. Here is version 0.13 http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_28653832

Update

Hi, I did alot of re-write to the message component so that it can not only send but also recieve parameters. Also added a memory component for encapsulating simple memory functions. This allows for example to read from an object into memory and then write it to a channel for sending a message. It works nicely although a little fragile, care has to be taken that if a module expects a parameter, it must be available on the channel or the module freezes. I'll see what I can do about it. Meanwhile here is version 0.12 http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_28108048

Update

I decided to do some extra functions before porting such as basic string management, modules and also did some cleanup. I might actually do the API first and then port but I will see next week what feels right at the time. Things are going well... I improved the performance of method calling as you can see in the demo attached. You can find version 0.11 here: http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_27753400 Enjoy, Zakai Hamilton

Update

Things are going great :D OK, version 0.10 has methods working. This is very existing for me that I have reached this stage. I am using relative function addresses which means that even if the application moves around in memory, the function addresses still work which is very nice. Here is the latest code: http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_27284552 So what's next? Porting to PalmOS and Writing the API for programmers to call. This should take some time. Once the porting has been done and the API has been finished, then the first 'real' release of the kernel will be available which means that you can already use the kernel from your applications. I dont think you will find it too useful but it will work. After that I start writing the user interface module which means I will finally able to show something, untill then... please be patient, Thanks! :D

Update

Did a few more bits of fixes/cleanup making porting much easier. I am working now on finishing the message component. Once I finish, I will start porting it to PalmOS. This should be very easy if you look at the _Win32.c files that represent windows API specific function calls. Once I finish porting to PalmOS, I will start making the Screens API so that modules can call the kernel functions. The functions will be different from the components in the kernel to make a difference between the interface and implementation of the kernel. Here is the lastest version: http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_26815136

Update

Hi, I have done alot of work over this past week. I have made the porting file Store_Win32.c simpler and small leaving all the checks and steps for the platform independent code and making the porting file just a simple wrapper. This should make it even more easier to port Screens to other platforms when released. I have also written the first draft of the Message component which on windows uses pipes for inter-process communication. I will do the same thing as I did for the store component and make the Message_Win32.c just hold the wrapper while Message.c to hold the functionality. PalmOS will be using feature memory. You can find the latest code here: (I am trying this new service out since my geocities account has reached its limit): http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_26661554

Update

I have cleaned up the code a bit and done some changes such as renaming the Item component to Node and creating a new Item component that deals with collections and lookup. This provides the base for inheritence that will be used by the Type component and the Method component. Hope to finish them very soon... Here you can find the latest snapshot of source code: http://www.geocities.com/zhamilton1/Xec07.zip The current representation of objects in nodes is as follows: Object -> Collection -> Item -> Node... Each object has collections of items and each item can hold a hierarchy of nodes with data. This design makes the object storage very versatile and flexible and simpler. I have also implemented Links that allow a node to appear like another node in hierarchy and data. This is used for example in types where each object type links to its type super (class) object.

Another Quick Update

As you can see I am getting a bit of more work done on Screens, Here is the latest version: http://www.geocities.com/zhamilton1/Xec06.zip So, What's new? Well, I have fixed many bugs since and added a few new components like the quick cache manager so now creating items is realy fast (like 10,000 objects in less than 10 seconds on my windows machine). The cache manager is platform specific like the store component. On windows it just uses globals while on PalmOS it will use feature memory. I was able to implement this functionality very quickly.

Update

Hi, My son is now 4 months old, time does fly when you dont get sleep :) About Screens, I hardly had time to spend on it however lately I have done a big push of finding time to spend on it and while the code is not even complete (and yes... I rewrote again), I just wanted to update you that this dead horse is still being kicked. Hey... Vista took 5 years, Maybe Screens will too ;) http://www.geocities.com/zhamilton1/Xec04.zip It currently compiles and runs on windows (the Store specific file will be written for PalmOS when I finish). It basicly shows the speed of creating items which gets slow as more items are created because of the lookup routine for free handles (which will be improved but not at the moment). So why a rewrite? Well first of all everytime I rewrite I get things done quicker, easier and nicer. I have also planned a new easier and faster way for implementing methods which was getting really ugly with the previous version. I have 9 components written so far and many more to come. Xec is the code name for the launcher I plan to 'launch' when I finish (if I finish). Enjoy!