Wouldn't it make more sense to leave things as they are until 5.3.0? That
will at least give John's msi some serious testing, and it looks very
promising indeed at present.
----- Original Message -----
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "'Steph Fox'" <[EMAIL PROTECTED]>; "'Rob Richards'"
<[EMAIL PROTECTED]>
Cc: "'Edin Kadribasic'" <[EMAIL PROTECTED]>; <internals@lists.php.net>
Sent: Saturday, September 02, 2006 5:48 PM
Subject: RE: [PHP-DEV] libxml2/threading/win 2003
We need to fix that then. And we might need to do something a bit smarter
for php5isapi.dll. I'll think about it but need to leave now for the
weekend. I don't think my explanation covered this issue but only the CGI.
I prefer trying to resolve the issues in a long term way than making the
wrong decision now re: bundling.
Andi
-----Original Message-----
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 8:34 AM
To: Andi Gutmans; 'Rob Richards'
Cc: 'Edin Kadribasic'; internals@lists.php.net
Subject: Re: [PHP-DEV] libxml2/threading/win 2003
Andi - the old msi didn't even install extensions.
The new one's still in beta.
----- Original Message -----
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "'Rob Richards'" <[EMAIL PROTECTED]>
Cc: "'Edin Kadribasic'" <[EMAIL PROTECTED]>; <internals@lists.php.net>
Sent: Saturday, September 02, 2006 5:33 PM
Subject: RE: [PHP-DEV] libxml2/threading/win 2003
> Yeah but Windows is very friendly and designed for this. As
long as the
> dlls
> are in the application's directory you will not have
problems. This is
> actually much easier and straightforward than on Linux so
it sounds to me
> that dll clashing problems (which doesn't happen in this
case) means that
> either the .zip or the .msi were just putting the dll not
in the right
> place. That's an easy fix.
>
> Seriously, if there's one thing that Windows is good at is
in a friendly
> dll
> search order. They designed it so that you can keep dlls
with the app.
>
>
>> -----Original Message-----
>> From: Rob Richards [mailto:[EMAIL PROTECTED]
>> Sent: Saturday, September 02, 2006 8:17 AM
>> To: Andi Gutmans
>> Cc: 'Edin Kadribasic'; internals@lists.php.net
>> Subject: Re: [PHP-DEV] libxml2/threading/win 2003
>>
>> I am on the fence one this one.
>>
>> Going the dll route makes my life easier by no longer needing
>> to maintain those builds, but will almost certainly increase
>> the number of bogus bugs to be chased down and cause the
>> windows installation to be more complicated again (Just doing
>> a search you can find tons of people having problems just
>> enabling extensions due to dll requirements).
>> Of course my personal opinion at this point would be to just
>> go the dll route because the burden gets put on someone else
>> then to deal with alot of the issues :)
>>
>> Andi Gutmans wrote:
>> > I don't understand what problems you mean. On the contrary,
>> statically
>> > linking in everything makes the system extremely unflexible and
>> > doesn't allow you to upgrade dlls without having to upgrade
>> the whole
>> > PHP build. If libxml2.dll is placed in the same directory as
>> > php5ts.dll I don't see where the problems would come from.
>> >
>> The problem from the user side always ends up being
>> installation and dll maintenance.
>> It is also quite possible that another module would load a
different
>> libxml2 dll, causing XML in PHP to operate differently
>> between running it cli vs under apache.
>> This also requires the iconv dll (assuming that would no
>> longer be statically linked either). It could also require
>> zlib depending up where they got their libxml2 dll from.
>> These were some of the things that statically linking libxml
>> eliminated.
>> > On Windows, performance also isn't impacted by dll vs. non-dll as
>> > you'll always have position dependent code and worst case
>> the linker
>> > will relocate the dll.
>> >
>> Performance issues never factored into the decision.
>> > I feel strongly that statically linking 3rd party
libraries and PHP
>> > extensions such as PDO into php5ts.dll will lead to more
>> problems due
>> > to lack of flexibility in people's install. It's a really
>> bad design
>> > decision and I just don't understand how this happened.
>> >
>> You don't remember the bundling war? It was eventually
>> removed I believe just due to the additional size.
>> The windows build really didn't matter because either the dll
>> needed to be distributed or it would be linked in statically.
>>
>> Rob
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> __________ NOD32 1.1380 (20060125) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
__________ NOD32 1.1380 (20060125) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
