[quietbritishjim]

Sounds very interesting but it's quite short on details. If it's not Cygwin, then what is it?

> MinC is a tiny kernel which runs on Windows. The rest of the software was taken verbatim from OpenBSD, version 6.1. This means that by installing MinC, you run OpenBSD on your Windows machine at native speed.

How does it run this kernel? Presumably (?) it's running in user space, so how do these other tools communicate with it? Are they native(ish) Windows binaries like those built for Cygwin?

I suspect this could be an ingenious technical achievement but it's just hard to tell what exactly it is.

[delta_p_delta_x]

> If it's not Cygwin, then what is it?

Looking at the source code[1], it appears to be analogous to MinGW in the MinGW:GNU/Linux:Windows relationship, but replace with MinC:BSD:Windows. In other words, a minimal user-mode layer that presents BSD headers (and therefore BSD symbols, macros, and types), libraries, and core utils to end-users, thus abstracting over MSVC†.

EDIT: replace 'MinGW' with 'Cygwin' above. So it is Cygwin.

I'd say calling it a 'kernel' is quite a stretch—there is not much that runs in kernel-mode, and everything runs atop the NT kernel which does the actual 'kernel'y stuff.

[1]: https://github.com/dboland/minc

†: Until one wants to use very recent and very nice Microsoft libraries[2][3], and these fail spectacularly because MinGW doesn't know about nice MSVC-specific stuff like SAL annotations[4].

[2]: https://github.com/microsoft/wil

[3]: https://github.com/Azure/azure-sdk-for-cpp

