Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Для таких специфических проектов - да, придется приложению... 18.07.09 01:46 Число просмотров: 5138
Автор: amirul <Serge> Статус: The Elderman
|
> продолжать писать как писал - не выйдет, если надо писать
> х64 приложение которому требуется взаимодействовать с его
> же х86 частями (например длл с хуками которая грузится в
> х86 процессы)
Для таких специфических проектов - да, придется приложению "знать" об обоих ключах. Таких все таки меньшинство.
> Ты че. Не "без COM", а без перенаправления. Симлинки на
Ок. Просто там по контексту было непонятно
> новые ветки реестра были бы гораздо более наглядны для
> понимания чем некие алгоритмы в ядре которые работают как
Ну да. Надо либо заставлять вручную переписывать обращения к system32 в system64, либо автоматически редиректить. Можно было бы ввести специальный тип симлинка, который имеет разные таргеты при использовании из 32-бит и 64-бит процесса. Сильно сомневаюсь, что такое решение было бы значительно лучше.
> им вздумается. То есть по сути перенаправление это и есть
> старые добрые симлинки, только реализованные в виде некого
> захардкоженного в ядре алгоритма и усложненного доступа к
> "спрятанным" объектам.
Насколько я понимаю, все это делается полностью в юзермоде - при пересечении границы "виртуальной x86 машины" (как я уже говорил - параметры сисколов все равно конвертятся).
> Вот именно. Надоисправить_и_пересобрать А если бы этого
> перенаправления не было - не пришлось бы ничего
> пересобирать, все бы работало сразу и как надо.
Не все, а только far. Все остальное пришлось бы не просто пересобирать, а переписывать.
> Мне пофиг как чтото выглядит с т.з. приложения. Проблема в
> том что приложение не может использоваться для исполнения
> его основных функций - хождения по файловой системе, а
> значит оно -поломаноновой архитектурой. То что оно не
> падает не означает, что оно работает верно.
google://sysnative
http://www.nynaeve.net/?p=133
> "точки обзора" ее рассматриваешь . Так вот редирекшн - это
> совсем не эстетично. Просто на скорую руку слабанный
> костыль, совершенно не обдуманный.
Считай, что 32-битные приложения работают в собственной виртуальной машине с собтсвенным реестром и собственной ФС.
> В том то и дело что если мне не нужны оба реестра, решения
> с HKEY_LOCAL_MACHINE(32/64) было бы достаточно для
> совершенно чистой миграции приложениявообщебез правки
> чего либо. А если нужны оба -я бы просто написал
> RegOpenKey(HKEY_LOCAL_MACHINE32, "Software...", ...) точно
> так же как сейчас приходится писать
> RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software...", ...
> KEY_WOW64_32KEY)..
Неправда же. Сейчас тебе приходится писать ДОПОЛНИТЕЛЬНЫЙ код только в специфичных случаях (когда 32-битному приложению по какой то причине нужны x64 ключи). Ты же предлагаешь сделать полностью обратное: заставить "платить" всех, чтобы специфичные случаи были удобнее.
> Но в первом случае обращение к конкретному реестре
> декларируется как обычно - через его путь, а во втором (как
> сейчас реализовано) - почемуто через AccessMask, которая
> вообще для этого не предназначена. Это ACCESS_MASK которая
> проверяется с DACL объекта, а в нее впердолили (нет другого
> слова) еще и идентификацию объекта.
Согласен.
> Кстати для файловой системы тоже можно было бы сделать
> раздельные симлинки для х64/х86 - и с тем же успехом
> отправлять system32 SysWOW64 или System64 в зависимости от
> контекста. Это было бы более декларативно (настраиваемо на
> уровне FS) чем некий алгоритм в ядре который парсит и
> подменяет какие то захардоженные пути.
Какие симлинки? Вводить новый объект, новый атрибут в NTFS и пр.? Зачем, если все равно результат будет такой же: в зависимости от контектса тебя перенаправят по одному из путей.
> Проблемы такие что 32битные приложения взаимодействуют с
> 64хбитным. Welcome to real world :)
Ты предлагаешь переложить эту проблему на всех остальных?
Сейчас тебе нужно хорошо если для 1% приложений сделать условную компиляцию в зависимости от платформы, ты предлагаешь столкнуться с теми проблемами, которые решаешь ты в специфичной задаче ВСЕМ?
> честно говоря и мне спорить поднадоело :) все равно
> останемся при своих мнениях а винду уже никто не переделает
> - просто ярмо обратной совместимости у вас нынче стало
> значительно тяжелее :)
Вообще мне больше нравится XP Mode - там уже полноценная виртуальная машина для тех, кому надо, но во-первых wow64 появился еще в тукее, когда пускать виртуальные машины на обычных тачках было довольно рискованно, да и аппаратной виртуализации не было. Во вторых полная виртуализация той же видеокарты не слишком легкая задача, а консумерские x64 винды должны нормально запускать если не все, то хотя бы большинство 32-битных игр. Так и будут 32-битные приложения жить в собственной частично виртуализованной среде, пока их полностью не прибьют в какой нибудь Win2020. Собственно тот же ntvdm гораздо больше похож на wow6432, а не на XP Mode
|
|
|
подробно о проекте
Анализ криптографических сетевых... 
