Eclipse Community

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)

• It may be possible to replace a function with one even completely unrelated and still have the program work, like ResolveDelayLoadedAPI > ResolveLocaleName. This may not work in all cases.
  (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)

• GetCurrentThreadStackLimits > GetCurrentThread
  (8+ -> XP compatibility)

• GetDynamicTimeZoneInformation > GetTimeZoneInformation
  (Vista+ -> 2000 compatibility)

• GetSystemTimePreciseAsFileTime > GetSystemTimeAsFileTime
  (8+ -> 2000 compatibility)

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

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

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

• RaiseFailFastException > RaiseException
  (7+ -> XP compatibility)

• TryAcquireSRWLock*> AcquireSRWLock*
  (7+ -> Vista 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.

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?

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

At least in the case of Geometry Dash, I was able to replace the GetSystemTimePreciseAsFileTime function it called from Kernel32.dll with GetSystemTimeAsFileTime

Added, thank you.

Changing GetCurrentThreadStackLimits to GetCurrentThread (called from Kernel32.dll) gets klogg 22.06 (Qt5) running on Windows 7

Changing GetDynamicTimeZoneInformation to GetTimeZoneInformation (called from Kernel32.dll) gets the latest release of NXEngine-Evo running on Windows XP x64

According to https://forum.legacydev.org/viewtopic.php?f=37&t=68, you can change RaiseFailFastException into RaiseException and it will work (the function is in Kernel32.dll)

Changing ResolveDelayLoadedAPI to ResolveLocaleName (called from Kernel32.dll) gets WineMine running on Windows 7, but probably won't work for anything else that actually uses that function.
Indeed, it seems that changing it to anything that exist will make it work. I wouldn't add this to the post, unless as a side-note that changing an nonexistant function to an existant one may get the app to partially work.

Jevil7452 wrote: ↑15 Aug 2024, 12:34 Changing ResolveDelayLoadedAPI to ResolveLocaleName (called from Kernel32.dll) gets WineMine running on Windows 7, but probably won't work for anything else that actually uses that function.
Indeed, it seems that changing it to anything that exist will make it work. I wouldn't add this to the post, unless as a side-note that changing an nonexistant function to an existant one may get the app to partially work.

What I meant is that you don't add this particular one to the post, but just in general a note at the bottom (as this would apply to multiple DLLs) that sometimes replacing a function that doesn't exist in the DLL with one that exists might get it to work. I recommend to remove what I said about ResolveLocaleName, and just add that note.