API declaration using #1 function names

[TTn]

Does anybody in here know how to find out the API function names that correspond to the "#1" style of the same function names?

I read that it's actually quicker to use the enumerated function name, but I can't seem to find a list of the corresponding function names.

I've been matching some API's by trial an error, but there must be some documentation on this, that will save me a whole lot of time.

Thanks

[RobDog888]

"#1" style? There is the EntryPoint function name and alias and wide and ansi. Those are all I have heard of.

[TTn]

"#1" style? There is the EntryPoint function name and alias and wide and ansi. Those are all I have heard of.

I'm gonna call it enumerated alias style, because it had no name where i read it.(Dan Appleman's guide to the aPI). He mentions a performance increase.
I've tested it, and sure enough it works. I assume that the numbers run in linear order from 1 to about 900+.

When you use the Alias you put: Alias "#162".
But you have to know what the 162 nd function name is, in order to know what params to use.

I was doing a brute search with user32, and placing objects in the params with Nothing as the param. For example:

Public Declare Function Function1 Lib "user32" Alias "#1"  (ByVal p1 As Object, ByVal p2 As Object, ByVal p3 As Object, ByVal p4 As Object, ByVal p5 As Object) As Int32

This returns a value, but I have no idea what function I'm calling.
So i dont recommend everyone try this, as it could cause unintended results.

[TTn]

Okay i found something.
It looks like they are called ordinal (#x).

Here is an interesting link explaining why they are not commonly known.

[RobDog888]

Oh interesting but that list would seem ungodly to create as there are something like 13K+ APIs up to and including Vista.

Hmm, seems that maybe its in the Hint column of Depends when you open one of the windows core dlls like user32.dll. Could be close but you may want to take a look at it.

[TTn]

Okay Ive opened the user32.dll with notepad and found an alphabetic list of function names. Some of which seem to be completely unique, and undocumented! Is this what you meant?
It maybe that these are listed in order of their ordinal representations.
I'll have to do some testing to see if they match up with the alphabetic order.

Thanks for pointing me towards the right direction.
I should of thought of that to begin with.

[RobDog888]

Well instead of using notepad, use the utility Dependancy Walker (Depends.exe) to open the user32.dll. It will show the heirarchy of API calls and the "Hint" column which has the numbers in it. I think the hint is referring to what you are looking for.

[TTn]

I just tried AttatchThreadInput, declared as the ordinal #12, and it works perfect!

Now the interesting part is to find out what the parameters are for those functions that I've never seen anywhere.

Okay thanks for the depends.exe tip.

[RobDog888]

Ok, after looking a bit more I think it goes like this...

For each Windows dll it will contain its own set of ordinal number "Hint"s. So #13 in user32.dll is AttachThreadInput but in NTDLL.dll its AlpcAdjustCompletionListConcurrencyCount.

Something to watch out for as I guess ordinal lists for each windows component dll will be necessary.

Can you find the arguments for the functions on MSDN? I would look there first.

[RobDog888]

Bah! Just realized we are looking at the ordinal numbers. The Hints are different numbers.

Hints
#12 - AttachThreadInput - User32.dll
#12 - AlpcMaxAllowedMessageLength - NTDLL.dll

Ordinals
#13 - AttachThreadInput - User32.dll
#22 - AlpcMaxAllowedMessageLength - NTDLL.dll

[TTn]

Yeah I realized that the numbers run for each dll.

Some of those functions don't seem to come up on msdn.
For example AllowForegroundActivation.

[TTn]

I found a couple links.

Here is a link that has a simplified list of the user32 and kernel32
User32
Kernel32

This link has the AllowForegroundActivation function, and it's param.
http://www.reactos.biz/generated/dox...2stubs_8c.html

[penagate]

Ordinals are very slightly faster to compile because the function table lookup in the linking stage is avoided. This doesn't affect compiled performance.

Since compilation speed is very rarely ever an issue, I recommend avoiding the use of ordinals simply for readability's sake.

If you want to increase the speed of calling a native API function, investigate using a type library (.tlb) instead. This is the most efficient method.

[schoolbusdriver]

A link for NTDLL.DLL NTinternals which I've found very useful. And of course Windows Internals if you want the book.