What's the easiest way in C++ to get an ordinal of an exported dll function, given its name? (Looking for a way which doesn't invlove parsing the IATs myself...)
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- How to know full paths to DLL's from .csproj f
- thread_local variables initialization
相关文章
- vs2017wpf项目引用dll的路径不正确的问题
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
- What exactly do pointers store? (C++)
- Converting glm::lookat matrix to quaternion and ba
An ugly way would be to run a system call with a dumpbin command and parse the output. But that has about the same elegance as a bull in the proverbial china shop.
dumpbin /exports c:\windows\system32\user32.dll | grep FunctionOfInterest
Otherwise, you could write a simple loop calling GetProcAddress with ordinals (passed in the low two bytes of the name parameter). When the function pointer matches the pointer returned when passing the actual name, then you are done.
Here is the basic idea without error checking:
I can't think of any terribly simple way to do what you want. You have at least a couple of options that I can see:
The main problem I see with the first option is that you don't know how many ordinals to try (there can be gaps in the ordinal numbers, so counting on
GetProcAddress
returning NULL to signal the end won't work). It's also somewhat inefficient because it requires making a lot of Win32 calls repeatedly and it basically amounts to a linear search of the export address table. Pretty inelegant, indeed.As an alternative, you can search the NPT and use the resultant index into the EOT to obtain an ordinal. This is a more elegant approach because it arrives at the ordinal in the most direct way possible (it is actually the same method the dynamic linker uses to resolve export names to their addresses). Also, because the NPT is lexically sorted, it's possible to do a binary search which is obviously preferable to the other method's linear search. In fact, a single call to
GetProcOrdinal
implemented with this method should be slightly faster than just one call toGetProcAddress
. Perhaps more importantly, this method doesn't depend on any unknowns (i.e. number of ordinals). The disadvantage to this method is that it's not as simple as the other method.You could use the Debug Help Library to help avoid doing some of the parsing of the PE file image (this is what I did initially), but it turns out that parsing the required parts of the PE image is not that difficult. I think avoiding the dependency on the Debug Help Library is worth the minimal extra effort required to parse the PE image headers.
Getting down to business, here is an example implementation in C:
GetProcOrdinal
is where the interesting bits happen. The code is hopefully fairly self-explanatory; however, to fully understand it may require a bit of knowledge about the PE file format, which I'm not about to get into here (there's plenty of info on the web about it).FindNptProc
is simply a convenience function that does the binary search of the NPT.GetExportDirectoryTable
is another convenience function that parses the PE headers to locate the export directory table.The code above compiles cleanly for me under Visual Studio 2008 and Windows XP (SP3), but YMMV. I'm not really a Windows guy*, so this might not be the cleanest code portability-wise (in terms of different versions of Windows). As usual, this code is provided "as is" with no warranty of any kind ;)
*Yes, in case you're wondering, I do still feel kind of dirty after writing all that Microsoft-style Windows code.