[Lazarus] Beyond Compare 4 built with Lazarus 1.2

[Craig Peterson]

Hi All,

Yep, Beyond Compare 4 for OS X uses Lazarus with the Carbon backend.  Thank you to all of the hard working Lazarus and Free Pascal developers that helped make it possible.  

While I did mention some things in that post that I didn't like about Lazarus/Free Pascal, I think you've done excellent work.  I was really impressed with how much worked out of the box and how compatible everything was, both in the LCL and the compiler.  The Objective Pascal extensions are really well done.  Not having the IDE go brain dead while debugging was a welcome change too. :)

We actually got the core product up and running fairly quickly; the last two years have been spent making it more at home on OS X.  We've submitted most of our changes back to the team, and will get the remaining ones out soon.  Unfortunately a number of the enhancements, like per-window sheet support, rely on a lot of our application level behavior, so they can't be incorporated into the LCL easily, but I am happy to answer any questions or share the relevant code snippets for anyone who wants them.

We will definitely be looking into LCL/Qt for our Linux version once we get v4 released. Seeing the Qt5 bindings has made me very happy.

On Dec 25, 2013, at 11:51 AM, Marco van de Voort <marcov at stack.nl> wrote:

> On Tue, Dec 24, 2013 at 04:44:37PM +0000, Graeme Geldenhuys wrote:
> Which hopefully makes clear that Delphi compat unicode is needed by some :-)

As long as "string" supports Unicode, and AnsiString/UTF8String casts do appropriate conversions, I don't really care whether it's UTF-8 or UTF-16.  One of the things that made code sharing easier is that OS X and modern Linux both use UTF-8 for C strings, so we were able to use string/TStringList/etc on all three platforms, with all three compilers, and know that it was always Unicode.  AnsiString was used in places on Windows where we needed it, but that was about it.  There were cases where we had to use UTF-16 on OS X to minimize conversions during drawing, and there were cases on Windows where we had to use UTF-8 to reduce memory usage.

Delphi compatibility in general has been very important, though, and I appreciate all the efforts in that direction.  BC's source code needed it, of course, but we also rely on some large third party libraries, like Indy and SecureBlackBox, and have had to port several others ourselves (ZipForge, Abbrevia, chsdet, some bits of the JCL). I'm quite confident that if there had been a significantly higher barrier to bringing our code over we would have switched to a non-Pascal environment instead.

In any case, thanks again.  We really couldn't have done it without this community.

-- 
Craig Peterson
Scooter Software