информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
А почему нельзя было: 17.07.09 02:34  Число просмотров: 4373
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 17.07.09 02:47  Количество правок: 4
<"чистая" ссылка>
> > Понравилось что избавились от registry reflection в
> x64.
> Ага. И почему нельзя было сразу сделать перенаправление с
> исключениями. Ведь дублирование данных ВСЕГДА в конце
> концов ведет к их "декогеренции".
А почему нельзя было:
- Для реестра просто ввести константы HKEY_LOCAL_MACHINE64/ HKEY_LOCAL_MACHINE32
В Win32\SDK: дефайнить HKEY_LOCAL_MACHINE на 32 или 64 в зависимости от текущего target machine.
В Kernel\DDK добавить хивы:
\REGISTRY\MACHINE_WOW64, \REGISTRY\USER\{SID}_Classes_WOW64
Общие подключи \REGISTRY\MACHINE и \REGISTRY\MACHINE_WOW64 (то бишь все кроме Software) сделать через симлинки, которые есть в реестре ядра NT начиная с первых ее версий. Сам функционал симлинок расширить, введя возможность задачи раздельных линок для 64 бит и для 32х. Благо делов то - нынешние линки создаются через задание value REG_LINK SymbolicLinkValue="путь", А 64хбитные создавать SymbolicLinkValue64="путь". Это позволит пененаправить HKEY_CURRENT_USER\Classes в \REGISTRY\USER\{SID}_Classes для нативных и в \REGISTRY\USER\{SID}_Classes_WOW64 для x86 апликух. И т.д. и т.п.

- Для FS тупо сделать %WINDIR%\System64. Все равно софт перекомпилять надо на 64 бита. А для 32битного софта просто оставили бы System32 как поступили когдато с 16битным System.
Те подкаталоги System32\System64 которые должны быть общими (есть вроде такие) - сделать NTFS reparse point'ами - благо виста только на NTFS жить умеет.

Если бы пошли таким путем, то получили бы полную бинарную совместимость с х86, под х64 совместимость бы была благодаря новым константам в SDK -все равно под него старый код надо пересобирать.+ получили бы возможность по желанию доступаться к "чужим" ключам реестра и каталогам, просто явно указывая HKEY_LOCAL_MACHINE64/HKEY_LOCAL_MACHINE32 и System32/System64 без этих кривоAPI типа Wow64EnableWow64FsRedirection и.. о боже мой.. флажков в AccessMask RegCreate/OpenKey(Ex) которым вообще говоря самое место в dwOptions RegCreate/OpenKeyEx

> > Его еще не уволили? :)
> У not kernel guy-а спроси - он вроде бы конкретно в той
> тиме работает :-)
Да както лень там регаться, писать пост etc.. Все равно уже поздно переделывать - уже тысячи приложений заложились на текущую кривохаковую архитектуру WOW64. (и кстати почему Wow64? Wow для 16битных апликух назывался Wow16, логично было бы сделать теперь Wow32..)...
Такое ощущение что нынче развитием архитектуры ядра занимаются некоторые личности которые его существующую архитектуру не очень хорошо знают :) За Родину обидно (с). И Катлера;)
<operating systems> Поиск 








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


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach