Why is Screens is taking so long?

Screens Environment has been going since 2002 and still no releases have made the light of day. There is a single reason why Screens has taken so long and why I have no idea when it will be released. Its not because I lack time or interest. Its because of the object storage.

If you look at the object oriented OS projects, none of them have made mainstream because they are not practical enough, too complex, too slow and still stuck in a concept. There are many companies trying to bring object oriented concepts to file systems just like me and just like me are still stuck.

If I was not making the object storage, I would of finished Screens long ago but then again the object storage is such a radical change that Screens would not be the same without it. In fact, the object storage would be the main difference between Screens and other middleware platforms.

I need luck, time and persistence to find a combination that works.

Component Oriented Programming

The difference between component oriented programming and object oriented programming is focus. In object oriented programming the focus is the objects themselves which is why you access methods through objects like this:

CoreObject * object = new CoreObject;

object->rename("My Object");

In component oriented programming the focus is the components and objects are just placeholders for instances like this:

CoreObject * object = CoreObjectNew();

CoreObjectRename(object, "My Object");

It looks like procedural programming but the difference is that it uses objects. One of the reasons object oriented programming has never able to become a file system is because when objects are created, they are stuck in stone in their definition. While their properties can be modified, you cannot add/remove properties. In component oriented programming, an object is just a placeholder where you attach/detach components to objects. Each component has a data definition associated with it. Because of this, when you attach an object to a component, you attach private data of the component to the object. Each component only accesses its private data per object and does not read or write another component data directly but rather uses the API provided by the other components.

That is component oriented programming in a nutshell.

Twitter

I am going to try and use twitter for quicker updates on development and keep the blog for more milestones and other news, follow me at http://twitter.com/zhamilton1 for some live development updates on how code is the Screens code is evolving and the issues I face daily.

New Born Baby Girl

Hi Everyone, Sorry for the lack of updates, I was at my wifes parents house for the last 3 weeks, so not only could I not do any coding but internet access was not as spiffy. My wife had birth to our new baby girl at 22:25 last night (monday night) weighing 3.780 kg in her 41st pregnancy week. The baby is beautiful (but then again, I am biased) and is healthy and doing very well. This is my second child with a nearly two year old boy and a less than 1 day old girl, I am a complete family. Oh and we have a dog and two cats, just keep the mix. Screens Environment will resume in code when I return home, but I am having been writing ideas and comments on my iPod touch. Because Screens Environment is multi-platform, the actual interaction I have to do with PalmOS is minimal at the moment.

Update

1. No Worries Don't worry... This is nothing to do with the state of PalmOS or Screens. I don't want to say anything just in case something does not happen as planned but I will not be very active on Screens in the next few weeks for some family prime-time. 2. Technical improvements I have uploaded the latest code for the shell bar and while it does not display anything at the moment on the bar (apart from an empty gray slice), the code is ready for loading the menu items from the xml but I still need to write a bit of code for displaying them in the menu list which is not very much code at all thanks to the UIList component which does most of the work for me. I can't wait to show you all an early demo of the slider which while it won't look up to snuff, it should be enough to rub your imaginations of what it could be in the future. 3. Platform status PalmOS is not in the best of shape at the moment and at the looks of things windows mobile is a little stale as well. Apple's iPhone seems to be the new kid on the block and hopefully won't suffer the same slowdown in a few years as PalmOS and Windows Mobile have suffered. I just bought an iPod Touch... Not for Screens but for personal productivity. I will keep my LifeDrive around for Screens development. I am not changing development sides but I need a device that won't crash all the time and the iPod Touch seems to cover that need. 4. Hope for the future Screens is still alive and kicking better than ever before and I hope you agree with me after the last few months of great activity. I am amazed how suddenly everything has been going great for Screens, how I am able to get so much done after so many years for absolute nothing. Thanks for keeping an eye on this blog, I hope the blog gets more interesting as time goes by as I pile the features on and getting Screens ready for the 1.0 release. Hopefully it will be this year but looking at my record, don't take my word for it.

A bit more thought

I added the rectangle when moving a window that shows the border that will cause the window to maximize.

