Re: [patch #6448] [MSVC 7/7] Add MSVC Support

[Peter Rosin]

Markus Duft skrev:
> > Markus Duft skrev:

> > > > > > >            The winnt was just the best that came to our ming,
> > since
> > > > > > the
> > > > > > > result is plain win32 binaries.
> > > > "winnt" is not the only kind of output from MSVC. So, why is winnt
> > > > better than win9x/winxp/win2k3 or whatever? And other tools also
> > > > target winnt. To sum it up, I think winnt is both too narrow and
> > > > too broad to be used as $host. Why not just parity?
> > > I don't support the 9x series of windows, and everything else is NT-
> > kernel
> > > based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2,
> > Vista
> > > and 2008 - that's what I intend.
> > Ok, but MinGW is also winnt. (If you stretch it a bit, Cygwin is also
> > winnt
> > for that matter, but that's a different libc.)
> >
> > > > If you want to have a common name, mingw is it, that's what's used
> > > > to denote the win32 environment w/o compatibility layers. If you
> > > > want to go your own way, winnt is too generic.
> > > IMHO mingw produces code that is very different from what MSVC
> > produces -
> > > not only performance wise (in some cases).
> > I don't think that matters when it comes to the $host triplet, you can
> > link code from MinGW with code from MSVC. Same os, same libc.
>
> Not necessarily same libc. Same kernel only. As you say below, mingw uses
> msvcrt.dll, which is the windows _internal only_ libc (MSDN: "The msvcrt.dll
> is now a "known DLL," meaning that it is a system component owned and built
> by Windows. It is intended for future use only by system-level
> components."). this means, that not a single windows "default" user can link
> against it. I guess mingw provides an import library for it, or ld can
> handle the dll directly without import lib. However it's in no way a setup
> you can get without mingw that easy (although - of course - msvcrt.dll may
> be loaded and used through LoadLibrary, even if another msvc??.dll is linked
> in).
>
> This means, that mingw is _not_ what the windows compilers/linkers will
> produce by default - I found quite big differences from msvcrt.dll and
> msvc80.dll for example. It's nothing else but _compatible_ with winnt.

Of course you'll shoot yourself in the foot if you're using two libc
in the same bin without taking *great* care. This also applies to the
heap manager below...

> Phew.. getting headaches now too (again...) :)
>
> > > Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this
> > > describes (in the same form as on linux) which platform I'm on.
> > Parity as
> > > platform would be a little bit misleading I guess, since I want
> > everyone to
> > > see on the first look that those binaries are native windows, and
> > nothing
> > > else.
> > MinGW binaries are also native Windows binaries, and nothing else. I
> > agree
> > that -parity as "-os" is bad, but since the only reason for you to add
> > a
> > new -os is to make it simple for you (i.e. easy to test in configure
> > and
> > libtool, no cross compiles when using interix as $build etc), I think
> > -parity is the best fit.
>
> I don't agree here. I think winnt ist the best match, since (opposed to
> mingw) I really use all the libraries and such exactly the same as the
> native compiler/linker...

You *are* using the native compiler/linker :-)
Or maybe not /the native/, but the most popular compiler/linker provided
by the vendor...

> > However, i686-pc-mingw32 is perhaps not correct for Microsoft compilers
> > other than MSVC 6, since they use a different libc. It might also be
> > incorrect for MSVC 6 w/o the -MD option since then you are also using a
> > different libc than MinGW (i.e. msvcrt.dll).
>
> Ok, maybe correct for MSVC6, but come one... :) this is stone-age. From
> todays POV it's no more than compatible, and even this is questionable,
> because mixing heap managers can be dangerous. What if a mingw dll allocates
> memory using msvcrt.dll, passes the pointer to an executable built with
> native linker, and this free's using msvc80.dll - or the other way round. I
> had such problems when I started out with parity. Believe me, they are no
> fun to hunt down ;)
>
> Cheers, Markus
>
> > I'm getting a headache...

I've been reading a bit in the MinGW list archive...

Apparently Microsoft has added newer stuff to the "system" msvcrt.dll
as provided by the WinXP (and later) systems, so that it in fact is
looking very much like msvcr71.dll (i.e. MSVC .Net, was that 2003?).
Or was that msvcr70.dll? Oh well, the exact details doesn't matter
here. That doesn't mean that you can mix this new msvcrt.dll with an
actuall msvcr71.dll in the same bin though, it's just a hint that
msvcrt.dll isn't tied to MSVC 6 (i.e. the stone age).

If I got it right, you can enable the new functions by using something
like "#define __MSVC_VERSION 710" prior to including the system
includes when using MinGW. But then you'll get a binary that will not
run on Win2k and earlier since msvcrt.dll on those systems don't have
the needed functions.

Also, MinGW apparently has import libraries like libmsvcr71.a to
actually bring in the newer versions of the MS runtime, if that's
really what you want to do.

So, it's not set in stone that msvcrt.dll is MSVC 6, and MinGW has
ways to use a newer libc.

My point is that -mingw32 as -os for MSVC is not so bad after all,
and that there's no real need for anything new (other than the
convenience it offers, of course, i.e. no cross compiles etc).

But yeah, it will perhaps be confusing to have $host match
*-mingw32, when the MinGW toolchain is not involved in any way. The
same is true for my work, which only require MSYS, not MinGW.

Cheers,
Peter