OSDev.org

Hi!

First things first this is not talking about my other operating system which I have mentioned around here a few times before. This is another thing which I'm thinking about seeing as that other one was such a muddle with disk drivers implemented in one way and window managers implemented in another way (that was worse than Microsoft Windows and a far cry from the Unix philosophy of "everything is a file"). So now I'm getting better than "everything is a file" and making everything inside your computer and operating system an object. Yes, everything is an object. Windows are objects, buttons are objects (child objects of windows for that matter) executable programs loaded into memory are objects. Even files are objects.

But anyway enough of that because this thing is so ridiculously complicated that I don't think that any reasonable programmer would ever be able to implement it especially given the muddled description which I am about to bombard you with:



And the reason for that muddle is because I can't fully explain this concept in words because I'm not good at explaining things like this in terms of words because I can understand the concept abstractly but I find words too linear (and sequential access) for explaining things like these clearly. So I hope that you can understand at least a bit of that muddled document thing because I'm afraid that this is such a wonderful concept but I cna't fully explain it in terms of words. It's locked up inside my head until I can somehow implement it in a way that others can appreciate (which I don't think I'll be able to do that either because I have to program it in terms of words as well, although I'm not too bad with programming in words LOL!).

Thanks,

onlyonemac

I'm sure you've already read these, but just in case you haven't, I'm working along the same lines as you are talking about:

Object Oriented Operating System: viewtopic.php?f=15&t=27971
Object Oriented File System: viewtopic.php?f=15&t=28181

In summary:

• The OS deals with, and manages, objects
• Objects contain instance data (stored as structs), properties (to access data within structs) and methods (to perform actions on structs)
• An object has a "type" or "class", which is an object that defines the properties and methods of that object (run-time reflection)
• Objects can be stored in memory or on disk in the same format (if I can figure out how to make this work)
• Memory management and garbage collection will work for both system memory and storage devices (if at all possible)
• All methods are co-routines, and return enumerable collections, which can be iterated over (will require a significant rewrite of existing code)
• Methods can be chained in order to execute functions on return values, which will automatically execute the method on each returned item in the collection (similar to jQuery)
• Device drivers are implemented as device specific classes that implement device type specific interfaces (i.e. IStorageDevice.GetTotalSize())
• Applications can either use devices directly (exclusive access), or use virtual devices provided by the OS (shared access). Both real and virtual devices will use the same interface, for simplicity.
• The OS will include common object types (Image, AudioClip, Document, etc.), and will use custom classes to convert to/from different formats (.jpg -> Image -> .bmp)

Only some of this has been implemented, and some of these items will require significant redesigns, so it'll probably be a few versions before I can get a lot of this stuff working.

Also, because I couldn't find any modern IDE or tools to do Assembly development, I decided to write my own "language" using XML.

You can see my progress on https://ozone.codeplex.com

I've also got some code in there for other platforms, like C64, GameBoy and Raspberry Pi, if you're interested...

I'm currently trying to decide how I want to store some of this information in memory, and on disk, so we may be able to help each other figure out how to make all of this work.

In any case, good luck on your vision. And, as always, don't take any negative feedback too personally...

The way you are trying to deal with object network is a bit compromised. You have decided to keep sibling information with every object, but such kind of information is usable only for objects that belong to only one object tree. Would there be an object network (not a tree or many owner trees) then your design will fail.

Why just not use references?

The same applies to the "Parent" of each object.

This design seems to assume that each object can only have one "parent". Unless I'm missing something, this would mean that if you wanted to add an object to more than one collection, it would have to be copied, making it a completely separate object. If so, changes to one of those objects will not be reflected in the other copied objects, unless you add more code to handle this automatically... (not recommended)

My OS is heavily object oriented, but being a microkernel I don't want the kernel to be too heavily involved in object lifecycle. I'm thinking of introducing a standard object model in my userspace libraries, maybe when I get around to C++ or Javascript support, but at the moment everything is just C structs and trees.

The main thing I've got is the concept of opaques. When a service wants to give an object to some other program to manipulate, it registers a (small, arbitrary) chunk of data with the kernel and gets back a unique identifier. When one gets transferred from process to process the old identifier is invalidated and a new one generated for the recipient. The process that created the opaque can dereference it and get it's original data back, which might be a file name and rights mask, or an index into a database, or an address range, or anything else. The service also gets a notification whenever one of it's references gets transferred. There is a syscall to post messages on a reference, which the kernel translates to events with the dereference data attached for the originator, so you get transparent RPC. This means that I can give services the ability to reference count shared resources, enforce different security policies, and have capability based security and addressing all without fixing the object model.