I still need to do a bit more design before I can finalize on the system bar and finish a first draft of its implementation. Hopefully I can have something by the middle of next week.

About the patents... It does not matter since the code is already public domain and I don't mind if someone else copies the idea, but thanks for thinking that its worth a patent in the first place.

Its getting really exiting (SVN 0.73)

Things are moving along again and every small step is shaping Screens into a much more usable demo. Here is a demo of the maximize/restore feature I told you all about which I hope you will like:

I found it very practical and easy to use and I wonder why no one else uses this method instead of small buttons. When the shell will be finished, you will be able to minimize windows by just dragging them to the bar at the bottom of the screen.

Screens object storage itself does not use the multi-tasking API's but then again since its cooperative multi-tasking, they don't need to. The advantage of cooperative is that the code does not have to worry about being stopped in the middle of processing. Switching of threads only happens when they call CoreThreadYield.

Moving along the shells (SVN 0.71)

Sorry for the lack of updates but this has been a slow period since not much changes from a visual perspective but alot has changed under the hood making way for the shell bar + slider. Windows can now be maximized by dragging their title to the top of the display and can be restored by dragging the title back into the middle of the screen. I hope you like it, I will upload a video soon showing this feature.

Maximizing along (SVN 0.68)

I have added maximize/restore ability to windows and added the window title text.

I will be starting shortly on the shell package which manages the Safire main system parts which is the slider menu and system bar.

I am designing the last API parts of the menu. Note that because I have not implemented timers, there will be no animations in the slider but it will still give the effect.

I can't wait to try the slider myself and show it to all of you.

On my way (SVN 0.66)

Details of my shell design are really coming along and I am starting to implement the basics to support the Safire shell. I already know more or less how the UI will look and I cannot wait to show you a demo of it. Now that all the platform main problems are behind me, I can finally start do things that are more user visible. A bunch of moving windows is not enough to spark user interest but I feel the shell will spark that interest.

I don't know how long it will take me, but I am trying to put as much time as I can on the project even though I have a full time job.

Screens is split! (SVN 0.65)

I have solved the exit issue and now Screens runs like it used to before the module split. The performance is not that bad:

I did not believe that Screens would improve as it has in the last 3 months. I still have alot of work ahead but these are design issues, not platform specific problems. I know how the UI will look but I need to design their components. I can't wait to show you all the slider, I think that while it might annoy some users, I think alot of you will like this design.

It works! (SVN 0.64)

I don't believe it! http://www.eskimo.com/~scs/cclass/notes/sx4aa.html

It turns out that PalmOS is pre-ANSI C compiler which means that it does not know how to always initialize local arrays correctly. It took me a long time to figure this out (thank you www.live.com)

OK, So let me tell you what all this work meant...

It means that Screens can support modules in a very easy way. Currently I am running Screens with three modules:

Windows:

core.exe, ui.dll and fs.dll

PalmOS:

core.prc, ui.prc, fs.prc

I did not believe I would get to this point so quick! Three months of hard work and suddenly everything is moving easily along.

Using the make_api utility I am able to easily create function wrappers for all my functions that I want to export for other modules to call. The nice thing about the wrappers is that they look exactly like normal functions and are called like normal functions. I do have alot of optimizations to do and I still don't know how slow this will affect the performance on my LifeDrive.

Update

OK, I still cannot understand why I am getting "Invalid read from 4E560000" error but I am still trying to debug the code (even though I cannot use the debugger).

However I have made a utility to allow me to create the API wrappers easily which has been uploaded including the source code.

Moving along

OK, Things went smoother than I thought. I have finished the API wrappers between the packages. I still have to do the final code to set up the feature memory function pointer so that I can lookup loaded modules for the associated function. It should not be that slow because I do a small string lookup for the package name and then the function is by index. Also its easy to set up for new modules which was important to me. Hopefully the performance wont be too bad.

I hope to soon restore the demo as it was before hand so that I can continue spicing up the demo.

Hard to connect the dots

Screens is not doomed yet, however I am working on a very non UI issue which is the package/module interconnection. I have no problem loading a module. The problem is linking between the API calls which I am doing in a mostly platform independent layer which makes it hard to get it working but once its working, it will be easy for me to write new modules and connect the modules together.

I also need to make some changes in the UI component that it cannot use globals. The new file structure is stored per package with a consistent folder hierarchy. Its going to look like not much is happening but the truth is once I finish this major part of Screens, I can go straight to more exciting UI stuff. This is where I wish I had developers working for me but I guess if I want it to be perfect (my way) then I need to do it myself.

Please bare with me, I am working as hard as I can to get this module stuff finished as clean and fast as possible. I want to get the alpha demo done much more than all of you put together.

Update

Hi, Sorry for the lack of updates...  I have been working hard on the module side of Screens. The kernel is more or less usable and now I need to start working finally on the UI Shell module. I still need to figure out the model model in all its glory details, this really feels like the final 'big problem' in front of Screens to stop the demo from being released. The loading of modules is more or less coded. The problem is the API side of things. I'll keep you posted on my progress.

Update

Sorry for the lack of posts and updates this week. I have had to put some more time in my full time job which did not leave me much time when I got home to work on Screens. However I have still had to plan the next components which is the shell itself. I have a new graphical layout which I hope to test soon in code.

I have had some SVN activity and I still need to upload some more changes in the way I update the screen. Screens now supports 320x480 resolutions and landscape support as well. I need to fix some bugs on this issue and then I will upload a video.

Fast enough! (SVN 0.57)

Here is the latest version of Screens running on my LifeDrive without crashing and with a good enough frame rate.

I decided that I would try optimizing my code first and only if all efforts fail go towards ARM. Well, It looks to me like its fast enough at the moment to continue on this path without ARM. First of all, this is the 'release' (not 'debug') compilation which improves the frame rate. Also the bitmap component allows for platform specific storage so in PalmOS I just store the bitmaps as normal PalmOS bitmaps. The only thing which is custom blitted is the fonts which is probably what is slowing it down.

If you want to run the full demo on your handheld, just send me an email to zhamilton1@yahoo.co.uk and I will send you a zip file containing all the files you need to put in \Xec folder in your internal/external storage card.

I am amazed how far I have come in such a short time span. Five years of research and suddenly I am cranking out releases on a nearly daily release. I guess innovative projects require time and patience.

So far... So Good...

Video on LifeDrive (SVN 0.54d)

Here is a video of Screens running on my PalmOS LifeDrive:

You can see that it is very slow and its because I am doing blitting without ARM code which seems to be the way I need to go if I want Screens to have more than 1 frame per second. I hoped I would not need to go in the ARM direction but I guess I have not much of a choice at the moment.

Screens still crashes on exit but what's strange is that it is after my application dies which is weird. What's even more weird is that if I don't let it go through the VFS stuff (no bitmaps/fonts/XML usage) then it exits fine, must find a way to debug that.

I can see bitmaps and text on my LifeDrive (SVN 0.54a)

Its as slow as hell because I am using a pixel by pixel blit using the WinPaintPixel PalmOS function. I just need to find a reliable way to blit to the screen and it should be much faster. Also when I exit it still crashes but I am sure I will find the solution to the crash very soon. Also note because I don't have a blitter, there is no transparency on the Palm version. Once I use a blitter, I will have no transparency issues.

Mounting VFS Folders (SVN 0.53)

Mounting VFS Folders works but what is even more cool is that the drives appear like windows drives so for example: I did not have to change a single path in my test file to test VFS browsing on the simulator. So for example C:\xec\ works also on the handheld using the first VFS slot (most devices have a single VFS slot) and mapping it to the C drive. This makes it easy for me to transition between the two platforms (Windows & PalmOS).

So what's next? First I need to make sure that read/write VFS files works on the handheld and then I need to figure out how I will blit the bitmaps to the offscreen buffer.

I have alot more work. The next biggest problem I can see on the horizon is dealing with launching Screens apps. Both for the launching and making it easy for them to call back into the kernel. I hope I can find a solution that is easy not only to write but to compile.

Another issue, I am having problems with the offscreen buffer which is some of the simulators is treating my bitmaps as low density. I spent a few good hours trying different calls but with no avail. I have decided to focus on improving the platform independent code and then returning to focus on the platform dependent code. This means that my current target device will be the LifeDrive.

