> 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.
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
Windows 2000 is my favorite release ever, but anecdotally, I can deny the "no crashes" claim. Sure it was rare, but I had my share of BSODs and weird behavior on it. Still much more solid than... pretty much every other release.
I think since Windows 7, it has been very solid except for maybe third party kernel driver issues which needs direct kernel access out of necessity. Today when you have a BSOD, it’s like a Linux, Mach kernel panic etc - 99% likely to be a hardware problem.
Yeah. It was indeed great, I was using for 10 years, then moved to Win2003 with I still use. But I think Win2003 is even better. It have better kernel, proper SMP support (multicore), good PAE support (16GB RAM), newer drivers, etc :)
They want to see if anyone will ever 0-day their system.
To be fair, I have old MacOS laptops that are my wife's laptops, we keep them around because they still turn on, and they have all her old files (I've backed it all up several different ways for her), but I never go on the web with any of the browsers installed on those systems.
I had a weird old "laptop" that I was given as a kid, didnt know jack about computers back then so I couldnt tell you what it was. It was one of those that came with a big heavy docking station and it couldnt run without it anymore so I assume the battery was dead. Had Windows 2000 and I used to play AoE 2 on it all day and it was smooth and the interface was snappy. Fond memories. I remember being really confused when people told me that Windows 2000 was bad.
Bear in mind that Microsoft was the largest commercial UNIX vendor in licensing XENIX for the TRS-80 Model 2 alone. From this experience, they had significant knowledge of 32-bit preemptive multitasking.
That exposure allowed them to see how valuable Dave Cutler's PRISM team would be in a total redesign in melding VMS and (whatever tolerable) UNIX features into a new kernel, but focusing it upon Win32.
There were OS/2 and POSIX emulation layers also, but these were obviously second class.
I love Windows 2000, it was pretty great, but display driver crashes would take down the system (similar to NT4). Also if 2000 was installed in most homes it’d be about as much of a fiasco as pre SP2 Windows XP. IIRC there were a bunch of worms that did affect Windows 2000.
Windows 10 on the other hand will deal with display driver crashes just fine, falling back to safe mode.
Windows 2000 was not developed for x86 directly. It first started on Alpha, then ported to x86, so its codebase is "double-brewed" in a way.
I also remember 2000 as the only rock solid Windows release, and I never had to reinstall it. XP was very close to that after it fully matured, but nothing feels like 2000.
True, but the flexibility that two attempts at porting to botched architecture introduced also resulted in 2003 becoming Microsoft's first x86-64 operating system. The very next day after the 2003 release, they released Windows XP Professional x64 Edition based on the 2003 codebase, which a user could run on their brand new x64 computer without much of an issue -- that is, if they had even heard of it... it was under-marketed because they needed to save the hype for Vista. So the struggle and failure may have been worth it in the grand scheme of things.
The two OS kernels and API are super close (outsider perspective). I used win2k for like 10 years mostly on the back of applications and games supporting XP for so long. I can't recall the big API differences. Maybe XP has UAC and there were APIs to check for it? Anyways, I still have fond memory of manually patching out API calls hard coded into EXEs to bypass XP only parts which were almost always superfluous.
Yes, I'm aware. Normally they shouldn't behave wildly differently, but the new GUI and userspace features made the system a bit flaky at first. Also, XP became a bit more finicky about drivers over the years, and this broke stuff, too.
2000s kernel was one of its better features, but lack of blingy GUI was also helping in its stability IMHO.
That's not really quite accurate. Windows NT began life on the i860, and then was ported to i386 and MIPS, and very shortly after the initial release, ported to Alpha. A year after that, PowerPC.
Through the life of Windows NT 4.0's life span, MIPS and PowerPC died early, and Alpha support was axed just before the very end. In Windows 2000's development, i386 and Alpha were the only ports left, and Alpha was axed before it could make it to final release.
x86 and Alpha lived simultaneously for most of its development. It wasn't done "first" on Alpha (quite the opposite).
If Microsoft had just iterated on Windows 2000 forever instead of continuing with XP/2003 and beyond it's quite possible I wouldn't be a Linux desktop user today.
The NT 3.x series might have had stricter userspace separation than 4.x did where they moved things like GDI into kernel space, but it still fell over hard at even the faintest whiff of fuzz-testing the native API. It wasn't until 5.x (Win2K) that they started taking that sort of thing seriously.
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.
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.
> 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.
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."
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.
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.
†: 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].
> 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.
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.
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.
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.
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.
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.
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.
> 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;
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.
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.
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.
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.
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.
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.
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
File system filters are pluggable kernel drivers. For example, ProcMon (Sysinternals tool) monitors file systems via a file system filter -- so fun fact, if you outright disable file system filters on a ReFS volume, you won't get any ProcMon results! This was a 'duh' moment for me.
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.
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
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.
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.
> 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.
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.
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?
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.
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.
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?
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.
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.
> 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.
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.
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.
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.
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.
Sure, it's confusing. But the suggestion here is that this single word implies a "lot of fundament misunderstandings and factual mistakes" (sic), and therefore the many negative comments in this thread about that word are warranted, and frankly that's just ridiculous.
Notably, from a teaching "Unix tools 101" perspective, the difference is super unimportant. If the author's goal is to get students to open a terminal for the first time in their lives (on their Windows laptops!) and type some ls commands and maybe pipe stuff into sed once or twice, they can learn this on a BSD and apply it in any Linux (or the reverse) just fine.
I think the author means it literally. His goal is to teach students some Linux basics, and his method is to put a BSD into their Windows. It's kinda nuts, but you gotta agree it's kinda "mad genuis" nuts.
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".
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.
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.
Right, and manually extracting MSYS2 packages into an MSYS2 environment is also possible if very unsupported (used that to get a copy of rsync once). My point, rather, is that GfW isn’t and shouldn’t be your starting point if you want to get a Unix-like environment; use actual MSYS2 instead.
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.
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
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
"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"
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?
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.
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.
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).
At my University I heard things like "Linux is derived Unix, BSD variants are something else entirely". I think education people are confused in general about this topic.
That's hilarious. It sounds like you know, but for anyone who doesn't, it's actually the opposite. BSD variants are derived from Unix--that's where the BSD comes from, it was the Berkley Software Distribution of Unix tools, that later implemented the rest of Unix so universities could use the same software without having to worry about licensing from Bell Labs.
Linux is something else entirely, a student's project to make a MINIX compatible kernel, usually packaged with the GNU operating system, which like BSD aimed to be Unix compatible, but notably is not Unix (It's right there in the name: GNU's Not Unix).
The operating system interface that Unix, BSD and Linux share is called POSIX. The term POSIX is not widely known, so people sometimes make up for it by using "Linux" in-place because it is the most popular implementation.
This explains people who argue that Android is not Linux, despite it featuring a Linux kernel and self-identifying as so: They are intending to say that Android is not POSIX.
We need to make POSIX (as concept/word) more popular.
Especially to package writers that assume bash is available everywhere, hope that bin/sh is the same as bin/ksh...sed -i... not on unices, grep missing a ton of options....
It's never going to happen. POSIX has been around for 4 decades now. The longer something is not popular, the lower its chances to ever become popular.
Yes. Teaching anything to children is to start simple. So I start with bare-bone UNIX. In their second year we move to Linux (all flavours). For their final exam in the third year, they must be able to use Suze Linux.
What is Suze Linux? Did you mean Suse Linux? I would suggest dropping Linux from the description since this has nothing to do with the Linux kernel. Perhaps you could write POSIX instead.
Wouldn't it be easier to use WSL? Microsoft has done al the hard work in getting native Linux code to run on Windows. I don't know how bare-bones you want it to be, but if you install Debian in WSL without extra packages, that seems pretty bare-bone to me. And it seems to me you avoid unnecessary friction from switching from OpenBSD to Linux later on.
Installing WSL was much harder than 'download and double click EXE' when I last did it. The 'app' shop installed something botched I now can't easily get rid of and then I had to do a few Powershell incantations to actually get an install that boots a Linux-like terminal. If I had to use Linux under Windows more than a few hours per year I'd Hyper-V it instead.
I'd also guess 'telemetry' pumps out all one does in WSL, while this might leak less of what the kids are doing.
I doubt that, since telemetry slows things down and it has been found that software runs faster under WSL than native Windows. A quick search found this, which shows a substantial performance difference for the same thing between native Windows and WSL:
There have been others who observed the same in the past (and with WSL1), although I do not have a list. I recall reading libc telemetry hooks on Windows that are absent as being claimed to be the cause, but I cannot find the page where I read that. The Reddit post has the alternative suggestion that process creation speed is the cause.
Suggesting that the entirety of the performance difference between Windows and WSL is due to telemetry is by far the weirdest MICROS~1 apologia I've come across.
Performance on my bare metal Linux machines is even better. Do you consider this to be sufficient proof that WSL has telemetry hooked into it?
While that may certainly arise if someone is lazy about #!/bin/sh when they didn't really mean /bin/sh I'd bet it's /bin/sed and similar friends that are different between the GNU versions and the BSD versions. So much make-macro-trickery out there when one is trying to use -i without a backup suffix, and I have no idea why GNU tried to be a trailblazer with their parsing :(
If you want to communicate to people wanting to learn "the linux" that this (to a close approximation) does this, with very few words, you could do worse.
After all, if you learned to do "linux" on OpenBSD you'd be pretty much at home on Linux, too.
It's a clever bit of SEO, too, mashing in Cygwin, Linux and OpenBSD in the copy.
Huh. This was my entry point as well, but I find Linux very aligned with my feelings about the 4.1 experience, as opposed to Solaris which felt clunky and overbuilt. Of course this is purely subjective emotional stuff I'm talking about.
Yes, the switch to Solaris was definitely abrupt. But the current BSDs feel more like SunOS 4 to me than Linux does. Though to be honest, I do use Linux more than any of the BSDs these days.
Former Sun Micro CEO Scott McNealy, known for his provocative quotes, says Trump is doing a 'spectacular job' amid the coronavirus crisis. That's not how many tech experts see it:
If you assume Windows machine as a starting point, you'll need to answer "Why not WSL?". I can think of good answers, but this would be good to document somewhere.
Weird that a video format that's been around since 2010 still doesn't have wide support. But, that takes me back to the codec problems from around that time.
so maybe in a comically ancient version of Android, or perhaps a "hardened" distro that eschews modern stuff?
Merely as another datum, I did URL surgery to get the prior .webm flavor and it's blank for my FF 137 on macOS so there was obviously something else going on (by blank I mean it had 21 seconds worth of black pixels, not that it didn't play)
MSYS2 is basically Cygwin with Pacman for package management, plus several other environments with either GCC or Clang and different Windows-Native C and C++ runtimes.
It's nice, but not perfect. It inherits a lot of problems from Cygwin. File access is still slow (as mentioned in other threads) and symlinks don't behave right (by default making a symlink creates a deep copy of the target, and even NTFS symlinks need to know whether the target is a file or a directory; either way you cannot create a symlink when the target is missing, and this causes rsync to fail, for example.)
MSYS2's strength is as an environment for compiling cross-platform apps for Windows, and I would recommend WSL2 for anything else.
Agreed that it's good for building native Windows software and there are better options for other use cases. When recommending–praising MSYS2 I sometimes forget that the only time I use Windows is to build software for use by other folks who actively run Windows as their desktop/laptop OS.
Re: "Cygwin…plus several other environments[+]", the second paragraph of MSYS2's home page summarizes it pretty well:
Despite some of these central parts [Bash and cli tools] being based on Cygwin, the main focus of MSYS2 is to provide a build environment for native Windows software and the Cygwin-using parts are kept at a minimum.
My "bad experience" with MSYS2 was when I misunderstood how the different environments were set up.
There are several different environments, each with their own different and incompatible set of packages. When you run "mingw64", you are running a different environment than "msys2". If you install a package named "gcc", you are getting the "gcc" intended for "msys2", and not the package intended for "mingw64".
The "Msys2" version ships with Windows headers that are not compatible with some Windows programs, while the "Mingw64" has compatible headers. Then this led to me filing an invalid bug report.
The role of the different environments (with their color-coded icons), and the necessary prefixes to install packages for those environments could be made a lot clearer. And that if you are in the "Msys" environment, all software you build will depend on "Msys".
You’re right, getting started with it can/could be a bit confusing. The website explains everything clearly but is prose-heavy. The naming schemes for the environments and packages make sense after you understand how the system works, but it does seem like there’s room for improvement and simplification.
Honestly, I hate that the de facto terminal on Windows is the MinTTY that ships with Git, i.e. "Git Bash." I don't remember them right now, but there are weird quirks with that terminal that are mostly solved by the "new" Windows Terminal.
One of them is that typing your password shows each character briefly before it disappears. Maybe the same thing happens in other terminals too, but they are too fast to notice - but here I could actually read my SSH key password as I typed it. Not cool.
It's so easy to run a Linux VM under Windows, I don't understand avoiding it. There's a little to learn, yes, but then you have real Linux as opposed to dealing with the inevitable differences between Linux and any of: Cygwin, MinC, WSL2, or MacOS.
> 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.
You're right. I'll change it to "Windows XP or later".
IDK, I wouldn't be surprised if it ran on Windows 2000 (still the best OS Microsoft ever made)
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
https://www.youtube.com/watch?v=umJsITGzXd0
> It had no crashes
Windows 2000 is my favorite release ever, but anecdotally, I can deny the "no crashes" claim. Sure it was rare, but I had my share of BSODs and weird behavior on it. Still much more solid than... pretty much every other release.
I think since Windows 7, it has been very solid except for maybe third party kernel driver issues which needs direct kernel access out of necessity. Today when you have a BSOD, it’s like a Linux, Mach kernel panic etc - 99% likely to be a hardware problem.
CrowdStrike
> except for maybe third party kernel driver issues which needs direct kernel access out of necessity.
Yeah. It was indeed great, I was using for 10 years, then moved to Win2003 with I still use. But I think Win2003 is even better. It have better kernel, proper SMP support (multicore), good PAE support (16GB RAM), newer drivers, etc :)
Why use something so… old?
Because its snappy, have great GUI, I control it, I have all the tools for maintenance (compilers, DDK, disassemblers)..
I know, there pretty nice Linux distros that are lightweight and snappy too. One day... :) but not yet :)
Fans of SimH might give you many reasons for enthusiasm in retro-computing.
https://simh.trailing-edge.com/
They want to see if anyone will ever 0-day their system.
To be fair, I have old MacOS laptops that are my wife's laptops, we keep them around because they still turn on, and they have all her old files (I've backed it all up several different ways for her), but I never go on the web with any of the browsers installed on those systems.
> a fully-fledged operating system with a hardware abstraction layer, preemptive multitasking, permissions, a registry, proper device drivers etc.
Windows NT, which was developed by people (Dave Cutler et al.) who knew how to design and build operating systems (VMS, etc.).
there is a book about it, called "inside windows nt". I had read it back in the day,
it is by helen custer. it talks about dave cutler's work on it, apart from other stuff.
Got a copy sitting right next to me! Along with Inside The Windows NT File System (and The Design and Implementation of the 4.4 BSD Operating System).
'Windows Internals' series is the successor to Inside Windows NT.
I had a weird old "laptop" that I was given as a kid, didnt know jack about computers back then so I couldnt tell you what it was. It was one of those that came with a big heavy docking station and it couldnt run without it anymore so I assume the battery was dead. Had Windows 2000 and I used to play AoE 2 on it all day and it was smooth and the interface was snappy. Fond memories. I remember being really confused when people told me that Windows 2000 was bad.
Bear in mind that Microsoft was the largest commercial UNIX vendor in licensing XENIX for the TRS-80 Model 2 alone. From this experience, they had significant knowledge of 32-bit preemptive multitasking.
That exposure allowed them to see how valuable Dave Cutler's PRISM team would be in a total redesign in melding VMS and (whatever tolerable) UNIX features into a new kernel, but focusing it upon Win32.
There were OS/2 and POSIX emulation layers also, but these were obviously second class.
I love Windows 2000, it was pretty great, but display driver crashes would take down the system (similar to NT4). Also if 2000 was installed in most homes it’d be about as much of a fiasco as pre SP2 Windows XP. IIRC there were a bunch of worms that did affect Windows 2000.
Windows 10 on the other hand will deal with display driver crashes just fine, falling back to safe mode.
>In hindsight, the progress Microsoft made in the ten years between Windows 3.0 (1990) and Windows 2000 seems incredible.
compared to what, Linux? the BSDs? Solaris? OS/2 didn't achieve market success but it added major feature subsystems at the same brisk pace.
right, I suspect "NT" is the category they're looking for.
Hilarious that this was literally my exact thought.
What's wrong with 2003?
Windows 2000 was not developed for x86 directly. It first started on Alpha, then ported to x86, so its codebase is "double-brewed" in a way.
I also remember 2000 as the only rock solid Windows release, and I never had to reinstall it. XP was very close to that after it fully matured, but nothing feels like 2000.
[0]: https://en.wikipedia.org/wiki/Windows_2000
True, but the flexibility that two attempts at porting to botched architecture introduced also resulted in 2003 becoming Microsoft's first x86-64 operating system. The very next day after the 2003 release, they released Windows XP Professional x64 Edition based on the 2003 codebase, which a user could run on their brand new x64 computer without much of an issue -- that is, if they had even heard of it... it was under-marketed because they needed to save the hype for Vista. So the struggle and failure may have been worth it in the grand scheme of things.
The two OS kernels and API are super close (outsider perspective). I used win2k for like 10 years mostly on the back of applications and games supporting XP for so long. I can't recall the big API differences. Maybe XP has UAC and there were APIs to check for it? Anyways, I still have fond memory of manually patching out API calls hard coded into EXEs to bypass XP only parts which were almost always superfluous.
Yes, I'm aware. Normally they shouldn't behave wildly differently, but the new GUI and userspace features made the system a bit flaky at first. Also, XP became a bit more finicky about drivers over the years, and this broke stuff, too.
2000s kernel was one of its better features, but lack of blingy GUI was also helping in its stability IMHO.
That's not really quite accurate. Windows NT began life on the i860, and then was ported to i386 and MIPS, and very shortly after the initial release, ported to Alpha. A year after that, PowerPC.
Through the life of Windows NT 4.0's life span, MIPS and PowerPC died early, and Alpha support was axed just before the very end. In Windows 2000's development, i386 and Alpha were the only ports left, and Alpha was axed before it could make it to final release.
x86 and Alpha lived simultaneously for most of its development. It wasn't done "first" on Alpha (quite the opposite).
It's worse than 2000, IMO, bloated and not super stable like 2000.
Using Windows 2000 is like using a well-crafted Linux distro. Things just work.
If Microsoft had just iterated on Windows 2000 forever instead of continuing with XP/2003 and beyond it's quite possible I wouldn't be a Linux desktop user today.
A bit bloated. I think NT 3.51 is the coolest, extremely stable.
The NT 3.x series might have had stricter userspace separation than 4.x did where they moved things like GDI into kernel space, but it still fell over hard at even the faintest whiff of fuzz-testing the native API. It wasn't until 5.x (Win2K) that they started taking that sort of thing seriously.
Also you are confusing Visual Studio and VSCode
Win2k?
"later" is for lazzy developers.
Better list the complete list of versions where it has been tested, like "Windows XP/7/8/10/11"...
The frontpage says now:
"It runs on Windows NT, version 2003/XP/Vista/7/8/10/11."
Victory!
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.
> 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.
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.
> 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.
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."
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.
> 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-...
> 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.
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.
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.
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.
> 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.
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...
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.
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.
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.
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.
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
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
NTFS/ReFS are not slow. But there is an extensible file system filter layer above them that can slow things down.
microsoft introduced Dev drives for this reason, they are optimized such that no file system filters are attached
https://learn.microsoft.com/en-us/windows/dev-drive/
I thought by filters they quite literally mean the antivirus filters in Defender? Does it strip down some of the Windows file semantics too?
File system filters are pluggable kernel drivers. For example, ProcMon (Sysinternals tool) monitors file systems via a file system filter -- so fun fact, if you outright disable file system filters on a ReFS volume, you won't get any ProcMon results! This was a 'duh' moment for me.
https://learn.microsoft.com/en-us/windows-hardware/drivers/i...
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.
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
> 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
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
For a subset of "run shell scripts", I'm a fan of the one-executable-file busybox for windows.
WSL2 supports all the good stuff like systemd. With WSL1 I'd have to rely on Windows utilities or handroll a lot more things
> 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).
I like systemd. But I only know and use it superficially, mainly for fairly simple units that are sometimes running on a schedule.
And while WSL is worse than Linux without Windows, I still prefer it over MacOS with Linux running in a VM.
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.
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.
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.
Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
> 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.
> 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.
> 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
> 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.
Cygwin is not wine. Wine lets you run existing windows executables unmodified on Linux. Cygwin does not let you run ELFs on windows.
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.
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?
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.
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.
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!
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
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.
Isn't that what user-mode Linux is?
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.
I see. Thanks!
> 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...
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.
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/
I don't get the negativity in this thread. Looks like a cool project, keep up the good work
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.
> I don't mind.
That’s good. It’s an interesting project and the discussion here is overall very interesting. Thanks for posting it.
You're wrong, it should be BMW Beetle.
:-p
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.
> almost all references to Linux
The word "Linux" only occurs on the page once.
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.
Sure, it's confusing. But the suggestion here is that this single word implies a "lot of fundament misunderstandings and factual mistakes" (sic), and therefore the many negative comments in this thread about that word are warranted, and frankly that's just ridiculous.
Notably, from a teaching "Unix tools 101" perspective, the difference is super unimportant. If the author's goal is to get students to open a terminal for the first time in their lives (on their Windows laptops!) and type some ls commands and maybe pipe stuff into sed once or twice, they can learn this on a BSD and apply it in any Linux (or the reverse) just fine.
I think the author means it literally. His goal is to teach students some Linux basics, and his method is to put a BSD into their Windows. It's kinda nuts, but you gotta agree it's kinda "mad genuis" nuts.
Ah! You got it. Are you a teacher? You should try it.
Nop not at all. In fact I'm a Windows user who doesn't actually know how to pipe things into sed. :-)
If you were wondering, this is how fork() is implemented: as threads: https://github.com/dboland/minc/blob/8fe124625d2262b5bd83e0a...
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".
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?
I was a limper too, until I saw this demonstration by the creator of PowerShell from 2004: https://www.youtube.com/watch?v=4mBRA7pqITM
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.
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.
it seems possible to install GfW into an existing MSYS2:
https://gitforwindows.org/install-inside-msys2-proper
Right, and manually extracting MSYS2 packages into an MSYS2 environment is also possible if very unsupported (used that to get a copy of rsync once). My point, rather, is that GfW isn’t and shouldn’t be your starting point if you want to get a Unix-like environment; use actual MSYS2 instead.
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.
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
MinC a bit close to an existing MinC https://rtcmix.org/reference/scorefile/Minc.html (Minc is not C)
Its such great recursive acronym. [1]
[1]: https://en.m.wikipedia.org/wiki/Recursive_acronym
> MinC is a Unix emulator for Windows, based on the OpenBSD operating system
If anybody wondering.
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
I used CoLinux back in the days, it was bluffing:
http://zoobab.wikidot.com/openwrt-and-user-mode-linux
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.
"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?
I wish they'd include a datestamp in these intro pages. This looks like it could be from any era.
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.
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?
Agree. Looking at github, the most recent commit is yesterday and some are two years old.
The irc client (not naming it) is an interesting choice for a secure-by-default OS. My understanding was that it has several security concerns?
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?
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.
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.
wait, first graders?!?
He said 16 year old. I was installing Slackware from floppies at 16 so why wouldn't modern kids play with VMs?
This is pretty common. They turned off hyper-v.
Thanks, I'll check that when the easter some-people-took-more-time-off period is over.
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.
Because WSL is just a VM, Cygwin is native.
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).
You can have access to the entire fs (/mnt/c) and run exe files with WSL too
Probably WSL1.. Yeah.. But why should I bother with it if Cygwin does the work just fine? :)
Works in WSL2 - thanks to Plan 9’s 9P protocol
Many orgs’ security policies don’t permit WSL/2.
wow, TIL. Can't believe I've done nearly 40 circles around our sun and never knew about WSL/2.
To be fair, WSL/2 didn't exist for most of those circles.
One reason would be if anyone does not want to, or is not able to, enable virtualization (WSL requires this).
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.
Better manual pages?
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?
"MinC is a Unix emulator for Windows, based on the OpenBSD operating system. MinC was written to help children at vocational education learn Linux"
?
At my University I heard things like "Linux is derived Unix, BSD variants are something else entirely". I think education people are confused in general about this topic.
That's hilarious. It sounds like you know, but for anyone who doesn't, it's actually the opposite. BSD variants are derived from Unix--that's where the BSD comes from, it was the Berkley Software Distribution of Unix tools, that later implemented the rest of Unix so universities could use the same software without having to worry about licensing from Bell Labs.
Linux is something else entirely, a student's project to make a MINIX compatible kernel, usually packaged with the GNU operating system, which like BSD aimed to be Unix compatible, but notably is not Unix (It's right there in the name: GNU's Not Unix).
>usually packaged with the GNU operating system
It's usually packaged as a part of the Android operating system. GNU hasn't been the popular userspace for a long time.
Except in datacenters.
The operating system interface that Unix, BSD and Linux share is called POSIX. The term POSIX is not widely known, so people sometimes make up for it by using "Linux" in-place because it is the most popular implementation.
This explains people who argue that Android is not Linux, despite it featuring a Linux kernel and self-identifying as so: They are intending to say that Android is not POSIX.
We need to make POSIX (as concept/word) more popular.
Especially to package writers that assume bash is available everywhere, hope that bin/sh is the same as bin/ksh...sed -i... not on unices, grep missing a ton of options....
Time to ask an AI ?
It's never going to happen. POSIX has been around for 4 decades now. The longer something is not popular, the lower its chances to ever become popular.
The name might not be popular, but POSIX has long won. Everybody knows printf.
The thread is about the name.
If you can get the exact quotes, please send them to Computer Stupidities:
http://rinkworks.com/stupid/
As an obligatory warning, if you have never seen Computer Stupidities previously, expect to lose a day reading it.
Yes. Teaching anything to children is to start simple. So I start with bare-bone UNIX. In their second year we move to Linux (all flavours). For their final exam in the third year, they must be able to use Suze Linux.
What is Suze Linux? Did you mean Suse Linux? I would suggest dropping Linux from the description since this has nothing to do with the Linux kernel. Perhaps you could write POSIX instead.
Wouldn't it be easier to use WSL? Microsoft has done al the hard work in getting native Linux code to run on Windows. I don't know how bare-bones you want it to be, but if you install Debian in WSL without extra packages, that seems pretty bare-bone to me. And it seems to me you avoid unnecessary friction from switching from OpenBSD to Linux later on.
WSL requires Windows 10 or 11 though.
And you’re still locked in the Microsoft ecosystem.
Installing WSL was much harder than 'download and double click EXE' when I last did it. The 'app' shop installed something botched I now can't easily get rid of and then I had to do a few Powershell incantations to actually get an install that boots a Linux-like terminal. If I had to use Linux under Windows more than a few hours per year I'd Hyper-V it instead.
I'd also guess 'telemetry' pumps out all one does in WSL, while this might leak less of what the kids are doing.
I doubt that, since telemetry slows things down and it has been found that software runs faster under WSL than native Windows. A quick search found this, which shows a substantial performance difference for the same thing between native Windows and WSL:
https://www.reddit.com/r/rust/comments/vtc0fy/wsl2_faster_th...
There have been others who observed the same in the past (and with WSL1), although I do not have a list. I recall reading libc telemetry hooks on Windows that are absent as being claimed to be the cause, but I cannot find the page where I read that. The Reddit post has the alternative suggestion that process creation speed is the cause.
Suggesting that the entirety of the performance difference between Windows and WSL is due to telemetry is by far the weirdest MICROS~1 apologia I've come across.
Performance on my bare metal Linux machines is even better. Do you consider this to be sufficient proof that WSL has telemetry hooked into it?
No, since Windows is less efficient in general.
OK, so you agree that your argument was flawed.
Seems to me, that to some Linux has come to mean all things Unix-ly
Yes it seems to be misused that wat - now just try to rerun scripts on macOS or BSD when the author thinks Linux is all there is.
That's usually caused by assuming that everything is bash, which is not true even for Linux.
Yes - I come from an era when I used multiple Unixes and for several of them default shell was (t)csh.
Don't assume anything in shells except POSIX sh.
Unfortunately there are people who think Linux is the only way.
While that may certainly arise if someone is lazy about #!/bin/sh when they didn't really mean /bin/sh I'd bet it's /bin/sed and similar friends that are different between the GNU versions and the BSD versions. So much make-macro-trickery out there when one is trying to use -i without a backup suffix, and I have no idea why GNU tried to be a trailblazer with their parsing :(
If you want to communicate to people wanting to learn "the linux" that this (to a close approximation) does this, with very few words, you could do worse.
After all, if you learned to do "linux" on OpenBSD you'd be pretty much at home on Linux, too.
It's a clever bit of SEO, too, mashing in Cygwin, Linux and OpenBSD in the copy.
I learned to do "linux" on SunOS 4.1, and I feel less at home on Linux and more like a guest in my grandchildren's house.
Huh. This was my entry point as well, but I find Linux very aligned with my feelings about the 4.1 experience, as opposed to Solaris which felt clunky and overbuilt. Of course this is purely subjective emotional stuff I'm talking about.
Yes, the switch to Solaris was definitely abrupt. But the current BSDs feel more like SunOS 4 to me than Linux does. Though to be honest, I do use Linux more than any of the BSDs these days.
Speaking of Cygnus:
The Worst Job in the World, from Michael Tiemann <tiemann@cygnus.com>:
https://www.donhopkins.com/home/catalog/unix-haters/slowlari...
PS: Fuck Trump supporting anti-vaxer Scott "You have zero privacy, get over it" McNealy. May he run Solaris in hell.
Scott McNealy has long been one of Trump’s few friends in Silicon Valley:
https://www.sfchronicle.com/politics/article/Scott-McNealy-h...
Former Sun Micro CEO Scott McNealy, known for his provocative quotes, says Trump is doing a 'spectacular job' amid the coronavirus crisis. That's not how many tech experts see it:
https://www.businessinsider.com/scott-mcnealy-praises-trumps...
Sun on Privacy: "Get Over It":
https://www.wired.com/1999/01/sun-on-privacy-get-over-it/
If you assume Windows machine as a starting point, you'll need to answer "Why not WSL?". I can think of good answers, but this would be good to document somewhere.
Looks great. What do learners do using this OS (besides opening a web browser)? What other teaching resources do you use?
The System Boot demo video on the screenshots page won't play for me. Seems the format isn't supported by Firefox on Android.
It is a .webm file. It won't play in my BlueStacks Android emulator either. Do I need to add an .mp4 file?
Yes, webm support on mobile is horrible.
It works now. I had to add -pix_fmt yuv420p to my ffmpeg parameters. Thanks for the comments on this.
Weird that a video format that's been around since 2010 still doesn't have wide support. But, that takes me back to the codec problems from around that time.
I added an .mp4 source. Still not playing in BlueStacks Android. Does it work in a real Andriod?
Pay attention to the the codecs, mp4 is a container format that may contain a codec that Android doesn't support. This is a rabbit hole.
According to ffprobe:
so maybe in a comically ancient version of Android, or perhaps a "hardened" distro that eschews modern stuff?Merely as another datum, I did URL surgery to get the prior .webm flavor and it's blank for my FF 137 on macOS so there was obviously something else going on (by blank I mean it had 21 seconds worth of black pixels, not that it didn't play)
Playing fine for me, also Firefox on Android.
Ok so it's not Cygwin, how is it better (or worse) than Cygwin?
I think the name is just a pun. Like how GNU is short for "GNU's not Unix". Presumably MinC is short for "MinC is not Cygwin".
Cygwin is based on something called Newlib, also of BSD origins.
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.
Given that this has build tools, can it run pkgsrc?
It is interesting and there so many options.
Mingw
WSL seems to be new now
Cygwin
And this one.
MSYS2 ties it together for the best experience imo:
https://www.msys2.org/
MSYS2 is basically Cygwin with Pacman for package management, plus several other environments with either GCC or Clang and different Windows-Native C and C++ runtimes.
It's nice, but not perfect. It inherits a lot of problems from Cygwin. File access is still slow (as mentioned in other threads) and symlinks don't behave right (by default making a symlink creates a deep copy of the target, and even NTFS symlinks need to know whether the target is a file or a directory; either way you cannot create a symlink when the target is missing, and this causes rsync to fail, for example.)
MSYS2's strength is as an environment for compiling cross-platform apps for Windows, and I would recommend WSL2 for anything else.
Agreed that it's good for building native Windows software and there are better options for other use cases. When recommending–praising MSYS2 I sometimes forget that the only time I use Windows is to build software for use by other folks who actively run Windows as their desktop/laptop OS.
Re: "Cygwin…plus several other environments[+]", the second paragraph of MSYS2's home page summarizes it pretty well:
[+] https://www.msys2.org/docs/environments/My "bad experience" with MSYS2 was when I misunderstood how the different environments were set up.
There are several different environments, each with their own different and incompatible set of packages. When you run "mingw64", you are running a different environment than "msys2". If you install a package named "gcc", you are getting the "gcc" intended for "msys2", and not the package intended for "mingw64".
The "Msys2" version ships with Windows headers that are not compatible with some Windows programs, while the "Mingw64" has compatible headers. Then this led to me filing an invalid bug report.
The role of the different environments (with their color-coded icons), and the necessary prefixes to install packages for those environments could be made a lot clearer. And that if you are in the "Msys" environment, all software you build will depend on "Msys".
You’re right, getting started with it can/could be a bit confusing. The website explains everything clearly but is prose-heavy. The naming schemes for the environments and packages make sense after you understand how the system works, but it does seem like there’s room for improvement and simplification.
Yea, options now.
Does it support unicode and internationalization?
Yes.
Honestly, I hate that the de facto terminal on Windows is the MinTTY that ships with Git, i.e. "Git Bash." I don't remember them right now, but there are weird quirks with that terminal that are mostly solved by the "new" Windows Terminal.
One of them is that typing your password shows each character briefly before it disappears. Maybe the same thing happens in other terminals too, but they are too fast to notice - but here I could actually read my SSH key password as I typed it. Not cool.
>based on the OpenBSD operating system. MinC was written to help children at >. vocational education learn Linux
WAT? Linux == OpenBSD now?
> without the hassle of virtualization
It's so easy to run a Linux VM under Windows, I don't understand avoiding it. There's a little to learn, yes, but then you have real Linux as opposed to dealing with the inevitable differences between Linux and any of: Cygwin, MinC, WSL2, or MacOS.
[dead]
[dead]
[dead]
[dead]
[flagged]
[flagged]