8 ms·

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 s

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 2y ago
> 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 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 https://github.com/microsoft/wil [3]: https://github.com/Azure/azure-sdk-for-cpp https://github.com/Azure/azure-sdk-for-cpp [4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-annotations?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...
- quietbritishjim 2y ago
  > 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 2y ago
    > 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 https://github.com/skeeto/w64devkit [2]: https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw [3]: https://github.com/llvm/llvm-project/releases/download/llvmorg-20.1.0/LLVM-20.1.0-win64.exe https://github.com/llvm/llvm-project/releases/download/llvmo...
    - quietbritishjim 2y ago
      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.
      - delta_p_delta_x 2y ago
        > 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.
- regularfry 2y ago
  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.
thingfish 2y ago
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 2y ago
  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.
- quietbritishjim 2y ago
  > 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 https://en.wikipedia.org/wiki/User_space_and_kernel_space [2] Mirror is available at: https://github.com/openbsd/src/tree/master/sys/kern https://github.com/openbsd/src/tree/master/sys/kern [3] https://github.com/openbsd/src/blob/master/sys/kern/sched_bsd.c https://github.com/openbsd/src/blob/master/sys/kern/sched_bs...
amiga386 2y ago
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.
- haolez 2y ago
  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.
  - pjc50 2y ago
    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.
    - jandrese 2y ago
      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 2y ago
        Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
    - moomin 2y ago
      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.
dolmen 2y ago
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/ https://justine.lol/cosmopolitan/
somat 2y ago
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.

delta_p_delta_x 2y ago

> 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 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 https://github.com/microsoft/wil [3]: https://github.com/Azure/azure-sdk-for-cpp https://github.com/Azure/azure-sdk-for-cpp [4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-annotations?view=msvc-170 https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...

quietbritishjim 2y ago
> 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 2y ago
  > 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 https://github.com/skeeto/w64devkit [2]: https://github.com/mstorsjo/llvm-mingw https://github.com/mstorsjo/llvm-mingw [3]: https://github.com/llvm/llvm-project/releases/download/llvmorg-20.1.0/LLVM-20.1.0-win64.exe https://github.com/llvm/llvm-project/releases/download/llvmo...
  - quietbritishjim 2y ago
    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.
    - delta_p_delta_x 2y ago
      > 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.
regularfry 2y ago
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.

thingfish 2y ago

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 2y ago
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.
quietbritishjim 2y ago
> 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 https://en.wikipedia.org/wiki/User_space_and_kernel_space [2] Mirror is available at: https://github.com/openbsd/src/tree/master/sys/kern https://github.com/openbsd/src/tree/master/sys/kern [3] https://github.com/openbsd/src/blob/master/sys/kern/sched_bsd.c https://github.com/openbsd/src/blob/master/sys/kern/sched_bs...

amiga386 2y ago

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.

haolez 2y ago
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.
- pjc50 2y ago
  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.
  - jandrese 2y ago
    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 2y ago
      Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
  - moomin 2y ago
    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.

dolmen 2y ago

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/ https://justine.lol/cosmopolitan/

somat 2y ago

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.