In my experience, writing PHP on one platform and deploying it on another doesn't always work out. Your developers have to be aware of where their app will be d

In my experience, writing PHP on one platform and deploying it on another doesn't always work out. Your developers have to be aware of where their app will be deployed and the specifics of that OS. > I think PHP support on Windows is as good as on any other OS. I have seen several things fail in that environment - escaping shell commands and arguments is problematic, invoking external executables is only reliable when full path is used [1], realpath() (used to, at least) chokes on / as a directory separator... Autoloading classes based on classname => filename can produce funny results. File uploads can work differently (case sensitive filenames - foo.jpg and foo.JPG can coexist in Linux, but not in Windows). On the other hand, there are things like the new MSSQL PDO driver that only exist in the Windows world. --- [1] Windows 2003 Server was running our app, which invoked Imagick similar to `convert $input.jpg $output.jpg`. Worked just great for half a year. Deployed to a second machine, Windows 2008 Server. Command execution fails silently. Change %PATH% to be identical to the old server's one. Restart. Still fails. Compare phpinfo(). $_ENV['PATH'] in new server doesn't match %PATH% (it appears to be re-sorted with windows folders first), $_ENV['PATH'] in old server matches %PATH%. Messing around with new %PATH% changes nothing, new server keeps giving PHP the silently-reordered %PATH%. Nothing helps, short of specifying full path to `convert`. A very fun thing to debug.