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?
seems like 10 million :redface:
:biggrin:
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.
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
Quote from: dedndave on September 17, 2013, 08:37:18 PM
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]
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
JOCHEN,
Quote from: JOCHENParsing 1370+ files is not trivial, at present the attached proggie finds 8,600 different APIs,...
Ahhh,...HAH !!! This is clearly a NON-CRAP concept,...:dazzled:
If it was me,...I would have outsourced the actual work,...
This might help: Microsoft-Specific Modifiers (http://msdn.microsoft.com/en-us/library/6bh0054z.aspx)
...And, of course,...there's always this: C++ Language Reference (http://msdn.microsoft.com/en-us/library/3bstk3k5.aspx)
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 (http://en.wikipedia.org/wiki/Windows.h)
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
just be glad they don't have a half-dozen different memory models, like the old days :P
Quote from: Zen on September 18, 2013, 06:09:52 AM
This might help: Microsoft-Specific Modifiers (http://msdn.microsoft.com/en-us/library/6bh0054z.aspx)
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 __stdcallThe 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 // SHSTDAPIMeaning "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 :eusa_boohoo:
For COM related stuff you may try any of these keywords :
HRESULT is a bit too generic, but virtual and STDMETHOD look promising :t
Quote from: jj2007 on September 18, 2013, 09:13:38 PM
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)
Quote
... ... ...
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 )(
... ... ...
Quote from: jj2007 on September 18, 2013, 12:18:27 PM
#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 :eusa_boohoo:
Actually, it's not that hard to understand the intention behind the definition. The outer #if block just avoids duplicate declarations.
The inner block:
#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.
That's what I've found with find "void" *.h:
Quote
---------- 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);
Nice :t
With LWSTDAPI_, 21000+ are found.
JOCHEN,
Weirdly enough,...I dreamed about this question last night,...as I was falling asleep,... :icon_eek:
In my dream,...I did everything the hard way. I copied all those windows headers to a new directory (so as to not inadvertently write something trivial to the source files,...this can be a horror,...trying to find the error later). Then, I inspected all 1370+ files (the dream turned into a nightmare at that point, and, I woke up screaming !).
...Then when I fell back asleep, I wrote my assembly program (you know I worship code bloat) so that it makes TWO scans of every one of those windows headers,...the first scan to find the keyword (or modifier) that indicates the beginning of the API prototype,...and, the second scan to actually make the API listing. :icon_rolleyes:
...Anyway,...I often try to find the most reliable way to accomplish something, even if it takes an extraordinary amount of time.
But,...I think you are doing it the most efficient way.
When do we get to see your complete assembly code ???
ToutEnMasm wrote a SDK translator if I am not wrong.
I can't really answer your question, as I did it the hard way, checking for everything else, and if not processed, then checking for possible Function (...);
However, running 7.1 through my xlatHinc (functions show up as comments in my INC output since GoAsm does not use LIBs or PROTO or EXTERN), then passing the resulting files into EmEditor with a command line search for ";" I get closer to 111,081 which includes each interface function. The resulting EmEditor text file shows the source file, line number, and line contents, for a total of ~15MB (taking out the file and line info, leaving just the functions and parameter names, would be about half that).
...
Hi Zen, Erol, Wayne and Vertograd,
Thanks for gently pulling my leg ;)
I knew it had been done before... xlatHinc looks very mature, congrats to Wayne.
What I want is not that serious, just a quick and dirty list of APIs with their parameters, for use in my editor. For my needs, Hutch' Masm32 includes are more than sufficient, but I never can remember the number and positions of those bloody ShellExecute invoke parameters, so I thought a tooltip would be handy ;-)
Quote from: Zen on September 19, 2013, 03:51:16 AM
When do we get to see your complete assembly code ???
Attached. Thanks for all the helpful remarks :icon14:
Thanks, and nicely done too for quick and dirty (too much time in header files can render one dysfunctional :-).
If you were aiming for one parameter per line, just a bit more fine tuning with leading /*...*/ or __RPC or of the form __some_annotation(... , ...). With the exception of this last one, it may be easier to use the comma as the line separator.
Quote from: wjr on September 19, 2013, 10:37:08 AM
Thanks, and nicely done too for quick and dirty
Thanks, Wayne ;-)
I've picked up an idea of Dave: get the DLL exports first. Here is a first attempt, it creates a text file of exports from the System32 folder.
i like it :t
XP MCE2005, SP3
i got about 92,300 lines of text :P
78,600 for Win7-32 (no word wrap).
75*CreateInstance, 715*DllCanUnloadNow - some are quite repetitive.
Attached version 2a without duplicates. Win XP SP3:
1410 dll files with 43029 calls written to DllSys32.txt
P.S.: [?rbegin@?$list@VFilePathComponent@iop@@V?$allocator@VFilePathComponent@iop@@@std@@@std@@QBE?A
V?$reverse_bidirectional_iterator@Vconst_iterator@?$list@VFilePathComponent@iop@@V?$allocator@
VFilePathComponent@iop@@@std@@@std@@VFilePathComponent@iop@@ABV45@PBV45@H@2@XZ] is 265 chars long... guess for which company the authors of that DLL are working ;)