Home > Delphi, JavaScript, Linux, Object Pascal, Smart Mobile Studio > Moving to Linux, part 4

Moving to Linux, part 4

In this final installment of my Linux series we will be focusing more or the Linux side of things (with the exception of Wine Bottler for OS X), with pointers on how to write your own native Linux applications; and also (Unix wise) how to convert and publish your Win32 apps on the mac without a single line of code (!)  And yes, with no dependencies or virtualization involved.

You are probably expecting a long introduction to Lazarus, which I wont bother with since 90% of all Delphi developers knows perfectly well that Lazarus and FPC exist. So before we start talking about Lazarus and FPC, which I wont do in “presenting” fashion since we already covered that, I want to list a few alternatives which might suit you better.

New wine for aging bottles

In the old days Wine was “THE” magic app for Linux. In fact it was so successful –that more esoteric platforms such as the Amiga operative system – tried to adopt it. How that particular endeavour went I havent got the foggiest, I just remember reading that it was started on years ago.

Wine, a serious option for legacy win32 apps

Wine, a serious option for legacy win32 apps

If you don’t know what Wine is, here is a short low-down of the product:

In short, Wine is a re-implementation of key Windows modules. So it’s not an emulator, but rather a kind of portable variation of Windows’s sub-systems and core, created by open-source enthusiasts. It is also a system of mapping, in real-time, Windows OS calls into their linux POSIX equivalents. While this probably sound like a dodgy option for getting your Software to run on Linux without a massive re-write, I may remind you that Borland shipped Kylix running solely on Wine. Wine also runs Microsoft Office, Internet Explorer and a wast array of other titles flawlessly. So it should be considered a stable and viable option for getting Win32 apps onto the Linux/Gnu desktop

To sum up, unless your application hits the hardware directly (or indirectly, since Windows sandbox you with drivers. As it should), or uses one of the rare modules of Windows which is not handled by the mapping process — odds are you can “wrap” your executable(s) and start selling for Linux without any significant alteration.


This is a commercial product, but essentially it’s a fork of the Wine codebase. Produced and maintained by CodeWeavers, it features an easier path and less fiddling than the original Wine distro. But ultimately — it’s another incarnation of Wine.

Wine Bottler (the best option)

This is a god-sent package for Mac users. And you will probably feel bad for not knowing about this before now. Imagine the following: You have a fully working, well written Delphi Win32 application written using VCL. But, the idea of porting it from VCL to FMX, or from VCL to Freepascal/Lazarus will be to time-consuming and not economically viable.

Wine Bottler, the absolute dogs bollocks

Wine Bottler, the absolute dogs bollocks

How do you solve this? Well, chances are that you wont. You will stick to selling your software on the Windows platform. But this is where Wine Bottler comes to the rescue, because unlike Wine — the bottler is an application for completely wrapping your application with Wine, turning it into a self-sustained, no dependency OS X bundle (!)

So, if you have a piece of software you want to launch for OS X, but you don’t have time or money to re-write using FireMonkey, then you can use Wine Bottler to do the job for you. It takes you application(s) and turns it into a fully valid and working executable for OS X.

I sure wish I knew about that earlier.. would have saved me a lot of work.

As the docs says:

Double-click your .exe or .msi and convert it into an app with WineBottler. You can run the generated app like every other program on your Mac. For advanced users, WineBottler gives you a selection of options: install special dependencies and even turn your .exe into a self-contained app – that is an app, that contains everything to run it… even on other Macs. Porting to OS X never was easier ;). Find out more – have a look at the Documentation.

The big choice, FPC or Delphi

Opensource inside

Opensource inside

Lazarus is not for everyone. You either love it or hate it, but you have to agree that it’s one hell of a project. And you may not be aware that freepascal was actually used by Embarcadero in order to deliver iOS support for Delphi. This was prior to the completion of their own compiler. I feel a bit sad for freepascal in this regard, that Embarcadero just waltzed in and grabbed what they needed (and I wonder if they ever donated a penny to the freepascal project). It borders on what should be allowed to do with an open-source project. But one thing is clear: freepascal is of high quality and it produces high quality code. The question really is how dependent you are on third-party components and if they have FPC/Lazarus support.

Another factor that you should consider, although not without attaining your own subjective experience (read: try it!), is the quality of Lazarus and freepascal on the Linux/Gnu platform – compared to the quality of the same under OS X. Lazarus on OS X has begun to mature over the past 2 years, but I found it to be a mess at first. Always some strange exception, missing file or mysterious crash. Thankfully that was years ago — and today it’s a different story all together.

On Linux especially, Lazarus is a completely different product. I have so far only experienced a single bug (and lord knows Delphi goes down like the titanic from time to time). The overall experience is quite polished and — well, it’s just a completely different ballgame compared to OS X. The Windows version of Lazarus has always been very good, but the Linux version quite literally outshines them all.

What direction to take?

When faced with a complete re-write of a major project, you have to weigh the pros and cons carefully. If you chose to stick with Delphi that would mean re-authoring from VCL to FMX. This can either be simple, depending on how cleverly you wrote the original code, or a total mess. In my experience, “living” products tend to grow in complexity and spaghetti-factor when faced with a deadline, so how hard it will be to get your legacy win32 VCL app spinning on OS X and iOS is difficult to estimate. For Linux however, you dont have an option except either a Wine wrapper or a FPC/Lazarus re-write.

In this regard an FPC/Lazarus port is probably much faster. First of all the FPC RTL is identical to Delphi and VCL (it is actually a fork of Kylix, which was the open-source portable VCL); Secondly the UI toolkit is likewise more or less identical to the VCL (with some minor differences).

Large Delphi programs can quickly turn into a mess if you dont architect them properly