[4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...

[quietbritishjim]

> Looking at the source code[1], it appears to be analogous to MinGW in the MinGW:GNU/Linux:Windows relationship, but replace with MinC:BSD:Windows. In other words, a minimal user-mode layer that presents BSD headers (and therefore BSD symbols, macros, and types), libraries, and core utils to end-users, thus abstracting over MSVC†.

Are you getting MinGW mixed up with Cygwin?

MinGW does not emulate Unix-style APIs on Windows. (Actually I think there are exceptions but that is not its general purpose.) Instead, it is a port of tools aimed at Unix-like OSs (e.g., Make, GCC) to Windows so that they can be used to build source code that is already targetted at Windows. For example, source code compiled with MinGW might include a call to the Win32 API CreateProcess(), but cannot include a call to the Posix API fork().

Cygwin, on the other hand, allows compiling source code intended for *nix to native Windows binaries. For example, it compile code that calls fork(), getuid(), stat(), etc. It has that user-mode emulation that you mentioned (e.g. mapping between Unix-style UIDs and Windows SIDs), which happens in cygwin1.dll.

[delta_p_delta_x]

> Are you getting MinGW mixed up with Cygwin?

I think you're right, this is probably the BSD equivalent of Cygwin.

That being said... I feel the distinction is very blurred, and even more so with the inclusion of MSYS. It seems very few people use naked MinGW, despite a few distributions[1][2] being available.

For instance, MinGW also provides `unistd.h` and `pthread.h` on top of `windows.h`. Certain distributions of MinGW provide lib{std}c++ instead of MSVC STL. Where does 'build native Windows executables from source files that are already targetted at Windows' stop, and 'allows compiling source code intended for *nix to native Windows binaries' begin?

Also, based on my comment above, MinGW doesn't do a great job at 'already targetted at Windows', because some very core libraries that rely on fundamental Windows-y constructs don't work. Personally I avoid it because of its incompleteness, and just use straight `clang++.exe` from the Windows LLVM release[4], aside a full install of the Windows and MSVC SDKs.

[1]: https://github.com/skeeto/w64devkit

[2]: https://github.com/mstorsjo/llvm-mingw

[3]: https://github.com/llvm/llvm-project/releases/download/llvmo...

[kazinator]

Cygwin is based on Newlib, which is based on numerous sources of BSD origin.

Cygwin strives for certain Linux compatibilities; the project's motto, right under the title on the cygwin.com page, is "Get that Linux feeling - on Windows".

The userland in Cygwin is based on GNU Coreutils, and such.

MinC is going for a BSD userland; its motto could be "Get that BSD feeling - on Windows".

[quietbritishjim]

I think most people don't use vanilla MinGW because you'd have to run it on Linux and cross compile. The MinGW toolkit itself (e.g. GCC) isn't targetted at Windows so ironically can't be compiled with MinGW, not even cross compiled - it needs something like Cygwin as in MSYS2. But you're right that it does provide unistd.h and I'm surprised about that. To be honest I was going to say in my comment that it doesn't but I fact checked first! I'm not sure that the bits missing count as "fundamental", I think they're all quite new bits rather than core Win32 APIs. But maybe I'm just showing my age.

Anyway, I'm sorry I've distracted away from your core point: as you've said, despite its name, it seems MinC just provides a user-mode API layer, just like Cygwin does.

[kazinator]

Using vanilla MinGW would be masochistic, given that you can install the Cygwin environment in which the MinGW toolchain is available as a package!!!

Under Cygwin, you can compile programs in the MinGW way, but you can also use any build-time tool that will compile on Cygwin.

Getting a build-time tool for MinGW means porting it to MSYS; have fun!

[assassinator42]

No you don't, MinGW(-w64) targets windows directly (with MinGW statically linked in). I've built a Windows->Linux cross-compiler that depends solely on DLLs built-in to Windows (kernel32.dll, MSVCRT.dll, and user32.dll).

Granted that was hundreds of hours, some patches (only 8 lines though), and probably a bit of masochism.

I did of course need MSYS2 command line utilities like make and bison to run the GCC configuration/make scripts. Although we use the mingw32 version of make along with the cross-compiler which also has no other dependencies (it uses cmd.exe as a shell if you don't have a bash.exe in your PATH).

[delta_p_delta_x]

> Anyway, I'm sorry I've distracted away from your core point

Side-tracks and tangents are the powerhouse of HN comments ;)

As for MinGW and Cygwin (and all the other *nix-on-Windows stuff), I take a bit more lower-level view than what (developer or user) environments they provide, or what tools they use.

In a nutshell, C++ binaries compiled with MinGW are binary-incompatible with C++ binaries compiled with MSVC, because they are built against different binary interfaces: x86_64-pc-windows-gnu (or x86_64-w64-mingw32, which appears to be a synonym) and x86_64-pc-windows-msvc respectively. The former is the C++ Itanium ABI, the latter is a partially-documented MSVC ABI.

Cygwin is an 'ABI' of its own too, because everything needs to be linked against cygwin1.dll, and when it is missing there is a runtime error. WSL1 and WSL2 from an ABI standpoint are indistinguishable—they are x86_64-unknown-linux-gnu.

This is sort of why we can have LLVM-MinGW, which is the entire LLVM suite and only LLVM binutils (see my parent comment for a link), without nary a GNU binary. It's essentially Clang, built to target the MinGW ABI (this can be built on Windows with MSVC, oddly enough).

Speaking of Linux, every glibc upgrade is essentially a different ABI (for some functions) presented to the developer—so much for Linus' assertion of 'don't break userspace'. Even if the kernel doesn't do it, the entirely user-space C library will do it for him. Oh, and musl libc is yet another ABI.

I have delved too far into the weeds of cross-compilation, and as a result I can't help but absolutely despise everything about the C and C++ ecosystem.

[bonzini]

Cygwin is not GNU/Linux either, it used newlib (developed by Cygnus in the 90s) rather than glibc. newlib is not a GNU project, though it lived under the Sourceware umbrella together with GCC, gdb and binutils.

[regularfry]

I think it's a "kernel" in a similar way that user-mode linux is a kernel, right? It's not, but it looks like one to the programs it runs.

[amiga386]

Cygwin is WINE in reverse. It provides POSIX APIs in a Windows DLL, and the implementation tries to map them immediately to Windows API calls. You should then be able to take source written for Unix and you should be able to compile it and have it run on Windows.

MinGW is a GNU toolchain for writing Windows-native software... that happens to be used quite often to compile Unixy non-Windows software, so they added MSYS which is derived from Cygwin and works like Cygwin (a DLL providing POSIX APIs implemented using Windows APIs), to make it easier to compile and run Unixy software unmodified.

WSL is a VM that runs your choice of Linux kernel and distro as a guest OS, and adds integrations with the host system that make it seem much more native than it really is.

[kevin_thibedeau]

WSL2 is a VM. WSL1 is Wine in reverse. They run ELF binaries compiled against the Linux ABI. Cygwin/Msys is a Posix compatability layer for PE binaries.

[ryao]

I thought WSL1 implemented Linux's ABI in the NT kernel and uses a Linux userland. Wine reimplements the a Windows userland and emulates NT kernel services in userland. The two do not seem the same, although the intention of running Linux software on Windows is the opposite of the intention of letting UNIX system run Windows applications.

[lproven]

> I thought WSL1 implemented Linux's ABI in the NT kernel

Yeah, I thought that too, and said so in an article. It would be the clean, logical, elegant way to do it and inline with the history of NT.

I got angry denials from several Microsofties on Twitter!

It isn't at all.

WSL1 is an offshoot of the now-cancelled Android runtime for Windows.

They wanted to run Android's JVM/Dalvik apps on Windows Mobile... but discovered more and more native OS calls. So, they ended up implementing 90% of a Linux kernel emulator in userland.

Later, they made it standalone and complete enough to run a real Linux userland on top, and marketed it as a Linux runtime.

It is tragic to me that senior MS execs are now proud of this approach and scolded me for thinking otherwise.

My conclusion is that MS no longer has:

• Any kernel engineers who really understand how NT works deep down;

• Anyone skilled enough to modernise the NT kernel's POSIX personality to be Linux personality;

• Anyone in authority who realises it ought to have these things;

• Nobody left who feels shame at this.

[jborean93]

They call them pico processes and have documented them quite well [1]. The pico processes has a userland and kernel component and is quite interesting from a technical perspective.

[1] https://learn.microsoft.com/en-au/archive/blogs/wsl/pico-pro...

[kevin_thibedeau]

That's a byproduct of NT being designed from the start to have subsystems for alternate execution environments and was the path of least resistance. Conversely, it wouldn't be logical to make Wine tightly integrated into the Linux kernel when it had broader portability goals.

[ryao]

Interestingly, they recently pushed ntsync into the Linux kernel specifically for use by wine.

[haolez]

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.

[mikepurvis]

Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different.

Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.

[apatheticonion]

but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM.

For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux.

A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage.

WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.

[amiga386]

The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other.

For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead.

So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally.

See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8

[adgjlsfhk1]

I do think that talk is way too kind to the windows design. they're trying to make the argument that windows filesystem isn't slow, but the talk is how fixing the problem took 3 months of optimization and direct help from Microsoft. all of this could be avoided if Microsoft made their filesystem not ridiculously slow

[mikepurvis]

I find the filesystem and network integration to be a lot nicer than I what I get from a Virtualbox VM. Having the WSL system able to see the host as /mnt/c and also have the WSL filesystems appear in Windows Explorer is pretty darn convenient.

I know conventional VMs do this kind of thing too, but I've always found it more awkward to set it up, you have to install special tools or kernel modules, etc. With WSL it just works out of the box.

[trallnag]

WSL2 supports all the good stuff like systemd. With WSL1 I'd have to rely on Windows utilities or handroll a lot more things

[bornfreddy]

> WSL2 supports all the good stuff like systemd.

That has to be sarcasm, right?

Then again, I see WSL as a poor man's Linux ("poor man" being a developer in some enterprise who can't pick their tools freely due to some IT policy).

