OSDev.org

(There is no OS Theory forum, so it goes here.)

OK. You're probably thinking "oh, yeah, C++ for the kernel, blah blah blah". I would. But, no, it isn't about that.

The theory is to have a very tiny asm-only kernel. It'd do the very low level stuff needed to get the kernel to a level where it can run an ASM kernel-level interpreter for a highly object-oriented, fast, and not entirely unpleasant to code in (;)) language. Presumably, due to speed concerns, the unsuitability of just about every current interpreted language for e.g. driver development, and the needs-asm-interpreter part, it'd be a newly-created language. The interpreter would immediately initialize itself and then create a new instance of the (singleton, of course ) Kernel class. The constructor for Kernel would then initialize the things needed to have an OS that can do more than the very basics, and do something like OSLoader.start(loads of hardware info here...) or something of the sort. It would boot up the OS, and then continue...


... You might have noticed the distinctly modular, microkernel-esque design this is leading to. Of course, this is a direct side-effect of object orientation....

...to display a login prompt, call User.login with the details, etc

Now, a few things are required for organizing this to work well.

1. User integration with instances
A user should be able to "own" an instance, so that an object initialized by a user is not accessable by any others (unless, for example, theUser.omnipotent returns true ).

2. Subinstances
When you get a GUI and a window manager, you need to say "this instance is running under the gui". Traditional process-based OSs use parent processes to do this. But you have a subclass, why not a subinstance? i.e. an instance of a class that is a child of another instance of another class.

Anyway, this means:

1. Applications are classes
Simple. Use other classes in your app, organize it, sure, but an application could be defined something like this:
... and then to run it, a shell would do something like:
Also, because an interpreter is running all the time, startup time of apps is almost non-existant: if you can create a class and run a method on it in X time, that's how long it is to start a program!

"But what about files?" Simple. There are no files. Of course, you can persist objects, and it'd use a filesystem for that, but it would be abstracted away. For paths, it'd use e.g. "/Microsoft/products/WindozeXP" as a filename - direct mapping of namespaces to paths. If you wanted to, for example, give PNG support:
And applications would just use "Image.getViewer(...)" and get PNG back. Maybe a .persist(...) method for persisting them.

Comments on this "theory" are welcome... maybe if I get much, much better at ASM I'll try and make a start... maybe

Edit: Actually, that run() stuff is probably wrong - string arguments that you have to parse yourself? No, I don't think so. Attributes you can set before calling run(), yes.


To show the possible benefits of this:
...voila. Object oriented cat(1).

Or:
Note "delete this" to get rid of an instance --> close the program.

There *should* be a theory or advanced design section. Otherwise, theory threads get beleaguered by a flood of basic hardware questions.

Anyway, it looks like you've got a really neat idea. Running a bytecode interpreter (or a real interpreter) for an object-oriented language in-kernel has certainly been thought of before, but I like your thinking of everything-is-an-object.

Now here's my question: how will this system support concurrency?

I also have one suggestion: drop the Java-style single dispatch and go with Common-Lisp-style generic functions and (multi)methods. To show the benefits of the change, to writing a Java/Object-Pascal interface for a Set container. Let's call it ISet. ISet must support not only the unary operators of include and exclude, but the binary operators of union, intersection and difference. If multiple classes implement ISet, how do you implement the binary operators? Generally you either add a function to copy a set to ISet (if you want the binary operators to create a new set rather than alter an existing one), or you add a function to ISet that will return the contents of a set.

Now rewrite the whole thing using generic functions and multimethods. You can now use a cloner function or a contents function for the general case, but you can also write multimethods to handle specific combinations of actual classes passed to your operators.

But I ramble. Good luck!

It would be nice if there is an "Idea"/"Theory" section.

Yes, I noticed the pseudo-language I was using was leaning on the Java side - I personally don't really like Java, but blending some of its good aspects with the experimental parts of Lisp dialects and Smalltalk might just work...

ehird wrote:(There is no OS Theory forum, so it goes here.)

OK. You're probably thinking "oh, yeah, C++ for the kernel, blah blah blah". I would. But, no, it isn't about that.

