standard object library

[VolTeK]

i am using the idea of incorporating a standard file object library in my os or in other words say in order for the programmer to make a dialog box appear for his os, he/she will have to load that object from a standard library or file (same thing, but i dont care) i have been wondering who else uses this technique, but its kind of obvious that with any os its a good idea. i myself think asking this is a stupid idea, but im interested in who else does this.

[NickJohnson]

You mean, have a object oriented API for your OS?

[gravaera]

I'm going to assume you mean to imply the use of C++.

Your kernel, assuming it's written in C++, is a huge mess of structs, and functions, with each function which should be linked to by user apps being a class method, requiring a 'this' pointer.

For maximum compatibility, it is advised that you find a way to filer all of the kernel resources down to apps in a C style manner, without the need for this pointers. Some folks would implement a POSIX library whose public interface is, of course, C linkage POSIX functions, and within the library, the necessary code to locate the kernel class/resource is hidden from the user;

The idea is to have user apps not have to withstand the complication of linking to C++ methods.

There are better ways (imho) to implement a layer for translation to kernel classes (my own is much faster by comparison), but that's an implementation detail.

-All the best
gravaera

[NickJohnson]

For maximum compatibility, it is advised that you find a way to filer all of the kernel resources down to apps in a C style manner, without the need for this pointers. Some folks would implement a POSIX library whose public interface is, of course, C linkage POSIX functions, and within the library, the necessary code to locate the kernel class/resource is hidden from the user;

I don't know about that. At the lowest level, that's probably true for compatibility's sake, but it's good to have interfaces that match the language you're using. If everything that runs on the system is written in C++, for example, it would be better to give a C++ object interface for system functions in the base system. That goes even more for languages that are very different than C, like Assembly, Basic or Lisp. Either way, the user program isn't directly requesting from objects in the kernel - everything has to go through a system call at some point.

[pcmattman]

Hi,

If everything that runs on the system is written in C++, for example, it would be better to give a C++ object interface for system functions in the base system.

In this case I would say that you would have a C++ "Native Interface" through which applications use your kernel's interface via C++ objects, and a C-style "POSIX Subsystem" that uses a more conventional method of POSIX-compatible C functions. That way you get POSIX compatibility and your own native interface without requiring a compromise (if designed well).

Either way, the user program isn't directly requesting from objects in the kernel - everything has to go through a system call at some point.

Very true. Even if the userspace API is C++, at some point it will still be converted into a C-style system call (ie, 'write', 'read', C functions that call kernel system calls) in order to jump the gap between userspace and the kernel. In my opinion, what your goal as a developer of a C++ API should be is to reduce the number of C-style system calls made to an absolute minimum.

My project, when we implement our native interface, will approach this in a unique way by actually serialising all the important data in userspace and transmitting a single buffer to the kernel, where the data is unserialised and an action is performed (all this using our asynchronous event system). Whilst it isn't perfect it's far better than having a C-style system call interface (or building hte native API upon the POSIX API). Ideally this means we would have one C function that all objects use in order to execute an action.

As an example (not real code, and definitely not how I'd implement this), you might want to read a file in the VFS:

Code: Select all

size_t VFS::read(File &file, uintptr_t location, uintptr_t buffer, size_t len)
{
    // Some form of locking would go here
    m_AdditionalMetaData = file.serialize();

    // Store paramaters for serialisation
    m_p1 = location;
    m_p2 = buffer;
    m_p3 = len;

    // Run system call - calls serialise on the given object
    return ret = syscall(this);
}

If you were merely building on top of a C API without a method to serialise and transmit objects, it'd look more like this:

Code: Select all

size_t VFS::read(File &file, uintptr_t location, uintptr_t buffer, size_t len)
{
    int n = open(file.getName(), O_RDWR);
    lseek(n, location, SEEK_SET);
    size_t ret = read(n, buffer, len);
    close(n);
    return ret;
}

(Note that a File class would be more appropriate in this case as it could store important file metadata as part of the class. Again, this is just an example).

The point is, unless you have a decent method to serialise object data and then unserialise it on the other side, you're going to lose the appeal of a C++ API pretty quick: it'll just be a layer on top of a C API.

Cheers,
Matt