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...