The theory is to have a very tiny asm-only kernel. It'd do the very low level stuff needed to get the kernel to a level where it can run an ASM kernel-level interpreter for a highly object-oriented, fast, and not entirely unpleasant to code in (;)) language. Presumably, due to speed concerns, the unsuitability of just about every current interpreted language for e.g. driver development, and the needs-asm-interpreter part, it'd be a newly-created language. The interpreter would immediately initialize itself and then create a new instance of the (singleton, of course ) Kernel class. The constructor for Kernel would then initialize the things needed to have an OS that can do more than the very basics, and do something like OSLoader.start(loads of hardware info here...) or something of the sort. It would boot up the OS, and then continue...


... You might have noticed the distinctly modular, microkernel-esque design this is leading to. Of course, this is a direct side-effect of object orientation....

...to display a login prompt, call User.login with the details, etc

Now, a few things are required for organizing this to work well.

1. User integration with instances
A user should be able to "own" an instance, so that an object initialized by a user is not accessable by any others (unless, for example, theUser.omnipotent returns true ).

2. Subinstances
When you get a GUI and a window manager, you need to say "this instance is running under the gui". Traditional process-based OSs use parent processes to do this. But you have a subclass, why not a subinstance? i.e. an instance of a class that is a child of another instance of another class.

Anyway, this means:

1. Applications are classes
Simple. Use other classes in your app, organize it, sure, but an application could be defined something like this:

Code: Select all

class(Microsoft.products.WindozeXP) extends(Application) {
    method main(string[] args...) { // Where ... means "Take all other arguments and put them in the array of this definition"
        // Do stuff
    }
}

... and then to run it, a shell would do something like:

Code: Select all

theapp = Microsoft.products.WindozeXP.new
theapp.run(args passed in)

Also, because an interpreter is running all the time, startup time of apps is almost non-existant: if you can create a class and run a method on it in X time, that's how long it is to start a program!

"But what about files?" Simple. There are no files. Of course, you can persist objects, and it'd use a filesystem for that, but it would be abstracted away. For paths, it'd use e.g. "/Microsoft/products/WindozeXP" as a filename - direct mapping of namespaces to paths. If you wanted to, for example, give PNG support:

Code: Select all

class(MyCoolTechnologies.PNG) extends(Document) implements(ImageProtocol) {
    // Implement the stuff that ImageProtocol requires in its standard way here... and something to register it with Image
}

And applications would just use "Image.getViewer(...)" and get PNG back. Maybe a .persist(...) method for persisting them.

Comments on this "theory" are welcome... maybe if I get much, much better at ASM I'll try and make a start... maybe

Edit: Actually, that run() stuff is probably wrong - string arguments that you have to parse yourself? No, I don't think so. Attributes you can set before calling run(), yes.


To show the possible benefits of this:

Code: Select all

include System.Input.getLine;

class(MyApp) extends(Application) {
    method main() {
        while (System.Output.append(getLine()));
    }
}

...voila. Object oriented cat(1).

Or:

Code: Select all

class(MyGUIApp) extends(GUI.Application) {
    method main() {
        myWindow = new GUI.DialogBox("Hello, world!");
        myWindow.setLabel(new GUI.Label("Testing, testing."));
        myWindow.setButtons(new GUI.Button("OK"), new GUI...) // varargs
        while (event = GUI.recieveEvent()) {
            if (event.class == myWindow.CloseEvent) delete this;
            GUI.waitForEvent();
        }
    }
}

Note "delete this" to get rid of an instance --> close the program.

Wow. Sounds good. Similar to my design, a bit more complicated (and thought out) though. It sounds like security would be easy to implement, seeing as nearly all the code would be "managed" in Windowe terms. An object oriented design definitely makes the whole design much simpler, and easier to implement, which makes me think that what I should be doing


