Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
продолжать писать как писал - не выйдет, если надо писать... 18.07.09 00:31 Число просмотров: 5321
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 18.07.09 00:41 Количество правок: 1
|
> > Как программер говорю - это запутывает. Т.е. проблема
> не
> > фатальная, просто из разряда "геморрой".
> Да просто продолжай писать как писал и все. Что именно
> запутывает?
продолжать писать как писал - не выйдет, если надо писать х64 приложение которому требуется взаимодействовать с его же х86 частями (например длл с хуками которая грузится в х86 процессы)
> > Рано или поздно, или вернее говоря точно поздно вы
> поймете
> > что надо было без него вообще делать.
> Без кого? Без COM? Здесь ты неправ. Можно, конечно
> представить себе (с позиций текущего опыта) более хорошее
> решение, но насчет полной ненужности чего нибудь COM
> (CORBA/XPCOM) подобного ты неправ. ЗНАЧИТЕЛЬНО облегчает
> связывание гетерогенных сред исполнения.
Ты че. Не "без COM", а без перенаправления. Симлинки на новые ветки реестра были бы гораздо более наглядны для понимания чем некие алгоритмы в ядре которые работают как им вздумается. То есть по сути перенаправление это и есть старые добрые симлинки, только реализованные в виде некого захардкоженного в ядре алгоритма и усложненного доступа к "спрятанным" объектам.
> > > Не понял. Какие файловые менеджеры были поломаны?
> > Far, TC - нет доступа к настоящей system32. Т.е. я не
> могу
> > ими ходить по всей файловой системе -> поломаны.
> Ну FAR можно и под x64 пересобрать (правда с legacy
> плагинами проблемы будут), а можно и вообще редирекшн прямо
Вот именно. Надоисправить_и_пересобрать А если бы этого перенаправления не было - не пришлось бы ничего пересобирать, все бы работало сразу и как надо.
> в main-е (а можно и в плагине каком нибудь - все равно ж
> per-process) отключить, но блин, разве sysnative кто то
> отменял? С точки зрения 32-битного приложения все ВЫГЛЯДИТ
> в точности как ты рассказываешь. Или у тебя опять претензии
> к названию?
Мне пофиг как чтото выглядит с т.з. приложения. Проблема в том что приложение не может использоваться для исполнения его основных функций - хождения по файловой системе, а значит оно -поломаноновой архитектурой. То что оно не падает не означает, что оно работает верно.
> > > Вот здесь я не понимаю проблемы. Серьезно. Где
> именно
> > > видишь проблемы ты?
> > Проблема в том что теперь когда программируешь
> требуется
> > думать какой их HKLM\Software куда указывает. Есть
> сущность
> > - ключ реестра. И есть ее имя. Имя на то и имя чтобы
> > уникально идентифицировать сущность которую он
> означает. В
> Если ты программируешь согласно гайдлайнам МС, то тебе об
> этом думать как раз не надо. То есть не надо думать
> 32-битным компилятором ты будешь свой проект компилировать
> или 64-битным. Не нужно густо обмазывать код условной
> компиляцией с выбором разных строк для разных платформ. Ты
> просто пишешь так же как писал всегда.
Вот тут то и начинается вся фишка. Если программировать "согласно гайдлайнам" и ни о чем не думать оно конечно да. Но вот я уж так устроен что вначале пытаюсь понять высокоуровневую логику системы, и как бы так выразиться, ее эстетичность. Эстетичность системы в какой то мере выражается явной декларативностью ее поведения (как можно меньше алгоритмических special cases в коде) и инвариантностью ее архитектуры по отношению к тому с какой "точки обзора" ее рассматриваешь . Так вот редирекшн - это совсем не эстетично. Просто на скорую руку слабанный костыль, совершенно не обдуманный.
> > данном случае за одним именем скрывается две сущности,
> в
> > зависимости от того из какого кода ты его открываешь.
> Т.е.
> Когда ты запускаешь программу в виртуальной машине и она
> открывает свою виртуальную system32 тебе это тоже не
> нравится? Вроде название одно, а сущности разные.
>
> > С пуском лигаси софта все ок (не считая
> файлманагеров). Оба
> Создай в эксплорере пустой %SystemRoot%\sysnative
>
> > Проблема как раз в написании нативного софта который,
> > например, если имеет дело с легаси и нативным реестром
> > теперь ему надо их отдельно идентифицировать. Скажем
> была
> Здесь как раз упор на обратное. ТОЛЬКО если тебе нужны оба
> этих реестра (то есть твоя программа и так знает о них
> обоих) тебе нужно беспокоиться о разнице.
В том то и дело что если мне не нужны оба реестра, решения с HKEY_LOCAL_MACHINE(32/64) было бы достаточно для совершенно чистой миграции приложениявообщебез правки чего либо. А если нужны оба -я бы просто написал RegOpenKey(HKEY_LOCAL_MACHINE32, "Software...", ...) точно так же как сейчас приходится писать RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software...", ... KEY_WOW64_32KEY)..
Но в первом случае обращение к конкретному реестре декларируется как обычно - через его путь, а во втором (как сейчас реализовано) - почемуто через AccessMask, которая вообще для этого не предназначена. Это ACCESS_MASK которая проверяется с DACL объекта, а в нее впердолили (нет другого слова) еще и идентификацию объекта.
Кстати для файловой системы тоже можно было бы сделать раздельные симлинки для х64/х86 - и с тем же успехом отправлять system32 SysWOW64 или System64 в зависимости от контекста. Это было бы более декларативно (настраиваемо на уровне FS) чем некий алгоритм в ядре который парсит и подменяет какие то захардоженные пути.
> > Вкратце - я сейчас работаю над продуктом который
> > виртуализует ФС и реестр в юзермоде, и очень много
> поимел
> > геморроя пока имплементил дубликат вашего
> > рефлекшна/редирекшна на виртуальной ФС.
> Рефлекшн мне самому не нравится. Редирекшн решает именно ту
> задачу, для которой создавался - поддержка 32-битных
> приложений с одновременным облегчением миграции. Ну считай,
> что 32-битные приложения исполняются в виртуальной машине,
> у которой реестр не такой, как в хост-системе. Какие
> проблемы?
Проблемы такие что 32битные приложения взаимодействуют с 64хбитным. Welcome to real world :)
> ЗЫ: Я не то, чтобы против твоего решения (я бы вполне мог
> собрать все условно компилируемые вещи в один файл при
> необходимости), просто я не вижу чем же оно ЛУЧШЕ текущего.
честно говоря и мне спорить поднадоело :) все равно останемся при своих мнениях а винду уже никто не переделает - просто ярмо обратной совместимости у вас нынче стало значительно тяжелее :)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