[freedomben]

I felt the same way. WSL1 was game changing, while WSL2 isn't much better than just running my own VM, and in some ways is worse.

The one exception: my God filesystem performance on WSL1 was ass, and not an easy problem to fix

[teo_zero]

> A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need.

Something like skeeto's w64devkit? https://github.com/skeeto/w64devkit

[red_admiral]

For a subset of "run shell scripts", I'm a fan of the one-executable-file busybox for windows.

[EasyMark]

pulling up terminal running WSL instead of running a VM is a superior experience to me when all I need is terminal coding and python/bash scripting without having to block off a chunk of RAM for a virtual machine

[pjc50]

WSL1 mapped Linux file API calls directly to NTFS file API calls.

Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.

[moomin]

Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.

[jandrese]

Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.

[heftig]

Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.

[wvenable]

> but it was too complex to maintain and Microsoft decided to take the easy road.

The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference.

At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.

[emulio]

> it was too complex to maintain and Microsoft decided to take the easy road.

This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft.

This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that

[lproven]

> both WSL1 and WSL2 continue to be developed

I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022.

So I have to call [[citation needed]] on that.

[lproven]

> it was too complex to maintain

Nah. It was fine.

Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.

[nialv7]

Cygwin is not wine. Wine lets you run existing windows executables unmodified on Linux. Cygwin does not let you run ELFs on windows.

