Update - Bad Week

Guys, this week was terrible... So much to do and so little time to code... 1. I had to put my first dog to sleep because he was old, had a hernia and cancer spots. 2. I had to go to the lawyer to create a contact for the house that I am going to buy 3. Moved offices in NDS and switched to a new job - Real EPG :) 4. Had to pick up my second dog from the pound because he was caught after he broke from his chain. The list just goes on... its a very busy time for me... Hopefully I will get that alpha out by the end of febuary... Everytime I think... yay... I am getting there... something pushes me back...

Update

This last week did not go so well... The weather changes here from cold to hot and back to cold and I am not coping well with the situation. I have had too many hours of sleep this week... its time to cut those down and spend more time on coding... Hopefully I should finish the draw component this week... hopefully...

Update - An Object Storage Presentation

Hi Guys, Here is a small presentation file which explains the object storage: http://www.geocities.com/zhamilton1/ObjectStorage.zip Enjoy, Zakai Hamilton

Update - Should start UIDraw soon

First of all I have updated the source code: http://www.geocities.com/zhamilton1/Saturn.zip I decided to skip the Copy function for the moment and do the more simple work but repetative which includes the KernelFolder, KernelFile and KernelProperty components which are self explanatory. At the beggining I am coding everything into the kernel however after the alpha I will start moving things outside the kernel like the drawing driver, UI and windowing to test performance. I have by user request going to focus for the alpha more on the UI aspects and less on the thread execution model. This doesn't mean much apart from you will get more UI in the alpha than otherwise would of been if I had to implement the thread component. It will probably be better this way since I will visually able to test the thread and module support. Just to remind you that the source code will be updated as time goes by but I will not release the source code of the shell untill the beta stage. If you want the alpha when its released, just add me as your MSN Messenger contact and you will be dropped into the Screens user group. I will be emailing all the users in the MSN user list of the alpha and where to get it. So if you want to get your hands on the first demo as quick as possible... join now ;) KernelFolder, KernelFile and KernelProperty I should finish in a few days. Then follows KernelModule which basicly allows to load a module by its key and allows me to tweak pre-loading and other stuff without affecting the basic call model. Because everything is any way going to be inside the kernel at the beggining, its more of a place-holder... so it wont do anything.

Update

I went to a Microsoft Windows Embedded Technical Seminar yesterday in the tel-aviv area... Very nice ;) Learnt a few things about how the memory is handled on PocketPC's and that the object storage in Windows Mobile isn't exactly what it seems. Back to Screens... I still have KernelObjectCopy to code... Didn't have time in the last few days so hopefully I should have time by Sunday. I'll keep you all updated, Zakai Hamilton

Object Storage - So what is it?

I constantly get this question: What is the object storage? Well... lets ask what is it trying to solve... Data Sharing - Tired of copying data from one application to another? The object storage solves this by allowing you to specify links between data so when one changes, so does the other. No more do you need to keep your contact names syncronized manually throughout your appointments, With Screens Environment and its object storage, its automatic. Single Store - Tired of having to use a different application to manage each piece of information in its own container like WordToGo for documents, a launcher for applications and a file manager for databases? Screens Environment and the object storage allows you to hold in one folder - a database, document, appointment, contact or any other type you want. This is because the object store can learn of new types just like you add plug-ins to Windows MSN Search or Google Search, so does the Screens Environment object storage work in the same way but it allows you to manage, not just search data. You will able to see the information you use not just by its type but by date, author or any other meta-data you want your information categorized and sorted by. Note that everything is stored in the object storage from the windows displayed on-screen, color schemes, kernel information, threads and so on are all objects. Think of an object as any piece of information that can be identified. I think this is a good starting point... ask away for more details or if you have any questions dont hesistate to post a comment, so I can answer in an upcoming post. Just a quick update: I finished the KernelObjectMove function... one function left KernelObjectCopy... I have nearly finished the object storage.

Update - Nearly there

Hi Guys, 3/5 of the object storage functions have been coded with two left: KernelObjectMove and KernelObjectCopy. This is great news for me, since it basicly means that the object storage is only lacking moving and copying of objects with the copying the harder function. Once I finish these functions, I review the code and start coding the drawing functions so hopefully I will do something to give you all some aspect that Screens is working. I'll update the source code when I finish the functions. Thank you all for the warm comments, Zakai Hamilton

Update - KernelObject nearly coded

Hi Guys, Summary: KernelObject nearly coded. Ive got it going on... ;) Description: I spent a few hours last night and this morning and was able to code nearly all of the KernelObject apart from 5 functions (the hard ones: New,Free,Link,Move and Copy). For the hard ones I will actually write a step by step comments (all other code has no comments since they are not complex enough). I dont normally go for comments, but in these cases, I think they are needed. Hopefully they wont be as hard as I feel they are, maybe its just because I failed all the other 17+ times I tried to get those functions coded. Hopefully this will be the one time that doesn't happen. I also made some changes to the header file as well and to alot of the previous components. Before hand I had 0xFFFFFFFF as an invalid index. However it doesn't work out very well so I decided that indexes would start from 1 and therefore 0 is an invalid index. OK, Here you go for those following the blog entries: http://www.geocities.com/zhamilton1/Saturn.zip This is the entire source code currently written with the project file and everything. I use PODS so if you have PalmOS Developer Studio (can be downloaded for free from the PalmSource web site) you can open the project file. First of all please dont be angry if you feel its only a bit of code. You will see as time goes by how much the code grows... when I get down to it... I code quite fast I think. Most of the functions are very straightforward so I didn't write notes. The function names are self explainatory. Note that there isn't error checking in all places. The reason for this is that if a function fails because lets say the handle is empty, all subsequent functions will fail as well without bad pointer issues which is nice untill one will do a check and return. Enjoy and have a nice weekend, Zakai Hamilton

Update - Going to code KernelObject

Hi Guys, Summary: Going to code the object storage and then the drawing code to display lines, shapes, colors and text on-screen. Description: I am there again and this time I am going to make it. I have everything in place for coding the object storage once and for all. I should finish it by the end of next week and start coding KernelDraw which is the first component that not only uses the object storage but displays lines, text, rectangles, fills and so on. This is when I will finally able to run the application and deal with run-time bugs. I will probably enjoy the moment and do some performance tests on the blitting code which I might display some screenshots if I can do anything interesting like maybe a window or mockup. Note that I already have in mind how Screens Environment will look like. It will have a widget bar on the bottom of the display holding horizontal widgets. If you tap on an empty widget location, the 'add widget' dialog is displayed where you can drag widgets on and off the widget bar. This is only one of the elements which I think will not only make Screens Environment unique but usable. This feature will be available already in the first alpha. The alpha should be released around febuary but only to MSN users. I did promise this that only users that subscribed to my user list will get the alpha versions. You can add yourself via my MSN Messenger handle: zhamilton1@yahoo.co.uk Note that the release will be sent my email, so you dont have to be online to get the version. Betas will already be posted on the blog but alphas will remain in the MSN user list, so join now if it interests you. Alphas define the structure on how Screens Environment is built and its building blocks. Betas define the default skin look, animations, fine tune of the UI and other visual things. Screens Environment applications also get written throughout the beta stage. Good night, Zakai Hamilton

Old Source Code

You know what... just for kicks! Here is the old source code of version 0.1 and 0.2 that I made 3 years ago. The first versions of Screens that proved to me that it works, It was coded in Falch.net and not been touched for 3 years. I backed it up about a few months ago from my parent's computer. http://www.geocities.com/zhamilton1/Screens1.zip http://www.geocities.com/zhamilton1/Screens2.zip Enjoy! Technical stuff about v2: They work on the idea that they hold a fixed array of windows, controls and items that the API functions deal with automaticly. You can actually include the screensapi.cpp and screensapi.hpp into your project, call the functions in screensapi.hpp and it should work :D Remember to call InitAPI() before any other API function. You can modify the limits in the hpp file but beware that the limits depend on your stack size. It currently allows up to 20 windows, 100 controls and 100 items.

Welcome + Update

