Delphi is the VCL

June 25, 2007

Delphi is the VCL

The Delphi Roadmap and the Role and Future of the VCL. A long post linking to many sources and providing my point of view.

Over the last few weeks, I was quite busy, but collected many posts regarding the VCL and its future. Some of them relate with the recently published Delphi roadmap, but not all of them do. This is a long post... hope it is also useful to get the bigger picture. I was certainly pushed to write this by several posts including:

Serge's Delphi and VCL 2.0 or going into XXI century (although I disagree with the cross platform plan of this post).
Roland Beenhakker CodeGear to drop winforms designer in Highlander (OK, but...)
and (mostly) Julian Bucknall's Fahrenheit VCL (this is a very relevant point of view, although it is not mine)

Between the Lines of the Roadmap

I already posted about the Delphi roadmap, but it was updated and some more information became available for those good enough to read between the lines. First, the role of generics in Highlander has been clarified: they will be there in full mode. Second, as first reported by Julian, the C# support will be downplayed and the WinForms designer removed. Third, the 64-bit version of Delphi has a code name a a more precise time frame. There is more info in this thread.

As Nick stated many times, the roadmap is a work in progress. The plan is constantly updated reacting to users feedback, but also with further exploration by the R&D team. This is positive, as plans should guide users but not set in stone.

VCL and API wars

A relevant blog exchange related with the VCL is the one that took place between Steve Teixeira (of Delphi books fame but now working at Microsoft on Visual C++) and Steve Trefethen (at the time still a "full" CodeGear employee). I find it very interesting that Microsoft is now more serious on Win32 and native development than a few years back. Maybe not every application is moving to .NET, after all.

In a very well written post (over one month old) Trefethen considers that while Microsoft is all for .NET, their main products like Office and Vista are native applications. Of course, the OS must be native, but all the system utilities and tools are native as well. This is odd. If Win32 is dead, why add thousands of native APIs? The fact that Visual Studio support for Vista is more limited than Delphi's one is quite amusing. Question: will VCL.NET have full Vista support sooner than WinForms? What WinForms offers in that respect is a set of shallow add-in classes to call the native API.

Teixeira replied to this post with an interesting piece. He claims you can build "cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives". Well, with better native class libraries we could probably reduce the effort, even without having to move to WPF. Not that I dislike WPF. It is much better than some of the web-related alternatives, but I don't see many users looking forward to animations and nice effects in their accounting software. Anyway, you have to read the long post, here I'm giving you only another small quote: "We [the Visual C++ team] have some very aggressive post-Orcas plans for advancing the state of the art of native development!".

With the advent of Vista and a little more stability in the CodeGear camp, I'm getting many consulting requests from companies who use DelphiX (5 to 7, in equal percentage) and want to move to Delphi 2007. Vista support is certainly a reason. Having to drop the BDE (!) another. Looking for a more powerful IDE and better language/libraries a distant third. The amount of investment in Delphi code is huge, and there is no compelling reason for most of these companies to move away from native Windows VCL applications. Maybe Europe is different from the US in this perspective...

What I find very interesting is that CodeGear is investing on the VCL again. Unicode support is finally official (even if late, I agree). The developer team was looking for input and got some. They mention a "Ribbon-like UI", better multi-threading, and several other features. The VCL has been growing a little over the last year (after a long stop), but I want more! I know that the VCL for .NET lacks third-party support, and this is why it is not as much used, and this is why there are not many third parties... and so on forever. CodeGear should try to break this negative loop, but that's not easy.

WinForms, WPF, and the Future

Beside the ASP.NET world, the status of the user interface libraries on .NET is in a flux. WinForms is stable, but hardly pushed by Microsoft and its use is far from widespread. WPF (including its variations, like Silverlight) is taking off, but I don't see it well suited for classic client/server programs. Many Microsoft evangelists I spoke with agree with me. Is WinForms a central piece of the .NET technology and is it silly for CodeGear to drop its support? If WinForms is not heavily used (I remember a 88% to 12% ratio between ASP.NET and WinForms from a Microsoft source a couple of years back, with WPF still out of the picture) it is marginally used by Delphi developers: only a few of the few on Delphi .NET use it!

