Winamp Plugin - Access Violation (plugin dll created with Pelles C)

[viulian]

Hi!

I'm new to this forum, so please excuse me if I posted in the wrong board or if what I'm reporting is not a Pelles C bug.

Here's what happened:

I decided to use Pelles C to write an output plugin for Winamp (5.X). I have downloaded WinAMP SDK 5.0.2 from here: http://www.winamp.com/development/sdk and I use the latest WinAMP (free eddition, the one with installer smaller than 2Mb).

The SDK contains a output plugin example in the folder out_raw.
I imported in in Pelles C (had to set up include/libs directory, and add a couple of libs from Pelles C to the Linker). I've successfully compiled the code, deployed the out_raw.dll (must be named with out_ in front, otherwise plugin won't be even checked) and made Winamp use it.

Whenever I try to press Play -> winamp crashes.
However, If I compile the same code with LCC -> plugin works, winamp works.

Also, I have created my empty output plugin, which defines all the methods that winamp has to call, but all those methods only write to a log file.
When pressing Play, the .dll obtained from Pelles C is only able to execute the setvolume(int) method, then Winamp crashes. In LCC this doesn't happen, and it works.

I know that DLL is generated successfully, the About button works (that is the "void about()" method from plugin DLL gets called no matter how much I press About in Winamp) but when I decide to play a file, winamp is only able to call the setvolume() method and then crashes.

I do not have any other tools to investigate what it actually happens and what's wrong...

I am willing to test the code and switch back to Pelles later on I like it better than LCC.
(if you guys want to test LCC with the out_raw plugin, please make sure you select "Do not include underscores in dll exports)" in Project->Configuration.

[frankie]

This is not exactly a bug, but as I suspect the problem is due again to the incompatibility between PellesC I/O subsystem and M$.
Try to recompile your library with the following variations:
  1) In project options -> compiler check the "omit default libraries name"
  2) In the linker options add "msvcrt.lib" to the linker stream
This will force linking with M$ runtime.
Now recompile and test the plugin.
Please let me know if this works.

[viulian]

Thanks for the answer.

I have tested as you said, but it still fails.

Here are the corresponding lines from the .ppj file:

Code: [Select]

CCFLAGS =  -Tx86-coff -Ot -W1 -Gz -Ze -Zl #
ASFLAGS =  -AIA32 -Gz #
RCFLAGS =  #
LINKFLAGS =  -subsystem:windows -machine:ix86 -dll kernel32.lib user32.lib gdi32.lib comctl32.lib msvcrt.lib advapi32.lib delayimp.lib shell32.lib comdlg32.lib msvcrt.lib#
INCLUDE = C:\Program Files\PellesC\Include;C:\Program Files\PellesC\Include\Win;C:\Program Files\PellesC\Include\Win\gl;D:\PellesC\mgui\include#
LIB = C:\Program Files\PellesC\Lib;C:\Program Files\PellesC\Lib\Win#
(Please ignore the mgui include, I have tried to use that lib too but failed  )

Anyway, I have attached my small plugin. If you have WinAMP installed, you can use the copy.bat file in the project directory to copy the .dll to the destination directory. I rename it in the process.. (i don't think it should cause any problems though).

The path I used for project was

Code: [Select]

D:\PellesC\Projects\RemoWamp\ (so you should unpack the directory in the zip in D:\PellesC\Projects.

[Pelle]

It has nothing to do with I/O. Appears to work fine here, provided I fix all the warnings and the calling convention.

[frankie]

Yes the problem is the calling convention.
You have to select the __cdecl calling convention from the project compiler options.
Infact the routines in the "Out_Module" structure are __cdecl. This maybe is due to the fact that M$ doesn't convert all calls to __stdcall when windows program is selected.

[viulian]

Well, yup - it works for me too with __cdecl - even I don't think this is a beginner question  ..

I mean, we're on Windows, how come the M$ default (which is __cdecl per this article: http://support.microsoft.com/kb/100832 ) isn't the default  ?

[severach]

An even better question. Why doesn't the SDK writer put __cdecl before each function that is required to be that way to ensure that no matter what the defaults are the code works correctly?

[frankie]

Unfortunately most of free code and libraries generally come with M$VC project, and since M$VC doesn't default to __stdcall when compiling something different from a console app they doesn't feel obliged to add the call convention specifier (the same problem is present for SQLITE, SDL, etc, etc.)
Maybe it would be better if the next release of the compiler doesn't force __stdcall convention and  follows more strictly M$VC behaviour.