Update - Data component done

The data component has been coded, tested and it works! Things are moving fast and I am working extremely hard to finish this core as fast as possible. The source code has been in a comment line then function line design so it is very easy for me to reread the code (which I forget very fast). The next component is the list component. Hope to finish that soon so I can get to the meat of the core which is the object & links component. The list component has no problems in it's design so the coding should go very quickly (especially since its only using the data functions). I have a private schedule which so far I am way head of but still keeping it intact just in case I get stuck (probably in the object and links component). That's the programming barrier I have at the moment, so once I pass that it's all downhill for the core.

Update - Were on the way

Ready, Set, Go... we are on our way. Coding has started. I have already finished two functions of the data component and should finish the rest of them by next week. The perspectives are better than I thought and by making differences between the internal API, private API and public API it allows the internals to be completely covered (developers can only use public API's). The next component: List List takes a data allocation (from the data component) and allows to create an array of fixed structures. This is used to make the relationship lists, object lists and so on. This is a private component and therefore has no public API. You will start seeing 'effect demos' when I finish the core (since the component after that is the layers component). One of my favourite effects will be when a layer is updated/shown/hidden it will not just update the display but transparently appearing forward while the old layer state transparently fading to the background. This will be great for transistions between panels and showing/hiding windows. The effect will be disabled on devices that are not color (grayscale) or that it's too slow. Note that all animations get cut down by the speed of the device. This means that the effects will hardly ever slow down performance. The effect demos should show some things that Screens will able to do since the layers is the heart of the drawing design.

Update

So here we go... I have been spending alot of time this weekend researching and thinking about the code aspect like the use of the SysAppLaunch function used to pass control between function calls (using the ScrAppLaunchCode launch code). If anyone wants to know the speed of the SysAppLaunch try changing the time in the prefs app and quickly tap the find silk button and count the number of seconds it takes for the find dialog to show. This is going through every application's PilotMain even if it returns straight away on most apps. I have also made sure that this method is compatible with PalmOS Cobalt. The object component API has now numbered sub components and I am getting closer to the end of the perspective design and naming the functions. Once the function naming of the core (the object component) is done I can start coding the data sub component (hopefully). Screens is moving along and is showing more and more opportunity as time goes by. I have decided that by releasing the final release (demos will only be for PalmOS) on both PalmOS and PocketPC at once will allow Screens to get more users and because the changes are minimal, there is no 'cost' for the porting. The only problem is that code written for PalmOS wont work on PocketPC and visa versa. I might think about using java since it's platform-independent and all it needs to do anyway is call the Screens API. However drivers or any software which uses API's outside of Screens should be natively coded. If I could get the java idea to work it would allow the core to be natively coded and most of the other apps to be java compiled.

FAQ

Many users ask me the same questions so I hope this FAQ will help ;) Post question in the comments so that I will answer them here... 1. What is 'Screens Environment'? Screens Environment is a project to create a simple, stable and easy to use operating system. However unlike other operating systems, Screens has no 'legacy' baggage, works on top of existing mobile operating systems (at the beggining PalmOS and then PocketPC) and is built from the ground up to be very flexible and powerful and most of all expand easily without all the limits that haunt other mobile operating systems. 2. Why create a 'high-level' operating system? I believe that low-level operating systems (such as PalmOS) seem to be to much dealing with the internals than the user features. This is not bad, but it does require a high-level which takes advantage of the low-level features provided by the low-level operating system and create a high-level version of it merging many low-level features into single simple high-level features. Think of the low-level OS (PalmOS) as the behind-the-scenes while the high-level OS (ScreensOS) as the user and programmer interaction. 3. Is 'Screens' a launcher? Screens Environment has a launcher... but that's like saying that a plane has a bathroom. It's the whole package which makes it into an OS. It's not just an application but launches applications inside of it which are coded with the Screens API. It also can switch to the 'low-level' OS to launch the low-level apps. This provides 100% compatability to the device. It provides the high-level capabilities to apps coded with the high-level API but can still switch to low-level apps. 4. Why are PalmOS apps low-level? Have you seen the PalmOS API.... It's got internals written all over it. Not that it's a bad thing. It served it's purpose at the beggining for speed but devices are getting faster and requiring much more powerful apps which the PalmOS API just cannot give. This is why so many companies have 'common-code' base which just bloats the app size. Screens gives these needed features right from the Screens API making coding even high-featured apps a breeze. 5. Does Screens support HiRes and HiRes+ resolutions? Yes... but more than that... Screens has window management. Which means that you can move windows around, switch between them, maximize and minimize them and of course close them. Screens uses a icon-based-menu (a horizontal icon list which slides when dragged) to allow easy switching between windows. Because Screens is vector-based, it can use the high-resolutions to show more detail or more workspace depending on your choice. 6. How many Screens 'High-Level' apps can you launch at once? There is no limit. This is because even though an app is launched, it's not actually using CPU or even dynamic stack untill it's actually using the CPU. Screens takes advantage of the execute in place feature of PalmOS. For PocketPC which does not have the execute in place feature it swaps applications in memory by thier usage. So even on a PocketPC with 100 windows shown only the applications actually running (sending messages to the message loop) are in memory. 7. How does Screens handle data on the different platforms? Is it different per platform? No... Screens comes with a object oriented storage. This is the same over all platforms. The OBS (Object Based Storage) supports classes, extensions, relationships, meta-data handling, overriding and more. OBS is a hybrid of C++ object oriented design and object oriented storage databases. It is the core of the entire OS. Everything from the message loop, windows, input, network to appointments, files, multi-media is based on objects. 8. What does OBS give for the programmer/user? For developers, it provides an easy and common way to describe the data of thier application, store resources and build libaries and components easier. For users it provides a common interface to search, organize and create information. Want to attach people from your address book to an appointment - no problem. Want your PC to download a big presentation to your device for a specific appointment and remove it when the appointment finishes - no problem. Want to find all the documents in your device which were changed or created in the time of your buisness meeting - no problem. The possabilities are endless and even I dont know all the ways you will able to take advantage of the storage. 9. You said libaries... What about DLL-HELL? DLL-HELL is what users hated alot in windows (and other OS's) because when an old application needed a specific libary and a newer app using a different version of the same libary existed on the same computer, there was conflicts which caused the need for libaries to be as backwards compatible as possible. Screens solves this by not even going near versioning. It solves the problem from the core. Instead of libaries being fixed code blocks holding old and new code, libaries build apon existing code without having to have the old code in the libary. When a libary wants to fix, replace or extend a function, it does not edit the original code. Instead it creates an update just with the fix. This is using the power of replacing/extending method objects. Sounds complex but when you get used to doing it the Screens way, you will find that updating old libaries is better than creating a new one from scratch. In a way you are creating a new libary from scratch but you can use all the existing methods that work fine from the existing version. When a user installs the libary it installs the original and all the changes over time. I'll able to have more information when I code the actual design. 10. Does Screens support multi-tasking? Cooperative multi-tasking just like DOS, PalmOS, MacOS (9.x and previous) and Win 3.11 This means that if an application freezes the whole OS freezes which requires a soft-reset. Screens uses the capabilities of the low-level OS and does not add any extra low-level code. Since PalmOS does not have multi-tasking capabilities (up to Cobalt) neither does Screens. However in the future (Cobalt and above), Screens will probably support preemtive multi-tasking. 11. So a single application can ruin all my window layout and changes? No... Screens stores everything in the object storage which is persistent. There is no 'Save' button. All changes are immediate (but there is undo) so even if an app does freeze the system after soft-reset you will see everything (apart from the freezed app) just as it was before the freeze. No other system has this and you will appreciate it from the first freeze you get. However Screens will be checked all the time so that it is bug free on releases. 12. Does Screens support themes? Yes... but deeper than any other OS out there. A theme can affect the entire look but also the feel. For example: when I release Screens publicly, I will also work on some other OS look-alikes. The Windows theme will have a start menu and task bar which will work nearly exactly like the real windows start menu and task bar (however the tap bug of the 'Start' button is fixed). The gnome theme will have the top bar and bottom bar and the MacOS theme will have a global menu bar approach. Users can create additional themes. 13. But Gnome has the virtual workspace buttons below... How does Screens deal with that? Screens supports multiple users and multiple workspaces per user (with password protection per user). So the virtual workspace buttons are fully functional. You can also apply policies per users so for example: a kid user could be limited not to install new apps or run 'low-level apps' while a admin user could be able to switch to all users without a password but not visa-versa (allows quick access to your own user acount without having to use the password). This allows to have multiple depths of security levels. 14. This is all great but when will it be released? No idea... I am working hard day and night to get the core coded. Once the core is coded (basicly the object storage and basic window management) then I can release some alphas. Check up weekly on the blog to see how the progress is coming. I have been working on this project for more than 2 years and have my own funding so there is no normal reason this project would be 'halted'. I am not building a boot-loader so I am not stuck there ;) If you want answers to any other questions post in the comments section and I will update the FAQ ;)