Hi, Prepare yourself... alot of just text... So you have arrived to this blog of text and wondering what all this jumbo mumbo is about, you have arrived to the right entry. Hi, My name is Zakai Hamilton... This project started out officially on 8 September 2002 (Yes... I started writing notes on my palm then for the project). Q: So what is Screens Environment? A: Good Question. PalmOS - Yes... the OS (not the hardware) does feel a little old in the last few years right? Feel a bit abandoned? We were promised Cobalt just to find it trashed with some future linux version which we are a bit afraid of. But what about existing devices? If you have spent over 400$ on a LifeDrive device, you want to know that your device is going to last for quite a few years. So, the Screens Environment project is designed to bring the magic back to the OS. How? By enhancing it with a nice thick layer of icing. Think of PalmOS... Its very low level, its API is low level costantly using your pointers logic and even its user interface is low level. Very bare, simple and small. It reminds me alot of DOS... a very relatively simple thing which realy got better with the applications built on top of it. Then came windows and the rest is history. I think history is repeating itself with mobile platforms. You have the bare PalmOS which is cool and edgy at the beggining but looses its edge as time goes by. So to keep it alive but still be compatible, you have two options: Emulation and 'Shutdown to DOS'. I decided to choose the second option to be compatible with PalmOS applications. So Screens Environment is like Windows 3.1? Yes... Its an operating system on top of an operating system. So what does Screens Environment offer? 1. Cooperative Multi-tasking - Just like Windows 3.1 you will able to run multiple applications at the same time and switch between them easily. 2. Window Management - You will able to move, resize, size and so on just like Windows but on your Palm. Sounds flaky? It isn't. Its not the default. The default is maximized windows, so think of window management as an extra, not a forced default. 3. Managed information - Hate that Contacts and Calander dont cooperate very well? Screens Environment has a center object store that not only can store information but can manage external information as well. You will able to make relationships between information from different data sets so changing one automaticly changes the other. This is the highlight of Screens Environment and I feel is a key to its success. These I guess are the main three key points in Screens Environment with the third one being the main key point. Managing Information is why most users have a PalmOS device in the first place and Screens Environment is designed to take that a step further. Q & A: Q: Why is Screens Environment taking so long? A: This project has grown just as I have. I am married and work at a full time job which leaves me very little time for the project but my passion for it keeps me going (plus the comments and notes I get from you users here and there). Q: How much will Screens Environment cost? A: Nothing... Its open source... Free of charge... No money required... I respect users, not credit cards. Q: How open source? A: As much as it goes. I dont care if you take every line of code, repackage it as your own and sell it. If that's what you think will bring you success, its fine by me. Really... Consider it your own personal idea. That's what Screens Environment is... a bunch of ideas merged together. So its not GPL, LGPL or anything like that. Its Free as is as Free as it gets. Q: Wheres the catch? A: Uh... There is always a catch... but why I should I tell you that ;) Q: If Screens Environment is an OS, how much will the API cost? A: Nothing just as the operating system environment will = 0$ Q: Is this like Open source where you get money by support? A: No, Support is free... email me at zhamilton1@yahoo.co.uk at any time for any help. I constantly help PalmOS developers with thier bits and pieces. Q: So what's the catch then? A: You'll just have to wait and see ;) Q: What is Screens Environment requirements? A: A Palm III and up Q: Memory requirements? A: About 256K for minimum I think Q: Will it support HiRes and HiRes+ A: Yes... I personaly have a Tugsten E so it will mostly be driven for HiRes at the beggining with HiRes+ towards the 1.0 release. Q: Where are the diagrams? A: Well... there isn't much to show at the moment... I think diagrams will be more helpfull when the project is more 'alive' on my display. OK... Thats it folks... Now the update: The plan code named "Saturn" is designed to be the first release of Screens Environment. It does have the object storage but uses it more for data store and less for API calls. While this means less flexability, it gives the ability to release Screens sooner which I think is important. Technical Whoo...hooo... follows: The major stop part at the moment is the KernelObject component. The good news is that its not far away from being coded in that there is 4 functions left before it which hopefully I should finish by the end of the week to work on getting this object storage working. I must admit that my knowledge from NDS has had a positive effect on this object storage. I actually have a working version of it working on windows CE but its NDS property and coded in C++. Screens Environment is coded in C, so it uses its own object storage implementation but the ideas and design share quite alot. I finished coding the previous components: KernelMemory, KernelArray, KernelMap, KernelCollection have been coded with KernelItem left before KernelObject. Thier names are quite straightforward. KernelMemory deals with memory allocations, KernelArray handles a memory allocation split into fixed size elements. KernelMap extends that by allowing each element to have an identifier, KernelCollection is a two dimensional array where columns have identifiers while rows are by index and finally KernelItem is a hierarchy of memory allocations. All these together are used in KernelObject to form the hierarchy and organization of objects including relationships between objects. Just to give you a quick glipse on the code, here is the header file of the kernel which I have written up to and including KernelObject. http://www.geocities.com/zhamilton1/Kernel.zip I will give out the source code of up to the KernelObject once I finish writing it. But enjoy the header file untill then. Basicly I will publish the source code for every component I finish. Note that the source code has not been checked that its correct untill I can get the drawing functions to work, so dont tell me how the code is illegal (although I have spent alot of time on writing good code without a debugger). Also note that this is my own code, so feel free to accuse me of copying ;) I know this is a lot of technical stuff, but that's all exists at the moment. It will get much more interesting once I get to the layering component which follows shortly. Thanks again for your comments, they keep this project alive, Zakai Hamilton

Choose your subject:

Hi Guys, Since Screens Environment is not going to be released any time soon unless some miracle happens and I get loads of coding time, I decided that at least my knoledge shouldn't go to waste. Screens Environment is a collection of ideas which I am trying to implement myself, but the ideas work. This is one of the reasons Screens Environment is going open-source. I dont mind if any one ripped of my ideas even without telling me (although it would be nice to tell me). Because My ideas are ideas of others merged in specific ways. So... To make this blog a bit more interesting... post in the comments some of the parts of Screens Environment you want to know... like either technical details to the bone or maybe something more abstract... like the slider... from the object storage to the UI handling to multi-threading, if you wanted to know some information about how these things are done... post me a comment on some subject you would like to know about... anything ;) I figured out how to use the blogger picture feature, so I will try to show some pictures if they help (like maybe some diagrams or quick mockups). Enjoy and waiting for subjects, Zakai Hamilton P.S. http://tamspalm.tamoggemon.com/ - Thanks Brad for the link ;)

Where is Screens History?

Here you go, A list of links to how real Screens was at least before I went deep into details only ;) These are hosted on my old web-site so remember to do Save As... Old Demos: http://www.geocities.com/zhamilton1/ScreensOS.zip

When I mean old, I mean realy old around 2002. I made them at the beggining and figured out that I wanted to go full fledged and go the way of a kernel creation which I didn't know means that I'll be late for more than 3 years for a release.

Old Screenshots collection: http://www.geocities.com/zhamilton1/MyPictures.zip

I made alot of mockups as time goes by creating new designs, changing colors adding ideas and so on. The current design has no screenshot but has a combination of a widget bar at the bottom (like this: http://www.geocities.com/zhamilton1/SL-5-15a-6.gif ) with the popup 'slider' design (like this: http://www.geocities.com/zhamilton1/SL-4-5c.bmp ). The colors are more like this: http://www.geocities.com/zhamilton1/Objects.jpg

Hopefully this should show some of you where Screens has been through and a bit of where it will go. I have quite a few good UI ideas fitted in those screenshots here and there. I played around with colors constantly... it went from blue to purple to green to white. Enjoy!

Thinking about things

You know... I have been thinking alot about what is Screens Environment's main point and my conclusion is actually the object store. Think about it... There have been and will be releases of applications that provide frameworks or launching/file manager capabilites but there still has been no application that allows you to sort & manage all your information from a single location. This includes files, appointments, databases, contacts, memos, pictures, preferences and any custom information by 3rd party plug-ins. Think about it for a second what I am trying to accomplish... One location where you will be able to view and edit your information from a single location and make references from one data to another easily. This is a hard task which requires answering of many questions and I think that so far... I have solved a great amount of them. Screens is going to be spatial browser so every item in your collection has a window with a position, size, color and so on. This experience on a small screen might sound not very usefull which is why all windows are full-screen BUT give you the ability to move them around if you want to. Yes... Its a hard thing to do and I have been going round in circles for the last 3 years refining the design again and again... but its needed to do this right. I only have one chance to do this right... so why not take my time. It could be that many of you are angry or frustrated for this vaporware while others might have some faith in me but IF I do get this project done... It will realy make a difference I feel in the PalmOS world. Well... I guess we will just have to wait...

Update - Changes

OK, The good news is that I got a full time job position at NDS. I have been working very hard for this and while Screens Environment has lost some speed because of it, I need NDS as a financial stone to give me freedom to work on Screens without worry about my financial state. I will find some more time this coming week to code the kernel components again and get this object storage yet again hopefully done and working. About the screenshots... I just dont know where to start... All the screenshots I made untill now were done pixel by pixel in MS Paint. I just have no idea where to start with my screenshot mockups. I guess you'll all just have to wait or forget about this project ... I'm sorry.

Update - Made a pre-design of the sub components

I have renamed the kernel components to the Kernel prefix instead of the Core prefix keeping the Core prefix for the API. Here is my current list of to-do components untill I get to the object component: KernelMemory - Handles memory allocations and has the platform hooks KernelArray - Manages an array of fixed size elements KernelMap - Manages an array of fixed size elements with a key identifer KernelCollection - Manages a two depth array of a combination of a Map and an Array KernelTree - Manages a hierarchy of fixed size data with a callback to handle dynamic stuff like constructors and deconstructors. KernelObject - The object component which uses all the above components. Well see how it goes...

Update

OK, Didn't get to do much coding today but I found out why Screens Environment has constantly got stuck on the object storage. It wasn't because of the object storage design that evolved continuously but rather the way I designed the code. I was trying to build a user/programmer experience without any experience before it. I think thats why most developers get stuck in bootloader progress. Its because you are trying to build something on nothing which unless you are god, is plainly impossible. I was coding lets say CoreObjectNew and driving myself nuts on why I couldn't get the code logic to work. It just mounted into lines of code with a spageti and repetative feel. This is why NDS applications work out and Screens doesnt! For NDS I am building application on top of an existing API. Here I am trying to build an API on top of another API. The problem? The API I am trying to build is too high-level on top of the other API. That is PalmOS API is too low level for my own API. So I will need to stop trying to abstract too much and actually add some 'conversion' components between the low API and my high API. I cannot build the object storage on a low API which is why it just wasn't working untill now. Problem: I was trying to make a programmer experience with nothing inbetween. Doesn't work that way... Solution: Make some components to build up to the object storage instead of the object storage being the third component in the kernel. The object storage does alot of things and if I want that code to be small and neat, I'll need to create my own low level experience just for the kernel. The kernel needs a programming interface of its own, not an application programming interface. Well see how things go... but it does explain all these times I re-wrote when I got to the middle of the object storage... everytime!

Update

Hi Guys, A took a day off my NDS job to stay home and code... code... code... And boy... its tough... I am still stuck on this #?!% Object Storage. Why you might ask? Why is this object storage killing me? Because its new and not done by any other system for mobile devices for sure. One of the key things the object storage does is stop bad pointers. Which means that if you destroy an object, it makes sure that all locations that point to the object now know that the object is destroyed instead of keeping the destroyed pointer address. This is done by having a middle-man handle between the instances and the object itself. Basicly... Its still tough and its driving me nuts that its so hard for me. NDS has been a life-saver for my ego allowing me to know that I do know how to code, so I guess it's because Screens Environment is just a tough project. I feel kinda isolated here... while I get a comment once a month on my blog... I feel in the dessert. Everyone has lost interest and signed my project as vapor-ware. All my MSN Users I dont even bother to contact anymore because it feels like no one has time for me since I just go through the same redesign-recode stage that feels like it never stops. Its funny looking back... Screens Environment is a much larger project than it was 3 years ago but still I am the only one working on it. Users come and go and now... they are all gone. About my only inspiration left is my wife and Zane (EDGE). Zane, if you are reading my blog... Thanks!

Update

Hi Guys, Not only is my PalmOS knowledge expanding but my PocketPC knowledge is now getting realy good. Just learnt about DIB Sections which is a device independent bitmap (DIB) that an application can write to directly... going to check this out next week for some drawing effects since GDI just wont cut it I guess. While I am currently coding Screens Environment for PalmOS, I am coding my NDS stuff for Windows Mobile. This means I get double exposure and learn new ways of doing things for both platforms. So things are still tagging along... About the screenshots, I hope to find time next week since I had none when I got home this week - too tired to move out of my snuggish bead I guess ;) Have a nice weekend, Zakai Hamilton

