Tech-Ed: Don’t start new projects in Delphi or FoxPro

Yesterday I attended two sessions aimed at FoxPro and Delphi developers, on how and why they should migrate to .NET.

The FoxPro session drew sparse attendance, which did not surprise me. Fox developers do not attend Tech-Ed, as there is nothing here for them. Speaker Remi Caron made the point that FoxPro forms will never look quite right on Vista as the widgets are custom drawn, and the the FoxPro language is not as deeply object-oriented as C#. Many Fox application are utilitarian in nature, and Microsoft is doing and update codenamed Sedna, which focuses on .NET interop and Vista compatibility, so I am not sure that the arguments were fully persuasive. FoxPro applications will trundle on for a while yet. It is also interesting that C# 3.0 is only now getting integrated database query, which has been a feature of xBase from its earliest days. Still, FoxPro is undoubtedly coming to the end of its life as a product under active development.

The Delphi session was more interesting. Of course I make allowance for the fact that this is a Microsoft conference and that Delphi comes from a competitor in the tools space. Even so, it was a grim event from Borland’s perspective. Presenter Hadi Hariri is a Delphi person. He works for Atozed software, whose main product is a web application framework for Delphi. Also present was Chad Hower who worked on the Indy internet components for Delphi as well as Atozed’s Intraweb. Nobody could say that either speaker lacked Delphi knowledge. Around 25 delegates came to debate Delphi’s future.

Hariri and Hower did not advise developers to port their Delphi projects, unless there is really a compelling reason. However they did strongly advise against new projects in Delphi.* The main factor is integration with new .NET goodies such as those in .NET Framework 3.0, especially Windows Presentation Foundation and Windows Communication Foundation.

But surely you could use Delphi for .NET? Indeed, but there are two problems here. One is that according to Hariri the VCL.NET, Delphi’s backward-compatible .NET library, is failing to win significant adoption. He observes that hardly any of Atozed’s customers use Intraweb with VCL.NET, although it is fully supported. They all use either native Win32 VCL, or a few Kylix, the abandoned Linux port of Delphi. Other third-party vendors say the same thing: there is hardly any market for VCL.NET components.

Then surely you could use Delphi’s .NET compiler with Microsoft’s class libraries? Indeed, but will Borland or the new “DevCo” ever catch up with Microsoft? This week the .NET Framework 3.0 is fully released; yet Delphi 2006 only supports .NET 1.1. By the time Delphi appears with .NET 2.0 support, Microsoft will have updated Visual Studio with a designer for Windows Presentation Foundation and other .NET 3.0 features, which Delphi will likely lack for some time.

We used to laugh at vb applications. Unfortunately it is completely reversed now. We are always going to be behind now.

said Hariri. The session lends weight to recent calls for Borland to focus on Delphi capabilities in native code rather than .NET; yet that too is not ideal when so much of Microsoft’s development platform is focused on .NET.


* Hower has commented below and also written at length to emphasise that from his perspective this only applies to .NET projects, not Win32.

