4 ms·

Before WSL, the best ways to run unmodified Linux binaries inside Windows were CoLinux and flinux. http://www.colinux.org/ http://www.colinux.org/ https://git

• Fnoord 5mo ago
  Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995. The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL. Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...). Those constraints also meant native applications instead of Web 2.0 NodeJS and what not. Java specifically had a bad name, and back then not even a coherent UI toolkit. As always: two steps forward, one step back.
  • pjmlp 5mo ago
    Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.
    • DaSHacka 5mo ago
      I think those are two solidly different camps of people
  • barrkel 5mo ago
    Just use ssh from Cygwin. DLL hell was rarely a problem, just always install everything via setup.exe. The single biggest problem it has is slow forking. I learned to write my scripts in pure bash as much as possible, or as a composition of streaming executables, and avoid executing an executable per line of input or similar.
    • fc417fc802 5mo ago
      Slow forking is only the second biggest problem IMO. The biggest is the lack of proper signals. There's a bunch of software out there that just isn't architected to work well without non-cooperative preemption.
      • quotemstr 5mo ago
        Huh? Signals have worked fine for a long time under Cygwin.
        • fc417fc802 5mo ago
          That's fake cooperative emulation of signals. It isn't preemptive (unless someone got a kernel driver approved while I wasn't looking?) thus many things either work poorly or not at all. Pause-the-world GC algorithms are a good example. Coroutine implementations also have to be cooperative. If you're curious, I believe the issue was discussed at length in the Go GitHub issues years ago. Also on the mailing lists of many other languages.
    • chasil 5mo ago
      Try using the Windows busybox port of "Bash": https://frippery.org/busybox/index.html https://frippery.org/busybox/index.html It has a subset of bash implemented on Ash/Dash. Arrays are not supported, but it is quite fast. The forking problem is still present, though.
      • barrkel 5mo ago
        Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions. For example, someone might do something like this (completely ignoring the need to quote in the interests of illustrating the actual issue, forking): for x in *; do new_name=$(echo $x | sed 's/old/new/') mv $x $new_name done Instead of something like this: for x in *; do echo $x done | sed -r 's|(.*)old(.*)|mv \1old\2 \1new\2|' | grep '^mv ' | bash This avoids a sed invocation per loop and eliminates self-renames, but it's harder to work with. Of course the code as written is completely unusuable in the presence of spaces or other weird characters in filenames, do not use this.
  • radlad 5mo ago
    > Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...). Maybe so, but my memory of Cygwin was waiting multiple seconds just for the Cygwin CLI prompt to load. It was very slow on my machines.
  • toast0 5mo ago
    > Java specifically had a bad name, and back then not even a coherent UI toolkit. Java was ahead of its time, now nothing has a coherent UI toolkit.
    • zaphirplane 5mo ago
      Qt looks nice as a user and gnome gtk isn’t too bad either
      • cestith 5mo ago
        Wx isn’t bad either. https://wxwidgets.org/ https://wxwidgets.org/ You don’t get an app that looks the same across platforms. You do get apps that look like they belong on your platform, even though the code is cross-platform. It uses the native toolkit no matter where you run it across Windows, GTK, Qt, Motif, macOS/Carbon, macOS/Cocoa, and X11 with generic widgets. Older platforms are also supported, like OS/2, Irix, and OSF/1. https://wiki.wxwidgets.org/Supported_Platforms https://wiki.wxwidgets.org/Supported_Platforms It’s a C++ project, but it has bindings for most of the languages you’d use to build an application. Ada? Go? Delphi? Ruby? Python? Rust? Yes, and more. https://wiki.wxwidgets.org/Bindings https://wiki.wxwidgets.org/Bindings
        • demetrius 5mo ago
          The problem is, most of these bindings are out-of-date. Delphi from 2012, Basic from 2002, D from 2016. wxRuby is a dead link. wxAda was already dead in 2009, as the discussion I can google suggests. So, if you use wxWidgets, you probably have to use either C++ or Python version, others are unlikely to be supported.
          • VZ 5mo ago
            wxRuby has been resurrected as wxRuby3, see https://mcorino.github.io/wxRuby3/ https://mcorino.github.io/wxRuby3/ Among actively developed bindings, there is also wxRust at https://crates.io/crates/wxdragon https://crates.io/crates/wxdragon
  • omoikane 5mo ago
    Cygwin works fine if I am compiling stuff locally for my own use, but that cygwin1.dll (plus any dependencies) is a problem for distribution. What I usually do is make sure my code builds with both Cygwin and MingW, and distribute the binaries built with MingW.
  • kristopolous 5mo ago
    I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes. I'm sure they did the best they could ... it was just really painful to use.
    • rmwaite 5mo ago
      This matches me experience as well. Some of my earliest rsync experiences were with the Cygwin version and I can remember scratching my head and wondering why people raved about this tool that ran so slowly. Imagine my surprise when I tried it on Linux. Night and day!
  • da_chicken 5mo ago
    It's not just DLL hell. Cygwin was also notorious for being really out of date. Security vulnerabilities and missing features were both very common at one point.
  • e40 5mo ago
    I have used cygwin for 30 years and never had any dll hell issues, because all the programs came from the cygwin installer. Never once needed something outside it.
