MinGW and Python

[sturlamolden]

Re: MinGW and Python


Martin v. Löwis wrote:

[color=blue][color=green]
> > Nonetheless, Cygwin applications are not generally considered native
> > Win32 applications because of the dependency on CYGWIN1.DLL and the
> > related environment.[/color][/color]
[color=blue]
> - Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
> - A cygwin application does *not* require the Cygwin environment.[/color]

Cygwin executables are native windows ".exe files" just like MinGW
executables. They are built by the same compiler, a port of GCC to 32
bit Windows originally written by Mumit Khan. MinGW and Cygwin apps run
at the same speed. However, the CYGWIN1.dll is bloated and an has
unwanted overhead for many system calls. But as such, CYGWIN1.dll is
nothing more than a CRT with extended "Linux API" support, including
posix and xlib.

The problem is actually *licensing issues* related to CYGWIN1.DLL. It
cannot always be linked. CYGWIN1.DLL can only be used for Open Source
development.

"In accordance with section 10 of the GPL, Red Hat permits programs
whose sources are distributed under a license that complies with the
Open Source definition to be linked with libcygwin.a/cygwin1.dll
without libcygwin.a/cygwin1.dll itself causing the resulting program to
be covered by the GNU GPL."

Thus, if you have a commercial closed source application, you need to
use MinGW; that is, you cannot link with libcygwin.a/cygwin1.dll.

I am not sure if Cygwin has link libraries for the Win32 API. Is there
e.g. a libuser32.a for linking with user32.dll? But MinGW has that.

[Gerhard Häring]

Re: MinGW and Python

sturlamolden wrote:[color=blue]
> [...] The problem is actually *licensing issues* related to CYGWIN1.DLL. It
> cannot always be linked. CYGWIN1.DLL can only be used for Open Source
> development. [...][/color]

Of course Redhat offers an alternative license that does not have the
GPL restrictions: http://www.redhat.com/software/cygwin/

Like other annoying companies, they don't tell any rates at their
website and make you call them up if you're interested. Cowards.

-- Gerhard

[Ross Ridge]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> Nonetheless, Cygwin applications are not generally considered native
> Win32 applications because of the dependency on CYGWIN1.DLL and the
> related environment. While what you're saying a strictly true, the
> term "native Win32" is used to make a distinction between a port of a
> program that doesn't use or require the Cygwin environment from one
> that does.[/color]

Martin v. Löwis wrote:[color=blue]
> I know it is common to take that view, but I believe it is wrong, no
> matter how you look at it[/color]

Regardless, that's what "native Win32 application" means in this
context, and makes a useful and well understood distinction between
ports.

Ross Ridge

[Ross Ridge]

Re: MinGW and Python


sturlamolden wrote:[color=blue]
> Cygwin executables are native windows ".exe files" just like MinGW
> executables. They are built by the same compiler, a port of GCC to 32
> bit Windows originally written by Mumit Khan.[/color]

No, Cygwin executables are built using a different port of GCC, the
Cygwin port of GCC. The two ports are very similar, but the Cygwin
port is a Cygwin application. That means, for example, it uses Cygwin
pathnames instead of the standard Win32 pathnames that MinGW uses.

Ross Ridge

[Ross Ridge]

Re: MinGW and Python


sturlamolden wrote:[color=blue]
> That is correct. And it is the reson why the MinGW team is working on
> removing the dependency on this CRT.[/color]

No one is working on removing MinGW's depency on MSVCRT.DLL.

Ross Ridge

[sturlamolden]

Re: MinGW and Python

I seem to vaguely remember that MinGW was going to get its own CRT. And
unless it does, MinGW is a defect compiler for legal resons. It cannot
be legally used.

Microsoft has designated the CRT that MinGW links a system file,
against which no application should link. Insted they have asked that a
CRT is distributed together with any program that depends on it. If you
program needs msvcrt.dll, you should redistribute msvcrt.dll and place
a copy in your program's install directory.

When you compile with MinGW, you are not allowed to to that. Microsof's
CRTs can only be distributed with programs that are compiled with
Microsoft's compilers. Even if you hold a license for Visual Studio,
you are still not permitted to redistribute the CRT if you compiled
your program with MinGW.

http://support.microsoft.com/default.aspx?scid=kb;en-us;326922

[Ross Ridge]

Re: MinGW and Python

sturlamolden wrote:[color=blue]
> I seem to vaguely remember that MinGW was going to get its own CRT. And
> unless it does, MinGW is a defect compiler for legal resons. It cannot
> be legally used.[/color]

That is simply not true.
[color=blue]
> Microsoft has designated the CRT that MinGW links a system file,
> against which no application should link.[/color]

While they may not recommend it anymore, Microsoft no more prohibits
applications linking against MSVCRT.DLL than KERNEL32.DLL.
[color=blue]
> Insted they have asked that a CRT is distributed together
> with any program that depends on it. If you program needs
> msvcrt.dll, you should redistribute msvcrt.dll and place
> a copy in your program's install directory.[/color]

No, this is not how Microsoft recommends installing MSVCRT.DLL.
Because it is a system DLL it should be, after doing appropriate
version checking, installed in the system directory. See:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/redistribvc6.asp

[color=blue]
> When you compile with MinGW, you are not allowed to to that.[/color]

That's why MinGW applications don't include MSVCRT.DLL in their
distributions. There's no reason to do so, since it's installed
already on virtually all Windows systems. Even on systems like Windows
95 where MSVCRT.DLL wasn't originally a system DLL, it's usually
already been installed as a consequence of installing some other
application.
[color=blue]
> http://support.microsoft.com/default...b;en-us;326922[/color]

This article describes how MSVCR70.DLL, MSVCR71.DLL and MSVCR80.DLL
should be installed. Since these DLLs, as the article points out,
aren't system files they should differently than MSVCRT.DLL.

Ross Ridge