What would be the best solution for my Delphi apps on Linux - Delphi+Wine or Lazarus?

Question

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.

Neutron

Answer 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?)

Sivas

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. – Topsyturvydom

Answer 2

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.

Topsyturvydom

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. – Enchiridion

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. – Topsyturvydom

mghie: It turns out to be pressing the button AFTER rearchitecting to a different GUI library :-) – Topsyturvydom

Answer 3

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.

Dentate

Thanks for this - you certainly add food for thought. – Neutron

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. – Topsyturvydom

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... – Buffy

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. – Topsyturvydom

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. – Kirstiekirstin

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 – Topsyturvydom

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. – Buffy

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. – Topsyturvydom

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. – Sivas

Answer 4

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.

Shanks

Thanks for your post. I am mindful that vitualisation will have undesirable performance implications and other technical complexities, probably worse than I amy encounter by using Wine. – Neutron

lazarus has many bugs and AV problems, but against wine ? i'd say 1+ for lazarus. – Pax

But for maintainability, virtualisation can help because everything is self contained within the virtual machine. – Shanks

For an enthusiast, sure. But he can also deal with Lazarus and Linux. An avg user doesn't know how to deal with VMs. – Topsyturvydom

What would one run on the VM - ReactOS? – Neutron

You can run Windows/ReactOS but you can also run Linux/WINE (but with a controlled and tested version). It's been my experience that different WINE versions sometimes have issues. – Shanks

I think reactos is more a work in progress than the Linux Lazarus port – Topsyturvydom

Answer 5

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.

Lentil

Answer 6

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.

Sympathy

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. – Enchiridion

( 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) – Topsyturvydom

@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. – Enchiridion

Oh, that is not the question. It should be a breeze for a company that can maintain a commercial C++ compiler. – Topsyturvydom

Answer 7

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.

Primo

Answer 8

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.

Salazar

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. – Topsyturvydom