[FireNativeDLL] Создание полноценных DLL на Visual Basic

Обсуждение проектов наших жителей.
Вы можете выставить проект на тест или найти помощников для его реализации.

Модератор: BV

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 05.07.2011 (Вт) 22:30

Ну просто оболдеть, сколько свеженькой информации :)
Хакер писал(а):Она в том, что COM/ActiveX-основанность просто зашкаливает. В COM ведётся подсчёт ссылок на интерфейс (и так далее...)
Получается бабка за дедку, дедка, за репку... А если серьезно, то в этом то и заключается все различие между WinAPI библиотеками, которые такой природы не имеют и соответственно описанные процессы в них не происходят? (Можно просто Да и Нет, а то мне уже право слово неудобно :oops: )
Хакер писал(а):Все твои фразы настолько противоречивы, что к каждой можно написать такую разъяснительную мини-статью. Мне кажется, ты специально провоцируешь меня на это
Не виноватая Я! :) Честое слово никакого умысла на провокацию. А за разъяснительную статью просто огромное спасибо! Теперь у меня появилось очень много пищи для размышлений. В моем случае использование Init без UnInit, может привести к утечке памяти, поэтому стоит позаботиться о том, чтобы избегать загрузок-выгрузок и по окончанию работы, таки применить UnInit.
Хакер писал(а): Очень качественно, но совершенно тупо и неудобно с точки зрения пользователя
Мое субъективное мнение - мне вполне удобно, и совершенно не тупо, главное, что-бы работало. Одним объявлением/вызовом больше одним меньше, для меня не суть важно, да и для других я думаю тоже.
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 06.07.2011 (Ср) 8:05

ger_kar писал(а): если серьезно, то в этом то и заключается все различие между WinAPI библиотеками, которые такой природы не имеют и соответственно описанные процессы в них не происходят?


Нет. Библиотека, сделанная при помощи VB, сама по себе не требует быть инициализированной. Это функции, которые она вызывает из MSVBVM60, требуют.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 06.07.2011 (Ср) 14:50

Я думаю, а что если инициализацию (Init) сделать автоматом, ну а вызов Uninit возложить на пользователя, получится полуавтомат. Причем автозапуск Init можно сделать опциональным.
Бороться и искать, найти и перепрятать

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 12.07.2011 (Вт) 11:58

Продолжаю тему. В прошлый раз ты очень подробно разъяснил как работает VB и VBA. Из твоих объяснений я делаю вывод, что макросы VBA, хранится вместе с документом, уже в скомпилированном в P-код виде. И когда макрос запускается, то используется готовый P-код.
Далее, приложения, которые вызывает FNDLL, фактически юзают мусор (как ты выражаешься) оставшийся после деинициализации. Все это понятно. Но возникают непонятки вот по какому поводу. Несмотря на то, что после деинициализации остается только мусор, приложения, из которых делается вызов библиотеных функций, работают вполне себе нормально, что VB, что VBA. Но с VBA есть траблы. Т.е. когда макрос запускается в первый раз, то работает все прекрасно, библиотечного мусора оставшегося после деинициализации ему вполне хватает, но вот макрос отработал и наступает неопределенная ситуация, которую я бы назвал полуастоновом. Т.е. макрос вроде уже отработал, но полного останова, как такового, не происходит, глобальные переменные остаются инициализированными, по идее и с подключенной библиотекой не должно случиться ничего страшного, то тем не менее именно в этот момент происходит, что-то нехорошее. И после этого события повторный запуск библиотеки уже не возможен. Что может происходить в этот момент? Происходит еще одна деинициализация добивающая, то, что осталось от первой? Но по идее ее не должно быть (переменные же не сбрасываются), может это действительно глюк среды, которая некорректно обрабатывает режим полуастонова?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 12.07.2011 (Вт) 12:53

ger_kar писал(а):Из твоих объяснений я делаю вывод, что макросы VBA, хранится вместе с документом, уже в скомпилированном в P-код виде. И когда макрос запускается, то используется готовый P-код.

