I’m writing a wrapper to make FMOD functions available from Python. I’m using the incredibly wonderful ctypes package to do it all from within Python. This is when I discovered that the function names in the dll have been mangled. I can deal with it but it seems strange to me. For example the function FSOUND_Init is in the dll as _FSOUND_Init@12. Why the strange names?
I wrote a little script to bash the fmod.bas file (which lists the usual name and the mangled name) into Python code that gets access to the right functions. So, my wrapper is working but I wonder why I had to do that?
Thanks for the fine library,
Yep, FMOD is __stdcall all right. Compiled in VC++. The mangled function names are all because [i:3gu5fwf1]someone[/i:3gu5fwf1] (I won’t mention names, hehe) was too lazy to make a .def file for FMOD, and now it’s too late to unmangle the functions in 3.x because it would break compatibility…
No Brett, I don’t mean to bash you, so don’t bust a cap in my ass (I always wanted to say that, lol)! I’m just hinting that perhaps you should add a .def file to the FMOD4 project tree in VC++. The layout is simple…
Yep, that’s all you need–just the function names and an EXPORTS line at the tippy-top of the .def file. It’ll prevent the names from being mangled no matter what calling convention they use (so long as the .def file is inserted somewhere in the VC++ project tree anyway, and you still have to use extern “C”), and should make it tons easier to port the library over to other Windows compilers, too… then again, maybe you know all about .def files already…
As Mad suggests, the 12 bytes means it expects 12 bytes worth of parameters on the stack.
The odd naming convention indicates that it is using the stdcall calling convention rather than cdecl or fastcall convention. Essentially this means the following:
It expects arguments to be pushed onto the stack from right to left (like cdecl)
It will clean up the stack itself (unlike cdecl)
- Nick answered 14 years ago
Please login first to submit.