[Estimated Reading Time: < 1 minute]

As some people may have already noticed, Lazarus went “1.0” yesterday. The sensitivity – and some might say serendipity – of the timing of this can hardly have escaped many people, including myself.

Since I now intend taking a far greater interest in the alternatives to Delphi for those of us that enjoy the Pascal language, it also seemed appropriate to make some changes on my blog too. This is also reflected in some of the plans I have in mind for releasing some of my code, necessitating some further delays unfortunately, though hopefully not too significant.

Compatibility with FPC will now be something I shall now be looking at as a matter of priority. I am anticipating few difficulties on this score but only ever having very tentatively dipped my toes in the FPC/Lazarus worlds before, there will be some unavoidable ramp-up time.

Here’s looking to some brighter – and wider – horizons.

57 thoughts on “Lazarus Goes 1.0”

      1. Pastics!!

        ROFL

        No really you should, just for a day 😀

        Uli, I didn’t think anyone could top todays news of the XE3 Pro EULA decision reversal but I just can’t stop laughing at that. Thank you 🙂

        1. Oh well, never let it be said that I don’t listen to my readers. 🙂

          For 24 hours only (and I can’t change the domain name itself so that will just have to be accepted as “beyond scope”). 🙂

  3. My bread and butter project (300kloc) compiles and runs fine with XE2 and Lazarus 1.0. Only 10 or 20 Windows/OSX ifdefs.

  4. Be it few years ago when i was hardcore Delphi 5 users not spolied by XE2 extra’s.

    Well, let’s hope in couple of years FPC would catch up Delphi syntax compatibility 🙂

    1. The 2.7.1 development branch goes a long long way….
      And the 64bit compiler for windows is superior….to Delphi… try it (size, speed).

      I am using it in production – in big $ projects -, but I do not do much in visual appearance

  5. “Compatibility with FPC will now be something I shall now be looking at as a matter of priority”
    Excellent. Looking forward for your shared observations.

    “My bread and butter project (300kloc) compiles and runs fine with XE2 and Lazarus 1.0. Only 10 or 20 Windows/OSX ifdefs.”

    Dying to see screenshot of it. Please send to gaddlord@mtgstudio.com

  6. Maybe known to most here but very likely not by too many in the whole world … The CodeTyphon evolved. I have been surprised about the steady evolution and the continuous improvements. Pilotlogic integrates the components, does offer a MultiOS Installer and offers examples too. They do a lot more … They are very nice and make our life a lot easier. Wanted to say. Thank you.

    http://anyduck.blogspot.co.at/2012/08/opensoucre-and-pascal.html or direct link http://www.pilotlogic.com/sitejoom/

    Everyone can have a quick overview. They are doing a great job as well as the Freepascal and Lazarus people themselves.

      2. No they mean typhon: http://en.wikipedia.org/wiki/Typhon

        I really want to like Lazarus, but it’s still not ready for real usage (for example DB support is still not that good). Considering how much they have improved, I hope that someday in the near future they will be a real alternative to delphi.

        1. I am a newbie looking at both Delphi and Lazarus. Could you please expand on the comment that the Lazarus database support is not as good as Delphi’s? Does this hold true even if using the open source ZeosLib database components?

          Thanks.

          1. I must admit, I was wondering the same thing. I haven’t used Delphi’s “native” database capabilities since, oh, about Delphi 1 (I never bought in to “Data Aware Controls” and didn’t see the sense in tying myself to a proprietary DB access framework when the platform my apps were running on already had one – first ODBC then ADO).

            One of the things I shall be checking is that my ADO wrappers still work on FPC. I am expecting they will.

          2. In worst case you will have to invest a few hundred bugs into UNIDAC or AnyDAC, both support Freepascal already, since it is a requirement today. Without FPC support many companies don’t take the libraries. That has been surprising to me first but reality. From this I have drawn the conclusion too, that EMBs offerings for team developments are not this perfect match.

            Since 0.9.26 – 0.9.28 the out of the box DB access has improved dramatically and since it is provided by motivated people from a company in Germany, afik, I think those will take the DB support for their developments to. What does count in practice still, wire protocols. Neither Delphi nor FPC/Laz do provide this out of the box.

            Honestly don’t compare FPC vs. Delphi. Comparisons don’t make sense. They are here to divide people – politics. We all do develop in the ‘Pascal’ World. Anything else does not matter. Don’t waste your time with things that don’t work.

            In general you should be in the position to ‘repair’ whatever you use. I think Code Typhon is still a very comfortable way to get to know FPC/Laz.

            There are companies that use Datasnap together with EHLib + datasnap + AnyDAC, others like devart + devexpress, I combine XFiles with Raize in the Labs currently … others like TMS… 99% use Java and .net.

            Before you switch to all this … check what comes one board in every case.
            http://www.codeproject.com/Articles/199506/Improving-Delphi-TDBGrid for example and code samples or Cary Jensons Blog … http://caryjensen.blogspot.co.at/ …

            Simply take knives that work, I have some from Germany and the Swiss that slice things like butter, but you should be in the position to sharpen the knives. Knives from vendors tend to be less sharp, because they want to sell you something tomorrow and one day people forget that knives are sharp and you can cut oneself.

          3. The database support is exactly like Delphi. It works the same.
            it doesn’t have the midas stuff, but everything else is “EXACTLY” the same.
            For someone just starting out I would tell them to use Lazarus and don’t even bother with Delphi.

            You can even get third party support for databases like PostgreSQL from devart.com

            Lazarus is ready for real usage, don’t let anyone fool you.

        2. “Out of the box” DB Support with Lazarus is as good as Delphi XE2 with the few apps I have made for windows 32 and linux 32.

          ZEOS libraries are of course fully compatible with Lazarus (and Delphi) if you don’t like the native offering.

          I tried converting a windows touch screen exe from windows to linux last year and got really close, it wasnt the database layer that was the problem but the dispatch note printing that stopped this from being a goer.

          I use Lazarus more and more in my tinkering, just about everything works well and I’m getting used to the differences with Delphi.

          Delphi still rules on the windows desktop but Lazarus is certainly catching up.

        3. Typhon is a mythical Greek figure?

          Ah.

          I am enlightened. Thank you.

    2. but they are based at June beta version Lazarus 1.1
      How stable it is compared with 1.0 Laz release ?

    3. Interesting, never heard of CodeTyphon (with a single o), will give it a try. I tried Lazarus 1.0RC2 earlier in the week, not bad, has come a long way since I last tried it. One thing I miss is the ability to search for components in the tabbed interface. I’ve so many components on my existing XE that the search capability is very useful. If there was a concerted effort to move many of the common components (eg peg controls, spTBXlib) including JCL it would be much easier to justify moving over existing projects. However for starting new project it looks like Lazarus is a viable option.

      2. To search for components go to “View -> Components” (default shortcut is Ctrl+Alt+P). If you have enabled docking you can even dock the window somewhere comfortable 😉 (though one might request a removal of the buttons at the bottom…)

        Regards,
        Sven

  7. As long as FPC is like 5 years behind Delphi (advanced records, anonymous methods, enhanced RTTI to name just a few not supported features in FPC) it’s no option for me.

    1. An anonymous methods is a very interesting technology. But their implementation in Delphi is so slow! So they can’t replace good old callback functions.

      Enhanced RTTI – it’s what I immediately disable in every my program. Actually I’ve recompiled RTL and VCL with disabled RTTI. It’s bloated and prone for reverse-engineering.

      Advanced records – as I see FPC now have methods for a record type, including class methods. No constructors though. But a record constructor can be substituted with a static class function or a factory function.

    2. Well… there is a huge discussion regarding some of these concepts even between the developers, because some features like anonymous methods are considered an abomination of the language. Nevertheless if someone steps up and implements them they get implemented. At the start of 2011 I myself stepped up and implemented support for helper types (record and class helpers) and plan to extend them also for other types (interfaces, objects and primitive types). Also I’ve heavily improved support for Delphi style generics (though some things are still missing like generic functions/methods and constraints).

      Advanced records are already implemented in FPC 2.6.0 by the way (though constructors are not supported yet). One of the developers has started to implement class attributes and I’m rather sure that the enhanced RTTI will come sooner or later as well 😉

      Regards,
      Sven

  8. You really are miffed with the shiny new EULA!

    I gave a wry smile myself when I saw Lazarus 1.0 emerge yesterday. If our core application wasn’t such a beast I’d be looking in that direction at this point too.

    As it is, the EULA and its implications will be on the agenda for our monthly partners meeting next week. If this had happened when the 64bit debarcle was happening, then I know for sure we’d have jumped ship at that point.

    1. The EULA changes are just the latest, and most obvious to many, display of the deeper malaise within Embarcadero that has me “miffed”.

  11. Unfortunately, from what I can see, it appears that FPC *still* does not have proper support for Packages, and that the team doesn’t even seem to realize how crucial that is for a Delphi clone. It’s not just for the IDE; the BPL model also makes a great basis for a plugin architecture in general. Without it, FPC is unusable for me.

    1. Hmmm, crucial for some people I guess. 🙂

      Yes, packages make a great basis for a plugin architecture (not surprising, since a BPL is essentially a plugin itself, so they aren’t just the basis for a plugin architecture, they ARE a plugin architecture). But COM provides a similar basis too. Not as “native” to the language perhaps, but depending on the needs of your plugin, and the nature of your product, COM arguably is the better platform since it enables you to build your plugin support in a way that enables 3rd parties to build plugins without having to use Delphi.

      That’s reflecting a purely Windows perspective, obviously.

      Horses for courses. And of course, I haven’t yet grappled with packages or COM in FPC so time will tell. 🙂

      1. Last thing I heard was that working with COM or OLE in FPC is reeeaaaally tedious when compared to Delphi. We tend to forget how much work the Delphi compiler actually does for us in this area… (e.g. handling IDispatch – take a look at this thread on a Lazarus forum about Office automation)

        That was a couple of years ago though, so I’d be happy to hear things have changed…

        1. No, it’s pretty much the same.
          I recently wrote a COM app with Lazarus that uses OpenOffice to convert documents to PDF, I originally wrote it in Delphi and tried to port it to Lazarus on whim and it now compiles on both. The differences to make it work on lazarus were minimal.

    2. BPL is quite fragile and limited for plug-ins actually, since everything needs to be compiled against the same RTL and source code by the same Delphi version, one might as well build a monolithic executable in the first place.

      For plugins, COM or plain old DLLs with a C interface are far more practical solutions.

      BPL is just good for design-time components in the IDE, but as a plugin architecture for deployments in the field, BPL is very inappropriate IME:
      – need to avoid breaking changes without a proper interface to make it well-defined where those changes can happen
      – need to redeploy BPLs every time you deploy a new EXE with interface breaking changes or recompiled with a new version of Delph
      – unability to support multiple versions of the plugin interface (i.e. support old version plugins in the new executable)
      – unability to support plugins written in other languages
      – unability to isolate the plugin so it can be unloaded without leaks at any time, or can’t corrupt the host
      – etc.

      And tbh, most of the above make BPLs an uncomfortable solution even in the Delphi IDE.

      1. Perhaps your definition of “far more practical” is different than mine, but the practical advantages of *not* being limited to just a COM or C interface in a fully object-oriented language is one of the best reasons to want to use BPLs.

        Your first two points simply state, in essence, that your plugin system needs to be stable before you deploy it. But that’s essentially true for any plugin system.

        Versioning can be handled if you’re careful about it, and it’s not any more difficult than implementing COM-based plugin versioning. Why do you think that BPLs present special difficulty on that front?

        And what do BPLs have to do with an inability to unload a plugin without leaks or corruption “at any time”? The only way to make it so you can unload something at any time with no negative consequences, in a BPL or otherwise, is to put the entire thing in a sandbox, with no way to interact with the host, and destroy the sandbox when you unload it. But that whole “no way to interact with the host” bit kind of makes your plugin system useless, because it’s not plugging in to anything.

        On the other hand, if you relax your ambitions just a little, and aim for a plugin system that can be unloaded *at a well-defined time*, then it’s a simple matter of requiring that the plugin implement some well-defined cleanup mechanism. (And if the plugin does a bad job of cleaning up, it can still corrupt the host, but that will be true on a BPL, a COM system, or a C interface. Only way to make that not happen, again, is to sandbox the plugin into uselessness.)

        So what’s the problem with BPLs as plugins again?

        1. BPLs are fine for plugins if one organisation/individual is responsible for building them. Otherwise the restriction to a single version of an obscure minority compiler makes them untenable.

          If I were to ask my customers to compile plug-ins in the same exact same version of Delphi as my app, no plug-ins would be written.

          1. Indeed, not to mention they’re sensitive to internal implementation details within the same version of the compiler, and to implementation details of the rtl for a same version of the compiler. Those limitations are painful enough within the IDE, they’re unacceptable out if it.

    3. Yes, packages can be a crucial feature for somebody. But not for me. Never use them in my programs.

    4. The problem with dynamically loadable packages is that if we introduce them we want them to be supported at least on the major platforms Windows, Linux and Mac OS X. And this is already not easy when thinking about the concepts that are necessary. Also noone is currently interested in implementing dynamic packages or even providing the foundations for them (this also includes people not part of the development team)…

      Regards,
      Sven

  12. 10 years and reached version 1.0. Not exactly Firefox/Chrome release speed. Possibly a hair faster than WINE.

    1. Conservative release numbers are part of the freeware tradition.

      There is no marketing department pushing.

    1. Whether they have some dedicated full-time developers in the team?

  14. BTW mr. Ghisler has already converted its great “Total Commander” from Delphi to Lazarus.

        1. Link? All I’ve seen is a post in his own forums saying TC was compiled in D2.

          If he really did move the TC codebase from D2 to D2009 then FPC/Lazarus, then he would have wasted his time.

  15. To be honest: The release of Lazarus 1.0 was not really influenced by the current state of Delphi (though I personally consider it a lucky coincidence for Lazarus 😉 ). It was planned since some weeks already as this weekend the “Lazarus Day” in the Netherlands is held and they wanted to celebrate the release there.

    Regards,
    Sven

    1. Is there a changelog (high level, not source-level at the SVN level) of what is being added/changed in Lazarus and FreePascal?

      Something maybe like a weekly or monthly summary “we added feature X, we tweaked dialog Y”, etc.

      I’ve searched the site, but couldn’t find it. The summary for FPC 2.6.0 f.i. leaves out a lot of additions.

Comments are closed.