I recently installed Strawberry Perl on a virtual machine. Since Strawberry Perl doesn't (yet) include libwin32 from the start that was one of the first distributions I installed from CPAN.
I was annoyed to find that it aborted testing on Win32::FileSecurity. Why? Because my partion was FAT32, not NTFS. Ironically -- it warns that it will fail when not on NTFS, but does nothing to test for it. (c.f. Win32::FsType() -- though maybe that didn't exist when the test was first written)
While that's an easy fix, it highlighted a bigger issue that I have with libwin32. Because it bundles multiple modules as separate distributions with recursive Makefiles, that single failure stopped tests, so I couldn't even see if the rest of libwin32 worked correctly. (So, yes, hack-fix Win32::FileSecurity, continue testing, all tests pass, install, post bug and patched test.pl file to RT, whee...)
I wish all the individual modules in libwin32 could be broken out into separate CPAN distributions and all of them were just added to Bundle::libwin32 instead. That way, some strange failure of one module wouldn't stop the rest from installing.
Moreover, I wonder if having separate distributions would make it easier to distribute responsibility for tackling the growing RT queue and let individual modules be fixed and released on a faster cycle.
So that's my challenge to the maintainers and the lazyweb -- help us divide and conquer libwin32!
-- dagolden
The advantages of doing this are twofold. First, you eliminate compiler and binary compatibility issues, which are a major hassle on Windows. Second, you improve the likelihood of receiving patches, since most of your user base doesn't understand C or have a compiler with which to debug a C extension (especially Perl extensions - oof).
Speed is a non-issue. With Win32::API you're still dealing with wrapped function pointers so it's pretty zippy. Not as fast as pure C, mind you, but still plenty fast.
I speak from experience.
Re:Pure Perl
sigzero on 2008-02-18T17:07:58
That would be very nice!Re:Pure Perl
chromatic on 2008-02-18T18:53:18
Based on my experiments with FFI systems and Perl, the speed issue is mostly negligible. If Win32::API builds up thunks once, then lets you call the foreign functions through the thunks, then speed is nearly the same as that of XS. The real expense seems to be parameter marshalling and unmarshalling and the double-dispatch (first to the thunk, then to the actual function pointer). You have to do that with both systems.
... or you could use
pack/unpackand Perl'ssyscall, but I've only ever seen one person do that.
