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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
