ONE thing i need though are the raw-physical sugnatures of this 20 or something winapi calls I use (like the one above) this is the signatures

after unfolding al macros - i do not know from where to get this and do not risk the mistakes in types (becouse if i do mistake i will have a runtime corruption) :/ i would like to avoid this

They are all in the Windows headers that ship with any SDK. What do you think Windows.h is?

I'm obviously missing something here. You seem to think defining these manually rather than including the headers is affecting the dissassembly or something? There is no difference to the compiler whether you manually declare a function or include a header - #include is literally just text-replace by the preprocessor - so could you explain again why you are doing this?

If its just for fun or out of interest, good luck to you. For anything else it is just lunacy.

its for fun, also for some learning purposes (related to disasembly realm ,

thats why i used the word, when you trace api calls they are raw types

off-skined from define macros and typedefs to raw c types - i need some reference on an easy way for getting to know how such off-skined win api calls look like)

The macro forms are the actual API forms :)

Most implementation names are exactly identical with the API, only some come in ANSI and Unicode forms, denoted by ending in either a capital A or W (for "wide"). Usually they are accessed though an indirect jump via the import address table, since the virtual address is not known before the DLL is loaded, and not rarely several public API functions wrap one "Nt" function with a somewhat similar name. So prepare for a bit of a surprise when you debug/disassemble these.

A few API functions, such as GetCurrentThread(), are not functions at all but resolve to integer literals (-1) which serve as "pseudohandles". They only look like you're calling a function in source code, and you will not be able to find the function in any library. Nor will you be able to find the corresponding code, obviously.

Yet other API functions (e.g. InterlockedCompareExchange) are wrappers around compiler intrinsics that produce special instructions.

off-skined from define macros and typedefs to raw c types - i need some reference on an easy way for getting to know how such off-skined win api calls look like)

If you're using GCC on MINGW, you can run the proprocessor over your sources files containing the standard headers and seet what the actual C (or C++) code fed to the compiler looks like. The easiest way to do that is to add the -save-temps switch to the command line along with all the other options, and example the resulting .i (or .ii) file.

will luk on that, tnx for hint (Im new to mingw)

The macro forms are the actual API forms

Most implementation names are exactly identical with the API, only some come in ANSI and Unicode forms, denoted by ending in either a capital A or W (for "wide"). Usually they are accessed though an indirect jump via the import address table, since the virtual address is not known before the DLL is loaded, and not rarely several public API functions wrap one "Nt" function with a somewhat similar name. So prepare for a bit of a surprise when you debug/disassemble these.

A few API functions, such as GetCurrentThread(), are not functions at all but resolve to integer literals (-1) which serve as "pseudohandles". They only look like you're calling a function in source code, and you will not be able to find the function in any library. Nor will you be able to find the corresponding code, obviously.

Yet other API functions (e.g. InterlockedCompareExchange) are wrappers around compiler intrinsics that produce special instructions.

well, interesting

but i wonder how api call can produce intrinsics are the intrinsics

'manageable' (intrinsic as defined as some more than inline code,

some task recognized by compiler that could be managed more flexible

than even inline code - Im sorry if they are not yet quite manegeable by

coders .. (because it seems that they are not yet quite manageable and probably maybe they should)... tjis is a digression, maybe tou mean

here inline asm lines

Implemantation-defined. For example like this:

static __inline__ PVOID GetCurrentFiber(void)
{
    void* ret;
    __asm__ __volatile__ (
    "mov{l}    {%%fs:0x10,%0|%0,%%fs:0x10}"
    : "=r" (ret) /* allow use of reg eax,ebx,ecx,edx,esi,edi */
    );
    return ret;
}

This isn't precisely an intrinsic but rather inline assembly, but you get the idea.