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 _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
