[Python-Dev] Status of C compilers for Python on Windows

[Steve Dower]

Ray Donnelly wrote:
> On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> Ray Donnelly wrote:
>>> Also, where are the publicly accessible specifications and other technical
>>> descriptions that MinGW-w64 would need to implement strong binary
>>> compatibility with MSVC? As a random example, those for C++ name
>>> mangling and the PDB file format would be very helpful.
>>
>> C++ name mangling is always an implementation detail and it changes from
>> version to version. Luckily, CPython is entirely in C, so that doesn't matter.
>> PDBs are another red herring - you can build a loadable PE file without PDBs.
>
> Of course C++ can be called from C and that is done in some CPython
> extensions, so it's not a red herring. If we want to talk about strong
> binary compatibility I'd expect the aim would be to intermix freely
> between compilers. We'd like people to be able to debug MinGW-w64 code
> using CDB in Visual Studio if they want to, and on the flipside, to
> have GDB able to read PDB files built by MSVC (actually there's a long
> standing problem when debugging MinGW-w64 code in GDB that stack
> unwinding out of MS built dlls is flaky at best) - so again this is
> not really a red herring. I'm also led to believe that MSVC has a very
> good optimizer so if some project wanted to build certain libraries or
> objects with that for their performance critical paths then I can see
> that as being useful to those projects and their users'.

Binary compatibility that strong is very unlikely to ever happen, and certainly
not with versions of compilers that are being actively developed. It would be far
too restrictive to both development teams.

The weaker compatibility of C DLL boundaries is far more achievable - we already
mostly have it, as evidenced by some Python packages working correctly with
mismatched compilers. Soon the CRT will be isolated along the same boundaries,
which is short-term pain for long-term gain.

>>
>> The full source code for the MSVCRT is available with any version of Visual
>> Studio (including the free editions, last time I checked), so feel free to
check
>> whatever you need to ensure compatibility. I've suggested to the VC team that
>> they could get in touch with the MinGW projects and offer to help them improve
>> compatibility with MSVC, but unfortunately I don't think anyone will take me up
>> on that. I'm happy to research what I can to answer specific questions, but
>> there's very little that isn't already publicly available other than direct
>> access to the devs.
>
> Under what license? We'd rather have open specifications that
> copyrighted, strictly licensed code that we can't look at for various
> tainting reasons.

As far as I can tell, it's covered by the Visual Studio license, which basically
means you can't redistribute the files (I'm not a lawyer, but I've spent plenty of
time talking about licenses to lawyers... not sure how much that counts for :) ).

Most closed-source Microsoft code is not released under open-source-like licenses,
so there's no concept of derivative work, attribution or reciprocation, and that's
what appears to cover the CRT sources. "Using" the sources probably counts as using
VS, which may trigger some non-commercial clauses if you've got the free version
(but probably not the 30 day trial of the paid version... licenses are weird), but
reading them is well within the granted permissions.

The intention of including the sources is to help people with debugging... I don't
think it's even possible to rebuild the CRT from them. I do understand the taint
concerns though - until recently, I was operating under rules that made even some
documentation "unsafe"...

>> Cheers,
>> Steve
>>
>>>> Paul