Hi the list...

You probably don't know me but I'm for years a Lazarus fan.

I have to prepare a conference for February 2010 in my LUG. The main theme is to give a good idea of what are Lazarus and Free Pascal with technical demonstration. This is the easy part... The public will be mainly Delphi users (including companies) that want to move from Delphi to Free Pascal. So I need help with details about which problems they can meet, the solutions, supported feature, and not (yet) supported ones...

If you have information or ideas about precise things that I must give in such a conference, please tell me...

Thanks a lot!

Having ported/developed some applications, the main problems when porting are IMHO:

a) They should not expect to find the same components in Lazarus as in Delphi. (This concerns mostly DB components, web components. GUI is mostly covered)

b) Third-party components are usually not usable.
(unless that company supports FPC, which is unlikely)

c) Cross-platform development means:
- No Windows API. (e.g. the registry).
- SizeOf(integer)SizeOf(Pointer)!
- No assembler

And under no circumstances promote '1 source for both Delphi/Lazarus' because that is a recipe for problems :(

Michael.

Michael Van Canneyt wrote

Having ported/developed some applications, the main problems when porting are IMHO:

Same here for apps, including many Delphi components.

b) Third-party components are usually not usable. (unless that company supports FPC, which is unlikely)

If you have the source code for such 3rd party components, and you really need their features, it is not that hard to port to LCL. I have successfully ported about 5 such components to fpGUI Toolkit is a lot more incompatible with VCL compared to LCL. So LCL should be even easier.

c) Cross-platform development means: - No Windows API. (e.g. the registry). - SizeOf(integer)SizeOf(Pointer)! - No assembler

+1. Any not all components behave like Delphi. After all, they target more than just the Windows platform.

