Windows build

> Marcus Boerger wrote: >> Hello Ilia, >> >> weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind >> 6.0 long ago :-) > > For reference, ActiveState python is built on Studio 2003 al la 7.1, while > their perl is still built VC 6, if you are looking to coexist more peacefully > with one or the other.

> A last interesting question; what sort of headaches have you hit loading > within the ISAPI/IIS environment? I would presume that older/modern IIS > flavors suffer from similar headaches?

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

> Btw, today I never recommend running mod_php on Windows and always point > people to CGI or existing FastCGI implementations.