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

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!

Update: I am a father

Hi Everyone, Sorry for the lack of posts... My wife just had birth to my first baby boy two weeks ago on friday night. He was born at 7:50 PM (GMT+2) on 14/7/06. Thank god he is healty and doing well so far. Screens is suffered alot from this great piece of news since I dont have time anymore for personal things. I hope this will change but untill then I am sort of stuck on this project. It's just getting worse and worse... Everytime I think 'great, I am getting somewhere', I find that I am getting no where. The area here in Israel is pretty bad... a friend of mine was one of the soldiers killed in the north. It was very sad in our area this week. I dont want to be political... but it's always sad when your side has tradegies. I hope things get better for Israel and for Screens...

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

Whats happening with Screens?

Hi Guys, To tell you the truth, the moment I wrote you that last post I was sure I would be able to put Screens aside but... I was wrong! I have not stopped thinking about it and not stopped working on it since... Although from a code perspective its quite lousy but from a design perspective I have learnt so much. I am basicly never going to stop on Screens because it represents my vision for personal computing. If I will ever able to release anything before I am 50 is another matter but I will not be stopping development and design untill then ;) So... Here is the latest version of Screens code so far... But it does not run so dont try... http://www.geocities.com/zhamilton1/Screens.zip

What's going on?

OK, I have agreed to take time off the project... I have been working blindly on this project for the last 3 years without a single time off (not even on weekends... I was still thinking of the project) and I agree that its time to cool down and reget my energies back together again. See you all in a while, Zakai Hamilton

Update - When the going gets tough then Sleep

Hi Guys, I am not the only one who feels like this project has circled again and again... but let's not let that stop us... Coded StoreRecord and coding now StoreMemory... These are the final (I have seen that word before) components that the object storage implementation uses: StoreRecord - Provides a wrapper for PalmOS records and allowing read/write and copy to wrap on records, so writing to the end of X will continue on X+1. StoreMemory - Deals with allocation and adds chunks one after each other (in a linked list fashion) at the end of the last record (resizing the last record and adding additional records as needed). Compaction is done by aligning allocations. Allocations are found by handles (my favourite part of this component) which is a four part index (32bit) where each index is used to find a specific array allocation with the last indexed array holding the final allocation address. To cut it short... Each allocation can have a life long handle which never needs to change. The entire item storage depends on this. If you want to know more about this, leave a comment and I'll provide the jucy details. StoreItem - This takes allocations, puts a structure in them and has functions to manipulate the structure. Items are in a hierarchy with hard link support where each item can have an optional name and a data chunk. After this... I start coding the user interface components. Note that the alpha wont support the object oriented stuff. Neither will it support external modules. The idea is to give you all something to play with untill I finish the object oriented stuff which is realy tough (how many OO operating systems do you know of that made commerical success). The alpha will probably preserve the PalmOS look to ease my mind off the graphics part but will allow movable windows. We can make it different later on. The item storage sounds simple and probably is but it took me a long time to get here.

Update - Things are going well again

The lifedrive has realy given me a big 'pick me up' feeling which is just what I needed for Screens Environment. I had a day off work on last thurdsay and coded like crazy all day and went through the same write and then erase and then write again method which got me some code written that wasn't removed by the end of the day. I am still working on the first components and trying my best not to find too many flaws in them which should cause me to erase them. So far... So good ;) The combination of writing on my lifedrive and on my computer works out well so I might just able to get some code out of this research madness... It is tough writing an object storage... its a bit like writing a file system!

Back on track

Hi Guys, I am back on track and back coding on my new lifedrive which I realy love. I found out a design which would allow me to ignore multi-threading completely and implement it later easily. Messages can be sent syncronously or asyncronously. The system can decide how it wants to run the asyncronous messages with yielding the current message or without. This would allow Screens to run with or without the yielding of threads. Yielding makes sure that a message doesn't hog the CPU for too long. So the idea of this release is to make it as simple and small as possible including only the absolute needed features. Let's see how this goes... writing it on my lifedrive...

