Free Pascal Compiler

Free Pascal Compiler (aka FPK Pascal) is an open source Pascal compiler that supports the following operating systems: Linux, FreeBSD, NetBSD, MacOSX/Darwin, MacOS classic, DOS, Win32, OS/2, BeOS, SunOS (Solaris), QNX and Classic Amiga.

Free Pascal Compiler is available for different processors Intel x86, Amd64/x86 64, PowerPC, PowerPC64, Sparc and ARM.

Free Pascal Compiler features a very clean language, it uses no Makefiles unlike most programming languages, it is Fast with a big F, each unit has its own identifiers, and includes an IDE (Integrated Development Environment).

Moreover, the software features great integration with assemblers, object-oriented programming, smartlinking, distribution independence, and it is compatible with existing code.

What is new in this release:

• This version is a point update to 3.0 and contains bugfixes and updates packages, some of which are high priority.

What is new in version :

• Language changes:
• Anonymous inherited calls:
• Old behaviour: An anonymous inherited call could call through to any method in a parent class that accepted arguments compatible to the parameters of the current method.
• New behaviour: An anonymous inherited call is guaranteed to always call through to the method in a parent class that was overridden by the current one.
• Example: See http://svn.freepascal.org/svn/fpc/trunk/tests/tbs/tb0577.pp. In previous FPC versions, the inherited call in tc3.test would call through to tc2.test(b: byte; l: longint = 1234);. Now it calls through to tc.test.
• Reason: Conform to the FPC documentation, Delphi-compatibility.
• Remedy: If you wish the compiler to decide which method to call based on the specified parameters, use a fully specified inherited call expression such as inherited test(b).
• Overload modifier must be present in the interface:
• Old behaviour: It was possible to declare a function/procedure/method as overload only in the implementation.
• New behaviour: If an overload directive is used, it must also appear in the interface.
• Reason: The old mechanism could cause hard to find problems (depending on whether or not the implementation was already parsed, the compiler would treat the routine as if it were declared with/without overload), it could cause unwanted unit recompilations due to interface crc changes, and Delphi compatibility.
• Remedy: Make sure that the overload modifier is present both in the interface and in the implementation if you use it.
• Unit changes:
• Several methods of TDataset changes signature (TRecordBuffer):
• Old behaviour: Several (virtual) methods of TDataset have parameters of type "pchar", which are often called "buffer".
• New behaviour: The pchar type has been changed to TRecordBuffer. Currently this type is still an alias for p(ansi)char, but in time it will be changed to pbyte for the 2.7.1/2.8.0 branch, which is D2009+ compatible.
• Reason: Preparation for Delphi 2009+ compatibility and improving of general typing. In Delphi 2009+ (and fully compatible FPC modes in the future) pchar is not pointer to byte anymore. This change will be merged back to 2.6(.2), but with TRecordBuffer=pchar.
• Remedy: Change the relevant virtual methods to use TRecordBuffer for buffer parameters. Define TRecordBuffer=pansichar to keep older Delphis and FPCs working. In places where a buffer is typecasted, don't use pchar but the symbol TRecordbuffer.
• DLLParam changed from Longint into PtrInt:
• Old behaviour: DLLParam was of type Longint even on Win64.
• New behaviour: DLLParam is now of type PtrInt so also on 64 Bit systems.
• Reason: Prevent data loss, match the declaration in the Windows headers.
• Remedy: Change the declaration of the procedures used as dll hook to take a PtrInt parameter instead of Longint.
• Some symbols in unit Unix and Unixutils have been deprecated:
• Old behaviour: No deprecated warning for unixutils.getfs (several variants), unix.fpsystem(shortstring version only), Unix.MS_ constants and unix.tpipe. unix.statfs
• New behaviour: The compiler will emit a deprecated warning for these symbols. In future versions these may be removed.
• Reason: getfs has been replaced by a wholly cross-platform function sysutils.getfilehandle long ago. fpsystem(shortstring) was a leftover of the 1.0.x->2.0.x migration (the ansistring version remains supported), the MS_ constants are for an msync call that is not supported by FPC, and thus have been unused and unchecked for over a decade and might date to kernel 1.x times, tpipe was the 1.0.x alias of baseunix.TFildes, the unit where the (fp)pipe was moved to in during 2.0 series. Unix.statfs is an overloaded version that wasn't properly renamed to fp* prefix when the others were renamed in 2.4.0
• Remedy: Use the new variants(sysutils.getfilehandle,fpsystem(ansistring),baseunix.tfildes). In the case of the MS_ constants, obtain current values for the constants from the same place where you got the code that uses them.
• TStrings.DelimitedText behavior changed (unit Classes):
• Old behaviour: If StrictDelim is true, TStrings.DelimitedText did not completely follow the SDF format specification (which is defined in Delphi help) at least in case of spaces (and presumably other low ASCII characters) in front and at the end of fields as well as quotes and line endings. Worse, if StrictDelimiter is true, and in the cases mentioned above, saving a TString .DelimitedText and loading that text in another TString lead to differences between the two. Note: StrictDelimiter is false by default.
• New behaviour: FPC follows Delphi behaviour.
• Reason: Consistency (writing out and reading in DelimitedText should result in the same strings), Delphi compatibility (following the SDF specification).
• Remedy: Review your existing code that reads or write DelimitedText; if necessary convert data or write converter code. See tests\webtbs\tw19610.pp for a detailed test.
• fcl-image TTiffIDF renamed to TTiffIFD:
• Old behaviour: The tiff helper class for the "image file directory" was misspelled TiffIDF (tiffcmn unit)
• New behaviour: Now renamed to TTiffIFD
• Reason: Consistency, low usage
• Remedy: Rename identifier as appropriate.
• unit libc issues a deprecated warning:
• Old behaviour: While deprecated for years the libc unit didn't issue a deprecated warning
• New behaviour: A deprecated warning is shown when unit libc is used, urging your to update.
• Reason: unit libc is a Kylix legacy unit, with limited portability
• Remedy: Use proper FPC units as described in libc unit
• Other:
• UPX support has been removed:
• Old behaviour: There was some leftover UPX (an executable packer) support in the FPC Makefiles, and DOS and Windows FPC releases included an UPX binary.
• New behaviour: All removed.
• Reason: Release binaries haven't been UPX'ed for a while. The size of the FPC executables is generally insignificant these days compared to the total installation size, and using UPX occasionally causes some minor annoyances (false positives from virus scanners, worse paging behaviour by the OS, incompatibilities with certain executable sections, ...)
• Remedy: Download and install UPX yourself from its homepage and in general reevaluate the need for it.

What is new in version 2.4.4:

• This version contains most library fixes from early June 2010 through March 2011.
• There are also some compiler fixes, most relating to 64-bit.

What is new in version 2.4.0:

• Delphi like resources for all platforms,
• Dwarf debug information improvements,
• Several new targets
• 64-bit Mac OS X (x86_64/ppc64)
• iPhone (Mac OS X/Arm)
• Haiku (from the BeOS family)
• Improved ARM EABI support
• Whole program optimization
• Many compiler bugfixes and half an year of library updates (since 2.2.4)

What is new in version 2.2.4:

• All:
• Experimental packages-installation tool
• Packages:
• Added support for TIFF reading/writing in fcl-image
• Improvements and fixes in CHM support
• Fixed linking the gtk2-package with gtk versions above 2.13.4
• IDE:
• Added support for CHM help files