[amiga386]

Good point, using wine as the interpreter for PE executables is another cool part of the WINE project.

But it is the case that you can build a Windows application from source on Linux and link it with libwine, in the same way you can build a Unix program from source on Windows and link it with cygwin.dll -- I seem to remember some time ago CorelDRAW (or at least Corel Photo-Paint) was made available for Linux that way, officially supported by Corel.

[thingfish]

I started out by creating a dll file with all the system calls implemented. Later I learned how a kernel actually works. So I rewrote it, emulating an interrupt to run in a separate kernel space. Could you name some of the details you want described?

[skybrian]

What you said here is helpful.

Maybe start with an explanation of what it does without referring to Cygwin? That would be for people unfamiliar with Cygwin. Edit: actually you already did that, but starting off with “not Cygwin” is confusing.

You could also explain how your approach differs from Cygwin, for people who do know it.

[cryptonector]

But it's still a user-mode program, not a VM, right? That would be a lot like "user-mode Linux", which is a project that compiles the Linux kernel as a user-mode program that essentially is somewhere between a container and a VM.

So what happens when you "boot" MinC? It sounds like it runs all the usual OpenBSD services and what not. But are all of those new Windows processes, or just new threads in the one MinC process?

Also, do processes inside MinC get to interact with the Windows host filesystem and networking in any way?

BTW, this is very cool!

[nialv7]

It's a kernel in the library operating system sense [0]. A kernel doesn't have to run in a privileged context.

[0]: https://en.wikipedia.org/wiki/Operating_system#Library

[quietbritishjim]

I hadn't heard the term library operating system before, but what is described at that link is nothing like your project.

The "kernel" referred to at that link is a full actual kernel, with networking, proceed scheduling, device drivers and hardware access, etc. It means the full implementation of those features. The reason it can be linked into the application's process as a library is because it's taking about a situation where there's only a single application running on the whole machine (presumably a virtual machine). The kernel and application then run together in a single memory space, with the kernel code (maybe the whole thing?) running in kernel mode.

You have implemented the user mode API that makes system calls to the (Windows) kernel. That is not a kernel in any sense. It is confusing and wrong to call it a kernel.

[cryptonector]

Isn't that what user-mode Linux is?

[quietbritishjim]

User mode Linux does actually run something like a real kernel in user space. OP is just providing a POSIX API with no kernel implementation whatsoever. It just forwards those calls to the Window's API. The library OS concept linked to above is different again – that is an actual kernel running in kernel mode but as part of a unikernel (kernel code and application code linked together into a single process).

Still pretty cool but overshadowed by the claim that they've written a whole kernel.

[cryptonector]

I see. Thanks!

[potus_kushner]

