@@ -167,7 +167,7 @@ How can I embed Python into a Windows application?
167
167
168
168
Embedding the Python interpreter in a Windows app can be summarized as follows:
169
169
170
- 1. Do _not_ build Python into your .exe file directly. On Windows, Python must
170
+ 1. Do ** not ** build Python into your .exe file directly. On Windows, Python must
171
171
be a DLL to handle importing modules that are themselves DLL's. (This is the
172
172
first key undocumented fact.) Instead, link to :file: `python{ NN } .dll `; it is
173
173
typically installed in ``C:\Windows\System ``. *NN * is the Python version, a
@@ -191,7 +191,7 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
191
191
2. If you use SWIG, it is easy to create a Python "extension module" that will
192
192
make the app's data and methods available to Python. SWIG will handle just
193
193
about all the grungy details for you. The result is C code that you link
194
- *into * your .exe file (!) You do _not_ have to create a DLL file, and this
194
+ *into * your .exe file (!) You do ** not ** have to create a DLL file, and this
195
195
also simplifies linking.
196
196
197
197
3. SWIG will create an init function (a C function) whose name depends on the
@@ -218,10 +218,10 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
218
218
5. There are two problems with Python's C API which will become apparent if you
219
219
use a compiler other than MSVC, the compiler used to build pythonNN.dll.
220
220
221
- Problem 1: The so-called "Very High Level" functions that take FILE *
221
+ Problem 1: The so-called "Very High Level" functions that take `` FILE * ``
222
222
arguments will not work in a multi-compiler environment because each
223
- compiler's notion of a struct FILE will be different. From an implementation
224
- standpoint these are very _low_ level functions.
223
+ compiler's notion of a `` struct FILE `` will be different. From an implementation
224
+ standpoint these are very low level functions.
225
225
226
226
Problem 2: SWIG generates the following code when generating wrappers to void
227
227
functions:
0 commit comments