Server clinic: Xmingwin for cross-generating apps

Develop portable applications without proprietary lock-in

Xmingwin makes it practical to generate Windows programs from a Linux server. This column gives a recipe for setting up Xmingwin, and outlines the most important reasons for doing so.


Cameron Laird (, Vice president, Phaseit, Inc.

Cameron is a full-time consultant for Phaseit, Inc., who writes and speaks frequently on Open Source and other technical topics.

30 January 2003

I do much of my Window development on Linux hosts, even when working in C. This installment of Server clinic tells how you can, too, and why you might want to add mingw32-gcc source.c -o executable.exe to your usual repertoire of gcc source.c -o executable.

Automate chores with UNIX

Several of 2002's most popular Server clinic columns explained how to manage common desktop technologies, including PDF and DOC files, from servers. In one sense, this is the aim of many products and books, including WINE, VMware, and Linux in the Workplace. They all advertise the ability to replicate familiar desktop experiences from a Linux host. The Resources section, below, gives references to these alternatives and suggests where each best applies.

This column consistently handles such subjects from a different angle, though. The point this month is not to imitate Windows, but to automate the production of Windows deliverables with open source tools. Mingwin (also Mingw, Mingw32, and so on), the MINimalist Gnu for WINdows, fits this description. Mingwin is adevelopment suite for Windows, roughly comparable to Visual C++ or Borland's Delphi. Unlike the latter two, Mingwin's distinction is that it provides a UNIX-like environment under Windows. As it's based on the standard GNU compiler gcc, Mingwin also supports work in C++, Fortran, and other closely-related languages. It doesn't supply the baroquely integrated development environments (IDEs) common in Windows development shops. Instead, Mingwin's rich toolchest of robust utilities performs basic development operations: compilation, linking, and so on. All these are flexible and programmable, though, in the usual UNIX spirit.

Why does Server clinic take such an "old-fashioned" approach? Often I work with applications required to run equally under UNIX, Windows, and other OSes. It multiplies my productivity to be able to generate all deliverables from a single source set. By keeping sources on a Linux server, for example, and automatically cross-generating, I eliminate a whole layer of "Is it OK to re-boot? Are my file systems compatible? Has the project structure changed? ..." puzzles that seem to slow some development laboratories. Every developer change in my systems leads either to production of all deliverables, for all platforms, or an explicit error message. This immediate feedback prevents most surprises of the, "Well, we thought it was OK last week" sort.

If you, too, want to concentrate more on progress and less on platform hand-holding, you'll like Xmingwin. Xmingwin is my label for, "Mingwin run as a cross-generating application." Be aware: you'll also see it spelled as "cross Mingw32," "Xmingw32," or other variations. Usage isn't well standardized at this point. Recall that Mingwin installs on a Windows host and gives a UNIX interface; Xmingwin "retracts" that so that its operation is the same as on Windows, and it produces the same Windows-ready output but from a UNIX installation.

Installation is straightforward. I make a point of saying this, because I came across quite an assortment of correct, muddy, and misleading advice when I first worked with Xmingwin. Start with simple steps. For a basic x86-based Linux launch to your Xmingwin career, use a comprehensive bundle (see Resources for a link).

Unzip and unpack it:

Listing 1. Unpack sequence for Xmingwin bundle
      bunzip2 mingw-cross.tar.bz2
      tar xvf mingw-cross.tar

That's enough to start productive cross-generation work. While there are the usual thousands of possible variations standard for Linux developer tools -- link at different optimization levels, port to a different hardware variety of Linux, and so on -- a basic Xmingwin installation should take you a long way.

Use Xmingwin for cross generation

Add the distribution's bin directory to your PATH. Some developers favor schemes of linking or symbolic linking, so that they can type gcc at the command prompt, and have that resolve to, for example, /tmp/experiment/bin/mingw32-gcc. My own preference is to have gcc always mean the native compiler, and I explicitly invoke or configure mingw32-gcc as I need.

The first test of your new installation should be simply to ask it its version: mingw32-gcc -v. It's likely to report something like:

gcc version 2.95.3 20010315 (release)

Next, try the canonical "sanity test" -- write:

Listing 2. Source code for minimal "hello, world"
      #include <stdio.h>
      int main(int argc, char *argv[])
	  puts("It works!");

and compile it with:

Listing 3. Sample generation sequence for simple source
      export PATH=$PATH:$INSTALLATION/bin

      cc -o $WORKING/minimal $WORKING/minimal.c
      mingw32-gcc -I$INSTALLATION/mingw32/include \
            -o $WORKING/minimal.exe $WORKING/minimal.c

This script gives you a Linux application /tmp/minimal and its Windows twin /tmp/minimal.exe. Transfer the latter to a convenient Windows host, and you'll find it executes just as any other well-behaved Windows application.


And now you're in business. The Xmingwin/bin directory includes not just a cross-compiler, but cross-linker, cross-library-manager, and almost two dozen related tools for common developer operations. With a bit of practice, you can generate deliverables for Windows just as easily as you currently do for Linux, probably from the same Makefiles you're already using.

That's a lot of progress from 1998, when Colin Peters created the first Mingwin compiler. At that point, his version of gcc ran in the Cygnus environment. The evolution continued when Jan-Jaap van der Heijden re-hosted Mingwin as a native Windows application, and expanded Mingwin to include all GNU binutils and make; later, Mumit Khan extended these achievements with more Windows intimacy, including better Win32api binding.

GUIs and Win32-specific functionality is one focus for Mingwin; you can read more about that in Resources below, especially Khan's. Server clinic's emphasis is on applications that work on both Linux or Windows. My own development of that sort is split about equally between portable "pure C," and Critcl used for cross development.

Critcl is a fascinating extension to the Tcl programming language. Critcl starts by doing for Tcl roughly what Brian Ingerson's Inline does for Perl: allows "foreign" languages -- C, in this case, but in principle you might want SQL, assembler, or even wilder combinations -- to be embedded in the source of a host language. This provides advantages that it will take an entire future column to describe. The point for now is that Critcl inventor Jean-Claude Wippler has polished his creation sufficiently to make cross-generation easy. The result: a single source base is sufficient to generate both Tcl and C object code for both the host and cross environment, without any need to write make files or figure out linkage arguments. Critcl allows me to automate and finish challenging jobs far, far faster than conventional "by-hand" approaches.


But I digress: we'll talk more about Critcl in a future column. In the meantime, I'm interested in whether Xmingwin is as much a boon to you as it has been for me. Do your DLLs (Windows-specific, dynamically-loaded libraries, most often) work properly for you? More broadly, is development with just high-level Linux-hosted languages such as Python, Ruby, Tcl, Perl, REBOL, and so, going the way you want? Do you ever find you know of a job your Linux servers need done, but not how to do it, or even which language to use? Join us in the Scripting clinic discussion forum (click Discuss at the top or bottom of the article) to share your experiences.

Thanks to personal acquaintances Steve Landers, Rolf Ade, and Mo DeJong, among those who helped start me with XMingw32, and my congratulations to the MinGW team for the success and maturity of their achievement.


  • Participate in the discussion forum.
  • Check out the other installments of Server clinic.
  • Check out the Debian project, where you can download version 3.2-1 of mingw32 as an installable Debian package.
  • "The Unix Guide to Defenestration" is a book that preaches a UNIX-oriented approach to data-center management. Its case studies bear on the motivations and practices that make Mingwin interesting.
  • VMware is a commercial product that offers, among other variations, a virtual Windows host within a Linux session. Many developers with cross-platform responsibilities find VMware enormously helpful for its ability to share hardware and file-system resources between operating systems. A modest laptop can, for example, simultaneously appear to be a Windows and a Linux machine. VMware does not, however, particularly support automation of Windows in a UNIX style.
  • WINE is an almost decade-old project to define a compatibility layer for Windows applications implemented on other operating systems, principally Linux. Although most WINE energy goes into games and office automation, it's possible to use Windows developers tool such as Visual C++ through WINE.
  • CrossOver Office is CodeWeavers' proprietary WINE descendant.
  • Win4Lin 4.0 emulates at a lower level than WINE. This proprietary product of NeTraverse hosts an entire Windows95 or Windows98 instance as a Linux process. If you're happy with VMware, you might find Win4Lin even more satisfying for common uses, at a lower license cost.
  • Nicholas Petreley judiciously compares "Win4lin vs. VMware" in a 2000 article. Note that Win4lin installation has generally improved since his tests.
  • Linux in the Workplace is the most technically accurate description of the use of Linux as a desktop for office automation.
  • Cygwin, MKS Inc., and U/Win are essentially UNIX compatibility packages that allow UNIX applications and processes to be hosted on Windows.
  • This XMingw32 README explains XMingw32 generation and installation.
  • Inline is a special module that lets Perl programmers include functionality coded in C or other languages.
  • Critcl does much the same for Tcl, but extends the interfaces so they work across versions, operating systems, and other boundaries.
  • RubyInline is Ruby's equivalent to Inline.
  • Find more resources for Linux developers in the developerWorks Linux zone. The developerWorks Java zone also focuses on cross-platform programming.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Linux on developerWorks

ArticleTitle=Server clinic: Xmingwin for cross-generating apps