5 ms·

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

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

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.