Hi.

There's have been some previous posts about shared objects/dynamic libraries support with FPC/Lazarus IDE. I'm sending a link to an related article, about DLL, just for general information, not to start a "flame war":

http://www.extremetech.com/article2/0,1697,1153065,00.asp

What do you think ?

maramirez

That's an ancient article. The perceived problem with DLL's had more to do with Visual Basic's runtime and VB .ocx controls that had to be registered than it did with DLL's themselves. If you develop and distribute DLL's with your app, there really is no problem. You can even load them yourself with LoadLibrary.

All OS's and many apps on Windows, Linux and OS X are made up of numerous dynamically loaded libraries. You don't see Linux and OS X developers worrying much about this issue.

Thanks.

-Phil

Ugh! I used it as well as Delphi, freepascal/lazarus and Java, but I swear .net is like walking around the world to go next door !

GAC still needlessly focusses around the central storage idea. That is not necessary, see OS X with its bundles.

On Linux they used the OS abilities and naming rules to prevent a dll hell, since a typical Linux system contains at least twice (usually much more) the number of libraries and applications than your windows machine, if you have a 64 bit Linux you will see how nice libs are placed and with simple symlinks and version in .so names, there are absolutely no naming conflicts, still with all binaries in one place it manages to avoid the dll hell and make everyone happy. I assume OSX also played it smart but OSX had more planning in the first place. The only platform with dll hell is windows, because it didn't support any type of links until NTFS hard links that few know about or use, on windows Borland was smart enough to include versions in their .bpl files for each Delphi version, maybe M$ should have folowed the example instead of inventing a squared iron wheel covered in rubber named an "assembly" that tricks your app into dynamically loading whatever dll the user wants you to load, can't we implement such mechanism ourselvs.
I like the way Zeos Components make use of such dynamic loading and use different dlls and could even have multiple versions of the same dll loaded at once and change between those at runtime, it is a simple as creating a record structure holding the dlls functions and making instances of this record and dynamically loading every version of the dll, it is even more advanced than the assembly concept because you can chose from the application what dll to load and even use more than one version of it. I think FPC could make dynamic dll loading using the current static dll loading syntax or very similar syntax if you are too lazy to write a dynamic loader but then again how much use would it have to have almost the same syntax, maybe it would help automatic converters.

Razvan

Hello,

I don't understand the issue. As Razvan writes, isn't it an OS issue? For example, please find attached a small but complete example I've scratched together this morning to show how one can use <dynamically> DLLs in Windows. Obviously, a minor variation of the code could easily be done for the various linuxes.

FPC and Lazarus therefore do have <today> the capacity for dynamic loading of DLLs. It may be the compiler could add some syntactic glue, but nothing a competent programmer cannot do on his own with minor work, or encapsulate within a component. See the example. I guess GLScene is doing it already.

Or is there something I have missed here?
Best regards,
Thierry Coq

Razvan Adrian Bogdan a ?crit :

Here is the attachment and the examples for dynamically loading DLLs

Thierry Coq

Razvan Adrian Bogdan a ?crit :

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DynamicLoadingLibraryTestSources.zip
Type: application/x-zip-compressed
Size: 7127 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080223/7030af49/attachment.bin