I've used WinForms mainly for CF projects. I decided not to use the form designer anyway (because of the CF compatibility issues), so I won't miss it! I'm among the developers who prefer VCL.NET to WinForms. Not only because I know it. Not only because I have the source code. But because my code is portable, the library is rich (can I say more rich?), I feel at home, my data access code still works, it is Delphi. Truly Delphi is the language plus the library, keep half of it (the Object Pascal language alone) and it is not Delphi any more. I'd love CodeGear to support every technology out there. But having to choose between a better VCL (including a better VCL.NET) and WinForms support I'll vote the former. And having to choose between WinForms (something similar to VCL.NET) and WPF (something totally different and quite cool), I'd vote for the latter. The mistake was probably to redo the entire IDE for supporting the WinForms designer, but that's another story!

Summary: Delphi is the VCL

If you've read the entire post, you should know what I think. For me, Delphi "is" the VCL. So any advance for Delphi should be bound to an advance to the VCL. For example, now we have overloaded operators, but the VCL is not using them... so you don't end up using them often! On the other hand, the for..in loop is a hit because of the VCL support for it. This is a double-edged sword. CodeGear must put a lot of effort to keep the VCL growing much much faster than in the past, with Unicode and all. And moving to 64bit and multicore support. And adding nice graphical features to it. And look for a smooth support of XAML...

Nick states that CodeGear wants to be different, not play catch up with Microsoft feature by feature. I fully agree. If Delphi is the VCL, CodeGear is leading!

posted by marcocantu @ 5:09PM | 29 Comments [0 Pending]

29 Comments

Delphi is the VCL

Marco,

Very well-written post.  I can honestly say that my time spent 
developing WinForms code was some of the least pleasant in 
my development career.  It's not because it couldn't do 
something, it's because it was often not particularly elegant, 
required too many steps, and of course performed like crap.

I realize that Delphi on the .net platform will most likely never 
have the kind of 3rd party support that Delphi Win32 had (or 
has) because Microsoft's .net stuff has sucked much of the 3rd 
party oxygen out of the room, and the 'big pile of cash' that 3rd 
parties which to tap into is there. 

I think one fundamental question that CodeGear has to ask 
themselves is how Delphi and VCL can make it easier to re-use 
and share components than ever before, such that the 
COMMUNITY ends up replacing much of the role of dedicated 
3rd party developers, so that a great deal of leverage can be 
obtained even if companies like DevEx go do their thing on 
VS.NET.

Randy

Comment by Randy Magruder [http://randymagruder.blogspot.com] on June 25, 18:17

Delphi is the VCL

Marco, thank's for this post. Is the best thing about
delphi I have read in time.

Comment by dani on June 25, 18:24

Delphi is the VCL

"Of course, the OS must be native, but all the system
utilities and tools are native as well. This is odd"

I think this is NOT odd, at least by MS perspective.
Let's say, for example, that they wrote the control
panel apps (that are not console applications) in C#.

Well...every winform app sucks-up from 10 to whatever
MB of memory. Imagine to open 4-5 of these apps.
Imagine to open some of the other OS "apps" that are
(ypothetically) written in C#. Imagine that some more
"core" parts of the OS are written in C#...I hope you
get the idea.

The office is something like that. Sure, Excel can be
re-written in managed code but it will perform badly
and would required one of our memory modules to run...

I think that MS pushed .net very hard, and they still
pushing it. I was an early believer too! But the fact
that they do not use for their own serious stuff and
that is locked to windows are the main reasons that
made me use it less nowadays.

Comment by kikapu on June 25, 18:37

Delphi is the VCL

First a few typos, not very serious but a bit
distracting though:
 - "the bugger picture" -> "the bigger picture"
 - "it main product" --> "their main products"
 - "He claims yuo" --> "He claims you"
 - "move to WFP" --> "move to WPF"
 - "shuold be bound" --> "should be bound"
 - "overlaoded operators" --> "overloaded operators"

As for the article's contents, I agree with you 100%
and I also think CodeGear is going the right way.

Besides, for someone just wanting to start .NET with
no prior codebase, they'll probably use C# and MSFT
tools (they can even do it for free and still make
money out of what they create); everyone that is going
Delphi.NET definitely has some Delphi (read:
ObjectPascal) source code that they either want to
migrate or they want to re-use in their new projects
and thus they will most likely end up using VCL.NET
instead of WinForms anyway...

Sure, it's hard to drop that half-dozen users that are
actually doing .NET *and* doing it in Delphi *and*
using Winforms, but they really need to cut their
losses and no one can please 100% of their customers
no matter how hard they try, so better focus those
resources on making the other 98% of the users happy,
even if that will cost them the other 2%...

In the end, with 64 bit support, Unicode and
IDE/Language/runtime improvements, they will get back
more than those 2% that left because of no more
WinForms support.

For the record: I don't have any numbers about the
98/2% ratio of non-Winforms/Winforms codes in Delphi,
but it surely must not be too different from these
figures as CodeGear would not cut down on it if it had
a significant number of users using WinForms!

Don't forget that they had a poll quite some time ago
that will probably be helping them make this decision!

This is where those few Delphi+Winforms users are
thinking: "Damn! I knew I should have filled in that
poll! :)

