Plugins system for Delphi application - bpl vs dll?

Question

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

Dingy

Answer 1

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.

Simian

Can you provide any further information about how you iimplemented your COM-based plugin architecture? – Click

The basic premise is to create a common interface then create com automation objects which implement that interface. The parent program invokes the specific com automation object that is required for the behavior needed. I kept a separate lookup of available plugins and the unique class guid necessary to invoke each specific one. The class guid was for the individual automation object, which ALSO implemented the common plugin interface. – Simian

Answer 2

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.

Curmudgeon

Answer 3

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 built 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.

Logsdon

Memory manager ("no TFont is not a TFont error ;)" ) is also shared in case you compile both all plugin dlls AND application with runtime "base" packages like rtl and vcl... so that is not the point. My plugins do not share any code actually, the common units contains interface definitions only... so it's only "dlls compiled with shared bpls vs bpl plugins" ;) – Dingy

You are right about building the dlls with runtime packages. But then you have the same cons for dlls :) – Logsdon

I'm not sure, but I think Microsoft has deprecated COM and DCOM technologies. – Disvalue

Yes, afaik in favour of COM+, on which .NET is based and that is largely compatible with them. – Curmudgeon

After looking at Windows 7 Beta I can say with confidence that COM is still not depreciated and will not be depreciated as still there are a few part of Win which are using COM internally. – Tampere

Answer 4

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.

Attila

I've already decided to drop possibility of using any other language than delphi, because my interfaces are using some Delphi-specific types (like TForm for example ;) ) Writing wrapping interfaces even for those very base objects would take too much time for me ... – Dingy

Note the Delphi version thing. And maybe only Rad Studio versions (with BCB and Delphi on the same version?) might work. They probably have to, since packages are based on .BPL – Curmudgeon

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.

Tampere

I decided to use DLL as there is a planned possibility of plugin exposing some features to other plugins - thus, if the second plugin is installed, the first one can use it's features. If not, it doesn't failt but does not have extended possibilities. Anyway that would mean compiling both packages with "common interface package" which would make it not working if it is not present. No sense. I decided already there is no possibility for writing in other environments (non-VCL) as it is impossible for me to write wrappers for such a base classes like TForm and so on... – Dingy