Delphi Programming

Free Pascal is a 32/64 bit Open Source Pascal compiler that implements the Turbo Pascal and Object Pascal (as found in Delphi) dialects. In general the compiler can be seen as a portable Delphi compiler. It has the potential to take Delphi code where Delphi itself can't go.

Language support[]

Free Pascal's support for the Turbo Pascal and Delphi is quite complete up to version D7. The Turbo Pascal compatibility is pretty much as far as it can go on a 32/64-bit platform, without turning it into an emulator, and is slightly better than Delphi's.

The Delphi compatibility is slowly getting complete in the language department, but packages are missing. COM support (dispid and friends) were also missing, but have been implemented into 2.3. At the moment of writing, it is not clear if this will be merged back to the 2.2 series that is going to be released summer 2007. Some internals are also different (like RTTI format, but unit typinfo is afaik 100% compat)

A mode which implements the most important Mac Pascal (CW Pascal) constructs implemented also exists. This mode can also be used to port ISO pascal code, since it implements several ISO constructs that TP/Delphi don't have, including pre Delphi Object Pascal support. (e.g. all methods are automatically virtual)

A compiler dialect mode is a per unit decision, so multiple modes can be used in the same program.

Besides these compability modes, FPC also has 2 own modes, FPC and OBJFPC (Object FPC). Both are more or less a cleaned up version of resp the TP and Delphi modes with some extensions

Currently, libraries are a bigger barrier to porting than the language.

Target support[]

The compiler supports the i386,Power(PC),Sparc,Arm9 architectures including the resp. 64-bit incarnations. The core (Tier 1) OS support is Windows (32/64/CE), Linux, FreeBSD (x86 only) and Mac OS X. The Netware (classic and libc) and OS/2 ports are also in the regular release cycle.

Some notes about targets:

  • WinCE is the family of mobile Windows versions. This includes Windows Mobile 5.0 and PocketPC 2003, on ARM. Support of Windows Mobile 5.0 on i386 is under investigation.
  • Win32/64 are the windows 9x (95/98/ME) and Windows NT (NT4/2k/XP/Vista) versions of Windows on x86 and x86_64/AMD64. Windows on Power(PC) is not support (there are NT4 and 2k versions afaik)
  • For Linux, some provisions in the RTL exist to compile with embedded libc's like uclibc. This is considered an advanced topic though.
  • The FreeBSD x86_64 port was pretty far, but stalled because the porter wasn't able to get FreeBSD to execute the generated binary, and the OS didn't provide too many clues.
  • The Mac OS X port works on both ppc and x86, the earlier mentioned 2.2 version will have an out of the box universal binary support on x86. Since the PPC version can't crosscompile to i386, universal binary support built on PPC is not likely to arrive short term. (the problem is missing softfloat support to handle "extended" datatype for literals inside the compiler on ppc)

The list of targets constantly changes, specially in the minor platforms departments. If you have questions, don't hesitate to ask on a Free Pascal list.