UIList added (SVN 0.52a)

I just uploaded the new UIList component which deals with a collection of items and deals with scrolling them in a unique way. Here is a demo of what it can do with simple strings:

If you noticed at the end of the video, I run the same demo on my LifeDrive and it works (apart from the lack of font & bitmaps). I was so sure the speed was going to be terrible but I guess its not that bad after all (remember that I am using standard Palm draw functions, no special ARM blitter).

I will create a mini app to browse the objects in the system, so that I can debug the VFS stuff directly on my LifeDrive.

Moving along (SVN 0.51)

I doubt I will actually be at 'release' for 1.0 but it will probably be for demo release. I still have alot to do, but I am very happy with the progress and how the code is very streamlined. Note that if you want to take a chance you can find the Safire.prc file here:

http://screensos.svn.sourceforge.net/viewvc/screensos/Safire/garnet/make/

Note that its only been tested on the simulator and NOT on my LifeDrive yet. So please take care, since I not only have no warranty but I don't know if it will even work.

VFS Component Coded (SVN 0.50)

I have finished writing the FSDisk implementation for PalmOS using the VFS API. It took much shorter time then I thought it would. I used most of the FSDisk Win32 implementation. I now need to test & debug it and fix its bugs using the PalmOS Simulator.

I am a little PalmOS rusty (SVN 0.49a)

Here is a video showing the PalmOS version running on the simulator side by side with the windows version:

I have not coded for PalmOS for some years and I need to re-learn alot of the basics. Its very frustrating returning to the limited platform but its a great exercise.

I am getting there, but its taking forever. I am trying as hard as I can. About compatibility, I am currently targeting the simulator which is PalmOS 5 but if PalmOS 4 devices are still around when I get to release Screens, I don't see a problem being PalmOS 4 aware.

From the video you can see I still have a long way to do to get both versions identical. I am missing two major pieces which is the VFS component and the drawing of bitmaps. The first is harder than the second. The performance on the simulator is not that bad, hopefully it wont differ too much on an actual device. It also has a crash when releasing the objects, got to see what the issue is.

I do know that once I tackle these issues once I can more or less forget about them. This is the important part of the platform independency is that I don't have to interact with the platform API all the time.

I don't know if Screens will ever be released, but at least I am trying.

I have a PRC File (SVN 0.46)

I don't believe it! I have a PRC file that is compiled from the latest source code! I found a solution for the errors I was getting in PRC-Tools by using one of the latest cygwin1.dll files which seems to suddenly remove all my previous 'cygwin alloc' problems on vista.

I had to do alot of pluming for Screens to compile for PalmOS because of multi-segments. So I devised a platform independent way of dealing with multi-segments by having a PACKAGE name. So all functions in each component define their package. So all the UI functions have the PACKAGE(UI) at the end of their definition.

I do plan to make a readme file when I can actually get the code running. Yep, I still have to debug the code and make sure it actually runs. Once it runs, I will attach the prc file so you can all check it out on your devices.

Note that I still have the Disk component to write to interface with the PalmOS VFS stuff but that is not important at the moment. What I will be focusing on now is getting the demo running on the Simulator (and then having fun with it on my LifeDrive).

Screens is really getting there!

Thank you so much for all your help!

Moving along (SVN 0.43)

Screens is moving along slowly but so far, so good. I did some more bug fixes and added the check box component (which was mostly the button code). The video gives a demo of the check boxes.

I still don't know how I will finish the PalmOS port since I have no way to debug or even completely compile (I can do partial compiles) Screens for PalmOS since its not supported on Vista which is a shame. If someone else wants to finish the porting for PalmOS please help since I don't have the resources at the moment to do so. If you do want to port it and have questions, please send them to me at zhamilton1@yahoo.co.uk

I wonder what I should do next...

Trying to draw (SVN 0.41)

I have written most of the drawing code (still have the blitting function to implement) however while it compiles, I am sure it won't run and will need alot of debugging to get it working but I do know that the structure is mostly there. I did alot of copying from a previous project I had worked on a few years ago so I still have alot of work to comment the display code.

