Ask YC: Is it painful to develop with PHP/Perl/MySQL on Windows?
19 comments
I used to do it, I recall that it wasn't that much of a pain to setup (like I spent a half day getting everything working and didn't worry about it again), but it was enough of a hassle moving code between my laptop and the production Linux servers that I went and learned vi, started developing over SSH, and eventually just bought VMWare and loaded up a Linux image.
The shebang line isn't really a problem - Windows servers just ignore it. IIRC, the Windows PHP and Perl Apache modules go by the file extension to determine which module to execute. This is probably in the configuration instructions somewhere...I just followed a tutorial on the web.
The parts that are really painful are:
1.) You have to be really careful keeping your code platform-independent - which is good practice anyhow, but can be tricky. Paths are the obvious problem - I was always forgetting and hardcoding backslashes instead of using whatever the PHP platform-independent equivalent is. Since the directory structures are different, you'll need to keep every path in a config file and reference them indirectly - again, good coding practice, but easy to forget.
2.) Some functions don't work the same between OSes - anything with symlinks, permissions, umask, or pipes is going to behave differently. IIRC most of these functions had sensible defaults (i.e. do nothing) and didn't fail outright, but keep this in mind.
3.) Calling out to external programs is a real pain. I think this is what made me finally switch - the app grew so that it needed to call out to UNIX-only command-line apps written in C, and I didn't feel like porting them to Visual C++.
That's all based off memory - it's been about 4-5 years since I developed on Windows, and 3 years or so since I last worked with PHP. Basically the upshot is that it's possible, but there were enough corner cases that for intensive work, I found it was better just to bite the bullet and get VMWare.
The shebang line isn't really a problem - Windows servers just ignore it. IIRC, the Windows PHP and Perl Apache modules go by the file extension to determine which module to execute. This is probably in the configuration instructions somewhere...I just followed a tutorial on the web.
The parts that are really painful are:
1.) You have to be really careful keeping your code platform-independent - which is good practice anyhow, but can be tricky. Paths are the obvious problem - I was always forgetting and hardcoding backslashes instead of using whatever the PHP platform-independent equivalent is. Since the directory structures are different, you'll need to keep every path in a config file and reference them indirectly - again, good coding practice, but easy to forget.
2.) Some functions don't work the same between OSes - anything with symlinks, permissions, umask, or pipes is going to behave differently. IIRC most of these functions had sensible defaults (i.e. do nothing) and didn't fail outright, but keep this in mind.
3.) Calling out to external programs is a real pain. I think this is what made me finally switch - the app grew so that it needed to call out to UNIX-only command-line apps written in C, and I didn't feel like porting them to Visual C++.
That's all based off memory - it's been about 4-5 years since I developed on Windows, and 3 years or so since I last worked with PHP. Basically the upshot is that it's possible, but there were enough corner cases that for intensive work, I found it was better just to bite the bullet and get VMWare.
I've done web development (PHP/MySQL) on both Windows and Linux, and Linux wins hands down for me primarily because of the number of useful utilities at my disposal on the command line and ease in moving around the directory tree.
However, packages like XAMPP help greatly in making sure everything runs smoothly when developing on Windows. Nothing in the PHP/MySQL code itself should have to be different on Windows, but configuration settings need to be tweaked prior to launch on a Linux box.
Caveats I can think of when moving code written in Windows to Linux is that Windows uses the backslash instead of the forward slash for directory paths, but I think newer versions of NT support the forward slash, too - please correct me if I'm wrong. Also, Windows uses a semicolon (;) to separate path variables while Linux uses a colon (:).
Windows also uses \r\n instead of just \n as a newline character so when/if you edit the code after porting to Linux, you'll get ^M characters at the end of each line, which I can't stand. A quick global search and replace restores my sanity though.
I don't have any experience at all using Perl on Windows, sorry.
However, packages like XAMPP help greatly in making sure everything runs smoothly when developing on Windows. Nothing in the PHP/MySQL code itself should have to be different on Windows, but configuration settings need to be tweaked prior to launch on a Linux box.
Caveats I can think of when moving code written in Windows to Linux is that Windows uses the backslash instead of the forward slash for directory paths, but I think newer versions of NT support the forward slash, too - please correct me if I'm wrong. Also, Windows uses a semicolon (;) to separate path variables while Linux uses a colon (:).
Windows also uses \r\n instead of just \n as a newline character so when/if you edit the code after porting to Linux, you'll get ^M characters at the end of each line, which I can't stand. A quick global search and replace restores my sanity though.
I don't have any experience at all using Perl on Windows, sorry.
The phrase you want to Google is probably "XAMPP".
I'd also recommend setting up xampp to get going quickly - its pretty handy. For scripts and perl command line in win32 I found ActivePerl the best - you can get a version for free from here -> http://www.activestate.com/Products/activeperl/features.plex.
More info on perl on win32 here -> http://win32.perl.org/wiki/index.php?title=Win32_Distributio...
More info on perl on win32 here -> http://win32.perl.org/wiki/index.php?title=Win32_Distributio...
Agreed. And I recommend Notepad++ for text editor
Might it make life easier if you just ran Linux as a virtual machine with something like Virtualbox?
You can run samba on it and export the filesystem over to your Windows host, allowing you to work with all the stuff with Windows native editors.
Alternatively, just install Linux and do all your work inside of it. If you use WUBI (which the current Ubuntu Hardy offers) there's no need to repartition or anything and uninstalling it leaves the system in it's original state.
You can run samba on it and export the filesystem over to your Windows host, allowing you to work with all the stuff with Windows native editors.
Alternatively, just install Linux and do all your work inside of it. If you use WUBI (which the current Ubuntu Hardy offers) there's no need to repartition or anything and uninstalling it leaves the system in it's original state.
I would try the vmware route. The vmware player is free (I think the server verison as well), and you can boot any linux in it.
Use windows for developping, use rsync to transfer your changes to the vmware image (or use a shared disk, or mounted disk, etc...).
You will ahve much less hassle to install perl modules (they often require a compiler) and no path issues ("/ vs \")
Use windows for developping, use rsync to transfer your changes to the vmware image (or use a shared disk, or mounted disk, etc...).
You will ahve much less hassle to install perl modules (they often require a compiler) and no path issues ("/ vs \")
I recommend this.
Things are painful when development and production deviate - figuring out how to install a particular module or library becomes double the work, as does anything "low level", and you're always running the risk of doing something non-portable, which translates to a bug in deployment.
All the other benefits of a VM, like snapshotting, certainly don't hurt. And if you do a server install of something like Ubuntu, your VM image shouldn't end up being more than a few gigs.
Things are painful when development and production deviate - figuring out how to install a particular module or library becomes double the work, as does anything "low level", and you're always running the risk of doing something non-portable, which translates to a bug in deployment.
All the other benefits of a VM, like snapshotting, certainly don't hurt. And if you do a server install of something like Ubuntu, your VM image shouldn't end up being more than a few gigs.
I know somebody who seems quite happy with CoLinux.
I use linux for all my work perl/ruby stuff and I use Windows for all my home perl/ruby stuff.
The big question: are these scripts you are running yourself or deploying?
running yourself it's not that big a deal, because you can fix headaches as you hit them. Expect to be running CPAN a lot to grab modules. Expect to be re-writing any system calls to use similar functions in the language (your scripts will be better for it).
It is WAY easier to run linux on a virtual machine than it is to develop under Windows. Windows has a million and one quirks that will have you screaming if you're used to coding on linux.
If you have to deploy on Windows, I generally use perl2exe or rubyscript2exe to create a standalone exe -- usually less painful then trying to get machines to have matching perl distributions.
The big question: are these scripts you are running yourself or deploying?
running yourself it's not that big a deal, because you can fix headaches as you hit them. Expect to be running CPAN a lot to grab modules. Expect to be re-writing any system calls to use similar functions in the language (your scripts will be better for it).
It is WAY easier to run linux on a virtual machine than it is to develop under Windows. Windows has a million and one quirks that will have you screaming if you're used to coding on linux.
If you have to deploy on Windows, I generally use perl2exe or rubyscript2exe to create a standalone exe -- usually less painful then trying to get machines to have matching perl distributions.
I find it easier to develop in PHP/Perl on Windows than any of the other language/framework combos. Most of the frameworks these days are geared towards the Mac/Linux developer with extensive use of the command-line. It can still be done on Windows but it can be a PITA sometimes.
I developed Eureka Science News (http//esciencenews.com) completely under Windows (using WAMP). Be sure to backup everything often though, catching a nasty machine-disabling adware on your dev box a week prior launch can be stressful (been there, alas)
Depends on what you're going to use. Cygwin makes it easy. Using ActiveState + Native Win32 MySQL is going to be painful (I didn't have much success getting DBI/DBD::MySQL working in that environment, but that was a few years back).
For the last 8 years, I've been developing LAMP projects on Windows and deploying on Linux. I don't have any trouble with PHP extensions nor do I have to change any code to deploy on Linux.
I've used XAMPP with PHP on Windows. Easy to setup and use. Supported toggling between PHP4 and PHP5 (I think the default was PHP4).
Currently I'm using VMWare and Ubuntu 7.x (be careful about using Ubuntu 8.x - I've seem to recall that VMWare tools may not have caught up and play well with that version yet).
I prefer the VMWare/Ubuntu approach for now since it will more closely mirror my intended deployment on Amazon Web Services (already started playing with an Ubuntu AMI).
Currently I'm using VMWare and Ubuntu 7.x (be careful about using Ubuntu 8.x - I've seem to recall that VMWare tools may not have caught up and play well with that version yet).
I prefer the VMWare/Ubuntu approach for now since it will more closely mirror my intended deployment on Amazon Web Services (already started playing with an Ubuntu AMI).
ive run apache, php, python w/ django, mysql, activeperl, and more on windows w/o issue. in fact, its been really easy to get just about everything going.
the only real problem ive ever encountered was that sometimes you'll need cygwin around to compile custom perl, php, or python extensions and modules. in the same vein, some (like orange, a data mining module for python) are made to be compiled with visual studio and can be a hassle to set up for anything else.
the only real problem ive ever encountered was that sometimes you'll need cygwin around to compile custom perl, php, or python extensions and modules. in the same vein, some (like orange, a data mining module for python) are made to be compiled with visual studio and can be a hassle to set up for anything else.
thats pretty amazing because i've found that python w/ django on windows really did my head in. so switched to linux!
[deleted]
I use perl on Windows all the time via Activestate, and it has no significant problems. The shebang doesn't matter if you use perl file extensions. Some Perl modules aren't on Activestate, though you can easily install them yourself and most of the time they work. I've found a few bugs, but not many.
I can't speak to Perl, but PHP and MySQL are bone dead easy on Windows.
Thanks for the help.
I totally forgot about VMWare/VirtualBox; I'll have to look into them more. Seems easier that way, and I get to use the same OS that the server runs.
I totally forgot about VMWare/VirtualBox; I'll have to look into them more. Seems easier that way, and I get to use the same OS that the server runs.
If you like TextMate, TextMate compatible editor http://www.e-texteditor.com/
[deleted]
Install Ubuntu on your notebook.
Based on some research, MySQL has Windows binaries available, Perl has ActivePerl (from ActiveState), and both PHP and Apache have binaries available as well.
The only thing I'm concerned about is if I'm going to have change anything in my scripts when uploading/deploying them to servers (running Linux). For example, Perl usually uses the #!/usr/bin/perl shebang. Or if some PHP and Perl extensions don't run under Windows.
Thanks for any help.