So far it seems to work, but it's not had much testing. Mostly it came about as a solution to problems in my user-mode driver model, but the idea of capabilities rapidly grew on me and I redesigned several other subsystems around it. The big problem I probably have right now is that I haven't fixed a way of defining or exchanging the interface definitions for objects that are going through this.

No I have not read those. I don't think that we can help each other because the way that you are intending on implementing things (and also the general structure of your model) is quite different from mine and there are a lot of holes in mine as well. But yes I am also going to use an "Object File System". As for IDEs I just use a text editor and a command-line assembler/compiler (whatever is appropriate for the type of code which I am working with).I don't know what you mean by "referances" but yes each object can only have one parent (i.e. I am only using trees here; there is no support for more complex nework-style structures). No object can be in more than one "collection" (as you are calling it) because every object can only exist in one place (just as with real world objects). For example a toy in your bedroom would be called "my_house.my_bedroom.large_cupboard_full_of_toys.my_favourite_toy" - you would not call it anything else so why should it have more than one parent? Also this kind of structure is the way that libxml does it and I find that that works quite well (I think it's generally called a linked list).

The reference model we are talking about would come into play if you were to have an Employee class, and you wanted a collection of, say, full-time employees, and another collection of part-time employees, and you wanted a collection of contractors.

A full-time contractor may need to be in both the Full-Time collection, and in the Contractor collection at the same time. If an object can only have one parent, which "collection" do you use?

You may be better off just getting rid of the whole Parent concept. This is just a suggestion, though. You may have already thought all of this through.

What if I move the toy to the kitchen? Would it still be "my_house.my_bedroom.large_cupboard_full_of_toys.my_favourite_toy"? Or "my_house.my_kitchen.large_table_full_of_meals.my_favourite_toy"?

No it would become the latter, because the former no longer describes the object. The object is now in a different place in the tree.

Yes that is a difficult example and I'm not sure how I would handle it but if we talk about computing concepts rather than employees and contractors it seems to me that having everything in only one place is more logical. Consider this: os.drivers.disk.hdd.ide; os.drivers.net.wifi.pci; disk0.documents.stories.1948; mem.text_editor.executable.main_thread; mem.text_editor.gui_objects.main_window.format_toolbar.font_list. With all of those examples (which are just wild ideas of the kinds of object structures that I am expecting to implement with this) it doesn't really make sense to have anything in more than one place at the same time.

It doesn't make sense for a physical object to be in more than one place at a time, but what about non-physical objects?

Let's say that you want to keep track of a list of "favorite" songs, per user.

User 1 has marked Song 1, Song 2 and Song 3 as favorites.

User 2 has marked Song 2, Song 3, and Song 4 as favorites.

How many "songs" are there? 6?

The problem is that all "objects" are not physical objects. And that objects have "relationships" to other objects, that don't necessarily fall under the "parent/child" paradigm.

User 1 has 3 favorite songs. Song 2 has 2 users that have marked that song as a "favorite". This is a "network" type of relationship, where "connections" between objects are transitory, or temporary. They can be added or removed over time. This is difficult to model using a parent/child relationship model... which is why your "media" folder on your machine where your media player application tries, desperately, to store and organize all of your movies, videos, music videos, pictures, and songs always looks like a train wreck. (And why they pretty much only work for a single user...)

The Files/Folders paradigm that we have all grown up with does a good job of "emulating" real world objects that can only exist in one place at any given time. However, the reality is that all of those Files and Folders are just table entries with pointers to addresses that contain raw bytes.

(A more accurate representation would be shredded pieces of paper scattered over a football field, some of which contain a description on how to find other pieces of paper, and what order the shredded pieces should be read in.)

At best, all you can really say is that User 1, User 2, Song 1, Song 2, Song 3 and Song 4 all exist somewhere in memory or on disk (or both), and that from time to time, they can be related to each other in some way.

Just something to think about...

In that example the songs are not the objects. The song files (with the actual audio data in them) would be file objects on a disk but when it comes to favourite songs they would be stored by referance, just like how conventional song files are indexed under other operating systems. The idea of being able to group objects into arbitrary collections is certainly an interesting idea (and allows one to finally move beyond the restrictions and limitations of traditional directory-based operating systems which is in some ways something that I've always wanted to get away from) but having a slightly more traditional approach was my design idea and the main purpose of the objects is to unify the internal structure of the operating system and to make things more modular in their design, not to provide an alternative method of indexing songs.

However this has got me thinking that maybe I should scrap parent/child links all together (and the ugly mess that that makes with having to follow linked lists all around the disk) and go for a collection-based approach instead. It certainly sounds interesting, although implementing heirachical collections (something which is, of course, desireable) would result in messy linked lists again.

Exactly. And thus one could quite easily put the same "object" (disk sectors in this case) under more than one "collection" (folder/file in this case). That is what hard links are all about.