Update

Finished coding all functions in the PrivateData component apart from Resize and Align which while are not needed at the moment will be coded after CoreItem is coded (because CoreArray uses it). I have added a new feature to the CoreItem design which are called Temporary Items. The difference between a temporary item and a normal item is that once a normal item is removed, its handle now points to an empty item and the handle will never be used by another item. Temporary items once they are removed can have thier handle be used by another allocation. If you create a temporary item, you must make sure that the handle is not used or stored once its removed otherwise you might point to another item by mistake. Temporary items are used for either tightly controlled items (like the file item of an object) or quick/temporary uses. So I have CoreItem to code now which is going to probably take quite a while. Its a complex component but provides great uses once its finished. Then we have CoreArray which basicly takes an item and allows to store an array of structures together one after each other but unlike C/C++ arrays, the array is dynamic. I really feel the progress coming forward. I dont see myself recoding what I have coded so far, so I see this as the final code (not demo code).

Blog... Blog... Blog...

So I found last night what was causing headache while coding... Offset calculations The PrivateData component takes the stream provided by the PrivateDisk (previous) component and splits it into allocations called 'Data'. Each Data is allocated after the last data allocation so even if data is removed anywhere but the last data does not regain allocation free space. That space is regained by aligning all data to the start (overwriting free space). This makes allocation and deallocation actually fast while aligning is only done at specific times and is done step by step so it does not stop the flow of the environment. So where is the problem? There are many calculations done like getting the end of the header or getting the byte after an allocation and doing addition and subtraction on them. I was good at math but its hard to focus that hard when you focus after 9PM and able to read the code I just wrote. How will I solve this? I will create some macros to simplify the calculations into macro calls. I am working on the macros (throughout the day) and hopefully I will retry to code on sunday night. We are seeing progress and I am glad that its going well so far.

A bit of blogging

I bought myself a game two days ago for about 10$ (50 NIS in Israel) called 'Beyond Good & Evil'. And its been my latest thing from stopping me from focusing on Screens. Its so addictive that I spent playing it between 6PM-2AM last night without noticing the time fly by. I have decided not to by any more games untill Saturn is released. About a release date... I realy cant say now... I will have more of a release date once I finish the core. So what is left currently in the core? PrivateData - should of written it yesterday... see above why I didn't but I should code it today. CoreItem - Will code it next week and test it. Its a little complex but I should be able to do it. CoreObject - This is where the fun begins since there is no more calculations but rather just structures and item allocations. CoreFile - This deals with the 'stream' part of an object. You can read/write, resize and so on. CoreNumber - This is a subset of CoreFile CoreString - This is also a subset of CoreFile CoreLink - This deals with the relationships of an object. CoreFolder - This is a subset of CoreLink CoreProperty - This is also a subset of CoreLink CoreModule - This deals with module objects (like Applications and DLL's) which either hold code or point to code. CoreMethod - This is also a subset of CoreLink CoreTask - This deals with the task objects (like threads/proccesses) CoreMessage - This deals with the queue that each task has That is the Core. Most of the subsets are quite simple such as CoreString and CoreFolder. I will explain more on the components as I code them.

A bit of history

Because I am deep into the internal sea of details, I get too carried away and show you all the technical details which are either not interesting (to those who have no idea what I am talking about) or just have no actual use. They are more usefull to me when I want to port Screens to other operating systems without hacking my head like I have done for the last three years. I haven't had a single day of screens without indulding my brain into it day in and day out. Screens has changed alot over the years... who would believe that it was first created to be a common library so I could code some PalmOS games (still planned after Screens) and become a full-fledged multi platform environment designed to be a merging layer among operating systems to bring that unity to coding and user interfaces. If you look at my development history you wont find anything... sounds a bit suspicious but then again I only got an internet connection when I worked for NDS (The company that creates the smart cards for DirectTV and other sattelite TV providers) in Jerusalem (Israel) in 1999. I just turned 16 when I finished a summer work for them so I was allowed legally to continue working for them. I worked on many internal projects for them and got alot of focus on MFC (Microsoft Foundation Classes) user interface development in Visual C++. I worked there for 3 years and it was basicly a walk in the park. I realy enjoyed my time there (mostly playing starcraft when fellow employees would pass by my office). I only got my first home computer when I was 13 and was so amazed by it. Learnt Word Basic (for Word 7.0) and Visual Basic for Excel 7.0 and had my first environment where it was my solution to allow kids to have a customized user experience (with even a desktop background and per user settings) without ruining the computer for thier parents. I did alot of small projects for myself which sadly were lost with confronting the Chernobil virus twice (yep... 26th of april two years running because I replaced the computer but left the virus on the hard drive). I would like to thank my father because not only did he get me interested in computers, he got me the summer job in NDS in the first place. Anyway... So I was 17 or 18 (cant remember) when my girlfriend (now my wife, so far married for 7 months) gave me her Palm III device which she had no use for at all. I was absolutely amazed! I had noticed the Palm V devices in the stores but never bought my self one (although I could afford it then). It had 2MB of memory, small but expandable, pen based and fast... I enjoyed it for at least a year untill I found it dead from being sat on again and again in my jeans back pocket (where does it say not to put it in your back pocket in the instructions?). So my next device was the Visor Platinum with a Visor Phone. Walking around with that brick felt so good when people would stare at me. I loved being checked by security gaurds at the bus station to start having a convesation with them with 'what is that?' questions. My cat pushed the phone off a shelf and because I was basicly life dependent on it, I replaced it within a week with a Visor Pro. That lasted me untill I got a Tungsten E last spring when I got engaged with my wife and her father gave the handheld as a present (the ring was about the same price, so it felt even). So where does Screens get in the picture? Just the spring before I left NDS I got inspired by a PalmOS application called 'Extended Window Demo' by Andrew S. Downs developed in 1999. It had movable windows which just sparked in me and thats how Screens started. It just continued from there, starting to add more and more ideas and the shedule just moved on and on. You can see most of the history still on 1src at http://www.1src.com/forums/showthread.php?t=5646 Carefull... its alot to read. So thats basicly it... I have been working on Screens since... try to recode here and then (have rewritted just the few base components over 17 times) and redesign when I get stuck. Currently coding is going well and hopefully this will be the last rewrite untill the demo. I realy have a hunch on this version. The best way users can help me is to chat with me when they can via MSN Messenger or post comments on my blog or on 1src. The more questions the better it helps me fill the holes in my design and it allows me to get Screens out faster. For those who have sticked around since the beggining... THANKS. I know it must be hard to have faith with little substance but it will be fruitfull in the end and you will be graitfull for your support (I am already).

Heres another update

Hi Everyone, Nope... the project is not dead, its still going forward. So what has happened lately: 1. I have coded the PrivateRecord and PrivateDisk components... I have the PrivateData component to code this week and CoreItem component to code next week. I am late in schedule (I was meant to have a working demo by the end of march but then again I am never good at sticking to schedules). 2. The CoreItem component is now much better designed has a minimal footprint of only 4K without any items and items take only 128bits (16 bytes) per item. Objects are made of a few items so the overhead of each object is about 64 bytes. What does all this mean? It means that the more objects you have in the system there wont be much overload. The item component will get an editorial once its coded because its quite a piece of work. Each handle is fixed and is only 32bit and lasts untill the item is removed. It splits the 32bit into four 8bit indexes and in a tree design it finds the next address by each index untill the last index has the address of the actual data. This allows item blocks (which hold addresses of other items) to only be 1K and be movable without any problem. Only one location needs to be updated per item. I will update you all next week once I finish the PrivateData component. I am very proud of my progress over the years and I hope to give you some kind of facts very soon (but then again... I am always late in my promises).

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.