All the Perl that's Practical to Extract and Report

Win32 support

djberg96 on 2003-09-09T19:22:23

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. ;)

Poor Win32 support?

grantm on 2003-09-10T00:32:28

... 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 a compiler so I rely on the generosity of Activestate, Randy Kobes et al to provide pre-compiled packages for modules with XS components. I imagine they do suffer some pain getting things to compile, but the hard work has been done for the modules I use.

What sort of problems are you seeing?

Re:Poor Win32 support?

djberg96 on 2003-09-10T02:41:15

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.