10

I need to make my Delphi solutions available on Linux and I have tested them on both Wine and Lazarus. What are the technical considerations I should take into account (Programming, Deployment, Maintenance etc.) on the longer term in order to avoid landing in a maintenance nightmare. I keep my Windows components used pretty standard to avoid complexities that may develop on cross-platform. I am looking for some hard facts that should go beyond being subjective. I do not want to consider .Net/Mono because this will set me back immediately (Huge Delay to market) which I cannot afford.

I can think of some:

  1. Lazaraus may require some (changes) programming to make code work.
  2. Wine is a more difficult environment to maintain at a large base of customers.

You contribution on this would be greatly appreciated.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Johan Bresler
  • 6,450
  • 11
  • 56
  • 77

8 Answers8

18

I would say there is no golden rule there. It will really depend on how much of the components you use are supported with Lazarus.

I'd start testing with lazarus and keep Wine as a backup in case you get desperate.

The Codegear plans are still very vague (they are only "looking at it", but at the same time they smear the 64-bit rollout over two full versions, so even if this makes progress this could take quite a while)

The quick timeline makes me think that the Apple version will use QT, not native apis.

Update: nearly 4 years, and still no Linux support. Trees grow faster.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • 2
    Thanks for a voice of reason among the current starry-eyed believe that (one of) the next Delphi versions will allow to simply press a button and get all these wonderful Linux and Mac OS X applications. – mghie May 21 '09 at 08:19
  • Well, I don't want to be negative too, they at least have the Kylix codebase, and a revised (and hopefully portable) compiler as part of the 64-bits effort. FPC/Lazarus went multi platform and later -architecture via that same route too. However there is simply not enough meat to actually comment on. – Marco van de Voort May 21 '09 at 14:59
  • mghie: It turns out to be pressing the button AFTER rearchitecting to a different GUI library :-) – Marco van de Voort Sep 28 '11 at 14:51
16

I have to disagree with everyone else here and suggest that you use Wine. Google is shipping Picassa with a Wine install and you could do the same thing. Rather than relying on the version installed by the distro they have a copy in the program directory that's preconfigured and has a known version that you can test against.

Basically you just need to ask what a native port would provide that a Wine wrapper wouldn't. For most Delphi apps, the answer is probably themeing and very little else. We made a native port so we could access the filesystem at a lower level, but prior to that our product worked on Wine almost perfectly for years.

And speaking from experience, native ports aren't a walk in the park:

  • Any third-party components are probably not supported by Lazarus.
  • Unless you switch your Windows version to Lazarus too you'll need to maintain parallal .lfm files, and if you do switch you'll lose the Delphi IDE. As nice as Lazarus is, it's far behind the latest Delphis in polish and features.
  • Testing will require much more effort if you have a completely separate program with a different widget set. Testing on Wine would closer to testing your existing version on a new Windows version.
  • You won't be able to use any new features that the Delphi compiler introduces (generics, anonymous methods) until FPC has something equivalent.
  • Most 64-bit Linux installs do not include 32-bit versions of Gtk/Qt, and installing them can be complicated and error prone, so you'll need to compile 64-bit versions of your application too.
