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

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

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

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.

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!

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

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

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.

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.