MinGW and Python

["Martin v. Löwis"]

Ross Ridge wrote:
> 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.

I know it is common to take that view, but I believe it is wrong, no
matter how you look at it:

- Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
- A cygwin application does *not* require the Cygwin environment.
  You don't need to invoke it from bash.exe, you don't need
  to install Cygwin to run it, and you don't need a directory structure
  including /usr or /etc to make it work.

> For example, the official version of Python for Windows is
> considered a native Win32 application because it's implemented using
> the Windows APIs directly

That isn't (entirely) true. Python largely doesn't use the Win32 API
directly, but instead, it uses the C library of the C compiler it
was built with. It also uses the Win32 API directly, and more so
in Python 2.5 than in earlier versions, but reliance on the C library
still hasn't been dropped.

For Py3k, perhaps the C library can be dropped entirely: Guido wants
to drop usage of stdio as an implementation of the file object; if
then malloc/free is dropped in favour of a "direct" implementation
(e.g. based on HeapAlloc), then Python could become a "native Win32
application" in the sense you defined above.

Regards,
Martin