Zoë Peterson
  • 13,094
  • 2
  • 44
  • 64
  • Thanks for this - you certainly add food for thought. – Johan Bresler May 21 '09 at 13:20
  • 2
    I don't agree with the 3rd party components. Quite some of the core components ARE supported, like socket suites, ZeOS, VST, Comport, TeeChart and the list goes on. The second point I agree, at least the first part, the dual maintenance is a pain if you have a lot of GUI. (I switched most of my Lazarus projects to use Lazarus too on Windows, I had anyway because of win64) FPC released generics before D2009 did. But unfortunately CG implemented them incompatible The last point depends on how far you will go. Linux/PPC Sparc, ARM, Wince? First see if 64-bit Linux makes sense at this point. – Marco van de Voort May 21 '09 at 15:04
  • 4
    How many of the TMS and DevExpress components does it support? I must have also missed the Ribbon controls, imaging libraries, ZipForge/ziptv, VirtualShellTree, skinning/themeing, QuickReports, and more. Maybe the wiki is out of date... – Zoë Peterson May 21 '09 at 15:59
  • I don't know all of them, but that is not "probably", there are enough that are supported. Devart db stuff is another one I remember. – Marco van de Voort May 22 '09 at 07:04
  • 1
    I agree with Craig. The controls I care about for Delphi are not available for Lazarus. DevExpress is a *hugely* important add-on for Delphi (for me) that isn't available for Lazarus. That's a show-stopper for me right there. – Mick Jun 04 '09 at 20:03
  • Making a quick overview if your components are supported or not is a non-issue. I don't see a reason for a blanket negative advise. Kylix didn't support all components either. And neither does Prism – Marco van de Voort Jul 01 '09 at 08:00
  • 1
    Whether you like it or not, using anything besides Wine means missing out on lots of components and significantly more testing. That applies equally to Lazarus, Kylix, Prism, and Delphi 201x's cross platform work. I don't think a Linux port using Lazarus will give a better return on investment than Wine for most small devs selling existing Delphi apps. I do think an OS X port would have to be native to sell well, and I do think that if you have to have a native port FPC/Lazarus is the best option. If you disagree stop naysaying me and prove me wrong. – Zoë Peterson Jul 10 '09 at 13:43
  • It's a childish argument that I can't prove wrong as long as there is one unported component, so I won't bother. I hope the readers are smart enough to make up their own mind after this, and inventorize if the components that they actually need are ported. – Marco van de Voort Jul 14 '09 at 08:10
  • Certainly there are components supported for Delphi that are not Supported for Lazarus (and vice versa, btw!), however the importance of those varies from person to person. I had problems just upgrading between Delphi versions in old versions of Delphi because of overuse of 3rd party components. Then I switched to a core set that were better supported. Often times it's not worth the headache. Today I use only ZeosDB and Synapse TCP/IP, along with some TurboPower code occasionally. If you judicious in your use, Lazarus is just fine. That said, I now use only Lazarus even on Windows. – Noah Sep 03 '13 at 01:41
5

I would generally recommend using Lazarus. If you depend on WINE, you are also at the mercy of WINE bugs, which may affect your product quality. It may even be useful to use Lazarus + FPC on the Windows environment.

An alternative would be to use virtualisation but this depends on the type of application you are writing.

sybreon
  • 3,128
  • 18
  • 19
4

Looking at the plans of Codegear - search for some of the roadmap hints at DelphiLive 2009 - to provide native Delphi on Linux and Mac, I would for now go with Lazarus. You spare yourself of the Wine administration and later can port your app to native. (As somebody put it: Delphi will be like big zoo with penguins, tigers, leopards and snow leopards.)

Of course, porting will envolve quit some work. But if you have a careful look on issues like unicode and prevent doing the most common faults, it should be rather easy.

Search on delphifeeds for unicode and roadmap for further hints.

Ralph M. Rickenbach
  • 12,893
  • 5
  • 29
  • 49
3

I think either Wine or Lazarus would probably work for you. I've tested some of our quite large Delphi Apps (Many 3rd party controls) with wine, and they have worked pretty well. There were a few annoying font issues. The two thing that really failed majorly was where I used TWebBrowser (which looked like it almost worked, I think it was using the gecko rendering engine instead of IE). The other was a muli-tier (Datasnap) server, which ran but, I couldn't work out how to connect to.