There is hope

Thanks guys for last week's chat... I needed to be told what to do (I guess thats why things work out here at NDS). I am going to hopefully get my lifedrive tonight. They were out of stock on thursday so hopefully it should arrive soon to the shop. OK... so I shall spend this week time to code the KISS based Screens shell. This is basicly a re-write which is without the multi-threading and without any 'future' feature and focusing more on what is needed for the alpha. New hardrive... New lifedrive ... New oppertunity...

Bummer

I come home last night to code and my hard-disk died on me... thank god that I uploaded the sources online, my email is online, my msn is online... so I didn't lose much... I plan to buy a new hard drive today so hopefully I can get up and running tommorow. Here is a document I wrote a while ago which sums up alot of the features that I wanted Screens to have: http://www.geocities.com/zhamilton1/ScreensEnvironmentKernel.doc Hopefully this will be a change in the forever looping of Screens Environment...

I am not going to make it

Hi Guys, To tell you the truth, I don't see myself being able to code the alpha by the end of febuary. I am still getting stuck on the object storage. For other OS's the bootstrap might be what kills the project... for Screens... it feels like its going to be the object storage. I have all these ideas in my mind, and I just can't seem to close in on this object storage. I also don't see to have much time lately because of my job advancement. I tried coding on my handheld but my fingers ache. The life-drive might help in that department since it has a larger display space but I doubt it. I have all the designs in place but its the little things that are driving me insane. I realy dont know what to do and unless I get some real help in management, I dont see Screens going through. Yep... that's what I need... A manager for Screens. Over the years I have tried to find a partner for Screens... or someone who could deal with the marketing and 'deal' with me in the sense of planning and those little decisions. And I still haven't found one. I am a bit isolated in the sense that no one around me are geeks. I think I am about the only real geek in my entire area. I need someone to join the team... and no... there is no money involved... Screens is public domain so there is no money made here... It's just one of those "I wish for A and no one will make A, so let me try". Anyone interested for giving my some guidlines and education? anyone? Bill gates has Steve Balmer... I need a Steve Balmer on my 'team'. Anyone interested?

Update - Code on the go

OK, last week I didn't get anything done... so I have decided to start coding on my handheld via OnBoardC.. I travel every day nearly 3 hours so I think that it would be great to use that time for coding Screens. I am buying a life-drive at the beggining of febuary so that should help a bit with coding on the go. I however did get to talk to my MSN user group and thanks to thier comments, the alpha looks like it will still be on schedule. My multi-tasking design allows me to focus on the alpha and push the multi-threading to a later stage until its realy needed. There is no point having threads if I don't do anything that needs them. Threads just for the sake of it is not the point. Every module has the overhead of the item store which it can read and write to. I am now coding the item store database implementation so that it will use a resource database instead of dynamic memory. This will give it more persistance. The alpha user interface is not going to be defined in the alpha code but rather it is released in the item store database. This means that the alpha will have to prc databases: one for the alpha code and one for the item store. The advantage is that code is kept small while the item storage can then be modified at any time. I will actually be writing the user interface in XML and converting it to items. The advantage is that I can make changes without recompiling. I will make a small utility which will take a Palm DOC database in XML and create an item store from it. It will also allow to export the item database into an XML based DOC database. The advantage means that I can make tweaks to the user interface and only have to ship the item store database and not code changes. And you get the advantage that you can tweak it yourself ;)

Update - Real tough week

