Software-update: Officiële release PHP 4.1.0

Hans liet weten dat PHP 4.1.0 vandaag is uitgebracht, en dit keer betreft het de officiële release . De developers beloven onder andere een sterk verbeterde performance, met name onder Windows. Verder zijn er een groot aantal bugfixes gepleegd en nieuwe functies toegevoegd. De pagina met de release notes en de changelog heeft een lengte van ongeveer twee kilometer en zal ik daarom achterwege laten, maar ik zou iedere actieve PHP devver willen aanbevelen om deze stof tot zich te nemen:

After a lengthy QA process, PHP 4.1.0 is finally out. Download at http://www.php.net/downloads.php !

PHP 4.1.0 includes several other key improvements:
• A new input interface for improved security (read below)
• Highly improved performance in general
• Revolutionary performance and stability improvements under Windows. The multithreaded server modules under Windows (ISAPI, Apache, etc.) perform as much as 30 times faster under load! We want to thank Brett Brewer and his team in Microsoft for working with us to improve PHP for Windows.
• Versioning support for extensions. Right now it's barely being used, but the infrastructure was put in place to support separate version numbers for different extensions. The negative side effect is that loading extensions that were built against old versions of PHP will now result in a crash, instead of in a nice clear message. Make sure you only use extensions built with PHP 4.1.0.
• Turn-key output compression support
• *LOTS* of fixes and new functions

As some of you may notice, this version is quite historical, as it's the first time in history we actually incremented the middle digit! The two key reasons for this unprecedented change were the new input interface, and the broken binary compatibility of modules due to the versioning support.

Versienummer	4.1.0
Besturingssystemen	Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, macOS, OS/2, Solaris, UNIX
Website	PHP.net
Download	http://www.php.net/downloads.php

Reacties (36)

[Jack Flushell]

We want to thank Brett Brewer and his team in Microsoft for working with us to improve PHP for Windows.

... waag het eens anti MS racties te posten

De makers spreken in de release notes meerdere malen van een historische release en dan vooral t.a.v. het Windows platform. Ik hoop dat het nu eindelijk eens duidelijk is dat ook onder Windows het mogelijk is programma's stabiel te krijgen. Ik ben benieuwd naar de reacties van mensen over een aantal weken, als ze deze nieuwe versie uitgebreid hebben getest op het Windows platform.

[SvMp]

Ik hoop dat het nu eindelijk eens duidelijk is dat ook onder Windows het mogelijk is programma's stabiel te krijgen

Dat is al duidelijk!
Dat veel open source programma's minder stabiel of minder ontwikkeld zijn heeft niets te maken met de kwaliteit van Windows, maar met het feit dat Windows geen Unix is. Die open source programma's worden bijna allemaal op en voor Unix-platformen ontwikkeld. Die Unices lijken allemaal ontzettend veel op elkaar vanuit het oogpunt van een programmeur. Daarom draaien ze allemaal keurig op Linux, FreeBSD, Solaris, AIX en ga zo maar even door. Een aantal van die programma's, waaronder PhP en Apache, kan echter ook gecompileerd worden op het Windows-platform. Het Windows-platform is toch wel een tikkeltje verschillend ten opzicht van de Unices, en heeft daarom veel extra aandacht nodig. Voorbeeld: Een Linux programma naar FreeBSD omzetten is veel minder (lees: in de meeste gevallen geen) werk, dan een Linux programa naar Windows omzetten.
Die Windows versies kosten een beetje meer tijd dus, want nadat er nieuwe features en bugfixes zijn gekomen in de Unix-versies, moet ook bepaalde Windows-afhankelike code bijgewerkt worden om het in de Windows-versie door te voeren.
Daarbij komt nog dat Windows de meeste open source programmeurs niet interesseert. Geen flame of zo, maar de gemiddelde open source programmeur zweert bij Unix.
Die factoren tezamen maken dat in de regel de Windows port van een open source product wat minder ver ontwikkeld en stabiel is.

[Jack Flushell]

Dat weet ik m'n jongen. En daarom is het mooi dat die extra aandacht nu eens wordt omgezet in iets stabiels voor windows. Het kán dus wel, met meer moeite welliswaar.

