I didn't even know that Microsoft were the ones creating the official PHP builds, and now that I do, I have no idea why they were in the first place. Especially not when PHP is software that's owned by a company that has had the resources to pay for normal CI/CD pretty much since PHP became big enough for Zend to hire staff.
The Microsoft guys did more than providing a CI. They cleaned up in regards to windows, whatever devs using Linux only did. Also they spent some time tuning the stack and continuous updates to the stack.
Zend had nice marketing, but had been only one contributor under many. Far from owning PHP.
My experience with PHP on Windows has been continously terrible. Was there some trick I missed? I have never seen any options in a vanilla IIS to enable PHP.
I’ve been out of the PHP game for a decade or so but Windows, Apache, and PHP always worked no problem. Maybe Windows, IIS, and PHP is a more fickle stack?
That makes a lot more sense. And really just feels like Microsoft's current trend continuing: Dropping human-curated in-house QA and assistance in favor of automation and community contribution.
Not only that, with wsl2 on windows being in the mainline windows, developers have a very good alternative. I don't this is a coincidence... Running actual PHP servers on windows is a rarity, and not worth it to support it officially on Windows. Azure is able to run it all, so they don't really care anymore what platform you're targeting, as long as windows is a viable development platform, and Azure a potential deploy target.
This is about PHP For Windows [1], which build is currently supported by Microsoft. The original title "Microsoft Support of PHP on Windows" might be not sufficient but at least not inaccurate. (EDIT: The submission title has been updated since this post.)
Doesn't seem like a big deal. In this case I believe "MS support" is just compiling PHP for Windows and making them available at the PHP for Windows site.
I'm sure someone will pick this up. Or maybe it ends up being something like Apache where you have to find other places in the ecosystem which provide binaries for Windows. Or just compile the thing yourself.
Yes. In my experience, it usually comes down to "Our Windows admins don't know Linux, so it'll be easier for them to manage a server if it's running Windows!"
Except they never do, because they don't know PHP on Windows either and are afraid of breaking things, and the customer ends up with a PHP/Wordpress installation that is 4 years out of date.
Luckily, most of those are internal-only apps, but it still sucks.
Where I used to work, we developed and supported a SaaS app based on PHP with PostgreSQL and Apache. We had two self-hosting customers who ran on Windows Server with SQL Server for the exact reasons mentioned, and they were our most troublesome customers. Performance tuning (and hence regular complaints that 'our' app was horribly slow) was a particular issue - mostly due to their admins' lack of relevant experience on both the stack...and Windows Server(!). The whole setup was a pain because we got so much flak, despite the premise of 'self-hosting' being that the customer had sufficient smarts to support the infrastructure and stack and we'd just support the functional and development aspects of the app.
One customer also had the system so locked down that for remote admin we had to connect to a jump box via VPN + RDP and then jump from that to the server with another RDP connection. Fetching large log files through that setup was a challenge.
Partly for our sanity, we persuaded one customer to let us migrate them to a Linux server; that went very well and really cut down on angst all round even though we then took responsibility for platform support.
I don't blame the customer in these cases. The product shouldn't have been sold, or at least not sold with support, if the consumer was going deviate from build specs.
In my limited experience, this is the sales team saying 'anything' to get the sale.
Same here. I have been using PHP since it was publicly available after having used Perl for years (and even having written my own 'php' in perl before php; I did not know at the time that php was basically the same thing; a bunch of $source ~= s/(.)<\?(.)\?>(.*)/print $1;eval($2);print $1/isgm; kind of expressions) cgi-bin and even in heavy Windows shops end of the 90s, I have never seen it hosted on Windows.
I once seen a production server running a WordPress site on Windows.
The logic behind it was that the client had some other websites running on some .NET CMS (not .NET Core), so it made sense for them to run WordPress on the same one instead of getting another one.
Manufacturing Execution Systems run on Windows; when virtually all your servers are Windows because of the apps you need to run, setting up a few Linux servers for minor apps for internal use only is not worth, so PHP in fast-CGI more under IIS is a very simple and effective solution.
Having support people with good expertise on both Windows and Linux is expensive, having 2 separate teams in expensive (if you need high uptime), especially when the ratio Windows to Linux is just 10:1 or 20:1. Keep it simple, run PHP on Windows.
EDIT: I forgot to mention the pseudo-SSO called Windows Integrated Authentication that works with just a few clicks on Windows, probably a lot more key presses (typing) in Linux.
I have experience with using PHP on a Windows server, both with Apache and IIS.
With Apache, it's an unstable mess. IIS on the other hand works extremely well with PHP, we've had virtually 0 issues in more than 10 years using it for many different projects.
I dont think he is entirely wrong I had similar experience except in my case whether I used IIS or Apache with PHP didnt matter as much with my particular apps.
IIS is fine if it works just like Windows apps generally are fine when they work its the odd time where it breaks that you are mystified about the whole thing.
If I had to run a PHP app at work today, it'd be on Windows. Why? Because no one app justifies the amount of additional maintenance overhead of supporting an additional operating system. If your entire IT workflow is built on Windows, it's really the only sane choice.
And no, it probably wouldn't be WSL, it'd be using this. Because not everyone I work with is comfortable with Linux tooling and who knows if our management tools can see what's going on with it.
Wrong. When you have dozens of systems to manage that can all have security vulnerabilities, the less burden involved in keeping everything up to date and secure. Uniqueness breeds unique and unforeseen problems. (The modern way to describe this is to make servers like cattle, not pets.)
In a Windows environment, the best tool for the job is almost always another Windows box. Arguably, sure, PHP is a poor choice for a Windows environment, but IT/operations rarely has the luxury of deciding what line of business apps other departments use.
I do for several large projects.
But, I do not run IIS. Use Apache instead.
I have webservers running windows server, and databases servers on centos.
Main reasons familiarity started as a windows application developer, the gui in my case window explorer feels easier for the tasks that I need do.
I have setup webservers on linux as well, Just I work faster in windows can fix things easier then having to google with linux when things go wrong. I prefer the windows file permissions
WSL 1 was not a virtual machine. It was a re-implementation of the Linux kernel API within the Windows kernel. As such, it's probably more comparable to CoLinux (if that's still a thing).
It's not really about running linux applications as much as running your application in the same or similar environment to what you are ultimately deploying on.
I'm most curious about what happens to the official SqlServer drivers for PHP.
At work, we have an on-premise customer support application that relies on PHP being installable on Windows, and requires the official SqlServer drivers for PHP (since they are the ones that...work).
We have many customers on Windows infrastructure; PHP on Windows Server is definitely a real use-case.
So lacking a PHP option would definitely be an issue for us!
But also: In all of Microsoft, is PHP on Windows really just relying on one person????????
The beautiful thing about php is it might just work even without updates. There are quite a few extensions which are not updated for almost 10 years and they still work on newest php versions
Back when I was still coding PHP on Windows, I just used the XAMPP bundle to get the entire web stack up and running in minutes. Granted, that was 10 years ago, I'm neither coding PHP nor coding on Windows now, so I'm a bit out of the loop.
Surely I'm not the only person who has worked on PHP application that needed to stay running while it was being converted, piece by piece, to ASP.NET? Of course these days with dotnet Core this can all be done on Linux or the traffic routing can be trivially handled by nginx...
I'm trying to think of an answer to "We've got to do this on Windows!" but nothing realistic is coming to mind that doesn't involve legacy-ware that is over ten years old -- which is still beyond the scope of this general discussion.
Surely I would think that "PHP on Windows" going forward would be a feature delivered from WSL and not on Windows itself.
In my company some small internal web sites and simple apps run PHP on Windows; we always got the PHP zip from php.net and manually configured about 15 parameters to suit our needs, this was once per minor release, so about once a year (monthly updates did not need any config change).
I am using PHP for scripting anything that does not require an exe, but more complex than a batch file, it is the default scripting solution (I connect to SQL server a lot from these scripts).
Well, now that you can embed a Debian (or other) very easily, I guess it doesn’t make a lot of sense to continue compiling PHP for Windows ?
And there were always some traps (mostly because of the lack of case sensitive file names), so I feel it’s better to not use it anymore at all (the edge cases must be very low)
And most likely most Azure customers are already clicking the Linux option. So they can start wrapping support down. And a major version like PHP 8.0 is likely just the perfect moment.
If there was only one programming language to directly support, I guess this would not happen. But the landscape has changed (personally, I switched from php to python like 15 years ago).
If you read the next to mails, it seems they will still help, just not work directly to support it from Microsofts end.
Why does PHP need support from within Microsoft to be supported on Windows anyway? What I grasp from that email is that they support the development and build process in some way. Sure enough that could be done by someone else within the community. What's the fuss about?
> I don’t think Microsoft is doing anything that could not be technically done by somebody else.
This is generally true. PHP had Windows support early on and builds provided by community.
Having Microsoft backing it meant there were people with more time for it and some Windows-specific optimisation could be done, by people with access to true Windows experts. This gave a boost in the early days of their involvement.
>Sure enough that could be done by someone else within the community.
Sure, and usually in a hasty fashion, when they have time, understaffed, as is the case with many ports.
Instead, Microsoft wants this to be more high quality, to attract PHP devs to the platform and get PHP-based business on Azure/Windows, integrate it with their Windows dev tools, build goodwill etc, so they fund this and have some people working on it.
What does this actually mean? The PHP release engineer who replied didn’t make it sound like it was a major deal (of course, if it is a major deal, this may just have been an initial ACK statement).
Technologically it's not a big deal for developers who want to run PHP on Windows because WSL can do that. It might affect people who have, say, a .NET app running on Windows in Azure who wanted to put a Wordpress marketing site on the same server. As of PHP8 they'll have to either use an 'unofficial' PHP build for Windows or move the PHP site to a second server.
Politically though, it might be a big deal. Microsoft don't think supporting a native Windows build of PHP is worthwhile. That could say something about the server-side scripting language landscape changing. On the other hand, it might just say that it costs a few hundred thousand dollars of engineering time every year and they believe that could be allocated better. There's no way to know from a single post.
With WSL getting popular, between that and native build, there's two different versions of PHP to support on Windows in practice. And, given that WSL maps closer to production environments for most use cases, it's clear that it's the more important one.
As I understand it, it's not a major deal now that WSL (Windows Subsystem for Linux) means you can run Linux software natively within the Windows environment.
So, it's no longer necessary for PHP (or anything else Linux-y) to be natively supported on the Windows OS; anyone can just boot up WSL and run it there, where it will work better anyway.
I guess they also have know-how on how to do the Windows build now.
I remember before the windows.php.net day --- setting up PHP on Windows is much more of a mess that most people just use some kind of bundle (XAMPP, WAMP, etc)
For now, probably not much, not even for PHP on Windows. I guess someone else will compile it. It would be a bigger deal for the few who run PHP on Windows, if WinCache or the SQL Server driver were dropped.
* Used to run PHP on Windows, because $WORK had a tiny deployment that didn't need an extra server. In retrospect, getting a small cloud vm would have worked better, but letsencrypt wasn't around back then.
> With the new Linux subsystem, does Windows even need separate support for PHP anymore?
For Windows client, maybe not.
But some people run PHP on Windows Server in actual production scenarios (using either Apache or IIS) and those people absolutely need a native solution: WSL[2] has too much overhead.
SHOULD you be using PHP on Windows Server? Likely not, but it is more common than you'd think, I've personally worked at multiple companies that had a Wordpress based site running on IIS for example. This was pre-Cloud though so YMMV.
There's the UniServer https://www.uniformserver.com/ - a complete WAMP stack with quite a bit more, plus it is pre-hardened for use on the public web, ready for deployment and production. It's humorous how many WAMP developers work in public with their development hooks open, allowing outsiders to peer in and they are unaware. UniServer does not allow that.
The fact they haven't really updated their front page in years would make me nervous about using such a thing (PHP 5.6 came out 6 years ago and it reached EOL December 31st, 2018) and it took a closer look to see the project was still being updated with a new release just a couple months ago. I'm not trying to crap on the entire project, far from that! A more secure by default alternative to XAMPP/WampServer for Windows is great! But first impressions do matter.
This is incorrect. When creating an Azure App Service with PHP, you can choose either Linux or Windows. You would likely choose Windows if you needed to do things like execute Windows binaries as WebJobs.
Not Windows 10 but Windows Server is a server OS. Usage is probably declining but it's still in use in most companies somewhere for file storage, authentication (AD), databases (SQL Server) or even web servers.
Yep. We are forced to use it because we are a small company with a budget for one real server, and both our accounting and shipping management solutions are Windows-only. I'd wipe it and switch to Linux in a heartbeat if that weren't the case, as the only other functions the server handles are file storage and AD, both of which can be done on Linux.
You would be surprised about the number of Windows Servers out there. Yes Linux and other Unixes are the winners in the server space but there is a very significant amount of Windows servers in the wild.
What's the problem? At least the message for discontinuing PHP on Windows from version 8 going forward is clear and unambiguous. At the same time, WSL2 has made massive strides to bring Linux workloads to Windows in a way that doesn't require developers to handle all-too-well-known Windows compat issues (such as file names, file locking, CP/M era drive letters LOL). MS is only accepting the fact that, for most intents and purposes (except maybe MSO/sharepoint and other MS-only apps), almost all backend apps are developed for Linux or other Unix (but mostly Linux) anyway. I'd imagine many PHP and also Node.js apps won't work on Windows native OOTB anyway because of dependencies on Unix-like file conventions and third-party software, such as for running shell scripts. If you want to run popular PHP-based apps (like, idk, Magento), you buy into an ecosystem of "plugins" (such as for payments and delivery) and additional apps that usually work in a narrow setting anyway (for example, require config files at fixed or default locations), and trying to run these on Windows is the last thing you care about when setting up a shop and struggling to make it work at all in a best-practice way to avoid trouble or even liabilities going forward.
Seems like you could always run PHP on Windows without their help anyway. It’s just that if you trusted them and used PHP because Microsoft offered a supported version, too bad.
Dale from Microsoft is probably a busy person with a billion other things going on. He doesn't need to waste time elaborating on a subject that the PHP internals team are probably already pretty close to. You're not the audience.
If you have questions, you can feel free to email him though.
They are recommending a managed k8s cluster, although that k8s cluster can run "windows containers", but if the goal is "don't use aws" then they have to be pushing this way.
I am guessing you have not heard of .NET Core which has been running on Linux for a while. Not to mention Microsoft bought Xamarin which maintained Mono and mysteriously Mono was relicensed as MIT license. Though I am suspecting Mono might shut down given the amount of coverage towards consolidating all .NET platforms into just .NET with .NET 5.
Microsoft even fully embraced the community built package manager and they release important packages under it. You no longer need to upgrade your whole .NET platform (with some exceptions) just to use new packages from Microsoft that boost the ecosystem.
I have used .NET Core on both Ubuntu and Mac (which has its own Visual Studio - not Code) and it runs just the same.
I've worked on .NET Core services that ran in Ubuntu containers since the preview versions of .NET Core 2.0 (that was around spring/summer 2017) and since then .NET on Linux has been great. You get some config issues sometimes and weird use cases like if you use a closed and password protected 3rd party NuGet source, but it doesn't take that long to resolve those. I'm on a Mac nowadays and the same applies.
Package managers do not magically solve the problem of malicious programs, just as their big brothers, app stores, don't.
Of course you fully ignored the main point, which is that Linux protection features are completely out of sync with the needs of a modern single user desktop, being ballast instead of a benefit.
In response you seem to enter panic mode. Your last line even denies me reasoning, as if I can't have an argument unless an alternative exists.
So I guess you are exactly sensitive in the way I explained, presumptuously assuming Linux/Unix is the only true OS, employing the best minds, the winner. And more wishful and dangerous thinking like that.
The fact is Linux doesn't care about the user unless he is the sysadmin. Linux is the sysadmin wet dream. But you know what? People hate the sysadmin, and don't want to be one. They do not buy the gospel, and ultimately that is because Linux is an ideal not of this time and age. Linux is a castle, not a house, not a place to live in.
Linux was heavily inspired by Unix but it's not Unix in any sense.
Rest of Unix certified implementations are however not widely deployed. I don't see many AIX, Solaris production machines anywhere since everyone often deploys Linux instead.
Same story applies to *BSD family.
The only thing that keeps the Unix identity on those system is the Posix interface which is also extremely outdated on modern systems and it's kept around as a legacy.
Linux is Unix in the sense it implements most of the same core ideas in a similar way. The same applies to macOS, which is a layer of BSD on top of a Mach microkernel. All those systems have much more in common between themselves than anything else.
Key takeaway:
>This message means Microsoft aren't going to produce official builds for PHP 8 onwards.
>This message does NOT mean that nobody will.