Plugins/Dynamic Libraries

Plugins/Dynamic Libraries

[Andrew W]

Greetings All,

I am starting work on a plug in / dynamic library project with ADA and just
wanted to see if I had missed anything.  I understand that this is very
compiler and OS dependent.

Under Linux the accepted method is using the DLibs bindings to dlopen etc
http://www.cyberdanx.co.uk/ada95/dlibs.html

Under Windows the accepted method is using COM
http://www.gnavi.org/gnatcom/

I found a post from last year which mentions: "there is a AdaPlugin project
for Linux that use Dynamic Glib Module functionnality" but did not provide
any more information - I have been unable to find such a project.

I would most obliged if anybody has pointers to any other ada dynamic
library implimentations (especially under Linux/Unix).

Thank you very much in advance,

Andrew

Re: Plugins/Dynamic Libraries

[Martin Krischik]

Andrew W wrote:

> Greetings All,
> 
> I am starting work on a plug in / dynamic library project with ADA and
> just
> wanted to see if I had missed anything.  I understand that this is very
> compiler and OS dependent.
> 
> Under Linux the accepted method is using the DLibs bindings to dlopen etc
> http://www.cyberdanx.co.uk/ada95/dlibs.html
> 
> Under Windows the accepted method is using COM
> http://www.gnavi.org/gnatcom/
> 
> I found a post from last year which mentions: "there is a AdaPlugin
> project for Linux that use Dynamic Glib Module functionnality" but did not
> provide any more information - I have been unable to find such a project.
> 
> I would most obliged if anybody has pointers to any other ada dynamic
> library implimentations (especially under Linux/Unix).

A current version of GNAT and GPS can do DLLs out of the box. Just Add the

    for Library_Dir         use  ...;
    for Library_Name        use ...;
    for Library_Kind        use ...;
    for Library_Version     use ....;

to your project file and all needed steps will be done for you. Why there is
no checkbox in GPS I don't know. For Windows you need the "experimental"
MinGW GNAT based on GCC 3.4.2. Older GNAT's can do Linux DLLs only.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Plugins/Dynamic Libraries

[Adrien Plisson]

Andrew W wrote:

> Under Linux the accepted method is using the DLibs bindings to dlopen etc
> http://www.cyberdanx.co.uk/ada95/dlibs.html
> 
> Under Windows the accepted method is using COM
> http://www.gnavi.org/gnatcom/

well, let's relieve the pain:
for dynamic libraries under Windows, the accepted method is _NOT_ COM ! 
the equivalent of Windows COM under Linux may be CORBA, and the 
equivalent of Linux dlopen under Windows is LoadLibrary.

these are 2 totally different approaches to the problem:
- LoadLibrary and dlopen allows to load a module whose structure is 
already known through the use of header files, .def files and other 
documentations. the module itself does expose fully the name of the 
methods it contains (it may expose it, often decorated) nor the name or 
types of arguments to those methods. it is the programmer responsability 
to check that his header file correspond exactly to the version of the 
module he is trying to use, and the compiler will check that arguments 
types to method calls are correct.

- COM and CORBA allows to load modules whose structure and content is 
unknown. the module exposes fully its name, version, methods and other 
definitions. for each method, it also exposes the type of arguments in a 
rather descriptive way. this allows to plug an unknown module into an 
application at runtime. it also allows to plug a module which was not 
existing at the time the application was written.

so LoadLibrary an ddlopen are lightweight runtime dynamic library 
mechanisms whereas COM and CORBA are heavyweight dynamic library mechanisms.

if you plan on working on this subject, try to use equivalent mechanisms 
on each platform you target.

please note that there are many bindings to those methods existing: 
PolyORB, AdaBroker or ORBIT-Ada are CORBA implementations, DLib for 
dlopen, LoadLibrary should be accessible through Win32Ada, and for 
COM... well, i don't know...

-- 
rien

Re: Plugins/Dynamic Libraries

[Adrien Plisson]

Martin Krischik wrote:

> A current version of GNAT and GPS can do DLLs out of the box. Just Add the
> 
>     for Library_Dir         use  ...;
>     for Library_Name        use ...;
>     for Library_Kind        use ...;
>     for Library_Version     use ....;

these are static bindings done at compile time. the resulting executable 
contains a segment which tells the system to load the given library and 
relocate symbols in the process space. but if the library is not present 
at application startup, the application does not start: the system is 
responsible for loading and checking the dll. (at least it works this 
way under windows).

Andrew was talking about dynamic bindings at runtime. that is calling a 
function which loads the dll, whose name is contained in a variable. if 
at application startup the library does not exists, it is not a problem: 
the programmer is responsible for loading and checking the dll.

> to your project file and all needed steps will be done for you. Why there is
> no checkbox in GPS I don't know. For Windows you need the "experimental"
> MinGW GNAT based on GCC 3.4.2. Older GNAT's can do Linux DLLs only.

it seems GNAT 3.15p for windows is doing DLLs (according to the doc, i 
had no time to test it).

-- 
rien

Re: Plugins/Dynamic Libraries