And under no circumstances promote '1 source for both Delphi/Lazarus' because that is a recipe for problems :(

Definitely NOT! That is a nightmare to try and maintain.

Also it is worth mentioning that the RTL and FCL have some really nice goodies include to make cross-platform development earlier. So you might have to forgo an API under Delphi for something cross-platform under FPC's RTL or FCL.

Another HUGE bonus. Support is so much faster than with Delphi. Most bugs get fixed in hours or days - not years. Plus you don't have to pay for those fixes later on.

Le lundi 12 octobre 2009 21:23:50, Graeme Geldenhuys a ?crit :

Ok I was nearly sure of that, but if someone ask me for coordination method... In an other word, is there any simple way to coordonate Delphi and Lazarus version of the same source ?

Maybe a tool using diff api or something like that.

Yes, there is:

http://wiki.lazarus.freepascal.org/XDev_Toolkit

Make any form design changes in Delphi, then convert the .dfm's to .lfm's.

Thanks.

-Phil

Here are some more details:
http://wiki.lazarus.freepascal.org/Lazarus_Documentation#Coming_from_Delphi

Mattias

When a source is compiled for console application , with respect to my experiences there is no much difference between Free Pascal and Delphi .

The important difficulty is caused by GUI parts of the programs .

The following idea may be tested for applicability ( I did not applied it myself yet , but this is the my next step to try ) .

Assume you have a BIG Delphi program and you want to compile it with Lazarus due to its GUI structure .

By using Lazarus , re-generate forms as much as possible . In Delphi , convert parts to procedures ( or functions ( personally I am NOT using function because their maintenance is really very difficult ) ) unrelated to GUI parts as much as possible ( for example , checking the validity of contents of a string , computation of some formulas from some values , etc. ) . Call those procedures from Lazarus generated forms . At the end there will be GUI-independent procedures and GUI-dependent forms . Since forms are generated by Lazarus , they will be cross-platform and they will not depend on Windows unit ( We are assuming that GUI-independent procedures does NOT depend on Windows unit ) , they will be compilable and usable on platforms supported by Lazarus .

In that way , the total job is divided into three parts :

- Maintenance of GUI-independent procedures ,
- Maintenance of Lazarus forms .
- Maintenance of Delphi forms .

Trying to compile a source written with Delphi specific features by Lazarus by using ifdef-else directives to distinguish Lazarus and Delphi specific parts is to generate a source which is a nightmare to maintain . To avoid such a structure I am thinking seriously to write Windows_for_Unix and Windows_for_Linux units from scratch . I think this is much easier than to maintain a source described above .

Thank you very much .

Mehmet Erol Sanliturk

with the few very minor ones i've done, i pretty much agree on this...

The important difficulty is caused by GUI parts of the programs .

yes...

there is, in the menu at the top of the screen, a dfm->lfm converter... in fact, there are several delphi->laz converters up there... one converts forms, another converts units and there is a third one, too... these may help in conversion from delphi to lazarus...

the problem(s) i've found and not yet posted about are

1. which converter to use when...
2. is there a special order they need to be run in?
3. according to the wiki, there are some lines to add and others to change... does one of these converters do this?
4. it would be very nice for these converters to give a list of unknown procedures that they cannot rename or convert to laz style (if they even do that at all)...

what i'd really like to see, since i don't have delphi that i can work with and no delphi manuals available, would be an "app" converter... this way, one might point to the app file (dpi??) and have the converter walk thru all the dfms and units for the application and convert it all to lazarus...

another nice thing would be for the converters to move the delphi files to a subdirectory like laz does with the backup directory... maybe call it delphi~... in this way, someone like myself, who is flounder along trying to get things converted and working won't get confused if they have already converted something and possibly edited it and then loose those edits by converting again... it is a bit of a trouble to have laz open and also a window of the directory and manually move the files after they've been converted... especially when converting a lot of them and having to do one at the time, compile, try to test, start again or try converting another one...

2009/10/14 Mehmet Erol Sanliturk :

I would recommend you guys seriously look at only using Lazarus. What does Delphi offer that Lazarus doesn't. And then, to be fair, what and Lazarus offer that Delphi doesn't.

Our company switched some 5 years ago to only using Lazarus and FPC. Haven't had any major drawbacks - in fact this are working much better. Plus we are saving huge costs for not having to purchase development tools every 1-2 years. In return for getting such a lot for free (including the brilliant support form all of you), we are allowed to work on Lazarus features ever now and again in company time, to contribute back to the community.

To be honest, I can't really see any benefit in using Delphi these days. Here is a small comparison - as I see it:

- Lazarus is cross-platform, Delphi is not.
- FPC is cross-platform, Delphi is not.
- FPC has 64bit support, Delphi has not.
- Lazarus IDE is easy to extend and fix, Delphi is not.
- Lazarus Packages are brilliant, Delphi cannot compare
- FPC's FCL is fantastic, Delphi doesn't have something like that.
- Both can do GUI, Console and Web applications.
- Delphi is a bit better in the debugging environment, but the new FPC v2.5.1 (trunk) has been some good progress in that department. Debugging in Lazarus IDE is a lot more usable now.
- Bug fixes are free for FPC & Lazarus. You often need to upgrade to the next Delphi before you get fixes (that's IF they fixed it).
- You can always stay current with the latest FPC & Lazarus features for free. You have to purchase Delphi every time.
- Lazarus IDE is much less resource intensive. Delphi IDE is a dog.

Disclaimer:
These opinions are mine alone. In now way does it reflect the opinions of the Lazarus or FPC developers.

The problem exists for an EXISTING code base . When it is NOT trivial to compile it with Lazarus due to heavy dependence on Delphi specific features ( actually Windows specific parts ) causing semantic differences between Lazarus and Delphi ( especially because of widget sets ) it is becoming necessary to pursue a dual compilation environment up to a complete conversion .

For that reason I wish to have Windows units both for Unix and Linux ( at least for me , but for all supported platforms , having such units will make portability very easy for the Lazarus users in those platforms )

For a new start-up project with Lazarus and continuation with Lazarus there is NO problem because it may continue with only Lazarus .

To be honest I prefer to be able to compile the same code base with different compilers as many as possible to enable code reviews by different "EXPERTS" . By using dual compilers as ( Free Pascal , Lazarus ) and ( Delphi versions ) I have been able to catch many different errors recognized by only one of the compilers but not with the other . I will continue to use such multiple compiler application .

Thank you very much .

Mehmet Erol Sanliturk

+1: I agree so much on that. Port the code to Lazarus, and then stay there, currently! It's very possible to have back-end (no GUI) components that are delphi- and lazarus- compatible, but then you're forgoing some of the advanced goodies of Delphi OR Lazarus/FPC, like operator overloading and generics (improperly called class templates). Also the COM work is, for the moment, harder in Lazarus/FPC, although possible, as well as dynamic package loading.

Honestly, I wish it were different. Some components like GlScene I would love to have compatibility Delphi/Lazarus, but it seems so difficult.

IMHO, It would be a very good idea to have a tutorial, targeted to professional IT guys:
- on porting graphics,
- on porting interfaces to Office,
- on doing dynamic package loading,
- on porting DB-related code,
- etc.

I would be ready to help on the first point, as I'm doing the exercise right now for TDrawObject, as well as the second and third, also.

This is a very good initiative, by the way.

Good luck,
Thierry