On 06/12/12 12:53, Earnie Boyd wrote: > On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote: >> On 06/12/12 10:51, Jacek Caban wrote: >>> On 06/12/12 07:06, Yaakov (Cygwin/X) wrote: >>>> On 2012-06-04 04:04, Jacek Caban wrote: >>>>> Where? I don't see any. There is one change to propkeydef.h, but and I >>>>> believe incorrect. Generally, this patch makes REFIID and similar >>>>> typedefs depend on CINTERFACE, which is not present in MSVC. >>>> According to these, it is: >>>> >>>> http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx > Isn't this specific to COM and an IDL compiler? > > <quote> > Remarks > > By default, only COM-interfaces that are base classes of the coclass > are added in the IDL coclass. implements lets you force other > interfaces to be IDL coclass members. > </quote>
There is some misunderstanding here, perhaps I wasn't clear enough, sorry. Let me explain it in more details. IDL interfaces (and classes) have two forms. One is class-based for C++ and another is struct-based for C. Those are binary compatible as the C version contains C++-compatible vtbls. It's possible to use C form of interfaces from C++. That's what CINTERFACE does - it causes headers to use C variant of interfaces even when compiled in C++. That's all fine AFAIK in both mingw-w64 and mingw.org and the proposed patch doesn't touch that part. What the patch touches is REFIID type. It's a tricky type. That's a macro invented to allow using C++ references and being still binary compatible with C. REFIID is defined as |const IID&| for C++ and |const IID*| for C. Since C++ references are just pointers under the hood, it all works together just fine after compilation. My point is that REFIID's form *should not* depend on CINTERFACE. It's language-specific and that's the way MS designed it. Yet mingw.org has it depended on CINTERFACE and cygwin followed that bug. I do not think we want to propagate this bug even further to mingw-w64. Still, we need a solution. I can see two solutions: - cygwin fixes it on their side Sadly, that will require some preprocessor tricks detecting which variant of mingw is used. - mingw-w64 would introduce bug-compatibility macro Say we'd define REFIID to C form in C++ if __CRT_C_REFS is defined. Cygwin could just define this macron on command line and not change the code. The difference between this solution and proposed patch is that app would have to explicitly request this behaviour, so MSVC-compatible apps would be still fine. >>>> http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47 >>>> http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531 >>>> http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f > I didn't bother looking at social.msdn because it might influence me > with code I don't want to see. > >>> If there is any source of informations more misleading than MSDN, that's >>> MSDN forums:) Why do you need that change? That's not what mingw.org >>> does nor MSVC, so why is it needed for your code? Can you please point >>> me to the code that doesn't compile without this change? >> I double checked and mingw.org apparently has this bug. Anyway, that's >> still a bug on their side that I don't think we want to duplicate. > We (mingw.org) doesn't support COM and never has. A GCC supported IDL > compiler would be great but whose going to pick up the support on > that? Well, mingw-w64 has already limited support for widl (Wine IDL compiler) and I slowly improve it as a background project. It's sad that the way current relationship between project look like, mingw.org would have to duplicate those efforts. (Disclaimer: my primary project it Wine and I'm mostly out of the loop about what's going on with mingw.org/mingw-w64, so sorry if my impression is wrong and don't take it as a voice of mingw-w64 project). I have to ask about this: I've heard that mingw.org, after RedHat's legal approval for mingw-w64, has no objections to use mingw-w64's source. Why not to go one step further and simple use mingw-w64 *instead* of w32api in mingw.org? That way even widl would just work as good on mingw.org as it does on mingw-w64. That's just one of many possible benefits. No efforts duplication, mingw.org wins a lot of improvements, mingw-w64 wins more contributors. Has this been discussed? Cheers, Jacek ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
