Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:32677 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63595 invoked by uid 1010); 6 Oct 2007 18:13:35 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63579 invoked from network); 6 Oct 2007 18:13:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Oct 2007 18:13:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:52976] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B6/8B-26050-D40D7074 for ; Sat, 06 Oct 2007 14:13:34 -0400 Received: from MBOERGER-ZRH (unknown [216.239.45.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id E371F1B3654; Sat, 6 Oct 2007 20:13:25 +0200 (CEST) Date: Sat, 6 Oct 2007 20:13:21 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1319485978.20071006201321@marcus-boerger.de> To: "Andi Gutmans" CC: "William A. Rowe, Jr." , "Nuno Lopes" , "Pierre" , "PHP Internals List" , "Rob Richards" , "Frank M. Kromann" , "Edin Kadribasic" , "Dmitry Stogov" In-Reply-To: <698DE66518E7CA45812BD18E807866CEC12534@us-ex1.zend.net> References: <219701324.20071003170756@marcus-boerger.de> <019c01c80605$307c6140$4001a8c0@pc07653> <698DE66518E7CA45812BD18E807866CEC124AC@us-ex1.zend.net> <47042963.9090100@rowe-clan.net> <698DE66518E7CA45812BD18E807866CEC12534@us-ex1.zend.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] VS 2005 Support for 5.3? From: helly@php.net (Marcus Boerger) Hello Andi, as far as I heard from from MS that is the much better way anyhow. marcus Thursday, October 4, 2007, 5:43:55 AM, you wrote: > Another option which isn't always ideal is to use FastCGI and de-couple Apache and PHP. >> -----Original Message----- >> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] >> Sent: Wednesday, October 03, 2007 4:45 PM >> To: Andi Gutmans >> Cc: Nuno Lopes; Pierre; Marcus Boerger; PHP Internals List; Rob >> Richards; Frank M. Kromann; Edin Kadribasic; Dmitry Stogov >> Subject: Re: [PHP-DEV] VS 2005 Support for 5.3? >> >> Andi Gutmans wrote: >> > Although it may work for you with your applications unless all of >> your >> > 3rd party libs are compiled with VS 2005 there's a fair chance that >> > you'll have issues when data structures are passed between PHP which >> is >> > compiled against one CRT lib to DLLs which were compiled with older >> > versions (different size of structures, etc...) >> >> Or more to the point, localized resources that actually exist in one >> CRT >> which aren't visible to the other CRT. Faux-posix I/O that MS >> implements >> is a really good example of this. >> >> If you are building to Apache httpd binaries /as shipped by the ASF/, >> you >> will want to ship these in VC6 for the lifespan of httpd 2.0/2.2. As >> the >> corner turns over to httpd 2.4 sometime soon, there's a good chance >> that >> VS2005 will be picked up at that point (and stay there for it's >> lifetime). >> I doubt ASF will pick up VS2008 quickly, given the number of clib >> issues >> that occur in each iteration of the libraries. >> >> One trouble is that AS still ships Perl built on VC6 runtime, Python on >> the VS2003 runtime, etc etc. Until everyone can land on VS2005 at the >> same approximate time, it's a game of cat and mouse. >> >> [We won't go into the lack of wisdom of MS shipping yet-another-clib >> for each of their compiler versions.] >> >> If you just clean up the .pdb's to the point that they import cleanly, >> you can really keep everyone happy, today and tomorrow. When you ditch >> the .pdb's, it's no longer possible to export .mak build files at all >> for use outside of the studio-world. Best regards, Marcus