At least I know that the bulk of the code is platform independent and has been checked, so once I get something drawn on-screen I know I will be seeing the exact same thing you saw in the alpha demo app that ran on windows.

I am actually very happy that the code is becoming mature but I am still worried about how the performance will be on PalmOS. Hopefully it wont be too bad.

I still have the FSDisk component to port which maps to the VFS functions which I have never used before which will probably take me some time to port.

I will try and continue improving platform independent code at the same time so that I don't get stuck too long in the PalmOS port. I still have alot yet to write.

More PalmOS Code (SVN 0.40)

I have uploaded some more PalmOS components that although they have not been tested or compiled will provide me with the code to use when I can get an environment to compile in. I still have two files left to code for PalmOS to get the current platform dependent code written which is the FSDisk component which will be mapped to VFS PalmOS API functions and the UIDisplay component which maps to mostly Form and Window PalmOS API functions.

I am really worried about the performance factor when I run the test app on my LifeDrive device. If the performance is really bad, I hope that some little optimizations will help because I really don't want to have to re-write Screens for the 30+ time.

I looked back at the 1src posts I did between 2002-2004. I am so sorry that I did not live up to my own expectations. I really did think each time that I was going to release something and every time I failed. I am working very hard that this wont happen again. But if you look at my history, I am normally wrong. Forgive me.

Alpha Video (SVN 0.39)

Just uploaded SVN 0.39 which includes multi-line text and some minor changes to the threading component.

I am amazed at the progress so far and hope that it will continue.

I have decided to show you all what Screens Environment test app currently looks like. Note that this is just to test its capabilities and not how Screens will finally look in any way at all. Here is the video:

I don't know what component I will be working on next but I am very excited about the current state of Screens. This is the most featured version of Screens yet in the last 5 years! I feel that my design is rock solid so far and hope it stays that way. I am a little concerned at how I will port to PalmOS without a good environment to compile and test.

Thread Tweaks (SVN 0.38)

I did some work the thread component to make it more self manageable. It allows to use it by just creating threads using CoreThreadNew and calling CoreThreadProcess which returns when every thread has finished. I also added support for a parameter to be passed to the thread function. I think this is one of the easiest API's for using threads.

#include "CoreThread.h"

void main() {

CoreThreadNew(thread1, NULL);

CoreThreadNew(thread2, NULL);

CoreThreadProcess();

}

I hope the implementation will be compatible with PalmOS when I port the thread component.

Cooperative threading works (SVN 0.37)

It works even in release mode! It uses a simple setjmp/longjmp implementation which I will try to make even smaller. It uses stack copying and hope to make it with enough comments for future help to developers. It took me quite a while to get it working and there was not much information on how to use setjmp/longjmp in this design.

Note that the only dependencies of the CoreThread component will be the CoreMemory component which has no dependencies itself so you can always just use the thread code in your project since its public domain.

I would like to thank the users that have been testing the versions of Screens including those that helped me with the fonts. It really helps me the support, every word counts.

Nearly cooperative (SVN 0.36)

I have been trying for the last few days to try and get some basic multi-threading done however while it compiles and works wonderfully in debug mode, it is not saving/restoring the stack correctly in release mode. I am trying to figure out the differences between debug/release mode and while I turned off optimizations, it still happens.

I hope I will find a solution. I am using setjmp/longjmp which is known to not work in all situations. If you want you can try and diagnose it for me at my SVN repository: http://screensos.svn.sourceforge.net/viewvc/screensos/

If I get it working it will be really nice. Because its cooperative, its much easier to manage and will allow me to port it with more ease.

Note that I do stack copying which while its not exactly known for its performance, it has a higher rate of compatibility with function calls.

Wish me luck!

PalmOS Font Displayed (SVN 0.34)

I have converted the PalmOS High-Res Font to work on Screens. Its just a bitmap and an XML file that Screens uses to draw text very easily. You can easily understand the XML file where it specifies the character code, offset and width of the character in the bitmap file. Its uploaded to SVN.

I am amazed at the development this month. You can tell just by looking at the number of posts this month. I hope that this continues and that Screens will continue to evolve.

Text Alignment (SVN 0.31)

