-1

Are there any Windows API calls that will accurately tell me whether a .dll contains a procedure?

I know about kernel32.dll's LoadLibraryA, which (if successful) returns a handle to a specified procedure [library], or (if unsuccessful) returns 0 and leaves a number on GetLastError. Unfortunately, when I ask LoadLibraryA to tell me the handle for a procedure (such as LoadLibraryA), it returns 0, and sets GetLastError to 126. Obviously, LoadLibraryA was in kernel32.dll, but it could not find itself!

[oops -- this was a bug. LoadLibraryA works fine when I ask for the handle for kernel32.dll, instead of LoadLibraryA. ]

I want my program to be able to detect whether a procedure is available at run-time. I do not want to include any other software, such as from nirsoft or Visual Studio. Can this be done using just the Windows API?

I am running Windows 10. The software I am writing uses the 32-bit Ascii versions of the Windows API calls. The software will do its best to run on any NT-style windows from Windows NT through Windows 10, including WINE. Some of these versions do not include particular procedures, and I want to be able to detect and work around such problems.

Jasper
  • 409
  • 4
  • 17
  • A similar question: http://stackoverflow.com/questions/1128150/win32-api-to-enumerate-dll-export-functions – Jasper Mar 09 '17 at 20:37

1 Answers1

3

This is the true and trusted sequence:

You have to consider that in a 64 bit process (and specially on a WoW64 process as yours) there is a lot of thunking and redirecting going on behind the scenes, and also there is 'magic' going on with regard to ASCII vs. Unicode function versions (xxA vs. xxW). So I would take failure to 'find' LoadLibraryA in kernel32.dll on Windows 10 with a big grain of salt.

If you want to go a different route you would have to crack the PE and read the content yourself. Not impossible, read this 23 years old article that is still relevant: Peering Inside the PE: A Tour of the Win32 Portable Executable File Format. There are tools that can help you like dumpbin, but I for one would not do that. I would trust LoadLibrary + GetProcAddress, that is the way.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
  • Bingo! I had been doing this (and it worked), but then I mistakenly changed the LoadLibrary call to look for the procedure name. I changed it back to looking for the .dll, and now it works again. – Jasper Mar 09 '17 at 20:20