Guildenstern has asked for the wisdom of the Perl Monks concerning the following question:

Has anyone used Win32::API to call various Windows methods? I've got a project coming up soon that would be ideal for Perl, but would need to use some basic Windows functionality as well and I was wondering if there are any gotchas I should look out for.
I know that some functions are exported from different DLLs between Win9x/NT/2000, so I would probably have to perform a check on the OS, but that's pretty trivial.
What I'm really looking for is any kind of advice about using Win32::API. It may ultimatley be easier for me to write some Windows-specific code in Visual C++ then call it from the Perl script, but I would prefer a more homogenous solution.

Replies are listed 'Best First'.
RE: Anyone use Win32::API?
by t0mas (Priest) on Aug 19, 2000 at 22:05 UTC
    I've used the Win32::API to write Win32SnapWalk. It works well and is quite straight-forward. Main problem for me was to know which functon was in which dll, but if your'e an experienced Win32 C++ programmer that will not be a problem for you :)

    /brother t0mas
      i downloaded your code. great example of how to make the actual function calls, etc. i guess i'll just have to do my homework and make sure i know in what DLLs my functions are located in each version of windows.
Re: Anyone use Win32::API?
by tye (Sage) on Aug 20, 2000 at 05:40 UTC

    You might want to try the new Inline.pm. From reading the recent announcement for it in comp.lang.perl.announce, the author(s) really knew what they were doing. One thing it will give you is that you won't have to know which DLL a routine is in.

    It provides what is probably the simplest possible interface for accessing C routines from Perl. You can use it in a script (in which case the script won't be able to run on a machine that doesn't have a C compiler and have Perl configure so that MakeMaker knows how to use it). Or you can use it to write modules. You can probably make a PPM for such a module (nearly?) the same way you would for any other module.

    You can also look into the modules FFI and C::Dynalib, both of which appear to have a better design than Win32::API (as well as being portable to other platforms -- though that doesn't matter here) -- though I've never used either. I've used Win32::API enough to be frustrated with the design and the gotchas involved in getting it installed. But it is certainly powerful and I've used it successfully (before I'd heard of FFI and C::Dynalib). Now days I usually throw together a quick XS module instead of using any of these.

            - tye (but my friends call me "Tye")
      i find it interesting that using PPM supplied with ActiveState's Perl, none of these PM's showed up.
      Inline.pm looks like a good solution if we were rolling out our packages (internal term, not Perl packages) to machines that we knew had C compilers on them. in the Fortune 5000 world, i think this does not have a high probability. :) very interesting, though and i'll have to see if i can put into some development stuff.
      FFI looks to almost be more clunky than Win32::API. look at this chunk of code from the module's examples section:
      $clib_file = ($^O eq "MSWin32") ? "MSVCRT40.DLL" : "-lc"; $clib = DynaLoader::dl_findfile($clib_file); $strlen = DynaLoader::dl_find_symbol($clib, "strlen"); $n = FFI::call($strlen, "cIp", $my_string); DynaLoader::dl_free_file($clib);

      looks like a lot of work IMO.
      C::Dynalib looks good, but it appears that it still requires some knowledge of where the functions you want to call are located.
      it looks like for our use, Win32::API might just be the best option. we will be using several registry calls which are fairly well supported already, and after some design talks it looks like we'll only need to call one method through Win32::API, which shouldn't be too bad. if it were larger scale, Inline.pm looks very good.
      thanks for the excellent info!