[HN Gopher] MinC Is Not Cygwin
___________________________________________________________________
MinC Is Not Cygwin
Author : thingfish
Score : 246 points
Date : 2025-04-23 10:21 UTC (12 hours ago)
(HTM) web link (minc.commandlinerevolution.nl)
(TXT) w3m dump (minc.commandlinerevolution.nl)
| damnitbuilds wrote:
| "MinC is a _Unix_ emulator for Windows, based on the _OpenBSD_
| operating system. MinC was written to help children at vocational
| education learn _Linux_ "
|
| ?
| serbuvlad wrote:
| 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.
| blueflow wrote:
| 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.
| oblio wrote:
| 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.
| blueflow wrote:
| The name might not be popular, but POSIX has long won.
| Everybody knows printf.
| oblio wrote:
| The thread is about the name.
| m2f2 wrote:
| 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 ?
| thesuitonym wrote:
| 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).
| charcircuit wrote:
| >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.
| bornfreddy wrote:
| Except in datacenters.
| ryao wrote:
| 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.
| arka2147483647 wrote:
| Seems to me, that to some Linux has come to mean all things
| Unix-ly
| pasc1878 wrote:
| 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.
| Maken wrote:
| That's usually caused by assuming that everything is bash,
| which is not true even for Linux.
| mdaniel wrote:
| 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 :(
| actionfromafar wrote:
| 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.
| technothrasher wrote:
| 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.
| boutell wrote:
| 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.
| technothrasher wrote:
| 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.
| red_admiral wrote:
| 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.
| thingfish wrote:
| 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.
| roelschroeven wrote:
| 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.
| cess11 wrote:
| 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.
| ryao wrote:
| 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.
| cess11 wrote:
| 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?
| robohoe wrote:
| And you're still locked in the Microsoft ecosystem.
| ryao wrote:
| 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.
| ryao wrote:
| > 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.
| thingfish wrote:
| You're right. I'll change it to "Windows XP or later".
| bandrami wrote:
| IDK, I wouldn't be surprised if it ran on Windows 2000 (still
| the best OS Microsoft ever made)
| guerrilla wrote:
| What's wrong with 2003?
| actionfromafar wrote:
| A bit bloated. I think NT 3.51 is the coolest, extremely
| stable.
| chuckadams wrote:
| 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.
| tomrod wrote:
| 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.
| yellowapple wrote:
| 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.
| bayindirh wrote:
| 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
| adra wrote:
| 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.
| bayindirh wrote:
| 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.
| chungy wrote:
| 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).
| heavensteeth wrote:
| right, I suspect "NT" is the category they're looking for.
| tomrod wrote:
| Hilarious that this was literally my exact thought.
| haglin wrote:
| 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
| musicale wrote:
| > 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.).
| fuzztester wrote:
| 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.
| chungy wrote:
| > 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.
| jug wrote:
| 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.
| floxy wrote:
| CrowdStrike
| SkiFire13 wrote:
| > except for maybe third party kernel driver issues which
| needs direct kernel access out of necessity.
| Borg3 wrote:
| 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 :)
| Aloha wrote:
| Why use something so... old?
| giancarlostoro wrote:
| 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.
| chasil wrote:
| Fans of SimH might give you many reasons for enthusiasm
| in retro-computing.
|
| https://simh.trailing-edge.com/
| Borg3 wrote:
| 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 :)
| fsckboy wrote:
| > _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.
| cgannett wrote:
| 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.
| chasil wrote:
| 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.
| signal11 wrote:
| 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.
| zoobab wrote:
| "later" is for lazzy developers.
|
| Better list the complete list of versions where it has been
| tested, like "Windows XP/7/8/10/11"...
| tomrod wrote:
| Win2k?
| dimava wrote:
| Also you are confusing Visual Studio and VSCode
| gwbas1c wrote:
| 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."
| NikkiA wrote:
| 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.
| JdeBP wrote:
| ryao's above proposition is the converse, that only Win32s in
| DOS+Windows ME was adequate to running this, and that the
| prior Win32s in DOS+Windows 98 and DOS+Windows 95 was not.
|
| To be honest, though, I very much doubt that anyone has fully
| tested either that claim or what the headlined article itself
| claims. A quick look at the source turns up things that
| require the full Windows NT security model, wide character
| versions of the API, and threads.
|
| It probably does not run on _any_ version of DOS+Windows, and
| "except Win95 and Win98" in the headlined article is likely a
| fumbled way of saying that, which didn't account for those
| not being the only versions of DOS+Windows that exist.
| skissane wrote:
| > 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.
| skissane wrote:
| > 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.
| nasretdinov wrote:
| I think there used to be a similar project for Linux, called
| CoLinux. However using a BSD kernel probably is a more
| sustainable choice if anything because it's much smaller and
| simpler
| zoobab wrote:
| I used CoLinux back in the days, it was bluffing:
|
| http://zoobab.wikidot.com/openwrt-and-user-mode-linux
| ryao wrote:
| That is user mode linux. Cooperative Linux is something else:
|
| https://en.wikipedia.org/wiki/Cooperative_Linux
|
| Interestingly, Wikipedia claims that User-mode Linux inspired
| Cooperative Linux.
| zoobab wrote:
| "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?
| quietbritishjim wrote:
| Sounds very interesting but it's quite short on details. If it's
| not Cygwin, then what is it?
|
| > MinC is a tiny kernel which runs on Windows. The rest of the
| software was taken verbatim from OpenBSD, version 6.1. This means
| that by installing MinC, you run OpenBSD on your Windows machine
| at native speed.
|
| How does it run this kernel? Presumably (?) it's running in user
| space, so how do these other tools communicate with it? Are they
| native(ish) Windows binaries like those built for Cygwin?
|
| I suspect this could be an ingenious technical achievement but
| it's just hard to tell what exactly it is.
| delta_p_delta_x wrote:
| > If it's not Cygwin, then what is it?
|
| Looking at the source code[1], it appears to be analogous to
| MinGW in the MinGW:GNU/Linux:Windows relationship, but replace
| with MinC:BSD:Windows. In other words, a minimal user-mode
| layer that presents BSD headers (and therefore BSD symbols,
| macros, and types), libraries, and core utils to end-users,
| thus abstracting over MSVC+.
|
| EDIT: replace 'MinGW' with 'Cygwin' above. So it _is_ Cygwin.
|
| I'd say calling it a 'kernel' is quite a stretch--there is not
| much that runs in kernel-mode, and everything runs atop the NT
| kernel which does the actual 'kernel'y stuff.
|
| [1]: https://github.com/dboland/minc
|
| +: Until one wants to use very recent and very nice Microsoft
| libraries[2][3], and these fail spectacularly because MinGW
| doesn't know about nice MSVC-specific stuff like SAL
| annotations[4].
|
| [2]: https://github.com/microsoft/wil
|
| [3]: https://github.com/Azure/azure-sdk-for-cpp
|
| [4]: https://learn.microsoft.com/en-gb/cpp/c-runtime-
| library/sal-...
| quietbritishjim wrote:
| > Looking at the source code[1], it appears to be analogous
| to MinGW in the MinGW:GNU/Linux:Windows relationship, but
| replace with MinC:BSD:Windows. In other words, a minimal
| user-mode layer that presents BSD headers (and therefore BSD
| symbols, macros, and types), libraries, and core utils to
| end-users, thus abstracting over MSVC+.
|
| Are you getting MinGW mixed up with Cygwin?
|
| MinGW does not emulate Unix-style APIs on Windows. (Actually
| I think there are exceptions but that is not its general
| purpose.) Instead, it is a port of _tools_ aimed at Unix-like
| OSs (e.g., Make, GCC) to Windows so that they can be used to
| build source code that is already targetted at Windows. For
| example, source code compiled with MinGW might include a call
| to the Win32 API CreateProcess(), but cannot include a call
| to the Posix API fork().
|
| Cygwin, on the other hand, allows compiling source code
| intended for *nix to native Windows binaries. For example, it
| compile code that calls fork(), getuid(), stat(), etc. It has
| that user-mode emulation that you mentioned (e.g. mapping
| between Unix-style UIDs and Windows SIDs), which happens in
| cygwin1.dll.
| delta_p_delta_x wrote:
| > 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...
| quietbritishjim wrote:
| I think most people don't use vanilla MinGW because you'd
| have to run it on Linux and cross compile. The MinGW
| toolkit itself (e.g. GCC) isn't targetted at Windows so
| ironically can't be compiled with MinGW, not even cross
| compiled - it needs something like Cygwin as in MSYS2.
| But you're right that it does provide unistd.h and I'm
| surprised about that. To be honest I was going to say in
| my comment that it doesn't but I fact checked first! I'm
| not sure that the bits missing count as "fundamental", I
| think they're all quite new bits rather than core Win32
| APIs. But maybe I'm just showing my age.
|
| Anyway, I'm sorry I've distracted away from your core
| point: as you've said, despite its name, it seems MinC
| just provides a user-mode API layer, just like Cygwin
| does.
| delta_p_delta_x wrote:
| > 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.
| kazinator wrote:
| 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!
| assassinator42 wrote:
| 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).
| bonzini wrote:
| 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.
| kazinator wrote:
| 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".
| regularfry wrote:
| I think it's a "kernel" in a similar way that user-mode linux
| is a kernel, right? It's not, but it looks like one to the
| programs it runs.
| thingfish wrote:
| I started out by creating a dll file with all the system calls
| implemented. Later I learned how a kernel actually works. So I
| rewrote it, emulating an interrupt to run in a separate kernel
| space. Could you name some of the details you want described?
| skybrian wrote:
| What you said here is helpful.
|
| Maybe start with an explanation of what it does without
| referring to Cygwin? That would be for people unfamiliar with
| Cygwin. Edit: actually you already did that, but starting off
| with "not Cygwin" is confusing.
|
| You could also explain how your approach differs from Cygwin,
| for people who do know it.
| quietbritishjim wrote:
| > 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...
| amiga386 wrote:
| Cygwin is WINE in reverse. It provides POSIX APIs in a Windows
| DLL, and the implementation tries to map them immediately to
| Windows API calls. You should then be able to take source
| written for Unix and you should be able to compile it and have
| it run on Windows.
|
| MinGW is a GNU toolchain for writing Windows-native software...
| that happens to be used quite often to compile Unixy non-
| Windows software, so they added MSYS which is derived from
| Cygwin and works like Cygwin (a DLL providing POSIX APIs
| implemented using Windows APIs), to make it easier to compile
| and run Unixy software unmodified.
|
| WSL is a VM that runs your choice of Linux kernel and distro as
| a guest OS, and adds integrations with the host system that
| make it seem much more native than it really is.
| haolez wrote:
| This is WSL2, right? I had the impression that WSL1 provided
| a better experience, but it was too complex to maintain and
| Microsoft decided to take the easy road.
| pjc50 wrote:
| WSL1 mapped Linux file API calls directly to NTFS file API
| calls.
|
| Unfortunately this was cripplingly slow for use in e.g.
| Git, so they moved to a model which is more of a VM.
| jandrese wrote:
| Is this why Cygwin is such a dog at disk access? It seems
| like anytime a Cygwin binary needs to open a file it
| suffers from 100ms of stall.
| heftig wrote:
| Pretty much. AFAIK you're waiting for Windows Defender
| and other hooks to run.
| moomin wrote:
| 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.
| mikepurvis wrote:
| 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.
| apatheticonion wrote:
| 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.
| amiga386 wrote:
| 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
| adgjlsfhk1 wrote:
| 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
| p_ing wrote:
| NTFS/ReFS are not slow. But there is an extensible file
| system filter layer above them that can slow things down.
| ormax3 wrote:
| 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/
| trallnag wrote:
| WSL2 supports all the good stuff like systemd. With WSL1
| I'd have to rely on Windows utilities or handroll a lot
| more things
| bornfreddy wrote:
| > 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).
| mikepurvis wrote:
| 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.
| freedomben wrote:
| 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
| teo_zero wrote:
| > 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
| red_admiral wrote:
| For a subset of "run shell scripts", I'm a fan of the
| one-executable-file busybox for windows.
| emulio wrote:
| > 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
| wvenable wrote:
| > 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.
| kevin_thibedeau wrote:
| WSL2 is a VM. WSL1 is Wine in reverse. They run ELF binaries
| compiled against the Linux ABI. Cygwin/Msys is a Posix
| compatability layer for PE binaries.
| ryao wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| dolmen wrote:
| 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/
| somat wrote:
| 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.
| oblio wrote:
| 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.
| dev_l1x_be wrote:
| > MinC is a Unix emulator for Windows, based on the OpenBSD
| operating system
|
| If anybody wondering.
| SpaghettiCthulu wrote:
| The System Boot demo video on the screenshots page won't play for
| me. Seems the format isn't supported by Firefox on Android.
| thingfish wrote:
| It is a .webm file. It won't play in my BlueStacks Android
| emulator either. Do I need to add an .mp4 file?
| blueflow wrote:
| Yes, webm support on mobile is horrible.
| Cthulhu_ wrote:
| 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.
| thingfish wrote:
| I added an .mp4 source. Still not playing in BlueStacks
| Android. Does it work in a real Andriod?
| blueflow wrote:
| 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.
| mdaniel wrote:
| According to ffprobe: Duration:
| 00:00:21.20, start: 0.000000, bitrate: 307 kb/s
| Stream #0:0[0x1](und): Video: h264 (High) (avc1 /
| 0x31637661), yuv420p(progressive), 960x672, 306 kb/s, 10
| fps, 10 tbr, 10240 tbn (default)
|
| 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)
| thingfish wrote:
| It works now. I had to add -pix_fmt yuv420p to my ffmpeg
| parameters. Thanks for the comments on this.
| Toorkit wrote:
| Playing fine for me, also Firefox on Android.
| dbacar wrote:
| 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?
| blueflow wrote:
| Better manual pages?
| thunder-blue-3 wrote:
| wow, TIL. Can't believe I've done nearly 40 circles around our
| sun and never knew about WSL/2.
| orra wrote:
| To be fair, WSL/2 didn't exist for most of those circles.
| i_am_proteus wrote:
| One reason would be if anyone does not want to, or is not able
| to, enable virtualization (WSL requires this).
| robohoe wrote:
| Many orgs' security policies don't permit WSL/2.
| nottorp wrote:
| 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.
| skinner927 wrote:
| This is pretty common. They turned off hyper-v.
| nottorp wrote:
| Thanks, I'll check that when the easter some-people-took-
| more-time-off period is over.
| thingfish wrote:
| You hit an important point here. Teaching IT to 16 jear old
| children is very much like being an admin for a large
| corporation. Most of them have installed VMWare, VirtualBox,
| Hyper-V and pfSense, depending on the preference of the other
| teachers. Most first-graders don't know anything about
| networking, so I didn't want to add WSL to that. I used
| Cygwin. Worked perfectly until I started to teach Sendmail.
| Sendmail runs in unprivileged mode. This means that it starts
| as root, but then switches to a user with very few rights.
| Cygwin couldn't handle that at first, but I got it working.
| But then students couldn't uninstall Cygwin anymore because
| of changed file ownership in Windows. I had to install a
| second Cygwin to uninstall the first. With MinC I took
| extreme care to get all the different models of Access
| Control Lists that are used in Windows right.
| hughw wrote:
| wait, first graders?!?
| cowmix wrote:
| 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.
| Borg3 wrote:
| Because I want more tight coupling with Win32 OS. Im old Cygwin
| user here. Actually, I cant work on Windows without Cygwin. Its
| very first thing installed on fresh system so I can bring all
| my tools with it :)
|
| I have free access to entire FS, I can run Win32 console tools
| as well inside bash. If I want true Linux environment, I can
| always spawn VM and use Xserver on Win32 to work on it (Xming).
| charcircuit wrote:
| You can have access to the entire fs (/mnt/c) and run exe
| files with WSL too
| Borg3 wrote:
| Probably WSL1.. Yeah.. But why should I bother with it if
| Cygwin does the work just fine? :)
| dehrmann wrote:
| 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.
| max_ wrote:
| Its such great recursive acronym. [1]
|
| [1]: https://en.m.wikipedia.org/wiki/Recursive_acronym
| hatly22 wrote:
| I wish they'd include a datestamp in these intro pages. This
| looks like it could be from any era.
| emmelaich wrote:
| Agree. Looking at github, the most recent commit is yesterday
| and some are two years old.
| huksley wrote:
| Does it support unicode and internationalization?
| thingfish wrote:
| Yes.
| jdndndb wrote:
| I don't get the negativity in this thread. Looks like a cool
| project, keep up the good work
| mrweasel wrote:
| It might be because it's a teaching tool, but the introduction
| contains a lot of fundament misunderstandings and factual
| mistakes.
|
| Take networking, one of the screenshots shows the output of
| ifconfig. That teaches you almost nothing about Linux
| networking, because ifconfig in Linux and OpenBSD are two very
| different tools, and you'd probably not teach people to use
| ifconfig on a modern Linux distro. Same for the boot process...
| rc and systemd are not the same, not even close.
|
| It is a very cool project but almost all references to Linux is
| wrong.
| skrebbel wrote:
| > almost all references to Linux
|
| The word "Linux" only occurs on the page once.
| smcameron wrote:
| 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.
| skrebbel wrote:
| 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.
| thingfish wrote:
| Ah! You got it. Are you a teacher? You should try it.
| skrebbel wrote:
| Nop not at all. In fact I'm a Windows user who doesn't
| actually know how to pipe things into sed. :-)
| thingfish wrote:
| 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.
| oblio wrote:
| You're wrong, it should be BMW Beetle.
|
| :-p
| kergonath wrote:
| > I don't mind.
|
| That's good. It's an interesting project and the discussion
| here is overall very interesting. Thanks for posting it.
| berlinbrowndev wrote:
| It is interesting and there so many options.
|
| Mingw
|
| WSL seems to be new now
|
| Cygwin
|
| And this one.
| berlinbrowndev wrote:
| Yea, options now.
| michaelsbradley wrote:
| MSYS2 ties it together for the best experience imo:
|
| https://www.msys2.org/
| heftig wrote:
| 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.
| michaelsbradley wrote:
| 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.
|
| [+] https://www.msys2.org/docs/environments/
| Dwedit wrote:
| 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".
| self_awareness wrote:
| 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_?
| acyou wrote:
| Looks great. What do learners do using this OS (besides opening a
| web browser)? What other teaching resources do you use?
| add-sub-mul-div wrote:
| > 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.
| nunez wrote:
| 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.
| bornfreddy wrote:
| 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.
| int_19h wrote:
| Given that this has build tools, can it run pkgsrc?
| m2f2 wrote:
| 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?
| colordrops wrote:
| I'm using the nixos wsl image and a majority of my linux
| workstation setup was just installed with almost zero effort.
| happy and impressed. Using the Ameliorated.io debloater plus
| nixos wsl makes Windows almost tolerable.
| dist-epoch wrote:
| git-for-windows (the default Windows git client) includes a
| bash.exe and a selection of gnu utils.
|
| it's based on MSYS2, so it's native. maybe you should check
| this one out.
| mananaysiempre wrote:
| GfW is remarkably hostile to installing any additional
| components (e.g. I've needed to get ahold of rsync),
| especially compared to normal MSYS2, which is as flexible as
| any Linux distro.
| ormax3 wrote:
| it seems possible to install GfW into an existing MSYS2:
|
| https://gitforwindows.org/install-inside-msys2-proper
| mananaysiempre wrote:
| 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.
| 38 wrote:
| 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
| gkfasdfasdf wrote:
| Ok so it's not Cygwin, how is it better (or worse) than Cygwin?
| ktm5j wrote:
| 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".
| kazinator wrote:
| Cygwin is based on something called Newlib, also of BSD origins.
| ConanRus wrote:
| >based on the OpenBSD operating system. MinC was written to help
| children at >. vocational education learn Linux
|
| WAT? Linux == OpenBSD now?
___________________________________________________________________
(page generated 2025-04-23 23:00 UTC)