Некорректная выгрузка DLL при завершении скрипта

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1 2 След.
RSS
Некорректная выгрузка DLL при завершении скрипта, Некорректная выгрузка DLL при завершении скрипта
 
#1
07.12.2020 00:54:00
Нашел всего две темы про выгрузки DLL в скрипте и те какие-то странные, неполные что ли.
Суть проблемы: квик версии 8.10.1.1. После остановки скрипта, в котором подключена DLL (на С++!) - библиотека НЕ освобождается!
Код по высвобождению видел:
Код
  package.loaded[m] = nil
  _G[m] = nil
Не помогает! Как кто-то верно заметил - сама библиотека НЕ освобождается! Причем это действительно и для C++, поэтому я вверху указал на чем либа написана.

Как выявил:
1. Имеется либа на С++ с методом
Код
    string line;
    string outLine;
    const char* S;

    ifstream in("read_test.txt");

    if (in.is_open())
    {
        while (getline(in, line))
        {
            outLine += line;
        }
    }

    in.close();
    lua_pushstring(L, outLine.c_str());

    return(1);
Файл 100% есть, ошибок - нет! Если в LUA вызвать этот метод - он выполняется. Дальше я останавливаю скрипт и пытаюсь перекомпилить либу и получаю отказ в доступе. Пока не перезапущу квик - не компилит.

2. Имеется бородатый lua_quik_resources.dll и скрипт автологина, который давно всем известен (полагаю). Если запускаем квик с запущенным скриптом автологина и остановим его, а потом попытаемся запустить не закрывая квик, то получим:
сначала
Код
Critical error ACCESS_VIOLATION in script
А если после этого еще раз попытаться, то вообще намертво виснет квик и не оживает, пока аварийно не завершишь.

Имеется баг, который нужно фиксить!
 
 
#2
07.12.2020 01:58:29
Цитата
Виталий написал:
Код по высвобождению
Вы б лучше код загрузки показали. Про 8.10 ничего пока не могу сказать, но в предыдущих все ок с выгрузкой, это где-то накосячено.
 
 
#3
07.12.2020 09:15:55
Цитата
Anton написал:
в предыдущих все ок с выгрузкой
Не всё:
https://forum.quik.ru/messages/forum10/message46674/topic5336/#message46674
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#4
07.12.2020 12:31:51
Цитата
Anton написал:
Цитата
Виталий написал:
Код по высвобождению
Вы б лучше код загрузки показали. Про 8.10 ничего пока не могу сказать, но в предыдущих все ок с выгрузкой, это где-то накосячено.
Во-первых, ситуация описана очень подробно и не вижу смысла в еще каких-то кодах. Во-вторых, Старатель в комменте выше предоставил исчерпывающий пример, если моих кодов мало. Так что это не у меня накосячено, это выгрузка не работает нифига.
 
 
#5
07.12.2020 12:36:48
Если вдруг так сильно принципиально видеть код загрузки (хотя он стандартный и бородатый), то вот:
Код
path = getScriptPath() .. "\\my_lib.dll"
package.loadlib(path, "luaopen_my_lib")()
Только не говорите, что еще нужен код библиотеки, чтобы уверовать в некорректность выгрузки  :lol:  
 
 
#6
07.12.2020 14:22:55
Цитата
Виталий написал:
Только не говорите, что еще нужен код библиотеки, чтобы уверовать в некорректность выгрузки    

Во-первых, безусловно нужен. Про него вас и спрашивали изначально.

Во-вторых, я проверил на простейшей библиотеке
https://github.com/swerg/simple-lua-c-dll

на простейшем скрипте с использованием этой библиотеки:
luacdll = require("luacdll")
message(tostring(luacdll.GetCurrentThreadId()), 1)

