LWN: Comments on "MinGW and why Linux users should care"

MinGW and why Linux users should care

k8to — Mon, 01 Dec 2008 05:35:06 +0000

But firefox using backspace for previous page is exactly the problem with targetting windows users. You first think: okay, we just want to make the program available to windows users, so you do a straight port. Then you get pushback from your new userbase and you think: okay, we should really make this application more reasonable for windows users by meeting their expectations. Then you think: well most of my users are windows users, and doing things different ways for different platforms is redundant code; I can improve quality by doing things the same way on all platforms. Then you have stupid windows behavior on all platforms.

MinGW and why Linux users should care

Cato — Mon, 24 Nov 2008 11:33:11 +0000

Your first example (backspace going to previous pages in Firefox on all platforms) has nothing to do with Windows - you could design Firefox not to do this, and I'm sure a user can change this behaviour, or at least an extension.

The sheer volume of users on Windows can be beneficial for OSS software, by stimulating bug fixes and features, as well as providing people to support the software.

As a co-developer of TWiki (before the recent fork by most of the developers, i.e. http://foswiki.org/ ), I supported it on Windows for a few years, and used it myself on Windows for a time when I didn't have a Linux server available. This helped Linux users, e.g. I18N hacks that I did to work around Windows Perl's (very broken) locale support also worked for Linux platforms with broken locales, Perl 5.005 hosting users where I18N regexes were more basic, etc.

Where Windows is somewhat broken but you still have ported the app, you can also deliver a Linux virtual machine using VMware, which is what the TWiki team did as well - this ends up being a good advert for Linux as well.

Doing cross-platform code always risks introduction of bugs, so wherever possible it's best to use a third party portability library, or a portable language such as Perl, Python, etc.

MinGW and why Linux users should care

rwmj — Mon, 24 Nov 2008 09:52:34 +0000

But that's your choice if you are the developer of a program. You could look at it another way and say by keeping up your standards you are bringing better UI concepts / timezone handling / whatever to Windows users.

Anyway there is nothing in the Fedora MinGW work which prevents you from #ifdef'ing pieces of code, or even removing troublesome features from the Windows port entirely.

MinGW and why Linux users should care

k8to — Sun, 23 Nov 2008 19:23:51 +0000

Yes, porting apps to windows means a larger user base, but it often means a worse program. Windows imposes all kinds of stupid expectations that developers bow to. Witness backspace going to the previous page on all versions of Firefox. I have an example at my place of work about how we ended up having to implement our own timezone code because the windows timezone stuff is broken in various ways. Now our code has timezone bugs from time to time that affect all our platforms.

My expectation as a Linux user is that programs that are available on Windows as well will cater primarily to Windows users (the larger potential market), and will become less usable.

LGPL is compatible with Cygwin's license (GPL+exceptions)

vonbrand — Sun, 23 Nov 2008 00:16:57 +0000

The Red Hat people must have done their assignment before distributing the library under this license... and they are careful with legal stuff.

In any case, it is not the license which restricts distribution, it is copyright law. All the license does is allow you to do stuff the law forbids.

I build all my Free/GPL Photoshop plugins with MinGW!!

qu1j0t3 — Sun, 23 Nov 2008 00:06:22 +0000

Indeed it rocks, not having to boot sucky XP! (plugins here)

(OT) Visual C++ 2008 Express Edition runs well under WINE

qu1j0t3 — Sun, 23 Nov 2008 00:04:06 +0000

For those who need more than MinGW. I'm trying to chase down weird runtime problems on Vista / XP SP3 so have been building with both.

select

nix — Sat, 22 Nov 2008 12:34:43 +0000

That's the best news I've had all week :)

MinGW and why Linux users should care

bockman — Sat, 22 Nov 2008 08:25:54 +0000

How about this:

1. Porting applications to Windows makes for a larger user base

2. A larger user base makes open source developers happier (as long as windows users
don't whine too much ... but then at least windows users don't flame much )

3. An happier open-source developer makes better open-source software

