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.