RE: [INTERNALS-WIN] RE: Compilers, SDK support roadmap

[email protected] (Garrett Serack)
Newsgroups php.internals.win
Message-ID <689781C07FB27E458C58AC967E5444532EC72C23AD@NA-EXMSG-C113.redmond.corp.microsoft.com>
Sorry for joining the party late...

I think for the most part, I'm happy with the VC6/VC8 plan.

Before completely committing to that path, I think that we should review
a couple of quick thoughts I had about this over the weekend.

   1. The differences between VC8 and VC9 are pretty small--compared to
   well, any two other versions of VC.

   2. VC9 does provide the 'correct' environment, libraries, headers and
   whatnot for Server 2008. Code from other versions of VC obviously run
   on Server 2008, but VC9 includes support for new libraries and technology
   specifically for newer OSes.

   3. "Windows 7" will be a mid-band release, and significant kernel changes
   are not part of mid-band releases. VC9 will be the favored platform for
   this whole cycle, and the cycle next. And given Stephen Sinofski's
   desire to ship Windows releases ever two years, we can rely on that VC9
   will be the solidified platform for an extended period of time.

   4. The Windows SDK for Server 2008 (v6.1) does come with all the tools,
   and all are licensed for commercial use freely--including MASM, which for
   MASM 8.0 (if you want to use VC8), is a separate download, and even then
   the EULA is non-commercial -- a situation I'm trying to rectify.  With
   the 6.1 Windows SDK, it's a one-stop-shopping affair for compilers, code,
   libraries, and tools. (and it's one file!--rather than the 15 files for
   to download the previous version's offline install).

   Heck, even then you need Visual Studio 2005 Express, two SP's (one for VS
   and one for VS for Vista). the VC8 platform is a Tooling nightmare.  Oh,
   and don't install them  in the wrong order (like SDK then VS... no-worky)

   5. The stability of VC9 is pretty damn good. I know that a lot of product
   groups are relying on it, and the entire build of "Windows 7" is all using
   that right now.

   6. I can work with apache to go straight to VC9 for the same reasons. Really
   if it works on VC8, VC9 is not a problem.  Given that this is new territory
   anyway, maybe getting as close to the present is a good idea.  I'm working
   with the folks from Apache, and I can easily push for VC9 on the same basis.
   Frankly, this is probably far easier anyway.

   7. The tool model/layout for the 6.1 SDK is expected to be far more
   consistent going forward; so upgrading to the next SDK generation should be
   far easier.

Frankly, I'm now starting to lean to the VC6/VC9 model, with VC6 dropping post
5.3.  I really can't say that I see any VC9 adoption blockers, and it's
significantly easier to setup the build environment.

Garrett


-----Original Message-----
From: Pierre Joye [mailto:[email protected]]
Sent: Wednesday, July 16, 2008 7:35 AM
To: Elizabeth M Smith
Cc: [email protected]
Subject: Re: [INTERNALS-WIN] RE: Compilers, SDK support roadmap

hi!

On Wed, Jul 16, 2008 at 4:18 PM, Elizabeth M Smith
<[email protected]> wrote:
> If support is the issue, we can wait on 9, doesn't matter too much to me
> as long as VC6 starts the death march.
>
> However I think we need to NOT do any VC9 builds until VC6 builds are
> discontinued - supporting two compiler versions for a release will
> strain resources already.

Given than 5.3 is the last release to use VC6, it will certainly not
happen. The last line about VC8/9 (x86/x64) is what it seems to be
confusing. The idea here was to provide only VC8 and VC9 builds, not
VC6. But I'm 99.99% sure that we will have a 5.4, that will simply
kill VC6 sooner =).


> I'd say VC6 and VC8 "official" builds for 5.3, plus VC8-64 bit
> experimental builds (until they work well).

That's what my proposal says, good :)

> Then for PHP 5.4 or 6.0 (whichever comes first) kill off VC6 support and
> add VC9 and VC9-64bit.

Ditto

--
Pierre
http://blog.thepimp.net | http://www.libgd.org

--
Windows Internals Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.