On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <report@bugs.python.org> wrote:

>
> Nadeem Vawda <nadeem.vawda@gmail.com> added the comment:
>
> Thanks for investigating the Windows situation.
>
> > - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly
> > variables declared in the middle of a block.  It's doable for sure, but
> it's a
> > lot of work.
>
> I don't think that creating our own MSVC-friendly fork of liblzma is really
> an
> option. Over and above the work of porting it in the first place (and all
> the
> opportunities for bugs to creep in along the way), we'd also have to worry
> about
> keeping up to date with upstream changes. I believe we currently do
> something
> similar with libffi (for ctypes), and the impression I've gotten is that
> it's
> caused a lot of trouble.

It's much better to contribute patches upstream.

> > - The way recommended by XZ is to use a precompiled liblzma.dll; Then it
> > should be easy to build an extension module, but its would be the first
> time
> > that we distribute an extension module which needs a non-system DLL.  Is
> it
> > enough to copy it next to _lzma.pyd?  Is there some work to do in the
> > installer?
>
> I would guess that this is sufficient, but my knowledge of how Windows DLLs
> work
> is minimal. Could someone with more platform knowledge weigh in on whether
> this
> would work (and if there are any problems it might cause)?

I've not done much with windows dll's, but I've heard they're pretty similar
to AIX shared libraries which I've done some work with.  AIX shared
libraries don't deal with versioning well - if you have two version of the
same library on a system, you have to pop them into two different loader
domains, or suffer unresolved externals at runtime.  Then your applications
are in of the two loader domains, and if they're in the wrong one, you again
suffer unresolved externals at runtime.