In a recent blog item, Robert Scoble suggests that Joe Stegman’s video on Windows Forms answers Joel Spolsky’s article “How Microsoft Lost the API War.”
Sorry Robert – but it doesn’t.
Make no mistake, Windows Forms is great stuff. Ok, perhaps you hype it a bit too much – that great looking Outlook application that is created with 100 lines of code largely looks like Outlook because it uses an Outlook control. But nevertheless – it’s great.
And yes, Windows Forms will “play” with Avalon. Microsoft’s “Developer’s Guide to Migration and Interoperability in “LongHorn” on MSDN chapter 5 addresses this.
But “play together” in this sense is an interoperability issue. Avalon and Windows Forms represent two different programming models or API’s.
Let me stress the word “interoperability” here. Sure, Avalon can host Windows Forms and vice versa. Just as Windows Forms today can host COM ActiveX controls. But do you know many people writing COM ActiveX controls for use with .NET? No.
Why not?
- Because people are reluctant to trust an interoperability layer, both from reasons of compatibility and reasons of performance.
- Because once Microsoft adopts and promotes a new technology (.NET), they tend to stop development and gradually support on the old one (COM).
- Because psychologically, developers want to play with the latest technology, and managers feel pressure to adopt the latest technology.
Having two technologies that have different API’s have all the costs Joel discusses such as the cost to learn a new technology and the cost to port applications (even when there is no feature, performance or economic benefit in doing so).
With Avalon and Longhorn we are faced with the same process. Sure Windows Forms is being invested in big time. Sure Windows Forms controls will be hosted in Avalon through an interop layer (and vice versa). It doesn’t matter. The same pressures will apply in just a few years to migrate to Avalon. There will be inevitable problems in the hosting, concern about long term support, and pressure in the media and development community to use the latest and greatest thing.
Sure, if you’re writing software with a lifespan of a few years, Windows Forms is a great way to go. But we all know that software, enterprise software especially, lives a long time. Can Microsoft categorically promise to maintain a full commitment to development, maintenance and support of Windows Forms for the next 15 years? (A more typical lifespan for enterprise software). Will they maintain that commitment during at time where their marketing department and media are pushing Avalon and Longhorn?
Do you really want to invest full bore in Windows Forms today given the uncertainty of which technology will become dominant, run on the most platforms, and have the best long term support?
For smaller applications, absolutely. But if you’re going to invest in a large project, this is a very difficult decision, and waiting for Avalon might be the better strategy. It’s too soon to know.
RSS feeds for sites referred to in this item:
Can Microsoft categorically promise to maintain a full commitment to development, maintenance and support of Windows Forms for the next 15 years?
I’m not sure any vendor out there can *promise* support for an API for that long. Are there any examples out there of fully vendor supported APIs that are 15 years old?
Microsoft is actually approaching that with the Win32 API, Java is only about half that old, so it’s too tough to tell if anything from the Java world will last that long. Something like Java’s AWT is likely to become deprecated sooner rather than later. And I don’t believe things are any better on the server side either. Who knows what Java server-side code will look like in 5 years, much less 10 or 15. If I had to guess, new frameworks and APIs will developed that have compelling reasons to switch to them, and support and interest in todays current frameworks and APIs will fade away.
It might not be unreasonable to assume that WinForms will be supported in 15 years, but it may just be considered “old school” at that point. The best you can hope for at that point is a clean upgrade path.
I think the comparison between COM Interop and Avalon hosting of a Windows Form control is not entirely fair. COM Interop is much more complex (and therefore error prone) because of the managed/unmanaged marshalling, different memory model, etc. Windows Forms being hosted by Avalon are much simpler matter because they are both running as managed code on an evolved version of the .Net framework.
Can Microsoft categorically promise to maintain a full commitment to development, maintenance and support of Windows Forms for the next 15 years?
They can’t. Every 3-5 years Microsoft comes up with some entirely different developer API library that’s always touted as the next best thing to happen to this planet since the sliced bread. Everything else, according to MS evangelist forces, is pure crap and even your lame “but it works for me” gets silenced away in the corporate propaganda machine.
So totally agree with the Windows Forms limited shelf life. Hard to believe, but a lot of computers out there are below the requirements necessary to run .NET framework – they are just Win 95/98/2000 PCs that ran for years at customers’ locations and are not to be replaced immediately. You can use Windows Forms but in 2007-2010 timespan expect Microsoft come up with the new best thing and the message that only losers use the “slow and confusing” technology that Windows Forms will be labeled as.
I agree that the comparison between COM and Windows Forms is a specious one. Almost every app built for Windows to date is a “Windows Forms app” of some kind– we can’t say that about COM. Forms is just a standard UI convention that people understand. It should live on. COM, on the other hand, was a highly complicated and mostly failed object abstraction model. I don’t think too many tears will be shed when the last COM object is dereferenced..
Responding to #2 and 4
ActiveX/COM effectively wrapped the core Win32 API – specifically the USER32 API. And yes, in doing so it added complexity, yet the underlying UI portion of the API remained the same. Windows Forms also wraps the core Win32 API – it just does it better.
Avalon (at least on Longhorn) doesn’t use USER32 – so to say that interop will likely be smooth because both Windows Forms and Avalon is managed is wishful thinking. The differences (and interop) is happening at a lower level, but still represents interop between two huge and complex user interface and messaging systems.
“Windows Forms” in this context refers to the .NET managed wrapper over USER32, not generic Windows forms applications. I too will be glad to see the COM wrappers go away, but this doesn’t change the logic of my argument. Three years ago the pundits may be saying the exact same thing about Windows Forms. There lies the heart of the comparison, and the problem.
There’s a huge overhead to new technologies. Part is the time needed to learn the new stuff, while you throw away that high level of competence you got with the old system. Of course if we get evolution not revolution it’s great on all fronts. (This applies very strongly to web content.)
We’re just getting over the .NET transition, we don’t want to waste the time spent learning. (Just yet!)
Responding to #5. The problem with your argument regarding the pundits is that often Microsoft changes API too often. One very simple example is database access API’s. Let’s see, ODBC, RDO, ADO, ADO+, DAO, and a few others that evade my memory. This is not just one or two API’s. Essentially MS’s track record on database API’s is to introduce one every 1.5 to 2 years. That is downright silly.
This is what bothers people. Along comes a new OS, and yet again a new API that is “better” and more interesting. As IT is a mature market this is not what people want. There are UNIX GUI applications that are twenty years old and can be compiled today and run on any UNIX operating system. Not that I think it would be a great GUI, but the fact of the matter is that 20 year old UNIX apps still work today! And enterprise’s like’s that kind of ROI.
I don’t see the Windows Forms – Avalon being a major problem. If you design you application in an OO way, the forms layer is simply for presentation. If you want/need the look and feel of Avalon, rewrite the presentation layer and use your existing Business Objects and data layer.
Hey Dan, I’m a bit confused by your comment, “that great looking Outlook application that is created with 100 lines of code largely looks like Outlook because it uses an Outlook control.”
Not sure what you mean by this. Joe’s Outlook sample has *no* interop code in it nor uses any aspect of Office. It is completely written with Windows Forms controls that ship in the box. The majority of the UI is based on the new ToolStrip control. The left pane is a ToolStrip in split stack layout with a owner drawn TreeView. The middle pane is our new DataGridView control and the right pane is the WebBrowser control.
As you said, this is not pressure of Microsoft to change API. It is pressure of developer’s psychology or even pressure of our nature.
If all we so want to switch API, why really don’t do it?
Speaking about future WinForms support, you can find now some DOS software and run it on latest Windows XP. Is it runs? To be honest not always. But really very often it runs!
As you can see, Microsoft now supports API of 20 years old. Don’t say you are worying about 5 years it seems ridiculous.
And what software will be staying valuable after that 5 years?
Regarding 11:
The main window of the Messenger app is 100% Windows Forms. It uses the Messenger APIs to populate data (get a list of contacts, get their names, get the hotmail message count, etc).
However, the chat windows spawned from the main window are created by the Messenger API.
These apps should all be up on http://windowsforms.net soon so everyone will be able to go there and see the code for themselves.
What about using the browser? The uncertainty about what Windows UI to go for and moreover the longer-term uncertainty about what our clients are going to look like in a distributed world, indicates we shouldn’t write off browser-based interfaces just yet.
The trouble at the moment is the lack of a decent, richer browser-based UI framework. Technically certainly possible using JavaScript/XML/DHTML, but commercially not appealing for a company like Microsoft. However, I am pretty certain there is at least one party working on such a solution.
If such a framework were to appear, I would feel much more comfortable going with it than with WinForms or Avalon, as its lifespan compares to the lifespan of the web browser (still going strong) and its reach is much wider than the current Windows versions and the required hardware resources to run them.
Regarding 9 and 10:
If we all want to switch API, why not do it: Because as professional software developers we have a responsibility to make choices that are economically sound, not just fun. And rewriting your code to a new API only makes sense if the features justify the investment (which is rarely the case). If the software you are writing has a life span of only 5 years, it’s not a problem – but I’ve seen studies that suggest enterprise software lifespan averages as much as 15 years.
Mike’s right – in the video the reference was to a messenger control in the messenger application. However, I’m not going to edit the original message because it really doesn’t impact my argument. Let me reiterate: I have nothing against Windows Forms. I think it’s great. In fact, if Windows Forms takes off within the next year or two it wouldn’t surprise me if it becomes the dominent long term standard rather than Avalon.
Within (approx.) than 5 years we’ve had:
MFC/VB > WinForms > Avalon
DCOM > Remoting > Indigo
FAT > FAT32 > NTFS > WinFS
RDO > ADO > ADO.NET && ODBC > OLEDB
Innovation is one thing. Endless, reckless flavour of the month fads are another. I don’t know of a single non-developer PC in my universe that has a single .NET app deployed on it yet. And already two of its underpinnings are being shuffled towards the graveyard.
OK. Suppose I do not prefer use and spawn new API. But why me worrying? I can use â for example â COM. COM is here now and will be in future 10 years or so.
Old technologies are bad in just single way. Microsoft very often presents new cool technologies that make older ones relatively ugly.
Imagine BMW tomorrow will release new hot cool car. Without weels, on magnetic energy engine. And for price $20,000. Of course all today modern models will goind to seems like crazy willage carts.
Is it better not to release such hot magnetic futurism car to keep carts living? I don’t think so.
So looking from 2006 point, WinForms is sure ugly cart. But who is walking now waiting for magnetic BMW? I don’t see that guys, all we are driving (relatively) ugly cars.
Responding to 13:
There’s also XUL (XML User Interface Language), that can be used to create really nice web applications. Unfortunately it is Mozilla only; and I don’t know anyone who seriously uses it.
The new ATI catalyst control center is a .Net app. It could be the start of a bunch of real .Net apps.
Regarding 14:
“I donât know of a single non-developer PC in my universe that has a single .NET app deployed on it yet.”
If you, a friend, or a family member have purchased an HP printer, scanner or digital camera in the last year and half then you know someone running a .NET app.
The HP Image Zone app is written with Windows Forms. For more info on this app, see: http://www.microsoft.com/resources/casestudies/casestudy.asp?CaseStudyID=14965
Regarding 3 (sorry for all the posts):
The .NET Framework 1.1 will run on Win 95, 98 and 2k. The .NET Framework 2.0 will run on Win 98 and 2k.
As far as the comment about Windows Forms being labeled as “slow and confusing” in 3 – 5 years, well, Windows Forms might be labeled as slow, but the API is as easy to use as Avalon will be. In fact, we’ve sent some of our top brass (ChrisAn use to be our architect) over to Windows to make sure the Avalon team produces an API that is both easy to use and scales well.
Regarding 19:
Don’t apologize for the posts – you’re very welcome. Frankly, while Windows Forms might be somewhat confusing for someone coming in from VB6, it’s a HUGE breakthrough for those coming from MFC or ATL – providing an architecturaly clean forms model, while still building on familiar Windows concepts.
My concern with Avalon is that even if it is an easy API that scales well, if it is fundementally unfamiliar to developers – i.e., a truly new API, well – we’re back to Spolsky’s issue. Asking developers to learn and worse, migrate to yet another completely different API is a big deal. Will Avalon be truly that much better as to justify the effort? Or will people migrate just out of fear that Windows Forms will go away, much as many of today’s VB 6 developers are porting code to .NET purely because of concern about long term viability of their VB6 applications?
Actually the video of joe proves nothing but they took a deep look on delphi which was able to do “his cool stuff” since years ‘at design time’. Not very impressing, maybe except for some VB hackers.
Unfortunately there is still no real good abstraction I know of that separates UI from the business logic and gives some freedom concerning platforms. QT4 could be a candidate but the commercial licence is just too much.
Despite of that, I will follow the the crowd and emerge some apps to windowsforms as far they are not too important.
Response to 18 : “HP printer, scanner or digital camera in the last year and half then you know someone running a .NET app.”. It’s installed, this doesn’t make it used. And it’s not only HP printers, it’s HP computers as well with .NET 1.1 pre-installed.
Response to 20 : “itâs a HUGE breakthrough for those coming from MFC or ATL “. Dan, have you written a significant app with Windows forms? 1) lack of ON_UPDATE_CMDUI, and other such mechanisms 2) lack of friendly localization mechanism. 3) lack of full round-tripping with WIN32 windows API means yo uhave to P/Invoke. But in turn, P/Invoke is a security problem : a) needs user approval at run-time (non-admin scenarios) b) pretty much all WIN32 API method calls can be redirected by some third-party plugin.
Reponse to 23:
I’m primarily a component developer, not a UI developer. So whether I’ve written anything significant depends on your definition of the word.
1: ON_UPDATE_COMMAND_UI is an MFC construct, and before .NET I wrote UI apps in VB6. I found it much more productive than MFC.
2: Huh? Localization in Visual Studio is quite easy, though confusing at times.
3: True, but those security concerns apply equally to VB6 and MFC. At least here you have the potential for creating secure UI apps, but that’s a topic I’ll be writing about soon on the main blog.
What bothers me most about Joel’s argument and the claim that the API should be stable (or able to be stable) for 15 years is that they both encourage inaction. Before you know it, your app will be 15 years old and in the give-away pile at CompUSA.
Response to 24:
1: ON_UPDATE_COMMAND_UI provides a common routing mechanism that you don’t find in VB6, in particular you can have a single command id bound to as many UI controls as you want. When comparing with VB6, you are not only comparing apples and potatoes, you are also forgetting about a design that builds for many years and keep changes at a marginal cost.
2: May be I am the only one having to resort to command lines to handle these things, where the command lines are both those from the tools from the VisualStudio package, and tools that have to be developed anyway.
3: The concern applies to VB6 and MFC. What about the sandbox then? ISn’t .NET supposed to perform a full reset on the unmanaged world? Think it over, by using .NET you are trading one technology for another, you are adding more matters to existing matters. The beauty of VB6 and MFC is that the behavior are known and won’t change now anyway given there is no run-time change anymore. What about .NET, I hear that .NET 2.0 and .NET 3.0 both change the binding policies in dramatic ways…
Want to beat Microsoft? A huge amount of effort is wasted having to rewrite things everytime Microsoft decide they need to sell us a new suite of tools. Microsoft’s track record at ‘protection of investment’ is so bad you’re a fool if you’re going to bet your company’s future (or your job) on it. Java has been so effectively torched that many people no longer consider it an option. Great marketing work, but look at C#/.NET. How long do you think that is going to be around? No perfect solution, but if you bet the farm on any tech that Microsoft bring out you’ll be rewriting it in two years time. And if I happen to be your boss, I am going to fire you.
Folly. WinForms provides a level of abstraction of a bunch of standard widgets that have stabilised over twenty years: text boxes, tabsheet managers etc. Tiles and sexy rendering do not affect the need for these widgets; long after Longhorn has come and gone we will still have scrollbars and textboxes and buttons. Most of the graphical goodies of longhorn are at a lower layer of abstraction than that presented by the widgets of WinForms, so this whole discussion is largely without meaning.
Response to 23:
“lack of friendly localization mechanism”
No, one of the strengths of Windows Forms is localization. We had to beat up Microsoft to think about the rest of the world, but this time they’ve done a good job.
Have you tried setting the Language property of a form in Studio? You can enter strings for another language just as you did for your native language. Studio does the rest.
You can ship an application, then send follow-up satellite assemblies for further languages without having to change the original app.
So, in what way unfriendly?
I agree with 21. Borland Delphi can do this stuff for years now!
People should reconsider winforms. I, as a delphi developer will stick to Win32 development for now because delphi provides a smooth migration to .net, and they will (i guess) to Avalon as well. (VCL has been ported many times succesfull Win16->Win32->Linux->.NET which are all compatible (except for platform specific stuff) In other words I could build a Win32 app and recompile to .net.
Response to 7: Most 20 year old Windows applications can run on current versions of Windows too, so I don’t see Unix being superior in this instance. On the other hand, how many 20 year old Unix GUI applications run on a 1984-class PC (8088, 640K etc)? The point is that Windows and Unix were not designed for the same reasons and were shaped by radically different market forces.
The real question is what kind of programming does one want to do for a living. Do you want to be able to exercise your creativity doing something unique or do you want to integrate a bunch of boring pre-made drag and drop components for some mind-numbing bean counting application? Who cares if you can instantiate an outlook object and work with it?
“Studio does the rest.”
*ack* Just like the VB IDE did? I don’t want to be wrapped in cellophane. I don’t want all those bells and whistles. Mostly because as soon as I’ve gotten into a groove with them (2 years or so), the powers that be will change things around, add a bunch of features I’m not interested in, and remove a feature that I’ve come to depend on. Software tools by lowest common denominator feature determination are just that. The MS tools are great if you aren’t working on something serious.
Response to 32: So basically you’re saying it is better to re-invent the wheel and dismiss all forms of productivity aids because it makes you a more serious programmer? The reality is we generally develop for business needs and usually large factors in this are cost and speed of deployment.
In addition, if components are re-used and isolated then surely there is a reduced risk involved of anything going wrong.
Finally, do people really think it won’t be possible to support .NET / WinForms apps in 15 years? I mean, as long as you have the tools it is still possible to support apps from the last 15 years – even if the host operating system has been updated on numerous occaisions. At the very least, virtualisation of the operating system will provide these capabilities.
Obviously the only downside in the previous statement is finding the right skills to support such an app – however, languages and APIs are neither here nor there as long as there is adequate documentation. I don’t think it is that difficult for an experienced developer moving from one paradigm to another. Just read a few books. Sure this is a slight overhead, but that is offset against the length of time the application is in service. Besides, how many Unix apps are written using antiquated methodologies?
This is why I use alot of visual foxpro. 2O years of backwards compatiblity and can do anything VB (well, 98%) can do. The data bound language more thn maikes up the other 2%.
“The .NET Framework 1.1 will run on Win 95, 98 and 2k. The .NET Framework 2.0 will run on Win 98 and 2k.”
Not true. .Net 1.1 does not run on Windows 95. Runs on Win 98 and above (just like 2.0) but requires IE (5.5+ I think), which is automatically included with Win200 and above.
IN MICROSOFT’S BOAT
If you write your software in the same “langauge” (platform?) as Microsoft Office, I think you’ll be safe. That puts you in the same boat as microsoft. They aren’t going to shoot themselves in the foot. So, I’d put my foot on top of Microsoft’s .
My understanding is MS Office is written agains the Win32 API, right?
When they rewrite it in .net, I’ll rewrite MY 20 shrinkwrap (vb3 ) apps in .net.
And where will .NET/WinForms get you in 5 years time when your customer is demanding that your app runs on a non-Windows OS? It may just get you fired.
“Java has been so effectively torched that many people no longer consider it an option”
Wake up, spend less time on the MSDN site and get out there and read some objective commentary on the industry’s direction. You might then come to the conclusion that any Windows-only technology has nothing to offer in the mid-term anyway.
The enterprise CTOs I have spoken to in the last 6 months all state that they have Linux on their mid-term radar. And not just in the data-center. They will consider anything that helps them become more cost-effective – and goodwill generated by Linux on servers is giving CTOs reason to rethink their client strategies too.
If the lifespan of the average enterprise app is indeed 15 years (as mentioned by one of the posts here) then any CTO worth their salt should be demanding OS-independence from their developers NOW.
Follow this line of thinking and you will come to the conclusion that both WinForms and Avalon are dead-in-the water for enterprise development.
Java, SWT and the Eclipse rich client platform might just be worth another look…
Steven Williamson: you forgot Java Web Start. It’s a rich client over the web (with a lot of features, like configurable auto-updates, etc). I ‘m a .net and java programmer, and Java has the same api working since 1.1 version. And .NET internationalization is to poor (see all problems with keyboard shortcuts and internationalizated texts). While MS are putting news database api, in Java we have JDBC and Entity Beans for 10 years.
No, we have not had JDBC and Entity Beans for 10 years. Java has not even been available for 10 years.
JDK 1.0 was released on Jan 23, 1996, less than nine years ago. I think JDBC was not in 1.0 but was in 1.1 which was released on Dec 11, 1996 (less than eight years ago). EJB was announced Apr 2, 1997 and the 1.0 spec was released in late 1998.
Source: the first hit when you google “Java timeline” is:
http://java.sun.com/features/2000/06/time-line.html
Itâs a rich client over the web (with a lot of features, like configurable auto-updates, etc). I âm a .net and java programmer, and Java has the same api working since 1.1 version. And .NET internationalization is to poor (see all problems with keyboard shortcuts and internationalizated texts). While MS are putting news database api, in Java we have JDBC and Entity Beans for 10 years.