QUIK 8.6 -- после того, как скрипт отработал - dll-файл библиотеки остаётся заблокированным, т.е. dll не выгружена корректно.
QUIK 8.9 -- после того, как скрипт отработал - dll-файл библиотеки НЕ остаётся заблокированным, т.е. dll выгружена корректно, dll-файл с библиотекой можно переписать / удалить, не закрывая QUIK.
 
 
#7
07.12.2020 16:53:27
Цитата
Виталий написал:
Во-вторых, Старатель в комменте выше предоставил исчерпывающий пример, если моих кодов мало.
Он подтвердил то, что в моем вопросе подразумевалось: при ошибке в длл она не выгружается. Это не очень здорово, но это и не нормальная рабочая ситуация. По существу варианта два: а) в 8.10 что-то накосячили с выгрузкой (проверить не могу); б) в вашей длл есть ошибка (проверить не могу). Из уже показанного я бы предложил перед lua_pushstring добавить lua_checkstack. Хотя вряд ли это причина, это намекает на то, что длл сделана без должного пристрастия к деталям, в коих диавол.
 
 
#8
07.12.2020 17:23:39
В DLL ошибки нет, т.к. даже с более примитивным кодом типа отправки в LUA скрипт "Привет, мир!" - выгрузка не происходит. Впрочем, чтение из файла происходит успешно. Подозреваю, что и в показанном коде, стало быть, ошибок нет иначе свалилось бы. Кстати говоря, если есть ошибка в dll, насколько припоминаю, квик вывалит ошибку и захлопнется. Разве нет?
 
 
#9
07.12.2020 17:29:10
Цитата
swerg написал:
Цитата
Виталий написал:
Только не говорите, что еще нужен код библиотеки, чтобы уверовать в некорректность выгрузки    

Во-первых, безусловно нужен. Про него вас и спрашивали изначально.

Во-вторых, я проверил на простейшей библиотеке
https://github.com/swerg/simple-lua-c-dll

на простейшем скрипте с использованием этой библиотеки:
luacdll = require("luacdll")
message(tostring(luacdll.GetCurrentThreadId()), 1)

QUIK 8.6 -- после того, как скрипт отработал - dll-файл библиотеки остаётся заблокированным, т.е. dll не выгружена корректно.
QUIK 8.9 -- после того, как скрипт отработал - dll-файл библиотеки НЕ остаётся заблокированным, т.е. dll выгружена корректно, dll-файл с библиотекой можно переписать / удалить, не закрывая QUIK.
Первый момент: Вы будете удивлены, но именно этой репой я пользовался при создании своей DLL изначально. Второй момент, вы не описываете поведение в 8.10. Вполне возможно, что в нее могли вернуться баги из 8.6 - это обычная практика в большой команде на большом проекте. Третий момент: я проверю сегодня Ваш пример на 8.10, упрощу донельзя свой и тоже проверю. Результаты напишу сюда позднее и, вероятно, приложу свои коды. Тема заведена не срача ради, а во имя стабилизации и без того не очень ровного терминала.
 
 
#10
07.12.2020 17:35:42
Цитата
Виталий написал:
если есть ошибка в dll, насколько припоминаю, квик вывалит ошибку и захлопнется. Разве нет?
Не обязательно, lua_error из длл можно смело генерировать, они ловятся как обычные ошибки скрипта. Плюсовые исключения тоже ловятся, даже некоторые seh, но эти повреждают квику кишки и потом могут быть последствия. А вот если стек попортить, квик ничего не заметит и может на этом потом или упасть, или накосячить.
 
 
#11
07.12.2020 17:56:22
Цитата
Виталий написал:
Код
  Critical error ACCESS_VIOLATION  in  script 
  

https://forum.quik.ru/messages/forum1/message50121/topic5947/#message50121
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#12
07.12.2020 18:14:22
Цитата
Виталий написал:
Второй момент, вы не описываете поведение в 8.10.

На ftp arqa нет этой версии. Я не знаю где вы её взяли, поверить возможности нет.
 
 
#13
07.12.2020 18:38:08
Цитата
swerg написал:
Цитата
Виталий написал:
Второй момент, вы не описываете поведение в 8.10.

На ftp arqa нет этой версии. Я не знаю где вы её взяли, поверить возможности нет.
я не качаю нгичего на ftp. Я вхожу в квик и жму "Проверить файлы". Эта версия пришла с очередным апдейтом. Так что я хз че там за фтп и что на него кладут. Я доверяю апдейтам через меню )
 
 
#14
07.12.2020 18:39:22
Цитата
Старатель написал:
Цитата
Виталий написал:
Код
    Critical error ACCESS_VIOLATION   in   script 
    

