“I want to write PDA apps using Delphi and the .NET Compact Framework. Yet Borland still doesn’t support this. Why not?“
Borland has been in negotiations with Microsoft for the past three years on how Microsoft can support third party tool vendors to produce tools for the .NET Compact Framework.
To summarize the discussions and the lack of forward progress, it mostly boils down to Microsoft tribal politics and engineering shortsightedness, as well as Borland’s desire to minimize development costs.
The Microsoft team responsible for building the .NET CF runtime has been very supportive of Borland and done everything they can to pave the way for Borland tools to support the CF platform. The CF runtime team, however, does not have ownership or control of the CF design surfaces.
In the desktop .NET Framework, the WinForms form designer is actually part of the framework. Third parties such as Borland can instantiate the form designer and provide it with hosting interfaces and away you go – you have a design environment.
This arrangement came about partly because of Microsoft internal politics – the Visual Studio group was too busy to provide designers for the .NET Framework team, so the framework team ended up writing their own designers. There were other factors as well, but this was certainly a big one.
By the time .NET CF came around, the Visual Studio team was more able or willing to support .NET. VS took on the task of building design surfaces for the CF platform. The .NET CF designers are part of Visual Studio. Since small footprint was the highest priority for CF, design-time support was the first thing cut from the runtime footprint. This is understandable.
What makes things difficult is that the CF designers were not designed to support third party tools. It’s not just a matter of Microsoft not wanting to license the CF designer to third parties such as Borland, but also a matter of baked-in design limitations – the CF designer is so interdependent upon the Visual Studio architecture that a non-VS tool vendor would not be able to do anything with it even if the CF designer were licensed.
This is truely sad, because we know by the WinForms example that it doesn’t have to be this way. The WinForms designers were built by the “new-school, welcome everyone to our platform” Microsoft. The CF designers were built by the “old-school Visual Studio, third party tools are not our concern” part of Microsoft.
If you think I’m being melodramatic here, check this out: Even if a third party were to license the Visual Studio architecture to build their own IDE using VS bits, those VS bits do not include CF designers. You can’t get the CF designer *without* VS bits, and you can’t get the CF designer *with* VS bits. So, no matter which way you slice it, CF is screwed. By Microsoft.
Is this a result of deliberate Microsoft maliciousness? I doubt it. I find it much easier to believe in human nature than malicious conspiracy theories. Human nature focuses on the immediate task at hand and awareness of what you’re exposed to every day. If you work at the Microsoft Redmond campuses, you have to walk a long mile to rub shoulders with anyone outside of the Microsoft mindset. I’m no longer surprised when I meet smart Microsoft folks who don’t know Borland has a Delphi for .NET product. “Pascal has objects now?“
The outreach portion of Microsoft is keenly aware of this natural tendency for any large group of people to become introverted and self-centered to their common cause. Folks like Jim Miller work hard to correct that tendency within Microsoft where they can, because if they don’t Microsoft is setting itself up to be broadsided by some industry trend they didn’t see coming (like, say, the Internet). Microsoft actively solicits third party involvement and review, partly to help break the centrism spell every now and then. Reality check. Have we missed something here? Oh! Right! Good point. Hadn’t thought of that. It wasn’t something we needed, but it would certainly benefit a lot of other folks. We’ll get right on that.
I believe the CF designer situation is borne out of the economic pressure to ship something quick, without much time for design review or consideration for third party support of the platform.
Borland’s options to support the .NET Compact Frameworks platform include:
1. Leverage CF platform support provided by Microsoft. This is the most attractive, most economical option for Borland, but since it isn’t currently offered by Microsoft, it’s also the least available. Nevertheless, we continue to lobby for it because this would lower our costs to support CF so significantly as to make the decision a no-brainer. This would enable us to continue focusing on higher level programmer productivity enhancers instead of siphoning off resources to reinvent low-level plumbing that has already been done elsewhere.
2. Reverse engineer the VS CF designer architecture to build our own designer against the CF framework. Reverse engineering a black box as big as the .NET framework is a very expensive proposition. This route runs a very high risk of litigation and exposure to unknowns hidden
inside the black box.
3. Build something else that runs on the CF IL platform but not using Microsoft proprietary bits. This gives us the greatest freedom and flexibility, but also the greatest cost to develop. This option will always be playing catch-up. This option is also the least attractive to Microsoft, since it threatens to split the CF platform into incompatible camps just like Win CE’s fatal fragmentation.
It’s a question of business, not technology. Borland can certainly build CF tools without Microsoft’s blessing or assistance, but it will be much harder and much more expensive than if we had the cooperation of the platform vendor. Why should we plant seeds in a desert, with no option for water?
“More expensive” means we have to see an even larger financial return before starting down that path. CF development would be a great feature to round out our tool suite and would drive additional sales of the tool suites, but it is not hugely lucrative market by itself – certainly not as lucrative as Win32 or .NET development as a whole.
I am hopeful that we will be able to break this impasse with Microsoft. My impression is that most of the tribes within Microsoft recognize the value of having independent third party tools supporting Microsoft platforms and indirectly driving sales of Microsoft platforms. There are only a few groups in Microsoft that appear to still place greater priority on protecting sales of a specific product (VS) against competition over enabling and driving third parties to promote sales of the underlying Microsoft platform. Unfortunately, CF design support is owned by one of the more protective groups.
The good news is that Avalon appears to be leaning toward the WinForms designer mentality rather than the VS “all your base are belong to us” model that created this CF platform blockade.
This article is based on my newsgroup post to borland.public.delphi.non-technical