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