https://forum.quik.ru/messages/forum1/message50121/topic5947/#message50121
ясно, короче походу из одного места растут ноги. Я все равно еще позднее проверю репу, что тут давали, но почему-то мне кажется что это одна и та же ошибка.
 
 
#15
08.12.2020 20:44:25
И так, провел тесты. Вот результаты:
1. Коды из репозитория https://github.com/swerg/simple-lua-c-dll воотбще никак не завелись ни под каким соусом и возиться с причинами я не стал
2. Свои коды я прикладываю в архиве. Результат, как и писал ранее - НЕ выгружается либа после остановки скрипта

Описание
В папка x64 лежит откомпиленая либа + стартер на LUA для нее. Либа посылает в LUA строчку "Привет из DLL". Нит никакого кода, который может вызвать ошибку в DLL, после которого она каким-то образом заклинит и будет невозможно ее выгрузить. Код внутри DLL отрабатывает КОРРЕКТНО! Если кто-то сомневается - исходники приложены, можете открыть, вычистить папку x64 и скомпилить заново. Проект настроен таким образом, что у вас откомпилится DLL + рядом ляжет стартер на LUA.

Что я делаю
Запускаю скрипт и DLL прямиком из этой папки x64. После того, как вижу сообщение - останавливаю скрипт. Меняю что-нибудь незначительное, но достаточное для повторной компиляции в коде С++. Например, удаляю строку отступа или добавляю ее. Жму F5. Возникает ошибка Ошибка LNK1104 не удается открыть файл. Она означает ровно следующее: квик НЕ освободил DLL!

Вниманием!
Если просто нажать F5 не меняя код C++ в студии - ошибок не будет и может показаться, что DLL откомпилилась. Но это не так! У вас просто запустилась откомпиленная DLL (попыталась запуститься). Такая проверка не имеет смысла! Предупреждаю, вдруг кто до сих пон не знал/не понимал как это работает и думал, что все ок.

Очень интересно будет услышать мнение на этот счет от разрабов квика. Версия текущая 8.10.1.1
Надеюсь, теперь информации более, чем достаточно и вопросов/недоверия более не возникнет

Комментарии по моему коду принимаются и приветствуются!!!
 
 
#16
08.12.2020 20:54:31
Собственно, самое важное - коды https://github.com/alik1241/lua-cpp-test Как приложить архив - не нашел.
 
 
#17
08.12.2020 21:23:34
Код
path = getScriptPath() .. "\\central-core.dll"
package.loadlib(path, "luaopen_central_core")()

local m = central_core.DoSomething();
message(tostring(m))

function main()
    while (true) do
        sleep(100)
    end
end


У вас луа-скрипт корректно не останавливается. Что ж вы хотите-то?
 
 
#18
08.12.2020 22:57:48
Вы имеете ввиду, что нужна обработка флага в OnStop?! Если да, то мне тогда непонятно что делает кнопка "Стоп" в квике, просто меняет зеленый треугольник на красный квадрат?! Обработку в OnStop сейчас проверю.
 
 
#19
08.12.2020 23:01:27
Код
path = getScriptPath() .. "\\central-core.dll"
package.loadlib(path, "luaopen_central_core")()

local m = central_core.DoSomething();
message(tostring(m))

isRun = true

function main()
    while (isRun) do
        sleep(100)
    end
end

function OnStop()
   isRun = false
end
Теперь код верный? Если да, то все на что он повлиял - треугольник зеленый стал быстрее сменяться на красный квадрат. Т.е. быстрее стал останавливаться. Либа по-прежнему НЕ освобождается.
 
 
#20
09.12.2020 07:20:41
Ровно такой же скрипт сделал у себя для тестов
У меня DLL выгружается (QUIK 8.9) - после запуска и остановки скрипта могу DLL удалять, заново переписывать и т.д. (проверяю просто переписыванием поверх, буквально VS не собирает на то место, откуда запуск)
Но проверяю на другом коде DLL.
Если дойдёт руки - попробую буквально вашу DLL собрать
 
 
#21
09.12.2020 15:39:01
Цитата
swerg написал:
Ровно такой же скрипт сделал у себя для тестов
У меня DLL выгружается (QUIK 8.9) - после запуска и остановки скрипта могу DLL удалять, заново переписывать и т.д. (проверяю просто переписыванием поверх, буквально VS не собирает на то место, откуда запуск)
Но проверяю на другом коде DLL.
Если дойдёт руки - попробую буквально вашу DLL собрать
Спасибо, конечно. Будет интересно узнать результаты. Но повторю еще раз: версия квика у вас не та. У меня 8.10.1.1 - они могут отличаться. Чего я не понимаю, так это почему молчат представители поддержки официальной?! Их как-то нужно призывать по особому в тему?? По мне так уже давно могли бы что-то написать.
 
 
#22
09.12.2020 20:00:38
Цитата
Виталий написал:
Но повторю еще раз: версия квика у вас не та. У меня 8.10.1.1 - они могут отличаться. Чего я не понимаю, так это почему молчат представители поддержки официальной?! Их как-то нужно призывать по особому в тему?? По мне так уже давно могли бы что-то написать.

