Re: MinGW, GCC Vista,

[Mark Mitchell <mark at codesourcery dot com>]

Ross Ridge wrote:
> Mark Mitchell writes:
>> In my opinion, this is a GCC bug: there's no such thing as X_OK on
>> Windows (it's not in the Microsoft headers, or documented by Microsoft
>> as part of the API), and so GCC shouldn't be using it.
> 
> Strictly speaking, access() (or _access()) isn't a documented part of
> any Windows ABI.  It's only documented as part of the C Runtime Library
> for Visual C++, a different product.  This is an important distinction,
> while MinGW should support Windows APIs as documented by Microsoft,
> it's not ment to be compatable with Visual C++.  MinGW does use the same
> runtime DLL as used by Visual C++ 6.0, but this is essentially just an
> implementation detail, not ment as a compatibility goal.  There are a
> few of ways MinGW's runtime is incompatable with Visual C++ 6.0.

OK.  Unfortunately, I guess that's not what I hoped MinGW is. :-)

(Again, I'm not trying to be critical: I like MinGW, and it's not my
place to say what it ought to be.  I'm just giving feedback as a user.)

To me, the fact that it uses the MSVCRT runtime library is very
important, and the Visual C++ interoperability is important.  In light
of Brian's comment that:

> I may have overstated the nature of the change, as it still requires
> #defining a symbol to get a change in behavior:

it may be that MinGW is more like what I hope: unless I define the
special symbol, MinGW doesn't interpose anything between me and the
runtime library -- except that it defines X_OK, which, as you say, may
have been a mistake, but is certainly water under the bridge!

As a user, I certainly have no objection to MinGW offering more than
Visual Studio, in terms of things like libmingwex.  But, I would like to
perserve the ability to use MSVCRT in all its warty glory.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713