Thanks for taking the time to read the source code and commenting on it. And you're right. My kernel is implemented in userspace, so I should use the term "kernel emulation". But I did find it fascinating to find out some of the reasons why a kernel is needed in the first place.
For starters, I needed to put the code of my kernel emulation (libposix-6.1.0.dll) at a specific memory address in order to get that snappy feeling when you start an OpenBSD program. Normally, 32bit DLLs in Windows are loaded at 0x10000000 (called the "ImageBase"). This causes the Windows kernel reposition the DLL because in most cases, other DLLs are already loaded there. In my case these are netapi32.dll, ws2_32.dll, iphlpapi.dll and shell32.dll among others. Making my DLLs load at an address just below the 0x10000000 boundary makes MinC programs load faster, in effect creating a space for my kernel, e.g. "kernel space".
Secondly, I needed some mechanism to reset the contents of the CPU's registers after calling into the various Windows DLLs which are not part of the Windows NT kernel. For instance, the WriteFile() function changes the %edx register, which is used by the GCC compiler to contain the high part of 64bit variables. Turns out I needed what is called a "context switch", saving the contents of all registers onto the stack, calling my kernel emulation and then restoring the registers from the stack. In Linux, this mechanism is triggered by a special interrupt (int 0x80). I decided to name the function that does this in my kernel emulation "__kernel", so in assembly I can write "call ___kernel" [0].
There is more, but I won't go into that right now. I plan to do a write-up on the topic. By the way, Microsoft also has a user space implementation of their kernel, called kernel32.dll, implementing Win32 APIs in user space.
[0] https://github.com/dboland/minc/blob/master/libposix/arch/x8...
For starters, I needed to put the code of my kernel emulation (libposix-6.1.0.dll) at a specific memory address in order to get that snappy feeling when you start an OpenBSD program. Normally, 32bit DLLs in Windows are loaded at 0x10000000 (called the "ImageBase"). This causes the Windows kernel reposition the DLL because in most cases, other DLLs are already loaded there. In my case these are netapi32.dll, ws2_32.dll, iphlpapi.dll and shell32.dll among others. Making my DLLs load at an address just below the 0x10000000 boundary makes MinC programs load faster, in effect creating a space for my kernel, e.g. "kernel space".
Secondly, I needed some mechanism to reset the contents of the CPU's registers after calling into the various Windows DLLs which are not part of the Windows NT kernel. For instance, the WriteFile() function changes the %edx register, which is used by the GCC compiler to contain the high part of 64bit variables. Turns out I needed what is called a "context switch", saving the contents of all registers onto the stack, calling my kernel emulation and then restoring the registers from the stack. In Linux, this mechanism is triggered by a special interrupt (int 0x80). I decided to name the function that does this in my kernel emulation "__kernel", so in assembly I can write "call ___kernel" [0].
There is more, but I won't go into that right now. I plan to do a write-up on the topic. By the way, Microsoft also has a user space implementation of their kernel, called kernel32.dll, implementing Win32 APIs in user space.
[0] https://github.com/dboland/minc/blob/master/libposix/arch/x8...