И? Я не знаю зачем вы используете именно эту версию.
Вам ничего не мешает быстро проверить на 8.9

Цитата
Виталий написал:
Чего я не понимаю, так это почему молчат представители поддержки официальной?! Их как-то нужно призывать по особому в тему?? По мне так уже давно могли бы что-то написать.

Выгрузка / не выгрузка DLL - это последнее, что заботит реальных пользователей торгового терминала, даже если они используют какие-то готовые библиотеки. Так что, по-моему, это "проблема" приоритета из нижней десятки всех тех тысяч реальных проблем, которые есть в QUIK.
 
 
#23
09.12.2020 21:30:21
Цитата
swerg написал:
Цитата
Виталий написал:
Но повторю еще раз: версия квика у вас не та. У меня 8.10.1.1 - они могут отличаться. Чего я не понимаю, так это почему молчат представители поддержки официальной?! Их как-то нужно призывать по особому в тему?? По мне так уже давно могли бы что-то написать.

И? Я не знаю зачем вы используете именно эту версию.
Вам ничего не мешает быстро проверить на 8.9

Цитата
Виталий написал:
Чего я не понимаю, так это почему молчат представители поддержки официальной?! Их как-то нужно призывать по особому в тему?? По мне так уже давно могли бы что-то написать.

Выгрузка / не выгрузка DLL - это последнее, что заботит реальных пользователей торгового терминала, даже если они используют какие-то готовые библиотеки. Так что, по-моему, это "проблема" приоритета из нижней десятки всех тех тысяч реальных проблем, которые есть в QUIK.
Я использую эту версию, потому что мне ее предоставил брокер. Другой у брокера нет. Какая-то древняя только. С другой стороны, можно задать такой же вопрос разрабам (полагаю, они ее предоставили боркеру): зачем распространять сырую-косую версию?! Т.е. как бы я полагаю, что если обновление пришло и оно не помечено альфой или бетой - значит оно стейбл. А на деле оказывайтся хрень какая-то.
 
 
#24
09.12.2020 21:45:00
Виталий, Так ведь хрень вполне себе стейбл!  :smile:  
 
 
#25
09.12.2020 22:30:45
Цитата
Виталий написал:
Собственно, самое важное - коды
Вот да, это самое важное было.
Код
<CLRSupport>true</CLRSupport>
вместо тысячи слов.
 
 
#26
10.12.2020 03:46:44
Цитата
Anton написал:
Цитата
Виталий написал:
Собственно, самое важное - коды
Вот да, это самое важное было.
Код
   < CLRSupport >  true  < /CLRSupport >  
вместо тысячи слов.
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
 
 
#27
10.12.2020 03:48:10
Цитата
Владимир написал:
Виталий, Так ведь хрень вполне себе стейбл!  ::  
Ну, в целом да. Хрень в квике - стейбл. Жаль, аналогов этому терминалу нет. Финам че-то пыдился, но что-то сильнее, чем мобильное приложение - не вышло у них, а жаль.
 
 
#28
10.12.2020 08:29:33
Цитата
Anton написал:
Код
   < CLRSupport >  true  < /CLRSupport >  
вместо тысячи слов.

Слона-то я и не заметил!  :shock:
 
 
#29
10.12.2020 08:34:12
Цитата
Виталий написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?

Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