Наверняка нет.

ger_kar писал(а):но вот макрос отработал и наступает неопределенная ситуация, которую я бы назвал полуастоновом.

Нет никакого полуостанова. Когда выполнение вышло из макроса, оно крутится в цикле прокачки оконных сообщений.

ger_kar писал(а):по идее и с подключенной библиотекой не должно случиться ничего страшного, то тем не менее именно в этот момент происходит, что-то нехорошее.

Это ошибочное заключение.

Скорее всего происходит что-то такое: после того, как настало состояние, как ты его называешь, «полуостанова», а по-нормальну — idle-time, офисная среда решает вызвать CoFreeUnusedLibrary(Ex), потому что документация по функции рекомендует вызывать её именно в такие моменты.

Эта функция опрашивает все подгруженный DLL через DllCanUploadNow. И вот наша библиотека получает запрос, и думает: так, живых объектов нет, возвращаю «yeah, you can», но зато есть какой-то мусор, грохну-ка его.

Последствия ты знаешь.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 12.07.2011 (Вт) 15:13

Хакер писал(а):Это ошибочное заключение.

Хакер писал(а):Эта функция опрашивает все подгруженный DLL через DllCanUploadNow. И вот наша библиотека получает запрос, и думает: так, живых объектов нет, возвращаю «yeah, you can», но зато есть какой-то мусор, грохну-ка его.
Вот, и происходит это самое - нехорошее.
Теперь осталось проверить эту версию. Как это сделать вариант такой:
Сморю вызывается ли CoFreeUnusedLibrary(Ex) и если вызывается ставлю на неё бряк, далее снимаю дамп до вызова этой ф-ции и непосредственно после этого (дампить только адресное пространство библиотеки) далее сравнение двух дампов и анализ. Я на верном пути?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 12.07.2011 (Вт) 15:44

ger_kar писал(а):Я на верном пути?

Нет.
Ты получишь разницу в любом случае.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 12.07.2011 (Вт) 16:03

Хакер писал(а):
ger_kar писал(а):Я на верном пути?

Нет.
Ты получишь разницу в любом случае.
Ну, разница, то конечно будет, изменение переменных и все такое. Но я думаю, что изменений будет не очень много, в пределах разумного, и путем последовательного анализа, а в некоторых местах и трассировки можно будет выявить искомое. Вопрос только в том, достаточно ли для этого анализа адресного пространства DLL? Или же можно это сделать оптимальнее? И еще тебе самому интересно узнать истину и проверить свои догадки?
Бороться и искать, найти и перепрятать

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 12.07.2011 (Вт) 16:24

ger_kar писал(а):Ну, разница, то конечно будет, изменение переменных и все такое. Но я думаю, что изменений будет не очень много, в пределах разумного, и путем последовательного анализа, а в некоторых местах и трассировки можно будет выявить искомое. Вопрос только в том, достаточно ли для этого анализа адресного пространства DLL?

99 процентов разницы будет в кучах. Даже интересующая разница будет там. Изменившиеся блоки будут идти в перемешку. Ты их никак не отличишь.
Можешь попробовать, если нечем заняться. Времени на анализ потратишь столько же, сколько на написание новой FNDLL.

ger_kar писал(а):И еще тебе самому интересно узнать истину и проверить свои догадки?

Я предпочитаю потратить время на то, чтобы сделать заведомо ненадёжное заведомо надёжным.
А не на выяснение того, почему именно заведомо ненадёжное падает.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 12.07.2011 (Вт) 16:44

