On Fri, Dec 10, 2021 at 3:30 PM Craig A. Berry <craig.a.berry@gmail.com> wrote:
>
> On Fri, Dec 10, 2021 at 12:51 PM Nicholas Clark <nick@ccl4.org> wrote:
> > I don't think that bundling Win32::API is a great idea, but a minimal XS
> > module to wrap what we need does feel like a win here. There doesn't seem
> > to be one on CPAN (yet).
>
> The functions in here:
>
> https://github.com/Perl/perl5/blob/blead/cpan/Win32/Win32.xs
>
> seem to consist mostly of random things people needed to bootstrap
> other things. Arguably we now need a Win32::URLDownloadToFile() to
> bootstrap something. Or maybe Win32::InternetReadFile()[1]. If it's
> killing a sacred cow to put something else in Win32.xs, someone should
> speak up.
>
> > Not only am I not competent to write such a thing, I can't even volunteer
> > to have a go at something like "Markov chains and a regression test", as
> > I don't have access to anything Win32 to try it out.
>
> Damn. I have access so I have no excuses :-). Well, other than only
> ever having dealt with the Win32 API in Visual Basic, and that a very
> long time ago. Let me see how much trouble I can get myself into.
Quite a bit, it turns out. I've submitted a solution upstream:
https://github.com/perl-libwin32/win32/pull/30
I looked at the docs for URLDownloadToFile and InternetReadFile and
they both had a deprecation smell emanating from them. Or at least
the doc pages I landed on said things about the documentation no
longer being maintained. It may be these things will be around
forever, but I ended up using the WinHttp library, which has been
around since Windows XP and looks to be very much maintained. It
involved 8 or 10 different API calls (I lost count).
It's fairly easy to demonstrate that the new function successfully
downloads (via https) a tarball whose checksum matches the same
tarball downloaded with a web browser. It is rather harder to
demonstrate that it has no memory leaks, no security issues, and
correctly handles all unexpected error conditions. But, I did make an
effort to chase down all the details I could think of. Feel free to
chime in on the GitHub PR if you have questions, concerns, or are able
to do independent testing.
>
> On Fri, Dec 10, 2021 at 12:51 PM Nicholas Clark <nick@ccl4.org> wrote:
> > I don't think that bundling Win32::API is a great idea, but a minimal XS
> > module to wrap what we need does feel like a win here. There doesn't seem
> > to be one on CPAN (yet).
>
> The functions in here:
>
> https://github.com/Perl/perl5/blob/blead/cpan/Win32/Win32.xs
>
> seem to consist mostly of random things people needed to bootstrap
> other things. Arguably we now need a Win32::URLDownloadToFile() to
> bootstrap something. Or maybe Win32::InternetReadFile()[1]. If it's
> killing a sacred cow to put something else in Win32.xs, someone should
> speak up.
>
> > Not only am I not competent to write such a thing, I can't even volunteer
> > to have a go at something like "Markov chains and a regression test", as
> > I don't have access to anything Win32 to try it out.
>
> Damn. I have access so I have no excuses :-). Well, other than only
> ever having dealt with the Win32 API in Visual Basic, and that a very
> long time ago. Let me see how much trouble I can get myself into.
Quite a bit, it turns out. I've submitted a solution upstream:
https://github.com/perl-libwin32/win32/pull/30
I looked at the docs for URLDownloadToFile and InternetReadFile and
they both had a deprecation smell emanating from them. Or at least
the doc pages I landed on said things about the documentation no
longer being maintained. It may be these things will be around
forever, but I ended up using the WinHttp library, which has been
around since Windows XP and looks to be very much maintained. It
involved 8 or 10 different API calls (I lost count).
It's fairly easy to demonstrate that the new function successfully
downloads (via https) a tarball whose checksum matches the same
tarball downloaded with a web browser. It is rather harder to
demonstrate that it has no memory leaks, no security issues, and
correctly handles all unexpected error conditions. But, I did make an
effort to chase down all the details I could think of. Feel free to
chime in on the GitHub PR if you have questions, concerns, or are able
to do independent testing.