Last week I popped on over to Redmond to have a chat with the guys at Microsoft on the future of
Visual C++, MFC, and the new .NET world. Instead of presenting a point list of what we can expect
in the future, I wanted to give you guys a taste of what a visit to Redmond is like from a
personal point of view.
Please be aware that this isn't an in-depth technical treatment of .NET - there are a million
magazine articles and a ton of stuff on Microsoft's own site to get the basics. The
.NET specific stuff presented here will mostly be new information that I wasn't
aware of, and that I
felt you guys would be interested in, or was simply a vague thought that came to me
while slurping through tubs of Ben and Jerry's Fudge Chocolate Disaster ice cream.
A quick Thanks goes to Dundas Software and Microsoft for making this trip possible.
Part 6 - The Libraries and .NET
The big question that most people will be asking is "what's the future of MFC?". Well, it's
still here and will be for a while yet. An obvious statement no doubt, especially considering
the amount of legacy MFC code that is out there. The library has been enhanced
to provide support for .NET, and there are a bunch of new classes that allow MFC apps
to be a provider
and a consumer of web services. The MFC DLL has been renamed to MFC70.dll (finally!), and certain
classes - most notable the CString class - have been rewritten so they
work seamlessly with ATL. I mention CString because this class is now shared between MFC and ATL.
Interestingly, there is no longer a separate ATL and MFC include directory.
All MFC and ATL include files now reside in the same directory, and the two libraries work together
a touch more gracefully than before. There are new dialog classes that use HTML resources instead of dialog
resources, new accessibility support, multi-language support improvements and imaging support via
GDI+. All in all it's essentially business as usual for MFC, so don't be expecting any Earth-shattering
changes to the library. All it's little warts and fond peculiarities are still there.
WTL will always be in the SDK. As to its "official" future - who knows? There has been a lot
of confusion as to the state of the library - especially given the comments by Microsoft that
WTL was a 'mistake'. This seems not to be the case, with the team at Microsoft saying they will
continue to release the library as part of the SDK, but are unsure as to whether developers
really want another library like WTL. Do we need another library? Should WTL be wrapped
into the ATL fold? Or should Microsoft ditch WTL and use something like
STL has been improved. It is now the second most compliant implementation of STL available,
and was only let down because of compiler compliance problems.
Compiler errors in STL are now more readable.
The error messages are far less "noisy" and the variable types will be resolved
back to more intelligent names, instead of the mess of angle brackets that is
currently offered. When an error occurs you will be pointed to the
instantiation of the error, and not the base class. On top of this the STL documentation is
By now most of you should have heard of
ATL Server - the
tag replacement system that allows
you to develop high performance web apps. ATL Server allows you to create high performance web apps
using C++. It's a fast, easy to use and contains support for performance counters, thread pooling, CGI
processing and a bunch of other stuff. There are no DLLs - all source is included.
A big surprise was that a subset of the .NET runtime has been submitted to ECMA for standardising.
We all knew that C# had been submitted, but the fact that parts of .NET had been submitted too was
This is a significant move by Microsoft and paves the way for third parties to develop their own
implementation of .NET on other systems.
Since managed applications need to be compiled to intermediate language (IL) before the JIT'd
and run under the CLR, there is always the question 'Why not just add in the managed code at
compile time and then compile to native?'. The obvious answer to most people is that .NET on Win32
is a precursor to .NET on other platforms, such as CE, win64, and of course, Linux. The recent
Microsoft-Corel buy up has fuelled speculation, but the Microsoft team were at pains to stress that
they are not in a situation to answer the $64,000 question. Maybe there will be .NET on Linux. If
not by Microsoft then surely by someone else who sees an opportunity. .NET has not even been
launched on Win32, so I think we should at least wait until we have it on its native territory
before we start speculating about greener pastures.
But why not think about Linux and .NET from another perspective? Why not, using the JIT compiler,
devise a way that Linux applications can run natively on .NET?
And so the meeting ended. I'd almost finished my monster chocolate brownie, the cold and flu tablets
were wearing off, and jetlag and information overload was setting in.
Did I come across as all starry-eyed after my big visit to the grand-daddy of all software companies?
Maybe. It was not Microsoft's efforts at providing us with better tools, or their attempts to correct past
wrongs, or their cafeteria that made me think good or bad about the company. It was the people who work
there that touched me.
Unhesitatingly friendly, critical of themselves and their company when discussing some aspects of their
work, while at the same time immensely proud of their successes and achievements. They have a remarkably -
in fact staggeringly - large audience they have to play to, and if a bad call is made on something that,
at the time, didn't seem important then they live and die with that decision. There was almost a childlike
delight in some of the developers when showing off their new products - a withholding of breath as
they wait to see the reaction to their 3 years of work.
I guess what I came away with is a glimpse of the human side of Microsoft. The soft, fallible, uncertain,
squishy underbelly. It was nice.
So we wandered back to the hotel trying to put in some sort of order the tidbits that we had been told.
There were times when stuff we'd been told seemed to contradict something said by another manager, or
information we'd read elsewhere, and I do know that I will never give up my day job to be a stenographer.
We wandered around Seattle, had a brief chat with Obnoxious Bastard, palmed off some Canadian quarters,
and wasted far too much money on video games. We travel all the way to Seattle and spend a good deal of
the evening at a video game arcade. If that doesn't make us geeks then I don't know what will.
The next morning we wandered back to Microsoft and pestered Kent Sharkey the SOAP evangelist, and stole
some T-shirts from him. Why do I keep pestering this man? I don't know - I just can't help myself.
I hope, in some small way that I've managed to convey not only some of the useful bits and pieces of
information we learned on the visit, but also an idea of what it's like inside the company. I also hope
that my rambling wandering account of my thoughts and feelings have given you a feel for what a visit to
Redmond is like.
There are still odd bits and pieces I could add, including The Kent Sharkey Hunt, but the aftermath of
celebrations last night have shortened this day a little.