Update

Thanks to Zane, I was able to finish my first EDGE experience. This is the best game ever :D Yesterday I went to do a IQ test to become a full time employee at NDS... Hopefully I have passed. On Screens Environment issues: I spent some more time on this object storage and hopefully this build should be better than previous versions. I am going to test it more thoroughly in the coming days. About the mockups... I know I haven't updated them in quite some time... so I'll spend some time this week to create you an updated mockup of what I expect Screens Environment to look like in some way or another. So stay tuned...

Update

OK... I got to admit... EDGE (Extreme Dungeon Game Experience which I think it stands for Extreme Damn Great Experience) is realy taking up my time. I must release myself from the game to get some more coding done. You'd think that because I bought a Palm game, I wouldn't be playing it while sitting next to my desktop computer... go figure ;) Anyone who hasn't checked it out: CHECK IT OUT! www.zanegames.com For only 24.95$, its well worth it! My personal only pick! OK... enough for advertisements... Screens Environment is moving a bit slow in the last month from working extra at NDS. However my experience at NDS has been only great for Screens. I have polished my programming and learnt how to finally fix myself on ideas without constantly changing. I am now coding this week v2 of the MobileEPG UI which will only be great news when I use these ideas for Screens Environment such as alignment to any layer dynamically (realy eases those window sizing since controls can be aligned to any other window/control position in multiple ways). I believe that Screens Environment will be hitting the year 2006 because of NDS. They have realy made me able to test out my ideas without implementing the whole thing at once. I have tested my Layering engine skills and Object storage skills. Expect Screens Environment to be a real kicker - 2006! Expect some more work done this month than ever and more posts... I am asigning November as the month of work. So you might even see some graphics at the end of the month but thats realy teasing myself. Remember that Screens Environment is free and will be released open source. Requirments: Palm III and up Yes... low requirements but will support all the latest HiRes+ displays. The idea is that Screens Environment has very low dependencies to work but has a driver model to take advantage of all newer capabilities.

Update

Hi Everyone, I am on holidays at the moment... so I might find some more time to code on Screens Environment. So far... So good. Hopefully a release should be available in '06 but thats just me dreaming again. It's nice to hear about the EDGE game coming out... It shows that when a developer has persistence, he can still keep a project going (most of the time). I look at that and say to myself, that I can keep Screens going too. I believe that '06 will be a great year for PalmOS with EDGE and maybe even Screens Environment.

Update

So I finished coding the CoreObject class and its working wonderfully. Finally some code I realy like which is simple and small. It took me a few hours to write which shows that designing code is the hard part, not writing the code. I am coding 'Saturn' which is a Shell explorer (without a programmer API and without virtual object support) that will show a few of my ideas like the Icon bar. By not releasing an API, it takes off the pressure of having legacy applications when I want to code 'Safire' (which is the full Screens experience). Saturn will allow you to view databases and records as files and folders, so you can see memos as actual files in a folder which should allow a more interesting ability to handle records of different types. It would allow you to able to view your records without your application. So bitmaps are viewable, text is opened with a notepad like application and forms can be created using an IDE and so on (dont know about the last idea...). This will show of the layering system which allows for movable windows with no flickering and the module based behaviour. Stay tuned (yes... this is another lets try again post...)

Update

Oh well, NDS wont allow me to post screenshots at the moment... I guess I'll have to wait a while to show you what I have been working on. If any of you were at the IBC 2005 at Amsterdam, tell me if you saw the mobile application working on the iMate or Dell Axim. I have been doing alot of code design and writing lately, messing around with the object store. Hopefully I can get the object store finally working in code. Its design is smaller and simpler than ever but also faster. I learnt alot being around NDS Employees including alot of C++ code experience. Writing the layer design into the NDS MobileEPG was very good for Screens, since it allowed me to prove to myself that I am able to do this Screens Environment project. I also learnt the problems with my design, so I wont have those issues in Screens Environment. I guess my blog is kind of an island at the moment, however, maybe in the close future, users will flock to my blog and read this post ;) I am currently coding the Item class which is the Object class without the method capabilities. I hope to finish the Item class by the end of this week. The hardest part of Screens Environment is to agree on things. Any time I have multiple paths to choose, I start scratching my head of where to go. I used to talk alot via MSN Messanger however once users lost interest, that sort of lost its use. Oh well... Alone again...

Single Object Store

I have just been watching for over 2 hours the PDC 05 Event from the Microsoft Web Site... cool stuff this Avalon... um... Windows Presentation Foundation. Those 3D effects are realy smooth ;) But then they start with Data... This LINQ stuff might sound good but its just adding another headache for developers, not removing it. Developers have to deal with so many API's and although they are trying to add yet another single API, they are just adding another beast to the collection. There are so many data sources we deal with... from tables to file systems to the registry to file internal data and so on. What is needed is not a WinFS single store but rather an API to merge all these sources into a single design API. I dont care about that registry folders are called Keys and that registry files are called Values. Just give me Folders and Files instead of including new concepts. Here is the rant: If I write an application to use the registry but then I am told to use an INI file (so that the settings can be shared on a server). Think of the amount of not only API but logic that needs to be changed to make this work. Although they both are using the key and value design (just INI files have only one key depth), I still need to use a different API. Dont think this rant is just at windows, PalmOS does the same thing! Instead of having a single database API, I have three API's to handle! The data manager, The resource manager and the VFS manager. If I want my application to read documents on the card instead of from the internal drive, I need to recode all my calls to the data manager when they have exactly the same ideas. This is one of the reasons I have been working so hard on the Object Storage. Its not about adding meta-data but about abstracting the meta-data we already have. I want a single API with minimal changes works for both the memory manager, VFS Card, Databases, Files, Serial port, Bluetooth and the list goes on and on. Instead of calling a function like: SetDeviceID, I want to browse the IDs and select the one I want using a hierechy design. Give me Folders and Files everywhere! I want a device to be a folder, I want a document to be a folder holding the documents elements. I want a serial port to be a folder which any data I put in is sent over through the port. I want to create 5 files with data and send them all off together easily without fiddling with data buffers. This frustration is what is driving me forward with the Object Storage. I want a single abstract design which will spare me the details and allow me to do things in a 'virtual' way.

Screens is still alive (or at least its concept is)

