Having been on the job for a few months now, I feel like the team and I are finally beginning to settle in.  It's been a period of significant flux for the Parallel Developer Tools team that included a new leader and (largely) new team trying to adjust to one another, building a plan for the next release of Visual Studio, recruiting and hiring top talent for the team, physically moving to a new building on a different part of campus (and separate from most of the rest of VS), building and strengthening partnerships with teams internal and external Microsoft to drive the Parallel Computing Initiative forward, and, and, and...

I came across this InfoWorld article today regarding developer skills and parallel computing.  I was amused the fact that the issues raised by Dan Reed in the article echoed a conversation I had with Dan just yesterday when I met him for the first time in his office (which happens to be just across the street from mine).  It's a fact that developers largely really are not (yet) trained for parallel computing.  What's more, those that are trained typically have their experience base in high performance computing (think massive amounts of data being crunched on clusters), which is a slightly different problem than that we're trying to deal with on the PCP team.  Our focus in more squarely on leveraging the increasing parallel-capable hardware of a single node, typically a client PC running Windows, and dealing with the complexities of shared memory, making existing software more parallel-scalable, and how we'll design next-generation, inherently parallel software, and -- of course -- how to make parallelism second nature to current and future developers.

By the way, I should mention that I'm looking for the industry's best developers, testers, and program managers to assist us in this effort.  Here are some of the current job openings on my team:

Lead Software Development Engineer

Software Development Engineer

Group Program Manager

Software Development Engineer in Test

Software Development Engineer in Test

No, not that PCP.  The PCP to which I refer is the Parallel Computing Platform, a fairly new organization within Developer Division that is working to unlock new experiences for PC users by making it much, much easier for developers to build applications that leverage the opportunities for parallelism afforded by new multi-core CPUs.  Read more on the coming shift to parallel computing and what it means for developers in this Microsoft white paper and Herb Sutter's The Free Lunch is Over article from Dr. Dobb's Journal.

Yes, this means I've moved on from the Visual C++ team.  In my new role I'll be serving as Product Unit Manager for the Parallel Developer Tools team within the PCP organization.  My team is focused on the tooling developers need to build highly parallel software, such as debuggers, profilers, analysis, and designers.

So how can you be on PCP? You can start by visiting our Parallel Computing MSDN dev center.  If you're really ambitious, you can start playing with our Parallel Extensions to .NET 3.5 CTP.  Of course, there's more where that came from, and in the coming months you can expect to see things like parallel development libraries and tools for both native and managed code developers.

I'm late in getting this blog entry out, but I wanted to do a quick recap of the Visual C++ team's trip to TechEd and follow-on trip to Munich.  As I mentioned previously, my talk on debugging in VC++ 2008 went well, and my audience was an unusually attractive bunch.  Ale Contenti and Kate Gregory also did VC++ talks, and in the final tally the VC++ talks scored very well based on both attendance and attendee survey results.  Count on more VC++ talks at future TechEds!

Kate and Ale also did a great chalk talk on TR1 and C++0x, the upcoming C++ standard.

Ale deemed TR1 to be "super cool" (which sounds better when you say it with an Italian accent), which is plenty enough an endorsement for me.

We also enjoyed our traditional dinner out with C++ MVPs and the VC++ folks.  We ate at Cal Pinxo on the harbor, which was fantastic, as evidenced by the happy faces you see here:

Truth be told, this wasn't an exclusive VC++ staff/C++ MVP event.  In the photo you will notice some sketchy looking MS France guys on the right and some friendly but distinctly non-C++ MVPs from Italy.  They all looked hungry, though, so we invited them along.  :)

Before leaving Barcelona we also took the opportunity to sit down with our friend Charles Torre for a Channel9 video on VC++ 2008 and beyond.

Munich

After TechEd, Ale and I jetted off to Munich for an action-packed few days of presentations, customer visits, and press interviews.  The MS Germany team that arranged our visit, including Dariusz Parys, Christian Binder, and Barbara Steiger, were awesome and definitely kept us busy!

Imagine, also, if you will the small matter of temperature shock upon leaving balmy Barcelona for this place:

Dariusz and Christian were also kind enough to record a couple of Ale's sessions, which you can find here and here.

All in all a great trip, but very tiring.  Not to mention expensive for a poor soul like me that earns his income in dollars.  :)

