.NET is back again

[Tanuki]

Hello everybody,

My question is concerning Winanp plugin development using C# code. I know it's not possible, however I'd like to get some suggestions about something new, let me explain.

I wrote a native dll in C++, which has everything requiered for general purpose plugin. This dll is also using managed code (CLR). This dll has references to a purely managed dll writen in C#.
In the plugins folder of Winanp, I copied both dll gen_A.dll and B.dll (where genA.dll is the native C++ dll using managed code and B.dll is the C# managed code dll).

When I start Winamp, it fails at initialization time. Not a big surprise. I did several tests to try to understand what happens in the black box and noticed the following stuffs :

Really using managed code in the native dll works fine, int the init function given at the winampGeneralPurposePlugin global structure, I called System::Windows::Forms::MessageBox::Show("This MessageBox runs in managed code"); and the plugin could load fine and display the message box.

I created a managed class in the native dll, instanced this managed class using gcnew operator in the init function of the plugin and called a function of this managed instance and it worked fine too.

The only problem seems to be when I try to instance a class (or even call a static method) of a referenced managed assembly (B.dll code).

To ensure this is not an OS problem/limitation and/or an impossibility for a loaded dll from another application to host itself a managed dll, I created a small console application to try this out, here is the code :

(the following code in of course not PHP code)

PHP Code:

int main()
{
    HMODULE hDll = LoadLibraryA("gen_A.dll");
    printf("hDll : 0x%X\r\n", hDll);
    if (hDll == NULL)
        return (1);

    winampGeneralPurposePluginGetter genFunc =
        (winampGeneralPurposePluginGetter)GetProcAddress(
            hDll,
            "winampGetGeneralPurposePlugin");
    printf("genFunc : 0x%X\r\n", genFunc);
    if (genFunc == NULL)
        return (2);

    winampGeneralPurposePlugin* gen = genFunc();

    printf("name : %s\r\n", gen->description);

    gen->init();
    gen->config();

    return (0);
} 


This application runs perfectly, it loads the native dll using managed code (gen_A.dll), then gen_A.dll instance managed object written in C# in the B.dll (at gen->init() and gen->config() functions) and everything works fine.

So I guess Winamp do not load the dll the same way, or something else more complicated happens during Winamp's dll loading phase, and I'd like to understand what.

Thank you all for your answers.

[Tanuki]

Sorry for the long explanation before, I understand that some people probably don't want to read it so I attached an easy-to-understand schema to this post to show the problem I'm encountering.

There is 4 cases, and the last case is the one I'm interested in, and is unfortunatly the one causing problem.

Thank you all very much for your help.

[DrO]

winamp (or anything else that implements winamp plugin loading) will load plugins via the loadlibrary method as you've posted.

i would have thought there'd be some sort of error status you can check to see why the 4th case is failing to work since i'd have thought it's something to do with being loaded into another process than expected or some other weird dll dependancy issue. other than that i really don't know/can't suggest much else since it's not something i've tried/have the means to easily try out.

-daz

[Tanuki]

Thanks for your reply DrO.

Actually the gen_A.dll module is the exactly the same as the one Winamp tries to load and nothing else. I wanted to make sure the problem comes from my plugin and not from Winamp, so I wrote that small test loading code, that loads my plugins and interact with it using the Winamp generic plugin interface, just as same as Winamp would do... Unfortunatly this code runs perfectly.

Maybe Winamp plugins run in a different memory space, such as shared memory or very specific appartement thread process, I have no idea and I hoped you guys could give us some more info about it. I'll try some way to enter debug the dll and find out where the code fails.

In the meantime, of some body have any suggestions and/or idea, it's all welcome.

Thanks.

[Tanuki]

I found out the problem

Indead Winamp loads the plugin dll the same way as other application, except that for some unknown reason the reference search path is Winamp.exe root path and absolutly no others.

I've put the gen_A.dll in the [WINAMP_PATH]\Plugins and it is loaded without problems, and I noticed the plugin become operational only if the B.dll is in the same directory as Winamp.exe. Even if I drop it in [WINDOWS]\[SYSTEM32] folder and .NET GAC folder, it does not work.

So my plugin works fine like this but the problem is that I have gen_A.dll in [WINAMP_PATH]\Plugins directory and the other piece of my plugin in [WINAMP_PATH] directory. That's not as clean as I would like.

Anyway I could make C# code to run in Winamp plugin and I'm happy enough like this.

I found out this problem by debugging my plugin running in Winamp and at referencing-time, a System.IO.FileNotFoundException was raised. If somebody encounter this problem, it means the CLI dll couldn't reference (late-binding) your .NET full managed dll.

Now my plugin is in mockup state, but once it will be finalized, I'll propose it with full source code and tutorial to explain to Winamp lovers who also love .NET, how to use their favorite .NET language to write Winamp plugins.

Also, to Winamp programmers, I think it might be a not-so-big task to achieve a bridging component to directly allow a .NET plugin interface. If you think about making something this way, I'd like you to know that I'm ready to help such as development if planed.

Thank you all for reading, and please keep an eye on this topic.

[DrO]

i think the loading thing is more down to the OS than winamp since it is just a straight Loadlibrary() call being done - i think the documentation on msdn gives more information about the order that things are done with regards to the search paths. i know a number of the native plugins exhibit the same 'quirk' in loading.

the other option is to explicitly load the plugin specifying the direct path which would allow you to not have to place the other dll in the root of the winamp folder but often it is just easier to do it as is working now.

-daz

[Tanuki]

As I said, I post my plugin using C# code, as well as the full source code here.
If anybody have questions about using .NET code, do not hesitate to ask and I'll try to help.

It's a "Now Playing" plugin, I know there is many already but after checking official Winamp website and comments given to the other "Now Playing" plugins, I hope mine can provide to users a good alternative (however I do not have pretention it will).
Anyway for others who care more about programming plugin for Winamp using .NET than having a new "Now Playing" plugin, I think it's also good for them.

Here is the source code :
http://code.google.com/p/wimp/downloads