Hi Everyone, or anyone who checks this blog for life signals, My boss is at the IBC at the moment, so I am stuck at NDS a bit bored untill he comes back and gives me lots of work to do. Untill then, I have some spare time to actually code Screens at home. I just upgraded my RAM to 512 MB which should realy help when coding in PODS because before hand I only had 256 MB and PODS was so slow. I used to use Falch.net but they want down under. So finally it will be a joy writing lines of code without my CPU having to catch up (PODS uses Java which is why it has a hefty RAM requirement). I have been doing alot of research as usual and I still (I dont know if anyone has) haven't solved the problem of the store island which is how to import/export additional meta-data that cannot be stored with the original file. Untill I solve this, I wont be able to make the object storage. So instead, I'll spend time on trying to build a design without the object storage. This means that you wont able to attach contacts to mp3 files. I realy wanted this feature... oh well... I might find a work-around or maybe with a bit of luck solve it. I have noticed quite a lack of products in the area... iSpin seems to lack updates and WinLauncher is looking a bit old as well... is there anyone working on some secret release or is just no one interested in these kind of products anymore. PalmOS seems a bit dull lately apart from selling companies back and forth and new devices here and there. About the only interesting thing I receive from the PalmOS world is Jeff Kirvin ;) If there isn't an object storage which has been the number 1 reason for the lack of Screens release, is there anything you would want instead? Please post here or email me a list of your wannabe features. I am going to start coding next week again after a break of a few months (of coding that is). There isn't any point explaining why its so hard to create an object storage (just read WinFS's problems and I share them as well) but maybe an OS without an object storage is not that bad after all.

Still going...

Sorry for the lack of posts, I have been working hard at NDS and it looks like they might keep me after all (keeping my fingers crossed). I actually used a few of my Screens ideas (like the layering system) in the NDS project and the managers are realy happy with them. Its actually been great for Screens because it allowed me to test my ideas in real code and find all the inconsistencies and just make it better. It also allow me to know that my designs are implementable and that they work. Cannot show you any screenshots because I am under NDA but I have been told that the EPG is cool! You can come to the IBC 2005 at Amsterdam (sep 8th-13th) to see the UI I made for the Mobile EPG project. It can actually run live TV now on a iMate PocketPC. I am making changes this week so it will work on the Dell X50v (because its 640x480 VGA). Here is a little document I wrote over the weekend which describes the Screens Environment Kernel. Enjoy! (5 pages long) http://www.geocities.com/zhamilton1/ScreensEnvironmentKernel.doc Tell me what you think about it...

The search for storage Part II (Editorial)

Part II: Default Consistency In part I, I talked about that the object storage needs to be simple if it wants to even be implemented, not even talking about using it. I do alot of research and here is one of the articles called "The Anti-Mac Interface" http://www.acm.org/pubs/cacm/AUG96/antimac.htm which goes over alot of issues but the one I want to focus on is consistency. While complete consistency is quite impossible if the storage is going to be useful (if it was totally consistent, there would be no such thing as links because deleting an object would always remove its data) but thier are basic rules which are needed to be kept especially in the removal area. Having removing an object in one place, removing it from another does not sound like a good idea and many times I have created a shortcut to a file instead of a copy just to find it out when I delete the original. Ways to solve this is by using references where removing the last reference, removes the actual object. The problem with this is that current reference designs are very limited where links are either included in the reference count or not. WinFS is built this way and its not even released yet. The reason this is a problem is just a plain idea of categories. If I put references to a document in multiple categories and I want to delete the document, I dont want to have to remove it manually from all categories. A way to solve this is by allowing objects to list thier references and then just remove all references, but then you have lost the whole idea of references in the first place which is to allow data to exist in multiple locations shared. So you need a way to have references to references where you can have basiclly a tree of reference points so deleting the last reference of the original object will delete all the child references. The problem with this is that its not very consistent. Why should it be? That is exactly what the Anti-Mac article talks about. These known things like "the user should be in control" or "Metaphors" are what cause problems with this design. If I reference to a reference which references to a reference which references data, doesn't this sound a bit complex. Well yes... but I dont normally need this depth of referencing anyway but it would be useful if the time came up. How has this got to do with consistency? Not much... just kidding... The thing to understand here is that sometimes consistency can limit you. I am not saying that things like the OK & Cancel buttons should have different positions in different dialogs, I am saying that consistency should be a default, not a forcing rule. Think of it that consistency is the way a bar of metal should be, straight and strong but bendable if needed to be. This comes to the first word of the title of this editorial which is Defaults. Defaults are a very powerful feature. It allows a normal user to use an application or system and feel that its small and comfortable but if he wants he can unlock the power of the system when he needs that power. Users dont like modifying techincal options very much. They might do some tweaking for performance sake but most of the time the options you want to modify have a look & feel written all over them. These should be the default options displayed consistently throughout anything. Dont tell me I need to enter a port number if you know the one to use in the first place. I might want to use a different one, but since 'I might' is less important than 'I mostly use', the default should be non-technical options which make changes in the way I work, not in the way the computer works. This design should be applied to the file system as well. I dont need to care about providing a 'save' name to every document just because the file system is dependent on it. Names should be optional. If you are dependent on some unique name, create one yourself and allow the user to change it LATER IF he wants to. The same goes with the documents location. Dont force the user to search for a location if you know the most common one to use. No, Its not the last used location because probably I chose a different location because I made an expection, not because I wanted to make it the default next time I save a document. It drives me nuts when I save a new document on a floppy but next time I save another new document, it shows me the floppy to save it in! Floppy is a temporary storage and you dont create multiple documents just to save them to the floppy and if that is the matter, allow the user to jump to the last used location but the default should still be 'My Documents' or such. Defaults can be a great factor if a user is happy or not. Before you prepare to make a user make a decision or choose an option, think about if it is realy and totally neccessery to ask him. Its like these installation wizards which most of the time you press next, next, next, next, next and another 7 times next just to install a product where it should show you a single finish button with a great button called 'Options' on the side. Now wouldn't that cut the need for a wizard just to install applications.

The search for storage Part I (Editorial)

Storage... The hot topic which is nearly always vaporized into the future but never quite gets into the present. But what's so hard? It sound simple doesn't it? Why is it that so many object storages never get delivered (WinFS, Screens Object Storage, Cairo Object Store, Gnome Storage...)? The file system was a very basic design where it did x and y and nothing else. It had folders and files with basic meta-data and although you had NTFS and BeOS with extra attributes, they still were a file system. That is the success of the file system - that its simple. It might not be what people want, but its simple enough to explain and implement. Object storages on the other hand try to be the 'perfect file system' and promise to solve every file system problem you have like file location independent, description of file contents, search, filter, sort, slice and dice your information in any way you want where ever you are. And this search for perfection sadly never goes anywhere because nothing is perfect and designs that sound good not always work out when you need to write the implementation. You suddenly find huge performance bottlenecks, problems with compatibility and scalability over unknown systems and you get frustrated and in the end give up or push the date of release further and further away. No one wants to be the middle step between the file system and the perfect storage because of fear of obsolete and then we are still stuck after 30-40 years with the same basic file tree structure with basic meta-data. But is this really bad? Does the actual file padigram need to change? This editorial checks a bit of this out. Its too long for all of it, so hopefully I will break it down into multiple parts: Part I: Simplicity One of the basic things we first do with data is store it somewhere. So where do we store it? Well... in a file system we store it under a folder. But wait... what if I want to store it under multiple folders? That would be cool now, wouldn't it? The ability for your files to be location independent, allowing you to access your files from multiple locations is like being able to get your money from any bank. Sound wonderful, but then what's the problem? The problem is quite simple. Computers are very fixed, they do X and Y and if X fails, you must know how to handle it and the same with if Y fails, you must know what to do with it. So while storing a file in multiple locations might be handy for a user but if I want to open a document, where do I open it from? If I delete the document, does it delete it from a specific location or from all locations. While a user can decide on this, computers cannot. Computers do linear actions and cannot decide by themselves. You must tell them where to look. So, lets take the bank example... Where is your money REALLY stored? In your specific one local bank you have your account in. The other banks just reference your money and transfer it over to them but your whole account exists only in one location in your single local bank. Lets apply this to the file system... Your documents exist under a single location but you can reference them anywhere. Sound familiar? Shortcuts, Aliases, Hard links, Soft links are all solutions to referencing your data. So where is the problem? Well all these solutions fail on certain areas and transparency is one of them. There should be no real difference between using a reference and the original apart from three actions: copy, move and delete (move is actually copy to new and delete old). Apart from those actions, everything else from open to properties should work on the original. That sounds good, and its implementation is not that hard to implement since you are basically mapping all methods apart from copy, move and delete to be passed on to the original object. But... Lets take this a step further... If I have a document in a specific location, I might want to associate with it location specific information. For example: if I have music file in one playlist, I might want it to be listed in a different position then in another playlist and since the position is stored in meta-data, what to do? Well... you make the reference become a derivation from the original, so the reference shows the original plus any changes by the reference. So the reference becomes the original+reference. So now what's the problem? Well... if I add data to the reference, its not going to modify the original and then what's the point of the reference in the first place. This just shows you how a simple modification can kill the entire idea and that's one of the problems we face when creating the perfect system. We are not perfect people and therefore cannot understand perfect ideas. We like simple solutions, not complex ones and so far, these proposed object storage systems have been more complex and full-featured than simple and basically become a bloated design which grows until you just cant understand what's its advantage in the first place. Tune in for the next part when I can get round to writing it...

The bad and the good

Hi Everyone, This is already my second week in my new job as a programmer in NDS (www.nds.com). I am working on a project there around to the end of september in which my they will consider if I will continue in NDS or not. I am moving to my own apartment (I am currently renting) next year hopefully and I need to save up some cash. Instead of posting 'give me money' links, I decided to get an extra job, so I now work two jobs: NDS and the escort of 'special' children which should bring me a decent salary for a while. So whats going to happen with Screens? Well, yes, it will be postponed a bit, I dont have much choice in the matter since I am working nearly all day (my escort job starts at 6:30 AM!) but I am trying realy hard to keep Screens afloat. But I have talked with some NDS people about Screens and they are going to try to help me pull Screens from a small one man project to a sponsored project. So there might be help after all. I know many of you feel decieved, but I prefer to face you with the facts then just disappear. Life being married is wonderful but its great responsability and had to be my highest priority hence the need to earn more money to get an appartment than working on Screens which brings me zero income (I know that its an investment). If you have noticed, I have hardly even been online on my computer since mostly I have been working on my laptop (that I got from NDS). When you have seen me online, it was probably my wife who is finishing university on the 17th of july. The bottom line is that I am trying realy hard to juggle all my jobs together, so just understand that reality does bite a bit and our plans most of the time dont work out as planned. I could say, well... I have been promising Screens for 3 years and its been totally vaporware untill now, so therefore I should stop... but then I feel it would be a waste of your time. If I do ever release Screens, it will make all your efforts suddenly worth while.

Update - Great progress

After nights of bug finding, I finally solved the bugs in CoreQuery and it now works. I have also finished coding CoreData. This means I now have the object storage components working and I can allocate and manipulate data objects. Next components to code: CoreMeta - Deals with meta-data of data CoreType - Deals with types (like classes) and syncronization with instances CoreFolder - Provides a generic folder object type CoreFile - Provides a generic file object type CoreProperty - Provides a way to handle properties of an object (meta data) I should finish all these by the end of the week... wish me luck! So far, I am on schedule for the demo. If I see myself late on schedule, I have devised which components will get cut for the demo and which wont. So the original plan is to get all the original components to be in the demo, but if time is short, the demo will use quick implementations to get the demo out of the door a bit like the first Screens version. The demo depending on progress will hopefully look like the UI I have planned for Screens. You will see a few new ideas that have not been implemented in an OS before like my icon slider and multi-mode button. Hopefully I can get those visual effects working as well for the demo but that is pushing it. The demo will use a 320x320 resolution with 16bit color. It wont support HiRes+ because I think the energy should be spent on the insides of the demo and not its resolution capabilities (but it will support landscape/portrait). We will see how time works for me.

Update - Changes

Hi Everyone, What a week... I was stuck untill yesterday on a last function which is to remove data objects but I have solved the problem and hope to finish coding it by monday. Screens is moving along however I have decided to push the multi-threading and module support to after the demo. The demo will be a UI based on the data object storage which will be a launcher. It will launch PalmOS applications utilizing the object storage, so the demo will be basicly a small launcher. The idea is to show you that Screens realy exists and will allow me to be able to test the multi-threading and module support more easily. The demo should be finished before the end of july. I start working on the type system this week and should finish the basic types by the end of next week. Note that the API wont be present in the demo so you wont able to write applications yet for it but the demo should give you a general idea but not how Screens will finally look. The demo will use 16bit color on a 320x320 resolution and will contain an initial design of Screens.

CoreData nearly finished

I have already coded half of CoreData and should finish by tuesday. Things are going well... After CoreData I have the multi-threading components. I already have code which works on how to do the thread switching but I dont know the speed but it should be fast, not as fast as normal thread switching but should be fast enough. I will do tests on the components as soon as I finish coding them. Note that the kernel is only for developers, I will work soon after the release of the kernel on the UI module which deals with the graphic layers, input and window manager.

Why should I use the kernel API?

So the kernel will be released soon but it wont have the user interface APIs, so why should you as a developer even consider the kernel API's? The kernel provides two key elements: The object storage and the thread functionality which are basicly interconnected. As a developer one of the key things we do is store data. This could be a document, temporary data such as proccessing or any data you manipulate with your application. With PalmOS you currently have four options: Dynamic Memory, Feature Memory, Records and Resources. All these API's are very low level and wont do much more than give you chunks of memory and allow you to read/write to them and resize them. Resources do allow you to tag each chunk with resource and typeIDs but nothing more. Screens Object storage provides you with the ability to store data in its structured form without having to parse it in into structures to manipulate it. Each object can be based on multiple types which are like classes if you are used to C++/# or Java programming. You get basicly most of the advantages of object oriented languages into C but Objects are persistent untill you remove them so you dont need to revert to byte streams when you want persistent storage. The multi-threading APIs allow you to split your code into multiple functions that run simutaniously. This is not pre-emptive multi-threading, its cooperative however you dont need to specify yield points because any Screens API call can yield, so its easier to code than cooperative but is not as robust as with pre-emptive multi-threading. Data comes in many forms and I feel that the object storage will satisfy your needs if you check it out. Because you can do the Screens API calls in your current PalmOS applications, its easy to improve your existing application instead of rewriting it. Remember that the kernel is free to use in your products without licencing and that there will be alot of documentation available and email support to help you with integration.

Update

Screens is realy moving forward... Here are the list of changes: 1 . CoreList has been canceled since it wasn't going to serve any other components in any way. 2. CoreObject has been renamed to CoreData because it basicly provides only the data storage in which the methods are built on top of. The public developer API will use CoreObject instead of CoreData (CoreData is a private kernel component). I should have CoreData finished by tuesday. 3. The kernel release data is 8th september 2005. The kernel includes the object storage and the multi-threading API's. This is to start programmers in the programming style and getting programmers to start coding modules like the bluetooth and network stack while I focus on the graphic layering and window manager modules. 4. Betas will be released before hand as soon as I can finish the type components. They will be tested and will be released for looking at and evaluating the API so I can modify it based on developers requests. 5. Once the kernel is released, any developer can start using the API's in his existing PalmOS application. He just needs to include the kernel prc on the device and call the API wrappers (include the header and source files) and thats it. No linking, no libraries. Just include the files, call the wrappers and include the kernel prc file on the target device. The kernel is open-source but the betas will be closed untill the final release (september). 6. The kernel is only usefull for developers. The shell experience will be released hopefully by the end of the year but wont be free. Only the kernel and other API modules are open source and free, the launcher and shell will be commercial.

Finished coding CoreItem

Yes... its happening... I finished coding CoreItem apart from CoreItemAlign but since aligning is not needed at the moment (only at the end of the kernel) I wont code it now. But its not a deciding factor and not complex so dont worry. Next week: CoreList & CoreObject CoreList is a very small component that uses an Item created by CoreItem and allows to add or remove structures or data of the same size and retrieve them. Its how CoreObject maintains its list of children for example. CoreObject is one of the largest components but most of it is very easy to code since its based on the functionality that CoreMemory and CoreItem gives me. We are getting there... So Far... So good!

Nearly finished coding CoreItem

I have three functions left: CoreItemNew CoreItemResize CoreItemAlign They are fairly simple with the new design but they have multiple steps so they are longer than the other functions. But dont worry... its not something I cannot handle. I should have CoreItem finished coding by Monday. Then I will be coding CoreObject. You will now see how the coding goes full speed ahead.

PalmOS will survive

First of all, I would like to thank Jeff Kirvin for his latest 1src podcast: http://www.1src.com/headlines/show/001089.html

I think that Jeff is doing a great job and getting people to know about what the current state programmers are going through. They are having a hard time and someone needs to do something about it.

My post over at SoloMedia about PalmOne's ignorance of programmers and users and my solution for it (which as usual has something to do with Screens): http://www.solomedia.org/forums/viewtopic.php?p=2130#2130

Go and vote which components you find hard to code for at my 1src thread: http://www.1src.com/forums/showthread.php?t=89575

I think Screens is finally getting its purpose more clearly told. I am sad that this is the case for developers but it will be even a better reason for them to move to the Screens API's once I release it since its designed to solve the exact problems they are currently having with PalmSource and because its free I dont see the problem of programmers jumping in. I am working very hard... I have pinpointed the design and coding as we speak the basic object storage. My wife will be off her university in exactly another month in which she will help me with the project (I have been waiting for this moment). She is very talented (but she doesnt believe that) and I realy think she will able to boost Screens forward. So... the hour of Screens is at hand and the question is will I be able to take advantage of the moment... Hopefully... Wanna help me? Chat with me via my MSN Messenger group or via any thread you want... just send me the link (Via my MSN account, my email at zhamilton1@yahoo.co.uk or give a PM at 1src, my user name is zhamilton1, or just post it here.) I wont to get involved in any way I can to understand what developers want and need. Want the API to be easy in a certain area, tell me which area... give me your coding needs... let me find a solution for you... anything... In the comming days I will try and talk about Screens in any place I can find... if you have any links to thread locations to talk about Screens... tell me please I realy want this project to work and I think now is the criticial time I have been waiting for... the right time to let Screens out to the world.

Update - Going forward

Hi Everyone, The 1src chat gave me alot of insight and I have decided and designed changes in how the kernel will be coded faster. First of all, to my understanding, developers are realy having a hard time coding for garnet and therefore I feel that its more important providing a platform for developers than users at the moment. However dont worry, users are also high priority, its just that I think developers need a helping hand. To get the kernel out the door, I have decided to stop redesiging constantly to make Screens better and focus more about getting Screens out the door. I always wanted to create the best system I could and I think I am at the stage where cutting corners does not actually mean a less product. The changes are simple: The API stays a great design while the first implementation will be done as a quick and dirty solution which will in the future be changed. This way I can get developers coding via the API while I optimize the internals AFTER Screens is released. Techinical changes: (Screens is coded with C) I have already finished the quick and dirty implementation for CoreMemory, CoreItem and CoreObject. CoreItem basicly allocates handles in a single array at the beggining of the store and pushes allocations to the end when it resizes the array forward. This is easy to implement and still provides a single fixed handle to any allocation. Each handle is 32bit where 24bit is the index (which means that it allows up to 16 million allocations) and the remaining 8bit is used for a handle count to know if the handle is used by a different allocation. Here is the structure for a CoreItem header: typedef struct CoreItemHeader { Int32 Size; UInt32 Handle; } CoreItemHeader; If the size is less than 0 then the allocation is free while more than 0 then the allocation is used. This allows for allocations to be one after each other instead of using prev/next pointers. To simplify the design, when resizing allocations, its moves them to the end of the allocation stack instead of trying to resize it locally. While this does take a bit longer, its easier to implement and has no changes on the API. The handle is used to update its new address if it is moved. To regain free space, aligning is done where it aligns all allocations left overwriting any free allocations leaving the free space always at the end. The aliging is done automaticly as needed. An object is also just the following header in an item allocation: typedef struct CoreObjectHeader { CoreID Name; CoreObject Owner; CoreList Members; CoreItem Data; UInt32 Flags; } CoreObjectHeader; The name is a CoreID which is a 128bit identifier for unique object labeling. Each object has an owner and members. Members is a list of object handles and can include any objects. If an object is not owned then it is a link. The data handle allows for multiple objects to point to the same data but can use it in different modes like copy & write where writing to the shared data makes a copy and writes to the copy instead. Here are the list of flags: 0x01 - Copy on write (explained before) 0x02 - Owner of data (defines that the object deletes the data when the object is deleted) 0x04 - Hidden (the object is not listed when enumerating usefull for structuring) 0x08 - System (defines that the object is needed for the system to run and should not be removed) Thats the object design... simple but usefull. Its not this layer in which developers interact with but rather with a foundation of components which provide dynamic methods on object, properties, syncronization and type inheritence. So thats a summary of the new design which I am going to implement. My priority now is to get Screens out as fast as possible not to add more features or make Screens more efficient.

User benefits

I have many times talked about the advantages of Screens for developers such as a consistent data model and easy multi-threading design but I haven't talked much about what Screens means for users. Well this is a chain reaction in that if its easier for developers to code applications, there is a better chance for them to code better applications. But Screens is about more than that: Users are becoming more and more dependent on thier devices and as such require reliability. Currently if you forget to save your document even on a PalmOS device, its changes are lost. In Screens this cannot happen because even if you are editing a remote document, the changes are still stored locally. You do not have to fear that if an application dies, because any data it holds still stays consistent. Mobile users want to get to things fast and not have to wait for applications to load thier resources. Screens allows users to have as many applications as they want open and switch between them quickly and easily. This is done by automaticly switching applications resources into memory as needed. Even if a soft-reset or you close Screens to run another PalmOS app and return to Screens, it stays exactly the same way you left it... windows, controls and all. Users want Security, Screens will allow to encrypt objects by the user, so unless you log-in via your user profile, the files will stay encrypted. Decryption is done on the fly so there is no need to decrypt all objects, rather only the object you use. Because Screens is multi-tasking, it can decrypt your objects while still allowing you to work. Users normally work on a single task but sometimes they want to branch out to multiple tasks. Current systems are either single tasked like PalmOS, Windows Mobile and Symbian or multi-tasked like Windows, MacOS and Linux. The problem with single tasked OS's is that you are limited to only a single task at a time while the problem with multi-tasking OS's is that you are forced to be multi-tasked and even if you are only using a single task, it does not mean it will use the entire display surface. Screens solves this by its default being a single task design so you only have one document window displayed on-screen but allows you to drag its title to detach it from the single document model and allow you to move it around. This means that normally you deal with a single task but if you want to put two documents side by side, just drag thier titles to each side of the display and they will align themselves automaticly. These features are not used by any other operating system but provide the ability to 'have the power when YOU want it'. Screens goes further... When you are dealing with a document, you can delete the document even if it is open. Screens is smart enough to close the document window before deleting the document file. You can also rename, move or copy a document even when it is open. You dont need to close it and activate the file browser just to rename the document. With single and even multi-tasked systems you still have modes where you are limited to a certain functionality. Screens has a free modeless design where even when the Open dialog is displayed, you can still edit the document that is currently open. If you close the Open dialog and re-open it, it is shown exactly the same contents, so closing dialogs is usefull not just discarding. If you see the Delete warning, you can always edit your document, duplicate it and then click yes to delete the original. This allows you to start tasks when you remember them even if you only want to carry them out later on. Screens doesnt use scrollbars... it rather uses 'user context in the center' design where the center position is the active position and everything around it is scrolling. So for example: a list control that displays 9 items, the 5th item is the active item. Tap any item apart from the 5th item and it will scroll that item to be the 5th item. This makes scrolling more dependent instead of just a static bar which you drag up and down. Some cellphones use this design in thier menu systems, I am just using it interface wide. While this does mean extra taps sometimes, its more work flow oriented - taps is not what matters, its the work flow that matters. These are just a few of the ideas that Screens environment will give users to finally give them power to take advantage of thier device. The zen of computers is not dumbing down interfaces but rather making powerful features simple. Its always easy to remove elements, the question is can you make elements more efficent.

my 1src chat summary

This morning was an exellent chat... I learnt alot from the users... basicly everyone wants Screens out already (so do I) and most think that PalmOS and PalmSource just are not exiting anymore. So... what I am going to do about it? Well... I am going to put a bit more effort in finishing this kernel since thats the hard part of this entire project. So what can users help me with? Chat, Chat, Chat with me through my MSN user, through comments on the posts here... any questions technical or practical are helpfull. So what can developers help me with? There are many features that I wont be coding for Screens but someone else can code like the bluetooth driver, the network driver, the IR driver, the alpha blending driver and so on. When I finish the kernel and create my web-site I will post the API headers which all any developer needs to do is code the internals of the modules. He doesnt even need to send me the code, just the prc module. There will be many device specific features like the Sony Hi-Res which I wont be coding for either but any developer can create a module for. Thats the whole idea of Screens, its a community of developers and users which make small contributions via modules without exposing thier work. So let me just refresh to you that Screens will work on a Palm III and anything above it. The device specific features are implemented via add-on modules so for example sound is implemented through a sound driver for OS5 devices. I realy feel that the kernel will be out by the end of the year. I am further in code than I was ever before, so I think of that a sign that I am into the good object storage now. I should finish CoreItem any moment now and then go on to CoreObject. Note that all these components are already tested, so there are no suprises there.

The object user experience

I get alot of questions of how will the object storage affect the user experience. If anything is an object will users have to sort the properties of a file, will they even see the properties of a file as an object? Will documents be browseable? Will appointments have folders that hold the address fields? and so on... Hopefully this post will explain and answer these questions: First of all... the user and developer experience are different. Users use the UI while developers use the API. The user experience shows folders and files much like any file system does. It just adds many more types of 'files' a user will see like appointment and contact files but they still feel like a file that holds data. Only that it holds structure and data, not just a stream of bytes. Think of a file like a zip file... it holds folders and files inside it only each file can also hold other folders and files in it. Users see a contact file... they can delete it, sort it, filter it and do anything you would expect to do with a file however the developer using the API can dig deep into the contact file to view its properties, members, addresses, relationships with appointments and so on. So only objects which are self-holding and that users use like documents, email, PIM objects, devices, drives, folders and normal files are viewable by the user. All the rest are handled by developers and are visible either through specific UI's like the Properties view or used internally for the developers use. So for a user, there are folders which organize objects. For the developer anything is an object which can hold data (or share it) and hold other objects. So to the user it feels like a normal file system while to a developer its a data storage. Even applications appear to the user as a single object while to the developer - settings are stored inside of it including code and resources the application needs. If a user copies an object like a document... it copies anything in the document including embedded documents. So the user who is used to a normal file system continues to get the same feeling. Relationships with other objects are not copied, but still are referenced. If you move a document to another system, all its files are valid but its external references are invalid and removed unless you make them re-searchable by providing keywords or some other way to find thier new relationships on the new system. So you could make a file relate to a contact by its name so that when you move the file to another system, it relinks the contact by finding it by its name. This means moving objects between systems still remains intact. When you export an object, it includes all the contents of the object in a single file so you can move it between systems even over systems that dont understand the object format. But what about Search? Well... because it is an object storage after all... finding objects of the same type are instant since they are referenced by thier class (so the class can update its instances dynamically). Filtering, Sorting are all user interface issues, not object storage issues. And if you are searching lets say by Name, it returns not the Name object itself but a parent 'user-viewable' object in the results. So searching for a contact name, does not return the name property but the contact file object. Just like you can share object data between objects, so can you share objects between objects. This allows one object to appear in multiple places where only if the object exists in no locations, is the object removed from storage. But from the developers point of view, each object has only a single owner so while objects can appear in multiple locations, its still only owned by a single object. What does this ownership do? Its a spine for the object which defines its true location. When a user copies an object, it duplicates the contents of that object to the target location. If a user shares an object, only its link is copied, not the contents of that object. If the user deletes an object, it only deletes the link. If an object has no owners then it is removed from the system along with all its children (unless they are shared). This removes the need for shortcuts/shadows/aliases/soft-links but still gives the functionality of allowing to access an object from multiple locations. Note that you can always find all the locations an object is shared by to remove it from all those locations. Hopefully this should answer some of your questions about the object storage and its user experience.

Update - Started coding CoreItem

OK, I have started to code CoreItem and so far this is the easiest and simplest implementation I have coded so far for CoreItem. Hopefully I will finish it by the end of next week. I have increased the overhead of memory allocations from 12 to 14 bytes so that the size of an allocation can be up to 2GB. Note that this size is only in the implementation of storing objects internally and that external streams can be up to 4GB (32bit address space). The advantage of CoreItem is that it provides a fixed handle for any allocation which does not change even if the allocation moves around the storage stream. While I am coding this code for a Windows Console, only CoreStream needs to be recoded for the entire base object storage to work on PalmOS or any other OS. Although all meta-data and documents will be stored in the object storage itself, stream based objects like multimedia will be external files encapsulated as objects. So to the developer or user there is no difference but internally there is a difference which is the whole advantage of using dynamic methods on objects to overload default functionality.

Update - CoreMem coded

OK, So I finished coding CoreMem apart from the functions CoreMemResize and CoreMemAlign which are dependent on the CoreItem functions which I will be coding next week. This are going well at the moment... So far... So good... No problems in the object storage design Hopefully (as usual) this will be the last time I need to code these components.

Update - The memory component design is ready to be coded

So, I have finished designing the memory component, so I plan to code it in the next few days. Its faster, simpler and much much smaller overhead per allocation - 12 bytes! Why does it make a difference? Useless on a few allocations but when an average system will have no less than a few thousand allocations, those little overheads can make a difference. Just to give you an idea of the optimization I made in the design: it was around 80 bytes overhead before hand. But optimization was not the reason the memory component was re-coded but rather to make it more easier managed and easier to align allocations. Once I finish coding it, I will post an editorial on how it works which is quite simple but cool. But as usual, there might be something I missed, so I might have to get back to the drawing board. Wish me luck!

Update - Code untill I hit the wall

So... I am trying to code the kernel again however this time I am coding it as a windows console app first. Why? Because its more light-wait to test, the code is cross platform (so I make a few changes and it works on PalmOS or PocketPC) and I can print debug output or comments much easily. It also takes less memory on my limited 256 MB PC. The platform specific content is in a #define per platform so just define PLATFORM_WINDOWS for Windows or PLATFORM_PALMOS for PalmOS or PLATFORM_WINMOBILE for Windows Mobile. OK... Here is some more technical information: Applications can not only be launched by the kernel threads but can also be made to be launched by PalmOS directly. For example, the Screens Environment distribution is a normal module which can be launched by a normal PalmOS Launcher and it then calls the kernel. So the kernel is mostly the first sub-launch. This is how Screens will evolve at the beggining... PalmOS Applications will call the Screens API which will call the kernel. This can allow any PalmOS application to use the advantages of Screens without having to evolve to the programming model of ScreensOS. The idea is that Screens native modules can be launched by any Screens native or not-native module/application however non-native applications cannot be called by the kernel if they are not the active PalmOS application because sub-launches lack globals. You can solve this by allocating your own global space but then you have to save the globals to the thread and restore them each launch which can realy be slow. Screens kernel will be released open-source for multiple platforms (starting with PalmOS) but then I will create extra modules such as the type system and the user interface which will also be open-source. So how will I earn a bit of revenue at the beggining? I will create an MS-Paint like paint application which uses the kernel and other modules as its back-bone. The app will probably cost around 15$ and will feature all the MSPaint features like a thumbnail movable window, nearly unlimited zoom, easy color pallete usage and a pluggable design for adding effects, formats and brushes. This will give programmers and users the advantage of using Screens as an API. The advantage is when Screens will be finally released in its full environment, all these applications that use the Screens API (and either dont use globals or allocate them for them selves) will be able to run inside the Screens environment directly.

Update

As you can see I am writing alot of information in editorials lately just to give you another slice of what Screens has in the kernel core. I figured out how modules will interact with the kernel using FtrGet and SysAppLaunch which are the only two PalmOS functions used by user modules. system modules can use any PalmOS functions to implement functionality for other user modules to use. The idea is that system modules are device dependent while user modules are device independent. Think of system modules like drivers. There are still a few issues on how to actually store objects in a database which I hope to solve soon (as usual). The issues are like to do I use the database like a file stream where each record holds data of a fixed size or does each record represent an item. Hopefully I will be able to talk with some of the MSN friends in my Screens group to get some answers. The object storage is evolving very nicely and so far I am very proud of it.

Synchronization (Editorial)

Synchronization is a great feature in the object storage. Its how types work, how extensions work and many more features. First lets see what it could be used for: 1. You will be able to use synchronization to view a workspace on your device display and on your desktop easily even though the desktop has a different resolution. This is like VNC however Screens sends the actual drawing primitives instead of bitmaps, so its much easier to deal with. You will also be able to do separate log-ins to your device. Here is the vision: You are writing your document on your handheld and you go to a internet cafe, via the web, you log into your device via Wifi and continue writing your document on the nice 1024x768 flat screen monitor. Then you just log-out and continue writing the document on your handheld. It allows turning internet cafes into terminals. Think how cool that would be! 2. You will be able to track changes and work with a friend via Bluetooth on the same document. You make a change, and he sees the change. He makes a change, you see the change. You could also make team changes and decide which team members can modify the document, which can only read the document or which can make changes only to a copy so if they make a change, its not making a change on the original document, but rather on a copy. 3. You will be able to specify web-pages which synchronize locally so you can view them on your device even when offline. But you can take it a step further and specify to synchronize only when the connection is not in use, so it does not slow down your normal browsing. 4. You will able to synchronize playlists or collections of files to your device depending on appointments. So you can make an appointment repeated monthly which shuffles and downloads 80MB of your music on to your device, swapping the existing files apart from your favorite songs which stay on the device until you decide to let them swap as well. You will be able to specify that a presentation should be on your device a day before a business meeting and that it can be removed a day after the meeting. These are just ideas of how flexible syncronization could be used for. How does it work? Simple... every object which its data changes or its structure changes, an update message bubbles up to the root object allowing any parent object on the way to handle the method. This is how types work - Since all types are under the 'Types' object, any changes to any type bubbles up the update message which the 'Types' object handles and syncronizes the change with the type instances. If data is shared by multiple objects, they all get an update message rising up to the root object letting any parent handle the change via a method.

Why is Screens needed anyway?

Many times I get this question... why will Screens help me? Well... I now found out the hard way why Screens is needed for developers: API The PalmOS API is very low level, you deal with pointers, allocation, database locking, bit manipulations and everything is call this first then this or else... booom I am currently writing a normal PalmOS app for someone and when I found myself searching for how to handle the resolution change not even control moving and modifying... just knowing when changing into portrait/landscape mode and when the DIA is open or closed took me a long time raging over google, PalmSource and PalmOne for how to do it. These are simple things which should exist in ANY application... I am not talking about the Serial manager or bluetooth, I am talking about a frickin display basic manipulation. Sony... they realy stabbed everyone for buying thier devices by shutting down thier developer web site so no one can make apps for thier devices anymore. Smart move, Sony! And to try and figure out how to handle the T3 slider open/close, I still dont know how! Screens is going to have a very generic API without trying to be device specific. Its more like windows where you have a a generic model and have drivers to do the actual implementation. In Screens, you will write your application once, and it will automaticly use the driver its meant to use on each device. So a T3 might have one driver while the Sony device might have another driver. But the API and the applications stay the same. You think that the whole idea of an OS is to bridge between hardware, PalmOS sucks at doing that. There is a need for someone to take this forward and I dont expect PalmSource to do it, because it wont be compatible with old PalmOS versions! Which is why someone like me or maybe someone else will make a convenient, simple to use, flexible and consistent and device independent API which developers can use once on the simulator without worrying about testing on all devices.

Semi Pre-emptive Multithreading

Screens has a semi pre-emptive multi-threading scheduler. What is the difference? Single threading: PalmOS is actually pre-emptive but you can only have one application which has only one thread running. You cannot create threads however you can use the existing threads like the multimedia thread and the serial manager thread. Cooperative multi-threading: Windows 3.1 and MacOS up to version 9 are cooperative which means that you can have threads but they each thread must have points where it gives up (yields) control to the scheduler so that the next thread can be continued. This means that threads must call a specific yeild function at many intervals or otherwise it can starve the other threads in the system for CPU time. pre-emptive multi-threading: Windows 9x/XP/2003 and MacOS X are pre-emptive which means that you can have threads but the system forcefully yields threads instead of threads deciding when they want to share CPU time with other threads. semi pre-emptive multi-threading: Screens is semi pre-emptive which while in reality its cooperative in that the thread does the yielding, any API call can yield so as long as threads call API calls, the system can switch between threads. This gives the advantages of pre-emptive in that you dont need to structure your thread around yielding points but a simple for loop can still freeze the system. Why use the last method? Screens runs on top of PalmOS and it does not have access to the multi-threading API (only the system apps can). There are a few advantages of using semi pre-emptive multi-threading: 1. The threading actually happens in the module, so the threading is language and implementation independent. 2. You dont need to implement locks, semaphores or mutexes or deal with interupt problems. Screens does not use these. Because modules dont have dynamic memory, the sharable memory is the object storage and the object storage does the blocking of threads for you so that no two threads will read/write to the same object. So what is actually happening? The kernel (Screens Core) loops between threads depending on thier priority. When the kernel resumes a thread, it just calls the threads code application (prc file). The application then restores its stack from the object storage using DmFindDatabase and SysAppLaunch to do kernel API calls and jumps to the stack using ErrSetJump and ErrLongJump. When you do a kernel API call, it returns non 0 if the thread needs to save its stack and close down. Note that example code is given so developers dont need to do this, wrappers do it for them. Kernel calls are done using SysAppLaunch sub launching however most of the time function wrappers you call are doing a combination of kernel calls and might be doing a context switch. Developers do not have to worry about the swithing mecanism, just do API calls as normal, the example code does the rest. While calling a PalmOS function does block the kernel untill the function ends, the Screens API calls can yield to the kernel at any time.

The object storage - continued

The object storage has a few depths: 1. The data core - This provides the actual interface and implementation between the storage of the bytes (the PalmOS database or file stream) and the actual object design. It supports the ideas of a tree structure of objects and links, objects that point to data and data which points to multiple items. This indirection does mean that its slower but the flexability is just huge and allows to change the implementation in the future. 2. The dynamic core - This provides the thread and method functionality which adds the ability to connect code to data through methods. Each object can have methods which define functionality for it. From predefined methods like Open, Close, Read, Write, Move, Copy, Link and so on to custom methods like the window class has the Draw method. The programmers API does method calls, not direct function calls to the underlying data core. 3. Types - data has a common style which is known as the data type like windows, controls, layers, appointments, contacts, strings, numbers, bitmaps, resources, users and so on. Each type is an object just like any other object but it has methods which allow to syncronize between the type and its instances. So adding a new property to a type, adds the property to all instances. These methods are not defined per type but rather in the generic 'type' object. All types exist under the 'type' object so they automaticly get syncronization. So adding a opacity property to the window type means that all windows will have the opacity property and they also get the default value specified by the window type in which each window can override. The object storage is very simple and flexible which means that it can be used for nearly anything. Screens will be importing/exporting objects as XML so you will be able to export your document from Screens and move it to any OS and read it. I see the power in this and I am very happy with it. No, its not implemented yet and its taken me 3 years to get to this but the advantages I see with this design are just so worth it. As time goes by, you will see why.

The object storage (Editorial)

OK, This project is taking alot of time on just the object storage. Why not just make a plain file system (folder+file) and get Screens out the door? This is a constant question I have got and the problem is that people dont understand why this single component is the most important in this project. Data - Its all about Data. Computers manipulate data thats all. You have different storages like RAM, Hard drive, Disk-On keys, SD Cards which hold data. The computer or device manipulates that data either by reading or writing to it. A computer is useless without memory because you couldnt do anything with it. So data is important but whats wrong with a file system? Lets go through the changes that Screens object storage improves over a normal file system: 1. A folder can be a file and visa versa In current file systems, you have folders and files where folders provide structure and files provide data. In Screens, an object is both a folder and file, so it can hold both structure and data. How does this help? Well... its like bundling. You can move an application (data) to another device and it includes all the structure and data of the application with it. It gives more flexability and makes information more accessible. 2. Links are direct manipulation Unlike shortcuts which are basicly files that direct you to the real file/folder, links act exactly like the object it points to apart from moving, removing or copying the link which just copies the link, not the object it points to. But anything else affects the link directly. This means that you can use a link anywhere you would put an object the difference is that links point to the object, its not the object itself. Using links you can make the tree structure of objects more flexible. 3. Links are like aliases and hard-links Links point to objects by thier handles so it does not matter where the object is moved to, the link stays pointing to the correct location always untill the target object is removed in which the link is removed as well. 4. Data of objects can be shared over multiple objects with different access policies. Instead of an object exclusively owning the data, it can be shared over multiple objects so each object feels that it owns the data and can manipulate it but the data is only removed when no objects own the data anymore. However each object can have an access policy where it can be allowed to only read the data or have read and write abilities or it can be allowed to only write to a local copy which is called Copy & Write. Copy & Write means that you can read the shared data but if you write to it, it creates a copy of the data and writes to the copy. If the object is the only one who owns the data, it does not make a copy. 5. Object locking Threads can read data freely but only one thread can write to an objects data. All other threads are paused untill the exclusive hold of the thread on the objects data is released (which is when the thread closes the object data). A thread also has to wait untill all threads give up read access before it can get exclusive write access. This makes sure that no two threads will ever read and write at the same time which is a common problem in multi-threading environments. This means that developers dont need to deal with semaphores or mutexes, the system deals with this for the developer. 6. Objects have operations Each object can have operations called Methods. Method are ways to manipulate data using module code. For example an email has a method called Send which sends the email. A music object has a method Play to play the music in a multimedia application. 7. Objects have types Unlike extensions, Objects can be based on multiple types so an XML file can be based on the XML type which is based on the text type so any text application can open the XML file and also any XML application can open the XML objects. Types also allow to provide default properties for objects so for example the window title color can be made a default value in the window type and any window which does not provide a different title color will get the default window color. This is just a tip of the iceberg of what Screens object storage will able to do. It also deals with threads as batch jobs where only in specific locations do threads actually write the object storage which allows for application crashes not to leave objects in inconsistent states. It deals with versioning, extending types and object properties, members and data. Its very simple design allows to be flexible and powerful and still work on handheld devices like PalmOS and PocketPC devices.

Update - I think I have solved the object storage again

Yep... Again I have a design that I will go over the next few days to see if there are any problems with it. So far its a very nice design which is sort of a merge between a relational object storage and a file system structuring. I'll write an editorial on how great it is and why it is so important when I find that it suits Screens.

Update - Problems with the object storage

I am having problems with the object storage again but once I solve them I'll try and code the CoreLayer component again.

Update - CoreLayer

OK, So I am coding today CoreLayer. CoreLayer is quite a big component compared to the other components I have been coding in the last two weeks. It deals with the actual layer objects, updating and drawing the layers to the display. CoreLayer is quite a good design since it allows transparency with ease with only one offscreen buffer. Layers are like markup and store the points, actions and commands that layers use to draw like 'draw rectangle at position 0,0 and finish at position 0,0'. When a layer wants to be updated to the display it calls CoreLayerUpdate which adds the layer to the update layer region. It basicly enlarges the region to be big enough to hold all update locations. So if I only update layers in a certain area of the display, only that area is refreshed. CoreLayerDraw does the actual drawing of layers clipped to the update region. When it draws layers, it draws them one on top of each other on the offscreen buffer. It of course uses clipping to increase performance to not draw uneeded parts of the layer. It also only draws from the first base layer and on top. The base layer is found as the first layer on-screen which covers the entire update area and that is not transparent. This basicly will allow me to easily get transparency effects without having to use a mask. It acts more like a pile of papers where it draws the lowest paper and draws each paper on top untill it draws the top paper. While the CoreLayer will only draw basic primatives like lines, rectangles, round rectangles, frames, pixels and other PalmOS drawing primatives, it will expand to support much more complex types in the future.

API Perfection

You constantly see me making changes in the API design even before I have actually coded them, or even recode an entire component just because of a small change. You might think that I making changes just for the sake of it but there is something much more deep in this. If you look at many other development API's they have a constant problem of not being usable easily. Some use low case letters only which means that you have a real hard time reading your code when it uses function names like gtk_signal_connect or gtk_box_pack_start. C++ API's also have problems that thier class names and methods feel like programmers just added them in one by one without caring for any consistency. Just a look at MSDN .Net classes and you instantly get puzzled. I know that the Screens API is going to have problems of its own (no static type checking since object handles are actually UInt32 typedefs) but I did want the component names and function names to be very consistent and easy to use. I am constantly talking with my Messenger users about function names like should it be CoreListCount or CoreListSize to return the number of items in a list. They sound similar and you would think that Size might be in bytes but then again its a list and when you say the size of the list you mean the number of items, not the size in bytes of the list. Another reason I chose CoreListSize is because it has a 'set' function called CoreListResize which CoreListRecount doesn't work well. Nearly all function names have consistent names like Read/Write, Open/Close, New/Free, Get/Set and you will able to find them across most components. I myself plan to code alot using my API (My API uses itself, a brick on brick design) and I want it to be easy to use and not constantly grabbing some online documentation or book to write some simple code. I want to be able to see the function definition and know how to use it without special notes and warnings like you may only call this after this or that after that. There are times when these are crucial like you need an Open before you do a Read and you should not use a Write after a Close but even then your code wont fail but rather will reopen the stream for read & write use even if you only planned to read from the file which means that any other thread which wants access to that stream will have to wait untill either the thread is released or a Close function releases the stream. But its easier to add in an Open/Close function pair then finding why the application dies when it reaches the Read function. Programmers will be able to be notified of this via thier module blog which is where errors and warnings can be filed to the programmer without interupting the user. Over time I will probably continue to modify function names untill I get them right, but its better I spend time renaming them then programmers spending time being frustrated.