Цитата
Виталий написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?

Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
 
 
#30
10.12.2020 09:47:55
Цитата
Виталий написал:
Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
Влияет так, что загрузчик, видя clr в загружаемом модуле, загружает дотнет, и дальнейшим циклом жизни модуля управляет уже дотнет. Квик ни сном ни духом не ведает, что в него вперли аппдомен и его надо прибивать, соответственно никто его и не прибивает, соответственно длл выгружена не будет.
 
 
#31
10.12.2020 10:39:06
Виталий, Аналогов этому терминалу нет и не будет. Ибо задачи разработчиков диаметрально противоположны задачам пользователей: им не нужна стабильно работающая версия, им нужен непрерывный апдейт для имитации бурной деятельности. Алгоритмически задача торговли тупа до неприличия: есть какие-то курсы, которые либо растут, либо падают, либо стоят на месте, И ВСЁ - больше здесь нифига нет! Ну, кое-какие проблемы с передачей данных - деньги всё-таки, "безопасность", панимаш! А вот если туда впендюрить и DLL, и ОС, и .NET, всё это хорошенько палкой перемешать, изуродовать язык со страшной силой... тогда разработчикам будет обеспечен фронт работ на долгие годы.  :smile:  
 
 
#32
10.12.2020 13:47:04
Цитата
swerg написал:
Цитата
Виталий написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?

Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

Цитата
Виталий написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?

Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
 
 
#33
10.12.2020 13:49:51
Цитата
Anton написал:
Цитата
Виталий написал:
Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
Влияет так, что загрузчик, видя clr в загружаемом модуле, загружает дотнет, и дальнейшим циклом жизни модуля управляет уже дотнет. Квик ни сном ни духом не ведает, что в него вперли аппдомен и его надо прибивать, соответственно никто его и не прибивает, соответственно длл выгружена не будет.
Ок, разобрались. Проверил, без NET выгружает. Какие есть варианты самому сделать выгрузку или заставить выгружаться DLL c NET?
 
 
#34
10.12.2020 13:50:59
Цитата
Владимир написал:
Виталий, Аналогов этому терминалу нет и не будет. Ибо задачи разработчиков диаметрально противоположны задачам пользователей: им не нужна стабильно работающая версия, им нужен непрерывный апдейт для имитации бурной деятельности. Алгоритмически задача торговли тупа до неприличия: есть какие-то курсы, которые либо растут, либо падают, либо стоят на месте, И ВСЁ - больше здесь нифига нет! Ну, кое-какие проблемы с передачей данных - деньги всё-таки, "безопасность", панимаш! А вот если туда впендюрить и DLL, и ОС, и .NET, всё это хорошенько палкой перемешать, изуродовать язык со страшной силой... тогда разработчикам будет обеспечен фронт работ на долгие годы.  ::  
Тта эт понятно. Про аналоги, кстати, хз. Ведь есть MT5, который поддерживают некоторые брокеры. Просто странна вся эта ситуация, монополия какая-то.
 
 
#35
10.12.2020 14:43:13
Виталий, Не вижу ничего странного. Дело денежное и, следовательно, должно быть полностью подконтрольным. Тут просто не может не быть монополии! Вы полагаете, что какой-нибудь Сбербанк позволит использовать не аттестованное им программное обеспечение? Ну, конечно, должна быть создана видимость некоторой конкуренции. А конкуренции быть не может по определению - слишком проста математика для обеспечения сделок на бирже. Проста, понятна и логична. А потому весь этот туман от лукавого. Это не технические проблемы - это только политические.
 
 
#36
10.12.2020 21:44:45
Цитата
Виталий написал:
Цитата
swerg написал:
 
Цитата
Виталий  написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
 
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

 
Цитата
Виталий  написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
 
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
 
 
#37
10.12.2020 21:51:13
Виталий,По второму способу начинай изучать с CLRCreateInstance, ICLRMetaHost, ICLRRuntimeInfo, ICorRuntimeHost
 
 
#38
10.12.2020 21:54:44
Виталий, По первому способу
https://www.codeproject.com/Articles/35041/Mixing-NET-and-native-code
https://docs.microsoft.com/ru-ru/cpp/dotnet/mixed-native-and-managed-assemblies?view=msvc-160
 
 
#39
11.12.2020 01:04:45
Цитата
Александр написал:
Цитата
Виталий написал:
 
Цитата
swerg  написал:
 
Цитата
 Виталий   написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
 
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

 
Цитата
 Виталий   написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
 
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
 Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
