Windows 8.1 with update Pro x64 Optim-Full (noAppx) [Ru]

Windows 8.1 with update Pro x64 Optim-Full (noAppx)

---

Версия программы: 6.3.9600
Официальный сайт: Майкрософт
Язык интерфейса: Русский
Лечение: Требуется, но отсутствует

Системные требования:
• Процессор: 1 гигагерц (ГГц) или больше
• ОЗУ: 1 гигабайт (ГБ) или больше
• Свободное место на жестком диске: от 12-ти ГБ
• Графический адаптер: графическое устройство Microsoft DirectX 9 или более новой версии
• Чтобы получить доступ к Магазину Windows для загрузки и запуска приложений, требуется активное подключение к Интернету и разрешение экрана не менее 1024 x 768 пикселей

Описание:
Полная (за исключением метро-приложений) сборка операционной системы Windows 8.1 на основе "Pro"-редакции из оригинального образа ru_windows_8_1_x64_dvd_2707370.iso.
Без удаления компонентов (ну почти), без непонятных твиков и настроек, без патчей и бонусов на рабочем столе, ни единой левой софтины.
Интегрированы актуальные обновления (кроме "Средство удаления вредоносных программ" и "Camera Codec Pack").
Система проходит проверку целостности sfc /scannow
Сборка должна удовлетворить самых требовательных сборконенавистников.

---

Скриншоты:


Время раздачи: по возможности.

У меня прошло со сборкой не так гладко .
Коротко о проблеме . ( i5 3450 , Н-77 , SSD (система 60гб) +HDD (500гб) + HDD(500Гб ) Озу 16Гб )
Игра Battlefield4 установлена на первом HDD , сетьевой игровой режим , запись Bandicam на второй HDD , приводит к полному прекращению процессов , как игры , так и записи .
Сборку ставил 3 раза , первый ознакомительный , второй - внимательная установка без возможных ошибок , третий - сам себя проверял . Проблема осталась .
Я уже сталкивался с проблемой сборок , при использовании нескольких физических дисков , у которых при обслуживании происходило удаление информации на других носителях .
В остальном проблем не было .
Сейчас установлена сборка с данного сетьевого ресурса , описанных проблем нет , все работает без нареканий .
Зачем написал этот пост ? просто сборка приглянулась , а я их опробовал от безделья полтора десятка. Сборка стояла 5 дней проблемы с закрытием процессов не решил .

IOpa26
интересную штуку рассказал, я даже не могу прикинуть как сборка (причем любая) может на это повлиять...
... переполнение памяти, уход диска в спячку... и проверить/повторить нет возможности.

Добавлено спустя 2 минуты:

Divet писал(а):

Мелкомягкие сами его обновили! Это ведь из вот этого исошника: ru_windows_8.1_professional_vl_with_update_x64_dvd_4050520.iso

я эти исошники не использовал. Порылся в них, и решил что лучше я буду отталкивать от первоначального августовского (хотя бы потому что в новых сидят уже устаревшие обновления).

Подскажите, а баг с неработающим спящим режимом при активной домашней группе решен?

pytex писал(а):

я эти исошники не использовал. Порылся в них, и решил что лучше я буду отталкивать от первоначального августовского (хотя бы потому что в новых сидят уже устаревшие обновления).

А вот такой вопрос, в какой последовательности лучше делать:

сначала оффлайн поудалять ненужные пакеты из смонтированного install.wim, потом установить Windows, потом обновить с виндовзапдейта

ИЛИ

сначала установить и обновить, а уж потом в режиме /Online удалять пакеты, чтобы удалились и файлы, пришедшие с обновами?

Ну и еще вопрос: если делаем /Cleanup-Image /StartComponentCleanup /ResetBase, то что будет, если позже мелкомягкие решат ОТОЗВАТЬ какое-либо обновление? Старое невозможно будет удалить? Что тогда будет?
С этими апрельскими образами именно такой случай?

Divet писал(а):

А вот такой вопрос, в какой последовательности лучше делать:

Тут лучше никак не делать, просто поставить систему из образа и пользовать ее. Зачем заранее усложнять, решать всегда лучше по мере появления конкретных проблем.

Виталий-33 писал(а):

Тут лучше никак не делать, просто поставить систему из образа и пользовать ее. Зачем заранее усложнять, решать всегда лучше по мере появления конкретных проблем.

По-моему, я обрисовал проблему: 8 Гб системный раздел, Windows 8.1 x64 со всеми обновлениями. Поскольку эти два условия находятся в некотором противоречии , его приходится решать, путем удаления ненужных компонентов Windows.
Кроме того, мне нужно не забывать и о том, ради чего этот системный раздел имеет такой малый размер в 8 Гб (он находится в ОЗУ), а именно, нужна скорость. Поэтому полностью удаляем такие компоненты, которые уменьшают скорость работы. К ним относятся все виды индексирования, оптимизации, защиты, восстановления и т. п. фоновые процессы.
Образа, хорошо отвечающего этим требованиям, пока не существует Но он находится в процессе создания. Работаю же пока на Windows 8.1 Professional x64 Optim от уважаемого pytex.

Divet
Вот что остается от системы из этого образа после удаления языков
Это с учетом подкачки 512+256 метров и дополнительных драйверов Ati-видео и звука.

Так что под 8 системных гигов подходит, да и изначально эта система занимает меньше 6 гигов.