[Frank Piron]

Thu, 11 Nov 2004 11:49:17 +0100 Adrien Plisson 
<aplisson-news@stochastique.net> wrote:
> it seems GNAT 3.15p for windows is doing DLLs (according to the doc, i 
> had no time to test it).
>
It does and it works fine. We've build many dll's with GNAT 3.15p.
E.g. we use them inside a Winword macro and transport the doc into an
Oracle BLOB column.
-- 
Frank Piron,
etfrankatkonaddotn
(leftrotate two)

Re: Plugins/Dynamic Libraries

[Martin Krischik]

Adrien Plisson wrote:

> Martin Krischik wrote:
> 
>> A current version of GNAT and GPS can do DLLs out of the box. Just Add
>> the
>> 
>>     for Library_Dir         use  ...;
>>     for Library_Name        use ...;
>>     for Library_Kind        use ...;
>>     for Library_Version     use ....;
> 
> these are static bindings done at compile time. the resulting executable
> contains a segment which tells the system to load the given library and
> relocate symbols in the process space. but if the library is not present
> at application startup, the application does not start: the system is
> responsible for loading and checking the dll. (at least it works this
> way under windows).
> 
> Andrew was talking about dynamic bindings at runtime. that is calling a
> function which loads the dll, whose name is contained in a variable. if
> at application startup the library does not exists, it is not a problem:
> the programmer is responsible for loading and checking the dll.
> 
>> to your project file and all needed steps will be done for you. Why there
>> is no checkbox in GPS I don't know. For Windows you need the
>> "experimental" MinGW GNAT based on GCC 3.4.2. Older GNAT's can do Linux
>> DLLs only.
> 
> it seems GNAT 3.15p for windows is doing DLLs (according to the doc, i
> had no time to test it).

Last time I checked in GNAT 3.15p you had to read 2 pages of documentation
and then call dlltool 3 times with all sorts of wacky options while in GCC
3.4.2 you just tell the project manager you want a DLL and then GNAT does
it all for you (incl. calling dlltool).

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Plugins/Dynamic Libraries

[Pascal Obry]

Martin Krischik <martin@krischik.com> writes:

> Last time I checked in GNAT 3.15p you had to read 2 pages of documentation
> and then call dlltool 3 times with all sorts of wacky options while in GCC
> 3.4.2 you just tell the project manager you want a DLL and then GNAT does
> it all for you (incl. calling dlltool).

Not if you used gnatdll which handles everything for you. But right, the new
support based on project file is simplest yet and is following the same
procedure as to build .so on GNU/Linux.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Plugins/Dynamic Libraries

[David Botton]

GNAT has had no problems with DLLs already for many versions prior.

Here is an old article for using GNAT 3.11p

http://www.adapower.com/adapower1/articles/howto-gdllc.html

If I recall, the GNAT UG has the current directions which are fairly 
easy. For an example see GNATCOM (which automatically generates for you 
from an idl file a .EXE and .DLL code for a COM object and make.bat to 
compile it)

David Botton


On 2004-11-11 03:28:07 -0500, Martin Krischik <martin@krischik.com> said:
> For Windows you need the "experimental"
> MinGW GNAT based on GCC 3.4.2. Older GNAT's can do Linux DLLs only.

Re: Plugins/Dynamic Libraries

[David Botton]

On 2004-11-11 05:34:16 -0500, Adrien Plisson 
<aplisson-news@stochastique.net> said:

> well, let's relieve the pain:
> for dynamic libraries under Windows, the accepted method is _NOT_ COM ! 
> the equivalent of Windows COM under Linux may be CORBA, and the 
> equivalent of Linux dlopen under Windows is LoadLibrary.

I would not say they are equivalent. COM is also used as a spec for 
communication on a much smaller scale. As for being the accepted 
method, it depends on what you are trying to achieve. Most of the time 
COM is in fact preferable (encased in DLL, ie. an inproc server) since 
it is an automatic plug-in to Windows, .NET, VB, etc. DLLs still serve 
there place, but COM on Ada is easy to do and the results are far more 
flexible.

I find that in most modern serious projects COM (on Windows and 
starting recently for Mac OS X) is in fact being used over a plain dll 
and in particular if you are looking to do plug-ins.

In fact, on Mac OS X plug-in are also COM in a shared lib just like on 
Windows. COM is more of a spec for plug-ins that can interoperate than 
a distributed object system like CORBA.

There is no reason not to use the COM "spec" in the same way on Linux 
for plug-ins. Take a look at InsideCOM (Microsoft Press) for an 
introduction to COM the spec (it doesn't serve as a good intro to COM 
on Windows incidentally) The GNATCOM framework though would need a 
little bit of work though to make it really viable though for use on 
Linux, but is very reasonably doable.

I plan on a port of GNATCOM to OS X in the next year or so and that 
would be usable on Linux as well. On OS X it buys you the ability to 
plug-in to web browsers, etc. but on Linux you would still be able to 
use it for the purpose you are looking for.

