Enumerating Plugins

Cyberman · Oct 23, 2002

NRage, Azimer clue me in...

I seem to be having trouble getting a plugin enumerated .. now for the silly question How does PJ64 determine what plugins/DLL's are for what?
I am using
LibRef = LoadLibrary(<DLLPATH>);
if (LibRef != NULL)
{
GetTheInfo = GetProcAddress(LibRef, "GetKeys");
if (GetTheInfo != NULL)
{
GetTheInfo = GetProcAddress(LibRef, "GetDllInfo");
if (GetTheInfo != NULL)
{
GetTheInfo(&PI_NFO)
...

to grab the plugins that are Input Plugins (heh). The problem is my plugin doesn't seem to be recognized as an input plugin from PJ 64 so that's why the question.
Does it look for the same function names or with an _ proceeding them? I know that BCB prepends an _ to the local function names I'm wondering if I need to turn that off for the functions that I'm defining only to get my plugin Enumerated.

And don't ask what I'm doing.. at least not until it's close to working.. (mumble mumble).

Cyb

Hacktarux · Oct 23, 2002

Hmm you're searching in a complex direction something easy

When the emu loads a plugin it calls GetDLLInfo function. This function will fill a structure with all the needed infos such as plugin type... look at the beginning of the header file for description of this struct

Cyberman · Oct 23, 2002

Ok.. doh forgot about that.. however that doesn't answer why it's not recognizing the plugin I made.. I wonder if it's because of name mangling .. time to look a bit.

Cyb

Cyberman · Oct 23, 2002

Hmmm acording to the map file generated the names of the functions for export begin with _'s like _GetDllInfo.. etc. What's the probability that this is my problem why the plugin isn't recognized? It sets the correct type and returns the correct information however.. if the function name begins with an _ I believe it won't get called.. now I have to figure out how to turn this off for just the function names.

Cyb

flow`` · Oct 23, 2002

n-rage's source is available if you want to take a look

http://go.to/nrage

Cyberman · Oct 24, 2002

flow`` said:
n-rage's source is available if you want to take a look

http://go.to/nrage

I've downloaded that.. already the problem I have is that I'm not making a input plugin but interfacing to one and acting AS an input plugin. I'm using BCB5 for this.. I guess I might have better luck getting a root canal? I've tried turning off the _ compilor option that creates a lot of headaches.. because it makes all library functions go off the deep end

At least my Plugin for editing Save states on the PSX works

Cyb

N-Rage · Oct 24, 2002

You must make sure youre using the right calling-conventions.
The Plugin must use cdecl Convention( standard for c/c++ ) for exports. Dont know how to set it in Borland Builder. Best would be to replace the EXPORT and CALL Makro in the controller.h Header with Builder specific Instructions, AFAIK the commands used are M$-exclusive. Maybe you have to define a own file for declaring exports.

Oh, and dont use the V1.1 header, it aint working with any emulator

lain2:

Cyberman · Oct 24, 2002

N-Rage said:
You must make sure youre using the right calling-conventions.
The Plugin must use cdecl Convention( standard for c/c++ ) for exports. Dont know how to set it in Borland Builder. Best would be to replace the EXPORT and CALL Makro in the controller.h Header with Builder specific Instructions, AFAIK the commands used are M$-exclusive. Maybe you have to define a own file for declaring exports.

Oh, and dont use the V1.1 header, it aint working with any emulator lain2:

:!!!: ummm ok.. where do I get a new version of the header file then? I used the controller.h included with your plugin (that compiles just dandy). I suppose I should look for a newer version of the Zilmar spec header? (mumble mumble). Ok

Cyberman · Oct 24, 2002

Code:

/**********************************************************************************
Common Controller plugin spec, version #1.0 maintained by 
zilmar ([email protected])

All questions or suggestions should go through the mailing list.
[url]http://www.egroups.com/group/Plugin64-Dev[/url]
**********************************************************************************/

Hmm this looks like Zilmar 1.0 .. I'll Look at the PJ64 source and see what it's looking for when it does a GetProcAddress() for the functions in the plugin.

Cyb

Hacktarux · Oct 24, 2002

Actually i think that every input plugins are using 1.0 specs.
When i have implemented input plugins on mupen64, i have only used 1.1 coz i was on linux and there was no plugin yet, then when i switched to windows i was not able to find any plugin that work with those specs, so i have also implemented 1.0.

Cyberman · Oct 24, 2002

Ok .. it enumerates them by looking at *.dll in the plugin directory then it does a
hLib = LoadLibrary(<name>);
next
GetDllInfo = (typecast stuff here)GetProcAddress( hLib, "GetDllInfo" );

After that if GetDllInfo is NULL it skips that DLL
So it's not finding "GetDllInfo" in my plugin.. which probably means that an _ is proceding the thing (sigh). I can't use any VCL components if no _'s are allowed (hmmm) gets complicated fast.

Cyb

Cyberman · Oct 24, 2002

For those who want to write DLL's compatible with microsoft style ones with BCB, HERE is how you do it! Believe it or not it's not terribly hard (surprised?). OGL is easy to implement but doing a N64 Plugin for it is a horse of a different color. Anyhow... here is the "trick" apparently MS doesn't use the standard convention for nameing external functions which is "_" <function name> so for BCB to generate the function name properly you have to do this:

void __stdcall GetDllInfo(....
That's it just shove __stdcall instead of _cdecl in BCB

The it names the function properly!

Unfortunately I'm getting a memory access error when the DLL library is being loaded but at least it's whining about that.

Cyb

N-Rage · Oct 24, 2002

nono, stdcall will fook things up, must be cdecl, else you will do REALLY messy stuff after the functions were called.

I wasnt making it clear, but i meant you should use V1.0 of the specs, v1.1 is available with PJ1.4 and 1.5 but the Emu itself seems to not support the spec right.

if you included the controllerspecs you should be done normally. look at the CALL and EXPORT Makro an see if You find similary Builder5-instructions, CALL should set the function to cdecl and EXPORT should well, make the function available under that name.
You could also try creating a .def File for exports.

PS. You should write remarks into a file or maybe show a Messagebox when the functions where called, that way you can be sure it worked or it dint.

N-Rage · Oct 24, 2002

umm, thats a lill tool which can show You the exported names.
Run it with dumpbin yourDLL /EXPORTS from Commandline.

Cyberman · Oct 25, 2002

N-Rage said:
nono, stdcall will fook things up, must be cdecl, else you will do REALLY messy stuff after the functions were called.

I wasnt making it clear, but i meant you should use V1.0 of the specs, v1.1 is available with PJ1.4 and 1.5 but the Emu itself seems to not support the spec right.

if you included the controllerspecs you should be done normally. look at the CALL and EXPORT Makro an see if You find similary Builder5-instructions, CALL should set the function to cdecl and EXPORT should well, make the function available under that name.
You could also try creating a .def File for exports.

PS. You should write remarks into a file or maybe show a Messagebox when the functions where called, that way you can be sure it worked or it dint.

I created a DEF file using Impdef.. the toy you sent me require Microsofts LINK.EXE to execute (doh).

Here's the def output:

Code:

LIBRARY     CYBNPI.DLL

EXPORTS
    @@Configunit@Finalize          @17  ; __linkproc__ Configunit::Finalize
    @@Configunit@Initialize        @16  ; __linkproc__ Configunit::Initialize
    @@Netpi@Finalize               @15  ; __linkproc__ Netpi::Finalize
    @@Netpi@Initialize             @14  ; __linkproc__ Netpi::Initialize
    @@Netstatus@Finalize           @13  ; __linkproc__ Netstatus::Finalize
    @@Netstatus@Initialize         @12  ; __linkproc__ Netstatus::Initialize
    CloseDLL                       @1   ; CloseDLL
    ControllerCommand              @2   ; ControllerCommand
    DllAbout                       @11  ; DllAbout
    DllConfig                      @10  ; DllConfig
    GetDllInfo                     @3   ; GetDllInfo
    GetKeys                        @4   ; GetKeys
    InitiateControllers            @5   ; InitiateControllers
    RomClosed                      @6   ; RomClosed
    RomOpen                        @7   ; RomOpen
    WM_KeyDown                     @8   ; WM_KeyDown
    WM_KeyUp                       @9   ; WM_KeyUp
    _Config                        @20  ; _Config
    _NetForm                       @19  ; _NetForm
    ___CPPdebugHook                @18  ; ___CPPdebugHook

I'm not using the same compilor.. so things aren't always as simple.. now I suppose I could create a DEF file and use that instead ... hmmm I'll have to look into that. (sigh).

Cyb

Search

Search

Enumerating Plugins

Cyberman

Moderator

Hacktarux

Emulator Developer

Cyberman

Moderator

Cyberman

Moderator

flow``

flow``

Cyberman

Moderator

N-Rage

New member

Cyberman

Moderator

Cyberman

Moderator

Hacktarux

Emulator Developer

Cyberman

Moderator

Cyberman

Moderator

N-Rage

New member

N-Rage

New member

Cyberman

Moderator