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