_cdecl vs _stdcall name mangling .. etc.

Using BCB for making Zilmar spec plugins

Ok.. here are some dumb questions..
BCB will mangle names not a big deal that can be worked around.. here comes the real question what is the deal with _cdecl? It seems to create a non standard function call system..

So basically it's NOT possible to use any compilor other than VC++ to make DLL's for 'the spec' of PJ 64 or any other N64 emulator adhering to the Zilmar specs.

as far as I can tell _cdecl should only use the Microsoft C passing conventions right? is this not the same as _stdcall? or is _stdcall a seperate standard?

Does _stdcall use MSpascal and MSfortran conventions?

My problem is functions are being exported without the _ in front of them, which is non standard IF you are using _cdecl (C calling conventions). That's the default for BCB (C calling convention and _ in the front). I can't seem to create a DEF file that changes the names of the functions/ maps them to without the preceeding _ either... arg. No wonder Dave stoped using BCB.. unfortunately the problem doesn't really seem to be BCB but with VC++ not using .. standards.

Have suggestions? Note.. VC++ sucks in it's socket implementation and the documentation they have is worse yet. No wonder people curse MS's name so much.

I have VC.NET I just don't want to use the piece of crap.

Cyb

More stuff... here is MS's information regarding this...

It is not possible to directly call a C function in a DLL if that function uses the _cdecl calling convention. This is because Visual Basic uses the _stdcall calling convention for calling functions. This is a problem because if _cdecl is used, the calling function is responsible for cleaning up the stack. However, if _stdcall is used, the called function is responsible for cleaning up the stack.

Click to expand...

This is why I'm having problems it seems.. and to be blunt.. using _cdecl shouldn't be done.. thats what's causing the access violation is the STACK. There is no way for the emulator to know what the stack will be like after calling the DLL.. hence why it's crashing. It's assuming a lot and requires that the DLL not allocate local variables for the called function..

One way is dependant on the compiled source code of another program to pop off everthing from the stack pushed.. or even allocated. This is where things are getting into trouble I believe. I'm not sure how each compilor handles the local variable situation. My guess is that VC++ pops passed data off on it's calling side.. So I have to hunt down that.. Fffft

that still doesn't fix the problem of namely conventions.. which can't be resolved with BCB unless I can change how the names of the procedures are stored in the DLL.

The frustrating thing is _cdecl is supposed to export using the _<name> convention .. but it doesn't look like it does that (wrinkles brow) at all in VC++.

I think I'll need to find a way to edit the exported functions or map them acordingly. Then it should work fine.. unfortunately I have to find a way to export the functions without names with proceeding underscores.

Cyb

BCB fix for making your own plugins

I've found a solution and it works.. surprise..
here is how to use BCB to make a N64 plugin...
1: Don't change the macros.. it's not necessary
2: after you compile your DLL for the first time with ALL of the functions defined (this is mandatory) at the command prompt do
IMPDEF {DLLNAME} {DLLNAME}
3: In the project in BCB add to the project and type in *.def ..
{DLLNAME}.def should show up. Click this and click OK.
4: for each _{function} change it to {function} = _{function} for each function that is exported in the DLL.
5: recompile.. now you have 2 aliases in the DLL for each function that is used by the emulator. That's it.. believe it or not.

Your DLL will work.. granted it's not as easy as using VC++ but it does allow one to use BCB

Cyb

N-Rage said:

I searched the Documentation cause this got me interested.

actually, the funny thing is that the Docu of Visualstudio states that cdecl Function will get a preceding _ in the functionname, yet it aint doing it. Aint finding any references on how to toggle this behaviour off or on.

One can only speculate for the Reason behind this *cough* damn bastards *cough*

PS. stdcall would be renaming the function to _function@bytesofarguments atleast to the Docs.

Click to expand...

MS is the king of incompatible adherence to standards they make.

But I was able to make the functions export properly, although I'm still working on getting the thing to import another DLL properly and test it Perhaps when I get it working things will be good.

I wonder do N64 games sample the position information during the vertical interrupt?

Cyb