Plugins system for Delphi application - bpl vs dll?

前端 未结 5 1836
离开以前
离开以前 2020-12-02 19:18

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

5条回答
  •  一个人的身影
    2020-12-02 19:27

    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.

提交回复
热议问题