« Human-like Software | Main | Not the Microsoft I Once Knew »

October 08, 2003

All These Frameworks

I thought with the introduction of the .NET Frameworks and WinForms, that we had finally seen the end of an era where multiple APIs proliferated in the windows platform like MFC, VB Runtime, Win32, WFC, CRT, DHTML, and every other runtime of every other non-Microsoft language like Delphi. Although WinForms was still new and not as mature as MFC, there was that feeling that it would reach the polish of MFC and eventually exceed it; and that could happen with Whidbey.

But, then, you know, Microsoft presents us with this new Avalon API set. I don't know which group owns WinForms, but if I were to guess; it seems, as if WinForms was produced by developer division, but the OS division decided that, since they own Windows, they can do more than a wrapper implementation and actually BE object-oriented and can actually EXTEND the feature sets of all these objects, and so they want another crack at a managed Windows API. For years, Windows have been lambasted for it's lack of object orientation. (I could be wrong; Windows could have developed the WinForms API; I know, for instance, the GDI guys built the System.Drawing namespace.)

To be fair, with the dramatic changes that Microsoft already announced in WinHEC, with the long overdue overhaul of both USER and GDI, it makes more sense to build the Avalon library from scratch, rather than base it on the wrapper library that is WinForms.

One thing is different now. The whole world of Windows has become managed, so there is a consistent type system, consistent deployment story, and cross-language interoperabiliy. With this managed world, we may see API support for advanced constructs like generics.

I don't think we are face an all-or-nothing proposition as before. Avalon and WinForms are both managed, so naturally they can coexist with each other. Only one part of the .NET namespace is affected-- System.Windows.Forms; the rest of the .NET framework is shared. Session "Windows Forms: Exploiting Windows “Longhorn” Features from Within Your Application" has this to say:

Learn how Windows Forms and "Avalon" can work together to make awesome applications. See what work the Windows Forms team and "Avalon" are doing to ensure that there is a clear path for preserving and migrating Windows Forms investment in the "Longhorn" space. See examples of Windows Forms hosted in "Avalon" and "Avalon" hosted in Windows Forms, and how to architect your Windows Forms applications to be best prepared for "Avalon" and "Longhorn"!

As for MFC, the PDC does contain a session on Longhorn-MFC integration. If a managed version of MFC is provided in Whidbey, which isn't clear from the roadmap announcement of MFC support of the CLR, integration of MFC with Avalon and WinForms could be more seamless.