The base libraries are a mix of TP and Delphi (e.g. both unit Dos and Sysutils), as well as some own additional units and classes. The FPC specific parts usually abstract certain OS features in a platform independant manner. (like e.g. unit sockets, and the textmode console units Video,Keyboard and Mouse). Besides the base libraries, the default FPC installation contains a large set of headers, including Mac OS X headers, the Jedi Windows (APILIB) and SDL (Jedi-SDL) headers (see also licensing) as well as basic headers for most RDBMS systems. A database abstraction layer for SQL databases called "sqldb" is included, as well as TDBF for legacy dbf support. Many other 3rd party database systems (TIOPF, UIB,

Units that implement the Visual parts of FPC are in the Lazarus project. Since Lazarus is slowly maturing, installers that install FPC and Lazarus in an integrated manner are becoming more and more the rule.

In general the base units are fairly Delphi compatible, but a lot of the higher level frameworks (like DataSnap) miss completely, and the base DB routines and components are less complete and different (though evoluating quite fast). When using a 3rd party component for DB interface, check if it has been ported, a lot of them are.


licensing relating to usage[]

Free Pascal licensing is pretty liberal, including some additional clauses to avoid some people's fear of LGPL/GPL licensing (though often unfounded in practice).

The base licensing principle is that usage of FPC and its libraries should be possible in a normal responsible way. This means that anything that is linked into end users prograss should be usable in commercial programs. This is realised by choosing for the LGPL license, with additional clauses that remove any doubt or double interpretations. This combined license (LGPL formal text + additional FPC disambigiuation) is commonly refered to as "FPC modified LGPL". Here is the core additional clause:

As a special exception, the copyright holders of this library 
give you permission to link this library with independent 
modules to produce an executable, regardless of the license terms of these independent modules, [..]

This clause is mainly meant to avoid (maybe even justified) uncertainties about the "shared linking" only clauses in the LGPL.

GNU refers to such a modified LGPL as "GPL with linking exception"

licensing relating FPC (the compiler/IDE/Lazarus program) itself[]

The end binaries are mostly GPL. However products made by GPL are not subject to the GPL, so this only applies if you modify or integrate (by static linking) the compiler itself. Since there are many misconceptions about the actual meaning of GPL, in case of doubt ASK! Since FPC is often used as backend compiler in educational programming projects I'll try to debunk some of the more popular myths that apply to that environment:

  • If I distribute FPC with my application for internal scripting, I must also package the source. (a link to the FPC site in some copyright addendum is enough)
  • If I modify FPC and distribute it with my application (but am not linked to it), I must open source my application. (Only if you link your application to GPLed code. If you package it, modifications (or bettter the modified source) on your site or distribution media is enough)
  • If I link to GPL code, I must open my own sources. (yes, but only when you distribute them. See Lazarus licensing section)

So in short the GPL only applies if you try to integrate a core FPC end-binary into your application. Not if you merely call it. There is one unpleasant side detail though, see the lazarus licensing section.

The MPL problem[]

According to GNU, the MPL is GPL incompatible on hard to explain technicalities. (which to be honest I don't understand myself either). If this is true or not doesn't matter, the uncertainty alone makes the MPL-GPL combination annoying.

This is a big problem for the FPC project since it uses several endbinaries that are GPL, while the majority of the open source components in the Delphi world are MPL. Relicensing on the FPC side is hard, since the project is over 14 years old, and has numerous contributors. Fortunately there is an escape in some cases, the MPL provides a clause to duallicense LGPL-MPL. However this clause must be explicitely invoked in the license statement, which is effectively a relicensing (even though it is more a technicality to satisfy GNU than a massive licensing change. The MPL-LGPL differences are more a difference in viewpoint and wording, resp open source ideological(GNU) and corporate legalese(MPL) in than in content). But for any relicense, even if in practice a technicality, you must obtain consent from all major contributors.

If your MPL project still is in touch with all its contributors, you could ask their permission to relicense under the MPL dual license. In the past Jedi APILib, Math and SDL did this. (and are now part of the FPC distribution). The Jedi JCL had discussions about it (and had the choice, since they had a pretty tight core of contriburors), but I can't remember the exact end-outcome. Another major component that did this is VirtualStringTree from Mike Lischke.

Licensing relating to Lazarus and the MPL problem[]

Licensing of Lazarus is pretty much the same as with FPC itself. The libraries are modified LGPL, the environment itself is GPL. However designtime libraries link into Lazarus, making them subject to the GPL. The Lazarus teams defuses this situation by pointing at a fair use property of the GPL. This property of the GPL is that it doesn't come into effect until you distribute the result. However the result/product in the GPL license sense is the Lazarus binary with plugged-in components itself, not the application binary created with it. The application binary itself is only limited by the components you actually link to, and in the FPC/Lazarus project those are all LGPL.

So though potentially confusing this licensing is not a problem when crafting binaries with Lazarus, even if you have commercial components with designtime parts. This because you only have to open the source when you distribute the result (iow lazarus with preinstalled components).

However there is one sideeffect to this. If you distribute a Lazarus with components pre installed, they must be GPL compatible. IOW it makes it impossible for e.g. componentvendors to provide a lazarus with components installed, or create a Lazarus distro with the MPL-only Jedi components preinstalled.

External Links[]