An interview with Microsoft's new Visual C++ Architect Stanley Lippman

Stanley Lippman has a long history with the C++ language and
the C++ community in general. He was one of the first users and implementers of
C++, he worked under
Bjarne Stroustrup at the Bell Laboratories Foundation Project, was the principal software engineer at Walt
Disney Feature Animation and has written a number popular titles such as the
C++ Primer.

Stanley recently joined Microsoft as the Architect for
Visual C++ so I caught up with him to have a chat on what he sees as the past,
present and future of Visual C++, and what his own personal goals are for
Visual C++. First and foremost my aim was to provide a definitive answer as to
what's in store for us C++ developers. Many of us are wondering whether or not our
skillset will remain valuable in a .NET world. Will C++ be relegated to win32
development? Will Microsoft make good on it's promise to pursue C++ compliance?

It’s important to remember that Stanley is the architect for the Visual C++
language - and new to the job - and so libraries such as MFC, ATL, WTL, and tool
such as Visual Studio are outside Stanley’s role sphere of influence and experience.
The interview therefor concentrated on the questions that most developers
have been asking: What is the future of Visual C++.

Firstly I asked
Stan what it was that attracted him to work for Microsoft.

Stanley's background is in Unix, and he's developed against many
different platforms. Obviously some platforms are easier than others. When it came
to .NET Stanley absolutely loved the concepts behind it. “The framework is amazing,
rich and interesting.” Stanley has worked on platforms where even simple concepts such as threading are intensely painful to
get working, so having a comprehensive Base Class Library that provides you
with such things as a comprehensive threading model that can be accessed using any
.NET language of your choice is very important.

Stanley initially had only limited notions of where Visual C++ fitted into the .NET
picture, but once he investigated further he was pleasantly surprised when he realized that
C++ was not left out of .NET, but was in fact a first class .NET language.

So what do you see as the future of Visual C++, and as the new Architect what are your goals?

Stanley is very clear on the future: “I believe Visual C++
has a prosperous future”. He has met the Visual C++ team and says they have
undeniable enthusiasm and energy. His goal is very simple: “I want Visual C++
to be the C++ implementation of choice”. Stanley’s personal goal is to
have C++ developers choose Visual C++ not only because of the tools and
platform, but because it’s the premier implementation of the C++ standard.

Compiler compliance

In terms of C++ compliance Stanley admits that the latest release
(Visual C++ 7.0) isn’t quite there, but the substantial work that has been
carried out on the underlying implementation means that moving towards a more
comprehensively compliant implementation is within reach. He’ll be pushing
forward with compliance especially in the area of templates.

Even
though Visual C++ 7.0 does not have the full range of features that Stanley
would like to see implemented, he says it is still by far the most compliant
implementation of C++ that Microsoft have released. It’s not 100% perfect, but
it’s still an excellent compiler with high compliance to the standards. Areas that still have issues are fully
documented in the VS.NET documentation in the article titled "Standard
Compliance Issues in Visual C++".

Microsoft’s
goal is to have a ‘competitively compliant’ compiler – meaning it won’t be 100%
compliant. There are a couple of features of the ANSI/ISO standard (for
instance the ‘export’ keyword as applied to template classes) that won’t be
implemented because they are considered by Microsoft to be obscure and, at this
stage, theoretical. Microsoft is however working to ensure that Visual
C++ will compile the most popular libraries such as Boost, Blitz, Loki and a
fully compliant version of STL. The emphasis is on a level of compliance that
allows popular libraries to be compiled, not 100% compliance.

Nick
Hodapp, Microsoft’s C++ Product Manager also added that while high compliance
is definitely a very important goal Microsoft will not sacrifice code-generation quality or
robustness at the cost of extreme compliance. However in recent lab tests they
are still beating several popular compilers on conformance tests.

When will we see the next version?

Stanley
laughs and says if it were up to him he’d email out updates each week, but
there are pesky things like quality control and processes that must be adhered
to in anything as complex as Visual C++. With the latest version to be released
around February 2002 he would like to see an update for the compiler late the
same year, but is unsure as to whether that is possible. He’ll certainly be
fighting for an early update. Nick Hodapp backs this up by saying that it’s extremely likely that an update to
VC7 will be available next year. Microsoft are investigating the best mechanism
to release a compiler refresh next year that would focus on compliance
features.