What I'm looking for is conceptually similar to cygwin - where the "kernel", or better worded - the POSIX API - is provided as a library, not as a separate process that communicates via IPC with the minC "app"'s process. However, unlike cygwin, there should be a static libminc.a (or .lib) that can be used to make standalone binaries that don't need an external DLL like cygwin1.dll. MingW is not an option here as it lacks too many POSIX apis, but it could serve as the base toolchain to compile minc itself, and the programs linking against it, by switching out (or overriding) the default library and include paths. Basically making it use MinC's libc and OS syscall layer, but keeping its WinAPI interface. That would allow cross-compiling minc applications from linux, without having to use a win32 binary toolchain. Alas, the short project description on the website and on the github repo don't address any of these (imo crucial) details.

[quietbritishjim]

> I started out by creating a dll file with all the system calls implemented. Later I learned how a kernel actually works. So I rewrote it, emulating an interrupt to run in a separate kernel space. Could you name some of the details you want described?

"to run in a separate kernel space" You emulated those interrupts, and they really run in a separate kernel space [1]? Or you mean it's emulated as if it runs in a separate kernel space?

If it's really running in kernel mode, as you are literally saying, how is it doing that? Is it running in some virtual machine manager like Hyper-V or as something like a driver in the Windows kernel? How does it interact with the hardware e.g. does it access the same file systems that Windows does, and how does it coordinate that?

Looking at the source code I don't see any references to the Windows WDK / DDK (driver development kit) but a lot of references to user-space Windows API functions. I also don't see most of the actual BSD kernel [2]. For example, could you point me at the process/thread scheduling code (like sched_bsd.c [3])? Are you sure it's a kernel? Are you sure it runs kernel space, not user space after all? It seems like it might actually be an abstraction layer that emulates the user-space BSD system calls but runs in user-mode and make use of (only) the Windows kernel. If so, what do you mean by "emulating an interrupt" - how are you intercepting them? If you're just providing the C API functions to link into the application, and that don't actually trigger those interrupts at all, that is something a lot less ambitious. Still something impressive and worthwhile but you're setting readers up for disappointment if you describe it as something that it isn't.

That is what Cygwin does by the way. It implements POSIX APIs in user space. It does not claim to be a kernel (because it's not) or to run in kernel mode (because it doesn't). The thing is, I can understand you may have chosen the name "MinC is not Cygwin" because it works in roughly the same sort of way as Cygwin but is a different implementation. But the name, along with the description as being "a tiny kernel", suggests that it's not Cygwin because it works in a fundamentally different way, i.e., running the actual BSD kernel in actual kernel mode.

[1] https://en.wikipedia.org/wiki/User_space_and_kernel_space

[2] Mirror is available at: https://github.com/openbsd/src/tree/master/sys/kern

[3] https://github.com/openbsd/src/blob/master/sys/kern/sched_bs...

[thingfish]

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...

[quietbritishjim]

Thanks for taking the time to reply.

What you've done is very impressive. But, as I've said elsewhere, it's overshadowed by you insisting on calling it a "kernel" when it's not. Please stop doing that, and please don't include that claim in your future write up of how it works. The thing is, some submissions to Hacker News are by people who really have written their own actual kernel so readers have no reason to doubt your claim. Many will believe you really have written (or ported) an actual operating system kernel and then be disappointed when they realise you haven't, rather than excited by what you have achieved.

> My kernel is implemented in userspace

Your kernel is not implemented in userspace, because you have not written a kernel. User mode Linux is an actual real kernel running in user space. It is just a totally different concept.

> I should use the term "kernel emulation"

No, you shouldn't. This is coming a bit closer to the truth but still wrong. You have emulated **the system call interface** of a kernel. The implementation of the system-call interface is only a teeny tiny part of a kernel.

> ... the code of my kernel emulation (libposix-6.1.0.dll) …

You mean, the code of your system-call interface emulation.

> 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".