Would all of the code (outside of the kernel, apps n' such) be handled by the interpreter, via the kernel?


Will it be a pure-interpreter, JIT or compiled into bytecode? The the biggest problem w/ high level languages like Java, C#, Ruby, Python, Lisp etc. is that they need a lot of library stuff written in a low level language that can interface w/ the kernel and hardware more effectively, coding on an OS written in one of these languages would be neat

I agree, there should be a "Advanced Design/Theory" section.

Crazed123 wrote:There *should* be a theory or advanced design section. Otherwise, theory threads get beleaguered by a flood of basic hardware questions.

Ok this is meta-topic I guess, but we could start a convention at put [THEORY] in front of topics concerning theoretical issues (since they are minority I guess).

anon19287473 wrote: Wow. Sounds good. Similar to my design, a bit more complicated (and thought out) though. It sounds like security would be easy to implement, seeing as nearly all the code would be "managed" in Windowe terms. An object oriented design definitely makes the whole design much simpler, and easier to implement, which makes me think that what I should be doing


Would all of the code (outside of the kernel, apps n' such) be handled by the interpreter, via the kernel?


Will it be a pure-interpreter, JIT or compiled into bytecode? The the biggest problem w/ high level languages like Java, C#, Ruby, Python, Lisp etc. is that they need a lot of library stuff written in a low level language that can interface w/ the kernel and hardware more effectively, coding on an OS written in one of these languages would be neat

I agree, there should be a "Advanced Design/Theory" section.

Pretty much all of the code, yes. The language would probably have kernel-and-devices-etc-restricted-only inline asm, to allow almost the whole OS to be written in it. If the interpreter dies, the tiny asm kernel would print a message informing the user and halt. Hopefully, the interpreter wouldn't die

Not compiled into bytecode, that's for sure. The idea is that you can use the "object browser" to view a tree, open e.g. Kernel.Filesystems.ext2fs, edit the code that it contains, then delete the current instance of that filesystem on a partition, and reinstate it (e.g. "delete Kernel.Mounts.HDA.0.1", "Kernel.Filesystems.ext2fs.mount Kernel.Drives.HDA.0.1") - and your changes would take place. So, any change is "instant". This would, naturally, make app development much nicer All the integration and power of a low-level language, without the compilation. JIT is interesting, but requires implementing for each processor (correct me if I'm wrong).

Edit: I think this OS could win the "Hardest to Switch To" award, both for its uncommon design and the fact that you'd have to learn a new language that you can't use elsewhere

ehird wrote: The theory is to have a very tiny asm-only kernel. It'd do the very low level stuff needed to get the kernel to a level where it can run an ASM kernel-level interpreter for a highly object-oriented, fast, and not entirely unpleasant to code in (;)) language. Presumably, due to speed concerns, the unsuitability of just about every current interpreted language for e.g. driver development, and the needs-asm-interpreter part, it'd be a newly-created language. The interpreter would immediately initialize itself and then create a new instance of the (singleton, of course ) Kernel class. The constructor for Kernel would then initialize the things needed to have an OS that can do more than the very basics, and do something like OSLoader.start(loads of hardware info here...) or something of the sort. It would boot up the OS, and then continue...

I don't see a point in having an ASM kernel. I'd say it buys you more or less nothing. Ofcourse if you like writing in ASM, then it's ok, but really, it buys very little.

I also don't see point in running everything with an interpreter. Direct interpreter will never be fast enough, so you'll probably have to analyze the code enough anyway, that making it a compiler is just a question of adding a codegen to the interpreter. Once you have a basic (=bad, slow) compiler (which is still likely to be comparable to decent interpreter) it's relatively easy to start adding optimizations.

... You might have noticed the distinctly modular, microkernel-esque design this is leading to. Of course, this is a direct side-effect of object orientation....

I don't agree. You can have object-oriented monoliths, and non-object oriented microkernels. The point is, stuff is modular, when components don't need to care about other components. Object-orientation is neither necessary nor sufficient for making a system modular.

...to display a login prompt, call User.login with the details, etc

I'm going to claim that how the login prompt is displayed is going to be one of the less important parts of any system's design. In fact, even Unix kludges logins on top of setuid() system call (well, in a sense the actual kludge is the setuid() syscall itself).

1. User integration with instances
A user should be able to "own" an instance, so that an object initialized by a user is not accessable by any others (unless, for example, theUser.omnipotent returns true ).

If you have secure pointers (in the sense of references in Java) then you don't necessarily need "user" to be able to have somebody own an object. The only necessary condition then, is that only your "omnipotent user" is able to enumerate object in the system.

You should read about E-language capabilities if you haven't.

2. Subinstances
When you get a GUI and a window manager, you need to say "this instance is running under the gui". Traditional process-based OSs use parent processes to do this. But you have a subclass, why not a subinstance? i.e. an instance of a class that is a child of another instance of another class.

Eh? Why do you need such a thing? In Unix the process parenthood has one important function: it allows the parent process to wait for it's child to terminate, and receive the exit status of the child process.

You can implement such functionality in many ways. You could simply have the garbage collector notify certain object that another object was collected. But for practical purposes, I don't think even that is necessary.

If you have threads in your system, then you can have one thread be the parent of another thread, and the whole issue goes away. If you have a garbage collector, then nobody cares if the object representing the application has been collected. What everyone cares is whether the thread created for the application is still running.

It's also worth noting, that you can easily get rid of your parent in unix, by doing fork(), then exiting the original process, and continuing in the new child (which get inherited by init). That's more or less how you start daemons in Unix.

1. Applications are classes
Simple. Use other classes in your app, organize it, sure, but an application could be defined something like this:

Don't forget that "application" or "process" is for the combination of some data, some code, and a thread of control. In cases where all the data is local to the code, it's rather painful to create a whole class just to have a procedure. There is lots of programs which don't necessarily benefit from having a class at all.

Also, because an interpreter is running all the time, startup time of apps is almost non-existant: if you can create a class and run a method on it in X time, that's how long it is to start a program!

You'll still have to load the class for the program, unless you keep all classes in memory all the time. In a typical system, most of the startup time for a process would be used in loading the program.

Ofcourse there's some overhead in traditional system from creating a new protection domain and all, and this can be significant in cases where there is no significant I/O (eg. webserver fork()ing on each new request) but then again there are usually easy ways to avoid such cases (eg. writing a better webserver).

Rest of the overhead is probably related to managing threads, which you'll only avoid if you don't create new threads (eg. webserver works by using poll() or some of the better scaling newer alternatives like epoll in Linux). Once that starts being an issue, I think you'll have the resources to forget about interpreters.

"But what about files?" Simple. There are no files. Of course, you can persist objects, and it'd use a filesystem for that, but it would be abstracted away. For paths, it'd use e.g. "/Microsoft/products/WindozeXP" as a filename - direct mapping of namespaces to paths. If you wanted to, for example, give PNG support:

This is wonderful idea, except in some cases it's actually rather nice to have files. Like, suppose you want to serve files over network (webserver again) and you would prefer not to care about what files they are. You just want to read certain amount of bytes, and dump it to the socket, when when the socket is ready for more, you want to read some more, and dump that to the socket as well.

One of the advantage of files, is that it's possible to handle huge files, since they need to be read into memory at once. If you want to maintain any sort of performance, the application should be aware of this. Sure, you could use a B-tree of objects, but then you just end up re-inventing filesystems in applications, which isn't necessarily such a good thing.

Even media streams (like movies) become complicated problems, not to speak of stuff that requires random access to potentially huge amounts of data. Filesystems are pretty nice for stuff that requires an indirection anyway.

------

I don't think the concept of object oriented systems is a bad idea. But I also don't think it's good idea to take them too far.

Think of how your ideas scale to large amounts of users or data, and it'll probably work for one user with a little data as well.

Since I'm stubborn, I disagree with you.

mystran wrote: I don't see a point in having an ASM kernel. I'd say it buys you more or less nothing. Ofcourse if you like writing in ASM, then it's ok, but really, it buys very little.

You don't want to have to mess about in C when you're writing a minimal-as-possible >base< of a kernel, with an interpreter that really HAS to run as fast as computer-aly possible.

mystran wrote: I also don't see point in running everything with an interpreter. Direct interpreter will never be fast enough, so you'll probably have to analyze the code enough anyway, that making it a compiler is just a question of adding a codegen to the interpreter. Once you have a basic (=bad, slow) compiler (which is still likely to be comparable to decent interpreter) it's relatively easy to start adding optimizations.

Modern computers are very fast. ASM is fast. Combine the two and the interpreter wouldn't be that bad. JIT could improve it further. The trouble most interpreters have is startup time, and with this design that issue is gone.

mystran wrote:

... You might have noticed the distinctly modular, microkernel-esque design this is leading to. Of course, this is a direct side-effect of object orientation....

I don't agree. You can have object-oriented monoliths, and non-object oriented microkernels. The point is, stuff is modular, when components don't need to care about other components. Object-orientation is neither necessary nor sufficient for making a system modular.

Correct. But an object-oriented program with encapsulation, good design, namespaces etc is going to be more likely to be more modular than, say, a 1000 line fortran program.

mystran wrote:

...to display a login prompt, call User.login with the details, etc

I'm going to claim that how the login prompt is displayed is going to be one of the less important parts of any system's design. In fact, even Unix kludges logins on top of setuid() system call (well, in a sense the actual kludge is the setuid() syscall itself).

I'm walking through an imaginary "system startup", to show how early on the object-orientation starts. Of course it isn't an important detail, though.

mystran wrote:

1. User integration with instances
A user should be able to "own" an instance, so that an object initialized by a user is not accessable by any others (unless, for example, theUser.omnipotent returns true ).

If you have secure pointers (in the sense of references in Java) then you don't necessarily need "user" to be able to have somebody own an object. The only necessary condition then, is that only your "omnipotent user" is able to enumerate object in the system.

You should read about E-language capabilities if you haven't.

Yes, but it's better to integrate the user model with the design than use a different protection feature and try and make it synchronized with users.

mystran wrote:

2. Subinstances
When you get a GUI and a window manager, you need to say "this instance is running under the gui". Traditional process-based OSs use parent processes to do this. But you have a subclass, why not a subinstance? i.e. an instance of a class that is a child of another instance of another class.

Eh? Why do you need such a thing? In Unix the process parenthood has one important function: it allows the parent process to wait for it's child to terminate, and receive the exit status of the child process.

You can implement such functionality in many ways. You could simply have the garbage collector notify certain object that another object was collected. But for practical purposes, I don't think even that is necessary.

If you have threads in your system, then you can have one thread be the parent of another thread, and the whole issue goes away. If you have a garbage collector, then nobody cares if the object representing the application has been collected. What everyone cares is whether the thread created for the application is still running.

It's also worth noting, that you can easily get rid of your parent in unix, by doing fork(), then exiting the original process, and continuing in the new child (which get inherited by init). That's more or less how you start daemons in Unix.

Sure. It's not neccessary. Nor is a mouse, but I'd bet you use a mouse on a computer daily. It's a thing that's nice to have.

mystran wrote:

1. Applications are classes
Simple. Use other classes in your app, organize it, sure, but an application could be defined something like this:

Don't forget that "application" or "process" is for the combination of some data, some code, and a thread of control. In cases where all the data is local to the code, it's rather painful to create a whole class just to have a procedure. There is lots of programs which don't necessarily benefit from having a class at all.

If it's an object-oriented design, a class is basically a must. Otherwise persistance, object browsing etc would go haywire. One-line hacks turn into larger apps fast, too.

mystran wrote:

Also, because an interpreter is running all the time, startup time of apps is almost non-existant: if you can create a class and run a method on it in X time, that's how long it is to start a program!

You'll still have to load the class for the program, unless you keep all classes in memory all the time. In a typical system, most of the startup time for a process would be used in loading the program.

I'm talking about the typical "startup time" of an interpreter process - which is in the order of a few millenia on average.

mystran wrote: Ofcourse there's some overhead in traditional system from creating a new protection domain and all, and this can be significant in cases where there is no significant I/O (eg. webserver fork()ing on each new request) but then again there are usually easy ways to avoid such cases (eg. writing a better webserver).

Rest of the overhead is probably related to managing threads, which you'll only avoid if you don't create new threads (eg. webserver works by using poll() or some of the better scaling newer alternatives like epoll in Linux). Once that starts being an issue, I think you'll have the resources to forget about interpreters.

<no comments >

mystran wrote:

"But what about files?" Simple. There are no files. Of course, you can persist objects, and it'd use a filesystem for that, but it would be abstracted away. For paths, it'd use e.g. "/Microsoft/products/WindozeXP" as a filename - direct mapping of namespaces to paths. If you wanted to, for example, give PNG support:

This is wonderful idea, except in some cases it's actually rather nice to have files. Like, suppose you want to serve files over network (webserver again) and you would prefer not to care about what files they are. You just want to read certain amount of bytes, and dump it to the socket, when when the socket is ready for more, you want to read some more, and dump that to the socket as well.

One of the advantage of files, is that it's possible to handle huge files, since they need to be read into memory at once. If you want to maintain any sort of performance, the application should be aware of this. Sure, you could use a B-tree of objects, but then you just end up re-inventing filesystems in applications, which isn't necessarily such a good thing.

Even media streams (like movies) become complicated problems, not to speak of stuff that requires random access to potentially huge amounts of data. Filesystems are pretty nice for stuff that requires an indirection anyway.

Yes. The "Document", etc classes would abstract this away, but also provide the low-level calls for apps that really, really need them. As for networking, I don't see the relation to files. If you mean like webservers, ftp etc then it's just a matter of writing a class that abstracts the raw ftp calls to integrate with the persistant objects.

mystran wrote: ------

I don't think the concept of object oriented systems is a bad idea. But I also don't think it's good idea to take them too far.

Think of how your ideas scale to large amounts of users or data, and it'll probably work for one user with a little data as well.

This is a hobby OS community. Who actually seriously uses their created OSs/the OSs they test as a serious main OS?

I think a compromise will work better than 1) Orthogonal persistence or 2) Normal filesystem. Why not have a hierarchical namespace of objects that get persisted in a filesystem? Some filesystems (Reiser4 comes to mind) actually support files that are also directories (you can read them, write to them, and change-directory into them), and this kind of structure would map perfectly to arbitrary trees of objects that need to persist themselves.

Crazed123 wrote:I think a compromise will work better than 1) Orthogonal persistence or 2) Normal filesystem. Why not have a hierarchical namespace of objects that get persisted in a filesystem? Some filesystems (Reiser4 comes to mind) actually support files that are also directories (you can read them, write to them, and change-directory into them), and this kind of structure would map perfectly to arbitrary trees of objects that need to persist themselves.

That's a good idea. But how would we emulate it on "lesser" filesystems? Object and .Object_dir? Or something?

Remember that you can't easily persist any object with volatile state. Stuff like threads can be supported on per-class basis, but stuff like network sockets will never be persistent.

Sure. so only persist objects where implements(Persistable).

Of course, objects would only be persisted if you clicked the "persist this!" button

ehird wrote:

anon19287473 wrote: Wow. Sounds good. Similar to my design, a bit more complicated (and thought out) though. It sounds like security would be easy to implement, seeing as nearly all the code would be "managed" in Windowe terms. An object oriented design definitely makes the whole design much simpler, and easier to implement, which makes me think that what I should be doing


Would all of the code (outside of the kernel, apps n' such) be handled by the interpreter, via the kernel?


Will it be a pure-interpreter, JIT or compiled into bytecode? The the biggest problem w/ high level languages like Java, C#, Ruby, Python, Lisp etc. is that they need a lot of library stuff written in a low level language that can interface w/ the kernel and hardware more effectively, coding on an OS written in one of these languages would be neat

I agree, there should be a "Advanced Design/Theory" section.

Pretty much all of the code, yes. The language would probably have kernel-and-devices-etc-restricted-only inline asm, to allow almost the whole OS to be written in it. If the interpreter dies, the tiny asm kernel would print a message informing the user and halt. Hopefully, the interpreter wouldn't die

Not compiled into bytecode, that's for sure. The idea is that you can use the "object browser" to view a tree, open e.g. Kernel.Filesystems.ext2fs, edit the code that it contains, then delete the current instance of that filesystem on a partition, and reinstate it (e.g. "delete Kernel.Mounts.HDA.0.1", "Kernel.Filesystems.ext2fs.mount Kernel.Drives.HDA.0.1") - and your changes would take place. So, any change is "instant". This would, naturally, make app development much nicer All the integration and power of a low-level language, without the compilation. JIT is interesting, but requires implementing for each processor (correct me if I'm wrong).