I have added text alignment and text in buttons so now I can display centered text in buttons which works very nicely. Screens is starting to get functional which is very nice.

I do need a better font though but meanwhile I think I will take the PalmOS font and convert it to my XML/Bitmap hybrid font format so it will work with Screens. Note that I use ASCII format and not Unicode at the moment.

I will start adding version numbers in the post titles to keep track of the changes in SVN in the blog.

I can draw text!

Finally... the moment has arrived... I can draw text on-screen using a custom made font (just took a snapshot of some capital letters and threw them into a bitmap and then described them in the XML file)

The format of the XML is very simple and the bitmap is just a 256 color bitmap where the palette is ignored and the index is the transparency from 0-255. If someone wants to create a better looking font, I am very interested.

The XML attributes are as follows: (the tag name is entry)

char - the character index in decimal (32 = space)

offset - the left position in the bitmap where the character starts

width - the size in pixels of the character

I am very happy I have got to this moment, since now have enough visual features to display something useful. This is a very important milestone for Screens.

Nearly can see text

I am very close to finishing the basic drawing of text on-screen. I have uploaded the changes already. Although I currently draw the entire font bitmap, I do draw it with a specific color. What I need to do now is mount the XML file and build an array of the characters offsets and widths so I can draw text elements easily.

Note that all this code including the zip and XML code is platform independent and therefore will help the PalmOS code base as well.

Things moving along

I am still getting problems with compiling for PalmOS on Vista using PRC-Tools. It works sometimes and then other times fails completely.

So I am jumping between advancing the feature set of Screens and porting to PalmOS. I am a step forward in the font engine dealing with the bitmap side since the XML side is more or less complete.

I hope I can find a more reliable compiling experience so that I can port to PalmOS faster.

Starting to Port to PalmOS

I have decided to port to PalmOS before dealing with the text & font component so that I can know the code performance.

It took me a long time to get to compile anything on vista with the PalmOS Developer Suite. Luckily I found the following article to help me compile on vista: http://charlesmcp.blog.com/1552399/

However I am still having the following error:

C:\PalmOSCygwin\bin\m68k-palmos-gcc.exe (8776): *** couldn't allocate cygwin heap, Win32 error 0, base 0xA40000, top 0xA4A000, reserve_size 40960, allocsize 40960, page_const 4096

Any ideas?

Bug Fixes

I am constantly trying different stuff to find bugs and fix them. You can see from my SVN activity that I am very active on Screens.

I just dealt with little/big endian issues and now I can easily read and write data in its little or big endian format without much work. This is crucial since PalmOS is big endian while Windows is little endian. The zip & bitmap format is little endian so on windows it does not conversion while on PalmOS it will swap all the variables it reads from the formats.

Luckily I had taken into account alignment so I had the macros for reading formats already, so I just had to make a slight modification to them for it to handle endianity issues.

I did find a potential problem that could cause problems with this Screens code base which is performance on PalmOS. Hopefully it wont be too bad or not bad enough that it cant be fixed. Currently I do notice a performance bottleneck when loading bitmaps which I will try to improve as time goes on.

Abstraction does have a performance price.

Uncompressed ZIP Component works

OK, I have decided to postpone zip compression to a later release since its not needed at this time for the font component. Screens can handle uncompressed zip files and mount XML files and draw bitmaps directly from within an uncompressed zip file.

This functionality is exactly what I needed for my font format which is an uncompressed zip file with an XML & bmp file. I am very happy with the results and the code has already been uploaded to SVN.

What's so cool is that the XML & bitmap component have no idea they are accessing their data inside of a zip file which is makes this design so powerful, less clutter and easier to use.

So now I have to design my XML font format and bitmap layout. I am designing it that you can use a bitmap & text editor to edit a font file. Once I have designed the font format, I will write the component to understand the format and draw text on screen.

Note that Screens is currently not supporting Unicode. I don't find it a crucial feature at this moment in development. Everything is currently ASCII.

Its going really well

I don't believe how far I have come in such a short time. This last month has been unbelievable. OK, I'll control my enthusiasm...

The zip component development is going very well. I now mount objects with the file names of the zip content. I still have to decompress the content yet which I might do on the fly if possible.

ZIP component going forward

