OSDev.org

Hello everyone, I am new here (and also to OS development). This probably sounds like a stupid question, but please bear with me as I'm a beginner. Me and a friend are working on an OS and ran into a little problem. We would like to expose an API similar to how the Windows API exposes its API (not necessarily a "DLL" system, but just a way that other programs can access functions for creating threads/processes(future), outputting text to the console, etc.) How is this usually done? For the sake of sake of simplicity lets say we have a DLL with functionality to create a Window (user32.dll). When "CreateWindow" is called by the process, how does it access a global window list without running into memory protection problems, or anything of that sort?

If you understand what I am trying to ask, and my entire concept is incorrect, please correct me (I am very confused). Thanks in advance.

It depends where the implementation is. If you implement the GUI in the kernel (like it is in Windows), the library function will excecute a system call into the kernel, solving the permissions problem. If you implement the GUI in userspace (like it is in Unix/Linux), the library function will use some sort of IPC (probably through another system call) to communicate with the program that is running the GUI. This applies to any sort of OS function, not just the GUI.

However, you probably shouldn't use DLLs. Instead use shared libraries. They are almostthe same thing, except shared libraries use position independent code while DLLs don't. Using a DLL like method will complicate everything and with the advent of x86_64 non-PIC libraries are rather unnecessary.

The normal way (and probably the simplest to implement) is to create a library that implements the API. If the API matches the syscalls (the mechanism that allows user mode code call supervisor mode code) closely this will be a very thin layered library and perhaps the functions could even be inlined in the header files.

The windows API does however not always closely match the syscalls and the API-libs here is in turn using the ntkernel.dll (or what's its name is) that is more in line with the syscalls. The linux libc also has a lot of userspace code that does more than is directly supported by the syscalls.

Don't know about the "create window". Let's use a simpler example, opening a file.

The standard C function to do so is fopen(), which is given a file name and a "mode" string. There is also a POSIX function called open(), which is given a file name and a "mode" integer. Effectively, fopen() parses the mode string, sets the corresponding bits in an int, and passes the call to open(). In the end, however, no user-space C library can actually open the file, it needs the kernel for that.

Calling the kernel (aka "system call") can only be done on the assembly level, because you have to use one of the low-level ways to "invoke" the kernel: raising an interrupt, calling SYSENTER, calling SYSCALL, something like that. That means you don't have a comfortable C-style parameter list, you have to pass your parameters in registers. Which registers, and how to invoke the kernel, is the actual API / ABI.

Let's say your OS does system calls by invoking interrupt 0x80. The number in EAX tells the kernel which function is requested (1 for opening a file, 2 for closing a file, 3 for removing a file, 4 for printing a string, etc. etc.). Each function then defines which further parameters are passed in which register. In our case, EAX is 1 (open a file), so the kernel knows it will find a pointer to the filename in EBX and a "mode" integer in ECX. It can thus satisfy the required service, put a return code into EAX and return from the interrupt.

On the application side, this is normally done in a small C wrapper, so you don't have to do the register "magic" yourself. In the case of opening a file, this wrapper is the open() function (which, in turn, is called by fopen()).

I hope this sheds some light on things.

Solar wrote:I hope this sheds some light on things.

Very much so, thanks a ton!

Also, thanks everyone else. I really appreciate the quick responses!