Хочу разработать DLL, которая будет подключаться к Java-программе. Нужно понять, что делать с MSVCR. Хочется минимизировать количество артефактов, чтобы для корректной работы хватало самой DLL. Кроме того хочется минимизировать её размер.

JVM собрана с определённой MSVCR. Например версия 8 собрана вроде бы с помощью Visual Studio 2010, т.к. в ней лежит msvcr100.dll. Версия 11 собрана уже какой-то новой VS, там лежит целый ворох api-ms-win-core-console-l1-1-0.dll и тому подобного. Естественно мне так же не хочется зависеть от JVM, т.е. чтобы DLL подключалась к любой JVM.

Также это всё должно работать в Windows XP.

Абсолютно готов писать на чистом C. Даже если буду писать на C++, по сути это будет C со стрелочкой, никаких исключений, никаких STL.

На границе с DLL никакого CRT нет, с этим проблем не должно быть (типа malloc в DLL, free в приложении, такого не будет).

В общем как в итоге всё это правильно организовать? Как я понимаю, у меня есть такие варианты:

1. Использовать статическую линковку. Тогда DLL будет одна, но здоровая.

2. Устанавливать на компьютер VC Redistributable. Не очень удобно, но, похоже, это "правильное" решение.

3. Копировать нужные DLL-ки вместе с моей DLL куда-то (пока не понимаю, куда, достаточно ли будет указать java.library.path или надо прям в JVM их сувать? Не повредит ли это самой JVM, у неё же своя CRT, а ну как всё перемешается).

4. Отключать CRT и писать на чистом WinAPI. В принципе почитал, похоже на хак, но вроде должно заработать? Как я понял, самое геморное это то, что компилятор будет генерировать вызовы некоторых функций и без моего участия, поэтому, возможно, придётся несколько функций скопипастить откуда-то? Вроде не так уж страшно.

В целом мой идеальный вариант: использовать CRT, но при этом использовать как-то ту CRT, которая идёт с JVM (ну взять минимально адекватную версию вроде 2010). Но, как я понял, такого варианта Visual Studio не предоставляет и гарантий совместимости не даёт.