Monday, March 21, 2005

VCL.NET on CF? We control the horizontal...

Danny is making some waves in this post he made over the weekend.  One thing to note is that Borland has never set out to do things only half-hearted.  Unless there is some reasonable chance of success, we will rarely go off and speculatively head down a path.  VCL.NET on CF is one such item that is still being considered and reasoned out (read: Researched... IOW, the “R” in R&D).  Nearly four years ago I brought up the prospect of moving VCL onto the Windows CE platform using the .NET framework on those devices. This was before CF was released.  At the time, there was much poo-poo'ing of the idea because we had visions (delusions ;-) on being able to license the CF designers.  After all it was just a version of the desktop WinForm designer... right?  Fast forward to now and it is quite well known that CF WinForm designer support in the Delphi IDE is currently in a coma...  There has been much moaning and gnashing of teeth over this whole issue.

After following the ensuing discussion both in the comments on Danny's post and the spillover into the Borland newsgroups, I must say that there is more misunderstanding about this whole issue than I thought.  I mean there are several folks who simply out of hand blast the notion of VCL on CF and simply say, “just give us WinForm CF support.”  So we try and clarify by asking if they'd be willing to accept a solution that came with no visual designer support whatsoever?  Then, with a wide-eyed look of surprise, they say,  “Well, of course you need the designer support.”  We're talking in circles here folks.  For Borland to release a product that advertises and touts mobile device support, the expectation will of course be full design-time support.  Then there are those that immediately backpedal and and say that compiler only support is fine.  Read my opening statement about half-hearted implementations.  I'm confused...

Let's recap;  CF/WinForm designer support requires licensing technology from MS, however it is more than just a licensing issue.  It is also a technical one.  Read my comments here and Danny's here, about the issues with CF designers.  Now with VCL, it is a fully Borland designed and built framework.  The VCL designer is also fully Borland designed and built as well.  We have the source code.  We intimately know how it works.  We know where to make the proper incisions in order to repurpose it for another framework.  Do not attempt to adjust your monitor... we control the horizontal... we control the vertical...  Yes, it would be a lot of work, no-one is denying that.  So recall my opening statements about doing something with a reasonable chance of success.  Now the issue comes to whether or not it is something that would be accepted by the customers.  Basically, Danny, the Delphi team and myself are just thinking out loud... which is good because at least you know we are thinking about it. ;-)


  1. re: feasiblity

    Ok, get back to us, then, with a yay or nay.

    A point of clarification. Do you mean all this time the whole issue about MS CF licensing could have been side-stepped with a VCL for CF, all this time? Or do you still need permission from MS to do CF support even via the VCL?


  2. Dennis,

    Go back and re-read some of Danny's and Allen's remarks on this. This issue is not as simple as licencing. As I read it, it is more of an implementation issue. The CF designers are not part of the framework but built into Visual Studio. Which looks like Borland would have to provide their own implementation.

    -- Robert

    Just my 2cents.

  3. My question is whether or not the whole MS licensing issue can be side-stepped with a VCL/CF implementation.

    I, of course, realize that there are "technical" issues with building such an implementation.

    I wonder why that would need to be pointed out, since the target audience here are all software developers...


  4. Give us a Borland (D2006) visual designer framework that fully supports current and future CF technology and I promise I won't give a hoot whose label is under the hood!

    If Borland can truly achieve this CF compatibility with home grown VCL, I know I won't need to switch to the dark side.


  5. Dennis:

    No dealings with Microsoft are required to build VCL.NET/CF.

    We would still prefer to take the shorter route and license a CF WinForms designer instead of diverting our resources into it. As no CF WinForms designer has been forthcoming, we're now evaluating other options.

    Could VCL.NET/CF have been started earlier? Sure. Why didn't we? Because CF was not considered important enough to justify sacrificing other Delphi product work.

    Now it is. We are now sacrificing other Delphi product work in order to investigate these CF paths. Everything has a cost.


  6. Guys,

    If Borland is really serious about mobile development then what about symbian The symbian O/S has a 95% market share compared to windows mobile. Mobile hardware (specifically smart phones) is going to be dominated by the European powerhouses (Nokia, Ericsson, Symbian) for some time to come. Europe is way ahead of the United States here and a smart technology company should stop contemplating it's Microsoft navel and look further afield to see what is happening in this market. European Telcos are NOT going to let Microsoft Commodatise

  7. So has finally Borland realized that reinvent the wheel is expensiver than to licence it?

    If Borland stuff (ECO, Delphi, VCL) would be hosted in VS.NET, Borland would have time to

    a) concentrate on Value Added Products (what is not implemented by M$, like ECO, VCL & language itself).

    b) concentrate on quality.

    d) concentrate on Delphi Win32/Win64.

    It's time to face the truth - Borland is no- way a competitor to Microsoft on Microsoft native ground - .NET. And this distance will only grow with time.

    As a developer I see this extremely clear.

    There was no need to merge Win32/64 and .NET in one IDE. D7/VS2003 IDEs are much more robust and responsive than D2005's one.

    Look at VS IDE core as ADO components, which are supplied with Delphi SKU. Does anybody hesitate to use ADO inside the Delphi?

  8. Sorry more to add to that last post.

    ... European telcos are NOT going to let Microsoft commoditize the phone market.

    Why is this relevant to this discussion. Well for Borland to spend any efforts on mobile developent. I would hate them to target the minority platform. Borland claim to be agnostic on plaform support. Well prove it, by supporting the major player and not the minor players.

  9. I am sure we all want full designer support eventually but many of the comments on the blog clearly indicate that we simply want entry support (compiler only) and that sooner is more appropriate than later. I think it is reasonable to wait until the next major release to have any designer support and it makes sense to encourage version uptake. Getting the compiler support out under the current version also makes sense so it can get some exercise and those people, like myself, who need to get something done in the short term are not put in a precarious situation.

    I really appreciate you and Danny providing these insights, Thanks.

  10. How much time and resources will it take to get a VCL.NET/CF designer? Will it be for .NET 2.0? It better be or you will be putting yourself just that much farther behind MS. I do not think that you should go down this path if you sacrifice anything to get Delphi to .NET 2.0. I would love to have the ability to build mobile applications with Delphi but not if I cannot build Delphi Win and Web Form applications for .NET 2.0.

  11. John, Please read my discussion regarding VS.NET integration here:

    Peter, I think your numbers are a little out of date. The Windows Mobile platform has now overtaken PalmOne on the PDA side and is making significant headway into the smartphone market. I'd rather be on the upswing of a new technology or platform rather than jumping in at the top. That's a little bit of hyperbole, I know, but that is the direction things are looking to take.

    Another point, is that the Symbian OS is a mess of an OS. It is based on C++ which by definition is a brittle way to interface to a framework. Since it is early bound, you cannot compile an application for one version of the OS and have any hope of it working on a subsequent version. We've been down this path. Look at CBX.

  12. Allen. I gather that you believe the Symbian OS is based on the brittle C++. A language that is clearly not to be trusted to write operating systems in. Well excuse me. Every Microsoft OS is written in C++ (you do support Microsoft's OS's don't you?). Even when we get to Longhorn the majority of the OS will not be written in .net. I think you will find that windows mobile is also written in C++.

    If someone wants to port the .net runtime to Symbian then feel free. (Oh!! does .net run on linux via mono? is it an OS? is it a bird? I do not know ... )

    So anyway all that nonsense aside. It's about deployment and Symbian is way ahead of Microsoft in the smartphone market. No doubt at all. Symbian doubles and then doubles from a significant base (enough of an upswing for you?). Microsoft is just trying to catch up and will have to try harder.

    So - Symbian is the platform. The rest need your sympathy.and

    Ps. In Europe we are using what works. Symbian has 41 devices

    Microsoft has 14!

    Come on guys help us out here...

  13. Peter,

    Yes the programming interface in the Symbian OS *is* C++. As for Windows, it was actually originally developed using C (not C++). Yes there is now significant C++ throughout the OS, however the binary API is still a flat functional C style API. This is not true of the Symbian OS.

    .NET can support a truly OOP style API because it is *late* bound. This means that the JIT compiler will handle all the tasks of laying out the actually run-time class formats. All you need to worry about is whether or not a method is available on that particular version of the framework... kind of like programming against the Win32 API.

    If the Symbian OS does anything to modify the API, such as adds a virtual method, or adds new instance data, all descendants of that class are now binary incompatible. This is because of the early bound nature of a compiled-into-machine-code environment. The descendant code hard-codes specific field and virtual table offsets. These cannot be easily changed without recompiling the application. This means you have to compile your application for a Series 60, or a Series 90, or a Series xxx phone. With Smartphone and .NET CF, your application has a much higher degree of portability to other phones.

  14. Does .NET 1.0 application work on .NET 2.0 Framework?

  15. John,

    Yes, the application will automatically "float" to the most recent version of the framework. However you can, using an application config file, control that behaviour.

  16. These people asking for full compiler + designer + debugger support for CF remind me of the "must have Delphi on Linux" days.

    The concept is great, but in reality I think the required effort will take away from Desktop Delphi as well as other things ( on Mac maybe).

    Do you guys actually have apps that you'll develop if you had this or do you just want it because you think it would be cool?

    Borland, think about it very carefully. I can't help to think that in all the time that's been used up in having this discussion you guys could have implemented CF Compiler support.

  17. Allen, (my last reply on this. Promise)

    I know where you are coming from with the fragile base class on symbian. However nothing is stopping symbian from getting a .NET style Virtual machine to solve those problems, it already has Java. Maybe someone will port CF to symbian and this will all be moot.

    I guess I was struggling with the concept that because Symbian was not as elegent as .NET then it should not be a target platform for Borland/Delphi.

    Borland used to have a platform agnostic view of life and would go where the developers/market are, rather than doing what is cool or just following Microsoft.

    Symbian, and lets comfirm the figures here, has shipped 14 million units this year. That is more that a 100% year on year rise for three years in a row. Ovum predicts 100 Million units being shipped in 2007 compared to 20 Million units of Windows Mobile. I would hazard a guess that most of Windows Mobile shipments are present are on PDA's and not smartphones.

    Now that is a sizeable market, and the mobile phone manuf's in Europe know where the next battle ground is, and they are not going to let Microsoft eat their lunch.

    Waiting for Microsoft to simply take the market over and "Democratise" it for developers is simply not an option. Smartphones are not the same as PC's.

    So please please consider a Delphi that can target mobile devices directly, rather than waiting for CF.

    Currently we use appforge which allows .NET code to be run on Symbian, Palm, Windows and Windows Mobile.

    But I am a die hard Delphi fan and know that Borland could do the job much better and I guess there are a whole bunch of European Delphi developers who would love a Delphi for Mobile.

  18. Peter:

    Borland is intimately familiar with the Symbian OS. We have built two development environments targeting Symbian: one for Nokia, and one for multiple mobile platforms (CBX). Both were C++ based. Why? Several reasons:

    1. Targeting Symbian with Delphi would require writing another code generator, which is a complex and expensive undertaking not to be taken lightly.

    2. Symbian's exclusive reliance on C++ objects as the API layer requires all tools for the Symbian OS to conform to how the C++ language defines how an object is laid out in memory and how it should operate. Delphi is not C++, and the traditional gcc objects do not provide all the symantics that Delphi objects need. Delphi meshes well with Borland C++ only because we modified the implementations of both languages to support a common object model that supports the needs of both languages, including compatible RTTI and object vtable layouts.

    Perhaps things have changed more recently, but at that the time I was (peripherally) involved in discussions with Symbian, Symbian was not interested in broadening the object model to support other languages. Symbian would be the first to declare proudly that they are a C++ only shop.

    In terms of system support for binary interoperability between disparate programming languages, and binary compatibility of code across system versions, Symbian is the antithesis of .NET.

    2. The sponsors of these projects (Symbian clients) did not want Delphi. We offered C++ and Delphi together. They specifically requested Delphi be removed from the proposal.

    Our work on Symbian tools was in progress when Borland began to take interest in the emerging .NET platform. Given the unique challenges of implementing new code generators for the Delphi compiler, and given the commoditization of code generators for C++ compilers, we chose to hedge our bets with two strategies: Cover the native side of mobile development by licensing multiple C++ compilers for the various processor targets in CBX, and cover the managed code side of mobile development with JBuilder for Java and Delphi for .NET.

    We chose to take the hit of building a new Delphi code generator to target .NET IL specifically because IL code can execute on different runtime hardware. We write one code generator and target multiple devices through the hardware independence of .NET IL code.


    p.s. We've also worked closely with appforge, btw.

  19. William:

    Please read the blog articles. CF compiler support is done.


  20. Hi Danny,

    Thanks for the response. I really get the point that Symbian is not Delphi friendly and targeting it would be a big PITA and not something to be undertaken lightly.

    I also understand the Borland do understand the Symbian OS, and they have targeted it with other languages. (did not intend to imply you were ignoring it completely)

    But we seem to be missing a market view as opposed to technical view.

    As a Delphi user I have no way to target the biggest Mobile Platform.

    Your response to me, as a Delphi developer is

    1.) Use C++

    2.) Use Java

    3.) Wait for someone to port CF to symbian

    Given you are at a juncture and about to take a big plunge to build CF support into the Delphi tent, then I was trying to articulate the European view of life. Which is, Yes we want windows mobile; BUT the market leader is Symbian, help us target that.

    However ugly Symbian is inside, it has captured the imagination of all the major phone manufactures over here. And sorry to keep coming back to this: Europe is leading this space, by some margin, so you should, in fairness, take you cue from what is happening on the ground over here.

    Something that really frustrates me about us as a community is how we geek-out over devices and ignore what the typical consumer wants. In the long term Smart Phones is where it is at, not PDA's. The average guy in the street does not want to carry round an big ugly brick and a cell phone. The consumer space is something that the likes of Nokia, Sony-Ericsson et al really get, and to be fair Microsoft have been late to understand.

    Could I suggest you (Borland) run a survey specifically aimed at Mobile development and break down the results by region (e.g Europe Vs US), and make the distinction between PDA's and Smartphones.

    Cheers Peter

  21. Just wanted to say I think VCL.NET on CF is a great idea. Bring it on.

  22. trying to remenber the name of the TV show Do not adjust your set, we control the vertical, we control the horizontal? Can anyone help?


  23. Does .NET 1.0 application work on .NET 2.0 Framework?


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.