Monday, June 23, 2008

The trials of a CPAN author

As mentioned previously I have a module called Win32::EnvProcess. The CPAN people (modules@cpan.org) don't like that name, although I'm not sure why. Changing a name is not clearly defined, and I don't get answers to email. Hey ho, it doesn't stop Win32::EnvProcess from being found and downloaded.

And that's the trouble with being a developer – people will actually try and use the stuff. So I get queries, and I get bug reports.

Generally the email queries are sensible, and I have had a few over the past week. First I, or rather a user, had an issue with Microsoft Visual Studio 2005, which is a version I haven't got around to using. It seems that good ol' Microsoft decided to fix the "DLL hell" problem by introducing a 'manifest' file into its link/load phase. So now we get "manifest hell" instead - the issues are well documented on the web. Of course the Perl MakeMaker does not generate a manifest file for its DLLs, and so my module wouldn't load and run. After some blind alleys and investigation I found a patch for MakeMaker, via perlmonks which I passed on. Of course that meant I had to document the thing as well. Meanwhile I found a small memory leak. OK, so that was worth it.

Then I got a bug report saying that the installation failed if the user did not have a C/C++ compiler. OK, I would have thought that if the product included an XS file, and the documentation showed compilation steps, then that would have been obvious. Clearly not, so more lines to the doc.

A user sent a "it would be great if…" feature request. "Good idea", I thought. "Simple patch", I thought. Only one of those thoughts was correct. Well you see it all worked on my Windows machines, it's just that it failed everywhere else. It wasn't until one of the cpan testers sent me a copy of his environment block that I cracked it. Their environment blocks were bigger than a hard limit I set – size matters. I hate hard limits and try and avoid them, but in this case I have to set one to a file mapping object. It's just that I was not handling the overflow case correctly.

There is nothing like a sustained bout of debugging to improve the diagnostics available in code. And of course I found another (unrelated) buglett as well – a possible race condition.

Then another bug report, this time someone is trying to compile the module under cygwin. Cygwin is a UNIX emulation environment, and this module is called Win32::EnvProcess – the clue is in the name. I check the OS name in the tests, but the thing won't compile and link anywhere except Windows. Of course not, RTFM. Alright, so Cygwin runs under Windows but it doesn't give access to the Windows kernel, it pretends it is UNIX.

Don't get me started about Strawberry Perl, just don't. Alright then. Strawberry Perl is a laudable package of open source products to enable you to install Perl without any dreaded Micro$osft licences. Good, great stuff, more power to them. Except that the Perl installation tools, like MakeMaker, doesn't really support it. So more magic in my Makefile.PL, already burdened by this stupid manifest issue. UNIX? Pah, that's easy.

Version 0.05 of Win32::EnvProcess has just been uploaded. God bless her, and all who sail in her.