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.

> - 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)?