Edit: I think this OS could win the "Hardest to Switch To" award, both for its uncommon design and the fact that you'd have to learn a new language that you can't use elsewhere

Neat, very much like what im doing (a self-modifying OS), more as novelty. The OOP idea is a great idea to organize the greater structure, many "props".

Edit: I think this OS could win the "Hardest to Switch To" award, both for its uncommon design and the fact that you'd have to learn a new language that you can't use elsewhere

Definitely.

ehird wrote:

Crazed123 wrote:I think a compromise will work better than 1) Orthogonal persistence or 2) Normal filesystem. Why not have a hierarchical namespace of objects that get persisted in a filesystem? Some filesystems (Reiser4 comes to mind) actually support files that are also directories (you can read them, write to them, and change-directory into them), and this kind of structure would map perfectly to arbitrary trees of objects that need to persist themselves.

That's a good idea. But how would we emulate it on "lesser" filesystems? Object and .Object_dir? Or something?

I would emulate it this way: for object Object, you have a directory named Object. In that directory are subdirectories for each object Object owns, and a file named .contents (or contents.dat with the Hidden attribute turned on, whatever) that holds the persisted object.

Of course, talking about any filesystem at all assumes the security model used in that filesystem, but what with the interpreted language you can probably build object-based security on top of any file-system security.