информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Во первых я уверен что таких случаев при _миграции_ х86 (тех... 17.07.09 21:28  Число просмотров: 4460
Автор: 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 но и без редиректа как такового.
<operating systems> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach