New in version 2.6.2

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.

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).

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.

New in version 2.4.4 (June 1st, 2011)

This version contains most library fixes from early June 2010 through March 2011.

There are also some compiler fixes, most relating to 64-bit.

New in version 2.4.0 (January 7th, 2010)

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)