Хакер писал(а):Я предпочитаю потратить время на то, чтобы сделать заведомо ненадёжное заведомо надёжным.
А не на выяснение того, почему именно заведомо ненадёжное падает.
Время потрачу я, но прежде чем я его начну тратить, я перед этим хочу выбрать самый оптимальный путь (и помощь, а точнее намек нужна в выборе этого пути), для меня это не будет бесполезной тратой времени, ибо (я так думаю) процесс будет сопровождаться обучением и это скомпенсирует потраченное время. А про интерес вопрос повторю с уточнением: Скажем тебе будет интересно узнать чем закончилось мое исследование? И кроме того я думаю вот что, несмотря на то что VB6 не поддерживается, тем не менее эта система программирования живее всех живых, правда с некоторыми изменениями. Это VBA, который встроен даже в самую последнюю линейку Office и таким образом живет и процветает, и меня интересует взаимодейтвие FNDLL и VBA в большей степени, чем с VB. Ну и опять же знать истинную причину всегда полезно.
Бороться и искать, найти и перепрятать

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 14.07.2011 (Чт) 9:36

Хакер писал(а):Хотя это намеренно привнесённая мною ошибка: в самой первой выложенной версии уничтожение только что созданного объекта в DllEntryPoint не совершалось, и библиотека была стабильна всегда. Но была другая проблема: поскольку объект не уничтожался вообще, возникала угроза возникновения утечки памяти. Хотя рядовые библиотеки подгружаются в АП процесса только единожды, возможен всё-таки случай, когда библиотека будет периодически загружаться/выгружать из в/из АП процесса с помощью LoadLibrary/FreeLibrary. Если будет выполнена тысяча таких выгрузок-загрузок, в памяти будет висеть тысяча неуничтоженных объектов.
Про тысячу выгрузок загрузок, мне кажеться ты утрируешь, если например создавать объект из простейшего класса, то он много места в памяти не займет, соответственно и памяти много не утечет. Даже если будет небольшая утечка - это же не фатально, пусть лучше небольшая утечка чем нестабильность в работе. И еще, а разве нельзя при создании нового объекта, проверять наличие ранее созданных экземпляров, и если таковые есть, то в этом случае новых не плодить?
Бороться и искать, найти и перепрятать

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 05.02.2012 (Вс) 18:28

Добрый день!

Прошу совета у всех, но в первую очередь у Хакера.

Занимаюсь декомпиляцией старенькой игры Ecstatica 2 тут: http://ecstatica2.livejournal.com. Система: Win7.
Подсмотрев здесь: http://habrahabr.ru/blogs/asm/51857/ как можно подключив к exe-шнику специальную библиотеку wndmode.dll сделать DirectDraw приложение оконным.
Соответственно подключить библиотеку у меня получилось: http://ecstatica2.livejournal.com/20646.html.
Подключал библиотеку следующим ассемблерным кодом:
Код: Выделить всё
push offset LibName ; "wndmode.dll"
call cs:__imp_LoadLibraryA


Захотелось пойти дальше и написать свою dll, уже которая в свою очередь загрузит wndmode.dll и выполнит кое-какой другой дополнительный код.
Так как по профессии я не программист и изучать специально для написания native Dll язык вроде С++ никакого желания нет, да и VB6 я люблю, решил написать библиотеку на бейсике. Так я на эту тему и вышел, потому как ActiveX dll не подключишь.

И вот когда я набросал простой проект, который от стандартного шаблона StandardDLL отличается двумя строчками:
Код: Выделить всё
Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
...
Case DLL_PROCESS_ATTACH
LoadLibrary "g:\games\Ecstatica_2\wndmode.dll"
DllEntryPoint = 1
...

Скомпилировал и попробовал подключить к exe-шнику у меня ничего не получилось. То есть если библиотеку подгружать к проекту написанном на VB, все отрабатывает отлично, а вот в ecstatica2.exe нет.
Сначала я попробовал подгрузить библиотеку так как делал раньше:
Код: Выделить всё
push offset LibName ; "StandardDLL.dll"
call cs:__imp_LoadLibraryA

Код библиотеки из функции DllEntryPoint не отработал.
Не работает скорее всего по причине, которую описал Хакер в этом сообщении: viewtopic.php?f=15&t=34902&start=90#p6752609
Тогда я решил перенести нужный мне код из функции DllEntryPoint в любую другую и ее добавить в таблицу экспорта и вызвать так:
Код: Выделить всё
[code]
push offset LibName ; "StandardDLL.dll"
call cs:__imp_LoadLibraryA
push offset FuncName ; "LoadLib"
push eax ; eax - hModule библиотеки
call cs:GetProcAddress
mov edi, eax ;
call edi ; вызываем экспорт-функции библиотеки

