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

[Markus Duft]

> 
> Markus Duft skrev:
> >> I Forgot to answer some things...
> >>
> > <snip>
> >> My patches use the same host/build as MinGW when using MSYS, on the
> >> grounds that the output from the MinGW tools and MSVC are compatible
> >> (so same $host) and that MSYS is MSYS (same $build). That's also
> >> how cccl has it (at least I think so...)
> >
> > Hmm.. but your compiler is a different one, and thus behaves
> different than
> > mingw. I don't think it's a good idea to take the mingw triplet for
> > something other than mingw. Who knows - if there is something out
> there that
> > is capable of patching mingw binaries in some form, relying on code
> that
> > only gcc creates (I know that sample is kind of unrealistic, but hey
> - I
> > patch MSVC binary code ;)) - it would fail with you binaries.
> 
> Then I think you are reading too much into the host triplet, it denotes
> hardware-vendor-os (and possibly -libc appended). There is no info in
> there that helps you determine the compiler.

Hm, yeah, right :)

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

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

> 
> 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...
> 
> Cheers,
> Peter