Сообщение JNI DLL и MSVCR от 12.03.2020 14:39
Изменено 12.03.2020 14:40 vsb
JNI DLL и MSVCRT
Хочу разработать DLL, которая будет подключаться к Java-программе. Нужно понять, что делать с MSVCRT. Хочется минимизировать количество артефактов, чтобы для корректной работы хватало самой DLL. Кроме того хочется минимизировать её размер.
JVM собрана с определённой MSVCRT. Например версия 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 не предоставляет и гарантий совместимости не даёт.
JVM собрана с определённой MSVCRT. Например версия 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 не предоставляет и гарантий совместимости не даёт.
JNI DLL и MSVCR
Хочу разработать 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 не предоставляет и гарантий совместимости не даёт.
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 не предоставляет и гарантий совместимости не даёт.