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 -- http://mail.python.org/mailman/listinfo/python-list