4. Better open-source software makes linux user happier

MinGW and why Linux users should care

k8to — Sat, 22 Nov 2008 03:57:19 +0000

Hmm, this seems to be "MinGW and why Linux developers and free software advocates should care". Maybe I'm splitting hairs, but I see nothing here to care about as a Linux user. Ho hum, some stuff can run on windows, which I don't use.

Sure the theory is that making these tools available to windows users will enable them to transition away from proprietary tools, but I don't buy it. I switched from windows to Linux in 1996 with no pain at all. If what Linux offers was compelling to most people, they would have already transitioned. I don't see any benefit to those who care about free software, because they're already off windows. I don't see any benefit to linux users in making linux desktop apps run on windows. The basic tools already work after a fashion in cygwin, and have for a long time.

I'm certainly not upset with these developers for working on this project, but I don't really see a benefit to me, the Linux user.

MinGW rocks!

rwmj — Fri, 21 Nov 2008 23:44:56 +0000

Of course we're huge fans of lilypond. Does it build with the Fedora MinGW project? If you'd like help, let me know.

MinGW and why Linux users should care

rwmj — Fri, 21 Nov 2008 23:43:08 +0000

I'm actually gonna go one better than Dan and say that I built quite a lot of the mingw32-* packages on Fedora 8. The ones we are building now are all done against Fedora 10 and some of them no longer just install on Fedora 8, in particular I know the C++ ones don't because some fundamental C++ library has changed its soname.

The "official" line is we are supporting RHEL 5 (through EPEL) and Fedora ≥ 10. Anything else that works is luck, or you will have to join the project and help support it yourself.

Rich.

MinGW and why Linux users should care

danpb — Fri, 21 Nov 2008 19:00:02 +0000

90% of our development has been done on Fedora 9 in fact, the source RPMs we have published should work just fine on F9. We're targetting F10/11 for our initial push but its quite possible we'll build them for F9 too once we get stuff through the package review process. If you want to keep up on details, join the fedora mingw mailing list....

LGPL is compatible with Cygwin's license (GPL+exceptions)

giraffedata — Fri, 21 Nov 2008 17:39:15 +0000

Red Hat permits [open source programs] to be linked with libcygwin.a/cygwin1.dll without libcygwin.a/cygwin1.dll itself causing the resulting program to be covered by the GNU GPL.

This wording shows a typical misunderstanding of copyright, wherein someone thinks a copyright license is something that restricts you in distributing software.

If the resulting program is not covered by GPL, nobody has Red Hat's permission to distribute it at all. (We assume of course that it's a derivative work so that Red Hat has copyright, because otherwise nobody needs Red Hat's permission and the whole point is moot).

I believe what the license means to say is, "... without Red Hat asserting any copyright over the resulting program due to libcygwin.a/cygwin1.dll itself."

select

aleXXX — Fri, 21 Nov 2008 08:50:16 +0000

Initial support for building Boost using CMake has been committed to the
Boost repository a few weeks ago.

Alex

MinGW and why Linux users should care

brouhaha — Fri, 21 Nov 2008 00:24:01 +0000

I've been using MingW on Fedora for several years to build Windows versions of several of my programs. It's great when it works, but I've found it difficult to build working versions of the compiler, tools, libraries, etc. for various Fedora releases. Some combinations work well, and some fail to build for non-obvious reasons. Lately I've been doing the cross-development in a virtual machine running Fedora 7, because I wasn't able to get MingW to work properly on Fedora 8 or 9.

The IMCROSS project is an attempt to solve these problems in a distribution-neutral way, and helped a lot, but I'm more excited about seeing MingW become a part of Fedora, with proper RPM packages. Now that the Fedora MingW SIG is making these packages available for Fedora 10, I am even more eager to upgrade to Fedora 10, though I might spend a bit of time finding out whether those SRPMs build and work on Fedora 9. Thanks, guys!

select

nix — Thu, 20 Nov 2008 22:50:52 +0000