How big is TechEd? So big that they had to add additional capacity to the conference center here in Barcelona in the form of two vast portable session halls, lovingly referred to as "Tent1" and "Tent2." Yours truly was lucky enough to give his session on Debugging and Crash Dump Analysis in VC++ 2008 in Tent2 today.  I must say, it's the first time I've ever performed under the Big Top, but I hope it's not the last.  The circus life is for me!

I had the audience pose for a picture prior to starting my session.  Check it out:

Nice group, eh? I might add that this was clearly the most intelligent and downright attractive crowd at the conference.

There are tons of hidden gems in the debugger, so I tried to avoid the obvious stuff and focus on some of the power features as well as offer a discussion on how to avoid having bugs in the first place.  I had a good time, and I hope the audience did as well.  I do know at least one member of the audience found it useful; now, I don't read Italian, and I'm never one to toot my own horn, but I'm pretty pleased with Raffaele's assessment of "Magnifica la sessione." :)

Hey, long time, no blog.  I'm in TechEd this week along with Ale Contenti for TechEd EMEA.  Luckily, my trip was pretty much uneventful (if you don't count the up-close-and-personal wanding I received at SeaTac airport), and I even have my luggage, unlike last year.  If you're going to be at TechEd and want to chat, please drop me an email -- I'd love to meet up.  I'm speaking on Wednesday, and I'll try to be at the Visual Studio booth as much as possible otherwise.

Next week, we'll be in Munich for a series of Visual C++ customer meetings and events.  We'll be hosting an open public VC++ event on Thursday, November 15th at 6:00 PM.  See Dariusz Parys' blog for details -- I expect to see all you Bavarian C++ developers there!  :)

Interesting blog entry from my old friend and colleague Steve Trefethen on Microsoft APIs.  Steve brings up a lot of good points, and I particularly agree that the API landscape is way more fragmented and confusing than it should be, and we at Microsoft need to fix that.  However, I also come in on the opposite side of several issues Steve raises, so I thought it would be worthwhile to call out a few specific points.

It seems Redmond has one-upped Google by putting out alpha software and beta software with "Go Live" licenses. How long will it be before we see alpha software with a "Go Live" license? Are we to believe businesses today are betting their future on all of this pre-release code?

While I agree the proliferations of alphas, betas, CTPs, etc. can be confusing, I actually don't feel this is a bad thing.  Years ago, Microsoft (and the industry as a whole, for that matter) was much more secretive about project under development. These days, customers overwhelmingly prefer transparency, even knowing that transparency means working with software that has a few warts and is subject to change in shape and behavior.  The comparison with Google is also interesting because Google customers have clearly been very happy to use services that Google has deemed beta quality (Gmail, Maps, Toolbar, etc.).   Given the way folks are voting with their feet in favor of these things, a reasonable person could conclude that customers often find value in software even if it's not considered "RTM quality."

Is [an MSDN statement comparing WPF to GDI] implying that the new Office 11 Ribbon UI is "constrained? Ah, but it's  not .NET so it must be constrained. And what about Vista's fancy new albeit unmanaged UI surely that must be constrained right?

Nobody ever said that all things .NET were constrained.  The referenced quote was making a point that it's a great deal of work to build WPF-quality user interfaces with straight Win32 because Win32's GDI is old and crufty.  Of course you can build the Office ribbon and cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives.

Btw, where is Microsoft's developer support for the new Vista UI? That's not due to arrive until Orcas ships. Didn't the MFC guys know when Vista was going to ship? Or was it that it just didn't matter until recently?

Our bad.  While Developer Division was successful in launching .NET 3.0 technologies (e.g., WPF and WCP) with Vista, we did not deliver comprehensive tooling that enables developers to easily take advantage of the breadth of the platform.  Yes, the MFC guys (i.e., my team) knew Vista was coming.  We were just not agile enough to release such a product before Orcas.  However, making mistakes is also a great way to learn, and you can bet that future tools releases will have better schedule alignment with major platform releases.

It's almost as though the Microsoft factory is stuck on hyperdrive. They're competing with Linux, Apache, PHP, Flash, Eclipse, Java, Oracle/MySQL/DB2/etc, Google, Mozilla, Open Office, MySpace, Yahoo and over the past 12 months have released betas in nearly all of these areas.

I wouldn't say that we're in "hyperdrive." This is who we are.  We're the world's largest software company, we have broad product and business portfolios, and we're going to be very competitive in all of the markets we serve.  However, I do think it's fair to say that because of this broad scope, Microsoft is less technologically homogenized than in past years, which can mean a lot of different platforms with a lot of different APIs which can result in a lot of confusion.

