when you need to use a function you include a header file but wheres the function code is defined?
Dave, the code lives in the various and many DLL files in your Windows\system32 directory.
The actual code that implements the Win-32 API are defined in various DLLs on your system. These DLLs have names like kernel32.dll, comctl32.dll etc. You will find them in C:\Windows\System32.
What generally happens is that you link your code with kernel32.lib etc. that have a little code to dynamically load the DLLs when your program starts. This allows Win32 API functions to directly call into the DLLS.
Well as explained above you are in the hands of microsoft.
You can always look at the msdn http://msdn.microsoft.com.
For most API functions you can find some information at the bottom.
For most function you get from there:
Minimum supported client
Minimum supported server
Header
Library
DLL
Unicode and ANSI names
Related
I'm trying to load GetStagedPackageOrigin WinAPI dynamically using LoadLibrary and GetProcAddress so that my app could also run on Windows 7. So according to documentation that API is supposed to be imported from Kernel32.dll, but in reality (in my Windows 10 v1709) it is not.
I was able to find it in Kernelbase.dll instead:
So I'm wondering, can I dynamically load it from Kernelbase.dll instead?
this definitely bug in documentation. if we call (test on win10)
GetProcAddress(GetModuleHandle(L"kernel32"), "GetStagedPackageOrigin");
we got 0 - this mean that this api not exported or forwarded from kernel32.dll
but if call
GetProcAddress(GetModuleHandle(L"kernelbase"), "GetStagedPackageOrigin");
we got it real address.
next - when I search in latest sdk libs - I not found GetStagedPackageOrigin in kernel32.lib too. only one lib containing this symbol - OneCoreUap.lib umbrella library - and marked it exported from api-ms-win-appmodel-runtime-l1-1-1.dll .this dll resolved in runtime to kernel.appcore.dll. implementation - simply jump to kernelbase.GetStagedPackageOrigin
so most correct I think try import this api from api-ms-win-appmodel-runtime-l1-1-1.dll
very strange appraisal for my look :) with so simply question
anybody can easy test this simply code on win8.1, win10
GetProcAddress(LoadLibrary(L"kernel32"), "GetStagedPackageOrigin");//fail
GetProcAddress(LoadLibrary(L"kernelbase"), "GetStagedPackageOrigin");//ok
GetProcAddress(LoadLibrary(L"kernel.appcore.dll"), "GetStagedPackageOrigin");//ok
GetProcAddress(LoadLibrary(L"api-ms-win-appmodel-runtime-l1-1-1"), "GetStagedPackageOrigin");//ok
and view that by fact GetStagedPackageOrigin not exported from kernel32.dll. this is simply fact.
about lib file - i have no win8.1 sdk under hand, but i search this api in 10.x sdk version through lib files - and i found that this api implemented only in OneCoreUap.lib (not this symbol in kernel32.lib). and OneCoreUap.lib say that this api ix exported by api-ms-win-appmodel-runtime-l1-1-1.dll. so if we link with this lib - we by fact will be try import this api with api-ms-win-appmodel-runtime-l1-1-1.dll (this name will be hardcoded in our pe file). so we need or link with OneCoreUap.lib (i advice add it at the end of lib list) or direct call GetProcAddress(LoadLibrary(L"api-ms-win-appmodel-runtime-l1-1-1"), "GetStagedPackageOrigin");.
and can note that which header files use - absolute not related to question at all. if somebody not agree with this - can i ask - which lib need use - please concrete answer. and from which dll - please concrete dll name application will be use when use this lib (this dll name will be hardcoded in pe import table)
I would certainly not bind it to the versioned api-ms-win-appmodel-runtime-l1-1-1.dll , but the two generic ones. kernelbase or kernel.appcore.
The versions are visual studio/ucrt version specific.
I have a TCL application that is intented to run on Windows only and uses twapi to access some Windows-specific functions.
Now I need to call some C function that are in a custom DLL.
I know I can load the DLL with twapi::load_library (should be the same as LoadLibraryEx()) but I can't understand how to call a function within the DLL itself!
What did I miss?
I would prefer to avoid other dependencies (like critcl, for example) and to avoid to have to transform the current dll in a tcl extension (e.g. via SWIG) so a twapi only solution would be really helpful!
TWAPI doesn't seem to provide any public binding of GetProcAddress (the Windows API function for getting from the name to the address of a function in a DLL).
Use ffidl for simple APIs (i.e., where there are no callbacks) or critcl (for all kinds of APIs, including those with callbacks, because it can do much more extensive code generation; more effort to use though).
twapi's load_library command is there for manipulating the resources in a dll (string tables, icon etc.). It's not intended for calling functions in the dll since that, as Donal points out, requires marshalling and some code generation.
Looks like you'll have to use ffidl to do the job.
When one should implicitly or explicitly link to a DLL and what are common practices or pitfalls?
It is fairly rare to explicitly link a DLL. Mostly because it is painful and error prone. You need to write a function pointer declaration for the exported function and get the LoadLibrary + GetProcAddress + FreeLibrary code right. You'd do so only if you need a runtime dependency on a plug-in style DLL or want to select from a set of DLLs based on configuration. Or to deal with versioning, an API function that's only available on later versions of Windows for example. Explicit linking is the default for COM and .NET DLLs.
More background info in this MSDN Library article.
I'm assuming you refer to linking using a .lib vs loading a DLL dynamically using LoadLibrary().
Loading a DLL statically by linking to its .lib is generally safer. The linking stage checks that all the entry points exist in compile time and there is no chance you'll load a DLL that doesn't have the function you're expecting. It is also easier not to have to use GetProcAddress().
So generally you should use dynamic loading only when it is absolutely required.
I agree with other who answered you already (Hans Passant and shoosh). I want add only two things:
1) One common scenario when you have to use LoadLibrary and GetProcAddress is the following: you want use some new API existing in new versions of Windows only, but the API are not critical in your application. So you test with LoadLibrary and GetProcAddress whether the function which you need exist, and use it in the case. What your program do if the functions not exist depend total from your implementation.
2) There are one important options which you not included in your question: delayed loading of DLLs. In this case the operating system will load the DLL when one of its functions is called and not at the application start. It allows to use import libraries (.lib files) in some scenarios where explicitly linking should be used at the first look. Moreover it improve the startup time of the applications and are wide used by Windows itself. So the way is also recommended.
I have a DLL that's compiled, and I don't have the source code for it anymore. The only thing I want from the DLL is the functions it provides, and how they are accessed, i.e. their signature.
How can I do this?
You can extract the following:
Metadata (all classes, methods, parameters, etc.) in case of a .NET Assembly. Use Reflector and ILDasm for this purpose.
Exportable functions in case of a native DLL. Use the dumpbin utility. There is also a professional tool called IDA. It's very powerful and is meant for iterative reverse-engineering.
Assuming I have a list of DLL's an executable loads, How do I get a list of all the functions defined by those DLL's?
EDIT: preferably without the use of GUI's or huge programs like Visual Studio
Thanks,
You're not saying if you want to do this from code or you're just looking for a utility. For the latter, try dumpbin.exe from the Windows SDK, for the former check out the psapi and or toolhelp APIs.
Microsoft Dependency Walker can also be used which is a single executable.