Но при таком коде GetProcAddress не возвращает в eax указатель на экспорт-функцию.

Подскажите, в чем проблема? Обязателен ли в моем случае CoInitialize до LoadLibrary?
И если есть здесь гуру ассемблера, как мне добавить фукнцию CoInitialize в таблицу импорта ecstatica2.exe для того чтобы я ее смог вызвать в коде программы?

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 05.02.2012 (Вс) 19:25

Сам отвечу на свой вопрос (как часто бывает: хочешь найти ответ, правильно и ПИСЬМЕННО сформулируй вопрос):
Зачем нужно добавлять функцию CoInitialize в таблицу импорта ecstatica2.exe, если можно загрузить библиотеку ole32.dll и получить из нее при помощи GetProcAddress нужную функцию CoInitialize?

Следующий код выполнил нужную мне задачу:
Код: Выделить всё
push    offset aole32dll ; "ole32.dll"
call    cs:__imp_LoadLibraryA
push    offset aCoInitialize ; "CoInitialize"
push    eax             ; hModule
call    cs:GetProcAddress
mov     edi, eax
xor     eax, eax
push    eax
call    edi ; CoInitialize(0)
push    offset awndmodedll ; "wndmode.dll"
call    cs:__imp_LoadLibraryA

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 06.02.2012 (Пн) 1:18

terar писал(а):да и VB6 я люблю, решил написать библиотеку на бейсике. Так я на эту тему и вышел, потому как ActiveX dll не подключишь.


Не правда. Подключишь. Нужно делать CoCreateInstance вместо LoadLibrary в тот момент, когда хочется подключить.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 06.02.2012 (Пн) 7:14

Мне в моих предыдущих задачах знание COM особо не требовалось, да и сейчас распыляться не хотелось бы, но насколько я понимаю CoCreateInstance для своей работы требует регистрации библиотеки в реестре. В случае с CoInitialize и LoadLibrary достаточно положить библиотеку в туже папку, что и запускающий exe-файл.
Но опять же с COM я почти незнаком, того, что я прочитал достаточно лишь для того, чтобы понять почему CoCreateInstance вместо LoadLibrary заработает, поэтому допускаю, что в своем предположении могу быть некорректен.

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 06.02.2012 (Пн) 8:07

terar писал(а):но насколько я понимаю CoCreateInstance для своей работы требует регистрации библиотеки в реестре.

Требует. Это проблема?

terar писал(а):В случае с CoInitialize и LoadLibrary достаточно положить библиотеку в туже папку, что и запускающий exe-файл.

Я же говорил, что самая последняя выложенная версия FNDLL делает нестабильные DLL. Их использоваие очень рисковано. Впрочем, это касается версии, которая была последней версией на сайте, а что выложили люди здесь в топике — надо смотреть, вдруг это первая версия.

Тем не менее, если использовать CoCreateInstance, то FNDLL вообще не нужен.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 06.02.2012 (Пн) 13:46

Совсем не проблема.

Как узнать какая у меня версия FNDLL?

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 06.02.2012 (Пн) 19:44

terar писал(а):Совсем не проблема.

Лучше тогда этим пуйтём пойти.

terar писал(а):Как узнать какая у меня версия FNDLL?

Да так грустно получается, что они обе кривые.
Одна не уничтожала объект вообще (и вызывала memory-leak).
Другая слишком рано уничтожала объект (и всё могло упасть вообще просто так).

Узнать можно по вызову IUnknown::Release во внедряемом коде.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 06.02.2012 (Пн) 21:02

У меня первая с memory-leak, пока поживу на ней.
Тем не менее жду новую версию FNDLL, ACM-Tools если мне память не изменяет, надеюсь проект еще не заброшен.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 07.02.2012 (Вт) 18:02

