Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Во первых я уверен что таких случаев при _миграции_ х86 (тех... 17.07.09 21:28 Число просмотров: 5362
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 17.07.09 21:33 Количество правок: 3
|
> > Я занимался такой миграцией и не раз. Так вот во всех
> > случаях замена System32 на System64 была бы самым
> простым
> Я тоже. В случаях когда ДОСТАТОЧНО заменить system32 на
> system64 при текущем решении миграция сводится просто к
> перекомпиляции новым компилятором вообще без всяких
> изменений.
Во первых я уверен что таких случаев примиграциих86 (тех которые на х64 изначально не были рассчитаны) на х64 приложений ни у кого не было. Так что такое решение - подкова для сферического коня в вакууме.
Во вторых в конце концов банальный здравый смысл - System32 - для 32хбитных длл, system64 - для 64хбитных. А у вас сейчас внативной системе System32 - для 64битных, SysWOW64 - для 32битных. Офигенно интуитивно понятно:)
> > из всего что приходилось делать. Иногда надо просто
> > понимать что решать простейшие проблемы, создавая
> другие
> > потенциально более сложные - не стоит.
> С редиректом проблем нет. Или ты что то конкретное имеешь в
> виду?
Как программер говорю - это запутывает. Т.е. проблема не фатальная, просто из разряда "геморрой".
> Хорошо, у тебя есть x86 COM, хостящийся в отдельном
> процессе. Его пытается использовать x64 приложение.
> Регистрируем COM в двух отдельных ветках? А когда одна из
> веток изменяется? Копируем изменения? Вот тебе и рефлекшн -
> он появился именно из-за попытки сделать правильно (хранить
> действительно ОТДЕЛЬНЫЕ ветки для 32 и 64). Оказалось, что
> это создает больше проблем, чем решает - просто сделали
> одну ветку и отключили для нее перенаправление.
Рано или поздно, или вернее говоря точно поздно вы поймете что надо было без него вообще делать.
> > И надо понимать, что существует целый класс 32хбитных
> > приложений, которым перенаправление по сути поломало
> > функционал - файловые менеджеры. Т.е. работать они
> > работают, но пользоваться ими невозможно. Благодаря
> ????
> Не понял. Какие файловые менеджеры были поломаны?
Far, TC - нет доступа к настоящей system32. Т.е. я не могу ими ходить по всей файловой системе -> поломаны.
> > перенаправлению их нужно изменить и
>перекомпилировать
> > чтобы стало "хорошо". Если бы не было перенаправления
> -
> > изменения бы не требовались.
> Вот здесь я не понимаю проблемы. Серьезно. Где именно
> видишь проблемы ты?
Проблема в том что теперь когда программируешь требуется думать какой их HKLM\Software куда указывает. Есть сущность - ключ реестра. И есть ее имя. Имя на то и имя чтобы уникально идентифицировать сущность которую он означает. В данном случае за одним именем скрывается две сущности, в зависимости от того из какого кода ты его открываешь. Т.е. вот так вот просто ввели новый уровень косвенности при идентификации ресурса вместо того чтоб ввести новый идентификатор для новых ресурсов.
> > > Она получилась и с перенаправлением.
> > "Она получилась" == "Оно работает". Когда нету других
> > аргументов в пользу решения - этот лучше даже не
> приводить,
> "Она получилась" в данном случае означает "она была
> спроектирована именно для решения (в частности) данной
> задачи".
Понятно.
> > еще не раз пожалеете о нем. Как 3rd party ответственно
> > заявляю - от пернаправления только хуже :)
> Что именно с перенаправлением не так? Нативные для
> платформы (x64) приложения видят все как есть, для лигаси
> (x86) ввели тонкий слой ВИРТУАЛИЗАЦИИ. И те и другие, если
> знают о существовании друг друга, могут явным образом
> лазить в чужие ключи/каталоги. Что именно не так с пуском
> лигаси софта в виртуализованной среде я понять не могу.
С пуском лигаси софта все ок (не считая файлманагеров). Оба решения, и с редиректом и с симлинками одинавого были бы эффективны (для файлманагеров - симлинки были бы лучше). для него потому его вообще не рассматриваем.
Проблема как раз в написании нативного софта который, например, если имеет дело с легаси и нативным реестром теперь ему надо их отдельно идентифицировать. Скажем была тулза которая позволяла копировать ключи реестра или файлы между машинами. Она их идентифицирвоала путями. Теперь надо еще добавлять новый идентификатор - тип подсистемы. Ну это чисто абстрактный пример, реальные проекты в которых я сталкиваюсь с этой проблемой настолько системно-недокументированно-зависимы что ты офигеешь :) Вкратце - я сейчас работаю над продуктом который виртуализует ФС и реестр в юзермоде, и очень много поимел геморроя пока имплементил дубликат вашего рефлекшна/редирекшна на виртуальной ФС.
> > Тем что можно было без них. Кривизна - это когда
> лишние
> > сущности. И когда сущности не на своем месте.
> Сильно подозреваю, что ни ты ни я не знаем о всех usage
> scenario, которые брались в рассчет при проектировании
> данной фичи, так что "можно без них" - вряд ли (см
> простейший пример с COM-ами).
С комами я написал решение которое эквивалентно решению в вин7 но и без редиректа как такового.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