I think holding out for Mac/Linux support for Delphi would be a mistake, the fact that they can compile a console "hello world" application for OS/X is impressive - but I think porting the VCL is a different story (unless you've written a console app).

If you already have a working application, then give wine a go - testing can't hurt.

The other thing to consider is who your users are (and how many)? If they are Linux geeks then they are going to have no problems configuring and tweaking wine (although they might find it offensive to use a native windows app). If it's a bunch of grandmothers then that's a different story.

Alister
  • 6,527
  • 4
  • 46
  • 70
  • The fact that they can compile "hello world" for Mac OS X isn't impressive, it's the bare minimum. I mean, we are speaking about a company which has been building x86 development tools for more than 20 years! (I guess they wouldn't target PPC, not much sense in doing that any more.) Otherwise your answer is good, +1. – mghie May 22 '09 at 22:19
  • ( OS X ABI is a bit funky, with alignment bytes, small records in registers stack alignment in every function etc. So it is not entirely trivial) – Marco van de Voort May 25 '09 at 14:49
  • @Marco: It may not be trivial, but there's tons of prior art to look at. They should know their stuff after all this time. And anyway, these days it will take much more than solving a "not entirely trivial" problem to convince people to pay for a development tool. – mghie May 25 '09 at 20:39
  • Oh, that is not the question. It should be a breeze for a company that can maintain a commercial C++ compiler. – Marco van de Voort Jun 01 '09 at 15:56
2

Free Pascal Compiler/Lazarus is not close to the latest Delphi features, but it is quite stable even though there are still bugs to find out.

Also, the executables produced seems larger, but it is definitely smaller than using a VM or deploying with Wine itself.

But it does something that Delphi/Kylix tried once. Cross build! By using it, you can compile from a platform to another.

Caglar Toklu
  • 576
  • 5
  • 11
1

Actually we use Wine for our ShareTeam product... We have an on-test version on Lazarus that is a good tool and have a lot of advantages but is not really complete at the moment. I think at the moment is better use wine if the work is not simple, converting a Delphi application to Lazarus/FreePascal is not simple. Personally i hope that Embarcadero make a cross-platform version of Delphi, not like Prism that have a lot of difference with Delphi.

  • I think the same components that are the problem with lazarus (like RTF,report packages, TWebBrowser (IE), XML (MSXML, but that is doable to emulate), ADO etc) will be a problem with multiplatform Delphi too. – Marco van de Voort Jul 13 '10 at 09:37
1

Firstly, you should try to make sure your GUI code and non-GUI back-end code are cleanly separated into the GUI app and libraries if they are not already. This makes for easier testing, and also easier implementation of command line interface, web interface, etc. These libraries (unit files with objects and procedures) should compile easily on FreePascal in most cases, however you should check and debug the non-GUI code first.

Once that's out of the way, it's time to take a look at your GUI. If you are using a lot of closed source 3rd party commercial components, then you may be out of luck with easily converting the GUI. If you are using mainly stock components and/or ones that have been ported to Lazarus, then you may indeed be able to convert the GUI and use it as-is.

Note that since Mac OS and Linux programs are often supposed to look different, you may want to consider that, depending on your application. Possible approaches include: 1. Use Lazarus even on Windows, and use the same GUI code for all platforms. 2. Use Lazarus only on OS X and Linux, and customize the GUI to be somewhat native looking after converting. 3. Code a native GUI for OS X (Using Cocoa and maybe XCode), and then link to your Pascal code for the non-GUI handling. This kind of thing is less necessary on Linux, but there you have a choice of toolkits for the LCL (VCL) back-end to make.

There are strong proponents of each approach, but which one is right depends on your "circumstances" and your goals.

If your main interest is OS X, consider joining the MacPascal list.

Wine is a huge overkill unless you need to get a Linux/OS X app out tomorrow with almost no modifications. (In that case, why not just use VMWare?)

Noah
  • 998
  • 1
  • 12
  • 22
  • Lazarus on Mac supports QT and Carbon. In the past even GTK (haven't tried that for years though). Cocoa is planned but progresses slowly. I assume it all depends on how eager you are to rearchitect your app, and what demands on GUI you have. – Marco van de Voort Apr 23 '14 at 11:54