The Information was gathered the hard way during my work on this.

You can encounter these pitfalls if you try to link a DLL compiled in FreePascal to application compiled in Delphi and exchange data between, or you can just flush a data structure to disc directly, and expect it to load in Delphi nicely...

Believe me, there's a fat chance it won't.

1). The dynamic array format (I didn't check, but it could relate to strings as well). As you know, in Delphi a dynamic array is in fact a pointer pointing to the actual data, with some additional info at negative offset (while an empty array is always just a nil pointer).

There is reference count (dword) at -8 and the array length(dword) at -4, (given in array elements, not in bytes).
Now a trap: in FPC it's almost the same, except it keeps the High() value at -4. I.e. length - 1. You try to pas an array.. and boom.

2). The set size. In Delphi sets take no more bytes than necessary, having length of (elements div 8 ) bytes. In FPC, sets have either 4 bytes in size (those with 32 elements or less) or 32 bytes, there are no other options.

3). The records size. Unless you use {$alignrecords XXX} directive or packed records, a record in FPC does always take 32 bytes as a minimum -- even if it consists of a single byte. Delphi arranges them differently.

4). The default field alignment in Delphi is 8 bytes (i.e. 64 bits). That is, it wastes half your memory if you use exclusively 32-bit fields in your classes. FPC employs some complex scheme I couldn't figure out (especially when you mix 32-bit and 64-bit fields), so I just forcibly set it to 4 in my system.

...Still feel brave enough to try and mix those two...?