Update - Speed Speed Speed

What a week... While working on the graphics component I checked how long does a message take to be executed. Well... I was in horror when I found out it was taking over 200 milliseconds per message. That means about 5 messages a second which is terrible. So I thought that I would either have to redesign the graphics component to use less messages or to improve the speed of messages. Well... it now takes about 7-8 seconds to create 1000 objects which is realy fast! While this performance test was on my PC (2.4 GHZ) and did not test this on my Lifedrive, I do expect the same kind of performance improvement. I improved the speed by caching objects that were constantly used in message communication. Things are going very well as you can see... The kernel is realy going well and the graphics component design has just been started. Thank you all for your help!

Update

Uploaded some changes to SVN such as returning CoreObjectMethod and modifying CoreMethodNew to return the method instead of a result. I have decided to avoid waste of time, I will be working now on the Safire module which is the GUI module of the Screens Experience. The GUI will be heavily object oriented which will show in its flexibility. Screens is all about the overall user experience and not about getting the best speed or polyogon count. Abstractions always fail when it comes to speed which is why all today's 3d games are close to the hardware. Safire, The next step of the Screens Experience.

Thanks

I have updated the look of my blog to reflect the maturity of the project. Screens methods actually work. I had a test application of a few lines that would register a function as a method and it would get called via a CoreObjectSend call. This would call the kernel module to deal with the CoreObjectSend interface function and then call my test application module to call the test function. I am very happy that I have got to this situation. Thank you all for supporting me for all these 4 years. The code is finally complete and will not be rewritten for quite a while :D Thank you all!

Update

I have uploaded a few more fixes to SVN. I hope to write the test application this week before the end of the year but I can never know what events happen throughout each week. I removed CoreObjectMethod and added a new function CoreObjectSend which sends a message to a method in a module. Because it uses objects, it needs to only send a single handle to the target module for it to figure out its parameters. It gives developers the flexability to share parameters without having to repass them in on the stack. Thats just one of the advantages of an object oriented storage. The code is now design complete. This means that although the code has bugs, its API is fixed and I will be using Safire - the graphics module to remove most of those bugs from the code.

Update

I have uploaded the property API to Sub Version. I told you it was easy :) I need to do make some command line look alike for PalmOS so I can easily test it. I might use the VFSDos project which seems to do that kind of work for me. Once I finish the 'test' application, I can officaly release the Xec kernel and start working on the Safire project. About speed... Screens currently has no optimizations in place and therefore is quite slow in executing modules however I do plan to make it faster as time goes by like caching the database handles instead of searching for them each time. Doing that optimization will help alot. You will see alot more happen visually on the Safire module than on the Xec module. Can't wait to get there...

The PalmOS port is finished

The PalmOS port works wonderfully. I can now add more common code without even having to test it on both platforms. I will add the property API's shortly. It sounds like they are alot of work since I have mentioned it so many times but thats totally not the case. Just lack of time to code. I do see myself releasing the kernel by the end of the month but might be postponed for a bit more bug fixing. I always read post replies. Only wish I got more... but I am lucky to get a question :D While Screens doesn't even have a UI or a Communication system, I have great plans for it in the future. I plan to take Wifi and Bluetooth a step forward by making them generic transfer protocols, you can do so much more with them. Connecting to a bluetooth device will be a simple as browsing a folder. Even for a developer it will be as easy as using the object API. That's the advantage of object oriented storage and why it is so key to Screens edge. You will be able to transfer files from a bluetooth device to wifi device with drag & drop. You will be able to treat them as like you use VFS. Here is a nice feature I will add: You will be able to do offline actions when ever you want that get executed when you get online with a device. Here is a scenerio: You meet a friend, connect to him and start to copy a file from his device to yours and mid way of the copy the friend has to run. The copy stops and when you meet your friend again and connect, it will continue to copy the file. Yes... Resume operations without you having to resume them manually. It goes more than that, you can transfer files back & forth from his 'offline' device folder and they will happen when his device is 'online'. The idea of everything is an object is taken to an extreme with Screens. You will still have applications that deal with specifics but the generic approach allows for many more uses that I cannot even imagine. Its all about a platform. Everything is a platform. If any of you have questions, ask away :D

Slow week

Hi, This week I did nearly nothing for Screens. I had to concentrate my energy on work for a change. I can see next week being more useful for Screens. I will try and at least finish the PalmOS port and if I can finish the property API. The PalmOS port is proving to be quite successful in the time it took me to write the port. It also allowed me to find bugs in the system that I could not see previously. Hopefully I wont find any problems.

Update - The PalmOS port is nearly working

I have finished the PalmOS port apart from one problem. The PalmOS File API's dont have a resize function. I can implement it by writing the extra bytes however it would be preferable if there was a standard file resize function. Oh well... I have uploaded v0.25 to SVN and will post something here when I finish writing the resize function. I still have the property API left but that's about it. I will make a simple app to prove that it works just like the Win32 version does. In fact, I might make the Safire application be a command line interface. This way I can make the code multi-platform. Note that I only ship in SVN the code itself and not the project itself to avoid compiler specific issues. You can however take my zip files which include the projects and the executables. For PalmOS I will just use a simple text entry for input and print out directly onto the screen. This will allow to ease the input code required for me to implement this. We are so close... so close...