Comment by Fernando Madruga [http://memyselfanddelphi.blogspot.com] on June 25, 18:43

Delphi is the VCL

Hi Marco,

I happen to be one, or the one ;-), delphi .NET 
developer. What you say would be so great if they did 
from the beginning!
CodeGear(Borland) has fragmented their market into 
two main streams Winform and VCL.NET, if they had 
chosen one stream from the beginning we would not 
have this problem right now.

I hope for CodeGear that it works now, but I have my 
doubts.

Comment by Roland [http://beensoft.blogspot.com] on June 25, 18:56

Delphi is the VCL

 Hi Marco
While I agree with you that Delphi is the VCL,the
following will make Delphi a well rounded
product(according to me)
- Win 32 /win 64(already planned by CG)
-VCL.net for ECO(expected in Highlander)
-Genrics(already on the road map though only for .Net)
-CF
-Linq-It is still in beta
-Delphi asp.net(already there & .Net 2 is on its way)

Hence only CF support is the missing link/feature.The
choice for CG is either develop CF in win 32 or
.net.Obviously vcl .net will be the easier option.
Hence if CG can just change the road map to include CF
support with .net ,all mouths will be shut.
Hope Nick Hodges is reading this

Comment by Venkatesh VT on June 25, 19:21

Delphi is the VCL

Congratulations. You have manage to describe Delphi in
a single phrase. "Delphi IS the VCL" and I agree 100%
with you.

Comment by Stelios [http://www.10dailythings.com] on June 25, 19:51

Delphi is the VCL

Very true, Delphi is VCL. But...

While there is a flux in UI paradigms in the .Net 
world, there is a very significant overall direction. 
The close connection between WPF, XBAP, SilverLight 
etc. makes it possible (more than any other time) to 
create common UI elements for Client Side and Browser 
hosted applications. Considering the push from pretty 
much everywhere to a more service oriented 
application architecture, this is a significant win. 

At the current state of affairs at CG, it looks like 
Delphi and VCL.Net will be atleast one release cycle 
behind the latest from MS. Making VCL.Net platform 
neutral, atleast within .Net, Win32, Win64 circle is 
crucial to support fast changing technology outside 
the control of CG. 

I am not sure this is what I see. For e.g .Net 
compatibiltiy breaking changes introduced in D2006 
Win32 and beyond for Unicode, like WideStrings.

Ideal VCL will be write once, compile in 
win32/64/.net/Mono. With accompanying 
interoparability solutions, I can use Delphi as the 
only tool I need to provide most solutions, provided 
the IDE will stop crashing so much...

Comment by Salim Nair [http://www.salimnair.com/blogs] on June 25, 21:33

Delphi is the VCL

Hi Marco,
Very nice article. 100% agree.
But try to read this article:
 http://blogs.codegear.com/DavidLock/archive/2007/06/0
6/35598.aspx
It doesn't look like CG want to invest to robust VCL.
From David Lock (CG VCL employee):
"I would agree that it is a small team. However the 
choice is a small team or no team. We simply don't 
have the resources to employ a large team to work on 
any area of the product. We do what we can with what 
we have."

Comment by Peter Schutz [] on June 25, 22:20

Delphi is the VCL

 I agree 100%, delphi is the VCL.

What we need is:
- New VCLs such as a ribbon control, UAC components...
- A smooth transition to 64bit. We already did it once
from 16 to 32 bits in Delphi 1 to Delphi 2 - It was
very smooth, some components needed minimal changes,
but it worked.
- Better multi-threading support.
- Better support for Microsoft's latest operating
systems (Vista, and beyond).
- New ideas that do not exist in Visual Studio (I
Remember the Difference between Delphi 1 and VB3 ...
it was a WOW factor).



I don't care about .NET in Delphi, .NET is a tool for
ASP.net, using VB.NET or C#.  Winforms does not really
exist that much in the VS2005 world, it seems like
it's an illusion.

Comment by Osama ALASSIRY [http://osama.alassiry.com/] on June 25, 23:29

Delphi is the VCL

 One more thing... The transition to unicode should be
transparent, just like in ShortString to AnsiString.

Comment by Osama ALASSIRY [http://osama.alassiry.com/] on June 25, 23:33

Delphi is the VCL

 Good post mr Cantu. Delphi is VCL. And now is ten
years old with a yonger competitor. The war is not
between IDE but between framework. Mind it cg.

Comment by DMC on June 26, 00:34

Delphi is the VCL

 I only need one feature from VCL, only one.

Make it thread safe.

I don't need fancy ribbons UI, not .NET support, And
Im fine with the current set of VCL components.

But thread safe is a must have, Im having problems
with crucial part of my software for this like ugly
memory errors,and not elegant works arounds.

CG DEVELOPERS, MAKE VCL THREAD SAFE THE SOONNES POSSIBLE.

HAVE MERCY.

Comment by Ramsees on June 26, 01:03

Delphi is the VCL

I don't have used WinForms from Delphi but to do a
webservice sample client with two memos and a button,
even more, I don't know someone else using it, so I
agree.    

Along with the "Delphi: a well rounded product" IMHO:
   Right now, we developers matter about a simple but
powerful IDE/Library/language, but the world we are
working for is interested in things like improving
their business processes, certainty, absolute control
of their business, quality management, reduce and
manage risks, etc. 

I think, the more our work and our tools help us to
help our clients and the organizations to achieve
this, the more support CodeGear is going to have from
the rest of the world. So, Borland was taking these
thoughts to the extreme, now this doesn't have to mean
CodeGear has to take it to the another end and forget
everything about business process integration. 

There is, IMHO again, the central idea where CodeGear
should focus to make their strategy desicions, not
"what developers matters", but "what developers
needs".    

Support for DB technologies, Webservices, XML are core
ideas. Refactoring, native Modeling support, testing
framework were good samples. Now: Team Development,
Object-Relational mapping for persistence, some basic
requirement management (something more advanced than a
TODO list for example), and much, much more
information to starting up (making Marco's essential
delphi and pascal guides somewhat official maybe?),
those ideas are what I'm talking about, things that
take Delphi development into the enterprises, and into
the schools too. Subversion integration (now in the
roadmap) seems to me like one of the best ideas. 

But the central philosophy should be, I think: SERIOUS
robustness in the integration of all those concepts
(and I mean both VCL and IDE). So, go CodeGear, there
is still so much to improve and to work on.

Comment by Salvador Gomez Retamoza [http://salvador.oversistemas.com] on June 26, 02:18

Delphi is the VCL

 I just wish CodeGear would honestly admit that their 
dotNet efforts were illadvised, too little too late 
and have utterly failed.

They are taking an unattractive approach to dotNet 
and making it even more unattractive by making it 
even more non-standard than it was previously.

Honestly, what is the attraction of Delphi.net after 
this?  Does it do dotNet better than anyone else?  
No, it even falls far behind in features.  Does it 
interop with other seemlessly? Certainly not with 
VCL.Net as the framework.  Why would anyone in their 
right mind choose Delphi.Net?  Worse, why would 
someone working in C# want to even consider 
installing the trial version of C#Builder knowing 
they are coding for an out of date, technological 
dead end?

No, I have no problems with them dropping winforms 
support.  I just wish they had the honesty to admit 
that their entire dotNet venture failed and just 
refocus on what they have actually done well in the 
past - win32.  Delphi could definitely benefit from 
the attention, clearly it is still left to languish 
as they devote what few resources they have to push 
their pithy, undesirable dotNet offerings forward.

Comment by Xepol on June 26, 05:50

Delphi is the VCL

I agree Delphi is the VCL and I am one of the few who
had been using Delphi .NET with Winforms. Why? Because
of ECO! In fact the extremely poor quality of Delphi
.NET IDE had made me gone to C# for all later ECO
projects, I had NO choice and I am now stuck... Only
if ECO supports VCL .NET out of the box from day 1 I
would had been happy coding with Delphi, but now...

Comment by william on June 26, 06:48

Delphi is the VCL

 About .NET in delphi ... I would advise CodeGear to
buy "Managed-VCL" ... They allow you to interop with
any managed code (even use .NET components in your
win32 apps).

And drop Delphi.NET.

Comment by Somebody [] on June 26, 10:47

Delphi is the VCL

Well said Marco.

Comment by Steve Trefethen [http://www.stevetrefethen.com/blog/] on June 26, 18:23

Delphi is the VCL

Ok, I can't say "their entire dotNet venture failed".
Personally, we do A LOT of ASP.Net from Delphi, and I
have to admit we do it better than succesfully. You
should try it sometime, BDP and DBWeb controls from
Borland aren't a waste of time nor a failure. Of
course it is just my point of view.

Comment by Salvador Gomez Retamoza [http://salvador.oversistemas.com] on June 26, 19:57

Delphi is the VCL

First, very well thought and nicely written post. 

Yes!!! Delphi is VCL from the day 1. Delphi IDE was 
written using VCL. Advantage of the Delphi as a 
programming environment is VCL. As much as I like 
Pascal it was VCL which kept us in Delphi camp for 
years.

PS. I would love to see your review comment in my 
post ;)

Comment by Serge [] on June 26, 23:47

Delphi is the VCL

I have been coding with Delphi since version 1.
Everytime MS pushes a new Technology, I always see 
the same thing...everyone SCRAMBLES to use it.  

Funny, I am still coding with the Windows API and 
some of my programs from 10 years ago are still 
running without any changes needed.

Delphi is the VCL and .Net is a fad. 

I remember when Java was going to be the ONLY 
language out there....Another Microsoft push...I 
coded in Delphi.  My apps are still running and the 
Java stuff that was written is gone.


Get Delphi back on track and drop the ".whatever" 
microsoft claims will take the world by storm.

Comment by Todd [] on June 27, 16:47

Delphi is the VCL

 ""Of course, the OS must be native, but all the 
system
utilities and tools are native as well. This is odd""

"I think this is NOT odd, at least by MS perspective.
Let's say, for example, that they wrote the control
panel apps (that are not console applications) in C#.
Well...every winform app sucks-up from 10 to whatever
MB of memory. Imagine to open 4-5 of these apps.
Imagine to open some of the other OS "apps" that are
(ypothetically) written in C#. Imagine that some more
"core" parts of the OS are written in C#...I hope you
get the idea."

@kikapu: I think mauro knew it pretty well, it was an 
irony from his side saying that its odd ;)

Comment by Henryk on June 28, 11:22

Delphi is the VCL

I like the idea "Delphi is the VCL". It gives a 
clear focus going forward. It's like Kellogg's 
cornflakes, "original and best" -- by which I mean 
that it belongs to CodeGear and it is very much a 
winning concept and technology. It has the potential 
to be a "universal adapter" to target, which can 
protect developers from the flux of continual 
changes to platforms. In other words, the service we 
get from it is to keep our applications working and 
allow us to develop applications that will keep 
working on whatever new flavour of the month comes 
along. 

Here is something that works. Certain things like 
SQL and VCL just work. It does what it says on the 
tin. Visual Component Library. Nobody can come along 
in the future and say, we don't need a visual 
component library anymore. All they can say is I 
hope my visual component library continues to work.

Comment by Steve Moran [http://www.silverlink.co.uk] on June 29, 19:38

Delphi is the VCL

I read in Highlander CodeGear is going to  drop
winforms design to C# Builder, We can have support to
ECO in Vcl.net but I have a doubts and don't get any
answer, 

What option will have the developers are using ECO +
Asp.net in C# Builder, We can design the ECO model in
Highlander to C# Builder?

Which option We have in Highlander to ECO and C# Builder.


regards
Frank

Comment by on July 1, 20:13

Delphi is the VCL

I like the statement "Delphi is the VCL". Bang on 
target! However, it is important to keep in mind 
that Delphi is NOT an island. This is *why* we need 
Delphi.NET in the first place.

Delphi apps often need to interact with .NET apps. 
Sometimes this can be done with interop, or web 
services or in fact, by taking a Delphi app to .NET 
using VCL.NET. The fact is that paying customers may 
have standardised their platforms or have existing 
or new .NET apps that are important to them. Delphi 
and Delphi.NET gives you the opportunity to play 
both sides of the fence. Perhaps WinForms is a small 
part of this, but so far, it has been a supported 
part.

Why drop the WinForms designer? I would understand 
not enhancing it more than what is absolutely needed 
for .NET2, but dropping it?

What if I wanted to use existing Delphi code in a 
WinForms control needed by a client, for example? 
Technically, I could do it all in code. But what if 
it is a really complex control? So, I write a 
VCL/VCL.NET control, wrap it in COM to use interop 
to wrap it in .NET? Seems clumsy - not a killer, but 
certainly a disincentive.

And of course I just took over a C# app that my 
Delphi app interacts with. It is too large to be 
rewritten in Delphi and I suddenly don't have design 
surfaces! I now need VS.NET *only* because CodeGear 
decided to drop the designer.

I want CodeGear to spend most of their effort on the 
VCL. But why remove functionality that is already 
there? I wouldn't call this a blow for Delphi as 
such and I certainly won't dump Delphi over the 
missing WinForms designer. But CodeGear - where 
developers matter - sure don't always seem to take 
into account the ecosystem those developers function 
in.

Comment by Cobus Kruger on July 2, 15:08

Delphi is the VCL

For me, Delphi is NOT the VCL.  I have used all the 
Borland Pascal versions since Turbo Pascal 1.  I 
didn't use them because of the component library.  I 
used them because of the language.  It is a 
relatively clean, fast to compile, easy to read 
language.  The VCL is yet another component library.  
It is an important part of what Delphi is, but if 
they had a better component library, people would use 
that instead.  The one reason that I have used 
WinForms is because of ECO.  I think ECO IS HUGE!! 
(and CodeGear is missing the boat by not promoting it 
and documenting it properly)  I only recently started 
looking at it because I have a new machine that can 
handle it.  I probably wouldn't have used WinForms if 
ECO didn't require it.  ALL of that being said, DON'T 
DROP FEATURES.  If it was important enough to add, 
then it is important enough to keep.  I don't want to 
have to redevelop my an app because I happened to use 
a piece of Delphi that they will drop in the future.  
I don't have that much time.

Comment by mtiede [] on July 5, 16:13

Delphi is the VCL

 This obviously wasn't any easy decision
for CG, for all the reasons that people 
have pointed out.

Which raises an obvious question.
Why drop a feature which is already implemented
and which you know is going to make people 
mad and feel duped.

Since we are reading between the lines already,
I'll take it a bit further and try to read the 
back of the page.

I'm guessing that the WinForms designer in 2.0
had more hooks into VS than in 1.1.
Same as the problem they had with the CF designer.
There had to be some high cost to keeping it 
that we can't see.

This is pure speculation of course, but it
is the only reason I can think of for why 
they would drop an implemented feature.

Comment by Brad White [] on July 6, 19:31

Delphi is the VCL

I strongly disagree.

The VCL is a relic from the past. It used to be the 
core of Delphi.
The biggest mistake Borland made was to create a 
VCL.NET.

I think that CodeGear has to split the two 
environments. Make a separate Win32 (Win64) with the 
VCL and a plug-in for Visual Studio for the .NET 
development without the VCL.

But most important is:
Make Delphi more stable and improve the update 
process.
Make it cheaper.

At this point we are unable to install the updates 
because we installed Delphi without preserving the 
installation cache.
The frustration grows by the day.

I also disagree with the assumption that WinForms is 
not being used.
95% of our applications are standard windows apps. 
We are in the process to convert more than 100 
applications to WinForms. (Without VCL.NET) 

At this moment I can’t see much feature for Delphi.
I am sorry, but for me Delphi is a dead product.

Regards
Johan Visser

Comment by Johan Visser on August 28, 11:30

Good

Good information, i have an idea on it.

Comment by Ray ken [http://homehealthcarejobs.blogspot.com/] on June 29, 19:02

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.