No, that is not "kernel space". None of those DLLs (netapi32.dll, ws2_32.dll, iphlpapi.dll and shell32.dll) are part of the kernel. They all run in user mode. Please read the Wikipedia article on user mode vs kernel mode that I linked to above, and understand that none of your code is running in kernel mode at all.

> By the way, Microsoft also has a user space implementation of their kernel, called kernel32.dll, implementing Win32 APIs in user space.

kernel32.dll does run in user space but it is not a kernel or an implementation of a kernel. Its name is a historical artefact. (Its name can be traced back to a component that, 40 years ago, in Windows 1.0, actually was a kernel. But even by Windows 3.0 it was already just an interface to some kernel services, not a kernel implementation.)

> ... after calling into the various Windows DLLs which are not part of the Windows NT kernel. For instance, the WriteFile() function ...

None of these DLLs are part of the kernel! (By the way, "WriteFile()" function is implemented in kernel32.dll. But it's still not part of the NT kernel.)

> 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).

No!

* "Context switch" means switching between user-mode processes, not between user mode and kernel mode. It is done by the scheduler within the kernel.

* int 0x80 triggers a system call on Linux, not a context switch.

* A system call doesn't trigger the save/load of registers, as you said. Instead, you need to save/restore the registers yourself. (i.e., to make a system call on Linux you would do: (1) stash registers on stack; (2) call int 0x80; (3) restore registers.)

* Saving registers and restoring them is part of many function calls, not just system call interfaces. It's just that usually the compiler takes care of it for you, rather than something you need to hand craft in assembler.

--------------

Here's how I'd attempt to describe what you've done in a way that isn't misleading:

Typically, if you're going to going to emulate the user-mode API of one operating system within another, you'd simply implement the user-mode functions of one directly in terms of the other. For example, you might implement the Posix open() API by reformatting the arguments and directly calling the Win32 OpenFile() function. In MinC, the user-mode API is instead emulated at the system call level. This means that the user mode DLL (libposix-6.1.0.dll) has the same code as the user-mode API in BSD except that the system-call interrupt is replaced with a call to the syscall emulation code.

[thingfish]

Thanks for taking the extra time making me consider dropping the term "kernel". But I need a term wich reflects my efforts. So I fed your description at the end into ChatGPT, asking for a one-word description. This is what it came up with:

Paravirtualized – commonly used when an interface mimics low-level system behavior but redirects to a host implementation; this fits your syscall-level emulation.

Interposed – describes the interception and redirection of system calls or API behavior.

Emulated – broad but accurate; emphasizes imitation of behavior at the syscall layer.

Rehosted – suggests the POSIX environment has been adapted to a different host OS.

Substituted – captures the idea of replacing one system mechanism with another.

Intercepted – emphasizes the capture and redirection of syscalls.

Translated – suitable if there's transformation between POSIX calls and Windows kernel APIs.

Adapted – highlights compatibility through minimal changes.

Bridged – suggests a connection or interface between incompatible systems.

Virtualized – somewhat general, but appropriate if the environment feels like a lightweight VM layer.

Interesting, but not very creative. Something like Ted Nelson's "transclusion". Suggestions? Anyone?

[somat]

Very cool project, what did OpenBSD do post 6.1 that interfered with the project tracking later versions?

By which I mean, completely understandable to pick a version and stick with it. If I were trying to develop a tricky layer replacement that is what I would do. However it is also tempting to try to follow upstream. I wonder if one of obsd's infamous breaking innovations actively interfered with the project.

For those unfamiliar, where Linux has a "don't break user land policy" and this is fine and good for a project like linux. It does mean that the linux project is terrible at handling needed user land breaks. Where OpenBSD's policy is more "we got really good at breaking user land" They are so good that most of the time the users don't notice. But I would not want to try and ship closed source commercial software targeting obsd.

[dolmen]

Nowadays, if I wanted to port Unix (non-GUI) software written in C to Windows I would first try to compile it with the Cosmopolitan LibC.

https://justine.lol/cosmopolitan/