There is no .Net in the new Delphi roadmap you say. And this is not true. HL is a .Net release. and there is more to it…

There is my take on this: Why should we care so much about “platform” layer? Why are we forcing CG to care so much about platform layer?

Nowadays environment is no longer “pure” such as – only Win32, or only .Net. There is mix of old and new applications.

Approach taken with BDS and early VS was great – one can develop both Win32 and .Net.

Now with CG being between two (three) fires and being burned from both sides, it is tough for them to please both with approach taken – by using “pure” adoption of both platforms.

I strongly agree with some, we need VCL 2, aka redesigned and abstracted from OS level and having adapter layer for each platform (if and where it is needed). I love idea of having one IDE and one language for all platforms – VCL->.Net->Win/Mono or VCL->Win32/Win64 or VCL->Mac.

Can it be done? Yes.
Will it require resources? Yes.
Can it be done? Yes, but…

First, CG has to have strong cash flow and able allocate resources for research not for maintenance/improvement purposes, but for actual research of new infrastructure.

What I see today is that CG taking on something they are comfortable with – Win32. I do not think there was ever clear understanding in the team on why they need .Net support. I do not see sometimes that MS has this understanding.

And might be a new roadmap just show it – taking step back into comfort zone, looking around and see what was gotten wrong.

Should we be worry about support for .Net? yes. Do we like it or not it will be around. It is almost a decade past of people talking how Unix/Linux/Java is great and free, but Windows is still around and growing.

So I think way to survive and innovate in such environment is to do not care about platform and trying to target directly one platform or another, but instead go further and above all of this.

First step would be to make compiler/IDE work for every platform and being as simple and open as possible. Have N compiler layers for N platforms. Have it pluggable into IDE.

Second, take all new good stuff and bring it into Delphi as language (forget VCL for a second)

Keep in mind though, that which IDE is developed set of basic components will be collected, but since IDE will be above platforms, so newVCL will be as well. Stop!!!!! Yes, VCL model should be in place taking best of VCL 1.0, .Net FW, etc. Then components developed for IDE should fit this model and thrive on it. And … we would have Delphi 1.0 for MPE (multi-platform environment).

Having that will ansure future of Delphi as a language and as an environment along with future of CG.

Categories: Delphi


Oh no! · Jun 20, 2007 at 10:46

Oh,no, not another VisualCLX

Serge Dosyukov · Jun 20, 2007 at 11:19

No, not VisualCLX.
Problem with attempts made before was that it was adoption of core VCL to the environment. VCL is not designed to be adopted and therefore adoption caused branching of the source, introduction of different class model.
What should have had happen is keeping surface intact – VCL for Win32 = VCL for .Net = VCL for Linux = VCL for Mac where adaptor level is what is proveded without changing any code in the core.
Consider it as universal API for all core functions used in VCL.
Another would be to use IDL for core code and then has implementer of IDL for particular platform.
Hm, it starts to sound like .Net… might be there is something in it and .Net should be used as core platform 😉

Daniel · Jun 20, 2007 at 14:30

Like wxWidgets

Serge Dosyukov · Jun 20, 2007 at 14:39

Might be. There is a lot of “like” around. But problem with them that they are incomplete, evolving without the structure or with intend that somebody else will improve them.
Advantage of VCL in 1995 was that it was complete, robust, extendable and it was Delphi. 😉

Fabio · Jun 22, 2007 at 03:24

Why not help the FPGUI project?

It’s compatible with MacOSX, Win32, WinCE and Linux.

PS: MacOSX is under working.

Serge Dosyukov · Jun 22, 2007 at 09:28

It is not about GUI project. It is not about platform either. It is about VCL.

We have seen what happen to JBuilder. Can it be done with Delphi IDE and VCL?

Somehow it did not happen so far. Might be because of small level of interest from the community or there could be other factors.

If someone is switching to some other environment from CG Delphi IDE there is a decision to be made if you should stick with Delphi at all. I, personally, have no problem to go and work with VS. I do not really care much about languages and/or platforms. Problem with Delphi lately that we are trying to make it so pointy to the platform.

Yes, FP as a concept is great. What worry me is the following statements:

“Object oriented programming And if you do the serious programming, you are of course very interested in object oriented programming. Use the Turbo Pascal and Object Pascal ways of OOP according to your taste. The FCL and Free Vision and provide you with the powerful object libraries you need. For your database needs we support PostgreSQL, MySQL, Interbase and ODBC. ”