Update - Bug Fixing

Hi, I did not get as much as I expected done yesterday. I do more of a cleanup and bug fixing then adding the remainder of the API. I have about 5 API functions left. I made it that you dont have to run Xec before running Safire by implementing basic version support. Everytime you run a new version of Xec, it detects this and re-registers its interface. This will stop the memory crashes that happen when running a new version of Xec on an old database. I also did some cleanup of the macros to deal with stack. Note that modules do not use interfaces but rather use methods. I will be adding some helper functions to deal with object based methods and module based methods. The kernel is released when I finish porting to PalmOS. I have not started yet, but I plan to do some very shortly. I can see a version being released before the end of the year. What does it involve porting? The stack will use feature memory and the store will use the PalmOS File API. The memory component just needs to use the PalmOS style functions for memory like MemPtrNew instead of malloc. The globals in the stack and store will be done using feature memory.

Update - I dont believe it

Yes... I am so happy that its going smoothly... I have added all the object functions to the interface and it works slowly but nicely. I use some macros to speed up the work so writing a wrapper was very quick and easy. The Safire application in the build talks to the Kernel and currently just creates objects and then counts them. I know the speed is terrible but thats what its going to have to be at the moment. But what is nice is the ease of using the interface. Include 'Core.h' and just call the interface functions as normal C functions. No need to include a library or setup some environment. Just plug and play the way its meant to be. Remember to run the Xec.exe first to register the interface before running Safire.exe otherwise it will not work. Also note that if you recompile Xec with changes, you MUST rerun it before running Safire or it will crash. This is because the interface depends on the relative function locations in Xec, so you must update the interface in the store before calling a function after a modification. You can find version 0.20 here: http://www.box.net/index.php?rm=box_v2_download_shared_file&file_id=f_30577216 I now need to create the interface for the other kernel components such property, type and method. This should be easy since the object interface was so quick to create. I should have it done very soon. Thank you so much for following up this long journey, the fruits are starting to show, Zakai Hamilton

Update

Great Work! :D Things are going great... I made a simple module that calls some kernel interfaces (CoreObjectRoot and CoreObjectNew) and it works very nicely. The idea is simple, clean and while there is alot of room for improvement, I am currently satisfied. I need now to finish the remaining API functions on both the module and kernel side which involves no complications. I should have this done by the middle of next week. I will be exposing the object, property, method and type components. The item implementation is private for the kernel. The advantage of having the kernel functions be in an interface lookup table is that I can modify them at run-time like hacks can do for PalmOS. Once I finish the API and do some basic testing that they work, I can port the kernel to PalmOS which should be very easy since there is a very small porting layer currently. I have uploaded the changes to SVN on my sourceforge site. 4+ years is alot of time but it was worth it. Remember that all this time was not about just planning the kernel but the future of Screens Environment. It does not take 4 years to write a kernel. It has taken me about two months to write it in code. So, when the kernel is released, what can you do? Well... its all about a store. You can include the Core files in your project and interface with the kernel to create objects with methods, properties, inheritence from types and so on. This does not sound like much but its the Core where everything else is just blocks on top that utilize the structure of objects that the kernel provides. Currently you need to run the kernel once to register its interface but I will improve this by checking if the interface exists and if not, register it. Zakai Hamilton

Update: Moving Along

I did some major cleanup today where I removed the Message & Channel component and made a simpler design called the Stack component. The reason for this is that I wanted the interface (that developers copy to call functions in the kernel) to be shared with the kernel itself to reduce duplicated code. Currently I have made the framework for the interface to be three files: Kernel.h, Kernel.c and Kernel_Win32.c This makes things very easy, much more easier than including a library into a project. You just copy the files into your project, include the Kernel.h where ever you want and call the API functions. I will be working on making a test module so that I can check the kernel interface works. I wont be uploading the source changes untill I can confirm that the mecanism works. We are really close then ever before, once I confirm that it works, I make the remaining API wrappers and we are done for the first release. The first release does NOT do multi-tasking but is the basic object storage and inter-process communication. The next step after releasing the kernel is to do the multi-tasking stuff or the graphics depending what is needed at the time. About the Stack component... Its basicly a temporary file used by all modules to transfer parameters from one module to another. You basicly push or pop parameters on one side and push or pop the parameters from the other side. Currently there is no protection in the case of non equal pop and push calls but I do plan to add that in the future.

Sourceforge here we go

Hi All, I have registered with Sourceforge: http://sourceforge.net/projects/screensos There are forums there and I am using the source control to upload changes more frequently. I will add here a link to snapshots which are useful. The latest code is a step closer to the API mecanism. I have finished the ability for the kernel , so I am now working on the code which is the interface that modules use. It contains a Core.h for the header, Core.c for the portable code and Core_Win32.c for the windows specific implementation. I realy feel that progress has been made in the last month and I am very happy with the code base. Modules call the kernel interface and the kernel can call modules methods. This one to one and one to many design makes it very controllable in the sense that all data goes through a single pipeline. I hope to have most of the module to kernel code done next week so I can than expose more and more of the kernel functions. We are realy getting there...