Here's my assessment: The traditional Win32 API is dying except for the Kernel, because it's a flat API, which severely limits the sophistication of applications that utilize it. WinForms and MFC will remain important because Avalon apps only run in Longhorn only and, being a 1.0 product, may require another rev to mature. MFC will continue to be enhanced and supported but it's not the company's direction, so it will be in perpetual maintenance mode. WinForms will continue to be enhanced and probably will have a much longer life span than MFC, because it is managed code, easier for company to enhance, and cross-language (More VB/C# users than C++).

The official Microsoft story is coming at PDC.


"Avalon and WinForms are both managed, so naturally they can coexist with each other".

I would love to work in a large project using winforms (to last a whole decade), only to be told that the layer is no longer supported.
When you know statistically how much winforms apps use untrusted code, this won't make easier the transition to true managed code. And I am afraid winforms is not a good transition to it, being too coupled with WIN32.

Stephane, is your only role in life to critize everything and anything? What should it be? C and Win32 and you'll be happy because nothing has changed from your skill set? I have never seen a positive post from you in all the posts all over the Internet. What do you favor? Do you really think that doing Windows/Win32/MFC/C++ is more productive than WinForms? How can you support this view when it takes orders of magnitude more effort, code and fustration? WinForms is not perfect but it makes developers far more productive.

The claim winforms is more productive than MFC is gratuitous without facts. I am listening.

MFC still has some features that WinForms does *not* have. One is the whole Docuement View Architecture thing. That is for sure. But it takes a very skilled C++/MFC programmer to program effectively in it. It's all about friction. The friction is extremely high for MFC. It takes an average of 6 months for most developers to learn and truly become proficcient in MFC. Your skill set is now pretty high in MFC but it took you a while to get there. There all sorts of nuances and tricks. Now the problem with Windows DNA development is that there are a whole slew of class frameworks each one with a *different" class library and being proficient in one does not translate into even being familiar with any of the others. The Delphi model is different than the VB6 model is different from the WFC model different than the MFC model. On many Internet projects, many developers are forced to learn many different models.

The huge productivity gains from WinForms (and the whole .NET Framework) is that instead of 10 divergent class frameworks that work completly differently from each language, there is one equally accessible and used the *same way* from all languages. One set of namespaces with classes that work the same way.

Productivity = programmer productivity NOT machine productivity. In this day and age who gives a care what its doing underneath. I now have a level and simple to use framework that I can use from any CLR language. I started programming with C/Win API in Windows 2.0 and have progressed through MFC and such. I have been programming in C++ for over 10 years and I can absolutely 100% guarantee I can develop my GUI apps with C# and WinForms 70-90% faster than C++/MFC. I have been doing it for quite a while now. I can also do it without spending weekends chasing down memory leaks, object references and all the ugly things that plague C++/MFC developers. I wouldn't go back for all the money in the world-)

"MFC still has some features that WinForms does *not* have". You got to be kidding right? MFC classes are extensible, unlike winforms. And has thousands of ready and fancy controls with source code, all for free downloadable from the net, and ready to use.

"One is the whole Document View Architecture thing.". http://www.codeproject.com/csharp/sdimdiwizards.asp Huh?

"But it takes a very skilled C++/MFC programmer to program effectively in it.". 90% programmers start with samples that come with the CDs, and samples from the net. Then they figure out sites like codeguru, codeproject. There is no skill involved here. For most projects, copy/paste ability with some distance is enough. And before you get into the afx_managestate() troubles, you'll have completed at least 10 significant projects.

" The Delphi model is different than the VB6 model is different from the WFC model different than the MFC model". Untrue IMHO. Both share a common C/COM plumbing and, thanks to it, a C++ MFC COM guy can get up to speed in Delphi in just 2 days.

"On many Internet projects, many developers are forced to learn many different models.". Yeah HTML markup is changing so much these days that IE releases have a hard time coping with it.

"The huge productivity gains from WinForms (and the whole .NET Framework)". Which shows you didn't get the point. The .NET framework is a fantastic piece of work, and is here to stay. Winforms, a tiny fraction of it, is crap however. On the one hand classes are sealed, on the other hand customization is hardly possible. In case you didn't know, it's intentionally sealed as a result of being an ultra thin WIN32 wrapper with no possibility to take advantage of object orientation.

"One set of namespaces with classes that work the same way.". I agree here. Winforms share a common misconception.

"Productivity = programmer productivity NOT machine productivity". Why part of the sentence do you miss in "MFC has a class wizard too" ?

"In this day and age who gives a care what its doing underneath". Not doing good a point on your side I am afraid. What is required is what the customer needs, (or what you invent). Tell me you don't need to go underneath when the app you started 5 minutes ago is already leaking 200 megabytes. Any app might require to go at an arbitrary depth and at this point you might choose MFC/C++/COM (some might recommend MC++) for this, for others you might need asm, and for some apps C# winforms could just be enough. I think it's gratuitous to claim "underneath plumbing" is not required. Let's take an example. You take the MS Office PIA, and write an Excel chart generator using automation. It takes two hours using C#. I write the same from scratch, without Excel automation support, and I need two weeks to do it with raw C/C++. At this point you win. Now you are selling the app to your customer. What are the problems ? nightly enterprise reports based on your solution require more than 8 hours of calculation and generation, with the consequence that employees cannot open reports when the step in in the morning. Mine takes 20 times less. Besides that, it looks like, due to marshalling leaks (in .NET 1.x) your solution breaks after a few hours (blocking VBA errors, low virtual memory, ...). What solution do you think the customer is buying?
(the scenario is a slightly changed one from what has happened many times in the company I am working for).

"I now have a level and simple to use framework that I can use from any CLR language". I agree. But we are not talking the winforms anymore here.

"I can absolutely 100% guarantee I can develop my GUI apps with C# and WinForms 70-90% faster than C++/MFC". Cool. I am pretty sure some experienced MFC guy could pledge the exact opposite figures. But ok, let's assume statu quo in this area.

"I can also do it without spending weekends chasing down memory leaks". I am not sure it related to the beginning of the discussion. There are memory leak tools, com interface leak tools, gdi handle leak tools, and plenty of profilers available. So what? (try playing with the built-in .NET source code profiler by the way, and prepare to die!).

"all the ugly things that plague C++/MFC developers". The level of control is totally different. On the other hand, I don't see what's ugly. Let's assume the first impression counts most, don't you think you have more "gpfs" (not really, but users end up with a miserable box so it's pretty much the same) with .NET apps than unmanaged apps, since exceptions is the standard way to signal errors?

This discussion might continue if you like, but I am not sure wesner agrees we pollute his weblog. So in case you are willing to add more be nice and send an email to fakedNOPAINwar@hotmail.com isntead. I accept your arguments although I am not convinced. Been playing with winforms for a year and a half, not convinced. I am convinced though of the amazing services in the CLR that I would otherwise have to rewrite, but are we talking winforms?

You said that "the GDI guys built the System.Drawing namespace". I think this is mildly misleading. As I understood it, the System.Drawing namespace was deliberately a more or less direct copy of the unmanaged GDI+ API. System.Drawing was basically done by one guy. I met him in Redmond about a year ago (along with a load of other techies from the Windows Forms product group) and when I harangued him about the non-existence of an object model to represent vector drawings, he explained that since he was the only person working on the System.Drawing namespace, the only thing he had time to do was to make a copy of the existing unmanaged C++ API.

So it's not quite true to say that the GDI guys built the System.Drawing namespace. System.Drawing is a very close copy of the unmanaged GDI+ API. (And presumably the unmanaged GDI+ API *was* built by the GDI guys.) If you compare these two APIs closely, they are strikingly similar and yet not quite identical.

As for who built Windows Forms, that team mostly came out of the WFC team, I believe. WFC was Microsoft's windowing library for J++. For a long time, Mark Boulter was in charge of the Windows Forms group, having previously been a senior guy in (and maybe in charge of) the WFC group. He is still a PM on the Windows Forms team, but the last time I saw him (June this year) he had stopped giving his job title as Lead PM, and was just calling himself "a product manager". I got the impression (although this is pure speculation on my part) that he was in the process of gradually handing control of the team over to Shawn Burke, prior to going and working on something else. Although it may just be that the team has grown enough that it's too big for him alone to be in charge of, so Shawn may just be stepping in to share the work load.(Shawn has been involved in the Windows Forms team for ages - he wrote most of the articles on the Design Time stuff. I'm not sure what his previous background was.)

For what it's worth, here's my take on the Windows Forms vs. Avalon thing. (And I speak as someone with a vested interest in Windows Forms, having written a book on the subject...) Windows Forms feels like a stop gap technology to me. It is a bunch of wrappers on top of Windows that enable you to use .NET for writing Windows apps. But it doesn't address many of the age-old problems that Windows itself suffers from, most of which are due to the sheer age of the Windows HWND and event models. (Basically, they can't change anything, because some age-old application that some important client somewhere has been using for the last decade will stop working...) The old model has many shortcomings.

In the .NET 1.0 timeframe, they didn't have the option of introducing anything new, not least because it requires platform changes. (And you only have to look at Java's abysmal record for UI performance to see what happens if you try to replace the platform's windowing system instead of working with it. Admittedly, Swing improvement has now improved to the point where it's possible to use a Swing app all day without going mad. But it's still noticeable very much slower than a native Windows app.) So Windows Forms is really a fairly thin set of wrappers around the underlying platform.

I think Avalon is what they really wanted to do. But since Longhorn isn't going gold any time soon (it appears to be increasingly unlikely that we'll even see a final version in 2005 judging by recent noises emanating from Microsoft, 2006 looking the more likely candidate now) something like 4 years may well have passed between .NET 1.0 shipping, and Avalon becoming available. So there was a clear need for a stop gap, and I think Windows Forms was that stop gap.

And it works pretty well...

The comments to this entry are closed.