Update

Hi Everyone, This week is preperation for Passover so I wont be on the computer hardly at all however I am still be thinking away... I have doing alot of thought on the multi-tasking design and so far it sounds very feasable although slow. I talked about it with my father and he liked it. Why is it so slow? Well because of the way the stack is stored/restored in each message switch. Because of limitations I had with making the system compatible with Cobalt, I had to use Dynamic memory and feature memory to deal with passing and returning memory. This means that the stack needs to be copied from an object to dynamic memory and then again to the local stack which is quite a performance hit. When does a switch happen? On any API call which involves calling another module execution. So if you call UIWindowDraw it is actually switching from your message to another message which deals with the window drawing. This will be tested to see how slow it is but in general, there is quite a bit of general traffic slowdown in theory. If it gets to slow, I might allow the API to be able to execute sub-calls directly without having to switch but then you get an even more slow-down when having to switch to another thread, so I will see how it works out. So what else has been happening? The object storage has been through a few changes. One of the problems with a reference only object storage was that you could get chains of orphaned objects where they referenced each other but you had no way to get to them from the root object. To solve this, all objects are stored in a tree just like a normal file system however each object is a file and a folder in one. Every object can also hold references to any other objects. However references and child objects have no difference apart from a single function CoreObjectIsLink which can check if an object is a reference or a child under a specific object parent. Another thing is links (references) do not have a handle, you cannot point to them because technically there have no representation. If you try to get the handle of a link, you get the handle of the object it points to. If you delete an object, it deletes all its children and all thier references. However if another object references any of those objects, the references are removed when they are encountered. This saves the need of searching the system for references. However each object has a reference count so that it can know how many objects are referencing it. This is a bit like WinFS and allows an object to act on its reference count to do things like removing itself if it has no references. This is one of the reasons that the object storage has to be multi-tasking because if it is going to execute methods on objects it needs to be able to switch to other threadswhile doing maintence work. Because when you delete an object, it first notifies all child objects of this operation and if they are deletable, then it goes through all child objects removing them and only then removes the parent object. If any child object fails to be removed (because they did not handle the previous notification) then the parent object is notified of this failed remove and it can decide what to do. Note that static objects (that dont have a new/free method) dont get notified (because they have no constructor/deconstructer).