On 11/05/16 12:53, François Laupretre wrote: > Le 11/05/2016 à 08:20, Christian Stoller a écrit : >>> -----Ursprüngliche Nachricht----- >>> Von: François Laupretre [mailto:franc...@php.net], Gesendet: >>> Dienstag, 10. Mai 2016 15:23 >>> >>> Please read and comment : >>> >>> https://wiki.php.net/rfc/load-ext-by-name >> Why not just naming them *.so on all platforms and removing the "php_" >> prefix on Windows? >> >> Apache modules on Windows also have the .so suffix. > > AFAIK, the 'php_' prefix is required on WIndows because, without it, > some extension file names would conflict with system DLLs. The only way > to unify names would be to add the php_ prefix everywhere. This is the > mechanism used by Apache, with the 'mod_' prefix. Unfortunately, PHP > started on Unix, where the prefix was not needed, and didn't want to > change the Unix behavior when Windows support was added. > > About the '.so' suffix, some systems don't use this as shared lib > suffix. HP-UX, for instance, uses '.sl', and others exist, like > '.dynlib'. On some systems, you cannot load a dynamic library if its > suffix is not the right one. So , '.so' is not usable everywhere.
One tends to forget the reason some decisions were made, and when prompted the reasons come back. It's the simple fact that windows will look in the path to see if it finds a copy of a 'library' which is the main problem here, and in my case it's finding copies of the gds32.dll which are the wrong format for the php_interbase.dll extension. I'm seeing the same problem with other third party clients, so in my book it is important to keep using the extension so one knows exactly which files are involved. But as I said I properly planned revamp of handling extensions does make sense? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