Хакер писал(а):Да так грустно получается, что они обе кривые.
Одна не уничтожала объект вообще (и вызывала memory-leak).
Другая слишком рано уничтожала объект (и всё могло упасть вообще просто так).

Как мне кажется краски сильно сгущены. Все зависит от ситуации в которых это будет применятся. У меня нет первой версии, которая не уничтожает объект, поэтому нет соответственно возможности протестировать ее на практике, но что-то мне очень сомнительно, что-бы памяти очень много утекало. Она конечно будет, но так сказать не заметна не вооруженным глазом. Я например, работая с последней версией, в которой объект уничтожается сильно рано, по совету Хакера (сам бы вряд ли додумался ;) ) в самом начале работы с библиотекой, т.е. вызовом самой первой специальной функции создаю инстанс пустого класса и все - вуаля! Работает все очень хорошо и стабильно. Если утечка и есть, то такая незначительная, что это по сути и проблемой то не является. Конечно я понимаю, что механизм не идеальный и такого профи, как Хакер это может беспокоить, но я думаю, что это можно сравнить с занозой, если ее не тревожить и про неё не вспоминать, то и беспокойства она доставлять не будет.
Хакер писал(а):Хотя рядовые библиотеки подгружаются в АП процесса только единожды, возможен всё-таки случай, когда библиотека будет периодически загружаться/выгружать из в/из АП процесса с помощью LoadLibrary/FreeLibrary. Если будет выполнена тысяча таких выгрузок-загрузок, в памяти будет висеть тысяча неуничтоженных объектов.
Ну в этом случае конечно это будет проблема и в таких случаях нужно очень сильно подумать, прежде чем применять FNDLL, но в том то и прикол, что этот случай один может быть на тысячу. Но тут опять же можно применять вторую версию FNDLL и создавать/уничтожать объект отдельными функциями и вызывать ф-ции парами LoadLibrary - CreateObject / DeleteObject - FreeLibrary чем не вариант?
terar писал(а):но насколько я понимаю CoCreateInstance для своей работы требует регистрации библиотеки в реестре.

Хакер писал(а):Требует. Это проблема?

Конечно это не проблема, но очень многим эта регистрация в реестре очень уж не по нраву. Да и лишнее неудобство, но это неудобство очень просто сделать незаметным. Достаточно в приложение в самом начале встроить ф-цию, которая бы проверяла наличие регистрации нужных компонентов в реестре и если нет регистрации искала в каталоге приложения нужные библиотеки и при нахождении регистрировала. В этом случае не нужно не инсталляторов ни лишних телодвижений. Все просто и почти гениально ;).
Бороться и искать, найти и перепрятать

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 07.02.2012 (Вт) 19:39

ger_kar писал(а):Конечно это не проблема, но очень многим эта регистрация в реестре очень уж не по нраву. Да и лишнее неудобство, но это неудобство очень просто сделать незаметным. Достаточно в приложение в самом начале встроить ф-цию, которая бы проверяла наличие регистрации нужных компонентов в реестре и если нет регистрации искала в каталоге приложения нужные библиотеки и при нахождении регистрировала. В этом случае не нужно не инсталляторов ни лишних телодвижений. Все просто и почти гениально ;).


Тут какой момент. Для меня не проблема написать код, который будет делать то, что вы описали. Более того, мне сейчас вообще непринципиально, как подгружается библиотека, работает (даже с утечкой памяти, у меня не будет 1000 загрузок подряд) и ладно.
Но я расчитываю, что в какой-то момент моя библиотека к Экстатике будет вносить такие изменения в код игры, что станет интересной многим. И вот тут возникает как раз тот момент, когда это "лишнее неудобство" оказывается принципиальным. Для того, чтобы библиотека подключалась к exe-шнику я напишу патч, который может заодно и зарегистрировать библиотеку, если это уже не сделано. Но этот патч будет запускаться однократно! И если человек захочет перенести впоследствии игру в другую папку тут библиотека уже не заработает. Писать проверку на регистрацию на ассемблере для того, чтобы встроить ее в откомпилированный exe-шник совсем не хочется.

