RE: [PHP-DEV] Windows build

Btw, one more thing which we could consider doing (although it means more work) is to do the nts build with VC 8 and the thread-safe build with VC 6. It'd probably require another machine (either physical or virtual). > -----Original Message----- > From: Andi Gutmans [mailto:andi@zend.com] > Sent: Saturday, January 06, 2007 6:20 PM > To: 'Edin Kadribasic' > Cc: 'PHP Internals List' > Subject: RE: [PHP-DEV] Windows build > > Hi Edin, > > The 2% surprises me a lot. We got very different results but > it might be due to different hardware, OS (we use Windows > Server 2003) and different tests. Here's what we got (all > non-threadsafe): > > vc2005 intel msvc6 > bench 9.326 9.378 10.28 > hello 10.48 11.6 11.28 > xoops 67.82 69.49 81.34 > static 16.97 18.4 21.18 > qdig 63.52 67.05 69.57 > qdig2 14.4 15.61 19.04 > > Btw, today I never recommend running mod_php on Windows and > always point people to CGI or existing FastCGI implementations. > That said, I understand that you don't want to break things > right now and stick to VC 6. Although I know it can work in > some cases, I agree with you that running two CRTs is > probably not a great idea. While the interfaces of the CRT > functions might be identical, I am not sure all the > structures are the same and that could cause some ugliness if > we get structs like file handlers from the Apache executable > passed into PHP and vice-versa. > > It's something worth looking into but not something one would > want to rush for a minor version like 5.2.1. > > Andi > > > -----Original Message----- > > From: Edin Kadribasic [mailto:edin@krug.dk] > > Sent: Saturday, January 06, 2007 1:28 PM > > To: Andi Gutmans > > Cc: 'PHP Internals List' > > Subject: Re: [PHP-DEV] Windows build > > > > Hi Andi, > > > > Turns out the problem is that Apache is building their > binaries using > > VC6 so wrong CRT gets loaded. The only solution I found was to tell > > Windows to load Apache with msvcr80.dll instead of msvcr.dll by > > suppling a manifest file in Apache bin directory. If you crate > > Apache.exe.manifest that contains: > > > > <?xml version='1.0' encoding='UTF-8' > > standalone='yes'?> <assembly > > xmlns='urn:schemas-microsoft-com:asm.v1' > > manifestVersion='1.0'> > > <dependency> > > <dependentAssembly> > > <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' > > version='8.0.50608.0' processorArchitecture='x86' > > publicKeyToken='1fc8b3b9a1e18e3b' /> > > </dependentAssembly> > > </dependency> > > </assembly> > > > > The Apache will load PHP and PHP will be able to load > extensions. It > > probably isn't good idea to force a different C Runtime on > Apache like > > this. > > > > Regarding performance, I found that on Zend/bench.php the > improvement > > was only marginal (2%) compared to huge increase > > (25-30%) when disabling thread support. > > > > http://edin.dk/archives/25-Benchmarks.html > > > > > > Edin > > > > > > > > Andi Gutmans wrote: > > > Hi Edin, > > > > > > Thanks for trying to get this to work! > > > > > > I think eventually it'll be the right move to go to VC8 > but I agree > > > that if it risks a successful 5.2.1 release then it might > > not be worth > > > doing that right now. If you can share with us a > > reproducing case we > > > can try and look into it and see if we can get it to work. > > So far we > > > have concentrated on CLI/CGI/FastCGi because that's the > > most feasible > > > way of running, but I agree that you also need to get the > > other methods to run. > > > > > > For those who are curious, there are some significant performance > > > improvements in VC8. Our tolower() optimization which is > > significant > > > is only for VC8, the compiler creates significantly > faster code (on > > > par with Intel C/C++ compiler), and I believe some of the CRT > > > functions like time() are also much faster. So I think it's > > definitely > > > worth upgrading but it should be well timed. > > > > > > Anyway, let us know and we'll try and dig deeper and help > get this > > > puppy ported and update the build. There probably is some > work that > > > needs to be done on the 3rd party libs. > > > > > > Thanks. > > > > > > Andi > > > > > >> -----Original Message----- > > >> From: Edin Kadribasic [mailto:edin@krug.dk] > > >> Sent: Friday, January 05, 2007 7:48 PM > > >> To: PHP Internals List > > >> Subject: [PHP-DEV] Windows build > > >> > > >> Hey, > > >> > > >> It seems that VC++ 8.0 (Visual Studio 2005) brings more > > trouble that > > >> its worth. Mainly the way it deals with the C runtime. > > After spending > > >> hours and hours of trying to figure out the way to make PHP work > > >> under Apache on Windows and be able to load extensions, > > I'm throwing > > >> in the towel. > > >> > > >> I can get PHP to work fine on the command line, both cgi > > and cli. It > > >> also works fine under IIS using fastcgi. But loading sapi > > dll into a > > >> webserver (not using php.exe or php-cgi.exe) works for the sapi > > >> itself, but trying to load any extensions via php.ini fails > > >> miserably. Sometimes you will get an error that the C > runtime was > > >> attempted to be loaded in an illegal way, sometime PHP > will claim > > >> that the extension does not exist, etc. > > >> > > >> I looked around at other projects and everyone seems to be > > using VC++ > > >> 6.0 for their builds (Active state, apache, ...) which > > eliminates all > > >> the hassle with bundling C runtime, etc. > > >> > > >> So I think the best thing for us would be to stick to the > > good old C > > >> compiler for making the Windows distro. > > >> > > >> Edin > > >> > > >> -- > > >> PHP Internals - PHP Runtime Development Mailing List To > > unsubscribe, > > >> visit: http://www.php.net/unsub.php > > >> > > > > >