Staying with Microsoft tools will undoubtedly mean moving to .NET...

No way, Jose! In fact, the Visual C++ team's primary focus is on the native Windows platform.  We have some very aggressive post-Orcas plans for advancing the state of the art of native development.  Our secondary focus, btw, is on native-managed interop, with the goal of enabling ISV-style applications to have their cake and eat it too by getting full value from their native code while still incorporating and benefiting from .NET technologies (or bringing together the Raymond Chen camp and the MSDN Magazine camp, to use Joel Spolsky's taxonomy).

I might also add that Olivier Giroux over at NVidia (who takes a wait-and-see approach to all of this new technology) intimates why native C++ code will always be important:

...I have to write cross-platform software by day...

In fact, many of our best C++ customers use C++ because it enables them to target almost any platform, whether it's consumer software on the Mac or server software on Linux or avionics software running in a jet fighter.  These customers require the portability and/or the runtime control offered by C/C++, but we do need to make sure they also have a development-time experience comparable to that of the managed code developer.

Does anyone know what will really happen to WinForms with WPF being touted as the new UI for Windows? Will there be an Interop WPF toolkit available to move your WinForms apps one form at a time to XAML/WPF?

I have a couple of thoughts on this: first, WPF does not currently have the features and capabilities necessary to supplant WinForms as the framework of choice for line of business style applications.  I know we've tried to message this appropriately, but I agree that it sometimes gets lost in the WPF enthusiasm.  Projecting down the road, I would ask: what are your expectations? If, some day in the future, WPF does overtake WinForms in terms of LOB capabilities, my expectation would be that we would continue to support WinForms for existing customers but recommend WPF for new code.  Or am I talking crazy talk here? Meanwhile, we do intend to support mixed WPF-WinForms apps in the Orcas release.  A WinForms to XAML converter is something I know people have talked about internally, but I expect customer demand would dictate what we do here.

The sad thing is that I'm actually interested in several of these technologies but the field is increasingly looking like the slide from Stephen Colbert's The New AT&T (see about 50 seconds into the video). I've been trying to keep up though it seems a lost cause with each passing day I'm falling further behind.

First, props for the pointer to Colbert's hilarious AT&T video! More seriously, my view on this is that the day has long passed where it is practical to keep up with every developer technology coming out of Microsoft.  Ten years ago, it was totally doable and expected that any "real" developer was totally on top of all of the new stuff coming out of Microsoft.  Today, software developers are more specialized.  A developer may focus on web applications or ISV-style native apps or LOB apps or mobile or SOAs or some industry vertical or some other spoonful of alphabet soup.  Or maybe even one or two of these.  After all, most of us have day jobs and the world of Microsoft platforms is so big that simply understanding it all to any reasonable level of depth would be a full time job in itself.

That said, I'm not going to hand-wave away the fact that there are areas where would do have overlap or should better aligned or must be better at messaging when and where to use what technology.  And we also need to better align platform and tools releases.  All of these things are true. But I don't believe it should be a fundamental goal to homogenize our platforms and APIs before letting anything out the door.

A number of news aggregators and blogs have picked up this Broadcasting & Cable story, reporting that HBO CTO Bob Zitter wants to stop referring to content securing technology as DRM and begin referring to it as DCE, for Digital Customer Enablement.  Are you kidding me?  Enablement?! Seriously.

Look, if you own content, you have every right to cripple protect that content however you see fit. I certainly won't debate that.  I also believe that companies that build platforms to host this content, such as Microsoft, Apple, TiVo, etc., must provide core technology to support the desires of content owners, even if those desires include DRM.

However, I'm also a big believer in free markets, and I'm confident that DRM'd content (at least in its current form, where the "D" in DRM could stand for Draconian) will ultimately lose in the market to companies distributing content in more convenient, customer-friendly formats.

But, all of this aside, don't try to make the rest of us use your weasel words.  DRM is not about customer enablement of anything.  It's about restricting what customers are already able to do in order to support a particular business model.  Again, I support a content owner's right to do this, but I will vote with my dollars for content owners with more customer-friendly approaches.

