Python extensions for windows

5. Building C and C++ Extensions on WindowsВ¶

This chapter briefly explains how to create a Windows extension module for Python using Microsoft Visual C++, and follows with more detailed background information on how it works. The explanatory material is useful for both the Windows programmer learning to build Python extensions and the Unix programmer interested in producing software which can be successfully built on both Unix and Windows.

Module authors are encouraged to use the distutils approach for building extension modules, instead of the one described in this section. You will still need the C compiler that was used to build Python; typically Microsoft Visual C++.

This chapter mentions a number of filenames that include an encoded Python version number. These filenames are represented with the version number shown as XY ; in practice, ‘X’ will be the major version number and ‘Y’ will be the minor version number of the Python release youвЂ™re working with. For example, if you are using Python 2.2.1, XY will actually be 22 .

5.1. A Cookbook ApproachВ¶

There are two approaches to building extension modules on Windows, just as there are on Unix: use the distutils package to control the build process, or do things manually. The distutils approach works well for most extensions; documentation on using distutils to build and package extension modules is available in Distributing Python Modules (Legacy version) . If you find you really need to do things manually, it may be instructive to study the project file for the winsound standard library module.

5.2. Differences Between Unix and WindowsВ¶

Unix and Windows use completely different paradigms for run-time loading of code. Before you try to build a module that can be dynamically loaded, be aware of how your system works.

In Unix, a shared object ( .so ) file contains code to be used by the program, and also the names of functions and data that it expects to find in the program. When the file is joined to the program, all references to those functions and data in the fileвЂ™s code are changed to point to the actual locations in the program where the functions and data are placed in memory. This is basically a link operation.

In Windows, a dynamic-link library ( .dll ) file has no dangling references. Instead, an access to functions or data goes through a lookup table. So the DLL code does not have to be fixed up at runtime to refer to the programвЂ™s memory; instead, the code already uses the DLLвЂ™s lookup table, and the lookup table is modified at runtime to point to the functions and data.

In Unix, there is only one type of library file ( .a ) which contains code from several object files ( .o ). During the link step to create a shared object file ( .so ), the linker may find that it doesnвЂ™t know where an identifier is defined. The linker will look for it in the object files in the libraries; if it finds it, it will include all the code from that object file.

In Windows, there are two types of library, a static library and an import library (both called .lib ). A static library is like a Unix .a file; it contains code to be included as necessary. An import library is basically used only to reassure the linker that a certain identifier is legal, and will be present in the program when the DLL is loaded. So the linker uses the information from the import library to build the lookup table for using identifiers that are not included in the DLL. When an application or a DLL is linked, an import library may be generated, which will need to be used for all future DLLs that depend on the symbols in the application or DLL.

Suppose you are building two dynamic-load modules, B and C, which should share another block of code A. On Unix, you would not pass A.a to the linker for B.so and C.so ; that would cause it to be included twice, so that B and C would each have their own copy. In Windows, building A.dll will also build A.lib . You do pass A.lib to the linker for B and C. A.lib does not contain code; it just contains information which will be used at runtime to access AвЂ™s code.

In Windows, using an import library is sort of like using import spam ; it gives you access to spamвЂ™s names, but does not create a separate copy. On Unix, linking with a library is more like from spam import * ; it does create a separate copy.

5.3. Using DLLs in PracticeВ¶

Windows Python is built in Microsoft Visual C++; using other compilers may or may not work (though Borland seems to). The rest of this section is MSVC++ specific.

When creating DLLs in Windows, you must pass pythonXY.lib to the linker. To build two DLLs, spam and ni (which uses C functions found in spam), you could use these commands:

The first command created three files: spam.obj , spam.dll and spam.lib . Spam.dll does not contain any Python functions (such as PyArg_ParseTuple() ), but it does know how to find the Python code thanks to pythonXY.lib .

The second command created ni.dll (and .obj and .lib ), which knows how to find the necessary functions from spam, and also from the Python executable.

Not every identifier is exported to the lookup table. If you want any other modules (including Python) to be able to see your identifiers, you have to say _declspec(dllexport) , as in void _declspec(dllexport) initspam(void) or PyObject _declspec(dllexport) *NiGetSpamData(void) .

Источник

Python extensions for windows

This is the readme for the Python for Win32 (pywin32) extensions, which provides access to many of the Windows APIs from Python.

See CHANGES.txt for recent notable changes.

Build 228 is the last build supporting Python 2, and as part of this transition, all code in the repository is now using Python 3 syntax. To highlight and celebrate this change, build 228 is the last numbered 2XX — the following build numbers start at 300.

In other words, there is no build 229 — the build numbers jump from 228 to 300.

As of build 222, pywin32 has a new home at github. You can find build 221 and later on github and older versions can be found on the old project home at sourceforge

A special shout-out to @xoviat who provided enormous help with the github move!

Feel free to open issues for all bugs (or suspected bugs) in pywin32. pull-requests for all bugs or features are also welcome.

However, please do not open github issues for general support requests, or for problems or questions using the modules in this package — they will be closed. For such issues, please email the python-win32 mailing list — note that you must be subscribed to the list before posting.

By far the easiest way to use pywin32 is to grab binaries from the most recent release

Installing via PIP

Note that PIP support is experimental.

You can install pywin32 via pip:

Note that if you want to use pywin32 for «system wide» features, such as registering COM objects or implementing Windows Services, then you must run the following command from an elevated command prompt:

python Scripts/pywin32_postinstall.py -install

Building from source

Building from source is extremely complicated due to the fact we support building old versions of Python using old versions of Windows SDKs. If you just want to build the most recent version, you can probably get away with installing th same MSVC version used to build that version of Python, grabbing a recent Windows SDK and running setup.py

setup.py is a standard distutils build script. You probably want:

You can run setup.py without any arguments to see specific information about dependencies. A vanilla MSVC installation should be able to build most extensions and list any extensions that could not be built due to missing libraries — if the build actually fails with your configuration, please open an issue.

The following steps are performed when making a new release — this is mainly to form a checklist so mhammond doesn’t forget what to do 🙂

Ensure CHANGES.txt has everything worth noting, commit it.

Update setup.py with the new build number.

Execute build.bat, wait forever, test the artifacts.

Commit setup.py (so the new build number is in the repo), create a new git tag

Update setup.py with the new build number + «.1» (eg, 123.1), to ensure future test builds aren’t mistaken for the real release.

Make sure everything is pushed to github, including the tag (ie, git push —tags )

Upload the .exe installers to github (using the web UI), the .whl files to pypi (using py -3.5 -m twine upload dist/*XXX*.whl where XXX is the build number).

Источник

Python extensions for windows

mhammond released this Jun 13, 2020 · 45 commits to master since this release

To download pywin32 binaries you must choose both the correct Python version and «bittedness».

Note that there is one download package for each supported version of Python — please check what version of Python you have installed and download the corresponding package.

Some packages have a 32bit and a 64bit version available — you must download the one which corresponds to the Python you have installed. Even if you have a 64bit computer, if you installed a 32bit version of Python you must install the 32bit version of pywin32.

To determine what version of Python you have, just start Python and look at the first line of the banner. A 32bit build will look something like