Many C++
developers feel that Microsoft is relegating Visual C++ to the sideline in
favour of the newer languages such as C#.

Stanley wants C++ to be far more a part of .NET than it is
currently. At the moment the biggest benefit of managed C++ is as a
transitional language. You are able to move your native apps into the .NET
framework or consume .NET components within your native applications, but it’s
not quite the language of choice for developing fully managed applications.

For the pending release of Visual
C++ .NET (VC7) Microsoft focused on enabling interop features. VC7 has the best interop scenarios of all the
managed languages and includes the ability to have both managed and unmanaged
code in the same image. They also
focused on enabling optimization technology on the generated MSIL - the result
is that VC7 is the only compiler to generate optimized MSIL. In future releases Microsoft will focus on
ANSI/ISO conformance (enabling many more features for both managed/unmanaged
code), as well as features that will give Visual C++ feature parity with C# -
WinForms, for example. Visual C++ will
be positioned as the power-systems language for .NET.

Template
support and generic programming are a must and Microsoft are very keen to implement codeDOM
support, both for ASP.NET and WinForms. With these added features Stanley
sees Visual C++ as being the power programmers language of choice for
the .NET framework - to compliment it’s current role as the language of choice
in unmanaged development. Even without the template support that is currently
being pursued Stanley sees Visual C++ as the only language suitable for those
who need more than C# or VB.NET can offer.

Stanley went on to congratulate Microsoft for shifting
away from being corporate oriented and moving towards being a more
developer-centric organization. To this end he will be pushing even more to
open up the company to developers and would like to see Microsoft to be even
more responsive to the developer community. Microsoft is renowned for pushing
ahead with innovation but there can be dangers in moving too far head of not
only standards, but also developer’s needs. Stanley will be pushing to ensure
that Microsoft listens more to what the developer community has to say while
ensuring higher standards compliance.

New features such as those in the C99 specification

On the topic of extending Visual C++ to embrace the new
features found in the C99 specification Stanley stated that these are issues
for the relevant Standards bodies. There is growing concern that a rift is
developing between C and C++, with C++ no longer being a superset of the
former. Microsoft’s aim is to have the most standards compliant implementation
so if the C++ standard is updated to include new features then Microsoft will
work towards implementing them in Visual C++.

Microsoft’s approach to adding new
features is whether those features are

being
used in code that other compilers can build, or

whether
those features are compelling enough that it becomes apparent that their customers want them.

Microsoft will not simply implement
features because they are specified in the standard. They will implement them when people want them because they are
beneficial.

The Message for us?

The message is that Visual C++ is definitely alive and kicking and has a very
bright future in the .NET world. Stanley's aim is to have the compiler at
a point where it’s the benchmark against which all other compilers are compared
– in terms of simplicity, fun factor and conformance. It should be easy to use,
versatile, enjoyable, and it should be what developers think of whenever they
think C++. Continuing improvements in C++ compliance along with future support
for ASP.NET and WinForms will ensure that Visual C++ be the power language for .NET
and for native development.

As to the question of whether developers will move to C# instead of managed
C++ Stanley thinks there will be more of a move from VB to C# than C++ to C#.
C++ is the better, more versatile and the only optimised compiler available in
.NET.

Share

About the Author

Chris is the Co-founder, Administrator, Architect, Chief Editor and Shameless Hack who wrote and runs The Code Project. He's been programming since 1988 while pretending to be, in various guises, an astrophysicist, mathematician, physicist, hydrologist, geomorphologist, defence intelligence researcher and then, when all that got a bit rough on the nerves, a web developer. He is a Microsoft Visual C++ MVP both globally and for Canada locally.

His programming experience includes C/C++, C#, SQL, MFC, ASP, ASP.NET, and far, far too much FORTRAN. He has worked on PocketPCs, AIX mainframes, Sun workstations, and a CRAY YMP C90 behemoth but finds notebooks take up less desk space.

He dodges, he weaves, and he never gets enough sleep. He is kind to small animals.

Chris was born and bred in Australia but splits his time between Toronto and Melbourne, depending on the weather. For relaxation he is into road cycling, snowboarding, rock climbing, and storm chasing.

Comments and Discussions

And that's already OUT OF THE STANDARD! A prime advantage of the standard is portability, but never mentioned in this interview. The moment I read sentence saying MFC/ATL/WTL is not gonna be in this interview, I knew this is no more than a "commercial" interview that keep C/C++ away from GCC/LINUX.

