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.