• A Guide to Installing Modules
• A guide to installing modules for Win32
• Practical Guide to Compiling C-based modules under Win32

While I'm sure that you can develop on Windows and deploy on unix/linux, as you've already been able to tell, there will just be some growing pains that may come back to bite you if you're not aware of them ahead of time. As an example, the drastic differences between how to install XS code on Windows vs unix/linux. As another example, the difference in path separators, or even PATH seperators (use File::Spec and other modules to handle all your filesystem interaction and you should be ok for this part).

If you're actually going to deploy on a Windows Apache server, then developing on a windows box makes sense. But if you're actually deploying on a Linux Apache server, then installing Linux (preferably the same distribution, but even a different one can be close enough for most problems) is just a sane thing to do. When your code deploys, any problems it has, your boss/client will come to you to fix. If you've got unix/linux experience, then it'll be much easier to fix. But if you've done all your development on Windows, you'll be sweating bullets trying to decipher some of unix's arcane error messages.

Given that you can get Linux for free and install as a dual boot system where you're not even committed to it 100% of the time, this just seems to make sense to me. Even if you only use the Linux partition for testing purposes so you can still use your favourite Windows text editor for most things. That said, my personal order of preference would be: Linux on its own computer (computers are getting pretty cheap, and you don't really need a fully decked out box for testing), Linux on a VMWare session (VMWare is even cheaper, but you need a reasonable machine to put it on - if you only have 256MB of RAM running XP, VMWare may put a fairly large strain on it), or Linux as a Windows application (I don't recall where, but I'm pretty sure I remember hearing that someone got the Linux kernel "booting" as a windows app so that you don't even need to install anything). If none of these are ok, and you can't even dual boot, you may get a LiveCD that runs Linux right off a CD, although each time you boot, you'll probably need to manually mount your Windows drives so you can run your application off the hard disk.

Similarly, if your deployment is going to be on a Sun box or an AIX box, etc., ideally you'd develop on that platform. However, those get to be a bit more expensive. Linux becomes a reasonably-close clone for most purposes, then you can take the above advice on setting up Linux.

Actually, if it was the other way around (developing on Linux, deploying on Win32) is that I'd be worried.

Mostly everything that runs under Win32 will run under Linux, but not the other way around (besides, obviously, Win32::* modules).

The only real problem I think is a fairly simple one: the path separator. But if you use '/' as a path separator on Win32 it will gladly work without complaining. And there's File::Spec that you already mentioned.

I think that, in a perfect world, perl should be really portable. But since that's not where we are, it's pretty easy to keep away from the non-portable features, if you need portability.


acid06
perl -e "print pack('h*', 16369646), scalar reverse $="