C>2. Или уж не проще ли тогда хук поставить причем именно на поток, который грузит ДЛЛ?
Хук на что можно в этот момент поставить? На создание окошка?
C>И не мудрить с перехватом, зачем недокументированное что-то юзать?
Кстати перехват выполняется с помощью tool-help функций (CreateToolhelp32Snapshot, Process32First, Process32Next, Module32First, Module32Next, etc.) и с помощью функций и структур для работы с PE образами (например ImageDirectoryEntryToDataEx, PIMAGE_SECTION_HEADER, PIMAGE_IMPORT_DESCRIPTOR, PIMAGE_THUNK_DATA, etc.), ну и конечно таких функций как VirtualProtectEx, VirtualQueryEx и так далее, т.е., как видите, используется исключительно опубликованное и легальное Win32 API, ничего недокументированного здесь нет. А в случае, если всё это проходит в рамках собственного процесса, и вы никуда не внедряете свой код и не роетесь в чужих адресных пространствах, то никаких проблем с Integrity барьерами, межпроцессным взаимодействием и Security не будет происходить, и такое приложения даже без проблем пройдёт Microsoft Windows Vista Сертификацию.
C>1. можно поюзать функцию SetErrorMode!
Согласен.
C>Не-е-е! Не катит! Уж больно глобальное решение — влияет на все в пределах процесса, чем такое может кончиться боязно и подумать :)
:):)
Ну это вы, Carc, совсем уж армагеддоный случай описываете. PATH именно потому и проверяется последней, потому что в PATH может лежать всякого левого мусора. Плюс я добавлял директорию в PATH чтобы искать свои собственные DLL'ки, которые уникальны и где-попало валяться не будут, и делалось это просто для удобства, чтобы в LoadLibrary писать не полный путь к библиотеке, а только её имя.
C>Если поставить еще одну директорию в PATH, то одному господу богу, где, и как, и кто может загрузиться за компанию.
Ну это означает только лишь то, что добалять директори в PATH надо с умом. Если ты добавляешь в PATH директорию %PROGRAM_FILES%\MyApp\PluginModules, где лежат пара/тройка ваших собственных DLL и более ничего, то никакой соседний код никакой мусор туда не загрузит.
C>Трабла с SetCurrentDirectory была мрачно автоматизирована в стиле идиомы "владелец ресурса" C>class CAutoDirectory C>CAutoDirectory directory_owner(strNewDir);
Интересное решение, главное только чтобы после создания и до разрушения объекта directory_owner не выполнялся код, который может сломаться, или отработать некорректно, при смене текущей диретории. Ведь в этом месте потенциально может выполниться код, который "одному господу богу известно" что сможет загрузить за компанию, в том числе и "какое-нить мс-офисное барахло", и вообще весь вышеописанный армагеддон, помноженный на то, что CurrentDirectory имеет намного больший приоритет чем PATH.
C>В моем случае искомая библиотека была в недрах Common Files\Microsoft Shared.
Согласен, что такую директорию добавлять в PATH опасно :):)
Но изначально речь шла не о RichEd20.DLL, а о собственных DLL, которые хочется разместить не всей кодлой в одной с приложением директории, а разбить их логически по sub-директориям. Это видно, если почитать ветку с самого начала. В таком случае, конечно что SetCurrentDirectory решение, что GetEnvironmentVariable/SetEnvironmentVariable решение подойдут более чем, однако, имхо: правильнее будет использовать Side-by-side механизмы в таких случаях.
На самом деле, что решения с помощью SetCurrentDirectory, что решения с помощью GetEnvironmentVariable/SetEnvironmentVariable — есть ужасно кривые способы борьбы с ужасной проблемой под названием DLL-Hell. И применялись эти решения исключительно до тех пор, пока Microsoft не предоставила "нормальный" механизм решения проблем DLL-Hell'а: Isolated applications и Side-by-side assemblies. Лично я использовал GetEnvironmentVariable/SetEnvironmentVariable до тех пор, пока не открыл эту ветку на rsdn, где Юрий Жмеренецкий подсказал мне
приложения: до этого я в манифестах ссылался только на shared assemblies (CRT/ATL/MFC/Common-Controls/etc.), теперь, я делаю собственные private сборки и на них же ссылаюсь в манифесте приложения. И это легальный документированный путь, который прекрасно работает без переписывания PATH и без перемещений туды/сюды текущей директории процесса.
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
C>>2. Или уж не проще ли тогда хук поставить причем именно на поток, который грузит ДЛЛ? R>Хук на что можно в этот момент поставить? На создание окошка?
C>>И не мудрить с перехватом, зачем недокументированное что-то юзать? R>Кстати перехват выполняется с помощью tool-help функций (CreateToolhelp32Snapshot, Process32First, Process32Next, Module32First, Module32Next, etc.) и с помощью функций и структур для работы с PE образами (например ImageDirectoryEntryToDataEx, PIMAGE_SECTION_HEADER, PIMAGE_IMPORT_DESCRIPTOR, PIMAGE_THUNK_DATA, etc.), ну и конечно таких функций как VirtualProtectEx, VirtualQueryEx и так далее, т.е., как видите, используется исключительно опубликованное и легальное Win32 API, ничего недокументированного здесь нет. А в случае, если всё это проходит в рамках собственного процесса, и вы никуда не внедряете свой код и не роетесь в чужих адресных пространствах, то никаких проблем с Integrity барьерами, межпроцессным взаимодействием и Security не будет происходить, и такое приложения даже без проблем пройдёт Microsoft Windows Vista Сертификацию.
1) Угу — только нафига весь этот мудреж с перехватом, который не шибко нравится всяким антивирям, если можно мрачно поставить хук и сделать все тоже самое!?! К чему выпендреж то?
2) Код загрузки конкретной ДЛЛ — это очень глубокий код, в конкретном приложении может быть зарыто ох как глубоко. И на тебе нах, есть нюанззз — оказывается там в недрах живет перехват... И о чудо, вдруг выясняется что другой разработчик в другом конце приложения тоже учинил перехват — и вдруг возникают какие-то ошибки взаимодействия 2-ух перехватов!?! И дело тут только в одном: людям свойственно ошибаться, а значит рано или поздно ошибемся. Каким образом можно вкурить, что загрузка ДЛЛ приводит к перехвату — пока в этот код носом не упрешься в голову не придет.
Собственно все это о том, зачем городить такой огород, который содержит потенциальные возможности ошибок, причем ошибок очень неприятных тем, что причина косячка в одном месте, а вылезает косячок совершенно на другом конце приложения. И более того, не в напрочь просветленному мужу и не придет в голову что LoadLibrary ведет к проблеме? На кой сложность, если можно проще?
C>>1. можно поюзать функцию SetErrorMode! R>Согласен.
C>>Не-е-е! Не катит! Уж больно глобальное решение — влияет на все в пределах процесса, чем такое может кончиться боязно и подумать R> R>Ну это вы, Carc, совсем уж армагеддоный случай описываете. PATH именно потому и проверяется последней, потому что в PATH может лежать всякого левого мусора. Плюс я добавлял директорию в PATH чтобы искать свои собственные DLL'ки, которые уникальны и где-попало валяться не будут, и делалось это просто для удобства, чтобы в LoadLibrary писать не полный путь к библиотеке, а только её имя.
Согласен — не спорю, несколько частный случай привел. Мне не нравится вариант с PATH тем, что
а) Влияет на весь процесс
б) Влияет раз и навсегда (ну по идее ставим переменную один раз и не убираем ее, так?)
Глобализация ведет к лишним, а главное не то чтобы неявным, а весьма и веьсма глубоко зарытым зависимостям, которые неизвестно каким боком, когда и куда стрельнут — а если ружо на стене висит, то ружно рано или поздно все-таки пальнет
А т.к. такие зависимости еще и глубоко зарытые, то с отладчиком наперевес придется рыться в коде ну очень долго ибо неясно откуда вообще проблема.
А т.к. зависимость на весь процесс — то еще и весь код перерыть придется (включая код сторонних ДЛЛ)
C>>Если поставить еще одну директорию в PATH, то одному господу богу, где, и как, и кто может загрузиться за компанию. R>Ну это означает только лишь то, что добалять директори в PATH надо с умом. Если ты добавляешь в PATH директорию %PROGRAM_FILES%\MyApp\PluginModules, где лежат пара/тройка ваших собственных DLL и более ничего, то никакой соседний код никакой мусор туда не загрузит.
C>>Трабла с SetCurrentDirectory была мрачно автоматизирована в стиле идиомы "владелец ресурса" C>>class CAutoDirectory C>>CAutoDirectory directory_owner(strNewDir); R>Интересное решение, главное только чтобы после создания и до разрушения объекта directory_owner не выполнялся код, который может сломаться, или отработать некорректно, при смене текущей диретории. Ведь в этом месте потенциально может выполниться код, который "одному господу богу известно" что сможет загрузить за компанию, в том числе и "какое-нить мс-офисное барахло", и вообще весь вышеописанный армагеддон, помноженный на то, что CurrentDirectory имеет намного больший приоритет чем PATH.
Нет, не совсем так.
Если код с C++ exception — то объект гарантировано разрушиться, и вернет свою прежнюю директорию. Ну а если мы ловим SEH исключение (и не ждем его, не обрабатываем), то тут и разговаривать не о чем — код уже понесло как лося по болоту, тут о каком-то дюже правильном выполнении программы вообще говорить не приходится.
Согласен с Вами что вся это моя муть с Set\GetCurrentDirectory — должна быть написана максимально аккуратно.
Но, есть одно "но" — вся эта муть происходит на стеке в конкретной функции, поэтому нужно очень аккуратненько спроектировать функцию, все остальное от этого решения не зависит. Имхо, это лучше, чем бороться с последствиями каких-то глобальных настроек для всего процесса, выставленных на весь сеанс работы. Потенциально, имею ввиду, лучше.
C>>В моем случае искомая библиотека была в недрах Common Files\Microsoft Shared. R>Согласен, что такую директорию добавлять в PATH опасно R>Но изначально речь шла не о RichEd20.DLL, а о собственных DLL, которые хочется разместить не всей кодлой в одной с приложением директории, а разбить их логически по sub-директориям. Это видно, если почитать ветку с самого начала. В таком случае, конечно что SetCurrentDirectory решение, что GetEnvironmentVariable/SetEnvironmentVariable решение подойдут более чем, однако, имхо: правильнее будет использовать Side-by-side механизмы в таких случаях.
ОК, не спорю — немного отклонились.
А что мне даст Side-By-Side?
R>На самом деле, что решения с помощью SetCurrentDirectory, что решения с помощью GetEnvironmentVariable/SetEnvironmentVariable — есть ужасно кривые способы борьбы с ужасной проблемой под названием DLL-Hell. И применялись эти решения исключительно до тех пор, пока Microsoft не предоставила "нормальный" механизм решения проблем DLL-Hell'а: Isolated applications и Side-by-side assemblies. Лично я использовал GetEnvironmentVariable/SetEnvironmentVariable до тех пор, пока не открыл эту ветку на rsdn, где Юрий Жмеренецкий подсказал мне
приложения: до этого я в манифестах ссылался только на shared assemblies (CRT/ATL/MFC/Common-Controls/etc.), теперь, я делаю собственные private сборки и на них же ссылаюсь в манифесте приложения. И это легальный документированный путь, который прекрасно работает без переписывания PATH и без перемещений туды/сюды текущей директории процесса.
Здравствуйте, Carc, Вы писали: C>+1 А вот за ссылки, спасибо! :up:
:):):)
... вообще-то эти ссылки ведут к истоку данного треда мессаг.
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
R>Здравствуйте, Carc, Вы писали: C>>+1 А вот за ссылки, спасибо!
R> R>... вообще-то эти ссылки ведут к истоку данного треда мессаг.
Чего то я зарапортовался Всё — хорош кодить, переходим к пункту "Разное"
По моему вы тут намешали проблему поиска црт/мфс/атл через манифесты и проблему загрузки нужных длл при обычном подходе
загрузка длл через манифесты апи функция или переменными окружения не управляется в принципе
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Carc, Вы писали:
C>1) Угу — только нафига весь этот мудреж с перехватом, который не шибко нравится всяким антивирям, если можно мрачно поставить хук и сделать все тоже самое!?! К чему выпендреж то?
На сколько мне известно антивирям он не нравится только тогда, когда вы пытаетесь это сделать в рамках чужого процесса, и то только потому, что вы для этого должны внедрить в этот чужеродный процесс свой модуль, и антивири ругаться будут именно на это. В рамках же своего процесса все эти действия по перехвату есть вполне легальные действия и никакой антивирь, или кто-либо вообще, не имеет право на меня материться. + ИМХО: установка хуков есть не меньший выпендрёж!
C>2) Код загрузки конкретной ДЛЛ — это очень глубокий код, в конкретном приложении может быть зарыто ох как глубоко. И на тебе нах, есть нюанззз — оказывается там в недрах живет перехват... И о чудо, вдруг выясняется что другой разработчик в другом конце приложения тоже учинил перехват — и вдруг возникают какие-то ошибки взаимодействия 2-ух перехватов!?! И дело тут только в одном: людям свойственно ошибаться, а значит рано или поздно ошибемся. Каким образом можно вкурить, что загрузка ДЛЛ приводит к перехвату — пока в этот код носом не упрешься в голову не придет.
Речь идёт не о перехвате функций LoadLibrary*(), а речь идёт о перехвате функций MessageBox*(). При этом я не вижу никаких проблем с тем, что в другом конце приложения другой разработчик тоже учинил перехват. В таком случае раньше перехват получит выполнение тот, кто по ходу выполнения программы первым устанавливает перехватчик, затем второй выполнение получит второй перехватчик, и так далее. Вот и всё. Если какой-либо из перехватчиков решит оборвать цепь вызовов (т.е. не вызовет в своём коде оригинальную функцию), то остальные управления, понятно, не получат. Но извините по большому счёту в HOOK'ах поведение то же самое: та же цепочка перехватов, так же один item этой цепи может её прервать.
Если честно, вообще не вижу никакой идеологической разницы между установками HOOK'ов, и перехватами вызовов функций, экспортируемых из некой длл. Что одно, что другое — суть хуки. Только реализация отличается.
Я просто хочу сказать, что и один и другой способ одинаково легальны, и если они одинакого могут решить конкретную задачу, то какой из способов выбрать лично вам и лично мне, это уже, извините, спор о том "какой вам цвет больше нравится".
И вообще, мне кажется, что наше обсуждение о том, что именно лучше/удобнее/проще/нагляднее/etc., хуки aka "HOOKS" или хуки aka "Перехват API вызовов", — есть флуд: ветка совсем о другой теме.
C>Если код с C++ exception — то объект гарантировано разрушиться, и вернет свою прежнюю директорию.
Нет, выше шла речь об армагедоне во время выполнения функции, создающей объект directory_owner. Там ведь с таким же успехом может отработать скрытый от глаз, где-то в недрах какого-то API, отработать код, который будет пользоваться этой текущей директорией. Я просто говрю, что опастнось армагеддона там не меньшая, а наоборот большая, т.к. CurrentDirectory имеет намного больший приоритет чем PATH. Дописывая в конец локальной переменной PATH, вы не перекрываете ничего. Меняя текущую директорию, вы перекрываете не только PATH, но и "Системный каталог Windows", "Основной каталог Windows", и всё, что находится в PATH. И таким образом что-то, что лежит в вашей "новой" текущей директории, начинает угрожать намного большему количеству модулей , а особенно системным модулям, что, согласитесь опаснее!
C>Согласен — не спорю, несколько частный случай привел. Мне не нравится вариант с PATH тем, что C>а) Влияет на весь процесс C>б) Влияет раз и навсегда (ну по идее ставим переменную один раз и не убираем ее, так?)
Я согласен, что установка текущей директории влияет на работу только одной функции, а не всего процесса. Это, вообще-то, — очевидно.
Я говорю о другом. Смотря что именно прописывать в PATH.
Если "Common Files\Microsoft Shared", тогда да, это жопа. В таком варианте контролировать текущую директорию намного безопаснее чем, прописывать это добро в PATH.
Если "%PROGRAM_FILES%\MyApp\PluginModules", содержание которой вы контролируете, то никакой жопы здесь нет. И добавить эту директорию в PATH будет намного удобнее, чем контролировать текущую директорию процесса. Кроме того, контролируя переменную PATH, вы работаете с самым последним звеном списка поиска модулей, а это значит потенциально менее вероятна опасность перекрыть какой-нибудь важный системный модуль (это, конечно, всё в виду соображений о наступившем армагедеце, который Вы рисуете).
C>Глобализация ведет к лишним, а главное не то чтобы неявным, а весьма и веьсма глубоко зарытым зависимостям, которые неизвестно каким боком, когда и куда стрельнут — а если ружо на стене висит, то ружно рано или поздно все-таки пальнет
С другой стороны "зубов бояться, в рот не ...", т.е переменную PATH может загадить всяким непотребом не только свой процесс, получить мусор можно от процесса-родителя, если какую-нибудь какашку пропишут в системную PATH. Поэтому длительные часы отладки вы можете получить и без ковыряния локально-процессной переменной PATH. И, думаю, именно поэтому переменную PATH разработчики Windows засунули в самый конец списка поиска модулей, ибо она редактируема как локально, так и глобально.
C>А что мне даст Side-By-Side?
В конкретно вашем случае поиска RichEdit20.DLL — абсолютно ничего. И собственно, чтобы порешать проблему DLL-HELL'а, вам ничего не остаётся, кроме контроля над текущей директорией процесса либо контроля над локальной переменной PATH.
В конкретно моём случае размещения собственных модулей в подпапках директории приложения, Side-By-Side избавляет меня от этих двух корявых методов борьбы с Dll-Hell'ом. Собственно говря, именно для этого я и создавал эту ветку форума.
:)
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Kingofastellarwar, Вы писали:
K>По моему вы тут намешали проблему поиска црт/мфс/атл через манифесты и проблему загрузки нужных длл при обычном подходе K>загрузка длл через манифесты апи функция или переменными окружения не управляется в принципе
Да нет же. Если у меня приложение MyApp.exe в результате линковки зависит от ToolDll1.dll, ToolDll3.dll и ToolDll3.dll, то я могу поместить их в подпапку "ToolAssembly", с помощью манифестов объявить её private assembly, опять же с помощью манифестов сослаться на сборку "ToolAssembly" в MyApp.exe.manifest, и моё приложение разрешит все свои зависимости без каких бы то ни было манипуляций с PATH или Current Dir. Это собственно то, что мне и нужно дабы не городить всякие корявости с помощью GetEnvironmentVariable/SetEnvironmentVariable или с помощью GetCurrentDirectory/SetCurrentDirectory.
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
R>Здравствуйте, Carc, Вы писали:
C>>Согласен — не спорю, несколько частный случай привел. Мне не нравится вариант с PATH тем, что C>>а) Влияет на весь процесс C>>б) Влияет раз и навсегда (ну по идее ставим переменную один раз и не убираем ее, так?) R>Я согласен, что установка текущей директории влияет на работу только одной функции, а не всего процесса. Это, вообще-то, — очевидно. R>Я говорю о другом. Смотря что именно прописывать в PATH. R>Если "Common Files\Microsoft Shared", тогда да, это жопа. В таком варианте контролировать текущую директорию намного безопаснее чем, прописывать это добро в PATH. R>Если "%PROGRAM_FILES%\MyApp\PluginModules", содержание которой вы контролируете, то никакой жопы здесь нет. И добавить эту директорию в PATH будет намного удобнее, чем контролировать текущую директорию процесса. Кроме того, контролируя переменную PATH, вы работаете с самым последним звеном списка поиска модулей, а это значит потенциально менее вероятна опасность перекрыть какой-нибудь важный системный модуль (это, конечно, всё в виду соображений о наступившем армагедеце, который Вы рисуете).
C>>Глобализация ведет к лишним, а главное не то чтобы неявным, а весьма и веьсма глубоко зарытым зависимостям, которые неизвестно каким боком, когда и куда стрельнут — а если ружо на стене висит, то ружно рано или поздно все-таки пальнет R>С другой стороны "зубов бояться, в рот не ...", т.е переменную PATH может загадить всяким непотребом не только свой процесс, получить мусор можно от процесса-родителя, если какую-нибудь какашку пропишут в системную PATH. Поэтому длительные часы отладки вы можете получить и без ковыряния локально-процессной переменной PATH. И, думаю, именно поэтому переменную PATH разработчики Windows засунули в самый конец списка поиска модулей, ибо она редактируема как локально, так и глобально.
PATH еще редактируема через ветку реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. Ниже можно обнаружить множество программ, например firefox.exe и excel.exe, которые, кроме полного пути к исполняемому файлу (в параметре по умолчанию), объявляют параметр Path, содержимое которого будет добавлено в переменную Path при запуске процесса.
И хотя указание Path в этой ветке не влияет на порядок поиска DLL, используемый по умолчанию, это позволяет запускать exe файл через команду Run/Выполнить, не указывая полного пути. А добавление Path к системной PATH позволит exe файлу загрузить необходимые библиотеки.
Стоит отметить, что начиная с Windows XP SP2, текущий каталог просматривается после всех системных, как раз перед тем, как искать в PATH, при условии, что включен SafeDllSearchMode (по умолчанию включен, начиная с Windows XP SP2). Это отодвигает текущий каталог почти в самый низ поиска, и можно словить трудно отлавливаемые баги, если вдруг Required.dll загрузится из системных путей, а не из текущего каталога.
A>Стоит отметить, что начиная с Windows XP SP2, текущий каталог просматривается после всех системных, как раз перед тем, как искать в PATH, при условии, что включен SafeDllSearchMode (по умолчанию включен, начиная с Windows XP SP2). Это отодвигает текущий каталог почти в самый низ поиска, и можно словить трудно отлавливаемые баги, если вдруг Required.dll загрузится из системных путей, а не из текущего каталога.
Внимательно читаем что я написал выше:
LoadLibrary(полный_путь_к_DLL); //чтобы не искала одноименные ДЛЛ где бы то ни было
Так что пофиг порядок поиска для одноименных ДЛЛ в системных папках. Фокусы с SetCurrentDirectory применялись в вышенаписанном для другой проблемы...
R>При этом я не вижу никаких проблем с тем, что в другом конце приложения другой разработчик тоже учинил перехват. В таком случае раньше перехват получит выполнение тот, кто по ходу выполнения программы первым устанавливает перехватчик, затем второй выполнение получит второй перехватчик, и так далее. Вот и всё. Если какой-либо из перехватчиков решит оборвать цепь вызовов (т.е. не вызовет в своём коде оригинальную функцию), то остальные управления, понятно, не получат. Но извините по большому счёту в HOOK'ах поведение то же самое: та же цепочка перехватов, так же один item этой цепи может её прервать.
В написанном ошибка. Здесь, конечно же имеется в виду, что тот кто позже во время выполнения устанавливает перехватчик, тот раньше получает управление при вызове перехватываемой функции. Т.е. порядок вызовов перехватчиков обратный порядку их инсталляции.
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, alexyv, Вы писали: A>Стоит отметить, что начиная с Windows XP SP2, текущий каталог просматривается после всех системных, как раз перед тем, как искать в PATH, при условии, что включен SafeDllSearchMode (по умолчанию включен, начиная с Windows XP SP2). Это отодвигает текущий каталог почти в самый низ поиска, и можно словить трудно отлавливаемые баги, если вдруг Required.dll загрузится из системных путей, а не из текущего каталога.
Я, кстати, был уверен, что со времён Win2k алгоритм поиска неизменен, и не знал, что, начиная с Windows XP SP2, во время работы SafeDllSearchMode'а текущая директория перемещается со второго (начиная сверху) списка поиска DLL на пятое место (т.е. предпоследний пункт). В виду этого манипуляции с текущей директорией процесса конечно же становятся менее опасными в силу уменьшения их приоритета.
, меня лично огорчило.
Единственное, что мне непонятно, почему Side-By-Side механизм не подчиняется обычным правилам поиска DLL, а обязывает assembly лежать рядом с модулем, для которого разрешаются зависимости (в случае с private assembly), либо обязывает assembly лежать WinSxS директории (в случае с public assembly). Было бы очень удобно добавлять дополнительные директории поиска в алгоритм поиска SxS-загрузчика. Например, что-то вроде локально-процессной переменной окружения SxS-PATH или что-то вроде этого. Т.е. возникает такое ощущение, что механизм SxS ещё достаточно сырой, и возможно, разработчики Microsoft будут в будущем расширять эту функциональность.
Хотя — хз, если по сей день от Microsoft'а так и не дождались "толкового решения" проблемы Dll-Hell (а время-то уже сколько прошло!), вряд ли от Microsoft'а можно этого ожидать в ближайшем будущем.
Короче, сидят и пинают они в рабочее время, вместо того чтобы усовершенствовать Core операционки, а не добавлять в новые версии тучу красивостей. Слава богу, хоть Windows Security обновили, и то хорошо.
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
R> Было бы очень удобно добавлять дополнительные директории поиска в алгоритм поиска SxS-загрузчика. Например, что-то вроде локально-процессной переменной окружения SxS-PATH или что-то вроде этого.
Для динамически загружаемых модулей перед вызовом LoadLibrary можно сформировать необходимый контекст активации с помощью CreateActCtx:
ACTCTX::lpAssemblyDirectory
The base directory in which to perform private assembly probing if assemblies in the activation context are not present in the system-wide store.
Всё — хорош кодить, переходим к пункту "Разное" 