Цитата:

Кроме того, мне нужно не забывать и о том, ради чего этот системный раздел имеет такой малый размер в 8 Гб (он находится в ОЗУ), а именно, нужна скорость.

А как, если не секрет, организована загрузка системы в ОЗУ?

Виталий-33 писал(а):

Вот что остается от системы из этого образа после удаления языков

Ну неплохо, но хорошо было бы еще на гиг-полтора уменьшить

Виталий-33 писал(а):

А как, если не секрет, организована загрузка системы в ОЗУ?

Так никаких секретов, рецепт уже некоторое время гуляет по сети, но обычно он перегружен ненужными вещами, а я буду краток
В ОЗУ читается с SSD веника 8-ми гиговый файл win81x64.vhd. Чтобы он читался, надо написать такой абзац:

map --mem-min=8G
map --mem /win81x64.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

- это текст файла menu.lst, который находится на загрузочном SSD вместе с этим vhd и еще одним файлом grldr, который вынут из пакета grub4dos-0.4.5c-2014-01-17.7z
А чтобы при загрузке искались эти два файла, а не bootmgr (коего на венике нет), надо обработать веник утилитой bootice (это один экзешник), которую придумал ipauly. Кнопочкой "Process MBR", настроить загрузку на grldr.
Всё, организация загрузки этим исчерпывается.

Файл vhd создан и использован стандартно, установка Windows в VHD. Только задаем его фиксированный размер чуть-чуть меньше, чем ровно 8192 Мб, например 8180.

В ОЗУ в результате он грузится выше 8 Gb (заполняя до 16 Gb), а все, что ниже - от 0 до 8 Gb - остается для работы системы.

Так, что я забыл. В VHD надо добавить bootmgr и папку boot с хранилищем BCD. Подойдет обыкновенное, только надо сделать, чтобы
device и osdevice были оба boot, плюс еще nointegritychecks чтобы был Yes.
И последнее, надо, как водится, очистить ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

Теперь точно все

Большое спасибо, ждём Lite x64

У меня закончился запрет на пост, поэтому могу отвечать дальше.

Divet

Divet писал(а):

А вот такой вопрос, в какой последовательности лучше делать: сначала оффлайн поудалять ненужные пакеты из смонтированного install.wim, потом установить Windows, потом обновить с виндовзапдейта ИЛИ сначала установить и обновить, а уж потом в режиме /Online удалять пакеты, чтобы удалились и файлы, пришедшие с обновами?

Сначала удаляем пакеты. Затем интегрируем обновы, можно оффлайн. Если пакетов в системе нет, то и лишнее из обновлений для этих пакетов не попадет в систему. Затем устанавливаем систему.

Добавлено спустя 3 минуты 13 секунд:

Divet писал(а):

Ну и еще вопрос: если делаем /Cleanup-Image /StartComponentCleanup /ResetBase, то что будет, если позже мелкомягкие решат ОТОЗВАТЬ какое-либо обновление? Старое невозможно будет удалить? Что тогда будет? С этими апрельскими образами именно такой случай?

Да, удалить будет невозможно. Решится это только если выпустят новое обновление с исправлением проблемы прошлого интегрированного.

Вы лучше подскажите как устранить глюк после восстановления системы акронисом - происходит почему то долгий запуск системы. Раз в шесть дольше.
Если до того система грузилась за 9-10 секунд, то после восстановления её из архива она стала грузиться почти минуту.(60 сек)
И это не только этой сборки конкретно.. но...

ded60let писал(а):

Вы лучше подскажите как устранить глюк после восстановления системы акронисом - происходит почему то долгий запуск системы. Раз в шесть дольше. Если до того система грузилась за 9-10 секунд, то после восстановления её из архива она стала грузиться почти минуту.(60 сек) И это не только этой сборки конкретно.. но...

тут дело не в акронисе. Все дело в обновлениях, по крайней мере у меня. Когда ставил чистую лайт сборку, все летало. Поставил сборку с обновами стало заметно тяжелее и запуск медленнее...(сам несколько раз восстанавливал акронисом - все пучком.)

pytex писал(а):

У меня закончился запрет на пост, поэтому могу отвечать дальше.

вас то за что банят

vlad1 писал(а):

(сам несколько раз восстанавливал акронисом - все пучком.)

Да я тож ... просто случайно заметил что ту же систему .. которая грузилась быстро сохранил... потом через время вернулся на неё... а присмотрелся, а она .... как в затяжном прыжке..... И так и этак, ни в какую..... Просто у меня в той системе стояла прога в авто запуске - BootRacer, которая все параметры загрузки пишет в лог и можно посмотреть.

ded60let писал(а):

vlad1 писал(а): (сам несколько раз восстанавливал акронисом - все пучком.) Да я тож ... просто случайно заметил что ту же систему .. которая грузилась быстро сохранил... потом через время вернулся на неё... а присмотрелся, а она .... как в затяжном прыжке..... И так и этак, ни в какую..... Просто у меня в той системе стояла прога в авто запуске - BootRacer, которая все параметры загрузки пишет в лог и можно посмотреть.

а вы попробуйте свежеустановленную ось забекапить и сравните, времени то у вас навалом

Времени то и нет.... ни кто не знает сколько отмерил ОН нам.. Я нарисовал проблему... просто сами обратите на это внимание.. а потом подумать надо.. и найти причину.