from Dave Thomas on 2001-10-31 at 11:26:25:
> "Curt Hibbs" <curt / hibbs.com> writes:
> 
> > What would MinGW buy us over straight MSVC? Since MinGW ultimately uses the
> > MSVC runtime, doesn't this just mean an extrat layer of overhead? Plus we
> > would be limited to whatever api support MinGW happenned to pass through.
> 
> Well - the compiler is free... :)

Yep. And there shouldn't be any overhead, really.

> OK - say we used MSVC to build it. Would folks with access only to
> MinGW be able to compile their own extensions?

A bunch of clever Python folks have in fact figured out how to do just this.
I'm not too knowledgeable about Windows linking, but from what I understand,
it's just a matter of converting the .LIB files into .A files that MinGW's
linker can understand. The actual code is still in a .DLL. I guess the .A
files are stubs or something.

http://starship.python.net/crew/kernr/mingw32/Notes.html

If somebody knows something about Windows linking and can pull my foot from my
mouth, that'd be great. In any case, it *should* work.

> And is it true that there's no difference in runtime functionality
> between the MSVC and MinGW versions? I have to admit I thought that
> MinGW added something to the mix, but I know nothing about Windows.

It *appears* to be the case. Following is a link of a bunch of standard Unix
shell utils ported to Windows, including Zsh, cat, etc. It's not quite as
complete as Cygwin, but it's pretty cool (no "clear", though! That's SO
annoying!)

http://www.wzw.tu-muenchen.de/~syring/win32/UnxUtils.html
or
http://unxutils.sourceforge.net/

In any case, I can extract JUST the sh.exe and run it without anything else
installed. So I assume MinGW produces dependency-free executables.

Yay!

Of course, if we go MSVC, we can still just distribute binary extensions to
everybody, and ignore the entire hassle of getting the two linkers to play
nice with each other... doesn't SourceForge have a Windows machine in their
compile farm?

Eli Green