Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[UPD] Нет. Делается это по большей части в ядре. 18.07.09 02:02 Число просмотров: 5589
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 20.07.09 19:48 Количество правок: 6
|
> > им вздумается. То есть по сути перенаправление это и
> есть
> > старые добрые симлинки, только реализованные в виде
> некого
> > захардкоженного в ядре алгоритма и усложненного
> доступа к
> > "спрятанным" объектам.
> Насколько я понимаю, все это делается полностью в юзермоде
> - при пересечении границы "виртуальной x86 машины" (как я
> уже говорил - параметры сисколов все равно конвертятся).
Нет. Делается это по большей части в ядре. По кр мере вроде как можно скормить те самые KEY_WOW64_*** флаги в NtOpenKey 64'битной версии - чтобы открыть 32'битный реестр.
Насчет FS не уверен, не дебажил, но подозреваю тоже в ядре. Тебе ведь проще - глянь сырцы и посмотри)
Если же и правда все это в юзермодной wow64 прослойке то это хоть что-то правильно сделано:)
К сожалению доступа к х64 системе до понедельника у меня не будет потому конкретно покопаться не могу.
[UPD] Порылся в registry redirection/reflection. Так вот redirection сделан в ядре, а reflection - в advapi32.dll :)
То есть оно оказывается еще и размазано тонким слоем :)
> > "точки обзора" ее рассматриваешь . Так вот редирекшн -
> это
> > совсем не эстетично. Просто на скорую руку слабанный
> > костыль, совершенно не обдуманный.
> Считай, что 32-битные приложения работают в собственной
> виртуальной машине с собтсвенным реестром и собственной ФС.
Но ведь это не так :) У них же все общее, кроме файлов и реестра - всякие мутексы, окна etc.
> > В том то и дело что если мне не нужны оба реестра,
> решения
> > с HKEY_LOCAL_MACHINE(32/64) было бы достаточно для
> > совершенно чистой миграции приложениявообщебез
> правки
> > чего либо. А если нужны оба -я бы просто написал
> > RegOpenKey(HKEY_LOCAL_MACHINE32, "Software...", ...)
> точно
> > так же как сейчас приходится писать
> > RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software...", ...
> > KEY_WOW64_32KEY)..
> Неправда же. Сейчас тебе приходится писать ДОПОЛНИТЕЛЬНЫЙ
> код только в специфичных случаях (когда 32-битному
> приложению по какой то причине нужны x64 ключи). Ты же
> предлагаешь сделать полностью обратное: заставить "платить"
> всех, чтобы специфичные случаи были удобнее.
Нет. Я предлагаю написать в winnt.h:
#ifdef _WIN64
# define HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE64
#else
# define HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE32
#endif
причем HKEY_LOCAL_MACHINE32 численно равно "старому" HKEY_LOCAL_MACHINE
так что код который не лезет в чужой реестр будет просто пользоваться HKEY_LOCAL_MACHINE
А кому нужен чужой - тот напишет HKEY_LOCAL_MACHINE32 или 64. Все просто и прозрачно и не требовало бы никаких изменений исходников при миграции. Просто пересобрать с новым SDK (что по любому требуется сделать)
> > Кстати для файловой системы тоже можно было бы сделать
> > раздельные симлинки для х64/х86 - и с тем же успехом
> > отправлять system32 SysWOW64 или System64 в
> зависимости от
> > контекста. Это было бы более декларативно
> (настраиваемо на
> > уровне FS) чем некий алгоритм в ядре который парсит и
> > подменяет какие то захардоженные пути.
> Какие симлинки? Вводить новый объект, новый атрибут в NTFS
> и пр.? Зачем, если все равно результат будет такой же: в
> зависимости от контектса тебя перенаправят по одному из
> путей.
Разница в том что это было бы декларировано на уровне атрибутов файлов/директорий (и управлялось бы на том же уровне, без привлечения специального API), а сейчас это декларировано на уровне кода в ядре (и добавлено специальное API для того чтобы этим кодом управлять).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
