units translation

[bnilsson]

Hi!

I consider porting a Delphi program from Windows platform that is using the following:

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Buttons, Dialogs, StdCtrls, jpeg, ExtCtrls, uElMath;

to Linux.
Is it at all possible without rewriting all code?
"Windows" I understand should be replaced by "Linux", but what about the rest? Are any "synonyms" that can be used to replace the existing units?

BN

[marcov]

Windows and messages are Windows only. In both cases what to replace it depends on what you use from it.  Just leave them out and see what you miss.

Some very general types are in "types" and system.uitypes (the latter in the upcoming FPC 3.2+).  These also exist in Delphi. (types since D7, System.UITypes since DXE2 I think).

E.g. for LCL internal messages afaik you can substitute with LCLMessages.

I think jpeg is not needed, and uElMath is afaik a 3rd party unit?  The rest is probably fairly ok.

[bnilsson]

In Lazarus, is the .dproj project file of any use?
 

[marcov]

In Lazarus, is the .dproj project file of any use?

Other than to open in notepad and guestimate what to enter in Lazarus configuration: no.

[bnilsson]

Ok, in Lazarus I got as far as getting an error:
{$ERROR only cpu i386 is supported}
I am sitting on MacOSX Mojave, for my convenience.
Is this the time I must proceed to Linux, as in my original plan?

[marcov]

Ok, in Lazarus I got as far as getting an error:
{$ERROR only cpu i386 is supported}
I am sitting on MacOSX Mojave, for my convenience.
Is this the time I must proceed to Linux, as in my original plan?

Best would be to first port to 64-bit under Windows, and only then go to other targets. Doing two things at the time (architecture AND OS) complicates the matter.

If your Delphi application contains older Delphi (D7 time) units with a lot of 32-bit assembler, that is a problem for going to 64-bit.

[wp]

These are my steps which I usually do to convert various demo projects and packages of the JVCL library:

• Copy the project to a separate location
• I normally do not use the Delphi-to-Lazarus converter because I'd like to have more control an what is happening. Of course, you can try it first, maybe you are lucky and the converter can sort out everything correctly.
• In order to make the program compile in Lazarus I rename the .dfm files to .lfm and change the {$R *.dfm} of the pas files to {$R *.lfm}. I rename the .dpr file to lpr, open it in an external editor and add "Interfaces" as first unit. Now I load the lpr file into Lazarus. Since there is no lpi file yet, Lazarus asks about the type of project to be created - normally "Application". Now I add the main form to the project (use Project Options), then the other units. It's good to load the original project (from its original folder) into Delphi to see what is missing.
• It is a good idea to activate {$Mode Delphi} in every unit or as default. This will save some work. Later I switch to {$Mode objfpc} which is my favorite because it is stricter. This requires using @ when procedure variables of events are assigned. And quite often there are parameters which have the same name as some already-existing property - I try to preceed procedure arguments consistently with an "A" (i.e. "ALeft" instead of "Left") to identify the argument and to avoid the duplication.
• Try to compile with Lazarus without changes in the units, first. The compiler will tell where something is missing. The only thing which has to be changed at this step is to remove the namespaces from the units in newer Delphi version, i.e. change "System.SysUtils" to "SysUtils" only).
• It's hard to tell how to continue here in general. In the case of a missing unit try to find out whether the "missing piece" exists in a different Lazarus unit. In case of a missing routine, maybe there is a similar one in Lazarus. etc.
• Once the project compiles, I remove the windows and messages units; somethimes there is also shellapi and others. Since Delphi adds Windows and Messages almost always to every new unit there are many cases where they can be removed without negative effect. When the project does not compile any more I add LCLIntf first - it contains most of the Windows-code in a cross-platform way. Sometimes I also have to add LCLType, LCLProc and/or LMessages. Again, think about replacements: a famous example is "ShellExecute" which often can be replaced by "RunCommand". In case of messages, e.g. WM_SIZE, replace the WM by LM (e.g. LM_SIZE), the message type also gets an L instead of the W. Be aware that when you meet messages the project may become very difficult or uncovertable.
• If the program compiles it is cross-platform now (in most cases). Test it carefully under all platforms. And fix very subtle issues -- sometimes this is the more difficult step.
• If it does not compile it is time to think about giving up or rewriting the broken parts - Of course, giving up for a demo program is something else than giving up for an important application...