Creating C modules for Python under Cygwin

[Alex Martelli]

Neil Hodgson wrote:
        ...
>    While you can link against executables, you should avoid doing so in
>    most
> cases. The common case where this occurs is where a DLL is mostly a
> library that provides services consumed by the executable but a need
> appears for a call back into the executable. You then have two binaries
> which depend on each others export libraries to link. To resolve the

When the EXE loads the DLL dynamically, it need not depend on the
DLL's export library to link.  Therefore, the dependency is not cyclical
and we're outside the "most cases" where the DLL -> EXE linktime
dependency should be avoided.  For example, when Python loads an
extension from a _GEER.DLL to satisfy an "import _GEER", Python will
have no linktime dependency on _GEER.LIB, and that doesn't change
whether _GEER.DLL is linked against the EXE itself, some common
DLL, or neither.  After the LoadLibrary call, Python will then use
GetProcAddress for "init_GEER" and, if found, transfer control to
that entrypoint.  There is absolutely no problem whether _GEER.DLL
now calls back into the EXE directly, or into a DLL they both share.


>> I wonder what those "other reasons" could be, though. What exactly
>> *is* the rationale for Python using a DLL on Windows?
> 
>    COM. If you want to use COM objects implemented in Python in-process
>    from
> arbitrary executables such as IIS or IE, then you can't require linking to
> another  executable.

Yes, that's good motivation -- any EXE needs a further process, so, if
you want to be able to run in the same process as your client, you do
need to pack your functionality up in a DLL (and further precautions).


Alex