А что я получаю при использовании native Dll? Как будет выглядеть инструкция по установке дополнения к игре в виде библиотеки? "Запустите patchEcstaica.exe и положите эту библиотеку в папку с игрой. При выходе обновления замените библиотеку на новую". Если бы я ничего не понимал в программировании второй вариант мне бы как конечному пользователю понравился бы намного больше.

Еще раз поблагодарю Хакера за FNDLL, лично мне она очень полезна. Да и узнал я много нового. :)

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 07.02.2012 (Вт) 19:50

ger_kar писал(а):Как мне кажется краски сильно сгущены. Все зависит от ситуации в которых это будет применятся. У меня нет первой версии, которая не уничтожает объект, поэтому нет соответственно возможности протестировать ее на практике, но что-то мне очень сомнительно, что-бы памяти очень много утекало. Она конечно будет, но так сказать не заметна не вооруженным глазом. Я например, работая с последней версией, в которой объект уничтожается сильно рано, по совету Хакера (сам бы вряд ли додумался ;) ) в самом начале работы с библиотекой, т.е. вызовом самой первой специальной функции создаю инстанс пустого класса и все - вуаля! Работает все очень хорошо и стабильно. Если утечка и есть, то такая незначительная, что это по сути и проблемой то не является.
н

Все, кто считают, что программа можно оставлять с утечкой, если утечка на заметна вооруженным взглядом, должны быть сожжены в печи :)

ger_kar писал(а):Все просто и почти гениально ;).

Это не гениально, а супер-тупо. Регистрация — это классно. А описанное полностью её убивает. Смысл регистрации в том, чтобы иметь 300 классов, у каждого из которых 500 версий, все эти верси реализованы в разных файлах, каждый файл где-то лежит, и нам не надо думать о файлах. Мы мыслим только ООП-категориями — классами.

И регистрировать сама свои компоненты программа сможет только если она — администратор.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 07.02.2012 (Вт) 21:26

terar писал(а):Тут какой момент. Для меня не проблема написать код, который будет делать то, что вы описали.
Да собственно в том то и дело, что такой код может сотворить практически каждый, но почему-то этот прием очень мало используется, а почему непонятно. Я например ничего плохого в этом не вижу, но может я и не прав, с моей маленькой колокольни, не такой уж и большой обзор ;) .
А...
Пока писал, появилось это
Хакер писал(а):Это не гениально, а супер-тупо. Регистрация — это классно. А описанное полностью её убивает. Смысл регистрации в том, чтобы иметь 300 классов, у каждого из которых 500 версий, все эти верси реализованы в разных файлах, каждый файл где-то лежит, и нам не надо думать о файлах. Мы мыслим только ООП-категориями — классами. И регистрировать сама свои компоненты программа сможет только если она — администратор.
Так и знал, что где то есть подвох. И если первое не очень существенно, то необходимость админской учетки это уже не есть гут.

terar писал(а):Более того, мне сейчас вообще непринципиально, как подгружается библиотека, работает (даже с утечкой памяти, у меня не будет 1000 загрузок подряд) и ладно.
Вот кстати интересно, при использовании версии с утечкой, эта утечка вообще хоть как-то заметна. Поделись наблюдениями.
terar писал(а):При выходе обновления замените библиотеку на новую". Если бы я ничего не понимал в программировании второй вариант мне бы как конечному пользователю понравился бы намного больше.
А он всем нравится больше, может кому-то и нравится регистрация, но я про таких не знаю. Конечно DirectX.dll может быть незаменима, но если проще использовать NativeDll, то это и надо юзать (ИМХО).
terar писал(а):Еще раз поблагодарю Хакера за FNDLL, лично мне она очень полезна. Да и узнал я много нового.

Советую прочитать и использовать это, классная штуковина.

