<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 May 2015 at 10:45, Manu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 31 May 2015 at 17:59, Shachar Shemesh via Digitalmars-d<br>
<div><div class="h5"><<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
> On 31/05/15 02:08, Manu via Digitalmars-d wrote:<br>
>><br>
>> On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d<br>
>> <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
>>><br>
>>> On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> When he says Windows, he means MSVC, gcc backend will never support<br>
>>>> interfacing that ABI (at least I see no motivation as of writing).<br>
>>>><br>
>>> I thought that's what MINGW was. A gcc backend that interfaces with the<br>
>>> Windows ABI. Isn't it?<br>
>><br>
>><br>
>> If your program is isolated, MinGW is fine. Great even!<br>
>> But the Windows ecosystem is built around Microsoft's COFF formatted<br>
>> libraries (as produced by Visual Studio), and most Windows libs that I<br>
>> find myself working with are closed-source, or distributed as<br>
>> pre-built binaries.<br>
><br>
> Again, sorry for my ignorance. I just always assumed that the main<br>
> difference between mingw and cygwin is precisely that: that mingw<br>
> executables are PE formatted, and can import PE DLLs (such as the Win32 DLLs<br>
> themselves).<br>
><br>
> If that is not the case, what is the mingw format? How does it allow you to<br>
> link in the Win32 DLLs if it does not support COFF?<br>
><br>
> Shachar<br>
<br>
</div></div>I did once play with a coff mingw build, but I think the key issue I<br>
had there was the C runtime. GCC built code seems to produce intrinsic<br>
calls to glibc, and it is incompatible with MSVCRT.<br>
I'm pretty certain that GCC can't emit code to match the Win32<br>
exception model, and there's still the debuginfo data to worry about<br>
too.<br>
</blockquote></div><br></div><div class="gmail_extra">Pretty much correct as far as I understand it.<br><br>- GCC uses DWARF to embed debug information into the program, rather that store it in a separate PDB.<br></div><div class="gmail_extra">- GCC uses SJLJ exceptions in C++ that work to it's own libunwind model.<br></div><div class="gmail_extra">- GCC uses Itanium C++ mangling, so mixed MSVC/G++ is a no-go.<br></div><div class="gmail_extra">- GCC uses cdecl as the default calling convention (need to double check this is correct though).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">That said, GCC does produce a COFF binary that is understood by the Windows platform (otherwise you wouldn't be able to run programs).  But interacting with Windows libraries is restricted to the lowest API, that being anything that was marked with stdcall, fastcall or cdecl.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">MinGW is an entriely isolated runtime environment that fills the missing/incompatible gaps between Windows and GNU/Posix runtime to allows GCC built programs to run.<br><br></div></div>