Eric Christopher <echristo at gmail.com> writes:> In my opinion none of these are irrelevant. Mingw and cygwin are separate > ABIs that deal with some C compatibility (problems mentioned in this thread > are important here too) and give you the ability to work with low level C > libraries on windows, but if you want true compatibility with the full > platform > those ABIs are insufficient.What do you mean by "the full platform"? Every propietary extension that MS came with along all these years? (From structured exceptions to whatever Windows RT requires?) MinGW is very well capable of using the Win32 API. There is partial or non-existent support for extensions such as COM, but those are not part of the "ABI", for sure.> If you think these are irrelevant points then you need to state why > and should back it up with less dismissive language.Sorry, but this goes the other way. If you need a lesson in history please start by investigating what "Borland" was, for instance. As already mentioned, for a long time MSVC was considered an inferior option and not required in any way for developing on Windows (not even for device drivers!) Then Borland and the other vendors were displaced by MSVC, but not because it was "the system compiler", nor even because it was technically better overall, severely lacking in C++ compliance, for instance. It gained market share because several reasons, among them because the other vendors had serious management problems and because MS marketers convinced the suits that for doing "serious" Windows development you need the tool made by MS itself. It is no surprise, but irritating nevertheless, that nowadays the fallacy is stablished as a truth. Sorry if I sound dismissive but it's quite irritating to see how authoritativeness is attributed to something that doesn't deserve it *to* *the* *detriment* *of* *our* *own* *project*.
On Thu, Mar 28, 2013 at 3:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> Eric Christopher <echristo at gmail.com> writes: > >> In my opinion none of these are irrelevant. Mingw and cygwin are separate >> ABIs that deal with some C compatibility (problems mentioned in this thread >> are important here too) and give you the ability to work with low level C >> libraries on windows, but if you want true compatibility with the full >> platform >> those ABIs are insufficient. > > What do you mean by "the full platform"? Every propietary extension that > MS came with along all these years? (From structured exceptions to > whatever Windows RT requires?) > > MinGW is very well capable of using the Win32 API. There is partial or > non-existent support for extensions such as COM, but those are not part > of the "ABI", for sure.COM is not part of the Windows ABI? That's news to me, given that there are hundreds (thousands?) of powerful APIs exposed *only* via COM, which are documented and supported by Microsoft. This may or may not be outside of the realm of the current discussion, but I would hate to see all the functionality exposed via COM to be tossed aside with the mistaken belief it's not part of the Windows ecosystem we need to support. ~Aaron
On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> What do you mean by "the full platform"? Every propietary extension that > MS came with along all these years? (From structured exceptions to > whatever Windows RT requires?) > > MinGW is very well capable of using the Win32 API. There is partial or > non-existent support for extensions such as COM, but those are not part > of the "ABI", for sure. >Mingw interoperates with the Win32 API, yes, but it's able to without having full C ABI compatibility with MSVC. For one, most of the Win32 API has its own "stdcall" calling convention, which is different from either Mingw's or MSVC's "cdecl" ABIs. The Win32 API also avoids passing or returning structs or other non-primitives by value, because C and Pascal compilers back in the early 90s didn't behave consistently outside of a small subset of C functionality, and MSVC and Mingw still don't.> Irrelevant too, since those "MSVC binaries" (whatever that means) are > usable by the other compilers. >Not unless the library authors take pains to only export APIs that conform to the subset of MSVC's and Mingw's ABIs that are compatible. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/ff57b631/attachment.html>
On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:> Eric Christopher <echristo at gmail.com> writes: > > > In my opinion none of these are irrelevant. Mingw and cygwin are separate > > ABIs that deal with some C compatibility (problems mentioned in this > thread > > are important here too) and give you the ability to work with low level C > > libraries on windows, but if you want true compatibility with the full > > platform > > those ABIs are insufficient. > > What do you mean by "the full platform"? Every propietary extension that > MS came with along all these years? (From structured exceptions to > whatever Windows RT requires?) > > MinGW is very well capable of using the Win32 API. There is partial or > non-existent support for extensions such as COM, but those are not part > of the "ABI", for sure. > >I don't care overly much about COM, but I do care about the C++ abi and using C++ libraries on the system and interacting with those libraries via clang.> > If you think these are irrelevant points then you need to state why > > and should back it up with less dismissive language. > > Sorry, but this goes the other way. If you need a lesson in historyplease start by investigating what "Borland" was, for instance. As>I'm quite familiar with Borland, thank you.> already mentioned, for a long time MSVC was considered an inferior > option and not required in any way for developing on Windows (not even > for device drivers!) Then Borland and the other vendors were displaced > by MSVC, but not because it was "the system compiler", nor even because > it was technically better overall, severely lacking in C++ compliance, > for instance. It gained market share because several reasons, among them > because the other vendors had serious management problems and because MS > marketers convinced the suits that for doing "serious" Windows > development you need the tool made by MS itself. It is no surprise, but > irritating nevertheless, that nowadays the fallacy is stablished as a > truth. >Honestly it doesn't much matter about history in this case. I understand the frustration coming from your perspective, but these days running binaries on windows involves interoperating with things compiled by MSVC. To have a toolchain that works with as many libraries on the system as possible requires interoperability with the tools used to compile those libraries. In this case it is MSVC and their ABI.> Sorry if I sound dismissive but it's quite irritating to see how > authoritativeness is attributed to something that doesn't deserve it > *to* *the* *detriment* *of* *our* *own* *project*. >How can having an MSVC compatible compiler be to the detriment of clang and llvm? No one is trying to break mingw here, merely add support for something else. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/1cc86c78/attachment.html>
Joe Groff <arcata at gmail.com> writes:> On Thu, Mar 28, 2013 at 12:19 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> What do you mean by "the full platform"? Every propietary extension that >> MS came with along all these years? (From structured exceptions to >> whatever Windows RT requires?) >> >> MinGW is very well capable of using the Win32 API. There is partial or >> non-existent support for extensions such as COM, but those are not part >> of the "ABI", for sure. >> > > Mingw interoperates with the Win32 API, yes, but it's able to without > having full C ABI compatibility with MSVC. For one, most of the Win32 API > has its own "stdcall" calling convention, which is different from either > Mingw's or MSVC's "cdecl" ABIs. The Win32 API also avoids passing or > returning structs or other non-primitives by value, because C and Pascal > compilers back in the early 90s didn't behave consistently outside of a > small subset of C functionality, and MSVC and Mingw still don't.If MinGW lacks some parts of the Windows platform ABI, that is considered something to fix by the MinGW community. Another question is the real possibiities of fixing the discrepancy, given the available manpower, expertise and perceived urgency by the MinGW community. Put it another way: I doubt you will encounter a MinGW maintainer that could say that implementing full C compatibility with MSVC is not something they would like to achieve. In that sense, the point is not about making a MinGW ABI-compatible Clang, but a MinGW bug-compatible Clang.>> Irrelevant too, since those "MSVC binaries" (whatever that means) are >> usable by the other compilers. >> > > Not unless the library authors take pains to only export APIs that conform > to the subset of MSVC's and Mingw's ABIs that are compatible.In my experience, the differences are not so widely used to be glaring. I'm writing this message on a editor which was compiled with MSVC but uses about a dozen C libraries compiled with MinGW. In any case, I concede that a difference is a difference and it is a good thing that Clang knows about it. I have no objections about that. What I object about is to declaring some vendor's compiler as a privileged component, all others (including Clang) being second class.
> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for somethingJust to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so Windows + Mingw + Cygwin - isTargetWin64() is is basically 64-bit version of isTargetWin32(), but strictly speaking is slightly different This naming while being the historical artifact is extremely confusing. For me it seems the best solution will be something like this: - isTargetMingw() - with obvious meaning - isTargetMSVC() - with obvious meaning - isTargetWindows() which will include all the flavours (so only OS will matter here) - isTargetWindows() can be combined with existing 32/64 bit checks This way we'll end with something being non-ambiguos. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Aaron Ballman <aaron at aaronballman.com> writes:>> MinGW is very well capable of using the Win32 API. There is partial or >> non-existent support for extensions such as COM, but those are not part >> of the "ABI", for sure. > > COM is not part of the Windows ABI? That's news to me, given that > there are hundreds (thousands?) of powerful APIs exposed *only* via > COM, which are documented and supported by Microsoft. This may or may > not be outside of the realm of the current discussion, but I would > hate to see all the functionality exposed via COM to be tossed aside > with the mistaken belief it's not part of the Windows ecosystem we > need to support.COM is a language extension. You could say the same thing about .Net. OTOH, I doubt there is any kind of project that you can't do on Windows because you can't use COM (apart from interfacing with certain applications, distributed with the OS or not.)