Доброе время суток, коллеги !

Хочу обсудить на форуме одну интересную тему. Предлагаю оставить пока за кадром полемику типа "а кому и для чего все это нужно". Как говориться, jedem das seine...
Итак, проблема - заменить одну из системных и загруженных в данный момент (это важно!) DLL Windows своей собственной. Либо системной оригинальной, но чуть-чуть видоизмененной - это кому что ближе ;-). Покопавшись в статьях и ссылках, я, к сожалению, так и не смог найти удовлетворительного решения. В официальной документации Microsoft сказано, что для подобных целей следует использовать файл wininit.ini для семейства Windows 9X и API MoveFileEx() для семейства Windows 2000-XP. Обобщением такого подхода может служить вызов функции SetupInstallFile(Ex) из SETUPAPI.DLL, которой нужно только указать source и destination, а всю остальную рутинную работу она берет на себя.
Но! Проведя с успехом подготовку к замене системной DLL, мы сталкиваемся с (вроде бы как) непреодолимым барьером : System File Protection ! После перезагрузки, когда процесс обновления DLL должен вступить в свою завершающую стадию этот код ( расположенный, как я понимаю, в SFC.DLL ) нагло перечеркивает все наши старания и усилия. Причем лично я наблюдал сей эффект только под Windows Millenium и XP - под Windows 98 и Windows 2000 вызов SetupInstallFile успешно решал задачу.
В чем же тогда дело ? Я пробовал вручную изменять версию DLL в ресурсах (якобы на более свежую), игрался с датой/временем создания файлов, однако это не помогало.
В одном из выпусков журнала 29-A (кажется в 5-м) я вычитал такую идею : вместе с модифированием системной
DLL автор предлагал также "подправить" и "виновника всех бед" - саму SFC.DLL. Однако, по ряду причин этот подход выглядит далеко не идеальным, скорее вынужденной, крайней мерой. И самая главная причина кроется в необходимости лезть напрямую по фиксированному смещению в код DLLки , которая вовсе не обязана быть одинаковой (скорее наоборот)для всех версий и под-версий Windows...
В общем, буду рад, если кого-то этот вопрос заинтересует.

С уважением,
VetabetA

Тема очень интересная. И действительно, по ссылкам тоже ничего удовлетворительного не видел. Поэтому прости, VetabetA, но готового решения тебе дать лично я не смогу - пока не нашел. Общая идея по этому поводу у меня - обращаться к файлу DLL с максимально возможными привелегиями, может быть Винды (если таковое вообще возможно) либо даже больше. Если она общается с файлами библиотек по общему своему стандарту, значит должен где-то быть хендл требуемой библиотеки. Вариант, если определить этот хендл и попробовать использовать далее? Я пока рою в этом направлении. (Не знаю, может и ошибочном?) Пытаюсь найти точку открытия файла системной ДЛЛ при загрузке Винды и посмотреть, есть ли хендл и, если есть, куда он помещается.
Буду благодарен, если кто-то подскажет уже проверенный надежный вариант решения проблемы.
С ув., Bazed

хм, заменить системную dll на свою ??? У меня был подобный опыт но только под win98. Значит, системные dll загружены в Shared M. Причём по строго фиксированному смещению. Насколько мне известно ни студия, и дельфа не позволяет откомпелить подобный тип Dll. Менять в бинарнике BaseImage тоже не советую да и это глупо. Ну, а с теми, что отображаются в контекст процессов ниже 2Гб без проблем прокатили, поскольку соответственно имеют секцию релакации для настройки адресов на новую базу. В системных dll ничего подобного я так и не нашёл.

секцию релакации для настройки адресов на новую базу. В системных dll ничего подобного я так и не нашёл.

Разве в системных dll нет релоков?