Aan de andere kant... (geen aanval op jou overigens) ALS open-source programatuur primair voor Windows zou worden geschreven (wat door allerlei niet nader te noemen redenen niet gebeurd, puur hypotetisch dus), zou alles op het Windows platform sneller goed draaien dan op de Unices.

[EfBe]

Dat weet ik m'n jongen. En daarom is het mooi dat die extra aandacht nu eens wordt omgezet in iets stabiels voor windows. Het kán dus wel, met meer moeite welliswaar.

Niet met 'MEER' moeite, maar gewoon door de docs te lezen. Veelal denken unix-focussed developers dat win32 precies zo werkt en gaan hun software voor win32 ook zo opzetten. Wat niet gaat, want win32 werkt anders. Met alle gevolgen van dien. Omgekeerd is het precies hetzelfde: een win32 developer die op Unix als een win32 developer te werk gaat zal slecht werkende software opleveren. Al wat men moet doen is de kenmerken van het targetplatform tot zich nemen en dan overgaan tot het bouwen van software volgens die kenmerken. Dat kost op win32 echt niet MEER moeite dan op Unix.

Wat ook niet MEER moeite kost is het stabiel te laten draaien. Microsoft heeft meer dan 1.7 gigabyte (!) aan informatie online staan in de MSDN library omtrent win32 development. Veelal leest men echter nauwelijks iets, denkt men niet als een win32 developer en is men boos op Microsoft als het resultaat niet naar behoren werkt.

_DAT_ is de reden waarom veel van Unix geporte software niet goed draait op windows. Wat logisch is, want in-depth kennis hebben van 2 platforms is een hele opgave. Dus grijpt men vaak terug naar het middel: anderen porten de spullen naar platform ABC. Maar die personen hebben vaak geen indepth kennis van de tool zelf. Waardoor je weer scheve verhoudingen krijgt mbt de functionaliteit van de tool op verschillende platforms.

Neem PHP. PHP is niet een taal met een COM interface, maar een ISAPI extensie. Was het een taal met een COM interface geworden (zoals VBScript, JScript, Embedded Perl etc) dan had je het in ASP kunnen hangen en was je in 1 keer klaar geweest. Nu is er op win32 een nieuw framework ala ASP gebouwd, in de vorm van een ISAPI (niet het simpelste werk), met daarin slechts 1 taal: PHP zelf. Sterker: met een COM based scriptparser had je PHP ook kunnen gebruiken voor ALLE scripting in het OS, dus ook voor OS specifieke zaken zoals systeembeheer/control/software installatie etc etc.

Wie doet er nu moeilijk: windows/Microsoft of de PHP developers? No offence, maar ik denk echt de laatste. Dat het dan moeite kost die ISAPI van de grond te krijgen met Unix focussed developers is niet vreemd: ISAPI is een complex iets (wat gelukkig wordt verbeterd met ATL server) waar je eigenlijk je handen niet aan wilt branden, laat staan wanneer je niet native win32 developer bent.

[SvMp]

Aan de andere kant... (geen aanval op jou overigens) ALS open-source programatuur primair voor Windows zou worden geschreven (wat door allerlei niet nader te noemen redenen niet gebeurd, puur hypotetisch dus), zou alles op het Windows platform sneller goed draaien dan op de Unices.

Natuurlijk, want dan is de situatie gewoon omgekeerd

[SvMp]

Wie doet er nu moeilijk: windows/Microsoft of de PHP developers? No offence, maar ik denk echt de laatste. Dat het dan moeite kost die ISAPI van de grond te krijgen met Unix focussed developers is niet vreemd: ISAPI is een complex iets (wat gelukkig wordt verbeterd met ATL server) waar je eigenlijk je handen niet aan wilt branden, laat staan wanneer je niet native win32 developer bent.

Ik ben het niet met je eens dat de PHP-developers moeilijk doen.
Waarom zeg je zelf al: Het is lastig als Unix minded developer om een goed win32 product van de grond te krijgen.
Oa. PHP en veel andere open source programma zijn gericht op Unix, en enkelen draaien ook op Windows, maar dat heeft lang zo'n grote prioriteit niet.

