Function (Procedure Entry Point) replacement list

[K4sum1]

If you've ever encountered "The procedure entry point x could not be located in the dynamic link library y", it could be possible to swap the missing function/procedure entry point with one that exists to make the application run.

To replace a function, you need CFF Explorer.
It will be faster to use Dependency Walker to figure out what all is missing instead of going one by one.
Open the application in CFF Explorer and click Import Directory.
Find the dll the error is from.
Find the function you want to replace.
Double click its name and replace it with the new function.
(Optional) Go to Rebuilder, untick Update PE Header and tick Update Checksum, then rebuild. (Required for drivers)
Save.

The list:

Multiple dlls:

• anything2 (IsWow64Process2 for example) can have the 2 removed, or replaced with A or (Ex)W and likely work
  (Anywhere from 10+ to XP and maybe earlier compatibility)

• Most anythingEx functions have alternatives, can be as simple as removing the Ex or as complex as K32GetModuleFileNameExA > GetModuleFileNameA.
  (Anywhere from 10+ to XP and maybe earlier compatibility)

advapi32.dll

• CredReadA/CredWriteA > CredFree
  (XP+ -> 2000 (extended kernel) compatibility)

cfgmgr32.dll:

• CM_Register_Notification > CMP_RegisterNotification
  (8+ -> XP compatibility)

kernel32.dll:

• CopyFile2 > CopyFileW
  (8+ -> XP compatibility)

• K32EnumProcessModules > GetProcAddress
  (7+ -> XP compatibility)

• K32GetModuleFileNameExA > GetModuleFileNameA
  (7+ -> XP compatibility)

• LoadPackagedLibrary > LoadLibraryExW
  (8+ -> XP compatibility)

ndis.sys

• NdisSetCoalescableTimerObject > NdisSetTimerObject
  (7+ -> Vista (RTM) compatibility)

ntdll.dll

• NtReleaseKeyedEvent > NtReleaseSemaphore
  (XP+ -> 2000 (extended kernel) compatibility)

• NtWaitForKeyedEvent > NtWaitHighEventPair
  (XP+ -> 2000 (extended kernel) compatibility)

ntoskrnl.exe

• anything_s (memcpy_s for example) can have the _s removed and likely work
  (7+(?) -> XP compatibility(?))

• KeQueryLogicalProcessorRelationship > KeQueryMaximumProcessorCount
  (7+ -> Vista compatibility)

• strnlen > strlen
  (7+ -> XP compatibility(?))

powrprof.dll

• PowerDeterminePlatformRoleEx > PowerDeterminePlatformRole
  (8+ -> Vista compatibility)

This list is nowhere near complete and there are many other functions that could be added. If you know or find any, please let me know and I will add them.

[265 993 303]

x86 typically has the function arguments passed right to left to the stack, so that the first parameter is at the top, and as such, replacing new function by old Win32 function will make it read the parameters from the stack as well. However, the problematic cases occur when the substituted function doesn't do what was originally intended with the arguments of the new function. In those cases, this function replacement method won't work.

What about more sophisticated replacements, such as by compiling a custom implementation of a newer Windows function in Digital Mars C++ and replacing the Windows dependency of the function in the program with the new implementation? (for instance by implementing Windows cryptographic functions in terms of mbedtls library functions) After such a custom implementation is made for each function and compiled, how would that be incorporated into the programs that have dependencies on the Windows version of that function?

[K4sum1]

I don't know. I've only made this post going by replacements I've been able to use in the past.