Не, приложение с передачей данных это такое себе. Это как C# приложение с коннектором C++ - древняя тема и такая же нестабильная. Я пробовал ее году в 2015 еще, че-то не зашло. Я тогда ушел на LUA чистый и его хватало. Сейчас появилась потребность в более нормальном языке, чем LUA и я нашел вариант с подключением библиотеки. Я продолжил бы писать на C# (его знаю, а С++ нет), но проблема в том, что на шарпе нет нормального способа сделать либу. Есть какой-то полукостыльный и он мне не понравился и результат сомнительный. Интерфейсы на чистом Win API тоже не осилил как-то. Вот прикрутил CLR, но оно вон че оказалось. Буду еще смотреть, что дальше делать, но куча посредников между биржей и моим алгоритмом - это печаль и зло. Хочу поменьше, чтоб стабильнее и быстрее было.
 
 
#40
11.12.2020 01:23:14
Цитата
Александр написал:
Виталий, По первому способу
https://www.codeproject.com/Articles/35041/Mixing-NET-and-native-code
https://docs.microsoft.com/ru-ru/cpp/dotnet/mixed-native-and-managed-assemblies?view=msvc-160
Че-то щас так посмотрел и печально все это как-то. Может Вы и правы в том, что отдельно софтину написать на шарпе и через C++ прокидывать туда данные. Надо подумать, попробовать, потыкать
 
 
#41
11.12.2020 16:32:21
Цитата
Виталий написал:
Цитата
Александр написал:
 
Цитата
Виталий  написал:
 
Цитата
 swerg   написал:
   
Цитата
  Виталий    написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
   
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

   
Цитата
  Виталий    написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
   
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
  Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
 Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
Не, приложение с передачей данных это такое себе. Это как C# приложение с коннектором C++ - древняя тема и такая же нестабильная. Я пробовал ее году в 2015 еще, че-то не зашло. Я тогда ушел на LUA чистый и его хватало. Сейчас появилась потребность в более нормальном языке, чем LUA и я нашел вариант с подключением библиотеки. Я продолжил бы писать на C# (его знаю, а С++ нет), но проблема в том, что на шарпе нет нормального способа сделать либу. Есть какой-то полукостыльный и он мне не понравился и результат сомнительный. Интерфейсы на чистом Win API тоже не осилил как-то. Вот прикрутил CLR, но оно вон че оказалось. Буду еще смотреть, что дальше делать, но куча посредников между биржей и моим алгоритмом - это печаль и зло. Хочу поменьше, чтоб стабильнее и быстрее было.
Сделай секцию экспорта в C# библиотеке: сначала дезасемблировать, потом прописывать флаги и секции. Я специально программу написал, которая такое делает.
И можно использовать LoadLibrary на стороне луа и все другие вкусняшки.
 
 
#42
11.12.2020 16:35:30
Александр, Сделай секцию экспорта в C# библиотеке: сначала деасемблировать, потом  прописывать флаги и секции, потом обратно скомпилировать. Я специально программу написал, которая  такое делает.
 
 
#43
11.12.2020 17:58:22
Цитата
Александр написал:
Цитата
Виталий написал:
 
Цитата
Александр  написал:
 
Цитата
 Виталий   написал:
   
Цитата
  swerg    написал:
   
Цитата
   Виталий     написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
   
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

   
Цитата
   Виталий     написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
   
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
   Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
  Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
 Не, приложение с передачей данных это такое себе. Это как C# приложение с коннектором C++ - древняя тема и такая же нестабильная. Я пробовал ее году в 2015 еще, че-то не зашло. Я тогда ушел на LUA чистый и его хватало. Сейчас появилась потребность в более нормальном языке, чем LUA и я нашел вариант с подключением библиотеки. Я продолжил бы писать на C# (его знаю, а С++ нет), но проблема в том, что на шарпе нет нормального способа сделать либу. Есть какой-то полукостыльный и он мне не понравился и результат сомнительный. Интерфейсы на чистом Win API тоже не осилил как-то. Вот прикрутил CLR, но оно вон че оказалось. Буду еще смотреть, что дальше делать, но куча посредников между биржей и моим алгоритмом - это печаль и зло. Хочу поменьше, чтоб стабильнее и быстрее было.
