I disagree: the mingw gcc versions I've used seemed to contain things most
I need: windows.h for example, and the necessary libraries. I haven't
needed
separate sets of headers and libraries. Otherwise I don't know what most of
the 12,000 files comprising mingw are for.
That would be because what you downloaded from mingw was not just the
compiler, but the compiler along with a set of libraries, headers and
runtimes!
Note - the original "mingw" project provides headers, etc., that come
from MSDN. They are thus as close to being Windows standard headers as
you can get - and that means they are as limited as Windows/MSDN's C
support, which is barely up to C90 standards. Mingw-w64 has new
headers, etc., to give modern C standards support, including much of C11
(AFAIUI). So if you want to use modern C on Windows, mingw-w64 (or
related projects, like TDM) is the way to go.
Again I disagree. Until about 2012 I maintained my own language and
compilers for use under Windows. Very little maintenance was necessary
(around 2000 for example I upgraded to full 32-bit code generation; a bit
late, but I'd already been using mixed 32-bit/16-bit code since the 80386
appeared). Object code generation and linking had been offloaded to NASM at
some time during the nineties.
If you want to keep up with the latest possibilities with the latest
versions of windows, you need to update the tools to match. Of course,
it is often fine to stick to a limited set of features and be compatible
with a wider range of versions - in which case you don't need to update
often.
That's really what I'm trying to avoid. I have enough trouble compiling my
own applications, and the largest one I have is only a dozen modules,
neither does it have any circular dependencies as you'd get when
compiling a
compiler with its own language (and what compiler version would be used to
compile it?). (I get enough of those sorts of headaches from working on my
own compilers which also compile themselves, and mine are tiny in
comparison.)
Using C was supposed to make life easier for me, not more difficult!
(I've just made a quick attempt to look at the gcc sources, but I got as
far
as the file gcc-4.7.2-1-mingw32-src.tar.lzma, with a extension I have no
idea of (is there someone paid to keep thinking up new ones) and a size of
80MB. I don't need to know any more! Clearly trying to build just a huge
project is completely out of the question as I wouldn't have a clue.
The file here is a collection of source files, bundled together in a
tarball, and compressed with lzma - a compression format that gives very
good compression and high speed decompression, at the cost of low speed
compression. 7zip and peazip should handle it fine.
Writing
my own compiler - even a C compiler - would be far easier, and I'm being
serious!)
Having built gcc for a variety of targets (mostly embedded processors)
and three different hosts (Win32/mingw, 32-bit Linux and 64-bit Linux),
I can tell you it is /vastly/ easier than writing a compiler. It's a
weird concept when you first do it, but these days it is not much more
than the old ".configure && make && make install" process. Getting the
right libraries and headers is often the biggest challenge, and
mingw-w64 gives you that.
However, I agree that it is nice /not/ to have to build gcc yourself -
and it saves a chicken-and-egg problem when you want a native compiler
(though you can build a win64 host / win64 target gcc using win32 mingw
gcc, or using gcc on Linux). With a bit of poking around, I found
pre-build binaries within the files area of mingw-w64 - as well as on a
number of different sites. But mingw-w64 would be much improved with a
link on the front page saying "this is the current best pre-build binary
package".
If you mean the wikipedia entries on mingw, that generates even more
confusion.
I meant the mingw-w64 wiki.
I think if gcc didn't have such a good optimiser (and was only so
ubiquitous), I would long ago have given up on it.
gcc - in any form - does not fit in well with the "windows way". Linux
developers are typically happy with command-line compilers, Makefiles,
etc., but Windows developers often expect point-and-click interfaces,
and wizards and dialogs for compiler setup. Tools like Code Blocks are
often a better choice for Windows than bare-bones gcc, as they come with
an IDE, debugger, libraries, etc., as well as the compiler itself.
Currently, Code Blocks only comes with 32-bit gcc for Windows (AFAIK),
though it supports 64-bit if you have it installed.
Of course, the real question is if you /need/ 64-bit gcc for Windows.
It will not be significantly faster for most code, unless your code
makes heavy use of 64-bit maths - on "typical" code the extra speed
comes from the additional registers in 64-bit mode, and is offset by the
slowdown of 64-bit pointers. (Of course, if your code needs more than 3
GB memory, you want 64-bit code.)