Stanley Lippman as an experienced developer, he should not blind fold his eyes and talk. We want a language that give freedom and meta, not a language that helps promoting a product. The CRT/STL itself is built by C/C++, that's what we want.

Couldn't understand why .net couldn't be access like native GDI+. Answer: So as time goes by, more and more young developers are addicted to C#, C/C++ will doom and together with GCC/LINUX. Smart eh!?

It is nice that the VC++ on a medium-scale timeframe targets "to ensure that" VC++ "will compile the most popular libraries such as Boost, Blitz, Loki and a fully compliant version of STL". However, these words could be interpreted in a way that would lead to an unsufficient result.Let us elaborate on the goal:

1)Obviously, in our context "popular" doesn't mean "in heavy use today", because people can only use these libs if their compiler permits. so I would strongly suggest to add some less known libs, e.g. for functional programming (FACT,FC++ or LL), as targets/benchmarks.

2)Libs like Boost and STLPort use a vast amount of dirty hacks to ensure that they can work with broken compilers. Your aim must be to compile the most advanced libs without them using special switches, i.e the "#ifdef VC ..." sections should be almost empty.

3)C++ programming using advanced generic libraries leads to a totally different code structure than programming with Java-style OO-frameworks. There are lots of small classes with inline functions instead of inheritance and virtual functions, and typically simple user code gets expanded to a huge maze of forwarding functions calls with many levels of indirection even to do straightforward. Unless the compiler is able to almost totally optimize away this abstraction penalty, this will never do.AFAIK the VC++ compiler is really good at optimising C -like code, and provides a good implementation of the C++ OO features (viruals, etc.), but it will need to become much better at small object optimisation, inlining, removing unnecessary code by restructuring, etc. Programming with such libs leads to a lot of complicated code which can be "folded" at compile time into something very simple, but only if the compiler tries first to inline even very complicated looking functions, and refuse to inline only after checking that they don't "collapse" even after very sophisticated optimisation attempts.

4) Of course, all this has to be done really fast, i.e. the compiler must be able crunch lots of templates, with many parameters and many inline functions, and with many levels of indirections.

5) Providing a new level of understandible error messages as well as new tools to analyse and debug template code would even make it easier to became "the C++ implementation of choice".

This creates a ruckus with the
IMPLEMENT_DYNCREATE and MESSAGE_MAP macros,
not to mention that ClassWizard runs amok. So
its back to the typing wizard, expanding all the
macros and typing in the entries into the message
map.

Question is, are the macros and ClassWizard
going to become more sophisticated?

Satheesh

To the moderator:

BTW I should have posted this in the
main Visual C++ section, can u shift it there?
thanks

"Microsoft will not sacrifice code-generation quality or robustness at the cost of extreme compliance".