Сделай секцию экспорта в C# библиотеке: сначала дезасемблировать, потом прописывать флаги и секции. Я специально программу написал, которая такое делает.
И можно использовать LoadLibrary на стороне луа и все другие вкусняшки.
Вообще не понял. Как я читал, у C# проблема с экспортом функций и чтобы они были доступны - нужно ставить какую-то приблуду, которая работает только в английской локали. Ты про это или про что-то другое говоришь?
 
 
#44
15.12.2020 13:03:27
Цитата
Виталий написал:
Цитата
Александр написал:
 
Цитата
Виталий  написал:
 
Цитата
 Александр   написал:
   
Цитата
  Виталий    написал:
   
Цитата
   swerg     написал:
     
Цитата
    Виталий      написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
     
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

     
Цитата
    Виталий      написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
     
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
    Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
   Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
  Не, приложение с передачей данных это такое себе. Это как C# приложение с коннектором C++ - древняя тема и такая же нестабильная. Я пробовал ее году в 2015 еще, че-то не зашло. Я тогда ушел на LUA чистый и его хватало. Сейчас появилась потребность в более нормальном языке, чем LUA и я нашел вариант с подключением библиотеки. Я продолжил бы писать на C# (его знаю, а С++ нет), но проблема в том, что на шарпе нет нормального способа сделать либу. Есть какой-то полукостыльный и он мне не понравился и результат сомнительный. Интерфейсы на чистом Win API тоже не осилил как-то. Вот прикрутил CLR, но оно вон че оказалось. Буду еще смотреть, что дальше делать, но куча посредников между биржей и моим алгоритмом - это печаль и зло. Хочу поменьше, чтоб стабильнее и быстрее было.
 Сделай секцию экспорта в C# библиотеке: сначала дезасемблировать, потом прописывать флаги и секции. Я специально программу написал, которая такое делает.
И можно использовать LoadLibrary на стороне луа и все другие вкусняшки.
Вообще не понял. Как я читал, у C# проблема с экспортом функций и чтобы они были доступны - нужно ставить какую-то приблуду, которая работает только в английской локали. Ты про это или про что-то другое говоришь?
В С# проблема с экспортом функций в том, что MS не хочет ее реализовывать. Практических проблем нет.
Ставить приблуду не обязательно. Надо:
1. ildasm.exe декомпилировать код.
2. В тексте кода найти все нужные функции и вставить .export[{номер функции}]. Можно использовать ObfuscationAttribute для определения нужных функций.
3. ilasm.exe скопилировать код в бинарник.
В 64 битном режиме поправить установить флаг .corflags 0x00000002
Утилиту которая такое делает можно написать за один вечер.
Читай книгу Serge Lidin ".Net IL Assembler"
 
 
#45
15.12.2020 13:11:29
Тут читать https://miac.volmed.org.ru/wiki/index.php/%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D­0%...
ExportDLL брать тут https://yadi.sk/d/qAlXi-OnjniSt
 
 
#46
15.12.2020 13:40:18
Фига себе!
Александр, спасибо вам большое!!
 
 
#47
15.12.2020 14:17:30
Цитата
swerg написал:
Фига себе!
Александр , спасибо вам большое!!
Сложно это все, проще через CLRCreateInstance, ICLRMetaHost, ICLRRuntimeInfo, ICorRuntimeHost
 
 
#48
15.12.2020 14:18:05
Кстати реализация ExportDLL моя собственная.
 
 
#49
15.12.2020 22:08:34
Цитата
Александр написал:
Цитата
Виталий написал:
 
Цитата
Александр  написал:
 
Цитата
 Виталий   написал:
   
Цитата
  Александр    написал:
   
Цитата
   Виталий     написал:
     
Цитата
    swerg      написал:
     
Цитата
     Виталий       написал:
И что не так? В этой либе мне нужно использовать CLR, там будут формы. Как сам факт поддержки CLR (без каких-либо вызовов) влияет на выгрузку библиотеки?
     
Как минимум - вот оно коренное отличие вашей DLL от моей, а вовсе не версия QUIK.
Ну и видимо передавайте привет .NET и особенностям ее работы.

     
Цитата
     Виталий       написал:
(без каких-либо вызовов) влияет на выгрузку библиотеки?
     
