Microsoft gaat php 8 niet ondersteunen op Windows

Microsoft gaat php 8.0 en latere versies zelf niet ondersteunen op Windows. Volgens de release manager van php 8.0 betekent dat niet dat er straks helemaal geen php 8.0-builds voor Windows verschijnen.

Het schrappen van php-ondersteuning vanaf versie 8.0 wordt via de PHP Internals-mailinglijst gemeld door Dale Hirt, projectmanager voor php binnen Microsoft. Hij bericht dat de ondersteuning voor php 7.2 op Windows in november stopt en php 7.3 vanaf dat moment alleen nog maar beveiligingsupdates krijgt. Php 7.4 blijft nog een jaar lang zowel bugfixes als beveiligingsupdates ontvangen. Hirt: "We gaan echter voor versie 8.0 en verder php voor Windows op geen enkele manier ondersteunen." De definitieve release van php 8.0 staat voor 26 november dit jaar op de planning.

Sara Golemon, release manager van php 8.0, spreekt haar waardering uit voor het werk dat Microsoft tot nu toe verricht heeft, maar laat ook haar teleurstelling blijken. Op Reddit verduidelijkt ze dat Microsoft Windows.php.net bijhoudt en verantwoordelijk was voor onder andere php.exe op Windows. Die builds zijn dus niet meer te verwachten voor versie 8.0. Wel spreekt ze haar verwachting uit dat er een geautomatiseerde methode komt waarmee toch builds verschijnen, 'misschien zelfs door dezelfde mensen die de officiële builds bij Microsoft maakten'.

Microsoft begon in 2006 met de ondersteuning van php in Windows. Het bedrijf bood toen een module voor zijn Internet Information Server, of IIS, aan om webservers met php-clients te verbinden. De meeste ontwikkelaars bleven de voorkeur aan php op Linux geven. Binnen Windows 10 heeft Microsoft inmiddels Windows Subsystem for Linux 2 geïntegreerd, waar php-ontwikkelaars van gebruik kunnen maken.

Reacties (117)

[dennisameling]

Gebruik nu een aantal weken PHP binnen WSL2 in combinatie met DDEV (heb er een blogpost over geschreven). Het werkt echt extreem snel en soepel allemaal. Extra bonus van DDEV is dat je dynamisch, per project, kunt wisselen tussen PHP versies. Heel blij mee zo

[zenlord]

Extra bonus van DDEV is dat je dynamisch, per project, kunt wisselen tussen PHP versies. Heel blij mee zo

Onder linux kan dat ook zeer soepel: als je gebruik maakt van de Sury repo's, kan je alle PHP versies naast elkaar installeren en mix-en-matchen wanneer en hoe vaak je wilt.

[GrooV]

WSL is Linux binnen Windows

[eborn]

Of je kunt de versies in docker draaien. Voordeel is dat je dan ook per project je dependencies kunt specificeren c.q. builden.

[Anoniem: 1367158]

ik vraag me eigelek wel af waarom iemand ooit uit eigen beweging een windows server zou kiezen over linux (tenzij een klant natuurlijk betaalt VOOR ... )
ik volg dat allemaal niet zo erg want ik ben tenslotte ancient en kapot maar heeft de windows server dan een filesystem dat niet moet gedefragmenteerd worden net als ext (onder andere andere verschillen) ondertussen ?
dat alleen al ...

[Centurius]

Ieder systeem heeft zo z'n dingen. Binnen mijn eigen bedrijf gebruiken we voor de meeste diensten op Linux gebaseerde systemen, maar voor bijvoorbeeld mail is Exchange Server geweldig en een Windows Server exclusive. Ook is Active Directory een verademing als het gaat om accounts beheren (alleen al doordat bijna alles er ondersteuning voor heeft). En zo hebben genoeg bedrijven hun zaken die gewoon niet even goed draaien op Linux.

[robbinwehl]

Een samba4 server op linux kan heel goed je Windows AD vervangen.
Je kan zelfs via een Windows client je domein beheren ;-)

[Centurius]

Oh dat het kan absoluut, maar het is een stuk omslachtiger en als er iets misgaat is de support route een stuk lastiger dan om gewoon Active Directory in te zetten.

[Blazing-Studios]

En vooral kostbaarder in veel gevallen.
Linux is "gratis" maar support en configuratie kost je vaak vele malen meer dan op windows (totaal van verloren of extra benodigde uren, duurder personeel, etc).

Daarom is Linux onder de streep vaak nog steeds duurder en blijven veel bedrijven bij MS omdat daar veel (ook vaak gratis) Automagische software is die ook voor leken vaak goed te begrijpen is of een mooie interface heeft (hoe vaak ik wel niet een betere commandline tool heb zien verliezen van mooie GUI's met minder functies).

Ook is MS de laatste jaren enorm verbeterd, het integreren van WSL (zou LSW moeten heten overigens) is een voorbeeld daarvan maar ook de omarming van nix en opensource in hun cloudplatformen en powershell zelf wat vrijwel gelijk is aan bash (ja ik weet dat PS output behandeld als object en Bash als string maar nog steeds erg gelijk in werking en functionaliteit)

Ik doe zelf winnix dus either way I'm good

[DZaehM2]

Er kunnen allerhande legitieme redenen zijn waarom je zou kiezen voor een Windows Server. De belangrijkste vraag is: "Wat helpt het bedrijf?" Draait de applicatie op Linux? Zo ja, wordt het dan überhaupt wel ondersteund? Hebben de mensen die het systeem moeten ondersteunen voldoende kennis om een Linux systeem te beheren? Of moet er bij elk probleem een derde partij worden ingeschakeld? Welk service level kunnen zij dan garanderen?

Ikzelf beheer naast linux servers ook een heel aantal windows servers en heb sinds de komst van NTFS volgens mij nog nooit een server disk moeten defragmenteren...

[MichaelBelgium]

Goeie blogpost! Maar in principe heb je docker ook niet meer nodig als je WSL gebruikt

[dennisameling]

Klopt, je zou ook direct PHP/Apache/MySQL/etc. kunnen installeren op de distro('s) die je in WSL2 geïnstalleerd hebt. DDEV werkt met Docker images waar alles direct in zit, vandaar de requirement voor Docker

[biteMark]

Geeft dat niet veel overhead als je meer en meer servers gaat draaien? Misschien is het dan tijd voor een dedicated server, maar da's niet altijd de realiteit (dev machines bijvoorbeeld).

[dennisameling]

Valt op zich mee voor dev machines. Je kunt met de commando's "ddev start" en "ddev stop" per project de container starten of stoppen, dus er worden geen resources gebruikt als je niet actief aan het ontwikkelen bent op dat project.

Voor productie omgevingen zijn er inderdaad tal van andere oplossingen met minder overhead, daar zul je bijv. ook sneller eigen Dockerfiles maken die alleen het echte minimum bevatten om de applicatie in productie te draaien.

[bskibinski]

Docker is volgens mij om compleet andere redenen handig:
Als je aan veel websites met veel mensen moet werken, is het een handige tool om voor iedereen makkelijk en snel de juiste omgeving op te starten, zo hoeft een werknemer geen kennis te hebben van server instellingen (een frontender bv )

Was net van plan naar van wsl1 naar wsl2 te gaan, ik ga die blogpost zeker even goed doornemen, komt als geroepen!

[ktorfs]

Ik wacht nog om terug naar Windows te gaan (zit nu op Ubuntu) tot PhpStorm echt deftige ondersteuning gaat bieden voor WSL2. Ook nog geen deftige manier gevonden om GitKraken te laten draaien gezien je code op het Linux bestandssysteem moet staan.

Overigens ook hevige gebruiker van DDEV.

[Reactie gewijzigd door ktorfs op 24 juli 2024 18:44]

[bskibinski]

Ik gebruik phpstorm al met wsl1? Filesystem is wel traag in 1 als je je sites binnen Windows filesysteem hebt, maar dat zou beter moeten zijn in 2. Wat mis je precies?

[ktorfs]

De traagheid van het bestandsysteem is en blijft een enorm probleem (Symfony). Heb nu wel gisteren avond wat aan het experimenteren geweest met het draaien van een x11 server in Windows en dan PhpStorm en GitKraken zo vanop WSL starten. Dit lijkt (tot nu toe) wel enorm goed te werken.

[MrCuddles]

Misschien eens vscode proberen. Deze heeft uitmuntende ondersteuning voor WSL, Docker en grafische beheer over git

[djwice]

Dus eigenlijk blijft er Windows ondersteuning, alleen dan onder Windows Subsystem voor Linux
Netjes in een geïsoleerde container.

[Reactie gewijzigd door djwice op 24 juli 2024 18:44]

[TheNephilim]

Docker zowel op WSL2 en gewoon Hyper-V geprobeerd, maar die laatste is echt een stuk sneller. Heb jij dezelfde ervaring of heb je alleen ervaring met WSL2?

[dennisameling]

Bij mij is WSL2 een stuk sneller, maar wel alléén als ik alles binnen WSL2 doe (dus ook mijn repositories opslaan) en niet van het Windows bestandssysteem gebruik maak. Dit wordt door Microsoft zelf ook aangeraden: https://docs.microsoft.co...em-for-faster-performance

[TheNephilim]

Aha, dat zou ik nog eens kunnen bekijken, maar als ik zo de andere reacties lees is dat niet gemakkelijk met diverse Windows applicaties. Hier ook oa. PhpStorm en GitKraken in gebruik.

[Jan-E]

Ik heb in de PHP Internals mailinglist net een reactie gegeven (met een cc aan de brenger van het nieuws). Ik citeer die reactie maar volledig. Microsoft is bezig zichzelf in de voet te schieten.

This decision took me by surprise, to say the least. Microsoft's involvement in developing (thanks, Anatol) and building PHP for Windows was a huge boost for the PHP on Windows community.

I am building PHP for Windows myself, but I know from the questions I am getting that a lot of corporate customers of Microsoft are running PHP on Windows Server 2016 or 2019. They are only allowed to use the official binaries that are supplied on windows.php.net or pecl.php.net. These corporate customers surely will not be amused by dropping Microsoft's support for PHP 8.

Besides that, SMB customers are often using Microsoft Azure for their Windows Server needs. Windows Azure will loose a lot of selling points without supported PHP binaries. A quick search on Azure marketplace revealed as well that some Azure partners will also be left in the cold: https://azuremarketplace....e/apps?search=windows+php Are the Azure Sales people already informed about your decision?

Please rethink if your decision is really in line with Micrsoft's long term policy.

[Reactie gewijzigd door Jan-E op 24 juli 2024 18:44]

[thof]

Er staat in het artikel alleen dat Microsoft stopt met de php.exe binary. Dat hoeft niet in te houden dat Microsoft op Azure helemaal geen PHP meer ondersteund. Ik verwacht eerlijk gezegd dat Azure gewoon linux App Services aan blijft bieden met PHP. Zijn zelfs nog iets goedkoper ook. Zou mij ook niet verbazen als ze uiteindelijk PHP op Windows blijven ondersteunen op WSL2, welke ondertussen ook GA is.

https://docs.microsoft.co...containers/quickstart-php

[moppentappers]

Het is mij niet helemaal duidelijk of PHP nu wel of niet zal werken met PHP 8.0 of dat Microsoft geen Windows implementatie meer gaat maken omdat Windows subsystem for linux dat nu prima kan afhandelen.

[NoobishPro]

Microsoft: "We are not, however, going to be supporting PHP for Windows in any capacity for version 8.0 and beyond."

PHP is op windows een 'programma' en Microsoft maakte daar altijd 'builds' voor. (php.exe en mod_php7.dll bijvoorbeeld).

Microsoft zal geen nieuw 'programma' maken om PHP8.x en verder te steunen en laten het dus in principe over aan anderen.

Puntje bij paaltje stellen ze dat er weinig zal veranderen, omdat de verantwoordelijken voor de PHP-runtime bij Microsoft deze verantwoordelijkheid tot zich willen nemen. Er is echter nog te weinig over bekend. Komt later.

[lordsnow]

Dank NoobishPro. In tegenstelling tot het nieuwsbericht is dit wel duidelijk.

[Wolfos]

Microsoft gaat de ondersteuning voor PHP staken. Waarschijnlijk neemt een andere partij dit over.

[sebastienbo]

of even snel (subsysteem kan sommige operaties vertragen (berekeningen / IO file actions / trafiekburst / compression / encryption)

Het zou dus kunnen dat standaard algoritmes even snel gaan, maar schrijven en lezen naar bestanden traag (denk aan cookies of session files of andere dingen)

[Reactie gewijzigd door sebastienbo op 24 juli 2024 18:44]

[Cergorach]

Ik vraag me dan ook bijzonder af waarom je PHP direct op Windows wil draaien? Uiteindelijk draait dat toch op een niet-Windows server? Dus waarom niet meteen een VM die het betreffende OS/webserver draait. Die vreselijke Windows LAMP installaties maken imho meer stuk dan dat het oplevert!

[Memori]

Ik gebruik het om lokaal classes of snippets te schrijven en testen zonder tussenkomst van een browser of ftp client. Rechts-klik -> New -> Text file gevolgd door schrijven en een shift-rechts-klik -> open power shell -> php.exe script.php. Vaak kan je dit zelfs automatiseren in de tool waarin je werkt.

[BL3ND3D]

Dan zou je toch eens naar WSL moeten kijken. Ik werk zelf niet met PHP, maar ik weet zeker dat ik met een uurtje spelen dezelfde functionaliteit werkend heb die jij beschrijft.

[Memori]

Ik denk niet dat WSL het makkelijker maakt. Zonder ook maar iets te installeren kan je met php.exe scripts uitvoeren in de command line. Binnen een minuut kan je php.exe downloaden en beginnen.

[klakkie.57th]

Waarom zou je geen php onder IIS kunnen draaien wat volgens mij de enige door microsoft gesupporteerde webserver is

[HerrPino]

Nee Kestrel ondersteunen ze ook. Daar draaien .Net Core web applicaties standaard onder.

[kroegtijger]

Inderdaad. Gebruik ik al enige jaren tot volle tevredenheid. Scheelt heel veel in het opvoeden van collega's om met Linux om te kunnen gaan. Een IIS kunnen ze wel beheren, maar Linux hebben de meesten helaas weinig kaas van gegeten.

[Shamalamadindon]

*WAMP

De L in LAMP staat immers voor Linux

[Saven]

Php is tegenwoordig vrij volwassen en meer een programmeertaal dan dat het ooit was. Totaal niet te vergelijken met bijv. NodeJS

[Mellow Jack]

Oeh mijn opmerking ging niet over PHP als taal maar PHP op Windows. Zullen vast usecases voor zijn dus ik denk dat een andere partij het zal overnemen maar verwacht dat het overgrote deel gewoon op Linux draait en het DEV werk in een container wordt gedaan

[junkchaser]

Duidelijk dat jij niet bekend bent in de IT branche... Zou je beter moeten informeren alvorens dergelijke veronderstellingen te posten.

[mikesmit]

Wat betekent deze aankondiging voor ontwikkelaars nou eigenlijk? Het blijft toch gewoon mogelijk om een Apache testservertje op te zetten aangezien Microsoft het heeft over php ondersteuning in IIS?

[NoobishPro]

Ik geloof niet dat het zo simpel is, hoewel dit ook een bijzaak kan zijn.

Ik heb het al even niet meer onderzocht/bijgehouden, maar van wat ik begreep, is PHP 8.x de eerste echte compiled-language versie van PHP (experimentatie is er al in 7.4).

Dit wil dus zeggen dat je de code moet 'compilen', ofwel 'builden'. Of dit echt "moet" weet ik niet, maar gezien je dus inderdaad zal moeten wisselen naar Linux voor php8, ga je dit vast wel kunnen builden op je linux server en dan lijkt mij inderdaad het enige overgebleven probleem de IIS support te zijn.

Ik weet verder nog niet alle details van hoe het compilen van PHP in zijn werk gaat enzo, maar mogelijk kun je het vergelijken met hoe je apps voor IOS moet builden op een mac.

Van wat ik begreep wil PHP met de compiled language ook gaan draaien op apparaten i.p.v. enkel het web. Mogelijkheden zoals PHP-apps op je telefoon, tablet, laptop en pc zijn dan dus geen onmogelijkheden meer. Echter wel als Microsoft dit niet gaat supporten.

Edit:
Mijn gegeven informatie klopt niet (hoewel ik nog steeds geen idee heb hoe de compilation gaat werken).

Microsoft stopt simpelweg met de officiële support voor PHP op Windows, echter nemen de verantwoordelijken het op zichzelf om het door te zetten. Het zal enkel niet meer 'officieel' zijn.
-- Mogelijk zullen we extra software moeten installeren i.p.v. het direct via windows settings op te kunnen zetten.

[Reactie gewijzigd door NoobishPro op 24 juli 2024 18:44]

[Kenos]

Het gaat om een Just In Time compiler (JIT). Wat betekent dat je nog steeds geen compiled code verspreidt maar gewoon de source code. Tijdens het uitvoeren wordt het on the fly gecompileerd.

[NoobishPro]

Ah. De laatste keer dat ik er wat over hoorde waren de specifieke zaken nog niet bekend. Ik heb het zojuist opgezocht en het maakt mij best gelukkig dat ze PHP met JIT doen

Mijn eigen bedrijf draait een beetje om efficiëntie. Onze code draait al zo snel dat optimalisaties totaal niet nodig lijken te zijn, maar wij proberen "ons steentje bij te dragen" door zoveel mogelijk op zo min mogelijk servers te laten draaien... Dat is groen enzo.

Tot nu toe gaat dat al super (vrijwel al onze producten draaien op 3 hele kleine vps-jes) maar ik zie nu dat php 8 met JIT zeker zo'n 5 keer sneller kan zijn in bepaalde taken. Bizar!

Overigens doet mij dit wel een beetje denken aan het Phalcon framework. Deze deed precies dit; PHP vertalen naar machinetaal voor JIT -- Ik ben benieuwd of het Phalcon framework overbodig zal worden met PHP 8


Edit: Bij nader inzien gaat het voor mij waarschijnlijk weinig uitmaken. Mijn applicaties bestaan 99% van hun runtime uit requests e.d. zaken. Computations zijn nooit echt het probleem geweest... Maar ik kan me wel inbeelden dat dit enorm helpt met encyption/decyption times?

[Reactie gewijzigd door NoobishPro op 24 juli 2024 18:44]

[R4gnax]

ik kan me wel inbeelden dat dit enorm helpt met encyption/decyption times?

Encryption/decryption APIs bestaan wss al uit bindings naar native C libraries.

[Saven]

In principe heb je daar opcache voor die compileert het eigenlijk al voor je

[Mellow Jack]

PHP apps zijn altijd al mogelijk. Uiteindelijk is PHP volgens mij gewoon C++. Er zijn alleen niet zoveel GUI achtige libraries voor.

Edit, blijkbaar zijn er toch een paar die het doen haha https://www.sitepoint.com...latform-desktop-apps-php/

Offtopic, uiteindelijk kan je met elke taal vrijwel alles zolang iemand het maar heeft gemaakt (of het kan integreren in iets anders). Zo heb ik wel eens met een collega een PowerShell GUI app gemaakt. Waarom? Gewoon omdat het leuk was om te doen. Is het nuttig? Niet echt

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 18:44]

[sebastienbo]

Ik vraag mij ook af of dat subsysteem even performant is als rechtstreeks met OS kunnen spreken

Als het blijkt dat php bij sommige operaties daardoor 10 keer trager word, dan is dat niet meer te gebruiken door bedrijven voor hun sites te hosten op windows.
Dan moeten ze wel overschakelen naar linux

[bzzzt]

Er is dan ook geen echte usecase voor PHP waarvoor je het per se op Windows moet draaien.

Op Linux distributies is de 'kant en klare' LAMP configuratie doorgaans een variant op Apache met PHP en MySQL. Die is meestal 'out of the box' als bijna productie-ready geconfigureerd en kost de minste inspanning om te gebruiken.

Als je het Windows 'kant en klare' pakket wil (met bijbehorende licentiekosten) is dat IIS met een of andere .net integratie en evt. SQL server. Waarom zou je dan gaan lopen hobbyen met PHP op IIS?

[mikesmit]

Ik bedoelde het meer in de trant van even op je dev pc/laptop een lamp draaien om dingetjes te testen enzo. Niet een echte test server/productie server

Voor ontwikkelen werk ik liever op Windows met mijn ide naar keuze en vind het dat een beetje zonde om een VM te moeten draaien om dingetjes te testen of features uit te proberen

[Pendaco]

Daar kan je toch nog steeds gewoon iets als XAMPP, MAMP of Wampserver voor gebruiken?

[Thyrosis]

Dat is me nou nog niet helemaal duidelijk. Want kan dat straks wel nog steeds?

Die maken immers ook gebruik van een PHP.exe. Dus een Windows executable.

[Pendaco]

Die maken immers ook gebruik van een PHP.exe. Dus een Windows executable.

Ja goed punt. Daar had ik niet aan gedacht.

Wat ik her en der lees is dat deze partijen (of een andere partij) dan zelf wel de Windows versie zal compilen. Maargoed, dat moeten we eerst dan nog zien..

[mikesmit]

Maar dit was mijn oorspronkelijke vraag ook. Kan dit ook echt nog?

[wizzkizz]

Daarvoor heb je nu de keuze uit eigenlijk twee technieken: WSL2 en docker containers.

Die laatste maken vanaf de Windows versie 2004 onder water ook gebruik van WSL2 maar zijn perfect porteerbaar tussen een Windows en een Linux bak.

[Anoniem: 80910]

Zeker wel, indien je windows applicaties wilt uitvoeren met php, bijvoorbeeld photoshop dan heb je php op windows nodig

[HansvDr]

Wij doen het. .net, php klasieke asp allemaal op 1 systeem en op iis Kan prima.

[xFeverr]

Da's niet gek dat een LAMP configuratie doorgaans een variant op Apache webserver met PHP en MySQL is.

Dat is waar LAMP letterlijk voor staat: Linux + Apache + PHP + MySQL

[nrg]

LAPM?

[lilmonkey]

Je praat altijd via een subsystem, standaard is dat het Win32 subsystem.

Daarnaast is WSL native, en draait WSL2 zelfs op een echte Linux kernel.

[Titulanix]

Ik vrees toch wel dat enkele zeer Windows specifieke features slechter kunnen gaan werken of zelfs helemaal vervallen. Dan denk ik aan single sign on, fastcgi impersonation, de Microsoft sqlsrv extension, mogelijk zelfs de momenteel uitstekend werkende IIS integratie met php-cgi.exe.
Dit kan gaan weer tot gevolg hebben dat voor momenteel succesvol bij de overheid draaiende systemen het onderhoud niet wordt verlengd. Dan moeten die systemen geheel vervangen worden, wat toch wel zonde van publiek geld is.

[thof]

Even inhakend op je Single Sign On, op zich is een applicatie niet meer waardeloos als je alleen het authenticatie mechanisme iets aan moet passen. Windows Authentication voor SSO is meestal prima te vervangen door een token gebaseerde SSO oplossing (OAuth2, ADFS, of SAAS oplossingen zoals Auth0 etc.). Paar keer zo'n migratie gedaan voor legacy applicaties, is goed te doen.

[holoduke51]

ik ben zelf al jaar of 15 developer. Al lang geen PHP aangeraakt. Maar waarom zou je in godsnaam Windows als development platform willen gebruiken. Voor bepaalde c talen binnen visual studio begrijp ik wel. Maar windows heeft totaal geen handige tooling voor het managen van PHP, python, javascript en andere scripting talen.
op een linux of Mac omgeving werkt het echt 100x beter. Het gebrek aan een normale console. geen package management en nog veel meer. Ik begrijp het niet

[sjongenelen]

Hmm, Windows heeft daar flink slagen in gemaakt. Zelf gebruik ik heel graag visual studio, maar dat kost natuurlijk wel een hoop meer geld dan een open source IDE.

VS code heb ik geen werk ervaring mee, maar sinds containers zijn de dingen die je noemt eigenlijk geen issue meer.

Overigens ken ik niemand die professioneel en vrijwillig VS gebruikt voor PHP

[Reactie gewijzigd door sjongenelen op 24 juli 2024 18:44]

[DoubleDot]

Visual Studio Community is gewoon gratis hoor En voor de meesten zal deze genoeg functionaliteit aanbieden. https://visualstudio.microsoft.com/vs/compare/

[xFeverr]

Nou nou nou, ik gebruik Windows als development-omgeving. Sinds WSL heb ik geen Linux desktop meer aangeraakt.

Hoewel ik groot fan ben van bijvoorbeeld KDE, is mijn mening toch dat Windows als desktop OS vele malen beter is. Helaas zijn veel CLI tools beter op Linux. Maar zoals ik al zei: sinds WSL kunnen alle tools die ik wil gebruiken ook op Windows beschikbaar. Win-win dus!

[BL3ND3D]

In godsnaam? Er zijn talloze redenen. Ik moet zeggen dat ik veel developers om mij heen ook vrij trouw zie blijven aan een OS en de manier waarop ze het gebruiken. Ik heb de laatste 3 jaar meerdere development systemen gehad met Windows, Mac en Ubuntu. Ik investeer veel tijd in het vinden van het perfecte allround systeem (voor mij: development, machine learning, gaming, muziekproductie, 3d modeling, vector art, pixel art, cleane look OS). Dat vind ik op dit moment Windows.

Als linux/unix gebruiker ben ik uiteindelijk volledig geswitched naar Windows. Laten we voorop stellen dat Windows allerlei voordelen biedt tov bijvoorbeeld Ubuntu of MacOS. Lees: betere drivers op notebooks en veel meer compatible software dan Ubuntu. Batterij en trackpad op dezelfde hardware werken vele malen beter op Windows. En tov Mac: GPU gebruik voor machine learning en gaming, betaalbaar, aanpasbaarheid van hardware en keuze.

Ik develop 100% op Linux via WSL2. Docker draait nu op native Linux, denk tov Mac een stuk meer performant (zou ik moeten checken). GPU pass through komt later dit jaar. Windows Explorer integratie werkt naar behoren. Met VSCode werkt alles super goed. Ik attach VSCode aan een docker container die in WSL draait, waarin ik dan een python project debug via de vscode jupyter integratie. Super responsief allemaal. Ik moet bekennen dat ik Windows nu redelijk stevig heb gemod om minder bloat in de UI te hebben. Zo gebruik ik de native Explorer, maar heb ik met registery mods alle overbodige elementen weggehaald en gebruik ik een True dark theme, waardoor het er allemaal vrij Zen uitziet.

Ik gebruik VSCode voor al mijn development, dat is voornamelijk python en javascript. Maar een leuke bijkomstigheid is de zeer uitgebreide plug-in store. Even een LaTeX bestand aanpassen? In letterlijk 5 seconden is de bijbehorende plug-in gedownload, geïnstalleerd en heb je volledige syntax en completion support.

[Thyrosis]

Maar waarom zou je in godsnaam Windows als development platform willen gebruiken.

Heel simpel: omdat het werkt.

En het werkt in mijn ervaring een stuk soepeler dan op Linux. Met goeie WAMP software (ben sinds kort overgestapt op wamp.net - ideaal!) is het een kwestie van downloaden, installeren klaar.

Begrijp me niet verkeerd, ik heb niks tegen Linux. Beheer voldoende servers om me er goed een weg in te kunnen banen. Daarnaast heb ik voor mijn werk een aantal jaren op een Ubuntu en later Mint machine gewerkt. Maar als desktop-omgeving heeft het mij nog niet echt kunnen bekoren.

Je kunt natuurlijk op een aantal manieren werken. Lokaal een LAMP omgeving downloaden, dus sudo apt-get install lamp zeg maar. In zo'n geval zit je altijd te klooien met bestandsrechten. Want je moet zelf als user bestanden kunnen wijzigen en mappen kunnen aanmaken, maar de lokale webserver ook. Het opzetten van een omgeving op deze manier vergt dus al een stuk meer knowhow van hoe Linux op een user-niveau werkt.

In het gebruik van (remote) containers heb ik me nog niet verdiept. Dat moet zowel in Linux als in Windows kunnen, maar nog niet de noodzaak gehad om hier verder in te duiken.

Mijn desktopomgeving met VSCode als editor, GIT (en GitHub Desktop) voor versiebeheer, Composer en NPM als package-managers en Wamp.NET als webserver e.d. (inclusief SSL en lokale mailserver à la Mailtrap) draait als een zonnetje.

Dus, om even terug te komen op de oorspronkelijke vraag:

Maar waarom zou je in godsnaam Windows als development platform willen gebruiken.

Waarom zou je in godsnaam Windows NIET als development platform willen gebruiken?

[IIsnickerII]

Ik werk nu pas 3-4 jaar in het vak bij meerdere werkgevers, en nu bij mijn huidige werkgever gebruiken we uitsluitend windows voor PHP development. En eerlijk gezegt, WAMPP, PHPStorm en GitBash als combinatie van tools werken voor mij 100% prima, en ik heb nooit echt de haat begrepen want het is letterlijk plug-and-play. Nooit rare errors tegengekomen die veroorzaakt worden door WAMPP, en GitBash ondersteunt over het algemeen linux-like commands voor windows (zoals het gebruik van 'ls' in plaats van 'dir').

Er zal vast een goede reden zijn waarom ontwikkelaars liever voor Linux gaan dan Windows voor PHP development. Wellicht is het sneller, wellicht is het stabieler. Maar naar mijn ervaring is het beheren van een linux server over het algemeen meer hassle dan het installeren van 3 programma's op Windows. Het draait bij mij nu 2 jaar als dev omgeving, en heb er nog geen moment spijt van gehad.

Nu is het wel zo dat ik altijd een windows gebruiker ben geweest, en alleen linux ben gaan leren omdat dat voordelig is bij het zoeken naar werkgevers. Ik heb het vak op windows geleerd, en het werkt voor mij prima.

[lilmonkey]

Wat een onzin. Jouw informatie komt van 15 jaar geleden zo lijkt het.

[valvy]

Volgens mij niet echt een gemist aangezien je tegenwoordig Ubuntu uit de app store kan trekken. Snap ik wel waarom Microsoft se plug eruit haalt

[rko4u]

Ubuntu in de app store, dat draait dus op Windows Subsysteem voor Linux(WSL)

[1superheld]

Php op Linux werke ook vele malen beter dan php op Windows, vind dit geen gekke keuze.

Nu met wsl2 kunnen Windows developers dit ook eenvoudig tegen near native snelheid draaien.

[batjes]

Ik heb absoluut geen idee hoe dit de afgelopen jaren zat.

Maar toen Microsoft met PHP5 ergens de ondersteuning voor IIS serieus begon te nemen, won PHP het in ieder geval een tijdje op Windows in de benchmarks. De ondersteuning in IIS7 was lange tijd ook prima, en heb ik het naar alle tevredenheid gebruikt. Vanaf IIS8 is het wel een heel stuk minder geworden en ben ik zelf voor mijn paar hobby projectjes ook weer terug gegaan naar Debian. Al komt dit ook deels omdat het installeren van plugins/modules in IIS een hork is geworden.

[WhiteDog]

Voor een paar € euro per maand heb je een VPS, zelfs om gewoon te spelen of te leren is dat eenvoudiger dan lokaal lopen te prullen (en je code staat ook meteen online).

[skatebiker]

Lokaal prullen gaat prima, zolang je Linux of macOS gebruikt. Linux kan ook prima in een VirtualBox. Zelfs op Android kan het, je installeert de graits Termux app, waar een Linux subsystem onder Android draait. Ik heb dat en dat draait een complete webserver met PHP, Apache en MySQL. Prima als testserver te gebruiken.

[skrebbel]

Kom, Tweakers, hou eens op met onzin verspreiden. Dit is niet jullie gewoonlijke niveau.

Microsoft houdt per PHP 8.0 op met het maken van en publiceren Windows-builds van PHP 8. Dus vermoedelijk gaat iemand anders dat doen. Microsoft maakt ook geen Python builds of Java JRE builds of NodeJS builds oid - dat wordt allemaal door vrijwilligers, of iig door niet-Microsoft-medewerkers, gedaan. En toch werken die talen ook gewoon goed op Windows.

De kans dat PHP 8 niet zal werken op Windows is nagenoeg nul. Het nieuws hier is enkel dat Microsoft niet meer belooft te zullen zorgen dat het werkt op Windows.

[Jan-E]

Het gaat vermoedelijk wel wat verder dan dat. De afgelopen jaren was bijvoorbeeld Anatol Belski (weltling) de drijvende kracht achter de inhaalslag die PHP op Windows gemaakt heeft ten opzichte van PHP op *nix. Het was me al opgevallen dat hij de afgelopen maanden steeds minder actief werd. Vermoedelijk is hij niet meer vrijgesteld om full time aan PHP te werken.

Verder is het afwachten wat er gebeurt met de PHP 7.2+ Windows ontwikkelomgeving op https://github.com/microsoft/php-sdk-binary-tools
Groot voordeel van de builds op windows.php.net was ook dat die PGO optimized waren voor enkele populaire pakketten en dat op windows.php.net ook DLL's gebouwd werden voor Pecl extensies en libraries werden bijgehouden die je nodig hebt voor het compileren van de extensies. Na het wegvallen van Anatol komt het bijhouden van die zaken neer op 1 persoon: Christoph M. Becker (cmb69), release manager van PHP 7.3. Geen Microsoft employee, voor zover ik weet. Christoph doet ook nog eens het onderhoud van de repo's op https://github.com/winlibs/

Dat is een wankele basis, zeker als je bedenkt dat Christoph naar eigen zeggen weinig ontwikkelervaring had toen hij zich aanbood als Release Manager van PHP 7.3. Hij heeft zich wel heel snel ontwikkeld, maar de diepgravende kennis die Anatol had van Windows heeft hij nog niet.