[Fnoord]

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.

[barrkel]

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.

[jasomill]

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.

[fc417fc802]

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]

Huh? Signals have worked fine for a long time under Cygwin.

[fc417fc802]

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.

[dspillett]

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.

[chasil]

Try using the Windows busybox port of "Bash":

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]

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.

[emmelaich]

You could also use the inbuilt substitution mechanism:

    $ parameter='fisholdbits'
    $ echo ${parameter/old/new}
    fishnewbits

[chasil]

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]

> 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]

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?

[chasil]

  $ rpm -q bash
  bash-5.1.8-9.el9.x86_64

  $ man bash | sed -n '/BUGS/,/^$/p'
  BUGS
       It's too big and too slow.

[toast0]

> 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]

Qt looks nice as a user and gnome gtk isn’t too bad either

[cestith]

Wx isn’t bad either. 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

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

[demetrius]

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]

wxRuby has been resurrected as wxRuby3, see https://mcorino.github.io/wxRuby3/

Among actively developed bindings, there is also wxRust at https://crates.io/crates/wxdragon

[bmn__]

> [Wx] uses the native toolkit no matter where you run it

This is false. https://news.ycombinator.com/item?id=24250968 https://news.ycombinator.com/item?id=24259040 It was false in 2020 and it is still false today (I just checked).

I wish the Wx proponents would stop saying these things. Who exactly are you trying to fool? Do you have no concept of reputational damage? What good comes from a claim that is so easily disproven by just installing a Wx application and looking?

[cestith]

Do you understand the difference between a toolkit API and a graphical widget?

I’m not trying to fool anyone. I'm not affiliated with the project. I’m just aware of it and have used it a few times. You, on the other hand, have called me a liar and a fraud because I repeated exactly what the project docs state and which your two links do nothing to contradict. In fact, you linked to yourself being corrected by the actual maintainer of the project. Did you read anything he wrote?

[bmn__]

> Do you understand the difference between a toolkit API and a graphical widget?

I think I do. I have taken a few minutes on the Web to compare that what I had in mind is correct. What was the point of asking this question? Was it to trap me in a gotcha, or paint me as clueless, or what?

> have called me a liar and a fraud because I repeated exactly what the project docs state

Good, you realise you are taking on the claims made by Wx on paper. However, there's more to the world. To get the full picture, you have to also engage with what I have listed. The docs say one thing, the reality shown in the screenshots say another. There is a contradiction. It remains unresolved, not for lack of trying on my part.

> your two links do nothing to contradict

You are not further allowed by me to invalidate what I was writing about by simply disregarding the evidence. Engage with the points I was making. The differences in look and feel between Wx and native are plain for everyone to see and verify. So, what now? Who is right?

> Did you read anything he wrote?

Yes. Examine this:

his claim> OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native

my counter-evidence> Well, let's verify that… https://i.imgur.com/uHfjoUs.png No, they're not.

his deflection> Sorry, I don't know what is this supposed to prove

So instead of admitting that there is a contradiction, he just pretends to not understand it.

Also examine this:

> look good

> look good

> looks fine

> look good

I never mentioned anything about looking good, this is a distraction designed to deflect from the central point I was making. As I wrote before, the central point made by me remains completely unaddressed.

Alas, I cannot deal with those crazy-making techniques, his behaviour measured by outcome is indistinguishable from the mentally ill. With the help and advice from a friend, I came to the conclusion that it was not safe for me to respond, so I then decided not to.

[kristopolous]

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]

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!

[radlad]

> 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.

[omoikane]

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.

[da_chicken]

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]

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]

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]

I think those are two solidly different camps of people