Sep 21, 2004 | Software Development
In my recent blog “Spolsky 1: Scoble 0 – Stegman’s Video, while Great, doesn’t apply to the API war” the most surprising results were in the responses. While many did address the focus of the item (that of API changes), there were a number of responses directly relating to Windows Forms as a technology. Recently, Mike Harsh elaborated on this topic as well. Clearly there is interest in where Windows Forms fit into the greater scheme of things. I think this is worth of further discussion.
It’s possible Mike may be too conservative about the future of Windows forms. Curiously enough, the very issues that Joel brings up with regards to the API war actually work in favor of Windows Forms. You see, even though Windows Forms is a managed wrapper for User32, the key point is that it does wrap User32 – the old Win32 GDI API that every Windows developer in the world is familiar with.
So here comes Avalon – a new approach and new API. Do the features that Avalon promises truly justify the investment in learning this new API? It’s too soon to say. It will likely prove compelling to those developers who really need to take advantage of new UI features, just as the DirectX API is worth learning for those who need that capability, but that may prove to be a minority of Windows developers.
My point is this – you have a huge number of Windows programmers, who grew up and know User32, how it plays with VB6, MFC, ATL and now Windows Forms. Do you really think they’re all going to just jump to Avalon overnight? Over a year? Over 10 years? .NET has compelling advantages over COM, and the transition is proving very slow. There’s every reason to believe that the transition to Longhorn and Avalon (that in my mind are still classified in the category of vaporware) will be as slow or slower. If there is no compelling economic advantage, Windows Forms might be the dominant managed forms package for many years.
Unless, of course, Microsoft abandons Windows Forms, either on purpose, or by implication (say, by failing to make interop work as smoothly as promised on future OS’s).
It’s a tough problem. Technically, I do believe Windows Forms is better than VB6 or MFC. But it suffers from the .NET distribution issue. Even ClickOnce may not change that (a topic I’ll be writing about soon). Avalon will suffer the same runtime distribution issue, plus the additional problems of limited OS support and the need to learn a new API.
I was discussing this earlier today with Christian Gross, and he suggested I take a look at GTK# . I doubt it’s as cool as Avalon, maybe not even as cool as Windows Forms. But I must confess, the idea of a forms package that runs on Windows, OSX and Linux is intriguing. Something to look at… in my copious spare time.
Sep 14, 2004 | Software Development
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:
Joel on Software
Scobleizer
Sep 13, 2004 | Software Development, Technology
Let’s start with the obvious. Almost nobody reads software licenses. You know why – they’re incomprehensible, too long, and in cases where you have to use the software anyway, you’re stuck with the license regardless. The only exceptions are the large corporations who have the lawyers, time and money to deal with them. Normal people don’t bother.
Unfortunately, this has some pretty serious side-effects. Aside from the obvious fact that millions of people are in effect agreeing to contracts they’ve never read, one of the common ways that spyware and adware are spread are by having users agree to them without realizing they are doing so.
I think it is time to completely revolutionize the way we deal with software licenses. To do so, I offer the following modest proposals.
-
A law should be passed that restricts the length of software licenses for consumer software to no more than 500 words. For comparison: the BSD Open Source license is 225 words, The Claria (formerly Gator) adware license agreement is over 6600 words (15 pages single spaced).
-
Software licenses must be written in plain language that can be clearly understood by the average 13 year old.
-
Security updates to software may not include any license terms that were not present in the original software.
-
No license for released (not beta) software may include any terms that restrict speech, review or benchmarking of the software. For a software publisher to restrict free speech and commentary on their products is shameful and unethical. I do think, however, it’s fair to require that any benchmarks include the source code of the benchmark so people can independently review the results.
My Challenge to Microsoft
As the software industry leader, I call on Microsoft to take the lead in coming up with creative and user friendly solutions to this problem. To start with, try taking the software licensing process out of the hands of your lawyers, and hand it to your user interface people. They’re good, and if they can’t figure out a way to revolutionize software licenses so they work, then we should all go to open source, because the situation will truly be hopeless.
My Challenge to the Government
Yes, I know – asking Congress (which is made up primarily of lawyers) to create laws that simplify license agreements seems like a long shot. But I can dream, right?
How else do you think software licenses need to be changed? Comments welcome.
Sep 3, 2004 | Security, Software Development
This week I was quoted in an SD Times story about 64 bit Windows. In it I say:
“Migration to 64 bits is likely to be slow, as is migration to any new technology. What’s more, delays of major products from Microsoft are common, so it’s hard to get excited about them.”
Now, for the record, I was not misquoted. Nor was this taken out of context. However, also for the record, I’d like to include the remainder of the quote that was not included in the article:”
Not only are delays on major products common, but as an industry we would much rather Microsoft take the time needed to “do it right”, and make sure the technology is secure and reliable, than to rush something out the door.
Kudos to Microsoft for having the discipline to wait until it’s truly ready to ship.
Now, on another note. I saw the most remarkable phishing email scam today. The misdirected link was subtle and hard to spot in the message source code, even when I knew what I was looking for. I wrote up a description of this IE specific attack at alwaysuseprotection.com. Visit the page using IE – it’s a trip.
Aug 30, 2004 | Software Development
Like many developers, I’ve started the process of getting acquainted with beta 1 of Visual Studio .NET 2005, along with the new versions of both C# and Visual Basic .NET. One thing has become increasingly apparent – Microsoft is effectively abandoning the Common Language Specification (CLS).
If you think back a couple of years when .NET was first announced, the CLS was one of the lynchpins of the .NET message. The idea that every .NET compatible language would be able to work seamlessly with any other .NET language was one of the key innovations of .NET. This meant you could create components in any language, and easily use them from any other – a vast improvement over the previous generation where mixed language development required great care to match calling conventions, parameter count and type, and responsibility for reference counting and memory management.
There is no doubt that .NET is a huge improvement over previous approaches. As a component developer, and someone who strongly believes in software reuse and component based software development, the CLS was gospel. I believed that every assembly should always be CLS compliant (even private code, in the hope that one day it might be refactored into components). Visual Basic .NET 2002-3 produces CLS compliant code by default. C# does not, though it’s not hard to maintain CLS compliance, and the compiler can check for it if you wish.
With Visual Studio 2005 it seems clear that Microsoft has effectively abandoned the CLS in favor of a new standard: specifically – the set of language constructs supported by Visual Basic .NET and C#.
Want proof? Visual Basic .NET 2005 no longer creates CLS compliant code by default.
And you know what? Microsoft made the right decision in this case. Leaving these features out of VB .NET would have crippled the language (both in perception and in reality, though mostly the former – a subject I’ll return to later).
The three major non-CLS compliant features I’ve seen so far are generics, unsigned variables and different access levels for property procedures. All of these are extraordinarily useful features for VB .NET. All will make it easier for VB .NET and C# assemblies to work together.
What does this mean to other language vendors? Can they leave out these features with the argument that they are not necessary because they are not CLS compliant? Of course not – how can you be less than 100% compatible with the two major .NET languages? In effect, VB .NET and C# will define the new de facto standard.
The idea of a common language specification is a good one, and the truth is – they are so close that it’s hard to see this as a big deal. But language interoperability is important – especially if we are ever going to convince developers to truly adopt component-based development. Both VB .NET and C# should produce CLS compliant code by default and require an explicit developer choice to turn it off (just as systems should be secure by default – same concept). But I’m not suggesting they change the default attributes for VB .NET and C# projects. Rather, Microsoft should update the CLS to match the new de facto standard and make that the default setting for VB .NET and C#. This will help vendors of other components and the folks developing Mono to have a clear common guideline to work with, and in the long term ensure that the interoperability promised with .NET does not devolve into an illusion.
Related Articles:
How Microsoft Lost the API War by Joel Spolsky is essential reading to every Windows software developer. Check out his new book.
RSS feeds for sites referred to in this item:
Joel on Software
Aug 22, 2004 | Software Development
Why is it that hardware developers benefit from component reuse and software developers do not?
Jack Greenfield recently authored an article on MSDN called “The Case for Software Factories” that I encourage you to read. While I don’t disagree with this article or it’s sequel, there are some areas that I think deserve elaboration.
In his article, Greenfield distinguishes between economics of scale and of scope. Scale is where you can easily make copies of an existing item, Scope is where you can create custom items by assembly components that you already have. When it comes to scale, software has the edge: just duplicate a CD or post an installation file to a server. When it comes to scope, hardware as the edge.
A chip maker wouldn’t dream of designing a chip using individual transistors. They use libraries of components and advanced design software to assemble chips from the simplest ASIC to the largest microprocessor.
Why don’t we do this with software? What do hardware engineers do that we don’t?
Ultimately, it comes down to two things:
- Hardware components have their behavior specified in extraordinary detail. You can predict with great accuracy what even a complex hardware component will do in a system. Microprocessors, for example, come with documentation books that cover every aspect of the chip’s behavior from commands, to electrical characteristics, to the precise timing of signals.
- Hardware developers use sophisticated tools to build systems from components, whether designing a chip from predesigned elements, to building systems using commercial or custom components.
In software we have primitive versions of both. There is a third party component industry (that I’ve been a part of for years with my company Desaware www.desaware.com), but the industry is tiny compared to the overall software market (I discuss this further in my article “Impact of Source Code Availability on the Economics of Using Third Party Components” )
The Heart Of The Problem
The fundamental reason that hardware developers are ahead of software developers in reuse is this: coding is cheap.
Intellectually, we know that software is expensive to develop. We know that coding is a very small part of the total lifecycle cost of software. But when we look at a software component, we still tend to think we can do ourselves cheaper rather than using something off the shelf. The fact that coding is inexpensive gives us a distorted view of development costs.
If software components were specified and documented with the level of detail common for hardware components, perhaps it would overcome some of the reluctance people have to using components, but the nature of the software market prevents this. The component market is not large enough to justify the investment in documentation, customers do not demand it, and the marketing drive to constantly add features to software drives up the cost of specifying and documenting components even further.
Regarding high level tools, it’s easy to justify the long term investment in developing and deploying such tools. But the key word here is long term. Most companies do not think long term. Time to market and this quarter’s profitability are stronger driving forces.
The Hardware Edge
Why have hardware developers turned to components and invested in high end development tools? Because the economics are compelling both on the long term and on the short term!
The cost to develop an integrated circuit are enormous. Prototyping a chip is time consuming and expensive – you can’t just mock up a chip the way you might mock up a user interface. Actually building a test chip is expensive as well – especially for complex chips. Testing is expensive, often requiring complex hardware and programming.
In short, hardware development is so expensive both in reality and perception that at a certain level of complexity it is not only costly, it’s virtually impossible to do without componentization and use of sophisticated development tools that allow a high level of abstraction. It is this cost that forces hardware developers to buy instead of build components (overcoming “not invented here” syndrome). It is this cost that overcomes the temptation to build something because it’s fun – you just can’t rationalize the extra development work the way you often can in software.
Curiously enough, even as the low cost of software development prevents us from enjoying the economies of scope (code reuse), the low cost of software reproduction makes piracy a greater problem in software than hardware (though hardware piracy exists as well).
Links:
Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, et-al. I haven’t read this, but if you like the MSDN article, you’ll probably like this book.
Code Generation in Microsoft .NET by Kathleen Dollard. Practical rather than academic, if you want to try code generation with .NET, start here.
RSS feeds for sites referred to in this item:
Kathleen Dollard’s Blog