[fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.

Skybuck Flying skybuck2000 at hotmail.com
Thu Dec 18 18:47:50 CET 2008

----- Original Message ----- 
From: "Florian Klaempfl" <florian at freepascal.org>
To: "FPC-Pascal users discussions" <fpc-pascal at lists.freepascal.org>
Sent: Thursday, December 18, 2008 12:10 PM
Subject: Re: [fpc-pascal] FreePascal/Lazarus plug-in's for Delphi.

> Skybuck Flying schrieb:
>> Hello,
>> To make it easy for Delphi programmers to write code in Delphi and then
>> switch to free pascal/lazarus the following could be done:
>> Delphi's IDE is still more stable than Lazarus IDE.
> Why should I/we spent time into improving other people's software
> (making a delphi plugin) instead of improving our own software
> (debugging lazarus)?

Let's go back in time a bit to find out the answer.

Turbo Pascal/Borland Pascal came first, then Delphi came, and then probably 
free pascal, give and take a little.

The first three mentioned products were and maybe are still much more 
populair than free pascal.

Therefore I bet a lot of code has been written in turbo pascal, borland 
pascal and Delphi.

Therefore making sure that your free pascal compiler and lazarus can compile 
all that code that has ever been written doesn't actually make Delphi a 
better product since Delphi can already compile all that with minimum 

No... it makes *your* free pascal "product" a better product !

So you're wrong when you say you would be improving other people's 
product... especially if you ment Delphi... if you ment my own products then 
again you might be mistaken since lazarus doesn't seem that super yet, also 
for me personally I haven't made any big free pascal projects yet so that 
remains to be proven as well ;)

I tried compiling the free pascal compiler in Delphi and noticed how free 
pascal had some language features which were not supported by Delphi, which 
scares me a bit... I would like to have the ability to go back and forth 
between compilers because that's in my own best interest ;) and actually all 
pascal users.

So I hope all pascal compiler writers, free pascal, delphi, maybe even 
delphi prism/oxygen whatever work together to make sure the pascal community 
is not fragmented across different pascal language extensions because 
ultimately that would hurt all of us pascal programmers.

Therefore compiler writers that want to compete with each other should not 
compete with each other at the language extensions front... they should work 
together to make the language better that is in the interest of all.

Thus the pascal compiler writes should make sure there is one pascal 
language and not a zillion different ones.

Competition between pascal compiler writers could focus on:

1. Higher quality of compiler in the sense of:
1.1 Less crashes of compiler.
1.2 Less bugs of compiler.
1.3 Better code generation of compiler for higher performing code.
1.4 Faster compiler.
1.5 Cross compiling to different platforms.

Now a word about the plugin concept and the reasons behind it.

At least for Lazarus I wonder how much time it would make to create a plugin 
for Delphi.

If the lazarus code is compatible with Delphi then at least it won't have 
language porting issue's, so scratch one issue.

Then it depends on the widgets/gui components... do they have their own code 
to draw things ? or do they simple wrap some gui library ? Are they wrappers 
or true components themselfes ? Or maybe a mix of things ?

Whatever the case may be... the Delphi VCL is worked out well and has been 
around for a long time... maybe it has a bug here and there... but nothing 
too serious... therefore supporting the Delphi VCL is a good investment of 
time !

This will make Lazarus more valuable as well to Delphi programmers, so then 
can switch more easily.

Other benefits might include: Lazarus wrappers around the VCL might still 
contain bugs and can be debugged by Delphi programmers themselfes. Maybe 
these could even highlight design errors or bugs in the lazarus wrappers.

Also if Delphi programmers start switching to Lazarus then maybe on the long 
run they will start using Lazarus more often... and when they run into bugs 
in Lazarus itself they might become interested in helping out... finding 
Lazarus bugs and maybe even trying to fix them.

When it comes to debugging Lazarus this seems difficult. How does one debug 
Lazarus with Lazarus ? Very strange really...

If lazarus crashes... then how could I possible debug it ? Since it already 
crashed ? Pretty strange...

Maybe an idea would be to use two Lazarus instances... one which will be 
debugged with the other Lazarus instance... but then it's hoping that not 
both will crash... ;)

These kind of debugging technique's should be documented somewhere... maybe 
even on the "frontpage" for maximum exposure ;)

However now the question becomes the opposite:

Why would we Delphi programmers invest time in trying to make Lazarus better 

Why would we Delphi programmers invest time in trying to make Free Pascal 
better ?

So far these two tools do little for us Delphi programmers:

Lazarus is still buggy, and kinda annoying ;) :)

We cannot easily move our Delphi code to Lazarus.

We cannot easily move our Delphi code to Free Pascal, this is partially 
because of new Delphi language extensions... and VCL fields/properties 
missing in Lazarus...

I would like to bring to your attention this project:


DWPL... it was quite impressive... it had a text gui which was compatible 
with Delphi... not sure if it's still compatible with Delphi 2007... 
probably not... maybe it has the same issue's as Lazarus now has... maybe 
Lazarus was even based on it... (?)

