информационная безопасность
без паники и всерьез
 подробно о проекте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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да нет, как раз с перенаправлением все правильно 17.07.09 06:49  Число просмотров: 4398
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> - Для FS тупо сделать %WINDIR%\System64. Все равно софт
> перекомпилять надо на 64 бита. А для 32битного софта просто
> оставили бы System32 как поступили когдато с 16битным
> System.
Потому что миграция с 32-битной платформы на 64-битную у кастомеров тоже не должна вызывать проблем. В идеальном случае должно хватать простой перекомпиляции x64 компилятором

> Те подкаталоги System32\System64 которые должны быть общими
> (есть вроде такие) - сделать NTFS reparse point'ами - благо
> виста только на NTFS жить умеет.
В случае перехода с Win16 на Win32 было сменено API и миграция приложений все равно была затруднена. Здесь API изменено не было, соотетственно искать во всех прогрммах захардкоженные System32 и менять их на System64 никому не надо - в МС совершенно дикие требования к обратной совместимости (вплоть до воркэраундов для хаков/багов в third-party коде)

> Если бы пошли таким путем, то получили бы полную бинарную
> совместимость с х86, под х64 совместимость бы была
Она получилась и с перенаправлением.

> благодаря новым константам в SDK -все равно под него
> старый код надо пересобирать.+ получили бы возможность по
> желанию доступаться к "чужим" ключам реестра и каталогам,
> просто явно указывая
Это тоже возможно в текущей ситуации.

> HKEY_LOCAL_MACHINE64/HKEY_LOCAL_MACHINE32 и
> System32/System64 без этих кривоAPI типа
> Wow64EnableWow64FsRedirection и.. о боже мой.. флажков в
> AccessMask RegCreate/OpenKey(Ex) которым вообще говоря
> самое место в dwOptions RegCreate/OpenKeyEx
Что в них кривого то?

> текущую кривохаковую архитектуру WOW64. (и кстати почему
Хм. Да нет там хаков. То что ты предлагаешь имеет такой же уровень "хаковости", но с тем что сделано еще и проблем с переходом гораздо меньше

> Wow64? Wow для 16битных апликух назывался Wow16, логично
> было бы сделать теперь Wow32..)...
Wow6432 вообще то.

> Такое ощущение что нынче развитием архитектуры ядра
> занимаются некоторые личности которые его существующую
> архитектуру не очень хорошо знают :) За Родину обидно (с).
> И Катлера;)
Бывают и не разбирающиеся, но к проектированию фич уровня wow6432 их никто не пускает :-), так что можешь быть уверен, что данное (компромиссное) решение было принято человеком, отлично разбирающемся в потрохах винды. А Катлер уже давно лазурными облаками занимается
<operating systems> Поиск 








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


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