Creating C modules for Python under Cygwin

[Alex Martelli]

<posted & mailed>

Martin v. Löwis wrote:
        ...
> Both: it is impossible to access symbols that are defined in an
> executable on Windows - you *must* get all symbols you need from a
> library.  

Martin: this assertion is simply incorrect.  Windows has enough real 
problems, without a need to go inventing more, false ones gainst it.

For example, take the following the_exe.cpp:

#include <stdio.h> 
#include <windows.h> 
 
extern "C" 
__declspec(dllexport) 
void greet() 
{ 
        printf("Hello World!\n"); 
} 
 
typedef void (*pf)(char*, int); 
 
int main(int argc, char* argv[]) 
{ 
        HMODULE h = LoadLibrary("a_lib.dll"); 
        FARPROC f = GetProcAddress(h, "repeat"); 
        (*(pf)f)("greet", 3); 
 
        return 0; 
} 

and the following a_lib.cpp:

#include <windows.h> 
 
typedef (*pf)(void); 
 
extern "C" 
__declspec(dllexport) 
void repeat(const char* name, int n) 
{ 
        HMODULE h = GetModuleHandle(0); 
        FARPROC f = GetProcAddress(h, name); 
        for(int i=0; i<n; ++i) 
                (*(pf)f)(); 
}


Build each of these into the_lib.exe and a_lib.dll respectively, setting
each to use the same runtime (e.g. the popular MSVCRT.DLL, "Thread-safe
DLL").  Place them in the same directory and from a Dos prompt run
THE_LIB.EXE.  You'll see the DLL perfectly able to "access symbols that
are defined in an executable in Windows".

This is with Dynamic loading, but static link-time resolution works just
as well, since linking THE_EXE.EXE produces a THE_EXE.LIB to go with it
(and similarly for A_LIB.DLL producing A_LIB.LIB), so you might do static
linking if you wished.  Also, you might use .DEF files if you wished
rather than the __declspec(dllexport) decoration -- impractical for C++
mangled names but quite OK for plain C ones (as here defined thanks to
the 'extern "C"' notation).

So, it's PERFECTLY feasible on Windows for a DLL to access symbols that
are defined in the executable that loads said DLL, by any of several
means.

> So if you have a standalone python.exe, it is impossible to
> build extensions for it.

I really can't see that.  A standalone python.exe might be less than
optimal for other reasons, but it would be PERFECTLY feasible to build
extensions for it (presumably to be linked against the PYTHON.LIB, and
with symbols exposed from linking with PYTHON.DEF, though you could
vary either of these building choices for some reason).


Alex