Which DLL has PathCchAppend?

Question

I'm trying to conditionally use (if available) the function PathCchAppend. I have got the function signature from header pathcch.h. However, when I try to get the address of function from SHLWAPI.DLL, it fails:

auto pca = GetProcAddress(GetModuleHandle(L"shlwapi.dll"), "PathCchAppend");

Using Depends, I saw that this function does not exist in this DLL (I'm on Windows 10). There doesn't exist any pathcch.dll and hence cannot load it either.

In which DLL this function is placed?

EDIT: Thanks to the answers. Here I found the names of DLL as is mentioned in the answers below:

https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-81-api-sets

Answer 1

You can use the DUMPBIN tool to extract this information from the .lib file:

dumpbin /headers /path/to/pathcch.lib

You then need to sift through the output to find the function in question. For instance, this is the output for an x64 version of the lib file:

  Version      : 0
  Machine      : 8664 (x64)
  TimeDateStamp: FFFFFFFF Sun Feb 07 06:28:15 2106
  SizeOfData   : 0000002E
  DLL name     : api-ms-win-core-path-l1-1-0.dll
  Symbol name  : PathCchAppend
  Type         : code
  Name type    : name
  Hint         : 5
  Name         : PathCchAppend

---

Regarding the comments about backwards and forwards compatibility of hard coding this DLL name, the .lib file hard codes the DLL name. So if you link to the function using the .lib file, then you are hard coding a dependency to that DLL. This binds Microsoft into a contract to continue exporting this function from this DLL in future releases of Windows. And so it is no more or less safe to link explicitly using LoadLibrary/GetProcAddress than it is to link implicitly using the .lib file from the SDK.

Answer 2

api-ms-win-core-path-l1-1-0.dll is not an actual DLL nor file on disk, instead it's some virtual name only, so that the loader is able to map requests to some disk on the file in the end. The extension DLL is used by convention or as a system requirement by the loader only, but doesn't imply any file as well.

You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.

https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names

So the real answer to the question is KernelBase.dll. That is important for use cases like mine, where I need to create a lib file based on an actual DLL, which is only possible with KernelBase.dll. MS maintains some additional docs making the underlying file of some API set available as well.