#9086: correct wrong terminology about linking with pythonXY.dll.

1 files changed, 11 insertions, 11 deletions

diff --git a/Doc/faq/windows.rst b/Doc/faq/windows.rst
index 4954ac0..bc539d5 100644
--- a/Doc/faq/windows.rst
+++ b/Doc/faq/windows.rst
@@ -290,20 +290,18 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
 
 1. 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
+   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.
 
-   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.)
+   You can link to Python in two different ways.  Load-time linking means
+   linking against :file:`python{NN}.lib`, while run-time linking means linking
+   against :file:`python{NN}.dll`.  (General note: :file:`python{NN}.lib` is the
+   so-called "import lib" corresponding to :file:`python.dll`.  It merely
+   defines symbols for the linker.)
 
-   Linking dynamically greatly simplifies link options; everything happens at
-   run time.  Your code must load :file:`python{NN}.dll` using the Windows
+   Run-time linking 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
@@ -312,6 +310,8 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
    Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf.exe
    first.
 
+   .. XXX what about static linking?
+
 2. 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