Original Translation
1107
The reason you can link the C code in step 2 into your .exe file is that calling the initialization function is equivalent to importing the module into Python! (This is the second key undocumented fact.)
1108
In short, you can use the following code to initialize the Python interpreter with your extension module.
1109
#include "python.h" ... Py_Initialize(); // Initialize Python. initmyAppc(); // Initialize (import) the helper class. PyRun_SimpleString("import myApp") ; // Import the shadow class.
1110
There are two problems with Python's C API which will become apparent if you use a compiler other than MSVC, the compiler used to build pythonNN.dll.
1111
Problem 1: The so-called "Very High Level" functions that take FILE * arguments will not work in a multi-compiler environment because each compiler's notion of a struct FILE will be different. From an implementation standpoint these are very _low_ level functions.
á é í ó ú ç ñ ü ¿ ¡
1112
Problem 2: SWIG generates the following code when generating wrappers to void functions:
1113
Py_INCREF(Py_None); _resultobj = Py_None; return _resultobj;
1114
Alas, Py_None is a macro that expands to a reference to a complex data structure called _Py_NoneStruct inside pythonNN.dll. Again, this code will fail in a mult-compiler environment. Replace such code by:
1115
return Py_BuildValue("");
1116
It may be possible to use SWIG's ``%typemap`` command to make the change automatically, though I have not been able to get this to work (I'm a complete SWIG newbie).