International readers, please bear with me while I get all North American-centric on you for a sec.  One of my favorite "business" books in recent years is Moneyball: The Art of Winning an Unfair Game by Michael Lewis.  On the surface, Moneyball is a book about baseball and specifically about my hometown team, the Oakland Athletics in the year 2002.  For the baseball fan reader, the book is full of great anecdotes about on-field heroics and front office intrigue.  However, below the surface Moneyball is all business.  It's a story about exploiting the inefficiencies in a market, about identifying metrics that directly correlate to success, and about buying low and selling high.

I had a Moneyball moment a couple of weeks back when a colleague and I were discussing "model" employees for a certain role.  As my colleague threw out a few examples that fit his model, I realized he was falling victim to "the good face" mentality described in Moneyball.  Lewis talks about baseball scouts referring to prospects as having "the good face" when they look the part of a major league baseball player: handsome and well built, preferably with a flair to their personality and game.  Of course, this is an utterly bogus consideration in terms of assessing a prospect's major league potential, but some scouts obviously gave it consideration because the Oakland Athletics organization exploited this market inefficiency by focusing on things like track record, college experience and just generally recruiting ugly, chubby guys that could play baseball.

Anyhow, I realized my colleague was falling into the trap of describing his idea of model employees for a role in terms of the attributes he thought someone in that role should have and how he felt they should behave, as opposed to in terms of the results someone in that role should achieve and their track record of successful results (note, by the way, that by "results" I don't simply mean "money" or "profit" but the full scope of metrics and attributes by which an individual's job performance is measured).

This Moneyball moment was a reminder to me be crisp about what success looks like and to let that vision of success inform my actions.  It's nice to do a really great presentation or to craft a particularly brilliant email, but unless it contributes to successfully accomplishing the goal, it's just the good face.

Remember the good old days, when a progress bar in the user interface actually provided an indication of, well, progress? Alas, today the progress bar devolved into little more than a dancing monkey, doing the electric slide back and forth in its tiny box in an attempt to simultaneously communicate to me that something is happening while also trying to distract me from from the fact that I'll be waiting some indeterminate period of time for that thing to finish.

In the beginning, progress bars made a credible attempt to demonstrate the percentage of completion of some particular task.  The movement of the progress bar wasn't always smooth -- it could linger on 25% complete a bit longer than 75% complete -- but it did provide a reasonable approximation of progress toward completing a task.

However, keeping the progress bar in general synchronicity with reality can be hard, so, over time, software designers began to give up.  Maintaining any semblance of accuracy or smooth motion in the progress bar became a distinct non-priority.  I remember my first exposure to this temporal dissonance while installing some software on Windows 95.  The user interface provided a few vague textual messages about what was happening as the progress bar ranged from about 0 to about 90%.  This took about 10% of the install's total time.  During the remaining 90% of the total install time, as the progress bar inched its way the last 10% to completion, the installer provided textual messages with ridiculous detail on what it was doing.  It's almost as if the point of the UI widget was to annoy rather than inform.  Alas, this form of progress bar remains the most common species found in the wild today.

Shamefully, a colleague pointed out to me a particularly egregious progress bar in Visual Studio today, where it takes about 15 minutes to get to 100% and then lingers on 100% for several hours.  Sigh.

And a particularly hideous offspring of the inaccurate progress bar is the one starts all over again from zero after it completes.  Sometimes more than once.  Oh, the humanity!

Anyhow... along came the web, which you might say forked progress bar behavior.  Something like a progress bar was pretty difficult to do accurately in HTML, particularly when things you'd normally want to use a progress bar for tended to involve the code on the web site merely firing a single request to some other server, with no hope of knowing the progress.  So instead of a progress bar, we got that progress-bar-appearing-thing-with-oscillating-Cylon-eye-motion.  I'll call it PATWOCEM.  The PATWOCEM's #1 goal is to encourage you not to navigate away to another web page by providing an indication that something worth waiting for is going on.  On some level it makes total sense: If you just display some text like "please wait..." people will get impatient after a minute or so.  However, add a PATWOCEM, and you probably increase their willingness to wait by a factor of at least 3x.  While the psychological effect is no doubt real, I can't help but be frustrated by its functional uselessness and the continued devolution of the progress bar.

The PATWOCEM has found its way from the web to the rich client in the form of the indeterminate progress bar, which is so common in Windows Vista.  I really do understand that this PATWOCEM is useful for cases where the overall progress cannot be determined, but I'm also confident that developers use this as a crutch when they don't want to do the bit of extra work involved in figuring out how to track progress of a given task.  C'mon, do the work! Your users will be happier! My crack research staff (okay, me) uncovered the design guidance on progress bars for Vista on MSDN.  The content is actually good.  If only more developers followed it.

