Windows API: Strange behaviour after calling GetModuleFileNameExA

Tobias Wassermann mail at tobias-wassermann.de
Tue Nov 27 21:58:36 PST 2007


The problem is:

EnumProcesses() and GetModuleFileNameExA() both are marked as extern "C" within the psapi.h - the difference is: EnumProcesses works and GetModuleFileNameExA() in D and with DMC seems to corrupt the stack. If I move the C-ported code to the Microsoft Visual C++ and compile it, it works fine.

On the other side: extern (C) within D is the only possibility to use for this two functions, if I use extern (Windows) I'll get linker errors (linker can not  find symbols _EnumProcesses at 12 and _GetModuleFileNameExA at 16).

With extern (Windows) it seems to be correct - remember: EnumProcesses() works fine, only GetModuleFileNameExA() causes the problem. 

Additional note: GetProcessImageFileNameA() (which could be an alternative to GetModuleFileNameExA()) causes the same problem.

Joel Lucsy Wrote:

> Regan Heath wrote:
> > I've just looked at the psapi.h header in my SDK I see:
> > 
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> > 
> > BOOL
> > WINAPI
> > EnumProcesses(
> >     DWORD * lpidProcess,
> >     DWORD   cb,
> >     DWORD * cbNeeded
> >     );
> > 
> > note the extern "C" there.  I believe that confirms it's C linkage and 
> > not Windows linkage.
> 
> Actually, the WINAPI is what sets STDCALL. I believe the extern "C" is 
> for telling the compiler how to mangle, or not mangle in this case, the 
> name of the function.
> 
> -- 
> Joel Lucsy
> "The dinosaurs became extinct because they didn't have a space program." 
> -- Larry Niven




More information about the Digitalmars-d mailing list