Microsoft heeft met MSDN inderdaad zeer veel info online staan, maar over Unix zal dat ongetwijveld nog meer zijn. Alleen het staat niet op 1 site, maar verspreid over tig sites. Op de Gnome site vind je bijvoorbeeld alles over GTK/Gnome, maar dat is maar een klein stukje.

[wzzrd]

Het is natuurlijk heel lief van M$ om te helpen PHP stabieler te maken etc. onder Windows. Met name als je kijkt naar het feit dat PHP dé grote concurrent van ASP is.
Aan de andere kant, moet je er wél rekening mee houden dat voor het ontwikkelen van stabiele en snelle open source scripting voor M$ OS, toch weer de hulp (en dus de source) van M$ zelf nodig was. Dat geeft natuulijk niet, maar het bewijst wel 2 dingen: ten eerste dat als M$ zijn source aan wat meer developers zou vrijgeven (nier per sé open source devs), windows i.h. algemeen sneller en stabieler zou lopen. Ten tweede dat dit niets zegt over PHP 5, of Apache (om maar wat te noemen). Je hebt dus telkens mensen van M$ nodig om dit te regelen...

[EfBe]

Waar staat dat ze de source van windows nodig hadden om het stabiel te krijgen? Of inside info omtrent vermeende geheime NT API's ?

Nergens.

Zou het wellicht zo kunnen zijn dat MS ze heeft geholpen met het wijzen op informatie HOE je het beste je scripting engine in win32 kunt hangen? (bv door het een COM interface te geven? ) Of is dat tegen je complottheorie waarin een monopolist iedereen kapot maakt?

Lees eens wat info omtrent Win32 software development, wellicht laat je de volgende keer achterwege hier poep te praten.

Verder is PHP geen concurrent van ASP, omdat ASP een framework is en PHP een scripting engine, plus ASP veelal gebruikt wordt i.c.m. COM components, terwijl men in PHP alles in PHP schrijft.

[wzzrd]

Net zoals jij, Otis, mag ik hier mijn mening geven. Als jij daar niet op een normale manier op kunt reageren, zeg dan niks.
Jij zegt wat je DENKT dat er gebeurt (staat namelijk niets over in de changelog), ik zeg wat ik DENK. Daar is een reactie systeem voor.
Jij zegt dat het niets te maken heeft met de source, ik zeg van wel (misschien wel indirect, maar toch). Ik zeg niet dat ze de source gekregen hebben, misschien heeft M$ alleen wat dingen gezegd over COM elementen. Misschien wel niet.
En dan nog: wat vind je nou zelf, heeft het NIETS te maken met de manier waarop Windows is geprogrammeerd, de manier waarop het in elkaar zit? (met de programma code dus?) Okay, jij je zin. Ik vind van wel.
Goed, was het niet juist om te zeggen dat het over de source van windows ging, maar mijn punt blijft staan: het is blijkbaar erg moeilijk te ontwikkelen voor Windows...

Tenslotte: ik zeg dit helemaal niet om M$ te flamen. Ik zeg dit, omdat ik denk dat IEDEREEN beter wordt van meer openheid. Desalniettemin vind ik deze ontwikkeling erg positief.

PS. Dat ASP iets anders DOET wil niet zeggen dat het door veel mensen niet voor hetzelfde DOEL wordt gebruikt als PHP. Dat ASP op een andere manier gebruikt KAN worden wil niet zeggen dat iedereen dat doet... Ik vind het dus wel concurrenten van elkaar.

[Verwijderd]

Ik zou niet durven

[EfBe]

$_COOKIE - contains HTTP cookie variables
$_SERVER - contains server variables (e.g., REMOTE_ADDR)
$_REQUEST - a merge of the GET variables, POST variables and Cookie variables.
In other words - all the information that is coming from the user,
and that from a security point of view, cannot be trusted.
$_SESSION - contains HTTP variables registered by the session module

... waar KEN ik deze dingen toch van?

[Johannes]

Geen idee? Naja, ik vind het niet zo'n geweldige verbetering. Ik had nu namelijk altijd al register_globals uit staan, en dan gebruikte ik een functie waarmee ik zelf gewoon aangaf welke vars er door mochten, en die zette ik dan uit HTTP_*_VARS naar de global scope. Hierdoor had ik eigenlijk geen problemen meer met beveiliging. Je moet natuurlijk nog steeds wel die vars nachecken, maar dat is heel wat simpeler dan alle vars.

[EfBe]

ASP heeft build in objects die net zo heten en net zo werken .

[Johannes]

- Removed the sablotron extension in favor of the new XSLT extension.

Iemand enig idee welke XSLT extension dit is? Ik kna het nog niet in de manual vinden. Xalan misschien?

[nospam]

Denk het niet. Xalan is meer bedoelt om samen te werken met Xerces, en niet met Expat...

[Johannes]

Ik heb nog ff wat beter rondgekeken, en er is veel info over te vinden in de dir php4/ext/xslt. Het is dus een generieke interface geworden die meerdere XSLT processors kan ondersteunen. Sablotron wordt nog wel als standaard meegeleverd, en kan dus ook gebruikt worden door middel van de nieuwe interface.

Therefore, I've created a processor independent api for XSLT, aka, the XSLT extension (but doesn't "A processor independent API for XSLT" sound cooler?). It defines a set of functions which every XSLT backend must provide, as well as a syntax which those functions must adhere to. Furthermore, the underlying code, provides a "library" if you will, of code that is relevant to all XSLT extensions.

[Verwijderd]

Deze versie is anders dan de versie die een paar weken? terug hier stond:

Nieuw:
root@uranium:/usr/local/src# md5sum php-4.1.0.tar.gz
4c2bfcc3cfc0b5b49d855316d78a3afc php-4.1.0.tar.gz

Oud:
root@uranium:/usr/local/src# md5sum php/php-4.1.0.tar.gz
0b46ba4e45de7242400f2215c1b869e0 php/php-4.1.0.tar.gz<div class=r>[Reaktie gewijzigd door [Felix]]</div><!-- end -->

[_JGC_]

Ja, die van vorige week was een uitgelekte versie die uiteindelijk de laatste RC is geworden. Zaten nml wat bugs in bleek later.

[Dryw.Filtiarn]

Ieamand een spiegeltje? Aangezien php.net redelijk uit de lucht is na deze release.

[Verwijderd]

http://php.mirror.widexs.nl/downloads.php

[NeoReY]

Er zit in deze versie een zeer irritante bug bij het uitlezen van files.

De functie is_readable returned een error wanneer een file niet bestaat. Vrij irritant wanneer je files uitleest en die functie veel in je code hebt staan.... ben dus maar weer naar 4.0.6 terug gegaan.

Dit gebeurde bij mij trouwens onder Suse Linux 7.2

Bug is inmiddels ook bekend bij PHP.net

[Verwijderd]

gewoon een @ teken voor je functie plaatsen en het probleem is opgelost ..

(dus @is_readable($file), dit werkt ook bij is_file en is_directory etc.)

checken met file_exists() levert geen foutmeldingen op.

[GdeKeijzer]

hmm 4.1 Windows Binaries zie ik anders niet staan.

tja... als je even op www.php.net kijkt...

Windows binaries will be available in a few days.

tja... waarom zou die er dan nog niet zijn

[0siris]

Het over een paar dagen verkrijgbaar zijn van een windowsversie zegt niets over een reden of oorzaak van het uitblijven van een windowsversie in het heden.

[Verwijderd]

Wel euh... het is "uit" maar het staat nog niet op de page om te downloaden? (enkel de source dan)

Vreemd?

[OxiMoron]

idd..
en heb niet veel zin om het zelf allemaal te moeten doen

zelfs met een beetje link-hacken is ie er niet

[Tom]

Link-hacken? heb ik iets gemist?

[DAzN]

Ben geen echte *devver*, maar mijn squirrelmail werkte niet meer bij de on-officiele release. Ligt dat aan mij of zijn er toch enkele functies veranderd.

<edit: typo>

[_JGC_]

Heb em inmiddels draaien, maar de Zend Optimiser doet het niet meer

Heb ik dus een nieuwe versie voor nodig, en het enige wat ik krijg van Zend zijn 0 byte files.
Iemand die Zend Optimiser al heeft voor PHP 4.10?

edit:

Inmiddels gedownload en Zend Optimiser draait weer, was ff een tijdelijk probleempje bij Zend