Хакер писал(а):Все, кто считают, что программа можно оставлять с утечкой, если утечка на заметна вооруженным взглядом, должны быть сожжены в печи
Я согласен с этим тезисом, но только при одном условии, если есть утечка, эту утечку обнаружили, и ее можно устранить, но она из-за пофигизма или других проявлений человеческой натуры не устраняется, то это криминал. Но если это очень сложно или вообще невозможно устранить, как в случае FNDLL, то взвешивая выгоду от использования FNDLL с одной стороны и несущественную утечку с другой, то разница между первым и вторым настолько большая, что второе, можно вообще не принимать во внимание, как несущественное условие.
Бороться и искать, найти и перепрятать

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 08.02.2012 (Ср) 12:38

ger_kar писал(а):Вот кстати интересно, при использовании версии с утечкой, эта утечка вообще хоть как-то заметна. Поделись наблюдениями.

На фоне firefox.exe, который под себя сожрал полгигабайта и его plugin-container.exe еще на 300 мегабайт эта утечка незаметна вообще.

ger_kar писал(а):Все, кто считают, что программа можно оставлять с утечкой, если утечка на заметна вооруженным взглядом, должны быть сожжены в печи

Вот это характер!

ger_kar
Продвинутый гуру
Продвинутый гуру
Аватара пользователя
 
Сообщения: 1906
Зарегистрирован: 19.05.2011 (Чт) 19:23
Откуда: Кыргызстан, Иссык-Куль, г. Каракол

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение ger_kar » 08.02.2012 (Ср) 18:54

Это кстати не я писал, а Хакер, а я его только процитировал. Что касается меня, то я не настолько категоричен, а скорее даже наоборот :).
Бороться и искать, найти и перепрятать

terar
Начинающий
Начинающий
 
Сообщения: 8
Зарегистрирован: 04.02.2012 (Сб) 21:16

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение terar » 08.02.2012 (Ср) 20:18

Ой!
Моя ошибка. Поверьте не намеренная, конечно это я относил к хакеру.

jangle
Википедик
Википедик
Аватара пользователя
 
Сообщения: 2982
Зарегистрирован: 03.06.2005 (Пт) 12:02
Откуда: Москва

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение jangle » 07.03.2012 (Ср) 12:43

Вот еще один подобный проект http://vb.mvps.org/tools/vbAdvance/
Но там есть пример вызова нативных vb dll из сишного кода

Trink
Новичок
Новичок
 
Сообщения: 26
Зарегистрирован: 22.01.2014 (Ср) 11:47

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Trink » 22.01.2014 (Ср) 23:26

Еще одна статья на эту тему. http://www.cyberforum.ru/visual-basic/thread943581.html
Вызов DLL из другого ЯП. http://www.cyberforum.ru/visual-basic/t ... ost5362662

Хакер
Телепат
Телепат
Аватара пользователя
 
Сообщения: 16134
Зарегистрирован: 13.11.2005 (Вс) 2:43
Откуда: Казахстан, Петропавловск

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение Хакер » 23.01.2014 (Чт) 6:09

Trink писал(а):Еще одна статья на эту тему. http://www.cyberforum.ru/visual-basic/thread943581.html

Кому нужен этот шлак. Создание путём подмену линкера кто только не обсуждал. Но в этом случае нет инициализации рантайма и в таких DLL каждый шаг — как последний, ибо почти ничего сделать нельзя.
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.

TimVTimV
Начинающий
Начинающий
 
Сообщения: 1
Зарегистрирован: 20.02.2014 (Чт) 12:14

Re: [FireNativeDLL] Создание полноценных DLL на Visual Basic

Сообщение TimVTimV » 23.02.2014 (Вс) 8:34

Хакер писал(а):Разработка DLL
Далее, откроется проект, состоящий из обычного модуля и модуля класса. Вы можете работать с проектом как с обычной ActiveX-библиотекой, т.е. добавлять формы, модули, классы, ресурсы и т.д. в свой проект.

Добавлять формы можно и работать как с обычной activex библиотекой можно, а вот вызвать форму из полученной длл нельзя! Смысл всей этой поделки в чём? Не проще в блокноте dll написать?

Пред.След.

Вернуться в Наши проекты

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

    TopList