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