I knew this would happen and it did... This is going to be one of the most toughest weeks before the alpha. Let me explain why: One of the most important things in any OS is how one peice of code talks to another. At first I thought I could do this through shared memory. But that just turned out to be an absolute no go. Each module is going to have to know how to read and write to the object storage. The advantage is modularity and flexability... the downside is that any major design change that I make to the object storage will break all existing modules. This requires to recompile all modules if I change the object storage. This is ok in the alphas and betas since I am the only one writing modules but after 1.0 I am locked into this specific implementation for many years to come. I'm going to take that chance. I am going to do some cleanup in the code this week removing the complex bits in the code and making them simpler. I am also going to make the memory components now use the ObjStore.prc resource database. I am also going to start a new project in the workspace called 'Shell' which is what you users are finally going to click on in the PalmOS launcher. OK... so what are the multi-threading biggest limitations: One running instance per module - This means that two instances of the same module will not run at the same time. One instance must finish before another instance of the module can be active. Think of it as each module has an instance queue and the first instance in the queue is the 'active' one. This does mean that other modules can do calls to modules without worrying but it means that if you have a module A in a loop and module B tries to call module A, module B will have to wait untill the first instance of module A ends before it can call the second instance of module A. Cooperative multi-tasking - This means that if an application does a loop without calling any external API function, the system is stuck untill the loop ends. This is like Windows 3.1 but since any API function can yield, it will only be noticable for situations when calculation loops are long or stuck. The lucky thing is that even if the code gets stuck and you need to soft-reset, all the user interface and data stays intact. The project is realy getting into shape... but its going to be a hard job untill I finish Screens Environment's basic structure... Wish me luck! Edit: OK... I think I missed something... 1. Screens Environment runs cooperative - While this is true in Garnet, there is little stopping Screens from running pre-emptive in the future like for PalmOS Linux. For developers who will write Screens native applications, they wont have to worry. There is a limitation if Screens did run pre-emptively which is that a single module would never run two instances in a pre-emptive environment. This doesn't mean that two instances cannot switch, it means that code of a module wont able to run using interrupt based multi-threading but rather only via cooperative multi-threading. This means that if a module does an endless 'while' loop... on Garnet, Screens will halt untill you soft-reset while on PalmOS Linux, Screens might continue to run but any code that is dependent on that module will halt. I know it sounds terrible, but its not realy that bad especially since the user interface is seperate from code so even if an application 'halts' the system, your changes are not lost.

Update - Research week

Ok... this week was more about learning than coding (last week was more about coding than learning). Not only did I get to go to a Effective C course this week but I read two books about Windows (one about 3.1 and one about CE) which were filled with kernel details. I also must thank my father for getting some sense into me about 'pre-mature optimization is the root of all evil'. I have put more design onto the multi-tasking model so that I can code it next week. It won't be fast but it will work. Optimizations can come afterwards. Code clarity is more important. The way it works is that each module calls another module via the kernel. The only way for modules to exchange information is through the object storage. Each call is done using SysAppLaunch but saves the stack of the module before hand. The kernel holds the schedular which chooses which task to launch. A task is either a sub kernel call or any other module. A module can only call the kernel. The kernel can queue a task which is executed at another time. This does mean that even though a module thinks it's doing a sub call to another module, it realy isn't. Instead its queuing up a call to the schedular. The kernel always returns after every thread switch which means that for systems that require response at all times can use Screens Environment since the shell is the application that says 'OK kernel, call your next thread call'. The shell also is responsible for sleeping or stoping the kernel from running. It is also responsible for passing key and pen events by calling the appropriate functions. The shell is the PalmOS application you see when you goto your launcher. You dont run the kernel directly, you run the shell which runs the kernel. Think of the shell as win.com used to be ;) Reading and Writing to objects is done using shared memory which is allocated as system memory blocks. When you read or write to an object, the memory block is purged so you cannot use it again. Think of it as a one way channel to send or recieve information. Each kernel call can pass one memory block and recieve another. Its up to the kernel to purge the passed memory block and up to the module to purge the recieved memory block. Note that the framework will do all this for you. All you do is call the API functions. Everything else is handled for you. That's enough specifics for now... For those who don't understand... don't worry about it.

Update - Things are getting done

Finally, things are getting done... I have nearly finished the surface component (to create offscreen buffers) and hopefully today I can get some rectangle and line drawing. Then I start working on the layering code elements. Once that is done, I'll be very happy. I am trying to make things very simple for the alpha and cutting out any imediate use features such as multi-display support. While users wont notice the difference, it does mean I might have a harder time in the future introducing such a feature. I'll keep you updated when I finish the elements code with maybe some screenshots ;)

Update - Finally a written object storage

Updated the source ;) I dont believe I got to this position... here is a list of components coded so far: SaturnMemory, SaturnChunk, SaturnItem, SaturnData, SaturnFolder, SaturnFile, SaturnProperty and finally SaturnType. The code compiles but has not been tested... I plan to do bug testing when I have something usefull to test with which is after the window management is written. If you look at the code, it's got loads of comments, so if any of you want to go through the code and point out bugs to me... that would be helpful. So what's now... as I said in the previous article, I will now be working on the drawing model. OK... so I want to let you know of some of the user interface policies/issues/ideas that Screens I plan to do for the 1.0 release: 1. No Tap Count - Screens is not going for the least number of taps. Yes... if you think you will be able to do simple tasks in the least amount of taps... use PalmOS. Screens is all about balance of all features in a usable design. The least number of taps does not mean the easiest to use or the fastest way to get to something. You dont have some kind of time-limit on your taps... so sometimes two quick taps is better than one long one. You will notice this alot when you deal with objects since nearly everything pops up a context menu when you tap on it. Yes folks... 2. No Secret Pen Tricks - No tap and hold... I have thought of this feature time and time again and just dont see to find any justice for it. I know you many of you are used to left-click defaults and right-click context menus but for Screens... the left click IS the context menu. I know its going to take time to get used to this... Screens is not trying to please anyone by copying some other OS (you know who) by these windowing shell features. I want to try out new things and what better way then with a new project. No double taps either or any other combination of secret drags and drops. Everything is visually visible in Screens and I plan to keep it that way. When you drag & drop an object, you will know exactly what its going to do. You wont have to guess what the action will be (move, copy or maybe poof like in MacOS), you select the action. While this does mean an extra click for the default... I think it makes the feature more worth while for a extended use than guessing the default behaviour of things. Many wish the UI would just know what I want... I dont... I want to tell it what I want because sometimes even I dont want to do what I think or prefer. 3. Extensive use of the 'Go' slider - Yes... The sliding icon bar is going to be used as a very central part of Screens. The slider is a flim strip like bar which sits above the widget bar and when you tap on the sphere in the widget bar, it will popup the slider. The slider is your gateway to launch applications, switch between applications, goto settings, the applications menu and so on. I realy hope you will like this idea and I am sure it will get refined as time goes by. No one has gone this way before. You can find an old editorial I made on the idea here: http://screensenvironment.blogspot.com/2004/08/icon-based-menus.html 4. The Widget bar - The widget bar sits at the bottom of the display with the go icon in the center (the icon raises a bit higher out of the bar). You can tap any unused area in the widget bar to show the Widgets window which you can add new widgets to the bar. Tap any widget to show a window representing the widget, so tapping the Time shows the 'Diary' window where you can see a today like screen. The default has mostly an empty bar with the time on the right. It allows to put any of the features you use the most on the bar as your personal preference goes. Dragging widgets off the bar - remove the widgets but not with a poof but rather undock them where you can either close them, put them back on the widget bar or have them hovering above all other windows like post-its. While widgets will be code based at the beggining, I see a future of script style widgets as well. 5. Hybrid Browsing - Yep... Screens is going to be more spatial than any other spatial system known to date. Everything has its color, position etc. But it doesn't mean that if you want to dig down some folders that you have to be spatial about thier location. Screens extends the browsing to not just a navigational OR spatial browsing but rather a spatial AND navigational browsing. You can position all folders and document windows in your locations (wont have much use on such a small screen but when we get to terminal futures...you will get the picture) but you can also dig down in a navigational window to any folder you want like a link refers to another object, a navigational window can refer to a spatial window showing it in another size and position and even a different view. Think of it as a temporary clone... That is... Everytime you dig into a folder in a navigational window, it makes a copy of the spatial window and applies the navigational window settings to that spatial window copy (like the view, size, position) and so on. Your original spatial window is not affected. Only when you make changes to the spatial window are the changes kept. I find this a difference between temporary browsing (navigational) and common browsing (spatial). 6. Sessions - Ever wanted to stop your current task, just to do another quick task and return to your other task but forgot what the original task was when you finished the first one? Well... Screens understands your problem. Screens allows you to work on windows that are to do with a specific task or session and if you want to suddenly work on a new task, you can just create a new session and it puts a half transparent layer on top of your existing work and allows all new windows opened to do with another task. Want to return to your previous task, you can either switch to its session or close the new session. The advantage here is that any change you make on one session such as moving windows does not affect the layout of another session. I believe that looking up a contact or creating a quick appointment or jotting down a note wont distrubt your workflow. Sessions can be created automaticly like when you get an email notification, if you tap on the notification, it creates a new session for you to read, reply and manage the email message. Once you are finished... return to what you were doing before hand. This is just a tip of the iceberg of innovation I have in my head just waiting to be implemented for Screens... Enjoy the teaser of words ;)

