Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

dagolden (6584)

  (email not shown publicly)
AOL IM: xdaveg (Add Buddy, Send Message)

Journal of dagolden (6584)

Monday February 18, 2008
08:50 AM

libwin32: can we divide and conquer?

[ #35683 ]

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 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 Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I highly recommend that, in addition to splitting out these libraries into individual modules, they be converted to pure Perl using Win32::API.

    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 W

    • That would be very nice!
    • 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/unpack and Perl's syscall, but I've only ever seen one pers