So, there is a great distance for it to go.
CG would not need to use some other solution, they have their own. You do not want another Kylix failure, do you. Can we get another Eclipse but for Delphi? Did not happen, for some unknown reasons…

Brad White · Jul 6, 2007 at 09:28

I am totally opposed to a cross platform version of Delphi.

While I like the idea, theoretically, of having one IDE and VCL
for all platforms, in practice it can’t ever work.

As you mentioned, there are lots of attempts at this and they
are all incomplete. It is a catch 22. Until they are complete,
people won’t use them, and if people are not using them, there
is no incentive to complete them.

Delphi can’t even keep up with 2 platforms when one isn’t moving!
Let alone trying to have the VCL be compatible with multiple
platforms. That would just tie it down, and they would spend
all their time tying to keep up with the platform and no time
or energy left to innovate where they should – on top of the platform.

Other parts of the application are easier to port, and I’m OK
with that. Say if they wanted to release a server-only version
of Kylix. But GUI components are notoriously difficult to port.
And you end up with the base common features for each,
instead of the best of any.

Lastly, each UI has its own behavior, language if you will.
Applications should be rewritten for the new target to
take that into account.

I’m OK with the idea of having a Delphi-like IDE for other
platforms. I don’t blame people for wanting that.
But I definitely don’t want it to be Delphi itself. I don’t
want it to be shackled to more platforms than it already


L505 · Jul 23, 2007 at 18:40

If there is a kylix it should be geared toward making CGI/Apache related items, and the items kylix creates should not require a dedicated server to run. Making use of existing infrastructure such as CPanel/Plesk web hosting accounts is essential. CPanel is the “windows desktop” of linux.

Moderator: This comment has been moderated as it contains hidden advertising. Sorry.

Ebikekeme Ere · Sep 5, 2007 at 07:33

Delphi 1.0 for MPE will not fly. It might just become another fluke like Kylix

Yogi Yang · Oct 4, 2007 at 02:02

New and updated VCL is a priority but I think we are missing very obvious thing here. If we look back and observe we will see that.

If any one has given some thought to VCL it architecture and design, will surely have observed that one has to use DELPHI (or C++ Builder in some cases) only for building VCL and no other development language or tool can be used. This is a serious limitation.

Say for example I am a good programmer in C++ and have developed a library which has got lot of functionality which a Delphi developer can use, as such functionality is not there in Delphi. Now to make this possible I will have to learn Delphi or find someone who has strong hold on Delphi as well as C++ and get him to translate the whole library to Delphi and obviously charge for that. If I want to launch the library for free I cannot afford spend on getting it converted to Delphi.

The solution is that, Delphi should be able to use and link with C++ libraries.

This means CG will have to change the very file format of their DCUs and OBJs to COFF as at present they are in OMF (or some such) format. I can bet CG does not have enough cash and inclination, to change the very foundation.

Another solution is to add support for compiled VCL libraries which can be and may have been written in any other language but as long as they are created based on specification of CG there should be no problem.

YES. I am talking of adding external dependency as M$ did for VB which is OCX. But instead of OCX develop such an Extension system that there is no GUID, UUDI business and everything can be deployed just by using XCopy. Don’t misunderstand me here this is necessary and M$ in their arrogance has missed this thing totally in their new Development tools viz. .NET!

Don’t trouble you mind for a solution. There is one already existing and was very very successful during its era, was easy to implement, and robust. The VBX technology!

Are you getting me?

On analyzing the design of VBX I have come to the conclusion that is it more usable then OCX/COM togather and easy also. We can modify and extend the proven and really usable VBX technology of M$ as it is easily expendable to true 32Bit as well as 64Bit platforms.

When I say VBX I do not mean it literary. But we should develop some such Extension system which is OS independent.

Ok you may say why the hell do we need yet another library/extension system which will add a HELL of external dependency, instead of getting compiled directly in the EXE (executable) file. Well this is a necessary evil. I have been tracking a variety of computer languages/compilers and have found that none have succeeded as much as M$’s VB. See VB is easy to use and so is Delphi, but why has Delphi not caught on as much as VB? Think over this and you will have an answer for yourself.

Besides the language part it is this extendability that has made it popular as any developer who does not know VB can develop Extensions in form of VBX/OCX and thus allow a VB developer to do what is normally not possible in VB.

I know some of you will immediately point to the fact that Delphi supports COM very well. But the fact is that it is not to the level required and this is evident from the fact the better COM support has to be implemented in Delphi in the Roadmap.

Think it over.

Leave a Reply

%d bloggers like this: