A mate of mine (who's done some 'toy' bootstrapping before) and I have been toying with the idea of designing and developing a 'research' OS based almost entirely on objects. Btw, you don't need to warn us about the development of everything as we know how much work goes into even a simple kernel (and we hope we get even that far!) because its more of a practical, fun exercise in trying to design an operating system that deviates from the files, folders, square window UIs style generic modern operating system.
Our basic premise is that eveything in the system is an object of some sort. In code any hardware, file or runtime (three main types) object inherits from a SystemObject class which consequently inherits from a code-wide Object base class. A system object may represent a file, a process, a network device, a game controller (and any other type of system object).
Not only is the system represented by an object but so is the filesystem. In fact, the storage functionality more resembles a heirarchical file/folder system than actually is one.
For example, you may have two partitions on your drive for use with the OS (we've named it Objective-OS for the moment) so each is represented by a VolumeObject under the 'Volumes' collection. Under that are FileObject's. The Object file heirarchy resembles a folder heirarchy however with one key distinction; folders are files themselves and contain child file objects.
For example, your system might contain such runtime objects (linked to their respective hardware and system objects such as a filesystem or process):
Code: Select all
+ Volumes as VolumeObject collection
+ System as VolumeObject equivalent to C:\ or Macintosh HD
+ Backup as VolumeObject
+ Media as generic FileObject containing no data
- MySong as AudioFileObject of sub audio type "MP3"
+ Docs as generic FileObject containing no data
+ index as HTMLFileObject
- topics as XMLFileObject
+ Devices
+ USBDevices as USBDeviceObject collection
- GameControllers as GameControllerObject collection
+ Programs
+ Shell as ProgramObject containing children
- Thread1 as ThreadObject
Think of "MyApplication.Images.WindowBackground" as "program.exe/images/windowbackground.jpg" in a familiar environment.
MyApplication is an executable with child resource file objects. You run the application and its working object is itself so it may simply do a OpenRelative("Images.WindowBackground") call in code.
For example, in C++ you might do this:
Code: Select all
OS::ImageFileObject *image =
OS::OpenRelative("Images.WindowBackground")->As <OS::ImageFileObject>();
if (image) {
image->SetPixel(100, 23);
image->Save();
} else {
// create some random image buffer and create image file object
image = new OS::ImageFileObject(myImageData, 100, 100, OS::ImageFileTypeJPEG);
// attach to our current program object
OS::GetCurrentFileObject()->AttachChild(image);
// save image (write object to the filesystem)
image->Save();
}
// Release image object (and file handle)
image->Release();
This isn't all of our thoughts on the design but it'd great to hear your thoughts about such a model and the pros and cons. Like I said, we probably might never get far given operating systems are a monstrous amount of work no matter what you do, but this is a research OS design so we can design it however we want