Plugins system for Delphi application - bpl vs dll?

Question

Hi, I'm writing delphi app which should have capability of loading plugins. I'm using JvPluginManager as plugin system/manager ;) Now, in the new plugin wizard they say it's better to use .bpl type plugins instead of .dll plugins ... What are the pros of this solution versus dll type plugins? So far I've found only cons of this solution:

1. I have to put all the common interface units in separate package so that while loading plugins it won't throw any error about the other package containing common unit

2. if, let's say, one of plugin developers decides to uses some well-known unit (like synapse), which doesn't have runtime package by default, and the second plugin developer does the same, than bump... it's crash here ...

So, what are actually the pros of using bpls instead of dlls compiled with runtime packages?

Thanks in advance

Answer 1

Your first con is also a pro. If you replicate shared code in each dll the dlls get bigger and bigger. Even when using dlls you can prevent this by moving shared code in a separate dll.

Pros:

1. Types are shared. No TFont is not a TFont problem
2. Memory manager is shared. Strings and classes can be used as parameter between plugins without problems.

Cons:

1. Plugins can be build using Delphi or BCB only.
2. Plugins should use the same Delphi or BCB version.

Have you considerd using COM? COM makes it possible to share types, strings and classes and the plugins can be written in many programming languages.

Answer 2

I'm not familiar of JvPluginManager, but it depends on how you're going to use BPLs.

Basically, BPL - is just a usual DLL, but its initialization/finalization work is stripped from DllMain to separate functions: 'Initialize'/'Finalize'.

So, if you're going to use BPL like usual DLL, there are no cons that I'm aware of, only pros: there will be no more troubles with DllMain. That's all. The only difference.

But BPL in Delphi also provide a convient way to share code. This means great advantages (common memory manager, no duplicated code, etc, etc). So usual BPL does a lot more than "being just a DLL". But this also means, that now your plugin system is limited to Delphi only (well, may be C++ Builder too). I.e. both plugins and exe MUST be compiled in the very same compiler to run smoothly.

If this is acceptable for you (i.e. no MS Visual Studio, no, sir, never) - then go ahead, you can use all power of BPLs.

P.S. But upgrading such BPLs plugins can be also a nightmare, if you do not design interface side carefully. In certain worst cases, you may need to recompile everything. P.P.S. Like I said: I have no idea, how it is applied to plugins, created by JvPluginManager.

Answer 3

As Alexander said, a BPL is basically a DLL. But there are some conditions (from a not-so-short summary I made: http://wiki.freepascal.org/packages ):

• A unit can only exist once in BPL's +Exe. This avoids duplication of state (twice the heapmanager and other global vars of system etc, VMT tables etc)
• .BPL's can only USE other .BPLs.
• This means that dynamic types like ansistring and IS/AS work properly over BPL interfaces.
• Initialization/finalization are separate procedure and their initialization order is strictly controlled. For static dynamic loading this is simpler, for dynamic loading (plugin-like) all dependancies on units are checked .
• Everything is essentially one big program, which means that the BPL's must be compiled with the same compiler version and RTL and depends on the versions other dependancies. It might be harder to make .BPL's to plugin to an existing EXE, since the Delphi version must match.
• This also means that you must deliver .dcp's for (non Delphi) .BPLs the plugin .BPLs depend on

In short: if the plugin architecture is open, make it a DLL. Otherwise people have to have the exact same Delphi version to write plugins.

Hybrid is also possible. An higher level .BPL interface for functionality you factor out into .BPL yourself and selected devels, and a rock bottom procedure DLL interface for the rest.

A third option is using DLLs, but ordain Sharemem. Strings will work, multiple Delphi versions will work. Objects can work but are unsafe (e.g. I guess e.g. D2009 with an earlier version wouldn't work). Even other language users might be able to allocate over COM, not entirely excluding non Delphi.

Answer 4

Another disadvantage to BPL's. When you switch Delphi versions you will have to re-distribute new plugins. After many attempts at attempting to find the perfect plugin system, I ended up with COM and I have never regretted that decision. In a commercial application which has had the plugin requirement for over 8 years, the application has continued to move forward and yet some of the plugins that were released with the first iteration still exist in their ORIGINAL form.

If you choose this method, do yourself a favor and start with a simple interface and then add new interfaces upon it. You don't want to ever change your base interface, so keep it simple and sweet.

Answer 5

Avoid blp approach as you will have to ship a big bag of bpl with you software and thus, distribution will become bulky.

why do we use Delphi to compile small stand alone programs that just RUN anywhere without any runtime dependency. Using bpls means defeating this very purpose.

I don't know as to how comfortable you are with DLLs, but I would suggest you to use DLLs.

• This will give other developers (who may get interested in your software) a chance to use any development language (as long as that language can spit out dll) to write their own plugins that can be used in your developed software.
• Another thing is that you will be saved from Delphi's vcl version dependency tyranny. A major weak point of Delphi till date.