RayDonnelly

It's really nice to see the amount of gnome stuff we've got now. And GTK-3 on Windows looks quite pretty I think.

IMHO you have managed to get into a situation where Windows has been asked to run two different cygwin1.dlls at the same time and Cygwin has detected this. (I recommend using Process Hacker 2 for helping to track down which processes have handles to cygwin1.dll).

This is unfortunately just something you need to manage for yourself.

Cygwin got itself into trouble like this because it never had a good enough package management story (because Windows can't overwrite a currently loaded dll, they didn't attempt a good system package manager, as best I understand it) so developers would end up bundling cygwin1.dll alongside their own executables instead, so there would end up being lots of cygwin1.dlls on a users machine.

The same thing could happen on MSYS2 if you had two MSYS2 environments, however, to get them both in-sync again, you'd just have to do "update-core" in each and that would be that.

Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.

It's the latter. Arch Linux is Arch Linux.

The same way that Cygwin implements fork (the msys2-runtime is a very light fork of Cygwin):

https://www.cygwin.com/faq.html#faq.api.fork

The packages in the msys2 repository (which, if they link to msys-2.0.dll are all GPL licensed) only really exist to aid building the packages in the mingw32 and mingw64 repositories which don't implement fork() at all and are the real purpose of MSYS2, i.e. providing normal Windows software.

If you want a POSIX-y system, please use Cygwin.

Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution.

We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date.

Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant.

Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.

Autorebase hell is I hope a thing of the past. We made all of the executables involved in the running of pacman static (except msys-2.0.dll obviously, and some post-install scripts, but we try to remove those) and split the update procedure into two parts, "update-core" which handles updating the core of MSYS2 and pacman. The rest of the system update is then completed with "pacman -Su". We've had no reports of update failures since then.

We didn't remove support for symlinks, you can enable them in the MSYS env. var winsymlinks:nativestrict if you want. If symlinks didn't require special permissions, we'd enable them by default, but unfortunately they do. Maybe one day Microsoft will change their minds on this. I can only hope so. I guess you may have meant that we don't create the 'Cygwin special' symlinks that winsymlinks:native falls back to when it doesn't get permissions? Yes those are an interoperability disaster for MSYS2 when native programs read them.

This sounds like you're trying to scare people off using MSYS2 altogether with the GPL bogey man, and it misrepresents the point of MSYS2.

The 'msys2' software repository (as opposed to the 'mingw32' and 'mingw64' ones) contains things that link to msys-2.0.dll which is GPL, and yes it includes compilers and linkers that in turn generate new PECOFF objects that in turn link to msys-2.0.dll. This repository exists mostly as build scaffolding (Autotools, bash) to support building native Windows software (as exists in the other two repositories) and that is the real goal of MSYS2. If you want POSIX-y GPLed software on Windows, use Cygwin.

You are right to caution people on the naive usage of our msys2/gcc package, but you've made it sound like something much worse than it is.

As soon as Microsoft open sources PowerShell I'll be more than happy to take a look at it and perhaps add it to MSYS2. Until then for me and many like me, it's neither half bad nor half good, it lies orthogonal to the scale on which I judge software.

As far as I can tell (initial glance only), building this port requires Visual Studio which is a shame. It'd require a bit of effort to port. I wish MS had gone down the CMake route again.

As for Cygwin's sshd, we don't want to step their toes any more than we already have.

In my industry, app data size swamps app executable size by a factor of about 2000.. So all this app thinning stuff seems useless (to me).

MSYS2 packages are signed by Alexey Pavlov. Pacman won't install unsigned ones by default.

We hear you, so long as our project isn't hijacked we'll never agree to malware (or any other) bundling.

Hopefully SF will not deem us to have abandoned the project either!

There was a recent discussion on Reddit where some MSYS2 users chimed in that which may cover some useful ground:

http://www.reddit.com/r/cpp/comments/2v6vlg/decission_which_...

Thanks, sure, POSIX is a round hole and Windows a square peg, but I think that the excellent work done by Cygwin over the last few years has done a great deal to file down the edges of the Windows peg. MSYS2's hacks on top usually function ok.

With Git, I can clone very large projects almost as quickly with MSYS2 as I can ArchLinux. We did begin to port msysGit (the native, non-MSYS executable, yeah, go figure) to MSYS2 and found very little speed improvement so stopped since the msys2 version is much more functional and always up-to-date.

