Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by djberg96 (2603) on 2008.02.18 12:01 (#61139) Journal
    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 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. [rubyforge.org]

    • 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