информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеАтака на InternetГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Я тоже. в случаях когда достаточно заменить system32 на... 17.07.09 20:52  Число просмотров: 5521
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Я занимался такой миграцией и не раз. Так вот во всех
> случаях замена System32 на System64 была бы самым простым
Я тоже. В случаях когда ДОСТАТОЧНО заменить system32 на system64 при текущем решении миграция сводится просто к перекомпиляции новым компилятором вообще без всяких изменений.

> из всего что приходилось делать. Иногда надо просто
> понимать что решать простейшие проблемы, создавая другие
> потенциально более сложные - не стоит.
С редиректом проблем нет. Или ты что то конкретное имеешь в виду?
Хорошо, у тебя есть x86 COM, хостящийся в отдельном процессе. Его пытается использовать x64 приложение. Регистрируем COM в двух отдельных ветках? А когда одна из веток изменяется? Копируем изменения? Вот тебе и рефлекшн - он появился именно из-за попытки сделать правильно (хранить действительно ОТДЕЛЬНЫЕ ветки для 32 и 64). Оказалось, что это создает больше проблем, чем решает - просто сделали одну ветку и отключили для нее перенаправление.

> И надо понимать, что существует целый класс 32хбитных
> приложений, которым перенаправление по сути поломало
> функционал - файловые менеджеры. Т.е. работать они
> работают, но пользоваться ими невозможно. Благодаря
????
Не понял. Какие файловые менеджеры были поломаны?

> перенаправлению их нужно изменить иперекомпилировать
> чтобы стало "хорошо". Если бы не было перенаправления -

> изменения бы не требовались.
Вот здесь я не понимаю проблемы. Серьезно. Где именно видишь проблемы ты?

> > Она получилась и с перенаправлением.
> "Она получилась" == "Оно работает". Когда нету других
> аргументов в пользу решения - этот лучше даже не приводить,
"Она получилась" в данном случае означает "она была спроектирована именно для решения (в частности) данной задачи".

> еще не раз пожалеете о нем. Как 3rd party ответственно
> заявляю - от пернаправления только хуже :)
Что именно с перенаправлением не так? Нативные для платформы (x64) приложения видят все как есть, для лигаси (x86) ввели тонкий слой ВИРТУАЛИЗАЦИИ. И те и другие, если знают о существовании друг друга, могут явным образом лазить в чужие ключи/каталоги. Что именно не так с пуском лигаси софта в виртуализованной среде я понять не могу.

> Тем что можно было без них. Кривизна - это когда лишние
> сущности. И когда сущности не на своем месте.
Сильно подозреваю, что ни ты ни я не знаем о всех usage scenario, которые брались в рассчет при проектировании данной фичи, так что "можно без них" - вряд ли (см простейший пример с COM-ами).

> Wow6432, вернее Wow6432Node - это название ключа реестра. А
> так везде фигурирует Wow64.
Возможно. Тогда не знаю :-)
<operating systems> Поиск 






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


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