The Disk

This is alot to swallow... so only you users who want to know how objects are stored internally read on, otherwise skip the post. Screens needs a place to store its objects. Each object has properties like its name, type, size and so on and its data, however I need a place to store them and I cannot just write them down one after each other in a file. Screens has a stream it creates from a database 'ScrMain.pdb' with the type 'DISK'. This stream is interfaced through the Disk component. The Disk component gives me a file interface to read/write to the database. Why not just use the standard PalmOS functions? Because Screens is designed to have as little as possible dependency points on PalmOS. By using the Disk component which can use any underlying way to store the stream, Screens gets maximum flexability if it is ported to another platform. So the Disk component gives me a stream of bytes which I can read/write to. But its just a stream, how do I store objects on them? Well... If we think about it, each object has a header and data. Because its better to store them in seperate places because the object header is fixed and therefore indexable while the data is sizable and therefore needs some allocation/deallocation method. Screens devides the Disk into fixed Areas. The Area API allows to deal with these fixed areas. Currently Screens splits the Disk stream into two areas: the Object area and the Data area. Each Object header is stored in the Object Area and each data is stored in the Data Area. Lets focus on the Object header at the moment. The object area is stored from the end of the disk stream and backwards. It stores the object headers in a backward fashion (the actual header is forward but indexes backwards) so the first object is aligned to the end of the disk with the second object behind it. The start of the last object header is the end of the object area. The advantage of the area API is that it can store areas forward or backward. Each object header holds various object properties such as its Name and Type which are 128bit identifiers, the data offset (in the data area) and its flags (such as read-only). The size is stored with the actual data. The object header also holds a previous index, next index and depth value. I want to talk about those three values. You all know about node trees where each item in the tree holds its parent pointer, first child pointer, previous sibling and next sibling pointer and the advantage is that the items can be not in order (so new items are added at the end of the list and you can remove items from the middle) and still be fast at enumarating them. However one of the biggest problems with node trees is recursion. If I want to delete an item, I want it to delete all its children and its childrens children and so on, but then I need to use a recursive function (a function which calls itself) to go through and remove each item only after I have removed its children. So I need to dig up/down removing items with no children untill all children are removed. PalmOS has a limited stack, so it cannot handle such recursion. This is one of the reasons there is no VFS function to remove a folder with all its sub folders and files because it would require recursion which PalmOS is just not good at. Which is why I think they did not include a file system design in the first place. Screens solves this by using a hybrid node+depth design. A depth design holds a depth per item so it knows by its depth value who is a parent (the first item before it that has a -1 depth), its children (if the item has children they follow directly with a +1 depth) and its siblings which it can look up/down for items with the same depth (as long as the depth is not lower but can be higher). This solves the recursion since it puts the recursion in the storage design. If you want to remove an item, just delete the item and all following items untill you find an item with the same depth as the item you wanted to remove. So it puts recursion in a single while/for loop. The problem with the depth design is that it relies on the indexes, so if you want to add an item you have to add it at a specific index which means you have to shift everything else downwards. Screens solves this by using a hybrid design so instead of using index+depth, it stores a previous and next pointer (like in a linked list) and a depth. This gives you the advantage of recursion in a single for/while loop and you can insert items freely since they can be added pysically at the end but can insert themselves in the linked list to appear at a certain index. So, we now have all the object headers stored in the object area in the disk in a backward fashion. Now I want to talk about the data area: The data area stores the data of each object which has a 32bit size value so it does not have the PalmOS 64K limit. It stores data one after each other in a linked list fashion. So each data has a data header which holds the size of the data, and its next data header (the previous header is not needed to know). You remove data by just removing its header out of the linked list. When you reach the end of the disk area, it tries to resize the area to cover more of the unused disk area. If it cannot expand because it will overwrite the item area it aligns the data. Aligning data starts from the first data and makes sure it is aligned to the end of the disk header. It then takes the next data and aligns it to the end of the first data and so on untill all data has been aligned. Then it can add new data since all the free space of the data area is at the end. If there is no more free space, Screens can ask the user if it can resize the entire database to a bigger amount. This moves the entire object header to the end of the new resized stream since the object area is always aligned to the end of the disk stream. There you have it. My disk design.

Update - Sorry

Yep, Sorry I have not updated the blog lately. I have been working alot on Screens that even my sleeps are short. Screens is becoming more realistic and although I have my long design ideas, I am making Safire be more about being a 'stable release' then a full feature release. You can see this because Safire is targeted as a launcher and not as an environment. This allows me to not only release some build sooner but it allows it to be a perfectly valid release and not some demo. I have cut down the object storage inheritence, but made objects smaller, faster and simpler. What does this mean to the average user? Probably nothing. This is one of the reasons I have not posted lately... its just boring technical information. I hope to write some interesting post as soon as I can ;)

Update

I am still writing the tiny details for implementation of the object storage however I will not be including Services in the Safire release. The good news is that the object storage becomes less complex and I can finish coding it quicker, however the bad news is that no constructor/deconstructor for objects and no other dynamic abilities apart from inheritence. This means that an object wont notify you when it has changed, so untill I implement Services, polling or a refresh command will have to do. I am trying my best to be realistic about this project, so I am cutting off anything in the base which can be implemented later in the release cycle. This is so I can release it first and update it afterwards. I think its got to a stable stage where I can start coding and wont hit the wall after a few hundred lines of code.

Update - Internals

OK... so alot has happened... I have fixed alot of my 'year and more old' problems and found solutions for them from how to do inheritence (fixed today), How I deal with UIDs and even my syntax for the API has been improved to be more object oriented. I have made it that objects can be created without specifying where they are stored, instead they can be attached later on. UIWindowInfo MyWindowProperties; MyWindowProperties.Name = UID_MyWindow; MyWindowProperties.Title = CoreStringNew("My Title"); MyWindowProperties.Region = CoreRectangleNew(0, 0, 100, 80); MyWindowProperties.Align = AlignCenter; UIWindow MyWindow = UIWindowNew(MyWindowProperties); I will continue to refine it as much as I can but its much better from my existing syntax design. Simple types can be defined with parameters (CoreStringNew) while complex types are defined by structures (UIButtonNew). UIDs are declared by the following: #define UID_Name UIDPack(Company, Application, Module, Name) Where the Company is a number registered at my future web-site, application is unique per company and module is unique per application, and name is unique per module. I solved how to store inheritence with a combination of static and dynamic lookup. Its quite a good solution which I might post about another time. I need more help to get this project of the ground... if any of you want this project to be out quicker... please post questions or comments via email, posts or MSN Messenger.

Update - So what's cooking?

Hi Everyone, I have fixed another huge issue I had with the object storage which is 'virtual objects'. I have made objects to be able to mount and unmount without loosing links and relationships between objects. This is a great change since it means I am one step further solving all the quirks with my object storage. The object storage is the 'core' of Screens, so it has to be flawless (not in functionality but in reliability) for Screens to be built. It is the biggest building block in Screens and is the base of any functionality I have in Screens. Screens is moving... yep it is still going... I have already decided what Screens 1.0 will include which is basicly launcher capabilties and db/file manager capabilities. Screens 1.0 is basicly a 'launcher' and will be marketed as such. It is designed to be a technology preview. As time goes on I will add extra apps such as calculator, contacts, diary, paint and so on and wrap them into one package for 2.0 That is the basic plan, since I want to release Screens as soon as possible in some 'stable' state... taking the launcher route allows it to be a stable launcher and still be released early... how early? No Idea... I'll give you a 'real' destination date once the core is coded, that is basicly whats holding this project back = The Object Storage

Update - Where is Screens?

Hi Everyone, I haven't posted for a month and this post is explain why. Fear... fear of getting smashed was my reason untill I realized that it's my blog, so anything that happens, I can post without any problem. My blog, my reactions. Alot has happened in this last month which has required me to reget a big picture of Screens. Screens is not about being a good-ol launcher replacment or some niche enviroment to show 'I can do it'. Its about a stratergy and vision which I have and applying it to PalmOS devices. This stratergy and vision is not about handhelds today but more about tommorows handhelds. Todays handhelds are very limited, not in the hardware (my opinion) but in the software. If the software was top notch for the hardware, I would say the hardware needs improvement but today the hardware is driving the software. The same happened with PCs and which is why we never see any radical stuff happening... Because hardware moves slowly and thats how you see the software move - SLOW! Screens is designed to get the most out of the software and let hardware follow instead of being the leader. So what's been cooking: 1. Palm is making a linux-based version... Great! What does that mean for Screens... a great oppertunity. First of all, there are loads of different devices out there... and new will come with different specs. This will be hard for developers to code for all the different types. Screens solves that by design with it's action-key mapper for example. 2. Multi-tasking I think I have found a way to do semi pre-emptive multitasking which in this itself is a good enough reason to restart coding. By starting from a pre-emptive perspective (or even cooperative) I can let go of many old designs such as using a modal dialog for copy operations... why not show the progress under the object label itself. It gives Screens more room to innovate which I think is a good enough reason to reevaluate the core. 3. SMPI Screens has already defined a new syntax design which so far... I'm loving it. Instead of doing API, I am doing a SMPI (Screens Module Programming Interface) where the syntax is based more on modules than on applications. So far... so good. That's quite a short summary... I will probably (hopefully) write a few editorials on the matter. just remember that if you want Screens out faster... to help me speed up the proccess, PLEASE chat with me on MSN Messanger at zhamilton1@yahoo.co.uk