Update - Things are moving at great speeds

Hi Guys, I have a few functions left and I start coding the drawing components. After talking with my MSN user group, we decided to push any pixel effects such as alpha-blending to the beta cycle and leave the alpha for the basic stuff such as the interfaces and general structure. The first alpha is right on track for febuary and hopefully you will like my GUI ideas up my sleeve. Note that this is NOT trying to be a launcher like ZLauncher. I am trying to create something NEW, NOT be as close to PalmOS as possible. I got the feeling that some users thought I should go the 'be like somebody else' idea. Screens Environment deserves to be unique. If it's not going to change the face of the earth, what's the point of Screens in the first place. There are enough launchers out there. Anyway... I should hopefully figure out the function names (my hardest work... seriously) by the end of the week for the drawing component. Once I finish the drawing component and do a few animations, I will start working on the layer element functions which allow you to treat the display like a canvas and just draw layers and layers of drawings one on top of each other with clipping and transparency. The advantage is that as long as you dont do pixel effects (only supported in the beta stage) you dont have to worry about transparency colors. Once you do pixel effects, you must specify a layer which is like a mask but with the ability to allow gradients and shape based alpha blending. Remember that the animations are important and they are frame based which means that on slower devices you dont get a slower experience. Rather the animations are displayed with less frames. The advantage to this is while there is enough processing power, animations get displayed with full frames. If you are doing background proccessing, the animations frames get shortened. This allows you to enable all animations without worrying about it slowing down your device or experience.

The year of Screens Environment

Hi Everyone, Happy new year! This is going to be the year of Screens. I have the alpha coming out in febuary (probably at the end of febuary) and I have great plans for this year. First of all, know that I have been coding more than ever. I decided to rewrite the entire object storage to not only make it much more simpler but to go by the KISS rule (thanks to the MSN users). But dont worry, its been mostly coded already and uploaded. You can find nearly all of it here at: http://www.geocities.com/zhamilton1/Saturn.zip So what do I have left for the object storage? Two more components that I should finish tonight: SaturnProperty and SaturnTypes. It basicly allows to specify properties to objects. I am very happy with the current implementation. While the object storage will be updated before the 1.0 release, it wont be touched untill the first alpha. So, I have about two months left... So I will be now concentrating on getting the UI stuff going. I have had alot of experience building my layering engine for NDS and now its time to put that magic to Screens Environment. So I will be focusing my this month on the UI stuff like windows and controls. Note that I am not going to be implementing the Sony API's yet but hopefully will do so for the 1.0 release. Also I will only be supporting 320x320 resolution for the alphas. The 1.0 release will have multi-resolution support such as 160x160 or 320x480 with rotation. The first alpha as I said before will include the basic desktop with the widget bar and a few widgets. If I have time, I might add some more features, but this is the basic stuff if time is short. While everything is currently coded directly into the kernel, I will support 3rd party modules in the beta cycle. This is the year you have been waiting for... 2006