Cross-compiling and Boost.Jam? You have a stronger soul than I. Just
changing CFLAGS and the preferred installation prefix was hell, and then I
had to figure out why jam coredumped as soon as it started... Autoconf
may be nasty but it's a lot kinder to packagers/builders than bloody jam.
While KDE was searching for a new build system for KDE4 I was in terror
that they'd choose Boost.Jam because it was used for a successful C++
project. Thankfully they are not utterly insane and chose something nicer
(now with added lowercase! ;)))) )

Cygwin can do this!

zooko — Thu, 20 Nov 2008 18:02:39 +0000

Yes, it can. The cygwin gcc compiler accepts an option named "-mno-cygwin". If you pass that option, then it produces a normal Win32 executable which does not require cygwin1.dll.

Here is a HOWTO on how to use it, written in 1999:

http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html

why Linux users should care

chsnyder — Thu, 20 Nov 2008 14:09:47 +0000

Yes. Portable software (works the same across all platforms) breaks down barriers to entry for potential Linux users. Firfox, VLC, Thunderbird -- these look and feel the same across all platforms, and it's a HUGE deal.

It means that when a Windows user tries Linux, she can appreciate the performance and usability improvements without having to re-learn how to use her applications. It means that when you leave your Windows computer at work, and fire up your Linux laptop at home, you can use the same apps, the same documents, and even the same preferences.

To put it another way, anything that makes it easier to write portable code makes it more likely to be developed first in Linux, and then ported to other OSes. That is extremely good news for Linux users.

select

rwmj — Thu, 20 Nov 2008 13:46:11 +0000

I packaged boost. Boost is a classic example of an upstream package where they've gone off and written their own build system, so they have to maintain all the complexity of building on every system out there, and I had to add to that complexity for cross-compiling. I also did another C++ network environment called POCO, and they also wrote their own build system, completely different from the boost one obviously.

C++ programmers, eh - haven't they suffered enough already?

While we're on the subject of portability libraries, APR (Apache Portable Runtime) is another contender.

Rich.

MinGW and why Linux users should care

PaXTeam — Thu, 20 Nov 2008 13:09:23 +0000

until binutils/ld gets proper support, one can use editbin.exe from VS to set these bits in the PE header (it's a console app, should run fine in wine).

MinGW and why Linux users should care

nix — Thu, 20 Nov 2008 12:39:04 +0000

cmake supports lowercase! Yay! Now I can learn it without getting a hideous headache ;)

LGPL is NOT compatible with Cygwin's license (GPL+exceptions)

nix — Thu, 20 Nov 2008 12:36:59 +0000

This is a *management layer*. It's going to get used by people who have existing virtualization systems and want to manage them. Nobody, but nobody is going to say 'hey! my management layer uses GPL, so I should switch virtualization systems to one that is GPL!'. They'll just not use libvirt.

This is a classic example of a library that is better LGPLed than GPLed.

LGPL is NOT compatible with Cygwin's license (GPL+exceptions)

rwmj — Thu, 20 Nov 2008 12:35:28 +0000

LGPL protects the libvirt code while not imposing itself on other code that we didn't write.

As a free software developer yourself, you should know the difference between public domain, LGPL
and GPL.

MinGW rocks!

hanwen — Thu, 20 Nov 2008 12:25:29 +0000