• pjmlp 5mo ago
  Nope, the best way was VMWare Workstation, followed by Virtual Box.
  • doublerabbit 5mo ago
    And before those Virtual PC by Connectix. Which Microsoft bought and dumped.
    • pjmlp 5mo ago
      More like they integrated the technology they cared about into their products.
• barrkel 5mo ago
  Cygwin implements a POSIX API on Win32 with a smattering of Nt* calls to improve compatibility but there's a lot of hoop jumping and hackery to get the right semantics. Fork isn't copy on write, for one thing. I was a Cygwin user from about 1999 to 2022 or so, spent a little time on wsl2 (and it's what I still use on my laptop) but I'm fully Linux on the desktop since last year.
  • niobe 5mo ago
    Ha that tracks my own usage and timeline almost precisely, although I was using cygwin and WSL2 in parallel for a while. Lot of complaints about cygwin speed here, but NTFS filesystem access is actually a lot faster on cygwin than WSL2!
• radiator 5mo ago
  Nowadays MSYS2, which does depend on cygwin under the hood, offers such a package manager (pacman of Arch Linux) and it is quite a user friendly to run native POSIX binaries on Windows without a linux VM.
  • anthk 5mo ago
    w64devkit it's fine too; with just a few PATH settings and SDL2 libraries I could even compile UXN and some small SDl2 bound emulators. https://github.com/skeeto/w64devkit https://github.com/skeeto/w64devkit
  • ethin 5mo ago
    In my personal experience, Msys 2 would work great until it didn't. Unless this has changed, from what I remember, Msys2 compiled everything without PIC/PIE, and Windows does allow you to configure, system-wide, whether ASLR is used, and whether it's used "if supported" or always. If that setting is set to anything but off, Msys2 binaries will randomly crash with heap allocation errors, or they do on my system. It happened so much to me when I had actual coreutils installed that I switched to uutils-coreutils even though I knew that uutils-coreutils has some discrepancies/issues. Idk if they've fixed that bug or not; I did ask them once why they didn't just allow full ASLR and get on with things and they claimed that they needed to do non-ASLR compilations for docker.
  • ktm5j 5mo ago
    MSYS2 is my favorite in this area. Super lightweight and easy to use, highly recommend.
  • Dwedit 5mo ago
    MSYS2 is very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building. It doesn't help that the package simply named "gcc" is for the MSYS2 target.
• red_admiral 5mo ago
  Developing on cygwin, however, was a right pain. If a C library you wanted to use didn't have a pre-built cygwin version (understandable!) then you end up doing 'configure, make' on everything in the dependency tree, and from memory about two thirds of the time you had to edit something because it's not quite POSIX enough sometimes.
  • smackeyacky 5mo ago
    Ha ha doing Unix like it was 1989. At the time I thought configure was the greatest of human achievements since I was distributing software amongst Sun machines of varying vintage and a Pyramid. I want to say good times but I prefer now ha ha
    • jesuslop 5mo ago
      autotools felt old even in 90's
      • chuckadams 5mo ago
        Autotools was designed to produce a configure script with zero dependencies other than the compiler toolchain itself. I always thought it would be a good way to bootstrap a system configuration database (like the kind X11 already had, the name I forget) but it turned out to be too convenient to just drop autotools into every project instead. So now even today, compiling any GNU package means probing every last feature from scratch and spitting out obscenely rococo scripts and Makefiles tens of thousands of lines long. We can do better, and have, but damn are there a lot of active codebases out there that still haven't caught up.
  • jasomill 5mo ago
    Reminds me of a fun weekend I spent ~5 years ago building the newest version of every GNU program I could get to build on NEXTSTEP 3.3 (running on 68k NeXT hardware) without major changes.
• EvanAnderson 5mo ago
  On Windows NT building software from source under Interix[0] (nee OpenNT, later "Subsystem for Unix Applications") was pretty nice. Interix was implemented as proper NT kernel "subsystem". It was just another build target for GNU automake, for example. (Being that Interix was a real kernel subsystem I have this fever dream idea of a text-mode "distribution" of NT running w/o any Win32 subsystem.) [0] https://en.wikipedia.org/wiki/Interix https://en.wikipedia.org/wiki/Interix
• firesteelrain 5mo ago
  I thought WSL2 is functionally a virtual machine with deep host integration. That’s why you need HyperV.
  • NeutralWanted 5mo ago
    Sort of. Technically speaking, just enabling hyper-v turns your base windows install into a VM. Wsl2 then just runs along side
    • firesteelrain 5mo ago
      Huh that’s interesting I didn’t realize that
    • IcyWindows 5mo ago
      Enabling hyper-v turns your base windows install into a VM host, not a virtual machine itself.
      • noisem4ker 5mo ago
        It's kind of both. Hyper-V is a bare-metal (type 1) hypervisor. Windows runs virtualized, one level above it, in a privileged (host) VM, next to other (guest) VMs. https://en.wikipedia.org/wiki/Hyper-V#Architecture https://en.wikipedia.org/wiki/Hyper-V#Architecture
• pmontra 5mo ago
  I've been running colinux for years until early 2009 when I reinstalled my laptop with Ubuntu 8.04 and Windows XP in a VM. So much faster.
• charcircuit 5mo ago
  >Cygwin was technically the correct approach Requiring every single Linux app developer to recompile their app using Cygwin and account for quirks that it may have is not the correct approach. Having Microsoft handle all of the compatibility concerns scales much better.
  • Fnoord 5mo ago
    Why not? That is just a matter of porting stuff over, like a FreeBSD ports collection, an apt repo, or a bunch of scripts for Proton/Wine such as Lutris. Cygwin started in 1995. Microsoft wasn't cooperative with FOSS at all at that point. They were practicing EEE, and eating some expensive Unix/VMS machines with WNT.
• electroly 5mo ago
  Technically correct by some estimation, perhaps, but Cygwin is a crazy approach, was slow (contrary to the implication of the "low cruft" claim), was not as compatible as these other approaches, required recompilation, and was widely disliked at most points in its life. There's a lot of crazy voodoo stuff happening in cygwin1.dll to make this work; it totally qualifies as "hacking in some foreign Linux plumbing", it's just happening inside your process. Just picture how fork() is implemented inside cygwin1.dll without any system support. Cygwin doesn't work at all in Windows AppContainer package isolation; too many voodoo hacks. MSYS2 uses it to this day, and as a result you can't run any MSYS2 binaries in an AppContainer. Had to take a completely different route for Claude Code sandboxing because of this: Claude Code wants Git for Windows, and Git for Windows distributes MSYS2-built binaries of bash.exe and friends. Truly native Windows builds don't do all the unusual compatibility hacks that cygwin1.dll requires; I found non-MSYS2-built binaries of the same programs all ran fine in AppContainer.
  • skissane 5mo ago
    > but Cygwin is a crazy approach, was slow A lot of this is issues Microsoft could fix if they were sufficiently motivated e.g. Windows lacks a fork() API so cygwin has to emulate it with all these hacks Well, technically the NT API does have the equivalent of fork, but the Win32 layer (CSRSS.EXE) gets fatally confused by it. Which again is something Microsoft could potentially fix, but I don’t believe it has ever been a priority for them Similarly, Windows lacks exec(), as in replace the current process with new executable. Windows only supports creating a brand new process, which means a brand new PID. So Cygwin hacks it by keeping its own PID numbers; exec() changes your Windows PID but not your Cygwin PID. Again, something Microsoft arguably could fix if they were motivated
    • electroly 5mo ago
      > A lot of this is issues Microsoft could fix if they were sufficiently motivated... They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available. In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got. If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.
• jszymborski 5mo ago
  I remember when I first put cygwin in my path on Windows and it felt like magic. I can just ssh and git now? No need for putty or WinGit????
• tredre3 5mo ago
  > However, it lacked the convenience of a CLI package manager back then Cygwin still lacks that to this day, you have to fire up to GUI installer to update packages. MSYS2 is cygwin with pacman cli.
• mech422 5mo ago
  I used to use LOADLIN.exe - worked pretty, IIRC
• lmm 5mo ago
  Assuming you were on NT-lineage, rebuilding for SFU (Interix) was the technically correct and nice implementation, though since a lot of Linux programs are non-portable (or have maintainers who mistakenly think they can do better than autotools) it was a pain in practice.