Вы может и не вызываете, но раз хотите .NET - оно там очень могуче напрягается, чтобы вам его предоставить.
Вам наверное будет не сложно пока отключить использование .NET и проверить.
     Пока не сложно. Проверил. Без NET выгружается. Другой вопрос: как обеспечить выгрузку с NET, не знаете? Полагаю, спрашивать разрабов квика бесполезно про это...
    Способов подключения сборок на си++ как минимум 2: 1. это использовать управляемый код. 2. Использовать интерфейсы и самостоятельно загружать сборки.
Тот и другой способ гуглится.
Но возможно стоит начать вот CoInitializeEx и CoUninitialize.
Но я бы советовал сделать отдельное приложение на .net и передавать туда данные, например по сети.
   Не, приложение с передачей данных это такое себе. Это как C# приложение с коннектором C++ - древняя тема и такая же нестабильная. Я пробовал ее году в 2015 еще, че-то не зашло. Я тогда ушел на LUA чистый и его хватало. Сейчас появилась потребность в более нормальном языке, чем LUA и я нашел вариант с подключением библиотеки. Я продолжил бы писать на C# (его знаю, а С++ нет), но проблема в том, что на шарпе нет нормального способа сделать либу. Есть какой-то полукостыльный и он мне не понравился и результат сомнительный. Интерфейсы на чистом Win API тоже не осилил как-то. Вот прикрутил CLR, но оно вон че оказалось. Буду еще смотреть, что дальше делать, но куча посредников между биржей и моим алгоритмом - это печаль и зло. Хочу поменьше, чтоб стабильнее и быстрее было.
  Сделай секцию экспорта в C# библиотеке: сначала дезасемблировать, потом прописывать флаги и секции. Я специально программу написал, которая такое делает.
И можно использовать LoadLibrary на стороне луа и все другие вкусняшки.
 Вообще не понял. Как я читал, у C# проблема с экспортом функций и чтобы они были доступны - нужно ставить какую-то приблуду, которая работает только в английской локали. Ты про это или про что-то другое говоришь?
В С# проблема с экспортом функций в том, что MS не хочет ее реализовывать. Практических проблем нет.
Ставить приблуду не обязательно. Надо:
1. ildasm.exe декомпилировать код.
2. В тексте кода найти все нужные функции и вставить .export[{номер функции}]. Можно использовать ObfuscationAttribute для определения нужных функций.
3. ilasm.exe скопилировать код в бинарник.
В 64 битном режиме поправить установить флаг .corflags 0x00000002
Утилиту которая такое делает можно написать за один вечер.
Читай книгу Serge Lidin ".Net IL Assembler"
Спасибо, но на самом деле так можно и закопаться очень глубоко и забыть вообще что ты и зачем хотел сделать изначально )) Я действующий разраб по основной профессии, опыта уже 10+ лет. И вот именно этот опыт подсказывает мне идти по пути наименьшего сопротивления. Ибо если ты не можешь сделать сегодня то, что будет работать хоть как-нибудь - завтра это сделает другой. А ты так и будешь дальше сидеть и пилить идеальный код и решение , которое к моменту появления уже нафиг некому не нужно. Я занимался подобными вещами, как Вы описываете, когда пытался защитить от взлома программу на C#. И, скажу, довольно удачно. Метод был простой, как помидор: обфускация, упаковка и подмена парочки байт, чтобы обратно никто не распаковал. Все, не надо платить 100500 мильенов за дорогие защиты от вскрытия. Информацию сохраню, займусь как-нибудь потом. А пока время реализовывать идею. Вроде как, нашел рещение и оно даже мне подходит (не такое плохое).
 
 
#50
15.12.2020 22:10:50
Цитата
Александр написал:
Цитата
swerg написал:
Фига себе!
Александр , спасибо вам большое!!
Сложно это все, проще через CLRCreateInstance, ICLRMetaHost, ICLRRuntimeInfo, ICorRuntimeHost
Смотрел, не понял, как это сделать и куда всунуть чего в моей либе сишной. Да и есть ли смысл, уже не знаю даже. Лучше, наверное, все-таки делить ответственность: логика на C++, интерфейс на C#. За примеры спасибо, изучу, вероятно применю что-то в будущем.
 
 
Страницы: 1 2 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх