Changes in Windows distributions [Was: Patch for generator - allow compiling against multiple gtk versions]

I think we'd better start putting this on-list...

Steph Fox wrote:

Hi Elizabeth, The CLI won't have any problems because the runtime's readily available on your system. But now they've dropped Win98 support in PHP I suppose that's going to be true for everyone that can run the latest PHP 5.2.*... the bigger concern is whether the PHP-GTK binary would clash with the official PHP distro, which I rather suspect it will. Did you try the NTS build? I guess we don't need threading here either. It might make sense to provide a copy of that CLI compiled under 2005 with the 'latest and best' download, and at least it'll be light. We're probably going to need to support Win98 longer than most PHP related projects, i.e. we'll need to do similar packages for both 5.2.0 release/VC6 (the last Win98-friendly version) and 5.2.+/VC8 (everybody else). Apart from sheer bulk, can you see any potential problems with that thought? - Steph ps I have a copy of 2005, but it's on a DVD and I don't have a way to load those just yet :-) Give it another couple of weeks and I'll have a new laptop to load it onto, theoretically at least - this one dies under the strain of running MS Word at present.

Actually that's a good idea. Distributing a VC6 build for Win98/ME and a VC8 build for NT/XP/Vista. As long as the manifests are packed properly you can use php extensions compiled with MSVC 2005 with a php compiled with MSVC6. Doesn't mean it won't magically crash somewhere along the road, but it does work. But I usually build snaps so I get all the

extensions I have headers for.    I have done non-thread-safe php builds, but right now the php-gtk windows build system is checking for the php5ts/php5ts_debug libs and I didn't bother changing it because I wasn't sure how the php-gtk code would react.  I can give it a try, might be a lot faster.

As far as light cli's, in fact I have a (very hacked) php5 build system at this point that allows libxml and iconv to compile shared - so I could build the extensions against the gtk versions of these dlls and keep the cli a lot lighter. - I'm only building in spl, reflection, tokenizer, date, standard, pcre and com so I can get really little .exe's :) I'm actually building with Visual C++ Express - which doesn't have the fancy profile guided optimizations, but otherwise it is the same compiler from the full version of msvc 2005. I suppose it's a question of whether you want to distribute specialized php binaries along with php-gtk2 dlls ... and then there's always the gtk runtimes.

Light CLIs sound like a good idea, but may not be... There are basically two sets of users here, one lot on Win98/ME who can no longer use new PHP binaries because PHP dropped support for their system following the PHP 5.2.0 release, and one lot on WinNT/XP/Vista who are capable of running new PHP binaries _and_ VC8 builds. However, the PHP distro is still built using VC6, so anyone loading VC8 extensions against it is going to be loading two sets of C runtime, and I think clashes are probably inevitable there. If we distribute PHP-GTK binaries compiled under VC8, we'd need to supply a VC8 PHP binary to prevent that possibility. For either compiler version, there's reportedly a 25-30% performance boost available from dropping the thread safety mechanism - which we don't use. If we're going to make NTS PHP binaries we'll need to know which extensions are used by PHP-GTK/win32 users, because the distributed .dlls from php.net and PECL won't run alongside those binaries. It's definitely worth doing this for the Win98/ME people, because they can't upgrade PHP and they don't have the option to load the VC8 runtime. I think it's worth retaining support for Win98 throughout the lifetime of PHP-GTK 2.0, along with a big fat warning that this will be the last series to support it, because I know people are running PHP-GTK under Win98. For those users, a built-in libxml and iconv makes perfect sense to me, but I'll check that with Rob Richards because he might know some good reason not to. My inclination would be to pack as much functionality as possible into the core rather than the other way around, though, because these specialist, NTS PHP 5.2.0 binaries won't run with the publicly available ZTS PECL 5.2.* binaries. The only way it's worth it for the rest is if we want to leap ahead of PHP and start distributing VC8 builds now, because it will make our official builds incompatible with the currently distributed PHP binaries (even the NTS ones). But we _do_ know it's on the cards for PHP to upgrade to VC8 very soon... so any work done in this direction won't ultimately go to waste, whatever the decision. Currently, NTS builds made available on php.net are built with VC6 and labelled as 'FastCGI optimized'. The question is how much user confusion this is going to cause when 'FastCGI optimized' switches to from VC6 to VC8... Perhaps we need to ask Edin what the chances are of his compiling those 'optimized' builds using VC8 rather than VC6, since they're post-5.2.0 anyway and rely on the OS rather than on Apache for their C runtime. On the bonus side, there is (or was - I haven't reviewed your patch yet, Elizabeth!) a compiler version test in the PHP-GTK build, so we can at least ensure that all PHP-GTK/win32 builds get the flags they need. - Steph

Thanks, Elizabeth Smith