VadiMGP wrote: |
я неграмотный программист |
VadiMGP wrote: |
Большинство моих знакомых программистов, которые пишут dll, независимо от их уровня грамотности, заглядывают в MSDN ... DllMain с параметром DLL_PROCESS_ATTACH вызывается только один раз для каждого процесса, а значит тут-то, как правило, и делают инициализацию всех данных |
Quote: |
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions)… Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination… Do not call the registry functions… do not call malloc… Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions in their DLLs call LoadLibrary to load other system components. Conversely, calling those functions during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized…Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes. Deadlocks may occur as a result. |
Quote: |
DllMain с параметром DLL_PROCESS_ATTACH вызывается только один раз для каждого процесса |
Quote: |
This function was added by request from a user who needs to unload GDI+. It seems that GDI+ has a bug which makes it crash when unloading it in the DLL unload function, therefore a separate unload function is needed. |
VadiMGP wrote: |
Я бы в данном случае не стал париться |
VadiMGP wrote: |
Но эти дядьки не знают, что может прийти грамотный программист и скопировать dll в другую директорию, создав, тем самым, ситуацию, когда будет две попытки загрузить один и тот же dll из разных мест. Хотя ему, конечно, известно, что такое Dll Hell и, стопроцентно, он знает, что при этом DllMain с DLL_PROCESS_ATTACH будет вызван повторно для того же dll в том же процессе |
B4rr4cuda wrote: |
CdDataBase метров 20 весит. И храню я её в каталоге плага.
Что-то такое может быть и в каталоге wdx плага. Ситуация конечно теоретическая, но возможная. |
Dec wrote: |
Не допонял. Почему для того же dll? Ведь после копирования это физически будет другая dll. |
Dec wrote: |
В этом же MSDN паписано: |
Dec wrote: |
Повторюсь, что мы не знаем, какой код помещает разработчик в процедуры инициализации и финализации, которые, по его мнению, должны вызываться только один раз. И мы не знаем, к чему приведет их повторный вызов. |
Quote: |
разумеется мало-мальски опытный программист не будет в DllMain вставлять ни коммуникацию, ни межпоточную синхронизацию ни загрузку других dll |
Athari wrote: |
а куда совать инициализацию, общую для всей библиотеки? |
Quote: |
А что такое #pragma start? Что-то не припоминаю такой. |
VadiMGP wrote: |
Если я правильно понял, ты хочешь работать с WDX плагинами, так же, как SuperWdx, InfoPacker, WDXGuide и т.д.
В практическом плане никто из них, пока, ни на какую проблему (связанную с многократной загрузкой!) не наткнулся. |
VadiMGP wrote: |
Если мое предположение было верным ... |
VadiMGP wrote: |
В практическом плане никто из них, пока, ни на какую проблему (связанную с многократной загрузкой!) не наткнулся. |
VadiMGP wrote: |
на мой взгляд, ничего вообще делать не надо пока не столкнешься с каким-то плагином, который будет делать траблы. В этом случае он потребует специфического обслуживания, но какого именно - будет известно, только после того, как станет ясно какую именно проблему он создает. |
VadiMGP wrote: |
1. Очень нехилый объем работы. |
VadiMGP wrote: |
Насколько я вижу, протокол связи должен включать в себя весь WDX API! Отсюда вытекает следующий минус.
2. Вечная гонка за версией API. А что будет завтра, когда Гислер добавит к API пару функций или флажков? |
VadiMGP wrote: |
3. Когда запускать эту прожку-прослойку? |
VadiMGP wrote: |
Если же запускать ее однократно, сразу при загрузке твоего плагина, то возникает куча вопросов. а) Как прожка должна узнать что в ТС изменились переменных окружения? Ведь плагин может ими пользоваться. |
VadiMGP wrote: |
б) Как реализовать одновременную работу нескольких копий ТС?.
в) Как быть если ТС слетел (а значит и твой плагин тоже) и был загружен заново? |
VadiMGP wrote: |
4. Если плагин работает с сallback, то я, пока, вообще не вижу способа осуществить его для плагина, загруженного в прожку. Тут раздельные адресные пространства только мешают. |
VadiMGP wrote: |
5. Все равно будут плагины, которые потребуют отдельной обработки. Media.wfx показывает диалог на вызов значения поля. Есть плагины, которые не желают работать не из ТС. |
Dec wrote: |
Возможно, они просто не видны, а отлично скрываются за try…except…end. |
Dec wrote: |
Во втором случае даже если я брошу проект, то новые плагины для нового API должны работать по принципу обратной совместимости. |
Dec wrote: |
В WDX нет функций с сallback. |
Dec wrote: |
Ну что поделать, красота требует жертв. |
VadiMGP wrote: | ||
|
VadiMGP wrote: | ||
|
VadiMGP wrote: |
Кстати, если я правильно помню, твой плагин реализует GetLocalName, так? Интересно, что будет, если в ТС будет разрешен диалог атрибутов файла для "виртуальных панелей".
|
Dec wrote: |
В исключении нет ничего страшного, я не считаю его появление неправильным ходом работы. |
Dec wrote: |
Я имел ввиду, что новые плагины будут работать без поддержки новой функциональности.
|
Dec wrote: | ||
|
VadiMGP wrote: | ||
|
VadiMGP wrote: |
В меню ТС есть пункт File->Change Attributes. Он вызывает диалог атрибутов файла, и в этом диалоге можно отображать и редактировать поля из WDX-плагинов. Сегодня этот диалог работает только для "обычных" файлов на диске и не работает в FS-плагинах. Мне видится вполне вероятным, что Гислер добавит вызов такого диалога для "виртуальных панелей", то есть, когда плагин держит ссылки на реальные файлы. |
Dec wrote: |
Проблемы с новым WDX интерфейсом появятся, только если я перестану поддерживать проект, |
Dec wrote: |
Недопонимаю сути проблемы. |
Dec wrote: |
Кстати, если Ghisler добавит возможность редактирования атрибутов файлов для "виртуальных панелей", то он вероятно добавит и настраиваемые колонки, что я и пытаюсь сделать. |
output generated using printer-friendly topic mod. All times are GMT + 4 Hours