[split] Dynamically load DLL at run time (Re: Add dll to Carbide.c++)

[yebcha2050]

A 3rd party DLL and/or its link library if available must be copied in the SDK, next to the system DLLs. The location differs based on the build configuration for which the DLL is provided. Also the interface header files should be copied in %EPOCROOT%epoc32\import but that is not really mandatory.

To find out where to place the DLL/lib do a search in the SDK for "avkon.lib" and then make a judgement based on that listing.

Once the files copied in the SDK you can start using the library as you would do with a regular one, add it to the MMP and call its interface in code.

Hi There,

Anybody willing to tell how to load your own dll at runtime and how well is this possible does it need to be certified to be loaded at runtime when your application starts?

Thanks

[ltomuta]

Look in the SDK Documentation for RLibrary. Also read the Platform Security chapter which has the DLL loading rules.
Whether an application (or a DLL) must be certified or not it depends on what capabilities the application/DLL uses/declares. Of course certification is alwais recomended.

[The Cynic]

There are a surprisinly large number of people who want to explicitly load their own dlls, and frequently get into problems doing so, yet the system will load and unload a DLL for you so I never really understand why they want to do it for themselves.

[wizard_hu_]

Some people want to hack Symbian at any cost, instead of just simply using it.

[A.A.M.]

The Cynic, for example to implement plugins subsystem.

This code snippet might be helpful: Loading DLL by RLibrary

And, of course, don't forget about SDK help: check this section - Dynamically Loading Link Libraries

[The Cynic]

The Cynic, for example to implement plugins subsystem.

This code snippet might be helpful: Loading DLL by RLibrary

And, of course, don't forget about SDK help: check this section - Dynamically Loading Link Libraries

I forgot to mention, there are a surprisingly large number of people who want to load their own plug-ins, when ECOM will do it for you and in a standard manner. Replace something that is standard and works perfectly well and is seemless with something that isn't standard, frequently doesn't work well, isn't as seemless, and would be a lot of work to match all the functionality ECOM provides.
So I never really understand why they want to do it for themselves

[wizard_hu_]

Plugin architecture is already invented and implemented, that is ECOM.
However the RLibrary-based approach makes sense if someone can live without some component, but he/she can also make use of it. In this case RLibrary::Load-ing a custom .dll quickly tells if the system was able to resolve its dependencies (the component is present), or not.