No, it's not a code name for some cool, new developer tool.  It's what I found hanging out outside my window this morning.  Kinda cool.

Just had to share this.  We received this message via the feedback form on the VC++ team blog:

My text book says to make a simple program.

None of the new files have the option(simple program).

 

What would be the correct file?

A File|New|Simple Program wizard would indeed be handy! Probably second in usefulness only to the Project|Simplify wizard.  :)

I'm blogging live now from Eric Vernie's presentation on using WPF from within VC++ applications.  Despite the fact that I only understand 10% of his French language discussion, the presentation is very engaging, and he's written some really cool code to embed WPF within an MFC application.  I will try to get Eric's work published more widely in English because I think a lot of C++ folks looking to build WPF user interfaces will find it very interesting.

I just finished my presentation on VC++ futures, including an overview of what we're doing for Orcas.  Other than this, I've spent the past couple of days in meetings with a variety of French ISV that are using VC++.  It was really cool to see how this wide variety of customers are employing VC++ to build their software, and the meetings have reinforced my belief that we're on the right track in terms of product strategy as Bill and I discussed in the recent Channel 9 video.

I was also interested to speak today with a developer interested in contributing to ATL Server, which we recently released as shared source, as he was very interested in enhancing the functionality of sproxy (Goodness knows sproxy can use a little updating!).

Hearty thanks to Eric Mittelette of MS France, who kindly arranged the ISV meetings as well as this C++ conference day in Paris!

Vive le C++.

I'm blogging live from the Microsoft booth at the ACCU conference in Oxford, UK.  This conference represents one of the best opportunities of the year to rub elbows with influencers and luminaries within the C++ community.  For me, ACCU is also a great opportunity to practice my diplomacy skills, since speakers and attendees including healthy representation from the Linux and OSS communities.  :)  I'll be giving a presentation tomorrow on What's Next for Visual C++, including a dive into some of the Orcas features.  Next week, I'll be in Paris for a C++ conference and to meet with several VC++ customers.  Email me if you're in the neighborhood and want to meet up to talk Visual C++.

As a side note, the ACCU venue is nice, but I miss the central Oxford location of previous years.  We're on the outskirts of town, where points of interest within walking distance include the BP fueling station and a large grassy field.

Last week I saw a question on our MSDN forums asking how to link C++ and C# code into a single binary.  It's a scenario that we indeed support (albeit only from the command-line), but as I looked for a reference to which to point this person, I found precious little how-to in our own docs or on the web.  I decided to whip up an example myself, and to my surprise it took me the better part of a whole afternoon to get right.  The workflow is clearly more difficult than it should be, and I'm asking the team to look into how we can improve here in the future.  Meanwhile, I'm going to walk through the example here to ensure there is some reference out there for Visual Studio 2005 developers.

Single binary interop

Generally, we recommend doing native/managed at the DLL boundary.  When this pattern, you will typically have a collection of managed DLLs written in any managed language, a collection of native DLLs written in VC++, and a collection of mixed-mode DLLs that use C++/CLI to bridge between the two.  However, occasionally you may need to compress these three layers into a single .exe or .dll in order to reduce dependencies, simplify deployment, or the like.

At a high level, the process for combining native and managed code into a single binary is logical: compile your source code into a collection of .netmodule and .objs and link them all together using the Visual C++ linker.  However, the devil is in the details: dependencies between modules, linker switches, and where to use .objs versus .netmodules can be sticky issues.

An interop example

In my example, I'm going to create a C# application that uses C++/CLI to call into native C++ code without using C#'s unsafe language extensions.  Let's take a look at the simple C# application in Listing 1, which consists mostly of the code generated for me by the new C# Console Application project wizard:

using System;
using System.Collections.Generic;
using System.Text;
using MyInteropCode;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            String s = CPPClass.CallCPPFcn();
            Console.WriteLine(s);
        }
    }
}

Two things worth noting here: this module is referencing a namespace called MyInteropCode, which I'll talk about in a moment, and it's calling a C++ function called CPPClass.CallCPPFcn(). Listing 2 contains the C++/CLI interop code that is being referenced by Program.cs.

#include "nativecode.h"

using namespace System;

namespace MyInteropCode
{

	ref class CPPClass
	{
	public:
		static String^ CallCPPFcn()
		{
		     wchar_t c[32];
		     GetStringFromNative(c, sizeof(c) / sizeof(c[0]));
		     return gcnew String(c);
		}
	};

}