MinGW rocks! Our user base (see http://lilypond.org) is 60 % windows, and thanks to MinGW and NSIS (http://nsis.sf.net), I can ship weekly release in a neat .exe installer without ever having to touch windows.

select

aleXXX — Thu, 20 Nov 2008 12:23:10 +0000

...or QtCore if the license (GPL or commercial) is ok for you.

Doesn't Boost also have some file/threading classes in the meantime ?
Also signals..

Alex

LGPL is NOT compatible with Cygwin's license (GPL+exceptions)

fuhchee — Thu, 20 Nov 2008 12:21:27 +0000

nor do we want to discriminate against them by making them buy a special license

Since you consider licensing-based incentives to create free software as discrimination, what prevented you from (say) releasing libvirt into the public domain?

MinGW and why Linux users should care

aleXXX — Thu, 20 Nov 2008 12:21:27 +0000

Did you check lately ?
http://www.cmake.org/cmake/help/cmake2.6docs.html#section...

Since CMake 2.4.1 I think lower case commands are supported, and since
2.6.0 using all-lowercase is recommended.

Beside that, I can recommend the same: don't try to run executables
during the configure-step, in general this doesn't work for cross
compiling. If cmake recognizes that a cross-compiled executable should be
executed, it doesn't execute it, prints a warning, and writes a file for
setting the result-variables, with hopefully enough comments so this
becomes doable for the developer. Also the cross compiled executables are
kept so the developer can take them, execute them on the target platform
and enter the results manually in that file. That file can then be fed
into cmake using the -C argument.

Alex

select

danpb — Thu, 20 Nov 2008 09:52:54 +0000

MinGW at its core is just a cross compiler / toolchain, so it doesn't attempt to make Windows look like POSIX. It provides header files & linker stubs for the Win32 APIs. So you are developing against Win32 APIs, rather than POSIX.

If you want a Windows based runtime environment that strives to completely simulate POSIX APIs, then Cygwin is likely a more suitable choice. If you are happy to work against the Win32 APIs more directly, then GNULib provides wrappers around a number of Win32 APIs to give you a degree of POSIX compatability often good enough for many apps. Finally there are higher level APIs like GLib, QT, NSPR which attempt to provide a platform agnostic APIs.

LGPL is NOT compatible with Cygwin's license (GPL+exceptions)

rwmj — Thu, 20 Nov 2008 08:07:41 +0000

The people who are using libvirt are mostly developing a mix of in-house and proprietary
applications. They don't want to open source their code, nor do we want to discriminate against
them by making them by a special license. They don't need to buy a special license for libvirt on
Linux, nor to use proprietary APIs such as VMWare API / XenAPI.

select

rwmj — Thu, 20 Nov 2008 08:04:40 +0000

"MinGW" neither has nor doesn't have select().

The Fedora MinGW project is a cross-compiler that creates Windows executables. If you want
select-like ability, you could use some Win32 API for that such as - as nix says -
WaitForMultipleObjects.

But you could also (and we'd recommend) use some portability library like glib or NSPR which deals
with the matter in another way and has already been ported to whatever Win32 APIs exist (on
Windows) or whatever Linux/POSIX APIs exist on Linux/Unix.

select

nix — Thu, 20 Nov 2008 07:54:05 +0000

The latter, but thanks to WaitForMultipleObjects() et al one can fake
select(), and recent gnulib does so.

select

ncm — Thu, 20 Nov 2008 07:31:41 +0000

Am I correct in thinking MinGW doesn't have select()? Or does it, like Win32, have one, but it only works with sockets?

LGPL is compatible with Cygwin's license (GPL+exceptions)

dwheeler — Thu, 20 Nov 2008 02:50:17 +0000

First of all, the LGPL is typically compatible with the GPL, depending on their versions. See my FLOSS License Slide for more information on license compatibility.

BUT Cygwin's license is special: you can use ANY open source software license, without charge, with Cygwin. You can also use Cygwin to run closed source software, but you have to pay extra for that privilege. The Cygwin license, which is the GPL plus some exceptions, is at: http://www.cygwin.com/licensing.html.

The Cygwin license says: "Red Hat permits programs whose sources are distributed under a license that complies with the Open Source Definition [See http://www.opensource.org/docs/osd/ for the precise Open Source Definition and a list of the licenses certified by OSI as conforming to that definition] to be linked with libcygwin.a/cygwin1.dll without libcygwin.a/cygwin1.dll itself causing the resulting program to be covered by the GNU GPL. This means that you can port an Open Source application to Cygwin (TM), and distribute that executable as if it didn't include a copy of libcygwin.a/cygwin1.dll linked into it... Red Hat sells a special Cygwin (TM) License for customers who are unable to provide their application in open source code form."

MinGW and why Linux users should care

nix — Thu, 20 Nov 2008 00:38:38 +0000

But at least it's not quite as CAPITAL LETTER HAPPY as cmake, although
it's still CAPITAL LETTER HAPPY. Reading the cmake documentation or cmake
examples is almost physically painful. You'd think they hadn't realised
that lowercase letters are easier to read.

why Linux users should care

fuhchee — Thu, 20 Nov 2008 00:19:13 +0000

This is a little contrived, but the general point is to identify code which relies on undefined behaviour and only works on Linux by luck rather than design.

Cross-compiling per se will do very little to help with that. You'd actually have to test running the code on your targets, at which point you might as well run a native toolchain so as to get even more diversity.

why Linux users should care

proski — Thu, 20 Nov 2008 00:03:54 +0000

I can imagine it would work for specialized (e.g. scientific) applications, where potential users are experts in the problem area and can express their ideas in writing in a concise way.

As for general purpose applications (e.g. DVD burners, file managers etc), Windows users would probably only drain time of the developers without contributing back ideas and fixes. That could slow down or even halt the development, thus inconveniencing the existing users.

why Linux users should care

danpb — Wed, 19 Nov 2008 23:22:51 +0000

First, the title of the article would probably be better phrased as 'why open source users should care' rather than 'why Linux users should care'. I happen to use Linux for everything I do, but furthering open source software is my primary motivation.

The primary scenario faced is people evaluating whether to deploy a Xen/KVM Linux virtualization host vs a VMWare / Microsoft Hyper-V virtualization host. A common requirement is to be able to manage the virtualization host from a non-Linux client machine, Windows being very common, OS-X to a lesser extent. If a libvirt client were not available for Windows, then VMWare or Hyper-V would be chosen pretty much by default, instead of Linux. So providing Windows client binaries helps Linux adoption, which long terms helps all Linux & open source users. As a developer though I do not wish to use Windows myself, so using a cross-compiler like MinGW allows provision of Windows client binaries to help adoption of Linux virtualization, without requiring actual use of Windows on the part of the developer.

As a second scenario, there are developers who use Windows, but who value open source & wish to contribute to the project. By enabling use of libvirt (& other related apps & libraries) on Windows, it enables a larger pool of developers to become contributors to the project, beyond just Linux based developers. These developers will contribute new features, some of which help all users regardless of their host OS.

Addressing the last point raised, portability helps Linux users by identifying code which relies on undefined behaviour which "just happens" to currently work on Linux. As an example, printf() and the %s format specifier will happily accept NULL with GLibC, printing out '(null)'. This isn't true of other OS' implementation of printf(), so porting to Windows can identify this problem & result in a fix to the main codebase. It then turns out that even on Linux, passing a NULL to printf can cause crashes with certain optimizations the compiler may make - eg converting printf("%s", foo) to puts(foo). So, a porting to Windows identified & helped fix a problem which was lieing dormant during most use on Linux, but could ultimately still affect Linux. This is a little contrived, but the general point is to identify code which relies on undefined behaviour and only works on Linux by luck rather than design.

MinGW and why Linux users should care

rwmj — Wed, 19 Nov 2008 23:15:16 +0000

AC_TRY_RUN is definitely one of the autoconf constructs I'd like to discourage people from using.
To be fair though, only 2 out of 50+ of the libraries we ported actually used it.

Did I mention I'm no fan of autoconf ..?

why Linux users should care

rwmj — Wed, 19 Nov 2008 23:10:23 +0000

Maybe you could read more of the article. For example:

Bringing open APIs, apps and file formats to Windows users is important: It's important to Windows users because it breaks their lock-in and makes switching to a fully free platform easier down the road. It's important for [Linux developers], because your potential audience of users will increase by a factor of 10x or 20x.

Anything which increases the user and developer base, and brings in future Linux users, is good for Linux users and developers now. If you're a Linux developer forced to write software for Windows it's good too because you don't need to leave the Linux environment to use this cross- compiler.