Re: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.

Pierre Joye wrote:
> 
> Lua will go VC9, PHP is on its way, apache modules are compiled or can
> be compiled using the same CRT. I'm sure we can get perl to move as
> well somehow.

Lua goes as the user wants; there are some 12 build schemas around it.
I don't plan on shipping any of them (there will be an embedded lua in
the core distribution of httpd 2.4).  Even the contrib/ ones are hokey
(.bat file builds?  Get real).

Apache mods can be compiled, as you say, using whatever the user wants.
We have plans to fully support nmake -f makefile.win based on whatever
compiler tool chain the user wants, including studio 9.  (FWIW VC9 is
very very ancient, I don't think that's what you meant.  Studio 6 was
shipping with VC12).

I've had these conversations with ActiveState, don't expect things to
move rapidly for python and perl.  It's rather fits and spurts (I hadn't
even looked at their very latest builds, too many bugs in the perl 5.10.0
to even bother worrying it on win32).  Almost certain their last perl
release for amd64 binds to msvcrt (very forcefully, I might add --- they
have really made things difficult in source builds to NOT decouple
msvcrt and to actually use the msvcrXX of the week).

> This move is something we can manage for the easiness and stability of
> a wamp (or wamr) stack. Moving to VC9 does solve many issues that we
> can't solve with VC6, especially the CRT mess, the speed improvement
> and x64 support. The new manifests system will also greatly help with
> the CRT nightmare (manifests are supported in 2k5/8 or later, not 6).

What CRT mess are you solving with VC9?  Manifests solve nothing if you
have units of several different compiler results.  But I think most of
the projects now have the magic to compile in manifests as resources.

> We can and will talk with the VC team guys to figure out the best way
> to solve our requirements with a minimum pain for the users.

Sure, should continue those discussions, they've been ongoing for some
time.  But although the kernel and windows team rejected their approach
and they still don't see the light, I'm sure we'll convince them straight
away ;-)

> We can also help other projects to do the move. Either by providing
> build/snapshot support or by porting the softwares to VC9 when
> necessary. I did that already for many projects. They were all pretty
> happy to get some help, except a couple of projects which do not want
> to work with any VC version anyway.

If only I got to ignore those ;-P  Nope, I pretty much build everything
on VC whether the teams want the help or not.  If there is something you
would like me to help champion to the maintainers of a project that we
share an interest in, I'm happy to join you in prodding them.

>> OpenSSL project compiles to msvcrt from the modern compilers.
> 
> I compile openssl with any VC versions, for the record. It is
> available in our repository as well.

Of course, and I have no plans to use anyone's repository but OpenSSL's.

>> Until
>> Microsoft can grok the concept of modular development coming from
>> multiple parties (who don't share a single 'corporate direction' in
>> terms of the tools to use when and where), I'm afraid practically
>> speaking we can't follow the "wisdom" of the studio/c++ team.
>> I've broached this issue to them at Redmond, but I'm afraid all we
>> got were puzzled looks (you need to do what?!?  No company uses four
>> flavors of Visual Studio in the same finished binary.)
> 
> Well, it is not four, it is one, 2k8. The problem I have now is to
> have to deal with gcc 1.x, oops, wait, VC6 ;-).
> 
> All in all, the problem with CRT is the same than with libc. You can't
> use an app compiled with a a given libc or any other libraries on
> unix. However, if we prepare the move well, we can avoid further pains
> for the next years.

Uhm, what?  I have no problems using glibc 2.3 over a vast number of
linux revs, nor using solaris libc across three version majors.  You
are comparing to a tennis court to a football stadium.

Sorry if we disagree on the flavoring of the kool aid, but this stuff
has bitten me so many times, that I have reasonably little respect left
for the stupidity that can come from particular teams at MS.