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