MinC Is Not Cygwin
235 comments
·April 23, 2025ryao
thingfish
You're right. I'll change it to "Windows XP or later".
bandrami
IDK, I wouldn't be surprised if it ran on Windows 2000 (still the best OS Microsoft ever made)
haglin
Yeah, Windows 2000 was probably the best operating system Microsoft ever produced. It had no crashes, a snappy/intuitive/sleek user interface, and DirectX support for games. I am currently running Mac OS X because I never liked Windows XP/Vista/10/11.
In hindsight, the progress Microsoft made in the ten years between Windows 3.0 (1990) and Windows 2000 seems incredible. They transitioned from a 16-bit shell running on top of DOS to a fully-fledged operating system with a hardware abstraction layer, preemptive multitasking, permissions, a registry, proper device drivers etc.
Twenty-five years later, there has been basically no progress.
At a minimum, I would have expected something like the Knowledge Navigator
heavensteeth
right, I suspect "NT" is the category they're looking for.
guerrilla
What's wrong with 2003?
tomrod
Hilarious that this was literally my exact thought.
dimava
Also you are confusing Visual Studio and VSCode
tomrod
Win2k?
NikkiA
It might run on 3.1 and 3.11 via win32s, there were occasional odd things that would run on the win32 subsystem as was adapted to 3.1/3.11, but not 95/98/ME.
skissane
> It might run on 3.1 and 3.11 via win32s
It won't. I see lots of calls to CreateThread/etc in the source. Win32s didn't support threads.
JdeBP
ryao's above proposition is the converse, that only Win32s in DOS+Windows ME was adequate to running this, and that the prior Win32s in DOS+Windows 98 and DOS+Windows 95 was not.
To be honest, though, I very much doubt that anyone has fully tested either that claim or what the headlined article itself claims. A quick look at the source turns up things that require the full Windows NT security model, wide character versions of the API, and threads.
It probably does not run on any version of DOS+Windows, and "except Win95 and Win98" in the headlined article is likely a fumbled way of saying that, which didn't account for those not being the only versions of DOS+Windows that exist.
skissane
> ryao's above proposition is the converse, that only Win32s in DOS+Windows ME was adequate to running this, and that the prior Win32s in DOS+Windows 98 and DOS+Windows 95 was not.
Win32s was for Windows 3.x only
Win32 for 9x/Me was originally called Win32c, but then Microsoft renamed it to just plain Win32, despite the fact that name was shared by the much more complete NT-based implementation.
gwbas1c
I wish there was a date on that page.
Today in 2025, "It runs on all versions of Windows, except Win95 and Win98" comes across as a poetic way to say "we make an effort to support older computers running older versions of Windows."
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...
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.
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.
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.
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
> 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.
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...
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.
jdndndb
I don't get the negativity in this thread. Looks like a cool project, keep up the good work
thingfish
I don't mind. Many of the comments are about my incorrect use of the term Linux. In a way, they are right. But if one wants to teach Automotive Technology to future BMW mechanics, you start them working on a VW Beetle. Wax on wax off.
kergonath
> I don't mind.
That’s good. It’s an interesting project and the discussion here is overall very interesting. Thanks for posting it.
oblio
You're wrong, it should be BMW Beetle.
:-p
mrweasel
It might be because it's a teaching tool, but the introduction contains a lot of fundament misunderstandings and factual mistakes.
Take networking, one of the screenshots shows the output of ifconfig. That teaches you almost nothing about Linux networking, because ifconfig in Linux and OpenBSD are two very different tools, and you'd probably not teach people to use ifconfig on a modern Linux distro. Same for the boot process... rc and systemd are not the same, not even close.
It is a very cool project but almost all references to Linux is wrong.
skrebbel
> almost all references to Linux
The word "Linux" only occurs on the page once.
smcameron
Which is weird, because the stated purpose of MinC is: "MinC was written to help children at vocational education learn Linux without the hassle of virtualization." And it does this by running OpenBSD on Windows? That's really strange. Why not just run linux if the goal is to teach/learn linux? Perhaps the actual goal is not well stated, or I misinterpret what is really meant by those words.
m2f2
How long will cygwin lifetime be?
A proud cygwin user myself, with cygwin in the PATH since the 2000s, I recently sideloaded Ubuntu under wsl.
Right now, wsl is my primary terminal app, I've mounted C:\ as /c, added a symlink to bypass the ugly Onedrive default name, and... I'm happy.
Slowly, I removed 90% of the mixed BAT scripts, converted to bash the rest, and I now enjoy it.
As the old timer that I am, I limp around powershell, so no luck with that.
Cygwin on the other hand seems to be slowly dying, as more and more packages are now unsupported/unmaintained, with Redhat apparently willing to smother it at the first viable moment.
Any thought?
dredmorbius
There's a long history of Unix-like environments on Windows dating to the 1980s: MKS Toolkit (Mortice Kern Systems, later incorporated into Windows Services for Unix, precursor of WSL), UWIN from David Korn, Cygwin, and others.
I'd experimented with several of these before I realised that what I wanted wasn't Windows running Unix-like utilities, but a real honest-to-goddess Unix system, which was spelled "Linux".
colordrops
I'm using the nixos wsl image and a majority of my linux workstation setup was just installed with almost zero effort. happy and impressed. Using the Ameliorated.io debloater plus nixos wsl makes Windows almost tolerable.
dist-epoch
git-for-windows (the default Windows git client) includes a bash.exe and a selection of gnu utils.
it's based on MSYS2, so it's native. maybe you should check this one out.
mananaysiempre
GfW is remarkably hostile to installing any additional components (e.g. I’ve needed to get ahold of rsync), especially compared to normal MSYS2, which is as flexible as any Linux distro.
ormax3
it seems possible to install GfW into an existing MSYS2:
thingfish
I was a limper too, until I saw this demonstration by the creator of PowerShell from 2004: https://www.youtube.com/watch?v=4mBRA7pqITM
38
as a former long time cygwin user, my advice is dump cygwin ASAP. its not really good for anything anymore. the only reason I ever used it was for a C compiler, but Zig does that way better than Cygwin ever did. also honestly I don't even use C anymore unless I need to, I write most stuff in Go, but both Go and Zig can cross compile. finally I am using windows terminal and PowerShell
self_awareness
OpenBSD userland used to teach Linux?
Wouldn't it be better to either teach BSD with current toolset, or to use GNU tools to teach Linux?
max_
Its such great recursive acronym. [1]
dev_l1x_be
> MinC is a Unix emulator for Windows, based on the OpenBSD operating system
If anybody wondering.
nasretdinov
I think there used to be a similar project for Linux, called CoLinux. However using a BSD kernel probably is a more sustainable choice if anything because it's much smaller and simpler
zoobab
I used CoLinux back in the days, it was bluffing:
ryao
That is user mode linux. Cooperative Linux is something else:
https://en.wikipedia.org/wiki/Cooperative_Linux
Interestingly, Wikipedia claims that User-mode Linux inspired Cooperative Linux.
zoobab
"Under Windows Vista, I have installed Pubuntu, which is a distribution based on Ubuntu Hardy with a CoLinux kernel. Now I run User Mode Linux on top of CoLinux on top of Vista"
Maybe UML can run on top of MinC?
Does MinC accepts ELF linux binaries?
hatly22
I wish they'd include a datestamp in these intro pages. This looks like it could be from any era.
dredmorbius
Generally agreeing with you (date your work, peeps), checking the Wayback Machine often helps. First capture from 23 April 2025, which would be today:
<https://web.archive.org/web/20250423103309/https://minc.comm...>
There was a January 2024 HN submission requesting feedback by thingfish suggesting early work at roughly that time:
<https://news.ycombinator.com/item?id=38951099>
Thingfish: Adding creation / last modified dates would be helpful.
thingfish
I understand your point, but I'm intrigued. Could you elaborate with some kind of example why it is disappointing that people don't date their web-pages? Is this a generic problem or is it with specific web-sites only?
dredmorbius
Time matters.
A recently-released project may be intriguing but something risk-averse entities (individual/organisations) might prefer to hold back on for fear of, let's call it "infant death syndrome".
An old project with no active development is generally perceived as "dead", with risks that security- or bug-fixes could remain unaddressed for long times, or that there may be current zero-day exploits possible.
An old project with a healthy activity stream counters both points: the project has exhibited staying power and addressing ongoing maintenance concerns. Even active projects might give caution (say: feature creap or enshittification), but that's beyond the scope of merely giving initial / latest activity timestamps.
NB: I've well over 30 years of professional IT experience in shops ranging from small operations to multi-billion-dollar firms. Advocating for, or against, various technologies and solutions is a large part of that role. It's also something that carries into my choices for my own personal systems.
I'd be unlikely to do much with MinC myself as I don't use MS Windows, though it fits in with a long tradition of similar tools I have used, often with fond memories, including Cygwin, David Korn's UWIN, MKS Toolkit (Mortice Kern Systems, licenced by Microsoft for early versions of WSU, precursor to WSL, I've just learned), VMWare, Xen, qemu, Virtualbox, Parallels, etc. These have different architectures but all basically address the problem of "run programs from OS X on OS Y", which turns out to be a fairly-frequently-encountered challenge. I might well recommend MinC to those with such needs.
emmelaich
Agree. Looking at github, the most recent commit is yesterday and some are two years old.
oblio
Really cool, I guess this is meant for kernel hacking and also as a hobby project?
Cygwin itself is really easy to install, you can just copy the folder around, you don't need the installer.
cryptonector
If you were wondering, this is how fork() is implemented: as threads: https://github.com/dboland/minc/blob/8fe124625d2262b5bd83e0a...
thingfish
Cool. You found out why MinC is not Cygwin. To fork(), Cygwin starts a second copy of the entire executable. CreateThread() is much closer to what UNIX does. Any thoughts? BTW, there's another "easteregg".
cryptonector
Not sure I'll look for the other "easteregg", though I noticed that you set the new thread's impersonation token, which is presumably how you implement setuid() and friends [yes, that is how you implement them] -- is that the other easteregg? I also see that you use the last RID of SIDs as the UID/GID, and that you have hardcoded passwd(4)/group(4) entries, so you only support local users (which is fine).
Oh, ah, _task_copy(). You swap stacks... I think because of course.
Your execve() is real though, since you use CreateProcessAsUser(), which is good.
The compromise you made is pretty neat, though obviously some things might not work well. Though I'm guessing this is working quite well for you.
Your file names are weird; they often tell me nothing about what to expect to find in them.
I looked for fork() because that's the difficult one to implement on WIN32. What Cygwin does is some crazy gymnastics that sometimes fails. You might know that I think fork() is "evil" [0], or if you hadn't, you do now, and I guess you're likely to agree with that take, but I'd love to hear your thoughts on that, because clearly you've thought about fork().
I've to say that you've clearly thought a lot about this, and though I've not tried it (and probably won't) you seem to have done an excellent job.
[0] https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c...
thingfish
> I've to say that you've clearly thought a lot about this, and though I've not tried it (and probably won't) you seem to have done an excellent job.
Thank you. I needed that. I started the project in 2016 and have been obsessed with it since then. The weird thing is that I never had to use workarounds or hacks that are mentioned by the Cygwin team [0]. For instance, the select() call does map cleanly on top of the Win32 API. I just needed to use WSAWaitForMultipleEvents() instead of WaitForMultipleEvents() (the other "easteregg"). Why the Cygwin people didn't figure this out baffles me. I guess their current code base doesn't allow the rewrite. My big breakthrough was when I realized that the "inconsistent interfaces" [1] in Win32 file handles can be implemented as virtual file systems. One for each handle type (char, disk, pipe, etc). That was my "throwing away 1000 lines of code" [2] moment.
As to the weird file names, I use the file names OpenBSD uses. My rule is to always use the file name of the header (.h) file where the system call is declared in OpenBSD. I also use their struct and constant names, prefixed with "WIN_".
The "fork is evil" thing is discussed a lot in the programmers community. I myself find it quite clever. Threads are highly volatile and are very hard to program without running into race conditions. The solution is to make a copy of everything the child will be using: duplicate file descriptors, the stack, globals (rss). The kernel does all this for you in one system call. I often wonder how the people who complain about the absence of real concurrency in their programming languages [3] actually would use this feature. In my opinion the best way to use concurrency is to string individual programs into a pipeline. This will never go "evil" on you.
[0] https://cygwin.com/cygwin-ug-net/highlights.html
[1] https://www.usenix.org/legacy/publications/library/proceedin...
[2] https://skeptics.stackexchange.com/questions/43800/did-the-c...
dbacar
With all respect, why would anyone bother to use these tools when you have a full-blown linux distro at your command with WSL/2?
nottorp
Yes, set up a VM and then add 3 levels of nested containers inside the VM just to be sure.
Incidentally next week I have to debug one of our tester's laptop - he installed vmware which stopped WSL from running somehow and now neither option works.
thingfish
You hit an important point here. Teaching IT to 16 jear old children is very much like being an admin for a large corporation. Most of them have installed VMWare, VirtualBox, Hyper-V and pfSense, depending on the preference of the other teachers. Most first-graders don't know anything about networking, so I didn't want to add WSL to that. I used Cygwin. Worked perfectly until I started to teach Sendmail. Sendmail runs in unprivileged mode. This means that it starts as root, but then switches to a user with very few rights. Cygwin couldn't handle that at first, but I got it working. But then students couldn't uninstall Cygwin anymore because of changed file ownership in Windows. I had to install a second Cygwin to uninstall the first. With MinC I took extreme care to get all the different models of Access Control Lists that are used in Windows right.
hughw
wait, first graders?!?
skinner927
This is pretty common. They turned off hyper-v.
nottorp
Thanks, I'll check that when the easter some-people-took-more-time-off period is over.
dbacar
yes but you get what you pay for, a real linux environment that you can install any tool. Vmware is kinda problematic as I observe on my windows 11. And I had problems with hyperv . Even for wsl2 i had to do reinstalls till I get it working but now it is pretty cool. It takes around 5-6 seconds for initial vm startup. If you close the terminal the vm shuts down in a couple of minutes. But if you want it always up, I use the tmux trick to make it always stay up.
cowmix
WSL/2 has a lot of overhead and it NOT Windows native. I used it all the time, but I also use Windows Git Bash -- which is also like this project.
dbacar
I used Git Bash also but it is kinda slowish, does not act like a true terminal always but it is OK. WSL2 is much better in my opinion, and fast.
Borg3
Because I want more tight coupling with Win32 OS. Im old Cygwin user here. Actually, I cant work on Windows without Cygwin. Its very first thing installed on fresh system so I can bring all my tools with it :)
I have free access to entire FS, I can run Win32 console tools as well inside bash. If I want true Linux environment, I can always spawn VM and use Xserver on Win32 to work on it (Xming).
charcircuit
You can have access to the entire fs (/mnt/c) and run exe files with WSL too
Borg3
Probably WSL1.. Yeah.. But why should I bother with it if Cygwin does the work just fine? :)
robohoe
Many orgs’ security policies don’t permit WSL/2.
thunder-blue-3
wow, TIL. Can't believe I've done nearly 40 circles around our sun and never knew about WSL/2.
orra
To be fair, WSL/2 didn't exist for most of those circles.
i_am_proteus
One reason would be if anyone does not want to, or is not able to, enable virtualization (WSL requires this).
dehrmann
Doesn't WSL 2 essentially run Linux in a VM? It's fine when things are in one OS or the other, but gets weird when it crosses over.
dbacar
Yes it is in a VM but beautifully handled.Your C drive is mounted and slower than a real linux because it is NTFS but works much better than those cygwin, or git bash tools.
blueflow
Better manual pages?
> It runs on all versions of Windows, except Win95 and Win98.
For some reason, I suspect it does not run on Windows 1.0 to 3.11 either. I also find it strange to think it would run on both Windows ME and Windows NT 3.5, while excluding Windows 95 and Windows 98. Windows NT 3.5 and Windows ME are nearly a decade apart. The Windows subsystem’s software support in Windows NT 3.5 would be a subset of Windows 95/98.