Discussion:
[python-win32] pywin32 on Nano Server
Alessandro Pilotti
2015-09-06 16:19:07 UTC
Permalink
Hi all,

I’m getting some Python based projects to work on Microsoft Nano Server, in particular OpenStack Hyper-V / Windows componens and Cloudbase-Init / Cloud-Init for Windows.

Python 3.4 x64 and Python 2.7 x64 currently work fine on Nano (Python 2.7 needs to be compiled targetting VS 2010 or above), but pywin32 required some work as Nano supports a significantly reduced API surface, although proxies called reverse forwarders are included to simplify porting of pre-existing applications.

Failing to remove unavailable exports results in DLL loading failures (C000142 / C0000135 errors), as you’d expect.

Here’s a fork of the pywin32 repository with Nano support, which works on the publicly availbale Nano server builds (e.g. Windows Server TP3). In particular here's the relevant patch:
https://bitbucket.org/cloudbase/pywin32/commits/cae1b44e00195847312a4521ae6c5cca3bb5b195

The patch is quite coarse grained and is meant to provide a fully working PoC and not meant for merging at the current stage, as some cleanup and tests are needed, but it should give though an idea of the scope of work.

Do you guys have already a plan around Nano support for pywin32?

Thanks!

Alessandro

P.S.: The WMI module required a patch as well to work on Nano, due to the lack of COM monikers support:
https://github.com/cloudbase/wmi/commit/e452f464f6c3c46d6ecbc973034738491996561a
Mark Hammond
2015-09-09 01:56:39 UTC
Permalink
Post by Alessandro Pilotti
Hi all,
I’m getting some Python based projects to work on Microsoft Nano Server,
in particular OpenStack Hyper-V / Windows componens and Cloudbase-Init /
Cloud-Init for Windows.
Python 3.4 x64 and Python 2.7 x64 currently work fine on Nano (Python
2.7 needs to be compiled targetting VS 2010 or above), but pywin32
required some work as Nano supports a significantly reduced API surface,
although proxies called reverse forwarders are included to simplify
porting of pre-existing applications.
Failing to remove unavailable exports results in DLL loading failures
(C000142 / C0000135 errors), as you’d expect.
Here’s a fork of the pywin32 repository with Nano support, which works
on the publicly availbale Nano server builds (e.g. Windows Server TP3).
https://bitbucket.org/cloudbase/pywin32/commits/cae1b44e00195847312a4521ae6c5cca3bb5b195
The patch is quite coarse grained and is meant to provide a fully
working PoC and not meant for merging at the current stage, as some
cleanup and tests are needed, but it should give though an idea of the
scope of work.
That looks fine, although a consideration will be packaging - it appears
to mean there will need to be twice as many packages built, and the
potential for confusion by users who have no idea what a "nano" build is
and whether they want that.

Another alternative (that is probably not viable) may be to build a
(many?) "stub" DLL(s) that throws errors and is conditionally loaded,
thus allowing the same distribution (but with reduced functionality) to
be used on nano.

TBH though, I'd be fine with a patch such as you provided with an eye to
a better solution in the future - but I'm not sure I can commit to
making nano-specific builds for every current build. That might mean
people wanting a nano build need to make one themselves, but at least
they will be able to do so without modifying the source.

(Also note that the .cpp files in pywin32 tend to use tabs rather than
spaces (hysterical raisins) , but your patch is using spaces)
Post by Alessandro Pilotti
Do you guys have already a plan around Nano support for pywin32?
Nope - it sounds like you are helping make one though ;)

Thanks!

Mark

Loading...