Large Delphi programs can quickly turn into a mess if you dont architect them properly

But, we must also remember that Delphi is slowly moving towards coverage of all three major platforms, with only Linux missing from its impressive repertoire of technology. So you may wonder why you should choose between the Delphi path and the FPC/Lazarus path. It’s not a question of the past. Rather it has to do with where object pascal will be in 10 years.

Note: Remember how we trusted Borland, only to find ourselves in a 8 year long struggle, which nearly drove Delphi as a platform into extinction.

Well, I can’t tell you to migrate all your business to FPC/Lazarus. I would suggest you regard FPC/Delphi as two distinctly separate tools in your toolbox, with one substantial benefit: they both cover object pascal with miniscule differences in dialect.

The only real difference and potential deal-breaker, is of course that of generics. Which sadly differs vastly between compilers. But rumours have it FPC will add support for Delphi style generics syntax quite soon, once again restoring balance to the force.

Here are the pros for adopting Lazarus (IMHO):

  • Wast range of platforms supported
  • Your binaries require little in terms of installation (unlike C/C++)
  • Write servers, libraries and leverage Linux as a cost-effective solution for your customers
  • Free ! — A direct economic saving of $3000 straight our of the box compared to Delphi
  • FPC can be used as part of your product, Delphi cannot
  • Truly platform independent!

And here are the pros for sticking with Delphi:

  • Delphi offers a larger codebase compared to FPC/Lazarus
  • Delphi has the support of commercial component companies
  • Delphi is backed financially by Embarcadero
  • Delphi has the latest advancements, like GPU rendering under FMX
  • Delphi has a more modern IDE which we are acustomed to
  • With iOS, Android and “wearbles” Delphi has a leg up on FPC/Lazarus

I should perhaps mention the obvious. Namely that you can use FPC/Lazarus to get your VCL legacy code onto OS X and Linux, but for that purpose only. New projects and solutions might be better served by being written in FMX.

A word of warning: Delphi was near extinction only a handful of years back. Borland was forced by Microsoft to drop their competition, resulting in the spoils of war going to Microsoft (in this case Anders Hejlsberg playing the part of Bill Gates’s trophy wife). Embarcadero took over but did very little for Delphi during those years. Which is why Smart Mobile Studio came into existence. My point being: While Delphi has gone through the proverbial sinus-curve of popularity and decline, freepascal and Lazarus has remained largely unaffected by this. Which is truly worth considering if you have projects expected to be active for at least 10 years.

Moving to the cloud



Another interesting option, although perhaps beyond the majority of single person companies, is that of full cloud virtualization. This solves the problem of legacy (older code) and uproots the choice of platform once and for all. If you read my previous post on virtualization, then you know that cloud based computing includes the ability to upload entire VMWare images to be executed in the cloud. This means that native server software once again becomes important since it, in most cases, provides a significant speed boost over scripts and PCode runtimes. And it is of no consequence what language or compiler you use to deliver the goods – as long as they deliver.

Here is an example of a “typical” setup which covers both web, mobile and native:

VMWare Image #1

  • Port: 8040
  • Firebird database
  • Authorized access from IP of VMWare #2 only
  • Ubuntu

VMWare image #2

  • Port: 8090
  • morMot RPC (remote procedure call) service
  • Soap and JSON endpoints
  • Ubuntu

VMWare image #3

  • Port: 80
  • Apache HTTP server
  • Smart Mobile Studio driven website
  • Ubuntu

Image #1, your data store

The first image would house the database and storage facilities of your business. In our case we could use the freeFirebird database (pick the database of your choice here. MySQL is another great open-source alternative). Since we don’t want hackers to have a field-day with our investment, access to the database should strictly go through the RPC layer. This reserves for us an opening for a load-balancer should our business suddenly sky-rocket.

Image #2,RPC server

Where server #1 deals with data and storage exclusively, this VMWare image deals with access to that data and basically provides a fail-safe abstraction layer. the fail-safe being: login sequence, session management, data injection hack protection, data extraction protection (only valid sessions and users) and other “standard” methods of security.

By carefully crafting an API with SOAP and JSON endpoints, we cater for both native clients designed for the desktop – and HTML5 apps written in Smart Pascal — all from a single, unified API. I have proposed mORMot since that has excellent Smart Mobile Support. But Smart Mobile Studio ships with built-in support for Remobjects SDK. You pick the package that suits you.

Image #3, your HTTP access point

The last image represents the public “face” for your virtual enterprise. It has several key benefits, first and foremost that it will host the HTML5 version of your software (written in Smart Mobile Studio). Secondly, you have enough leverage for a RPC dispatcher — meaning that you can keep the RPC service private, using Apache as a gateway to the service in instance #2.

And last but not least, the above setup will not just cover HTML5, it will also cover native development. You can sit down and write the Windows and OS X native clients in Delphi with Firemonkey — and under Linux you make use of FPC/Lazarus. All clients would access the service the same way, and have identical features. So just like Dropbox your users can use either a native client app, or simply log-on through HTML5 and a standard browser.

Writing platform independent services with FPC

Note: Under Unix and Linux, a background service is called a “daemon”. The name stems from ancient greek religion, where all men were believed to have a personal daemon (helper, what in modern religion would be a guardian angel). Plato was said to have a daemon from the gates of hades. The ancients did not divide reality into good or evil, that came later with Christianity and Islam.

A fine paper on writing cross-platform services with FPC can be found here:

And as always, google is your friend. Should you need help I suggest you register on the FPC/Lazarus forums and ask. You will probably find that your questions have been answered before.

The mORMot framework can be found at Synopse, the company behind it (open source):

And lastly, the free and open-source database access framework Zeos can be found here:

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: