I'm building Windows-only DLL using Visual Studio that will be used from Java using JNI. Ideally I want it to be small, usable with any JVM and consisting of only one file.
JVM uses its own runtime. For example Azul Community JDK 8 contains msvcr100.dll (AFAIK it's Visual Studio 2010 runtime, so it hints that this JVM was built with VS 2010). JDK 11 contains plenty of DLLs like api-ms-win-core-console-l1-1-0.dll (probably it was built with something like VS 2017).
I'm absolutely fine with avoiding direct usage of any CRT functions (as Windows API is rich enough for my needs) and restricting myself to pure C (even with C++ I want to avoid STL, because exceptions in JNI are not a good idea and my functions are mostly wrappers for WinAPI).
What options do I have? Ideally I would like to allow CRT usage, but this CRT must be used from JVM (because it already has one). But every JVM ships with a different CRT and my little research shows that they are not compatible in any direction.
I can try to disable linking with any CRT, but it seems to be rather hacky because compiler might insert CRT calls for optimizations.
I can statically link CRT and that's currently the approach that I'll likely to take, but that has few drawbacks: DLL will be unnecessarily huge and that linked code might contain vulnerabilities that won't be fixed without recompiling.
I can dynamically link CRT and ship those files, but it's additional deployment burden that I'd like to avoid (also I don't really understand the implications of using multiple MSVCR-s in one JVM process).
What would be the best approach here?