Тема: Где взять lua5.1.dll? делаем ее на основе qlua.dll
При использовании сторонних библиотек для Lua в QUIK возникает стандартная проблема: надо где-то взять run-time библиотеки Lua, чтобы все это заработало. Как минимум, это файл lua5.1.dll, однако помимо него часто приходится еще разыскивать и run-time библиотеки MS Visual C++ (например, всякие msvcrt80.dll и т.п). Кроме того, хотелось бы запускать скрипты на Lua отдельно от QUIK, что удобно для изучения.
Обычно для всего этого рекомендуют установить пакет Lua для Windows, где все указанное содержится. Хотя и тут часто не все проходит гладко, прыжки с поиском и перекладыванием библиотек почти гарантированы.
Было бы здорово решить обе эти задачи без установки Lua. И это вполне возможно, ведь у нас есть готовая qlua.dll, которая содержит в себе полную реализацию Lua, к ней бы только прицепиться! Кто сам делает [url=https://quik2dde.ru/viewtopic.php?id=18]свои библиотеки на C++ для Lua[/url] – может легко прицепиться к qlua.dll и не зависеть от lua5.1.dll; а вот те, кто использует готовые библиотеки, теперь может воспользоваться готовым рецептом из этого поста. И никакую Lua for Windows теперь можно не устанавливать!
Идея проста: сделать «прокси-dll», которая будет называться lua5.1.dll, будет иметь идентичный с ней интерфейс, но для выполнения всех функций будет обращаться исключительно к qlua.dll.
На мой взгляд, от такой прокси-библиотеки, помимо упрощения развертывания сторонних библиотек, есть еще один плюс. Т.к. в QUIK работа Lua кода возможна как минимум в двух потоках, вся синхронизация содержится в qlua.dll и полностью отсутствует с обычной lua5.1.dll, что наверняка может порождать различные проблемы.
Как происходит работа с Lua-стеком (данными Lua-машины) при использовании обычной lua5.1.dll из поставки Lua, и внешней библиотеки в составе скрипта, запущенного из QUIK (для примера сторонняя библиотека названа wxLua):
Схема, конечно, упрощенная, но важно вот что: qlua.5.1.dll и qlua.dll работают с памятью независимо. Это не страшно в однопоточном приложении, однако в многопоточном наличие синхронизации в qlua.dll нас уже не спасает от «не вовремя» сработавшей процедуры в wxLua одновременно с qlua.dll, если такое срабатывание происходит в разных потоках, что обязательно приведет к несинхронной модификации одной и той же памяти.
Если же мы работаем через прокси-dll, то картинка одновременной работы QUIK и внешней библиотеки получается уже другая, вся работа происходит через qlua.dll:
Архив с бинарными файлами [url=https://quik2dde.ru/static-img/47/lua5.1.dll-cover.bin.zip]скачивать здесь[/url]. Он содержит два файла:
lua5.1.dll
do_lua.exe
lua5.1.dll предоставляет наружу те же интерфейсы, что и библиотека с тем же названием из поставки Lua, только все вызовы из нее передаются сразу в qlua.dll. Никакого кода кроме загрузки qlua.dll эта прокси-библиотека не содержит.
do_lua.exe небольшая консольная утилита, позволяющая при помощи lua5.1.dll выполнять Lua-скрипты из файлов. Я специально ее сделал, чтобы полностью исключить надобность в пакете «Lua for Windows». Формат запуска простой:
do_lua.exe <имя_файла.lua>
Установка: копируем файлы из архива lua5.1.dll и do_lua.exe в папку с установленным QUIK - и все. Это обеспечивает, во-первых, среду для выполнения сторонних библиотек, зависящих от lua5.1.dll, во-вторых, позволяет запускать произвольные Lua-скрипты, причем выполняться они будут с использованием qlua.dll! Теперь-то уж точно можно будет проверить: кривая там реализация или нет.
Кому интересно как это сделано – смотрят следующий пост.
Еще раз ссылка: [url=https://quik2dde.ru/static-img/47/lua5.1.dll-cover.bin.zip]скачать архив с бинарными файлами lua5.1.dll и do_lua.exe[/url].