I’m working with the SearchPath Windows API and running into an issue. When I pass NULL as the first parameter to use the default search behavior, it keeps finding files in the c:\windows folder even though I don’t want it to. Here’s my situation: I have an old config file sitting in c:\windows that needs to stay there for backward compatibility reasons. But I want my program to use a newer version of the same file that I placed in c:\users\public instead. I already added c:\users\public to the beginning of my PATH environment variable. The problem is that SearchPath still picks up the c:\windows version first. When I temporarily remove the file from c:\windows, it correctly finds the one in c:\users\public, so I know my PATH setup is working. Is there any way to make SearchPath skip the c:\windows directory without changing how the calling code works? I can’t modify the part that calls SearchPath to pass a specific path instead of NULL.
Nope, there’s no direct way to exclude c:\windows when you pass NULL to SearchPath. The function’s hardcoded to hit system directories before checking PATH. I ran into this exact problem two years back with a legacy app that had the same file conflicts. What worked for me was hooking the SearchPath calls at the DLL level - let me modify the search behavior without touching the calling code. You could also write a custom search function that acts like SearchPath but only uses your directories, then swap out the original calls with binary patching or API interception. Both approaches need some low-level work, but they keep your existing code intact while giving you full control over search behavior.
Been there. SearchPath is stubborn about system directories and there’s no clean flag to skip them.
One trick that saved me: use SetDllDirectory before SearchPath runs. Find where your app does the search and inject a SetDllDirectory call right before it. This redirects the search behavior.
You could also create a junction point or symlink in the windows directory pointing to your newer file. Windows follows the link transparently - SearchPath thinks it’s finding the old file but gets your new one instead.
Both are hacky but they work without breaking existing code. The junction approach is cleaner since it won’t mess with DLL search order for other parts of your app.
totally feel u on that! searchpath can be a pain sometimes. maybe try to write a small wrapper that ignores the default dirs? focus on ur specific ones, it might do the trick.
I’ve hit this same wall multiple times. SearchPath API won’t let you skip system directories - it’s hardcoded into the search order.
Here’s my workaround: automate the file management instead of wrestling with Windows APIs. Set up monitoring on both locations and let automation handle version conflicts.
The system watches your source directory (c:\users\public) and either updates the legacy file in c:\windows or temporarily renames it when your app launches. You can create rules to swap files based on which process calls them.
No API hooks or binary patches needed. Automation handles the file juggling while your legacy code runs unchanged.
I use this for config files across different app versions - way more reliable than trying to outsmart Windows file search.
Check out https://latenode.com for this kind of file management automation.