This month (March, but I forget the exact date) we celebrate the 1st anniversary of Vanilla Perl, and I'd like to thank all the Windows Heroes from irc.perl.org #win32, win32.perl.org and elsewhere that have put so much effort over the past year into helping make Perl on Windows suck less, as well as the many CPAN authors that have let us fix their modules, or fixed them for us.
Looking back how things have progressed, you can see a definite pattern forming.
Phase 1 - Creation of initial Vanilla Perl distro
Phase 2 - Porting and repair of the CPAN toolchain
Phase 3 - Creation of Perl::Dist and Strawberry Perl
Phase 4 - Porting and repair of the most popular CPAN modules
As you can see we've sort of swung back and forth twice now from working on the core distribution process itself, to working on modules and supporting issues.
While the porting and repair work on CPAN modules is likely to be an ongoing thing, I think I'd be safe in saying that most of the low-hanging fruit is gone now.
Almost all the basics of everyday life now work just fine on Windows, I'm happy to say.
There two situations left in which we have recurring problems. Both of these could be resolved by the people involved fairly easily, so I'm going to brand these people Windows Villains.
The first category are authors that, once we get their modules working on Windows, make major changes without doing dev releases to allow CPAN Testing to do it's job, and regress the entire platform into brokenness again.
It's not necessarily the author's fault for breaking them, they simply don't have the time to check, or don't have access to Win32, or care. But literally hundreds of other modules depend on these two, so for the sake of a dev release or two we have hundreds of modules being broken for months at a time between major releases.
The second category are similar. We've been producing patches and fixes for a number of modules, but the authors either haven't noticed or haven't had to time apply them. If the author has disappeared altogether, it's actually EASIER to fix them, because we just take those modules over.
If you own one of these modules, we'd really appreciate commit access or letting us have co-maint. We promise not to muck around with your code except for the compatibility changes, we've gotten quite good at it over the last year.
From the Win32 Problem Modules status page, our current list of Windows Villains for outstanding patches is Crypt::DSA, Devel::ebug, File::chdir, File::Tail, Module::Compile::Simple, Net::DNS, ppt, Sys::Hostname::FQDN, Test::HTTP::Server::Simple, WWW::Mechanize::Pluggable and WWW::Mechanize::Sleepy.
Please guys, if you could all move slightly to the left and just let us (well, chorny and tsee mostly) get past and fix your modules for you, we'd really appreciate it.
In any case, when it comes to CPAN modules I'm pretty happy now to draw a line under this work and call it "finished (mostly)".
Which leads us to the next series of problems to solve, and a new 3rd generation distribution.
Firstly, we need to get from an
The most promising progress on this problem is happening around a module in my repository called Win32::Wix. WiX (Windows Installer XML) is an XML dialect that when combined with a set of simple console
I wrote up an initial skeleton several months ago (taking an existing XML file and wrapping the WiX applications) but didn't really have the time to go further. metatrontech++ has recently picked up the module and is improving it to actually generate the XML files as well.
Once this is all working, hopefully we can merge it into Perl::Dist somehow and let you generate EITHER
As an added bonus, I'm informed that the WiX
There's also some changes pending to the MinGW setup to make them work better/properly on Vista, and it's probably about time we worked out how to force man pages to not be built (saving a bunch of disk space).
Driving these changes is the emerging demand from companies (I've had two job offers in the last couple of weeks) to take existing Perl applications made for Unix and be able to deliver them to customers that want to run them on Windows using Vanilla Perl as a (largely invisible) platform.
They like the idea of a fully automated and Open Source tool they can just throw their application at in the form of a CPAN-like distribution or something similar, twiddle with a few things, tick a few boxes, and it will work out the details and spit out an
They can then send that to their customers, who can push it out via Active Directory to their whole company. None of the customers even need to know the application is in Perl, it should all Just Work on Unix, Mac and Win32.
This means more income for Perl development companies, and more jobs for Perl coders. Which is always a positive thing.
Also driving this need for a new Vanilla release cycle is the upcoming Perl 5.10.0 release. Because the distro build process is now totally automated (thanks to David Golden) we hope to release an official production Strawberry Perl 5.10.0 on the same day as the official Perl 5.10.0 source release.
And after all THAT is done, maybe we'll finally get enough breathing room to start looking at doing Chocolate Perl and I can finally get my GUI CPAN client.