WINAPI, SHSTDAPI etc

[jj2007]

I tried to create a list of Windows APIs and their arguments from the header files in %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Include\*.h

Parsing 1370+ files is not trivial, at present the attached proggie finds 8,600 different APIs. My code looks for the keywords WINAPI and SHSTDAPI, they seem to cover most needs.

I guess I'm not the first one who tries this, therefore my question: What other keywords are universal enough to extract APIs from the header files?

[dedndave]

seems like 10 million   :redface:

[hutch--]

 

Perhaps not that many but the problem is the C #define statements so you get HANDLE as DWORD, POINTER as DWORD etc .... Ther are at least hundreds of these defines in the entire SDK header files and they are often nested in other include files. You basically need a C compiler front end to do them properly.

[dedndave]

if you want a list of functions, wouldn't it be simpler to get the exports from the DLL's
i mean there are only so many DLL's, and they export mostly functions
and - it might be easier to tell a function from data
no mucking around with constants, macros, and other types of defines

[jj2007]

if you want a list of functions, wouldn't it be simpler to get the exports from the DLL's

Sure, that's possible, but you wouldn't see the descriptive names of parameters...

@=_hread
_hread(
__in HFILE hFile,
__out_bcount_part(lBytes,
return) LPVOID lpBuffer,
__in long lBytes )
[WinBase.h]
...
@=ZombifyActCtx
ZombifyActCtx(
__inout HANDLE hActCtx )
[WinBase.h]

[dedndave]

maybe some sort of hybrid operation...
get the function names from the DLL's
then, get the other stuff from the includes
you have the name of the function - you don't really care about it's type name

just spit-balling, here   :P

[Zen]

JOCHEN,   

Parsing 1370+ files is not trivial, at present the attached proggie finds 8,600 different APIs,...

Ahhh,...HAH !!! This is clearly a NON-CRAP concept,...
If it was me,...I would have outsourced the actual work,...

This might help: Microsoft-Specific Modifiers
...And, of course,...there's always this: C++ Language Reference

As you are by now aware,... it's not quite that easy. Much of the Win32 API was written in C,...and, like HUTCH mentioned,...it's the defines that you want to locate,...and they're scattered randomly through-out the windows.h includes

[Magnum]

Zen,

All those header files in every nook and cranny is a big reason I stopped using C code.

Seemed like there were multiple versions of many headers, all with the same name.

Andy

[dedndave]

just be glad they don't have a half-dozen different memory models, like the old days   :P

[jj2007]

This might help: Microsoft-Specific Modifiers

Yes, that is a good starting point :icon14:

But it leads straight to WINAPI (WinDef.h):

#define CALLBACK    __stdcall
#define WINAPI      __stdcall
#define WINAPIV     __cdecl
#define APIENTRY    WINAPI
#define APIPRIVATE  __stdcall
#define PASCAL      __stdcall

The other one is in ShellApi.h:

#ifndef SHSTDAPI
#if !defined(_SHELL32_)
#define SHSTDAPI          EXTERN_C DECLSPEC_IMPORT HRESULT STDAPICALLTYPE
#define SHSTDAPI_(type)   EXTERN_C DECLSPEC_IMPORT type STDAPICALLTYPE
#else
#define SHSTDAPI          STDAPI
#define SHSTDAPI_(type)   STDAPI_(type)
#endif
#endif // SHSTDAPI

Meaning "if SHSTDAPI is already defined, then redefine it as STDAPI", which in turn is (BaseTyps.h)
EXTERN_C HRESULT STDAPICALLTYPE, which in turn means
EXTERN_C HRESULT __stdcall

Holy crap

[GoneFishing]

For COM related stuff you may  try any of these keywords :

• HRESULT
• virtual
• STDMETHOD

[jj2007]

HRESULT is a bit too generic, but virtual and STDMETHOD look promising :t

[GoneFishing]

HRESULT is a bit too generic, but virtual and STDMETHOD look promising :t

Yes, I agree with you but all those three keywords often come together :
output from  find "HRESULT" *.h command (%CD% = D:\Program Files\Microsoft SDKs\Windows\v7.0A\Include)

        ... ... ...
        virtual HRESULT STDMETHODCALLTYPE GetRecordDescriptorByTag(
        virtual HRESULT STDMETHODCALLTYPE GetCountOfTableDescriptors(
        virtual HRESULT STDMETHODCALLTYPE GetTableDescriptorByIndex(
        virtual HRESULT STDMETHODCALLTYPE GetTableDescriptorByTag(
        HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
        HRESULT ( STDMETHODCALLTYPE *Initialize )(
        HRESULT ( STDMETHODCALLTYPE *GetVersionNumber )(
        HRESULT ( STDMETHODCALLTYPE *GetTransportStreamId )(
        ... ... ...
       

[japheth]

#ifndef SHSTDAPI
#if !defined(_SHELL32_)
#define SHSTDAPI          EXTERN_C DECLSPEC_IMPORT HRESULT STDAPICALLTYPE
#define SHSTDAPI_(type)   EXTERN_C DECLSPEC_IMPORT type STDAPICALLTYPE
#else
#define SHSTDAPI          STDAPI
#define SHSTDAPI_(type)   STDAPI_(type)
#endif
#endif // SHSTDAPI

Meaning "if SHSTDAPI is already defined, then redefine it as STDAPI", which in turn is (BaseTyps.h)
EXTERN_C HRESULT STDAPICALLTYPE, which in turn means
EXTERN_C HRESULT __stdcall

Holy crap

Actually, it's not that hard to understand the intention behind the definition. The outer #if block just avoids duplicate declarations.

The inner block:

Code Select Expand


#if !defined(_SHELL32_)
#define SHSTDAPI          EXTERN_C DECLSPEC_IMPORT HRESULT STDAPICALLTYPE
#define SHSTDAPI_(type)   EXTERN_C DECLSPEC_IMPORT type STDAPICALLTYPE
#else
#define SHSTDAPI          STDAPI
#define SHSTDAPI_(type)   STDAPI_(type)
#endif


defines the calling convention when a) the API is called as an external dll or b) statically.

I guess b) is only useful for MS-internal coders ( who have to maintain the Windows/Internet Explorer ). Or perhaps, to support compilers that won't understand the __dllimport extension.

[GoneFishing]

That's what I've found with find "void" *.h:

---------- SHLWAPI.H
// Users of this header may define any number of these constants to avoid ...
... ... ...
LWSTDAPI_(void)     PathRemoveArgsA(__inout LPSTR pszPath);
LWSTDAPI_(void)     PathRemoveArgsW(__inout LPWSTR pszPath);
LWSTDAPI_(void)     PathRemoveBlanksA(__inout LPSTR pszPath);