clrcode.cpp defines the MyInteropCode namespace, which contains a managed class called CPPClass.  It is in this class (or some collection of similar classes) that I would place my interop functions, which leverage IJW interop technology to offer CLS-compliant interfaces and call native C++ within their implementation.  In this case, I'm surfacing one static function called CallCPPFcn(), that returns a System::String.  Within CallCPPFcn(), I create a local character array, pass that array to a native C++ function to be populated, and then construct a new System::String from that that array, which is returned to the C# caller in Program.cs.  Listing 3 shows nativecode.cpp, which as you might guess contains the GetStringFromNative() function called from clrcode.cpp.

#include "string.h"
#include "nativecode.h"

void GetStringFromNative(wchar_t* c, int num)
{
  wchar_t* s = L"Hello from native C++!";
  wcsncpy_s(c, num, s, wcslen(s));
}

GetStringFromNative()'s job is to populate the array passed in argument c with a locally defined string.  The two C++ files share a common header, shown in Listing 4, which simply contains the prototype for GetStringFromNative().

void GetStringFromNative(wchar_t* c, int num);

Building the example

To build an single binary interop app such as this, you'll need to compile in dependency order -- in this case that means the native code first, followed by the interop code, and then finally the purely managed code.  As I mentioned earlier, Visual Studio 2005 doesn't support this build scenario, so you'll need to build from the command line.  In this simple example we're talking about 4 commands: one to compile each of the source code files and one to link them all together.  Let's look at these starting with native.cpp:

cl /c /MD nativecode.cpp

Pretty straightforward here; this compilation will generate an output file called nativecode.obj.  clrcode.cpp is only slightly more complex:

cl /clr /LN /MD clrcode.cpp nativecode.obj

In this case I'm using the /clr switch to generate mixed-mode native/managed output and the /LN switch to indicate I wish to produce a clrcode.netmodule output target containing metadata as well as a clrcode.obj target containing code.  Because this module contains a reference to the native code, I also need to pass nativecode.obj so that this file can be passed through to the link line when the compiler invokes the linker to produce the .netmodule.  Program.cs is of course compiled using the C# command-line compiler:

csc /target:module /addmodule:clrcode.netmodule
  Program.cs Properties\AssemblyInfo.cs

In this case I'm using the /target switch to tell the C# compiler to product a Program.netmodule target and the /addmodule switch so that it can resolve references to my C++ interop code.  I'm also passing the AssemblyInfo.cs file that was generated for me by the Console Application wizard, although this isn't a requirement.

Finally, I use the Visual C++ linker to link together the output generated by these three compilations into one executable file:

link /LTCG /CLRIMAGETYPE:IJW /ENTRY:ConsoleApplication1.Program.Main
  /SUBSYSTEM:CONSOLE /ASSEMBLYMODULE:clrcode.netmodule
  /OUT:MixedApp.exe clrcode.obj nativecode.obj program.netmodule

There is quite a bit going on here, so let's look at each switch.  The /LTCG switch enables link time code generation, which is required when linking in C#-generated .netmodules.  The /ENTRY switch tells the linker what function to use as the program entry point.  The /SUBSYSTEM switch is required when the linker can't use the entry point name to determine how to mark the executable.  The /ASSEMBLYMODULE switch must include references the the C++-created .netmodules containing the interop code called from the managed code.  The /OUT switch tells the linker the name of the output file.  Finally, I pass the .obj files created by the VC++ compiler along with the .netmodules created by the C# compiler on the link line.

Now that it's built, running MixedApp.exe produces the very exciting output:

Hello from native C++!

A lot of great energy in the comments on my last post on UI Frameworks and Efficiency.  It turns out that most of the energy was devoted to vociferous disagreement with my opinion, which I actually think is cool because it creates the opportunity for a conversation.  :)

There are a number of comments along the lines of "these darn managed code frameworks are fat, slow, flickery, and CPU-hogging." Let me give you three comments that are representative of the majority of issues.  First, reader Andre writes:

I've compared several UI toolkits, MFC as well as WinForms, and except two all others were unusable. The first thing I try is resizing the window and see if the window follows the mouse smoothly. My experience with those toolkits were horrible, flickering and the window repaints once a second on a 3 GHz machine.

On his own blog, old friend Marco Cantu writes:

I have to say the he misses one of the efficiency points, as .NET applications with a UI slow down because of the marshalling and protection of the Win32 API calls, not because of the nature of IL.

Finally, reader Me says:

If you decompile WFC .net managed code (using Reflector for example), you'll see it does lots and lots of things until it gets to Win32 dll layer. For me all this extra work takes much more time during the whole app life than startup clr and jit.

These comments represent the three issues that seemed to float to the top for folks: the perception that managed code frameworks are slow, the overhead of native/managed marshaling, and the relative thickness of the managed frameworks.

Let me first respond to these comments in general: Yes, I agree that managed frameworks are generally going to require better hardware for comparable performance.  For some people, that's a major issue, which is fine and one of the reasons we continue to invest in things like MFC.

To the first issue, I would say: let's not damn managed UI frameworks in general because of the issues with WinForms.  As reader Bosco points out, WinForms isn't hardware accelerated.  WPF, by contrast, performs far better than WinForms in visualization-intensive apps.  For example, here in DevDiv we have a major project where the team chose to "re-skin" an MFC application with a WPF UI.  The application core remains in native code, and the look & feel of the UI is way better than the old one with no noticeable performance loss.

Which foreshadows the second issue: interop.  Native/managed interop is definitely one of those areas where it's easy to do the wrong (i.e., inefficient) thing.  While there is still much room for Microsoft to improve interop performance, this is not a dealbreaker for most UI scenarios if the interop layer is well designed.  Case in point: Visual Studio 2005, which contains significant native/managed interop.  Why I'll fully agree performance could be better in areas, it's quite good overall, and I would consider it a success story for successful use of interop in a UI.

Regarding the relative thickness of the framework, sure, a lot can happen in between the user calling a framework API and the API calling the underlying GDI or DirectX thing.  Again, I'm not arguing that managed frameworks are every bit as efficient as a think native wrapper.  I'm arguing that the large boost in developer productivity is often worth the typically small performance cost.

Now, to answer a couple of specific related questions I noticed in the comment stream for this entry.  First, reader Andre asks:

Do you expect WPF to replace HWND/GDI based user interfaces entirely in the next years?

No.  I expect lots and lots of people to use WPF, but I don't expect HWND/GDI based UIs to go away for the foreseeable future.  Andre also asks:

On a sidenote, there is a huge gap between the january CTP and what you are promising in the Channel 9 video. I guess the "big investments" haven't been integrated yet, currently I couldn't even tell a difference with VS2005 for C++.

The "big investments" Bill and I discussed in the Channel 9 video won't start to appear until the next Visual Studio release after Orcas.  Although we started this work during the Orcas cycle, the work involved is significant, so we won't have anything customer-ready until Orcas+1.  Our first priority with this work is to greatly improve the experience around Intellisense and code-focused IDE tooling in general.  We've detailed a lot of the Orcas features on the Visual C++ team blog.

Finally, zakimirza puts in:

Oh and can you comment on why there has been a huge shift in frameworks so quickly. I mean, we were in the GDI reign one day.... a couple of years later we migrated to the GDI+ towns in .Net 1 and then in .Net 2..but suddenly we have WPF all around. Also, how much is microsoft using .Net itself in its top of the line products(for what i know and listening to sumit chohan, the manager at Microsoft Access, most of the code is native C/C++ code).

Well, let's talk about the framework shift thing first.  I have my own theory on this, which I'll share with you.  While it would be great to have One UI Framework to Rule Them All, my observation is that software development technology continues to evolve at a rapid pace, such that it is far more practical to design new frameworks to accommodate new patterns & technologies than it is to retrofit old frameworks.  This kind of jumps out at you if you just take a couple of steps back a look at the evolution from GDI's C API to MFC's hierarchy + bag of classes approach to WTL's templated C++ classes approach to WinForms' language-agnostic but clearly J++/WFC and Delphi/VCL-derived model to WPF's XAML approach for better integration between developers and designers.

As to how much we're using .NET in our own products, the answer is that we're doing the same things we're telling ISVs to do.  If we have investments today that are substantially native code, they're going to stay that way unless there is a compelling business reason to change course.  Probably the biggest example of where we've added managed code today is Visual Studio.  We have another couple of other interesting projects going on in DevDiv, one is the WPF UI with native code that I mentioned earlier and the other is a new app build entirely in C#.  Another example is Office 12, which uses managed code for much of the new server-side technology, while keeping the existing client-side investments predominantly native.