"Benoit Cerrina" <benoit.cerrina / writeme.com> wrote in message
news:9pg69o$d2j$1 / wanadoo.fr...

> wrong here, for multiple reasons the first one being the price of VC, the
> second
> being the availability of windows there are many reasons to do it.

But the difficulty of obtaining gcc on Windows makes it a lot easier to just
dualboot Linux where you can get the CD's in the local bookstore or wrapped
with a magazine - or as easy to download CD images.

> uses for windows including (but not exclusively) games, having the
computer

Sure - but that is not development. I'm not saying I'd abandon Windows
altogether.

> At the basic level, MinGW is a set of include files and import libraries
> that allow a console-mode program to use Microsoft's standard C runtime

I don't actually mind MinGW (had a nice Tex environment based on Ming as I
recall), I just want something that supports standard linker format.
I have a little difficulty in seeing the purpose when you can use the
platform SDK (preferring that over third party everything else being equal).
To me the MingW purpose it to support Unix/Posix style api's for code
written for Unix, and to allow gcc to work with the Windows OS. If gcc is to
be supported and the platform SDK doesn't work with gcc, then MinGW has a
justification. What I'm not sure about is a) can gcc work with platform SDK,
b) can gcc compile in a compatible linker format.

The problem really is the linker format. That concerns me a lot. It makes
Ruby useless for many purposes.
The COM support in Ruby is not sufficient for all purposes. You can get
around that by wrapping it in an extension module IF the linker format
works. You can't integrate with .NET whatsoever in Ruby, but again you can
get around that by writing an extension module IF the linker format is
right. You may to use some third-party regular expression library - but it
has a library module that needs to be statically or dynamically linked. That
library doesn't compile with gcc if source is provided - or if source isn't
provided it is in a gcc imcompatible format.

This means that you can not use Ruby on windows for any serious software
development, unless you opt to compile the entire Ruby core into the
application with all the problems of not having it supporting the compiler
proper in the first place - meaning that it will be worthwile for a limited
number of applications.

> like it is said here although mingw is a set of tools it doesn't create a
> runtime dependency,
> just the build time one on the .h and .lib files.  So on the opposite to
> cygwin this is not so
> much as a tool to port unix apps but a tool to write win32app

That is actually nice - and better than MSVC which has it's own set of
problems with its runtime dll. But at least we have learned to live with it.
But if it doesn't support the prober linker format, it is a problem.

Say we support MinGW and gcc with incompatible linker format. This limits
the number of developers that actually develops extensions for Ruby under
windows. On the other it may support a large number of extensions developed
for Unix. But since the majority of these extensions are not precompiled for
the MinGW platform, they will effectively be useless to the majority of Ruby
users on Windows.
Requiring VC support will also limit the number of developers - by I reckon
the number will be larger than in the gcc case. And I believe it will help
promote Ruby better.

But what about Watcom - didn't they go free open source recently? Watcom
should be able to support standard linker format and platform SDK.

http://watcom.org/
quote
"Open Watcom is a joint effort between SciTech Software, Sybase and a
select team of developers, which will bring the Sybase Watcom C/C++ and
Fortran compiler products to the Open Source community."


Mikkel