Xmingwin For Cross Generation Applications

An anonymous reader writes "Xmingwin makes it practical to generate Windows programs from a Linux server. This column gives a recipe for setting up Xmingwin, outlines the most important reasons for doing so and shows you how to generate executables for multiple platforms -- including Windows DLLs -- from a single Linux source."

Comments

ohhh maaaan

[nocomment]

I've been trying to migrate people _away_ from windows, this only makes it easier for them to stay ;-)

Of course it also help linux break into places it wasn't allowed before, so i've got to say bravo for that!
Still, should be running BSD ;-p

Re:ohhh maaaan

[Cookeisparanoid]

Im not sure I agree, wine/winex helps to windows apps in Linux and helps to give Linux a higher profile. I dont think its existance stops the adoption of or the production of apps for Linux.
I would have thought the more choice and flexibility the better.

Testing ?

[MosesJones]

Winner of Company Most likely to produce Buggy Software....

The people who do this. You can produce work on the Server but to properly test you still need the windows environment. So you have to deploy to that, given that you need a testing environment per developer as well as for UAT and QA then your costs aren't really reduced. The advantages in terms of compile speed are killed in terms of transfer and deployment.

Somebody somewhere clearly things they need this, somebody somewhere doesn't work in large teams and on commercial apps.

Sorry to dis someones work, but I'd be more interested in a decent Open Source windows IDE on windows than being able to do a fraction of the work on Linux... and I loathe MS-Windows. Why do so many Open Source projects have to ape MS rather than take on the beast.

Too many people, too many projects. Come and save us IBM.

Re:Testing ?

[catscan2000]

If you're looking to replace Visual Studio for programs that don't rely too much on the COM wizards and such, try out Dev-C++. It's pretty fast, too, and it uses GCC :-).

Re:Testing ?

[batkiwi]

The number one advantage I can see for this in the environment I work in is automated builds.

We have big linux servers that do all of our java compiling nightly (and auto-runs junit tests/etc), but you can't do that for your windows dll's without a seperate box. Now that need is gone.

Re:Testing ?

[jd142]

You are right. That is sad. I'm doing an app for our students so they can sign up for job interviews via a nice little web app. Because it uses javascript, I decided to test the app on:

--Microsoft Internet Explorer 5.5 and above on any version of Windows 9x or later
--Mozilla 1.0 and above on Windows or Linux
--Netscape 7.0 and above on Windows or Linux
--Opera 6.0 on Windows
--Konqueror 3.1 on Linux

We don't have any macs in the building, and I just haven't gotten around to walking to one of the other buildings and checking it out. But I will before it goes live.

During the interview season I suppose we'll get maybe 2,000 hits a week from our 750 students. But their eventual livlihood depends on their student jobs now, so this is very important to them.

And people rag on those of us who work for the government instead of private business (which is, of course, perfectly efficient and hires only the best and brightest people).

Xmingwin?

[gwernol]

This sounds like intriguing functionality, but really can't they find a better name than Xmingwin? Its a horrible name, practically unpronounceable, difficult to remember and spell, easy to confuse with other similar projects.

I know this might sound like a troll but I'm serious about this. Projects do themselves no favors by adopting badly thought out names. A confusing name makes it less likely that I will use or evangelize this software. When someone asks me for a recommendation for a software platform for generating Windows executables on our Linux servers I'll be embarassed to say Xmingwin (I work in a corporate environment). Its hard to say, hard for someone to understand when said and worse it sounds amateurish. Its almost as bad as Ogg Vorbis: very geek-cool to use Klingon but the kiss of death in a serious corporate environment.

This isn't a slam on open source - god knows there are too many dumb names in the closed source world - but a plea for developers to think about naming. Its an important part of getting your technology talked about and accepted.

Re:Xmingwin?

[josh crawley]

I pronounce it like X-ming win. like ex-Penguin (with the p soundling like M)

Xmingwin vs gcc-mingw32

[----]

What's the difference between this announcement and the pre-existing mingw32 integration with gcc ?

• lets see, we have ...
• The mingw-runtime package

  The Public Domain versions of the MSVCRT header and library import files
  Beginning with version 2.0 C89 and C99 extensions are provided that include
  but not limited to, wide character functions, floating point environment
  functions (declared in fenv.h), floating point classification functions and
  macros, the inttypes.h format conversion macros, stubs for msvcrt.dll
  underscored functions that are now part of C99 standard, and a replacement for
  fseek and fwrite that are safer on W9x. The POSIX dirent functions have been
  moved from libmingw.a to libmingwex.a so those desiring 'Minimal' can easily
  have it. The ISO C extensions are visible by default within the headers, to
  remove them define __NO_ISOCEXT. You need to explicitly add these functions
  until they are eventually added to the GCC specs file for inclusion by default.

• The gcc-mingw32 package

  Mingw32 support headers and libraries for GCC

How exactly is this different? We've been able to produce win32 executables using mingw and gcc for years now.

Re:Xmingwin vs gcc-mingw32

[DivineHawk]

The same here as well. I've had no problems using the cross compiler here: http://www.libsdl.org/extras/win32/cross/

for quite some time now.

(Link referenced by http://www.mingw.org/mingwfaq.shtml#faq-cross )

Re:Xmingwin vs gcc-mingw32

[vrmlguy]

The difference is that this is running mingwin as a cross-compiler. Yes, we've been able to produce win32 executables using mingw and gcc for years now, but that's by running everything on a Windows-based system. Now we can run the same suite of tools on a Unix-based system.

Quick Note

[jchawk]

For those of you wondering, this only works for apps that you are currently writing. It isn't going to work for just any windows app, but it's still kinda neat.

---

If you just signed up for a new sprint pcs cell phone I can get you a $10 rebate. Email me at jchawk@ my website (tr0n.com) that's a zero in tr0n.

Not a bad idea for all teams

[mlyle]

Lots of people are posting on how this is potentially a bad idea. Sure, it's not likely to be as mature as other compiler environments. There's all kinds of small shops where this could simplify build infrastructure, though. Maintaining different build servers for all the platform variation a company chooses to support can be costly to build, especially with the infrastructure to do revision control and fire off simultaneous builds and package things together. If a company just needs to produce command line tools or simple DLL's to accelerate code in a scripting language, this might be a good choice.

Probably the largest win is allowing developers to unit test application logic on their local Windows desktop, if they prefer that environment, before doing final unit test, integration test, and deployment on top of *nix/Linux.

Re:Surely a security risk

[vrmlguy]

Huh? I'm not sure I understand what you're saying here, so allow me to paraphrase:

Placing a .EXE file on a Linux server helps spread virii, because the Linux server won't check to see if the file is infected with a Windows-based virus. This is bad because if the file becomes infected, the infection will be missed.

I'm making the generous assumption that you aren't saying that the Linus system will create an infected executable. Even so, there seem to be some unwritten assumptions here.

First, you assume that there is an infected Windows system. Just about every commercial environment that I'm aware of runs some form of anti-virus software on every Windows-based server and desktop. This means that there is little chance of infection by a known virus. I will readily conceed that unknown infections, such as Slammer, can still be a problem, but that leads to your second assumption.

You seem to think that any Windows-based system with read-access to the file also has write-access to it. This runs counter to the best-practices adopted at most sites. A fundimental rule of security is to provide no more access than is needed to get the job done. File servers generally restrict the average user from modifying static resources. In this case, I would include anyone with a Windows-based system as an average user. Since they aren't running a developement environment, there is no need for them to write to the directories where the software is stored.

So, did I miss something, or did you post of subtle troll?

Re:Surely a security risk

[The Bungi]

The time when viruses like Pong and Natas infected binaries are fading fast. Instead we have worms that are far more effective because they can infect other machines as opposed to just other applications on the same box. Before, you were scewed. Today, the whole goddamn Internet is screwed. It's just a matter of scale and opportunity.

Or are you saying that Windows executables are somehow more infection prone than ELF or Mac binaries?

It pulls everything down the tubes

Now, now. That's just your inner zealot speaking.

We've had this for years

[Stiletto]

I've been using a MINGW32-based linux->win32 cross-development environment for years. The same concepts apply as for cross-compiling to different hardware architectures. This is definitely not new software. With properly written makefiles, you can build to target both Linux and Win32 platforms from the same source tree and build environment. Of course you must test on both platforms, but having a setup like this definitely makes it easier to build large projects for both Windows and Linux.

Re:Usually...

[grolim13]

No, you're misunderstanding how this works. Cross-compilers have been around for ages, this one just happens to have the advantage that it inherently portable (because it is based on GCC) and targets Windows (which is phenomonally popular).

Wine works by reimplementing a part of the Windows API. Mingw32 is a compiler which takes C/C++ programs and Windows libraries and generates Windows executables. Its C/C++ support is just about flawless as it uses GCC; it can link programs against native Windows libraries just like any Windows compiler would; and it produces ordinary Windows executables.

These Windows executables, however, won't run natively on the (Linux) host machine.

Note that this is also not an automated system for writing portable programs; Xmingwin won't compile anything that wouldn't compile on a normal Windows machine. But if you have code that is portable, you can save a lot of hassle by having just one machine to build binaries for several platforms.

They're just following the Geek Rule

[dark-nl]

Every cool project should have a FAQ entry explaining its name. If the name is too easy, or has an obvious pronunciation, then it can't be a cool project. Ideally, there should be long-standing flamewars about it (i.e. is it "vee-eye" or "veye"?).

Re:Surely a security risk

[Howie]

Do you mean: Q80520 - How Microsoft Ensures Virus-Free Software?

It's not compilation, but the CD-mastering. (this used to be in the MS KB, but it seems to have gone).

Re:Surely a security risk

[Twirlip of the Mists]

I'm on a crusade. I intend to post a comment like this one whenever I see anybody use "virii." Please don't interpret this comment as either endorsement of or disagreement with the parent post. Moderators: with your help, we can wipe out "virii" in our lifetime!

The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

Here's a good explanation from cdknow.com, quoted here in its entirety because the people who most need to read this won't click on a link.

The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

For the purists, in Latin, there is a rarely-used plural form:

virus, viri (neuter)

(Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

More plural-of-virus resources:

perl.com, the canonical and exhaustive source
The alt.comp.virus FAQ
Jonathan de Boyne Pollard's Frequently Given Answer
Merriam-Webster's "Word for the Wise," January 20, 2000.

Xmingwin vs. Visual-MinGW

[Lumpish Scholar]

Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.

On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here.)

There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.

Automated builds + a full-featured dev environment

[danlyke]

Beyond just automated builds, my big issue with VisualStudio is that it sucks boulders through capillary tubes if you ever have to change compilation options on more than one build target, or add a bunch of "only slightly different" items to a build. Besides the fact that it's often bloody impossible to figure out where it's setting a given compiler option.

And when I've used the VC command line tools and called up Microsoft to report bugs I've gotten laughter, at best. They simply won't support anything but the visual environment.

This gives a full-featured development environment using real production quality tools in an environment that won't be blowing chunks every time I try to do something remotely outlandish with the USB bus. I've no problem with having a Windows box beside my Linux box for running the app, I just want a stable, full-featured development environment. Linux cross-compiling onto a Samba mount is closer to that than Microsoft's been in many years.

Re:Canadian Cross-Compiler?

[The Lord of Chaos]

Canadian Cross is when you are building a cross compiler to be hosted on a different platform than you are building it on.

Example:
Using a Linux-x86 system to build a windows hosted powerPC compiler.

"Canadian" refers to there being three different platforms (parties*) involved: the target platform (powerPC), the hosting platform (windows), and the platform building the cross-compiler (Linux).

* There used to be three national political parties in Canada before those pesky Quebecois formed a national party.