OK, it is harder than I thought it would be and it looks like it will take some more time just to support the basic deflate compression method in a zip file. But all this information is a learning experience for me which is nice.

Currently I know the number of files in a zip file but I still cannot seem to know their file name. Oh well, I will probably find it out soon. Once I know their names, I will start working on the deflate decompression function which I have no idea about at all so it will probably take trial & error.

If I succeed, then Screens will support zip files for anything and not just for the font files. I am currently supporting very basic I/O with the file name in both the disk and zip files. I am sure I will add more information in the future such as attributes and date/time stuff.

ZIP Component progress

I have started working on the zip component which just like the XML component, mounts a file stream and creates child objects that allow to access the uncompressed file data easily once mounted. I am trying to support basic zip files (no encryption or other fancy features) so that it will work with my XML+bitmap font design.

So far, I have already find the information I need for understanding the zip format and I am now writing the routine that understands the zip format. So far, its straightforward but since this is my first time writing a zip extractor, it should take me some time.

Of course because its object oriented, I can do things like mounting an XML inside a zip file which should be interesting.

Answers

Q. About how what is the maximum size of the read only cache?

A. The maximum size is the maximum that the allocation function allows (platform dependent). Because of its temporary nature, it just does a big allocation and if it fails, it returns NULL that it cannot give a read-only cache. The read-only cache is destroyed when you close the object.

Q. Also How do I compile the SVN files? do I compile them as a dll or exe?

A. Currently it compiles in visual studio 2005/2008 (but I am sure it would be GCC compatible - if not let me know). I use Visual Studio 2008 express edition which is free from Microsoft.

Create a new empty console exe application, add all the files to the project and compile away. I designed it to be very simple to compile and I hope you will agree with me. No macros, no setup... just the default settings should do fine. The flags that visual studio adds by default are:

WIN32;NDEBUG;_CONSOLE

If you have any issues compiling or find any bugs please tell me.

XML Component complete

I have finished coding the XML component and uploaded the changes to SVN. Tags are mounted as FSFolder objects while Attributes are mounted as FSFile objects.

I am amazed how things are suddenly moving very easily. But I doubt that the font & text component will be as easy. I will probably have to create a container component first to hold both the font XML and the bitmap font, so I will see if I will create a new one or use an existing format.

XML Component progress

Just to let you know that things are moving nicely.

I have nearly finished the XML component but currently lacking support for tag attributes and for the creation of the objects that are mounted under the XML file object.

This will allow me to mount any XML object stream and access its tag and attributes as simple objects. Because of the object oriented design, the XML component is not aware of how the stream is built, only that it supports direct stream access.

Update

It looks like I am going to have to use my own bitmap font format. However it will be using a standard 256 color bmp file for the glyphs and an XML file for explaining the glyphs in the bitmap file. These could be easily put in a zip container and when I add zip support to Screens, Screens will able to use the font directly from within the zip file.

Although I don’t yet deal with 256 color bitmaps, rather only 24bit, I will add support for 256 color bitmaps soon for the font.

For now, I am writing the XML component which is very basic and is designed for quickly reading tags & attributes as objects without much verification at all. The font component then reads the XML and makes sense of it.

I added support for caching small files and the ability to access them in a read-only cache without the overhead of having to manually allocate a buffer and read bytes in bit by bit. If the entire file cannot be allocated in memory, you cannot use the read-only cache.

I don't believe how Screens is moving along. A few of you that have tested the versions have given me feed back... thanks!

Bitmaps can now be displayed

This is the furthest I have ever gone from a code perspective in Screens in the last 5 years which is something. I always find some problem (complexity, speed...) which required a re-write of the object architecture.

I can now display bitmaps on-screen clipped to a region. What's cool is that the bitmap is loaded once into an element object and then the drawing is done from in-memory using a new feature: direct object streams. An object can allow a direct pointer to its stream if it can support it. The disk file system does not support direct object streams while the default object streams do support direct object streams.

The next work is to start on the font and text components so I can display text on-screen. This is a very crucial piece for Screens to display anything useful. I will be very happy if I can get text displayed on-screen. So far, so good!

The changes have been uploaded to SVN.