Dose the compiler rely on non-compliant feature to ensure quality or robustness? Or is the compiler design so less extensible that independent components are tiedly coupled? Anyway, one could hardly image this is the excuse for not including partial specialization. IMO, standard compliance should not reduce, but instead enhance, the quality of the compiler design. (BTW, I like VC++ very much. It's really a good product.)

The only valid argument that can be made is time required to implement such features. Development resources and time are limited. Assume that you are going to release a new version of Visual C++ 12 months from today. You pick and choose the features that can fit in that time frame. You will drop some features for the sake of others. There will be times when you will drop features which are only there to make the compiler more compliant with the C++ Standard so that you can get other features in to improve code-generation quality and robustness.

I have a real product that I ship, which currently compiles with Visual C++ 6.0. If I had to choose, I would rather have a faster compiler, that produces better optimized code, then support a Standard C++ feature that I may never use.

Sorry, I'm confused. Are you saying that it isn't necessary to stay 100% compatible with the accepted standard if a company has an ambitious release date to make?

Isn't the whole point of establishing a standard to have that standard be adhered to by the industry? If not, then it isn't really a standard, is it? Wouldn't it be more accurate to refer to it as a guideline?

In your example with the 12-month release date - wouldn't it be better for the company to set its release date based on the time it will take them to create a 100% compatible product than for it to arbitrarily set a 12-month deadline and the compromise the product in order to meet that deadline?

After all, if they don't, isn't there a chance that your product that was written in VC++ version x might not compile in the next version if one of the C++ features that you use gets sacrificed to make the 12-month release date.

Surely 'export' would be a major feature for C++ templates.
It would allow us to write huge template class member functions and compile them once (presumable into an intermediate goo) such that the linker (or whatever) can automatically create the code for all instantiations when the final app/dll is created.

> You may compile it once with explicit template instantiation indeed right now with 12.0.
> It is not automatic however but the effective solution.
Indeed, this is what we do now:
template class CAnyTemplateClass;

> And IMO the automation of such process may appear to be harmful in some situations.
I would be interested in seeing an example of where it could be harmful.

> > You may compile it once with explicit template instantiation indeed right now with 12.0.
> > It is not automatic however but the effective solution.
> Indeed, this is what we do now:
> template class CAnyTemplateClass;
BTW this is ill-formed -- template argument list is missing.

> > And IMO the automation of such process may appear to be harmful in some situations.
> I would be interested in seeing an example of where it could be harmful.
Generally speaking, making template instantiation process automatic may lead to the situation when you lose the control upon the amount and the make-up of instantiated code especially in large projects.
"Export" may appear to be the useful feature. But let us consider the situation we have right now:
having template void f(...); declaration in a header file and it's definition and all the necessary explicit instantiations in a cpp file you can control all the additional instantiations in your project the following way. You get a linker error and analyze the situation if you really need this very instantiation or can reorganize your code some different way. It is sometimes the totally different way as I have more than once found myself.
The unconscious automatization may lead to code swelling at best or you may miss some "particular" cases when you might need the an explicit template specialization.
One may consider that the problem is far-fetched. Then another reason against "export" (in respect to MS, I suppose) is that the existing "export" problem has the solution which is not that ugly and effective enough. While reading "The Design and Evolution..." by Mr. Stroustrup I was convinced by him that it is very serious reason.

With regards,
Michael Kochetkov.

P.S. To the moderator: it seems that e-mail notification does not work.

> > > You may compile it once with explicit template instantiation indeed right now with 12.0. > > > It is not automatic however but the effective solution.> > Indeed, this is what we do now:> > template class CAnyTemplateClass;> BTW this is ill-formed -- template argument list is missing.O-o-ops, I have gotten why it is missing.

This works fine, but is a bit of a pain to explain when you are writing libraries for other people to use.

> The unconscious automatization may lead to code swelling at best or
> you may miss some "particular" cases when you might need an
> explicit template specialization.
I take my hat off to anyone who has implemented a C++ compiler, but surely what you are talking about is a mere implementation detail of the compiler. What I mean is, it must surely be possible for the compiler/linker to work it out automatically (and without any code duplication). I do understand that it would be a pain to implement, though.

The reason is to help a compiler and a linker, to save some time and disk space.

[...]> This works fine, but is a bit of a pain to explain when you are> writing libraries for other people to use.Hm... That seems to be the core feature of the language. It is not the trick or a special technology. You do not have to explain it -- just document it. But nonetheless I agree with you.

[...]> I take my hat off to anyone who has implemented a C++ compiler,> but surely what you are talking about is a mere implementation> detail of the compiler. What I mean is, it must surely be possible> for the compiler/linker to work it out automatically (and without> any code duplication). I do understand that it would be a pain to> implement, though. Let us imagine that we have a C++ preprocessor that is capable to generate MightyUseful.cpp in my terms for a large project... for parameterized stuff with the export keyword ahead. It is not that hard to write such a tool (having EDG in mind), is it???

Did you mean template class MightyUseful<MyClass>;
rather than typedef MightyUseful<MyClass> MyClassMightyUseful;

Either way, the problem there is that you need to modify MightyUseful.cpp every time a new class uses it. If MightyUseful.cpp were a third party class, that would mean modifying third party source code!
Perhaps a better solution would be to have MightyUseful.hpp contain the source code, and for each project to have a MightyUseful.cpp that contains all the explicit instantiations for that project.

> Let us imagine that we have a C++ preprocessor that is capable to generate MightyUseful.cpp in my
> terms for a large project... for parameterized stuff with the export keyword ahead. It is not
> that hard to write such a tool (having EDG in mind), is it???

> > The reason is to help a compiler and a linker, to save some time and disk space.

> Did you mean template class MightyUseful<MyClass>;> rather than typedef MightyUseful<MyClass> MyClassMightyUseful;No.

> Either way, the problem there is that you need to modify> MightyUseful.cpp every time a new class uses it. If> MightyUseful.cpp were a third party class, that would mean> modifying third party source code! > Perhaps a better solution would be to have MightyUseful.hpp> contain the source code, and for each project to have a > MightyUseful.cpp that contains all the explicit instantiations > for that project.I was dead sure I was talking about this thing -- one cpp file that contains all the instantiations for a project. It looks like that my English have let me down, sorry. I have ment MightyUseful.cpp tobe your that very file that contains all the instantiations. And as far as the templates definitions _are_needed_only_for_this_very_file you may put them into this file as well (but you may preffer to put them in a different file, say MightyUseful.hpp, I have just emphasized the accented assertion above). Anyway, it does not matter at all. The main idea is the single file. It may appear to be very convenient in some cases. That was my main idea. It was probably vaguely formulated and made you guess but my English is not perfect indeed

> You may compile it once with explicit template instantiation indeed right now with 12.0.
> It is not automatic however but the effective solution.
Indeed, this is what we do now:
template class CAnyTemplateClass<CAnyType>;

> And IMO the automation of such process may appear to be harmful in some situations.
I would be interested in seeing an example of where it could be harmful.

I'm not sure what the standard explicitly says, but I suspect that an implementation of the export keyword would not necessarily allow you to compile them once into a library since you have a standards requirement to only compile things that are used (or explicitly intstatiated) - and this is crucial for alot of partial template specialisation stuff to work.

Where export is crucial though is avoiding circular include dependencies in large templatised libraries. Quite often you have to compromise a design to avoid the circular include which would not exist if the exported template definition sat in a cpp file somewhere not in the include chain.

I hope microsoft finally get round to implementing template within template support. This is required to compile the excellent Loki library.
See "Modern C++ Design" written by Andrei Alexandrescu. This book basically documents the Loki library, which is available at:
www.awl.com/cseng/titles/0-201-70431-5

It'd be even better if the freakin implementation didn't generate
unique object code in every .cpp where the template is used
which bloats the code segment to icode cache choking extremes
and making "Linking..." a dirty word around the office.

Templates are a mature feature of C++ that should have much
better support from these "innovators" in Redmond. These problems
are the kind that a bright second year college student could do
for a class project. They should be ashamed.

As the CLR improves, I foresee it replacing the Win32 API with something a little more object oriented. That's always been Microsoft's vision from the Cairo days and I see the CLR and the .NET framework being the first step.

"Microsoft will not simply implement features because they are specified in the standard"
Why not ? Isn't the standard what the language is supposed to do ? Period, no, ifs ands or buts.
Otherwise why have it ? It seems to me that if a language is specified to have features X, Y and Z, then any company implementing a compiler needs to implement X, Y and Z. Who is Microsoft to just arbitrarily pick and choose ? And if they feel the feature is "theoretical" then there is no way to really find out, since no one will be able to use the feature, since it is not implemented. An endless catch-22.
If the feature is incredibly difficult and impractical to implement then why not lobby to have it removed ? Lord MS spends millions and millions of dollars on R&D, they have hired some of the best and brightest in the field and they cannot make a compiler that correctly implements the C++ language ? C'mon...
I don't doubt that every member of the VC++ team works very hard, but this is a little difficult to buy into.

>I'd be interested to know how they pick and choose what part of standards
Well that's what bothers me - they shouldn't get to pick and choose. It is either C++ or it isn't. And if it isn't then it is just some subset and shouldn't be called C++ (maybe C+-... ).
Perhaps this is naive, but I am presuming that the features that make up the C++ standard are there for a reason, hopefully one that has been hashed out extensively. Isn't that the whole point of the C++ Standards commitee ?

They will try to drift it apart from standard as far as they can and at the same time they will pretend not to. That is typical and it's not the first time from MS side.

It seems to me that Mr. Lipman has already been polluted by the Microsft ideology so he can easily use their language - in one sentence said one thing and in the next say the opposite. I foresee his best carier because he already grasped the key to success...

No point trying to defend. George has his own view on what Microsoft are trying to do. Nothing anybody can say will change that viewpoint. There is no evidence that Microsoft want to kill off C++. Why would they try and kill off the language that most of their stuff is written in. Why would they want to alienate their developer base just when the battle against Linux is starting out. Microsoft knows they can't afford to lose good C++ developers to the open source enemy.

Michael P Butler wrote:George has his own view on what Microsoft are trying to do. Nothing anybody can say will change that viewpoint.

You don't know me...

Michael P Butler wrote:There is no evidence that Microsoft want to kill off C++. Why would they try and kill off the language that most of their stuff is written in.

You've hit the jackpot here, that is EXACTLY why! They want everybody to use .NET and C# and meanwhile they will make their own stuff in C++.

Michael P Butler wrote:Why would they want to alienate their developer base just when the battle against Linux is starting out.

No, not alienate - they want to JUMP (migrate). Battle against Linux? Now THAT sounds like a conspiracy theory.

Michael P Butler wrote:Microsoft knows they can't afford to lose good C++ developers to the open source enemy.

Microsoft thinks they can afford whatever they want. They don't want good C++ developers, they want a productive ones. That means C# and VB and maybe ASP.NET, not C++. The users base has been trained for years to accept low quality software (crash - reboot! attitude). Now that has been achieved time to rid out those C++ crowd who dares to point MSS mistakes...

George wrote:...but MS Word is not written with MFC and I doubt they are migrating it to C# either...

...and why should they? They have a stable product with a codebase they are quite capable of supporting.

In any sane environment the migration of an existing product to a new implementation should only happen if there's a good justification for doing so - either on cost, performance or useability grounds/

If you already have a stable product which you're confident you can continue to extend and support this probably doesn't apply.

Proposing a rewrite just because a new framework is available is just naive.

The codebases of Word, Excel, Powerpoint, NT and other apps often have pre-dated MFC. There haven't been significant rewrites, and some newer pieces of these apps use MFC. Publisher, Money, MMC, Encarta, Mappoint, Streets, PictureIt, and more are MFC apps...and coincidentally, are newer apps.

However, not every new app at Microsoft is written with MFC because our dev teams are free to choose the tools they think they'll be most productive with. As we all know, C++ developers often think they can write it better themselves and that certainly is true at Microsoft.

Virtually every commercial application, most mission critical applications, most of the trading apps on Wall Street, many Healthcare apps, and tons more are written in C++ and those are clearly important apps to have on Windows...we're not getting rid of our C++ tools.

There was a time when people thought Microsoft was going to get rid of everything but VB...

As a long time follower of the Boost libraries project (www.boost.org) I am very encouraged by people like Jason Shirk at Microsoft (and Howard Hinnart at Metrowerks) for actively keeping an eye on Boost and attempting to feedback problems into their respective compiler teams.

In consequence my next compiler is likely to be from one of their companies.

I am a little concerned that Jason's progress in implementing standards compliance issues seems to be scheduled for MSVC 7.1 someway off (seemingly late next year). Its a shame more can't be done to include some of this in the initial 7.0 release.

The importance of templates actually working, and other more advanced features relating to metaprogramming etc cannot be under-estimated.

Actually, my understanding is that most of the standard has been implemented (export being the one exception, but no one's going to complain about that) but for quality assurance and time reasons caused by marketing and other corprate initiatives a few of them (partial template specialization, for example) won't make it in 7.0. In other words, MS tried VERY hard to get there and deserves a lot of recognition for this. It's only pressures outside of anyone's control that will prevent a few features from being included in 7.0. Knowing this, and knowing of the effort and passion the MS team is putting into this I'm quite happy to wait for 7.1. In the mean time, 7.0 is light years ahead of 6.0 and allows most of what we need.

I'm a little surprised that, being such a toplevel C++ programmer as you are, you haven't put more emphasis on the importance of partial template specialization and how the lack of it in 7.0 shuts off the gates of metaprogramming paradise --or at least a good portion of it.
In my opinion, PTS is the single most productive feature of the last C++ standard, and it is only now that people are realizing what a great deal of amazing things PTS allows them to do. It's a pity MS folks haven't caught up yet.

Don't get me wrong... I want PTS in VC++ as much as anybody. But there's a few reasons I'm willing to live with out it in 7.0. First, MS has this done and so I know it will be in 7.1. Second, 7.1 is likely to be out this year as well. Third, they've become compliant enough with most of the rest of the standard that some well known work arounds can be employed most (not all) of the times when you'd want PTS. Fourth, the attitude change I've had first hand experience with from MS has made me more willing to forgive the lack of PTS, especially since it's missing only for reasons out of the control of the developers.