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

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 ?

[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 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 )

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

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

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

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.