Original Translation
1097
Yes, .pyd files are dll's, but there are a few differences. If you have a DLL named ``foo.pyd``, then it must have a function ``initfoo()``. You can then write Python "import foo", and Python will search for foo.pyd (as well as foo.py, foo.pyc) and if it finds it, will attempt to call ``initfoo()`` to initialize it. You do not link your .exe with foo.lib, as that would cause Windows to require the DLL to be present.
1098
Note that the search path for foo.pyd is PYTHONPATH, not the same as the path that Windows uses to search for foo.dll. Also, foo.pyd need not be present to run your program, whereas if you linked your program with a dll, the dll is required. Of course, foo.pyd is required if you want to say ``import foo``. In a DLL, linkage is declared in the source code with ``__declspec(dllexport)``. In a .pyd, linkage is defined in a list of available functions.
1099
How can I embed Python into a Windows application?
1100
Embedding the Python interpreter in a Windows app can be summarized as follows:
1101
Do _not_ build Python into your .exe file directly. On Windows, Python must be a DLL to handle importing modules that are themselves DLL's. (This is the first key undocumented fact.) Instead, link to :file:`python{NN}.dll`; it is typically installed in ``C:\Windows\System``. NN is the Python version, a number such as "23" for Python 2.3.
á é í ó ú ç ñ ü ¿ ¡
1102
You can link to Python statically or dynamically. Linking statically means linking against :file:`python{NN}.lib`, while dynamically linking means linking against :file:`python{NN}.dll`. The drawback to dynamic linking is that your app won't run if :file:`python{NN}.dll` does not exist on your system. (General note: :file:`python{NN}.lib` is the so-called "import lib" corresponding to :file:`python.dll`. It merely defines symbols for the linker.)
1103
Linking dynamically greatly simplifies link options; everything happens at run time. Your code must load :file:`python{NN}.dll` using the Windows ``LoadLibraryEx()`` routine. The code must also use access routines and data in :file:`python{NN}.dll` (that is, Python's C API's) using pointers obtained by the Windows ``GetProcAddress()`` routine. Macros can make using these pointers transparent to any C code that calls routines in Python's C API.
1104
Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf.exe first.
1105
If you use SWIG, it is easy to create a Python "extension module" that will make the app's data and methods available to Python. SWIG will handle just about all the grungy details for you. The result is C code that you link *into* your .exe file (!) You do _not_ have to create a DLL file, and this also simplifies linking.
1106
SWIG will create an init function (a C function) whose name depends on the name of the extension module. For example, if the name of the module is leo, the init function will be called initleo(). If you use SWIG shadow classes, as you should, the init function will be called initleoc(). This initializes a mostly hidden helper class used by the shadow class.