Я создаю Windows -только DLL с использованием Visual Studio, которая будет использоваться с Java с использованием JNI. В идеале я хочу, чтобы он был небольшим, пригодным для использования с любой JVM и состоящим только из одного файла.
JVM использует собственную среду выполнения. Например, Azul Community JDK 8 содержит msvcr100.dll (AFAIK - это среда выполнения Visual Studio 2010, поэтому он намекает на то, что эта JVM была построена с VS 2010). JDK 11 содержит множество библиотек DLL, таких как api-ms-win-core-console-l1-1-0.dll (возможно, он был построен с использованием чего-то вроде VS 2017).
Я абсолютно хорошо избегаю прямых использование любых функций CRT (так как Windows API достаточно богат для моих нужд) и ограничение себя чистым C (даже с C ++ я хочу избегать STL, потому что исключения в JNI не очень хорошая идея, а мои функции в основном обертки для WinAPI).
Какие варианты у меня есть? В идеале я хотел бы разрешить использование CRT, но этот CRT должен использоваться из JVM (потому что он уже есть). Но каждая JVM поставляется с разными CRT, и мое небольшое исследование показывает, что они несовместимы ни в каком направлении.
Я могу попытаться отключить связь с любым CRT, но это выглядит довольно хакерским, потому что компилятор может вставить CRT требует оптимизации.
Я могу статически связать ЭЛТ, и в настоящее время я, скорее всего, воспользуюсь этим подходом, но у него есть несколько недостатков: DLL будет чрезмерно огромной, и этот связанный код может содержать уязвимости, которые не будут быть исправленным без перекомпиляции.
Я могу динамически связывать CRT и отправлять эти файлы, но я хочу избежать дополнительного бремени развертывания (также я не очень понимаю последствия использования нескольких MSVCR-ов в один процесс JVM).
Каков наилучший подход здесь?