Heya, I'm currently working on a sound class DLL, which is finished [codewise] and I am about to test it. The project structure is as follows Audio Compiles to Audio.dll - statically linked with fmodvc.lib and dynamically with fmod.dll Lib Compiles to Audio.lib Audio_Test Compiles to Audio_Test.exe - statically linked with Lib and Dynamically with Audio.dll Now, all of the linking works, because I've used exactly the same codebase for linking [Lib and Audio_Test are almost identical to other projects that I've done similarly, so it's not the DLL loading/init code]. However, in the DLL Entry point, I call FSOUND_Init(44100,32,0) and it never returns. As soon as I take this line out, the audio dll works [as much as you'd expect an audio dll using fmod to work when fmod isn't...]. Otherwise, the dissasembly shows that the stack is pretty deep into DSound.dll after being pretty deep into FMod.dll, so the DLL is working. As soon as I make Audio compile to an exe [and add a respective WinMain], the FSOUND_Init works fine. I thought it might have been something to do with the [standard library]? version (in VC7), but Multithreaded Debug DLL doesn't do anything more than Multithreaded Debug. I'll try to post some code soon... Any ideas? CJM

Yes, you cannot call that init via a .dll (or to the best of my knowledge). Instead, the user must call it before they use any FMOD functions in the end product. I have made my own .dll engine, and I have learned, the hard way, that init functions such as that work best *not* in the .dll. Reason being is the .dll has its own memory and such. I'ts a long story, but for .dlls, you can't call memory modifying functions that you need in your program. This also means (which I also learned the hard way), passing char*'s won't work! You have to pass the char* to the .dll, then in the function that uses it, use some string copy, I used printf(), then use the variable. Its a pain and easy to forget to call it, but it is nevertheless necessay. Give it a try and let me know. Goodluck!

- Drew

Thanks Drew_Benton,

I was sort of scratching my head as to why that was happening, thanks for saving me a few hours of screwing around trying to see if there was a problem somewhere else. On a completely unrelated note, I set it to compile as a statically linked library, and [only had to comment out the dllmain function] had to move one line of code, but now it all works - though I still haven't tested it extensively, it's now compiling into the main project... maybe in the next version, I could put all FMod specific calls into the .lib and just have the file management routines in the .dll...

Anywho, I'm not sure how much of an effect it'd have, but rating++; Thanks for your help.

CJM

No problem!