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 ]

djberg96 (2603)

  (email not shown publicly)

Journal of djberg96 (2603)

Tuesday September 09, 2003
02:22 PM

Win32 support

[ #14607 ]
I've really gotten on this Win32 kick lately. Initially, this was brought on because I needed to make sure one of our apps would work on Win32 systems. However, it has started to bleed into a desire to make programming as seemless as possible between *nix and Win32.

Now, ActiveState took a pretty big step when they made fork() available in their Perl for Win32 product (I'm not sure if they did the same for Python). But, there's more to life than fork - etc, process info, native threads - the list goes on.

I have noticed that there's a decent selection of Win32 modules on CPAN, but I'm learning that anything that doesn't explicitly fall under the Win32:: namespace either does a poor job of supporting Win32 or doesn't support it at all. And, of course, anything that *does* fall under the Win32:: namespace (*horror*) only works on Win32 systems.

I've been working to rectify this somewhat in Ruby, which is lacking compared to Perl and Python when it comes to Win32 support, IMHO. However, I think all three languages (which can, naturally, more or less share source code) could use improvement in this area. Here are some ideas I've been tossing around:

  • fork() - Perl has it, but Ruby doesn't. Not sure about Python.
  • setsid() - Run the program as a Service, the closest thing to a background process that Win32 has. Not sure about privilege issues.
  • syslog - Win32 has the Event Log. Is the API similar enough to make this seemless? Again, I'm not sure about privilege problems.
  • etc - I've managed to get the get* side of the familiy for Ruby (hopefully it will be adopted into the core). I imagine that Perl and Python programmers might like it added as well.
  • Native Thread Support - I'm not qualified to do this, or even if it's worth worrying about. But I thought I would at least mention it.

Well, that's all I can think of at the moment. Oh, I should also mention that I would entirely focus on NT/2000/XP. Win95 and Win98 users can get stuffed - they're dead and no one uses them in any sort of serious production environment anyway. I don't want source code sullied by a bunch of #ifdef's just to make something work on Windows 95, for example. Too much cruft to support for no gain. Of course, the same could be said for BeOS, but hey, I actually *like* BeOS. ;)

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.
  • ... but I'm learning that anything that doesn't explicitly fall under the Win32:: namespace either does a poor job of supporting Win32 or doesn't support it at all...

    I'm not quite sure what you mean by this and one of the reasons I use Perl is that my experience has been exactly the opposite - most things work well across platforms. Certainly the big-name modules like LWP, DBI, XML::* have not given me any trouble due to Win32 issues.

    The biggest problem I've encountered on Win32 is that I don't have

    • Actually, I was only referring to C extensions, not pure Perl code. In that regard Perl, Python and Ruby are all more or less *nix-centric.

      Part of the problem I think is that a lot of the hard-core C programmers won't, don't or can't program on the Win32 environment and so it ends up an afterthought.