> 
> if you plan on working on this subject, try to use equivalent 
> mechanisms on each platform you target.
> 
> please note that there are many bindings to those methods existing: 
> PolyORB, AdaBroker or ORBIT-Ada are CORBA implementations, DLib for 
> dlopen, LoadLibrary should be accessible through Win32Ada, and for 
> COM... well, i don't know...

GNATCOM of course :-)  as he pointed out. http://www.gnavi.org/gnatcom

David Botton

Re: Plugins/Dynamic Libraries

[Adrien Plisson]

David Botton wrote:

> I would not say they are equivalent. COM is also used as a spec for 
> communication on a much smaller scale. As for being the accepted method, 
> it depends on what you are trying to achieve. Most of the time COM is in 
> fact preferable (encased in DLL, ie. an inproc server) since it is an 
> automatic plug-in to Windows, .NET, VB, etc. DLLs still serve there 
> place, but COM on Ada is easy to do and the results are far more flexible.

you're right, COM is not equivalent to corba, but DCOM is. but i would not say 
COM are preferable to dll most of the time. COM adds some (somewhat big) 
overhead which may not be interresting.

one thing to notice: coding plugins is ONLY a matter of interface. COM defines 
a standard interface, but you are free to use yours. i already worked on a 
small project involving plugins in C: a software that was adding funny 
movements to your mouse. each kind of movement was implemented in a standard 
dll, loaded dynamically at runtime. each plugin was implementing an interface 
consisting of 3 functions. those 3 functions were sufficient and using COM 
there would have been overkill.

on another scale, taking advantage of the ability to put C++ classes in dlls, i 
wrote an application based on modules. here again i defined an interface (a 
base class) from which modules derived. the only fancy stuff needed was some 
factory functions in each dll (this is a standard design pattern called 
Abstract Factory).

you will say that this is exactly what COM does for you, but unfortunately, you 
cannot strip down COM to remove what is not interesting for your particular 
project. the worst thing to do is trying to use the ATL (Active Template 
Library from Microsoft) to code simple COM objects: ATL suffers from a bad 
design which stopped me most of the time.

> I find that in most modern serious projects COM (on Windows and starting 
> recently for Mac OS X) is in fact being used over a plain dll and in 
> particular if you are looking to do plug-ins.

COM is almost always used over a plain dll.

> In fact, on Mac OS X plug-in are also COM in a shared lib just like on 
> Windows. COM is more of a spec for plug-ins that can interoperate than a 
> distributed object system like CORBA.

that's it: COM is an interface. DCOM is a more refined interface which allows 
for distribution.

> There is no reason not to use the COM "spec" in the same way on Linux 
> for plug-ins. Take a look at InsideCOM (Microsoft Press) for an 
> introduction to COM the spec (it doesn't serve as a good intro to COM on 
> Windows incidentally) The GNATCOM framework though would need a little 
> bit of work though to make it really viable though for use on Linux, but 
> is very reasonably doable.

I already read "Inside OLE" some years ago... (for those interested: "Inside 
OLE", 2nd edition, is given in an alectronic format with the MSDN library for 
Visual Studio 6)

> GNATCOM of course :-)  as he pointed out. http://www.gnavi.org/gnatcom

shortly after i posted it, i made a search on AdaPower.com and found it.

-- 
rien

Re: Plugins/Dynamic Libraries

[Pascal Obry]

David Botton <david@botton.com> writes:

> GNAT has had no problems with DLLs already for many versions prior.

Yep, but it was easy using gnatdll... With recent versions of GNAT you can
either use a project file to build the DLL or simply a "gcc -shared" command
(as done on UNIXes).

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Plugins/Dynamic Libraries

[David Botton]

On 2004-11-12 04:53:03 -0500, Adrien Plisson 
<aplisson-news@stochastique.net> said:
> 
> you're right, COM is not equivalent to corba, but DCOM is. but i would 
> not say COM are preferable to dll most of the time. COM adds some 
> (somewhat big) overhead which may not be interresting.

Actually it is very light, in particular if your are doing inproc.

> 
> 
> you will say that this is exactly what COM does for you, but 
> unfortunately, you cannot strip down COM to remove what is not 
> interesting for your particular project. the worst thing to do is 
> trying to use the ATL (Active Template Library from Microsoft) to code 
> simple COM objects: ATL suffers from a bad design which stopped me most 
> of the time.

That is why I write my COM in straight C++ or Ada and do not use ATL or 
MFC for COM. It is actually simple and fairly lightweight once you get 
to its heart.

David Botton

Re: Plugins/Dynamic Libraries

[Lionel Draghi]

Andrew W a ï¿œcrit :
> Greetings All,
> 
> I am starting work on a plug in / dynamic library project with ADA and just
> wanted to see if I had missed anything.  I understand that this is very
> compiler and OS dependent.

I don't know if it's still available somewhere on the net (or even if 
it's relevant), but the winner of the Ada-France 2001 contest was a 
project named AdaPlugins, from Franￜois Godmￜ.
(http://www.ada-france.org/article11.html).

You may try to google it.

-- 
Lionel Draghi