views:

1011

answers:

8

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.

+4  A: 

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
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.
mm2010
lazarus has many bugs and AV problems, but against wine ? i'd say 1+ for lazarus.
avar
But for maintainability, virtualisation can help because everything is self contained within the virtual machine.
sybreon
For an enthusiast, sure. But he can also deal with Lazarus and Linux.An avg user doesn't know how to deal with VMs.
Marco van de Voort
That's what I recommended.
sybreon
What would one run on the VM - ReactOS?
mm2010
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.
sybreon
I think reactos is more a work in progress than the Linux Lazarus port
Marco van de Voort
+4  A: 

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 Rickenbach
+8  A: 

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.

Marco van de Voort
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
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
+12  A: 

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.
Craig Peterson
Thanks for this - you certainly add food for thought.
mm2010
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 incompatibleThe 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
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...
Craig Peterson
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
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
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
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.
Craig Peterson
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
+3  A: 

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
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
( 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
@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
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
+2  A: 

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
+2  A: 

Did you take a look at VGScene?

Stephan Eggermont
+1  A: 

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.

Ivan Revelli
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