Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

A Visit to Redmond - Part 6

0.00/5 (No votes)
24 Oct 2000 1  
For those who are curious as to what a hastily scheduled trip to Redmond is like.

Introduction

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 Atilla instead?

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 much improved.

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.

.NET

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 news. 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...?

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.

Postscript

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.

cheers
Chris Maunder.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here