Replacing MSVC CRT function with private implementation - windows

Question

I have an embedded IoT project that I like to first develop in part by using PC tools such as VisualStudio. My embedded project has only a flash memory for a file system, and I'd like to redirect fopen fread etc. to my own private implementation on Windows. But what I'm encountering is an inability to have my private CRT library take precedence over the built-in CRT (e.g., built-in behavior driven by /MD compiler switch).
I have a simple three project solution.
Project 1 is a test executable. It has a one line main:
int main()
{
test();
}
Project 2 and 3 are static libraries. Project 2 has:
#include <string.h>
#include <stdio.h>
void test()
{
printf("%s\n", strchr("x", 'x'));
}
Project 3 has:
char * strchr(const char * s, int c) // exact signature of MSVC
{
return "overridden";
}
I expect output to be overridden but instead it is
x
But if I add this to Project 1:
printf("%s\n", strchr("y", 'y'));
The output will be
overridden
overridden
First one from test() in library, second from executable main() directly.
Any suggestions?

Answer 1

The linker resolves symbols on a first match basis - priority to separately linked .obj files, then .lib files in the order presented to the linker of the command line. So you can normally override a library symbol just be linking your own replacement. I have never tried it with MSVC, and it is a somewhat brutal approach.
An alternative solution that does not rely on specific linker behaviour is to use the pre-processor to replace standard symbols with your own alternatives. For example:
#if defined _WIN32
#define fopen test_fopen
FILE* test_fopen( const char * filename, const char * mode ) ;
#endif
add the other macros and declarations you need in a header file called testlib.h for example then use a "forced include" (/FI testlib.h in MSVC) to invisibly include the test interface everywhere. Then when built on Windows, all fopen calls will be replaced with test_fopen calling your replacement functions instead.

Answer 2

If the problem is caused by CRT usage in a static library only, and linker is finding MSVCRT DLL export lib before it finds private CRT static lib, a workaround might be to force a reference to the private CRT in the executable source files.
Example matching code above, placed in main as a global:
static char * (*p_strchr)(const char *, int) = strchr;
It is less than ideal but it alters linker search order in a reliable way.
More findings
There may be combinations (that I don't totally understand) where the linker will emit a LNK1169 "one or more multiply defined symbols" (more than one definition) linker error. For example, it might say fopen is defined more than once, and if you reverse the order of the private and MS libraries on the command line, then it might say fread is defined more than once. Perhaps it is caused by MSVC lib having DLL export signature, and the private lib being an import symbol. The behavior is hard to determine as it doesn't error on all of the functions that are being overridden.
If it is possible to switch all private libraries to /MT compiler switch (use static CRT), then the LNK1169 problem is resolved.