Using Autotools on MSYS2 isn't significantly slower than on GNU/Linux. You can try building any of the many Autotools based projects we provide to see this for yourself. Besides, for software which relies on Autotools for it's build system, there's no choice but to use it (outside of cross compilation).

That NTFS (and the Windows filesystem layer) isn't fast is independent of MSYS2 vs native Windows anyway.

An anti-virus will slow down all Windows tasks to an unusable crawl, just run your scan overnight and take care about what you click on. MSYS2 isn't hit worse than, say Visual Studio. Fundamentally MSYS2 is software distribution who's end product is native Windows applications aimed at the user. The POSIX stuff exists just helps us get there (this is why we don't provide X Windows; if you want that, use Cygwin), so for example using Qt Creator as supplied by MSYS2 should give an experience that's roughly the same as using Qt Creator supplied by the Qt Project (but much easier to maintain).

Apart from for installing and updating packages, you can avoid the MSYS2 console and just run programs in C:\msys64\mingw64\bin.

The security advantages we bring via shared packages (e.g. libraries) are very worthwhile.

> Trying to deal with SSH through bash and msys is not a user friendly experience. PuTTY is the gold standard of SSH clients on Windows.

Since on MSYS2, things are shared, your SSH keys are shared between all applications that use them in ~/.ssh, as you'd expect. I use mklink /D to unify my Windows User folder and my MSYS2 HOME folders (be careful not to use our un-installer if you do this though, if follows the symlink :-(). We do have putty but I haven't checked that it doesn't use %AppData% or worse, the Windows registry to store keys. If it does that's a bug we'll fix. To install putty:

$ pacman -S mingw-w64-x86_64-putty

I was asking about "MSYS2/MinGW-w64".

You seem to be confusing mingw.org (http://www.mingw.org/wiki/getting_started) and MinGW-w64 (http://mingw-w64.sourceforge.net) and your rant seems entirely directed at mingw.org.

The software distribution I was asking the parent poster about is MSYS2 (http://msys2.github.io/ and http://sourceforge.net/projects/msys2/), do please come back with constructive criticism on that project if you are interested enough to investigate further.

Care to explain what's gross about MSYS2/MinGW-w64? I'm genuinely interested in making it less gross.

There's also MSYS2, we are on SourceForge, but we'll never bundle or allow bundling crapware with our installer (and we release .tar.xz files for people who don't like installers).

https://sourceforge.net/projects/msys2/

No. As stated in the article, the array was not copied when it was assigned to var b as changes made to it via b also showed up in a.

This email just in today:

http://lists.qt-project.org/pipermail/android-development/20...

It's native look and feel though, and not native integration. However AFAIK it goes to great lengths to blend in with the actual device you're running it on.

Yes, pacman is wonderful. We're very grateful to the Arch Linux devs.

You guys are all correct, we've not paid nearly enough attention to marketing. Here's the description I tried to post:

MSYS2 is an updated, modern version of MSYS, both of which are Cygwin (POSIX compatibility layer) forks with the aim of better interoperability with native Windows software.

The name is a contraction of Minimal SYStem 2, and aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains.

We wanted a package management system to provide easy installation of packages, and ported Arch Linux's pacman. This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system (makepkg) which is used to make these packages. The set of software-building recipes (PKGBUILDs) for MSYS2 itself are at:

https://github.com/Alexpux/MSYS2-packages

.. and those for MinGW-w64 (i.e. native Windows software) are at:

https://github.com/Alexpux/MINGW-packages

Both 32 and 64bit are supported.

mingw and MinGW-w64 are not the same thing, so that URL would be less than useful.

MSYS2 is firmly in the MinGW-w64 camp. The schism happened when GCC was ported to 64bit Windows and we've not looked back since (much; working together is always to be preferred but sometimes that is not possible).

We're investigating why sourceforge will not let me update our description.

If you like your FOSS I can recommend MSYS2.

http://sourceforge.net/p/msys2

(disclaimer: I work on MSYS2)

This is an interesting project for sure. WinGDB is quite similar.

From the rationale page:

"Large numbers of these developers world-wide use Visual Studio as their primary IDE. Either by preference, or other external factors."

I wonder if having fairly good tooling is one of those factors? And if so, will this encourage people to stick to Visual Studio?

I'd recommend developers to try Qt Creator for Android (there's no requirement to use Qt with it if you don't want to). IMHO, for native development it is already good, improving rapidly and has the advantage of being cross platform and Open Source, though it's build system (qmake .pro/.pri) is arguably worse than MSBuild. Once Qbs support is finished I'll happily retract that statement.