4 ms·

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 ap

by Fnoord 6mo 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 6mo 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 6mo ago
  I think those are two solidly different camps of people
barrkel 6mo 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 6mo 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 6mo ago
    Huh? Signals have worked fine for a long time under Cygwin.
    - fc417fc802 6mo 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 6mo 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 6mo 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.
    - chasil 6mo ago
      No, seriously, give an ash-derivative a try. Dash has been benchmarked as 4x faster than bash. The bash manpage ends by stating that "bash is too big, and too slow."
      - Dylan16807 6mo ago
        > No, seriously, give an ash-derivative a try. To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated? If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.
        chasil 6mo ago
        No, because the Ada gsh also proved that the POSIX shell syntax could perform far better. Bash is prominent in announcing that it is "too big and too slow." It has said this for years. Why are its supporters so firmly in denial?
- dspillett 6mo ago
  I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that). > slow forking There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort. Cygwin can't do anything about the cost of forking processes, unfortunately.
- jasomill 6mo ago
  On your own system, sure. As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy? Not so much. I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.
radlad 6mo 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 6mo 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 6mo ago
  Qt looks nice as a user and gnome gtk isn’t too bad either
  - cestith 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.

by Fnoord 6mo ago

pjmlp 6mo 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 6mo ago
I think those are two solidly different camps of people

barrkel 6mo 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 6mo 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 6mo ago
  Huh? Signals have worked fine for a long time under Cygwin.
  - fc417fc802 6mo 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 6mo 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 6mo 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.
  - chasil 6mo ago
    No, seriously, give an ash-derivative a try. Dash has been benchmarked as 4x faster than bash. The bash manpage ends by stating that "bash is too big, and too slow."
    - Dylan16807 6mo ago
      > No, seriously, give an ash-derivative a try. To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated? If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.
      - chasil 6mo ago
        No, because the Ada gsh also proved that the POSIX shell syntax could perform far better. Bash is prominent in announcing that it is "too big and too slow." It has said this for years. Why are its supporters so firmly in denial?
dspillett 6mo ago
I've never had a problem installing from setup, but some tools were (maybe still are, it is a long time since I've needed anything not in the main repo) ported to windows using the cygwin dlls were distributed with their own versions and could clobber the versions you have otherwise (and have their versions clobbered when you fix that). > slow forking There isn't much that can be done about that: starting up and tearing down a process on Windows is much more resource intensive operation than most other OSs because there is a lot going on by default that on other OSs a process ops into, only if it needs to, by interacting with GUI libraries and such. This is why threads were much more popular on Windows: while they are faster than forking on other OSs too, especially of course if data needs to be shared between the tasks because IPC is a lot more expensive than just sharing in-process memory, the difference is not as stark as seen under Windows so the potential difficulties of threaded development wasn't always worth the effort. Cygwin can't do anything about the cost of forking processes, unfortunately.
jasomill 6mo ago
On your own system, sure. As a dependency of a shipping Windows application that needs to cleanly coexist side-by-side with existing Cygwin installations and optionally support silent install/upgrade/uninstall through mechanisms like SCCM, Intune, and Group Policy? Not so much. I do use the setup program to build the self-contained Cygwin root that's ultimately bundled into my program's MSI package and installed as a subdirectory of its Program Files directory, however.

radlad 6mo 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 6mo 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 6mo ago
Qt looks nice as a user and gnome gtk isn’t too bad either
- cestith 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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.