OSDev.org

I don't like OSes that combines address-space creation, program load and thread creation (*nix and Windows). I have a syscall to create a new address-space + a new thread (which I call CreateProcess). This new process can then decide to run some code (like some things in kernel, like the video mode-switcher) or to load an application program. I then export two kinds of application-loading services: Detach a program in a new address space (CreateProcess + load executable) and chain-run program in current process. CreateProcess doesn't clone anything. There is also a syscall to simulate fork, and in the end provide *nix compability.

rdos wrote: This new process can then decide to run some code (like some things in kernel, like the video mode-switcher) or to load an application program.

When does this new process decides this? Do you have 2 syscalls do this?

rdos wrote: I don't like OSes that combines address-space creation, program load and thread creation (*nix and Windows).

It´s just a matter of some kernel functions. I do the same as you, I have a createProcess syscall which calls the function to create a new process (for the address space) and then calls the function to create a new thread.
But I don´t know for what I would need a syscall to create a new address space and call some code in the kernel?

FlashBurn wrote:

rdos wrote: This new process can then decide to run some code (like some things in kernel, like the video mode-switcher) or to load an application program.

When does this new process decides this? Do you have 2 syscalls do this?

CreateProcess is a kernel-only interface. It cannot be called directly from applications. Therefore, any driver in kernel-space can use CreateProcess to create it's own isolated thread. The executable manager device-driver uses it to create a new address-space & thead for running a new program (detached). The video device driver uses it to create a new address space for the video-mode switcher which has a special IO permission map that allows all IO-accesses when the video-mode switcher calls the real-mode BIOS to switch video mode. The kernel debugger also uses CreateProcess in order to be sure that it cannot be corrupted by faulty kernel-threads running in the default kernel address space (kernel debugger has a known-valid address space).

To applications, there are two modes of creating new address-spaces: The Windows-like way which creates a new address-space and runs the application there and the *nix way that uses fork and exec. Previously, I could emulate Windows CreateProcess to such a high degree that I could handle Borlands 32-bit debugger. Work on fork is not yet fully finalized, but the basics is in-place. It won't really be finalized until I try to port GCC and LIBC, which would need a functional fork. Currently, the main environment is OpenWatcom, which has native support for RDOS, both applications and device-drivers. This environment uses the Windows-style CreateProcess and the DOS-style application chaining.