Darth_Vader
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Oleg_Kurilin
Цитата:| Причем тут ядра? Файл сна загружает загрузчик, переходит в рабочий режим и передает управление образу, и если загрузчик 32-х разрядный, то и режим будет аналогичный, а с 64-ч разрядным, соответственно. |
Ядра как раз определяют все: нельзя ведь запустить образ сеанса 64-битовой системы для 32-битовой на винте, и не сможешь даже для другой ("неродной") 32-битовой.
Что касается совместимости загрузчика - тут есть ограниченная совместимость, а именно - обратная: 64-битовый лоадер спокойно грузит любые образы и просто ОС, 32-битовый - не может грузить ни 64-битовую ОС, ни ее образ хибернейта. Протестировано (что и требовалось доказать).
Цитата:| А уж определить какой режим был (какое ядро было загружено) это задача не невыполнимая, хоть по флагам, хоть по сигнатурам, хоть парсить содержимое |
Определить-то можно, но мы грим здесь о том что ты не заставишь ОС (файло на винте) работать с "чужим" образом ОС из ОЗУ, и наоборот... немного надо уточнить механизм хибернейта: сохраняется ли где-либо, кроме hiberfil.sys, информация о том что система была введена в состояние спячки - имеется в виду, какие-либо флаги/маркеры в реестре или файловой структуре ОС на винте, читается ли это загрузчиком при инициализации образа? Иб0 если да, тогда еще можно предположить возникновение "путаницы".
По идее, ВСЕ должен решать образ в памяти: там же хранятся дескрипторы файлов, инфа о том откуда ОС грузилась и где ее файло лежит...
Но это теория, а на практике мну не возникало никаких проблем с разными ОС ни на одном разделе, ни на разных.
Кстати, о маркетинге  В ридми к х64 грицца, что 16-битовые сетупы и приложения не работают вообще, кроме движка инсталлера M$ ACME. Именно такой сетуп использовался в приснопамятных M$ Office 9x, а я лично для себя до сих пор пользуюсь 97-м. Захотелось сендя переставить офис по-нормальному, чтобы не было ругательств на реестр и VBA - запускаю, здрасте вам: приложение не может быть запущено на данной архитектуре. Совершенно по наитию захожу в \Clipart, запускаю сетуп лежащий там - грит, давайте ставиться. Опять же, по гнусному подозрению копирую \Clipart\setup.exe в корень дистрибутива, и шо би ви уже таки думали? Офис ставится без единой ошибки. Типа, некрософт решил: раз есть деньги на такую вынь и на такое железо - найдутся и на офис-2003, нефиг мол 97-ми баловаться 
ALL
VirtualISO, кстати - не поставил, иб0 оно требует .NET Framework v.2.0 для х64, а тот весит 47 метров. Щас тяну, поскольку полезно иметь в системе свежак (пусть и бету) популярного рантайма последней версии, да еще и с поддержкой как 64- так и 32-разрядных приложений, вместо 1.1 только для 32-битовых.
CaptainFlint
Знач так, специально высвободил место на Ё: и доставил туда копию обычной винды, включил там и там хибернейт и попробовал потыкаться туда-сюда... нифига: при загрузке тебю выбора ОС просто не выводится, а при нажатии F8 в процессе восстановления состояния предлагается продолжить восстановление, либо удалить данные и вывести тебю загрузки.
Чтобы установить 32-битовый загрузчик (NT Loader), тебе не нужны ни fixboot, ни тем более fixmbr, иб0 не ст0ит путать загрузочную запись и загрузочный сектор с загрузчиком - гругря, программой осуществляющей выбор и загрузку одной из ОС в соответствии с настройками, в случае с NT Loader это файл ntldr и конфиг boot.ini.
Т.е. ты можешь взять ntldr от старой винды и положить его в корень вместо существующего, только после этого х64 грузиться не сможет...
Цитата:| А что при этом вообще происходит? В каждом из этих двух режимов. И зачем нужен режим S1&S3? |
S1 - это старый режим усыпления, в котором железо программно переводится в состояние энергосбережения АТ, соответствующее ACPI State 1, потому и кулера вращаются и все такое... S3(STR) = ACPI State 3, работа устройств "приостановлена", питание подается только на RAM, соответсно содержимое памяти сохраняется до "пробуждения". За процедуры ввода железа в состояние ACPI S3 и вывод из него отвечает ACPI BIOS, поскольку ни ОС, ни загрузчик этот процесс контролировать не могут. Для поддержки ACPI S3 необходима полная поддержка этого режима со стороны ОС, BIOS, системной платы, всех и каждого из устройств и каждого из драйверов устройств. Скажем, NT4 не поддерживала ACPI, и драйверы устройств от NT4, будучи установлены на ХР/2К, например если "родных" дров на конкретный девайс для этих ОС просто нет в природе - блокируют возможность ввода системы в S3 Standby.
----------
На самом деле, я очень добрый. Только никто этого не знает. А те кто догадались - уже никому ничего не расскажут... |
|
Кстати, Winimage уже есть в 64-битовых версиях, причем давно. 