Now finally the question is... why or why not keep compatibility with 

Delphi has this VCL... it's code is maybe protected by copyrights by 

You guys want to distribute your own products... but you cannot include the 
VCL from CodeGear because of copyright reasons.

These are legal questions.

There is such a thing as "a derivative work" which then maybe becomes a work 
in itself if it's modified enough... not that many modifications are needed 
to become "a derivative work".

I am not a legal expert... but it's worth looking into this to see if 
somehow the VCL code can still be used.

If this is not possible, maybe a wikipedia like donation initiative might 
work... for example CodeGear or whatever there name now is... could put a 
price tag on their VCL like:

"We want 5 million dollars" and then we will open source it...

Maybe if all pascal programmers put in a few bucks it will be open sourced 
:) maybe even some companies interested in supporting it ;)

I like to spent my time as efficiently as possible... and I sure hope that 
other people do to...

Recreating something like the VCL and Lazarus seems partially a waste of 

I for one will not attempt to re-create something like the VCL so don't 
expect any help from me at least at trying to do something like that... it's 
up to other "crazy" people that believe in such a project or have the time 
for it... I sure as hell don't ;)

However I am willling too:

1. Find bugs in Lazarus.
2. Find bugs in Free Pascal.
3. Find bugs in anything else.
4. Suggest improvements.
5. Maybe even provide the occasional bug fix now and then.

However all these 5 would only be related to my own products whenever I 
encountered a bug.

This seems more then reasonable for people who make their own products:

Find bugs and fix them for as far as it relates to your own products.

Therefore the end conclusion can only be:

1. The more users use Free Pascal/Lazarus, the more bugs will be find, and 
the more bugs corrected and fixed.

2. To get more users for Free Pascal/Lazarus it must provide something 
valuable to existing pascal programmers especially on for example Delphi:

This means:

2.1 Maximum compatibility with Delphi. Preferably two way: Free 
Pascal/Lazarus <-> Delphi.
2.2 Easy porting of code and gui's/dfm's, maybe even packages and projects.
2.2.1 Helpfull could be FreePascal/Lazarus plugins for Delphi to prepare 
Delphi projects for transition to Lazarus/Free Pascal.

Also think of other possibilities:

If lazarus code works in Delphi, and if lazarus can be compiled with Delphi, 
then Lazarus can actually be improved and debugged via Delphi. Many Delphi 
programmers available to look into something like that.

Some people mentioned trying to get free pascal compiling in Delphi and how 
it failed because of Delphi bugs... I truely wonder about that...

Did they split everything up into Delphi packages ?

Was the real problem with unsupported free pascal language extensions in 
Delphi ?

I can only recommend a modular approach to free pascal compiler and lazarus.

Split everything up into modules/packages.

Create test programs per module and package to test the module and find bugs 
and problems.

These test programs don't actually have to compile but they should indicate 
that it's possible to debug the module at the very least... without needing 
loads of other code.

Some more critique on free pascal:

I wonder how "modular" free pascal really is ?

The file names of free pascal are a bit cryptic ? Why not longer file names 
? (Only reason I can think of is dos.. but screw dos for now ;), dos users 
can fix dos with long file names ;):))

Here and there the source seems a bit focked... everything lower case... 
like tmyobject... why not TMyObject ?

But ok critique points there.

I also wonder about the docssrc which is in tex... the make doesn't work... 
what does it actually produce ?

Is it the same docs as the docs folder ? this is confusing.

Maybe the free pascal source tree/project has become to large and should be 
split up into "modules" that can work together.

A random idea:

1. Compile pascal to some sort of intermediate code. Stop there.

Call this the "pascal compiler to intermediate code".

2. Maybe add a intermediate step like:

A intermediate code to platform compiler which fixes the api calls and such.

"pascal intermediate code compiler to platform byte code".

3. Then add the final step:

"pascal platform byte code compiler to platform instruction code".

4. Maybe then add a linker for libraries if still necessary.

Add any additional steps I might have missed for example:

3.5 platform instruction code into platform executable format.

This idea could split up the free pascal compiler into a "tool chain"... 
where there are multiple compilers and such...

Finally a team could try to melt it all together into a nice distribution 
for the end users.

So this gives all kinds of possibilities:

Users interested in parts of this toolchain/pipelining can look at 
individual parts and figure out how they work... and maybe even improve or 
fix or debug them.

This should hopefully give the possibility of only downloading a certain 
module/part of the pipeline and be able to somehow compile it with the 
existing one... and look at it, inspect it, learn from it.

Finally this might make it possible for other to create/add additional 
modules for new platforms.

Since they don't actually have to know the entire tool chain/pipelining...

Maybe the only need to know little bits of it to extend it !

Hopefully totally compatible with Delphi and all other pascal compilers ! ;) 

So there ya go... those my thoughts on all of this ;)


More information about the fpc-pascal mailing list