9 thoughts on “Tech-Ed: Don’t start new projects in Delphi or FoxPro”

  1. “However they did strongly advise against new projects in Delphi.”

    Actaully thats not quite right – I specifically said that there is a lot of life left in native code, and that by far Delphi has a better form designer and is the hands down best solution for native code. I stated that for .NET code Delphi did not offer what is needed by developers and will be without WPF, Indigo, and other critical technologies for the foreseable future and that thus for .NET there is no real option to use Delphi in an enterprise which needs access to all of .NET, not just some and old versions at that.

  2. Thanks for the clarification. Clearly there are two separate issues here: .NET vs Win32, and Delphi.NET vs (primarily) C#. As I recall, the former was not the main focus of the discussion because those present already had reasons for wanting to migrate to .NET; however note this remark in the abstract:

    Even if you are not considering .NET now, at some point you will have to move to .NET with new code, or to port existing code. Staying with Win32 may be viable in the short term, but not the long term.


  3. The implementation of .NET 2.0 for Delphi.NET requires a lot more work then what will be needed for .NET 3.0, which mainly is just a bunch of components and does not require any changes in the language.

    I beleive and hope that .NET 3.0 support will be available pretty fast after we have .NET 2.0 support for Delphi. The roadmap gives a hint that we can expect support for both .NET 2.0 and the so called .NET 3.0 in next year.

    Also, one must take in consideration that the common Delphi programmer do native Win32 development, and will probably continue to do so for a long time. The main request from the community is to have native Win64 support, more then .NET 2.0. However, to remain as a truly competitor for Windows developmers, DevCo need full .NET support.

  4. uh, .net sucks for desktop and database applications when compared to Delphi. The VCL is still better in my book.
    You shouldn’t even use Delphi and FoxPro in the same sentence.
    Win32 applications are going to be viable for a long long time no matter what MS says.
    Hell, .net is just a layer on top of win32.

  5. Hell, .net is just a layer on top of win32.

    This is pretty much true for Windows Forms but less so for .NET Framework 3.0. My take is that WPF and WCF gives developers a stronger incentive to move towards .NET for typical business apps. If you want a small high-performance app that you can easily deploy to anyone running Windows, then you are right, Win32 Delphi is ideal.

  6. Correct, Visual Foxpro people don’t attend these type of events. We’ve grown to just ignore .notyet promises and instead concentrate on getting solid robust data centric applications out of the door.

    As for no more development – rubbish. The VFP development team and the WHOLE of the VFP community is involved in SEDNA development with regular CTP’s from the team. With SEDNAX and VFPX (Both on Codeplex) developers themselves are contributing to the product to make the language even MORE extensible than it is already.

    I use both Delphi and VFP and even though I love Delphi, VFP is just a breeze for SMB solutions using native VFP data as well as also front ending Client Server databases. As for speed in execution and development, it is second to none. Please don’t knock the product without being aware of its capabilities and knowing what you are talking about.

    Finally, as for not mentioning Delphi and Foxpro in the same breath, all the doom merchants said VFP was dead when M$ bought out FOX. Now Delphi looks like nobody wants it (good though it is) but M$ won’t let go of VFP as they realise what a versatile product it is with a truly brilliant and knowledgable user base. Many current VFP features are now finding their way into .NET whilst the VFP team at M$ are some of the most highly regarded people at Redmond.

    Oh just to rub it in, VFP support is guaranteed by M$ at least until 2014. Will Delphi still be around then?

    A dead product? I don’t think so.

    Dave Crozier

  7. Oh, look — more FUD from a Microsoft sponsored conference!

    Okay, first of all, no solid technical reasons were given here or in the comments that follow that in any way damage Delphi.NET. Instead, what I’m seeing is the ‘sheep mentality’ in full force. It’s the “don’t do because no one else is” approach.

    So much for software engineering being for pioneers. Now it’s for sheep. Baaaaaahhh.

    Okay, vent concluded. As far as Delphi needing to catch up, yes they better. But the idea that someone’s got a great crystal ball and can say definitively that Delphi will never catch up in .net, and will never be able to stay current with MS releases is reflective of an inability to accurately diagnose what has happened at Borland the last several years. The result of the identity crisis at Borland is the impending split of the DTG group. This group should be able to slowly but surely regain ground by closing the gap in compatibility while offering features that MS isn’t (particularly in sharing new advances across Win32 and .NET platforms).

    Maybe they will fail, maybe they will succeed. But it is far from given that they will fail.

    Secondly, I contend that the issue with VCL.NET development is largely a chicken and egg issue. There is a feedback loop between third party component vendors and developers. Why have I not done my apps in Because I lack some of the components I need. Why do I lack some of the components I need? Because vendors aren’t porting them. Why aren’t they porting them? Because no one is doing VCL.NET projects…and around and around we go. I bought the Dev Ex WinForms suite for C# development and have grown to bitterly regret that decision. I find development with it to be significantly more painful than their Delphi/VCL components for very little gain. If a bigger percentage of their suite was available for VCL.NET, I would have bought it. But I voted with my $ the way the Tech Ed people would have had me vote — with C#/WinForms components, and I’m sorry I did. I would have completed my projects much faster and much more smoothly with the VCL.NET versions of their Delphi components than with the WinForms versions.

    Because of DevEx’s unwillingness to invest further in the VCL.NET market, I’ve started buying the TMS component suite, which gets a significantly higher portion of its components converted to VCL.NET, and I’m looking at closely at LMD Innovative, which ALSO ports most of its stuff to VCL.NET. When I need to do .NET, I fully intend to do it in VCL.NET, and reward those third parties who have invested in it.

    Until then, let the lemmings continue to follow Microsoft’s dictates, and I’ll continue to code rings around them in Delphi.

    Meanwhile, DTG needs to absolutely make it a top priority to close the 1 year gap between .net versions and the Delphi support for those versions.


  8. I am currently interested in two types of applications: desktop apps (either c/s or n-tier w/ RemObjects), and web apps. Since I discovered Delphi in version 1, it was then the most revolutionary coding tool ever. It is still, by far, the most productive development platform around. For desktop apps, which my customers still require, Delphi Win32 is still the best choice. For web apps, I have discovered IntraWeb, and I have to tell you, it is a generation ahead of ASP.NET in terms of architecture and conception. Granted, the creator does not have the resources of MS, and hasn’t taken it as far as it could go — but is an amazingly productive tool for web apps that are very scalable as well. And then when you combine RemObjects’ Data Abstract tool to create your middle tiers, the desktop apps and the web apps can access the same source, and you get the most powerful combination I have seen to date.

    Yeah, .NET is the future of Windows programming, and for people that have been using MS tools for a long time, it is a major breath of fresh air. But a conversion to VS and/or .NET results in the loss of so many features and capabilities that Delphi users have become accustomed to, that there is no way to switch without experiencing a one-year or longer hit to productivity.

    Anyone who thinks that Delphi is dead is plain wrong.


  9. Talk about Microsoft FUD..!!!

    Lets just look at the commercial software market.. (Desktop not web, otherwise it will become a vs jsf vs php etc debate..)

    How many RETAIL applications are written in .NET ?
    Microsoft’s own WPF is a NATIVE DLL with a wrapper.

    Is Office 2007 etc written in .NET ? NO..

    Why ? Memory, speed, etc.

    YES there are times when .NET is appropriate.

    But IF the job can be done in WIN32 (delphi), why ? why ? why ? Do it in .NET ??

    We use TMSSoftware components due to their quality components, and support for VCL.NET.

    90% of the business I deal with (defence, retail, government) don’t even have .NET 2.0 installed yet.. They have Standard machine configurations and take STABILITY seriously.

    Lets SUPPORT CodeGear……!!

    .NET 2.0 will be available soon in the next release ‘Highlander’. Don’t forget .NET 3.0 is really .NET 2.0 + WPF/Indigo/etc.. Your code will run fine. And you can always add the WPF/Indigo yourself..!!!

    And after a number of C# .NET projects, i’ve come BACK yes BACK to DELPHI and Win32 for most of my customers needs.. Its what they want..!

    They don’t care what its written in, they want fast/clean/responsive apps, which Delphi Win32 does nicely..

    They don’t/can’t install .NET 2.0 due to department desktop policies, etc.

    BUT with Delphi I have ‘A’ path to .NET 2.0 if and when I need it.. (Microsoft isn’t fully .NET yet are they.!!!)


Comments are closed.