Update

Hi Everyone, Last friday was a great day for Screens since I was able to solve the internals of the object component which is based on a 'snack-machine' design where you can see all the different objects (objects with different name UID's) in a list and each object has a sub list holding all the objects with the same name holding the source and target of each of the 'duplicate' members. This design is fast because it allows classes and extensions to be modified and the update is done dynamicaly. There is no need for run-time checking for the correct override behaviour which makes the system very fast. A few users have already liked the new design. The object browsing of members API has been defined and has a macro which makes browsing very simple. Take a look: ScrObjectList(HContainer, HMember) { if(ScrObjectName(HMember) == UID_WINDOW) //Add code here } This code very elegently will loop through every member of a specific object (HContainer is a handle) and set the current member to the HMember handle. So any code in the brackets will be acted on any member in the collection. This makes it very easy to search, manipulate multiple objects very easily. The ScrObjectList is actually a macro which deals with the loop for you. Compare that to any other meta-data system out there. It's ideas like these that can make an OS very easy to code for however require a great deal of time to think of. What is left for the object component now that the object manipulation and object member browsing function names are designed? The browsing/creating/removing of classes and extensions (extension API can come later though). The class behaviour is the most important. The general prefix is something like this: Here are a few examples: ScrObjectNew ScrObjectFree ScrWindowMove CodeDataWrite Scr prefix is used for all the public API wrapper version while the Code prefix is used for the non-wrapper version. is used for internal (not to be shared outside it's source file) functions. This design makes it very easy to keep track of the multitude of functions. A huge amount of time is spent on not only the user interface and internals asspect but also the programmers view since a programmer is also a user so why should it be hard for a programmer to code. If coding was easier we would see more qaulity applications which is what I plan to show with Screens Environment. Know that the data component is totally ready for coding just waiting for the object API to be finished and I code away the first component which encapsulates a PalmOS database for read/write of records. It's functions took also some time to design however there is no public API (wrapper version) for the data component. This is because I dont need programmers touching the internals of the data component. The only component which does this is the object component anyway. Work is going well... and even though I dont have a working version I am very happy with the design. This is not your average OS... find any other OS that is using it's INTERNALS object oriented with run-time class support. This is not Spotlight or WinFS... The whole Screens Environment is composed of objects in the object storage from the message loop (yes, you can extend the message loop like to support real multi-tasking the future) to the window management (want to add a drop down to the close button on a tap & hold just add a tap & hold method to the close button control in the title control class which belongs to the window class). The possabilities are endless and very flexible which makes life easier for me and any programmer (and users) who make applications for Screens Environment. If anyone has questions... post them here or send me an email at zhamilton1@yahoo.co.uk