8 ms·

It was done because of technical limitations - the compiler didn't support dynamic packages (collections of dynamic libraries). This was again due to technical

It was done because of technical limitations - the compiler didn't support dynamic packages (collections of dynamic libraries). This was again due to technical limitations from the compiler having to work in multiple OSes (i'm not 100% sure on the detail) and how they share and export symbols from dynamic libraries, something that Delphi didn't have to since it only had to work with Windows and only with their own libraries. FPC and Lazarus are also technically separate projects with their own release schedules and Lazarus has to work with multiple versions of FPC that make things a bit harder. This made introducing dynamic packages very hard... and since there wasn't much of a benefit for most uses (recompiling Lazarus is almost instant after the first compile and even that takes less than a minute even on old hardware), it wasn't something that FPC developers focused on much. Having said that, the next version of FPC will support dynamic packages. They had to change some things in how RTTI is stored, apparently, to accommodate the OS differences (this may break some programs that use the RTTI structures directly, though the fix is trivial and 99.999% of programs wont be affected - even some of my own code that does touch RTTI directly works fine in both the latest stable version and the development version). However chances are Lazarus will still keep using the recompile approach for some time since it'll need to work with FPC 3.0.x... and also it will take some time to update all packages to work dynamically. Anyway, what i'm trying to say, this was done due to technical issues and compiler limitations due to what FPC and Lazarus have to support and remained an issue for a long time because in practice it didn't make much of a difference. However it will soon be solved.

unnouinceput 7y ago
" Delphi didn't have to since it only had to work with Windows and only with their own libraries" Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks. I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that
- badsectoracula 7y ago
  AFAIK Delphi on non-Windows is very different than Delphi on Windows, exactly because of issues (and AFAIK it even used FPC for a little for non-Windows targets, though this was eventually replaced with their own code when they started using LLVM). They were perfectly fine with having differences between platforms at the core level, however this wasn't what FPC developers or Lazarus developers wanted - in general they try to have things operate as similar to all OSes as possible and they also support way more targets than Delphi, which complicates things. In any case i was referring to Delphi in general from the start. Delphi had support for dynamic packages since version 1, but for decades they only supported Windows. FPC on the other hand had support for multiple OSes before even version 1.0 was released. TBH i do not remember the exact details, but IIRC it had to do with memory management, symbol resolution and RTTI support across DLLs (e.g. being able to do something like "Foo is BarClass" in DLL A, Foo is an object instantiated in DLL B with a class that is only available on that DLL B but descends from a class defined in the main program whereas BarClass is a variable holding a virtual class defined in DLL C that also descends from the same class - essentially tying to merge in RTTIs from different AOT compiled modules where none has a complete view). And of course the fact that it was a low priority issue since there wasn't any major practical drawback (personally the only issue i had was that i couldn't share the RTL and LCL between executables that i'd otherwise package together, meaning that the produced executables would take more disk space than necessary since each executable is having their own copy of the RTL and LCL instead of using them from a shared object/DLL).
  - unnouinceput 7y ago
    Yeah, Delphi is still trying to find its compass when dealing with cross-platform. Intentions are good, just execution lacks. Problem is currently none of them (either Delphi nor Lazarus/FPC) are a good fit overall. Each solves problems on different platforms differently while having other problems that are non-existing for the other. I do have fun playing with them though, trying to learn each what quirks lurks around. I mean one example is above I said - Delphi can target ARM if it's Android, but can't target ARM if it's Debian. So I can run on RPI something Delphi cooked if I have Android there, but if I have Raspbian I can't. Same hardware, different OS, such a hard nut to crack :). While if it's Intel and you have Linux, guess what - Delphi owns it. So for now I am switching between IDE's/Frameworks all depending on availability of technology and most importantly what client(s) want.

unnouinceput 7y ago

" Delphi didn't have to since it only had to work with Windows and only with their own libraries" Delphi has for some years the possibility to work on more then just Windows, and still is a breeze, regardless if I targeting Android or Windows, to just "here is the package, put the component on palette" with just 2 clicks. I really hope Lazarus will come home, like you say, with this, since Delphi is not targeting ARM in Linux, while Lazarus does. We'll see what future holds, as I have no problem using one or the other as long as the compiled project works on its intended target. Also regarding RPI, I can just install Android on RPI4 and Delphi will have no problem targeting that

badsectoracula 7y ago
AFAIK Delphi on non-Windows is very different than Delphi on Windows, exactly because of issues (and AFAIK it even used FPC for a little for non-Windows targets, though this was eventually replaced with their own code when they started using LLVM). They were perfectly fine with having differences between platforms at the core level, however this wasn't what FPC developers or Lazarus developers wanted - in general they try to have things operate as similar to all OSes as possible and they also support way more targets than Delphi, which complicates things. In any case i was referring to Delphi in general from the start. Delphi had support for dynamic packages since version 1, but for decades they only supported Windows. FPC on the other hand had support for multiple OSes before even version 1.0 was released. TBH i do not remember the exact details, but IIRC it had to do with memory management, symbol resolution and RTTI support across DLLs (e.g. being able to do something like "Foo is BarClass" in DLL A, Foo is an object instantiated in DLL B with a class that is only available on that DLL B but descends from a class defined in the main program whereas BarClass is a variable holding a virtual class defined in DLL C that also descends from the same class - essentially tying to merge in RTTIs from different AOT compiled modules where none has a complete view). And of course the fact that it was a low priority issue since there wasn't any major practical drawback (personally the only issue i had was that i couldn't share the RTL and LCL between executables that i'd otherwise package together, meaning that the produced executables would take more disk space than necessary since each executable is having their own copy of the RTL and LCL instead of using them from a shared object/DLL).
- unnouinceput 7y ago
  Yeah, Delphi is still trying to find its compass when dealing with cross-platform. Intentions are good, just execution lacks. Problem is currently none of them (either Delphi nor Lazarus/FPC) are a good fit overall. Each solves problems on different platforms differently while having other problems that are non-existing for the other. I do have fun playing with them though, trying to learn each what quirks lurks around. I mean one example is above I said - Delphi can target ARM if it's Android, but can't target ARM if it's Debian. So I can run on RPI something Delphi cooked if I have Android there, but if I have Raspbian I can't. Same hardware, different OS, such a hard nut to crack :). While if it's Intel and you have Linux, guess what - Delphi owns it. So for now I am switching between IDE's/Frameworks all depending on availability of technology and most importantly what client(s) want.