[addon] Утилита конструктор TextMode MassStorage-аддона (конструктор)
 

Mr dUSHA, тоесть утилита делает нечто похожее на ScanInf.exe от Boa Soft ? Можно ли и как ее юзать совместно с z_drv_inst ?

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

Boa Soft, Да и z_drv_inst надо уже давно доработать для работы с ини/инф файлами как работает Башратовский интегратор!

хорошая идея!

Mr dUSHA, Boa Soft, - если Вы объедените свои услилия в написании нового интегратора драйверов, ИМХО, башратовско-нлайтные интеграторы будут курить всторонке :biggrin:

ЗЫ: Хочеца чтоб данная утилита работала в купе с интегратором от Boa Soft а ни возникло двух независымых проектов....

Мы и так многое вместе раскапываем. Просто на данный момент утилита Mr dUSHA подготавливает файлы только для интеграции драйверов текстового режима. Совместить и сейчас не проблема, но с отказом от мультизагрузки. Достаточно будет только батник доработать.

Н-лайт, как оказалось - единственный интегратор, обрабатывающий еще и setupreg.hiv и HIVE для GUI этапа.

По поводу аддона. Скорее всего, силы пойдут на доработку GUI интегратора. Потому, что сделать совмещение мультибута и интеграции драйверов для средствоми пакета для меня достаточно сложно. А в GUI-интеграторе это занимает намного меньше кода. Суть - дравера интегрируются тогда, когда все обновления уже внесли изменения в дистрибутив, подготавливая сразу папки для мультизагрузки. Потом идет интеграция мультизагрузки. После этого уже не вносятся изменения в файлы дистрибутива.

Аддоном все сделать вполне реально. При соблюдении двух условий.

1. Аддон обьединяется с мультизагрузочным.
2. Аддон ВСЕГДА должен быть последним (после него - только утилита для создания iso, но и ее можно включить в аддон)

Или, второй вариант, внести небольшие изменения в __PATCH.CMD - по сути, вызывать интеграцию драйверов уже после отработки основного пакета.

Boa Soft,
как мне думается 2 вариант проще

Обновил версию.
Добавил автосоздание стандартного аддонового Финишера, который интегрирует ключи реестра из setupreg.reg в куст реестра setupreg.hiv дистрибутива.

Люди, чёто я не понял. А мануальчик по её юзанию будет? Если её использовать то получается винда сама будет подбирать дрова т.е режима выбора нету? Mr dUSHA, плизз напиши мануальчик или пример. Куда эти файлы XTSETUP, DOSNET, HIVE, FINISH, setupreg.reg, critical.inf потом ложить?

Mr dUSHA, где кнопка, чтобы высказать вам 1000 благодарностей? :) Неужели, наши проблемы с nVidia наконец-то решатся...?
Теперь по делу - как утилита обрабатывает inf-ы с закомментированными ( ; ) строчками? У меня совпадающие HWIDы закомментированы... Как она подружится с интегратором от Башрата?

Boa Soft, спасибо, что напомнили как называется этот файл - setupreg.hiv. А то я вспоминал, вспоминал. :)

Painkiller, причем тут окошко выбора драйверов, которое вылазит в начале графического этапа установки? Утилита предназначена для интеграции драйверов для текстового этапа установки.

Утилита почти на 100 процентов для парсинга inf-файлов использует "движок" из setupapi.dll, так что обрабатывает такие строки так же, как и сама операционная система, тоесть пропускает :-)
Кроме того поддерживаются inf-файлы в юникодовой кодировке.

Понятия не имею. Интегратором Башрата не то что никогда не пользовался, а и не видел его никогда...
Сейчас найду, скачаю, посмотрю, как он хоть выглядит...

Mr dUSHA, там (в интеграторе) есть такая фишка - можно отключить интеграцию для текстового режима. Я так понимаю, ей и стоит воспользоваться?

И еще, почему ваша программа обрезает &&SUBSYS_ ? Они не важны?

И еще раз еще. :) Какие файлы меняются/добавляются (полный список, если можно) в чистый дистрибутив при интеграции Z_MSST?

Воспользовался - сработало. Только описания в секции [SCSI] не понравились - сменил на Башратовские. :)

Обновил версию, в которую добавил параметр "-S" , отключающий обрезку SUBSYS-ов (если конечно вам от этого будет какая-то польза...). Но ИМХО для драйверов текстового этапа SUBSYS-ы - лишнее.


TXTSETUP, DOSNET - эти я вам не обьясняю, и сами знаете ;)

HIVE - вносит параметры в ветку реестра "HKLM,"SYSTEM\CurrentControlSet\Services\..." в уже собраный в самом конце текстового этапа настоящий живой реестр для начала графического этапа установки, и последующего использования ОСью.

setupreg.reg - с помощью скрипта FINISH вносит изменения в реестр текстового этапа установки setupreg.hiv. Вносятся те же параметры, что и HIVE

Mr dUSHA, т.е. вы хотели сказать так: в каталоге I386 после интеграции меняются файлы: dosnet.inf, txtsetup.sif и setupreg.hiv и добавляется файл hivepck.inf и сами файлы драйверов (*.sys). Я правильно вас понял? Или я чего-то упустил?

Обновлена версия.
Добавлено создание стартового скрипта START, производящего упаковку SYS-файлов драйверов при первом использовании аддона в составе UpdatePack.

Совершенно верно. Только эти файлы изменяются.

Обновлено

Исправлена ошибка в скрипте START, из-за которой не создавались сжатые файлы драйверов в папке "Files\ForceCopy" аддона во время интеграции его.

Boa Soft, Mr dUSHA, хотелось бы увидеть кроме переработанного движка интегратора еще и чисто косметические изменения, облегчающие жизнь, например как упомянул Samlab отдельные файлы настроек для каждого драйверпака... Или хотя бы скрипт который их объединяет в один и автоматически нумерует секции. У меня этих секций в finish.ini более сотни, хлопотно каждый раз нумерацию переделывать после обновления... Могу и еще пожелания высказать только надо составить список :)

Debugger, а что так много? Этот аддон разумно использвать для всего нескольких контроллеров, с остальными нет проблем и при использовании обычного интегратора (Башрата или Boa Soft).

YikxX, я имел в виду если этот проект и интегратор сольются в один... А так в итоге и будет скорее всего.

Народ, а ктобы мог озвучить конкретные контроллеры, для которых необходимо вносить твики реестра текстового этапа установки ?
ЗЫ: Хотелось бы знать конкретно на каком железе потестить данную утилиту, ибо со всем железом (его ксожалению не особо много) что проходило через мои руки проблем подхвата HDD в режиме AHCI установщиком ХРюши не возникало....

Dilinjer, у меня прописывает для ATI (SB6xx и SB7xx) и для nVidia (для тех, где используется драйвер nvgts.sys)

YikxX, То есть вы уже успешно испытали инструмент? (так как это не аддон, и проверить самому не на чем)

Поделитесь опытом успешной интеграции :drug:

Компы и ноуты с южником SB700 от AMD-ATI (т.н. платформа Puma) - уже 3 удачных установки. :)
RAID от nVidia - данных нет, пока некому проверить, а мне не на чем.
AHCI от nVidia (MCP67-M) - увиделся винт, который раньше виделся лишь после интеграции дров nLite'ом. Однако все зависло при попытки создания папки Windows (подозреваю, что из-за того, что ставил на раздел D: - а он остался еще от висты и не одна прога для разбивки диска (кроме Акрониса) этот раздел как NTFS не воспринимают).

К сожалению, если диск был размечен при установке Vista, часто единственное возможное решение - полная очистка диска (mhdd, diskpart > clean) и создание разделов заново из установщика XP или другим методом.

Mr dUSHA, тут один товарищ столкнулся с интересной проблемой - синий экран 0х000007B у него вылетает перед запуском графического этапа установки, на текстовом этапе винт и разделы на нем видятся отлично. Такое вообще бывает? Как лечится? Разделы все он удалял, MBR фиксил... Комп - Acer Aspire M3640 (MCP73PV)

Вы сразу скажите, это после аддона от моей утилиты, или вы вообще, по теме спрашиваете? :)


Сам синий экран 0х000007B означает то, что (образно и грубо говоря) системой не был найден подходящий драйвер для монтирования загрузочного диска.

Дело в том, что на начальном этапе загрузки (который выполняет NTLDR) работа с загрузочным томом осуществляется через функции дискового ввода/вывода BIOS-а компьютера. Причем на этом этапе работа с загрузочным томом осуществляется в режиме "только чтение".

Далее, когда запускается само ядро, запускает кучу своих диспетчеров и инициализирует все загрузочные минипорт-драйверы, в этот момент загрузочный том должен быть смонтирован в режим "чтение-запись", но для этого ввод-вывод с диска с загрузочным томом должен производиться посредством минипорт-драйвера дискового контролера, к которому подключен диск, и уже без использования функций BIOS компьютера.
Если в этот момент система либо не может найти нужный драйвер, либо сам драйвер не может найти свой контролер или диск, то вы и видите тот самый синий экран 0х000007B.
(Это конечно при условии, что разметка диска на разделы верна :) Но у вас, как я понял это уже было проверено...)

На текстовом этапе установки, установщик запоминает, какой драйвер использовался для подключения диска, на который производится установка, и в конце текстового этапа, после компиляции реестра из HIVE-файлов, в реестр также заносится информация о необходимости загрузки этого драйвера при следующем старте системы (а это будет уже графическая стадия установки). Если драйвер был добавлен через "F6", то в реестр также заносятся все специфические настройки драйвера из его файла txtsetup.oem. Кроме того сам этот драйвер копируется в папку \Windows\System32\Drivers.

Так что виновником, в данном случае, скорей всего является некорректная интеграция драйвера в дистрибутив, либо кривизна самого драйвера.... Хотя, если на текстовом этапе диск видится, и файлы с дистрибутива нормально копируются на диск, то технически драйвер уже ИМХО рабочий.

Ну конечно же после вашей утилиты, иначе зачем я бы спрашивал тут? :)
Я склоняюсь к тому же.
Я забыл добавить в txtsetup.sif команду на обработку файла hivepck.inf - дело, как я понимаю, в этом?

Да, конечно в этом.
Утилита ведь формирует HIVE-файл, и если вы интегрируете его не с помощью движка UpdatePack-а, а руками, то конечно это надо сделать обязательно, тогда увидится винт.
Как вариант, чтоб не пересобирать дистриб, можно загрузиться с WinPE (или подключить винчестер к другому компьютеру), подключить реестр SYSTEM из устанавливаемой системы, и внести соответствующий ключ в реестр руками, а потом запустить устанавливаемую ОСь, которая тогда продолжит установку.

Mr dUSHA, я патчу образ с помощью UltraISO (то есть именно этот патч, который ручками делается, для этого используется) но все равно спасибо за совет. А WinPE у меня нету... :)

У меня тоже удачные установки (ноуты Asus X50Z), причем при использовании интегратора драйверов от Boa Soft и DP_MassStorage 8.05 (драйвер на SB700 обновлял сам).
RAID и AHCI проверить могу, ибо каждый понедельник собираю компы. Все предложения в личку (сам я с аддоном из этой темы пока еще не разбирался).

А можно совместить? Тоже выложить для теста. Заодно может еще какие подводные камни найдутся, в дальнейшем легче будет.

Обновлена версия утилиты

Новое в текущей версии:
1. Добавлены новые ключи командной строки для возможности генерации аддона только из Miniport-драйверов, или только из BusExtender-ов.

2. Реализована проверка и обработка дубликатов HWID-ов. В текущей реализации выборка выборка наиболее подходящего драйвера осуществляется по дате, то есть выбирается наиболее новый драйвер по дате из его INF-файла.

Обновлена версия утилиты

Новое в версии 1.5.1:
1. Реализовано переименование дубликатов SYS-файлов драйверов.

2. Расширена информативность лога работы программы, выдаваемого в консоль.

Попробовал в деле вашу утилиту, результат впечатляет.
Проделывал примерно всё это вручную при сборке своего LiveXP, но Ваша утилита это что-то феноменальное - здорово облегчит работу!

Не знаю как вы дружите с Z_DRV_INST, но всё же спрошу. Если я создам аддон из башратовского комплекта MSST (понятно что дрова для 2000/2003 надо предварительно самому удалить из каталога)
В аддон z_drv_inst я не буду добавлять ни в распакованном ни запакованном варианте файлы dp_masstorage.7z, а добавлю только dp_graphics.7z, dp_chipset.7z и тп...
Не войдут ли эти аддоны друг с другом в конфликт?
Какой из аддонов надо предпочтительнее поставить выше другого по алфавиту - или всё равно?

Делал ли кто нибудь такой симбиоз, похоже что объём дистрибутива реально уменьшится на размер dp_masstorage.7z ведь как я понял теперь не надо его ещё раз распаковывать для графического этапа установки? Или надо оставлять этот архив ?

:tomato2:

Если вы имеете ввиду драйвер у которого один ИНФ и несколько SYS-файлов для разных ОС, то этого делать не нужно, поскольку утилита сама выбирает нужный SYS-файл.

Нет. Вы не поняли. Утилита создает аддон для интеграции драйверов текстового этапа. На графическом этапе вы должны предоставить установщику пакет драйверов, чтоб он обычным образом установил драйвера на контроллер, иначе получите синий экран после перезагрузки в конце графического этапа.

Mr dUSHA, теперь всё понял, спасибо

Совместимо и с тем и с другим. Только отключите интеграцию драйверов текстового этапа установки. Иначе будет нерабочая каша.

Не получится только реализовать мультизагрузку.

А когда реализуется такое? Хотелолось бы видеть.

Mr dUSHA, не читал ветку, может где писалось, в чем конкретное отличие от Башратовского интегратора MassStorage Text Mode???

Гм... Основное отличие в том, что утилита не использует башратовских настроечных INI-файлов вообще, а собирает информацию непосредственно из INF-файлов драйверов. Поэтому она никак и не привязана к башратовским пакетам, а может обрабатывать любое самосборное дерево драйверов.
Кроме того, не знаю, реализовано ли у Башрата добавление в реестры текстового и графического этапов параметра PnpInterface для нуждающихся в нем драйверов...

Изначально утилиту я писал "под себя".
А в своей сборке я не использую никаких интеграторов драйверов вообще, как собственно и стандартных пакетов драйверов. Вместо этого интегрирую только необходимые TextMode-драйверы, а на графическом этапе поддержку дерева каталогов с драйверами (копируемого на винчестер при установке ОС через $OEM$-папки) реализует собственнописный фейк-сетап.

Нет, не реализовано.

Я так понимаю, параметр PnPInterface берется из inf-файла? Если он там есть - то добавляется. Нет - не добавляется. Так?

Да. Так.
Тайный смысл этого действа заключается в том, что этот параметр если есть в inf-файле, то есть и в оригинальном txtsetup.oem этого драйвера. Поэтому и возникает иногда такой спецэффект, что если драйвер добавить стандартным способом с дискеты по F6, то все нормально работает, а если интегрировать - то не работает.

Кроме того многие txtsetup.oem содержат еще некоторые другие, специфические уже для конкретного драйвера, параметры, добавляемые в реестр текстового и начала графического этапов, которые возможно тоже влияют на нормальную работоспособность драйвера.
Я думаю, что возможно стоит реализовать еще и парсинг txtsetup.oem для тех драйверов, у которых он есть в комплекте (применимо например к башратовскому пакету), что возможно обеспечит более корректную интеграцию и стабильную работу...

Так у Башрата их нет и не было никогда

Новая версия программы

Новое в версии 1.6.0:

1. Добавлены ключи командной строки -WXP, -W2K3, -P32, -P64 для указания целевой платформы, для которой нужно производить отбор драйверов.
2. Расширена информативность лога работы программы, выдаваемого в консоль.
3. Оптимизация кода, мелкие правки.

Наверное стоит добавить поддержку интеграции на графическом этапе, чтобы не лепить симбиоз с z-drv-inst /то-есть распаковку 7z, прописывание путей к каталогам распаковки, снятие проверки цифровой подписи, хотя там установка панелей при первом входе через finish.ini но его можно аккуратно перенять в принципе/

Просто вариант когда данные об интеграции берётся не из башратовского инфа, где он может допустить ошибку, описку и т.п., затем ошибка например с пробелами с некороткими hwid, вкрадывается после конвертирования в msst.ini конвертером от BS. А в данном случае вся информация собирается и тестируется самим вендором. Потом действительно можно в дерево драйверов добавить свою ветку не заморачиваясь с конвертированием в формат башрата. Вобщем графический этап + установка панелей при первом входе...

Распаковку пакетов драйверов и динамическое формирование и прописывание в реестр путей к папкам драйверов возможно реализовать только с помощью фейк-сетапа, до запуска оригинального установщика (setupORG.exe или непосредственного вызова InstallWindowsNt из Syssetup.dll).
Связано это с особенностью устройства библиотеки setupapi.dll, которая во время первой загрузки и инициализации копирует из реестра список путей из ключа
HKLM,Software\Microsoft\Windows\CurrentVersion,DevicePath в свою внутреннюю строковую переменную. Так что если уже в оригинальном установщике где-то на Т-39 с помощью родной встроенной функциональности PreSetup запустить перечисление каталогов драйверов, то эффекта не будет никакого.

Опять же блокировка проверки цифровой подписи достигается из фейк-сетапа патчем всего 3 байт на лету непосредственно в памяти в исполняемом коде библиотеки Syssetup.dll. Другие полезные патчи/правки, такие как правка ранжирования неподписанных драйверов (для отказа от необходимости удаления старых встроенных подписанных MS-овских драйверов из дистрибутива) в коде Syssetup.dll и setupapi.dll также можно накладывать прямо в памяти на эти библиотеки.

Так что использование одного нормального фейк-сетапа избавляет от необходимости использования кучи мусорных утилит и патченых системных библиотек.

Ну вот, значит осталось нормальный фейковый сетап прикрутить к Z-MSST ;-)

Так как утилита уже вполне работоспособная, займусь созданием симбиоза с фейк-сетапом и мультизагрузкой.

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

А можно без мультизагрузки или её опционально, например я использую графический мультизагрузчик syslinux до этого использовал текстовый BCWD или он и туда и сюда пойдёт ?

А может утилиту вообще в варианте DLL-модуля еще сделать, чтоб стыковать с программой было проще?

Подскажите, в чём может быть проблема?

Беру DriverPack_MassStorage_wxp_x86-32_116_Greg_B вот отсюда http://forum.oszone.net/thread-91146.html, обрабатываю его MSSTMake 1.6.0, в протоколе утилиты вижу следующее:

============================================
Opening INF-file:
Index - 0057
Name - D:\M\S3132D\SI3132D.INF

[i] Selected platform extender [.NTx86.5.1]

[i] Parsing Manufacturer section [SI_HDC.NTx86.5.1]

Duplicated HWID [PCI\VEN_1095&DEV_3132] found
[-] Old driver with date 10/31/2006 replaced
[+] New driver with date 10/03/2007 assigned to this HWID

Duplicated SYS-file [SI3132.sys] found
[i] SYS-file [SI3132.sys] renamed to [SI3133.sys]

[e] Error in copying SYS-file [SI3132.sys]. Error code = 2


[i] Parsing Manufacturer section [SI_HDC.NTx86.5.1] completed


HWID Statistic:
---------------
Total found HWIDs - 34
New assigned HWIDs - 0
Replaced from this INF old HWIDs - 1
Discarded old or bad in this INF HWIDs - 0
Duplicated in this INF HWIDs - 33


[i] INF-file successfully parsed

Closing INF-file
============================================


Здесь идёт речь о переименовании файла SI3132.sys в SI3133.sys. По факту в папке Drivers не появляется файл SI3133.sys. Также информация о несуществующем SI3133.sys добавляется в DOSNET, HIVE, setupreg.reg, TXTSETUP.

Как следствие, после интеграции полученного аддона получаю нерабочий дистриб. Во всяком случае при установке в режиме обновления выдаётся ошибка о невозможности копирования SI3133.sys, делаю "пропустить", после перезагрузки компа программа установки не хочет без SI3133.sys продолжать.

На всякий случай прикладываю весь протокол работы утилиты.

Кажись понял.

В инфе S3132D\SI3132D.INF ошибка.

В секции [SI_3132_Service_Install] была строка ServiceBinary=%12%\SI3132.sys, поменял на ServiceBinary=%12%\SI3132D.sys - в протоколе больше нет ошибки.

Может файл read-only ?

Mr dUSHA,
По подключению фейкового сетапа нашёл статейку с готовым сетапом + утилитки + командный файл

http://www.msfn.org/board/SOLVED-drivers-CD-t12566.html

Всё довольно прозрачно - вся настройка установки прописывается в открытом команднике, утилитки снимают проверку подписи у драйверов и устанавливают пути сканирования inf для PnP этапа

Может имеет смысл добавить всё это хозяйство в формируемую папку Z-MSST ?
получится почти готовый симбиоз - останется спросить разрешение у BS для включения в этот симбиоз утилитки finish.exe + finish.ini (для установки панелей)

ЗЫ
У BS, конечно, утилита крутая (z-drv-inst), но исходников нету, а самому ему в последнее время не хватает времени заниматься проектом /как мне показалось/, а если и хватит, то будет 2 варианта - всяко лучше чем один или ни одного :tomato2:

Отсюда предложение. Если утилите дают кривой инф, пусть она как-то проверяет/игнорит его, чтобы не получилось, что файла нет, а ссылки на на него в DOSNET, HIVE, setupreg.reg, TXTSETUP создаются.

То, что предлагается там - примитивный и древний вариант.
Я уже давно разработал свой собственный фейк-сетап, в котором все реализовано в едином файле Setup.exe.
Если хотите, почищу из него весь лишний спицефический только для моей сборки мусор, и выложу сюда. Можно даже с исходниками (С++).

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

Кроме того, мой фейк-сетап рассчитан на использование $OEM$-папки, которая копирует драйвера на винчестер в уже распакованном виде.

Опять же, могу добавить такую функциональность в виде выполнения скрипта PostSetup.cmd в сам фейк-сетап, который будет выполняться после оригинального инсталлятора ОС, и еще до перезагрузки, где-то на Т-0.
До сих пор это никто не реализовал потому, что в инсталлятор, если не пропатчить в syssetup.dll Оптимизатор Реестра Оптимизатор, выполняясь на Т-0 в оригинальном инсталляторе, мешает установке любых прог на этом этапе, а точнее теряются все записи произведенные программой в реестр.

ОК. Подправлю утилиту, добавлю такую проверку.
Я на 116-й версии пакета не тестировал утилиту, а там, в указанном вами ИНФе, действительно ошибка.

Mr dUSHA, То, что предлагается там - примитивный и древний вариант

Жаль, зато всё прозрачно в "батнике" и распаковка пакетов 7z и прописывание путей...
Может сам попробую сляпать на базе этого варианта + ваш z-msst + finish от BS
/Понятно, что без выбора галочками пакетов драйверов, но я обычно всё равно все распаковываю/

Было бы неплохо пощупать с++ :o ...

Цитата:

Цитата BXA Было бы неплохо пощупать с++ ... »

Вот такой вот Фейк-сетап у меня примерно. (В архиве и бинарник, и исходники).
Он целяком заменяет оригинальный setup.exe, и в оригинале не нуждается.

Делает следующее:
1. Составляет список путей к драйверам, прописывает в реестр (корень дерева задается через INI-файл).
2. Отключает в реестре SFC (но нужна патченая SFC_OC.DLL)
3. Загружает и патчит прямо в памяти syssetup.dll setupapi.dll на предмет отключения проверки цифровой подписи, понижения ранга неподписаных драйверов, отключения защиты Syssetup.inf от правки (сами файлы не правлятся так что их цифровая подпись не теряется).
4. Запускает инсталятор через функцию InstallWindowsNt (syssetup.dll)

Можно только дописать еще пару строчек кода для реализации распаковки драйверов....


UPD: 09/10/2008 Новая версия, перенесена в шапку.

Было бы замечательно. А еще больше было бы замечательно, если бы можно было еще и все башратовские драйвера (ланы, видео и т.д.) этим сетапом ставить. Т.к. всеже для многих основной источник дров - это пакеты со всем известного сайта.

Этому ничто не мешает и сейчас. В INI-файле фейк-сетапа нужно только указать путь к дереву драйверов, чтоб на Т-40 он его просканировал и составил список папок с драйверами.

Сейчас какраз отлаживаю последние строчки кода новой версии фейк-сетапа. Но обсуждение его уже вынесу в отдельную тему. :-)

А зачем в отдельную тему? лучше сделать полный комплект аддона для интеграции.
Ведь сам по себе Z-MSST без фейка и фейк без Z-MSST - неполноценные ;)

В шапку добавлена новая версия Фейк-Сетапа.

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

Пригодятся... в случае проблем - легче организовать мозговой штурм и исправить неполадку сообща...

Обновлена версия

Новое в версии 1.6.1.0:

1. Реализована проверка и правильное разделение самих SYS-файлов драйверов на:
   - предназначенные для работы только в ОС Windows 2003 Server через портовый драйвер STORPORT.SYS;
   - универсальные, работающие через портовый драйвер SCSIPORT.SYS.
2. Исправлена ошибка в подборе подходящего PlatformExtender-а для целевой платформы.
3. Добавлен ключ командной строки -W2K3ONLY

Утилита не обрабатывает, выделенные для W3k и W2k в ini файле башрата каталоги:
D\M\H7S
D\M\H9S
D\M\P\K
D\M\P2\K
D\M\L6
D\M
D\M\P
D\M\P1K
D\M\P1S
D\M\P2
D\M\P2S
D\M\P4K
D\M\P4S
D\M\PAS
D\M\P\S

эти каталоги не детектируются по SCSIPORT.SYS и SCSIPORT.SYS

и непонятка с каталогом D\M\V3 в описании башрата, ваша утилита забирает в xp HWID для servera 2003
Тоесть наверное всё же ручная сортировка каталогов с драйверами пока неизбежна....

1. Эти драйверы работают через SCSIPORT.SYS порт-драйвер,
2. В ИНФах этих драйверов нет упоминания о принадлежности только к Вин3003, поскольку ленивые разработчики это не сделали. (Я имею ввиду не описание-комментарий в шапке, а отсутствие PlatformExtender-а .NTX86.5.2)

Таким образом автоматически идентифицировать принадлежность драйверов к платформе Вин2003 невозможно.

В этом ИНФе нет вообще упоминания о Вин2003, есть описания только для платформ х86 и х64, но в комплекте SYS-файл есть только для х86. Кроме того этот драйвер является "System Bus Extender"-ом, хотя в описании башрата он почему-то числится как МиниПорт-драйвер....

UPD:

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

1. МиниПорт-драйверы она отбирает только связанные с портовыми драйверами SCSIPORT/STORPORT.
Все остальное отсекается (за исключением только уникального в своем роде Intel iaStor).
Например отсекаются все nVidia драйверы nvata*, nvatabus*.
Так как, насколько мне известно, такие драйверы не нужны на текстовом этапе установки, поскольку винчестеры видятся нормально и без них.

2. Изменения в формировании секций в Txtsetup для BusExtender-драйверов:
BusExtender- разделены на 3 категории:
- использующие драйвер pciidex.sys;
- использующие драйвер classpnp.sys;
- не использующие этих драйверов вообще.

для первой категории формируются секции [files.xxxxx] такого вида:

[files.atiide]
atiide.sys,4
pciidex.sys,4

для второй категории формируются секции [files.xxxxx] такого вида:

[files.nvraid]
nvraid.sys,4
classpnp.sys,4

для третей категории формируются секции [files.xxxxx] такого вида:

[files.amdbusdr]
amdbusdr.sys,4

Mr dUSHA,
Почему то в файле HIVE присутствует 2 идентичных строки:
HKLM,"SYSTEM\CurrentControlSet\Services\Cpq32fs2\Parameters\PnpInterface","5",0x00010003,1
HKLM,"SYSTEM\CurrentControlSet\Services\Cpq32fs2\Parameters\PnpInterface","5",0x00010003,1

Ещё вопрос с переименованием файлов и связанных с ними inf файлов
вот например файл hpt3xx.sys -> переименован в hpt3x2.sys
в файле HIVE прописано
HKLM,"SYSTEM\CurrentControlSet\Services\hpt3x2\Parameters\PnpInterface","5",0x00010003,1

то есть когда актуальны эти параметры для переименованных файлов в файлах setupreg.reg и hive
как я понял hive - это уже графический этап где по идее должны подхватываться на pnp информация из inf файлов. и как это свяжется с тем что на текстовом этапе подхватился переименованный файл например hpt3x2.sys а на графическом будет pnp цеплять "его" inf а там файл hpt3xx.sys

Если ещё более конкретно, то мне это надо для LiveXP. Если я в system32\drivers укладываю переименованный SYS то в windows\inf мне наверное надо положить и исправленный inf (внутри тоже изменить имена sys) переименованного sys

И ещё вопрос с заменами существующих в дистрибутиве файлов - корректно ли будет просто заменить файл или надо ещё о нём предварительно почистить инфу в том же txtsetup.sif

Это подправил. Там на самом деле два параметра действительно из ИНФа задаются, но только один для шины PCIBus (5), а второй для шины Eisa (2).

По словам Boa Soft, все нормально работает. И когда на графическом этапе подхватится драйвер из ИНФа уже, то будет использоваться именно он.
Но на 200 процентов безглючность такого способа я вам гарантировать не могу, и поэтому предлагаю вам протестировать на вашем контроллере, как я понял, с драйвером hpt3xx.sys, и сообщить о результатах ;)

Это краеугольный камень. Над ним пока работаю...
Вообще то можно реализовать проверку по оригинальному txtsetup.sif на дубликаты SYS-файлов, но тогда Утилите нужно будет указывать еще и путь к дистрибутиву с txtsetup.sif. Возможно реализую это с опциональным ключом командной строки.

Проверял - работает. У башрата тот же принцип переименования. Останутся, правда "мусорные" записи, вносимые через HIVE, но это на работу не повлияет.

Там инфы не нужны. Надо вносит в реест то, что создавали ранние версии программы для sysprep установки.

ага я уже проверил: работает, в реестр (setupreg.hiv и HIVEPCK.INF-с_вызовом_из->txtsetup.sif) я внёс, то что сделала версия 1601

Нет. Boa Soft имеет ввиду файл Critical.inf, который раньше утилита генерировала, а сейчас я это отключил.

Возможно сегодня вечером снова добавлю этот функционал, и тогда вам нужно будет только насыпать в system32\drivers нужные драйверы, и добавить в реестр информацию лишь с одного файла Critical.inf, и больше ничего.

Mr dUSHA,
Да хоть и работает но ощущение мутности осталось - чувствую что чтото не то :-) ведь в инфах больше записей в реестр вносится ;)
ага, было бы здорово!

BXA,

Я немного ошибся. Это для susprepa надо. А для PE - внесение в txtsetup и в реестр. Так того, что формируется утилитой вполне достаточно. Можно только плагин сделать на основе результатов ее работы.

У кого правильно
HKLM,"SYSTEM\CurrentControlSet\Services\<DriverName>\Parameters\PnpInterface","5",0x00010003,1
у Башрата

или
HKLM,"SYSTEM\CurrentControlSet\Services\<DriverName>\Parameters\PnpInterface","5",0x00010001,1
в шапке этой темы?

0x00010003 - это и есть 0x00010001 вместе с флагом, означающим "не перезаписывать ключ, если он существует уже"

0x00010003 в оригинале у Майкрософта везде написано в HIVESYS.INF.

А что, башратовский интегратор тоже начал добавлять этот параметр?

Хмм, теоретически понятно и практически на scsi диске в vmware получилось (в варианте со scsi диском в xp работает тот же механизм/текстовый и граф этапы/ на нём и отлаживался) а вот реального железа нет по близости

Mr dUSHA, я думаю что надо бы всё равно опцию добавить для формирования Critical хоть я и нашёл у себя версию 1510 которая его формирует, но мало ли может всё же пригодится....

Обновил версию

Новое в версии 1.6.3.1:

1. Снова добавлена генерация файла Critical.inf.

Mr dUSHA,
В файле TXTSETUP есть строки:

а в MSST.INI

Похоже нестыковка...
У Boa Soft, если эти два контроллера в папке "P", исчезал Promise FastTrak 376/378 (tm) Controller (XP) (fst376xp.sys), если папку переименовать в "PE", они появлялись...
А здесь тоже исчез, а вместо него для 2000...

mercuryn,
Проверяйте в секции [HardwareIdsDatabase], какие HWID-ы каким реально драйверам сопоставлены.
Для каждого конкретного HWID-а выбирается наиболее новый драйвер.
Но если не хотите мешанины с драйверами от 2000 и ХР, то удаляйте папки для 2000 из пакета перед сканированием.

Mr dUSHA, Вся соль в обработке у Boa Soft распакованного DriverPacks_MSST с целью получения MSST.ini с подборкой драйверов для XP. Для этого у него служит MakeMSST.exe.
Вы же предлагаете вернуться в "каменный век" и выбирать руками всю эту подборку...
Что-то тут не так... Не верится в ...

YikxX, к сожалению...

Все идет по сценарию, пока вы используете готовые пакеты драйверов с прилагающимся INI-файлом. Если захотите добавить свой драйвер, то вы должны будете дописать соответствующую секцию в INI-файл.

Касаемо драйверов для 2000 из Башратовского пакета, то в драйверах, которые присутствуют в пакете в двойном или тройном комплекте, для 2000/ХР/2003, INF-файлы написаны таким образом, что их невозможно однозначно идентифицировать на принадлежность к какой-либо конкретной ОС из линейки 2000/ХР/2003.

Mr dUSHA, Ну а как же Boa Soft, ведь он с этой задачей справился...
А у Вас ...
Придётся возвратиться к предыдущему варианту. А жаль...

У него идет обработка башратовского INI-файла, в котором руками прописана привязка конкретной папки с драйвером к конкретной платформе.

mercuryn, я вот одного не понимаю - зачем использовать этот аддон для драйверов, которые и так работают (с ними нет проблем) при использовании интеграторов Башрата или BS? Используйте Башрата или BS для них. А этот аддон оставьте для драйверов, с которыми проблемы у Башрата или BS.
Не обращайте внимания, mercuryn просто не понимает, чем отличается обработка INI-файла драйвпака от обработки INF-файлов драйверов. ;) Я же сказал - Mr dUSHA, кстати, а нет ли возможности прикрутить анализ INI-файла драйвпака (лучше оригинального Башратовского) для проверки соответствия той или иной папки с драйверами той или иной ОС? Понимаю, что, возможно, геморно очень, но любителям метода "кнопочку тыкнул - комп все сам за меня сделал" очень бы пригодилось...

Я уже думал над этим. Возможно так и сделаю, в виде отдельного ключа командной строки.
Еще один вариант сейчас рассматриваю, но это только для драйверов FastTrak. Суть его в том, что в PE-заголовке драйвера прописана версия целевой системы (5.0, 5.1, 5.2). Для реализации этого придется немножко доработать функцию проверки дубликатов файлов.

Кроме того еще будет добавлен чистильщик результирующего файла TXTSETUP, удаляющий драйвера, на которые нет ссылок в секции [HardwareIdsDatabase]. Это происходит, когда находятся несколько версий одного и тогоже драйвера, сразу старый, а потом более новый, который переопределяет в [HardwareIdsDatabase] все HWID-ы на себя, но в секциях [SourceDisksFiles], [SCSI.Load], [SCSI] записи остаются.

Еще будет добавлена проверка дубликатов в оригинальном дистрибутивном txtsetup.sif

Mr dUSHA, И что мешает сделать комплексный вариант выборки из башратовских драйверов с использованием и его ini???
Ведь тогда вопрос разделения драйверов по ОС будет решён...

YikxX, Интересно, а как Вы планируете технологически этот процесс... Или

mercuryn, Просто это утилита для полуручной интеграции, она не закрывает все возможности аддона от BS и от Башрата...

Но имеет свои преимущества перед ними

Сделать полноценный аддон куда только положить пакет драйверов от Башрата + пакеты своих драйверов не описанных у Башрата, а он сам всё сделает - задача либо ручная либо отдалённого будущего когда BS и Dusha скооперируют свои усилия.

Но требовать нам этого от них - не совсем этично :-)

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

Комплексного варианта с обработкой Башратовского INI не будет.
Основная идея создания утилиты заключалась в не использовании каких-то INI-файлов, а извлечения информации из самих драйверов.

Вместо того, чтоб бороться с глупостью, вы можете самостоятельно создать инструмент, на 100 процентов соответствующий вашей точке зрения о правильности обработки пакетов драйверов.

К этому выводу я уже пришёл, второму...

PS
Для многих повторяющихся *.sys у Башрата использованы другие имена архивов *.sy_ с целью устранения дубликатов имен. Как это учтено у Mr dUSHA не очень понятно...

Не только планирую, а уже во всю использую. :) Я просто разделил драйвпак на 2 половины: 1. Драйвера для нВидиа, Интел, АТИ, ALi/ULi (рэйд); 2. Все остальное.
Все остальное я интегрирую интегратором Башрата. В папку OEMDRV перед сборкой образа кладу архив, где 2 половины слиты воедино. Ничего сложного нет.

Результирующие файлы, которые складываются в аддон, переименовываются автоматически. Так что можно показать утилите сколько угодно одноименных драйверов, но все они будут переименованы. Но повторяющимся HWID-ам будут ассоциированы наиболее новые по дате драйвера.

Очень интересует это направление развития вашей утилиты - так что не бросайте её развитие уж :)

Гм... С этой идеей ничего не получится, так как в многих ХР-шных SYS-ах по милости програмистов прописаны самые разнообразные цифры, от 4.0, и до 6.0. Так что такая идентификация не осуществима.
Единственное, в случае с башратовским пакетом, простое решение - перед сканированием, маленьким батником убивать все папки, которые относятся к W2K, W2K3. Благо, что они отличаются от своих ХР-шных братьев-близнецов последней добавочной буквой "K" и "S" соответственно.

я так и сделал, но сверяясь всё таки с башратовским inf ... на верии 809D - всё совпало

Mr dUSHA, а будет ли учитываться в дальнейшем информация из файла TXTSETUP.OEM при его наличии? Думаю, что лучше всего будет не копировать башратовский пакет, а собрать полностью свой из оригинальных драйверов с сайтов производителей.

Да, я планирую реализовать эту возможность.
Фактически кроме параметра PnpInterface, в TXTSETUP.OEM часто добавляют параметр TAG, который определяет очередность загрузи драйвера в его группе.
Возможно этот параметр также может повлиять на стабильность работы драйвера, особенно ввиду того, что в TXTSETUP.OEM и INF-е драйвера зачастую цифры в этом параметре разные.

Обновлена версия утилиты

Новое в версии 1.7.0.3:

1. Добавлена генерация файла MSST.INI для дальнейшего использования утилитой Gui-интегратор пакета обновлений и адонов от Boa Soft.
   Эта функция включается ключем командной строки '-A'.

Mr dUSHA, попробовал... Сравнил сделанные ВС с Вашими. Огромная разница в HWID, непонятные различия в наименованиях, взялись драйвера от 2000... Если интересно, могу выслать...

PS
Надо ли перед работой утилиты попрежднему очищать DriverPacks_MSST от лишнего???

Нужно.
&SUBSYS_ обрезаны, которые все равно не влияют ни на что? :)

Я уже писал, что идентифицировать их не возможно. удаляйте папки с дровами для 2000 и 2003 руками.

если запустите с ключем -S , то они не обрежутся, и попадут в INI.
Если запустите с ключем -T , то будут вырезаны суфиксы CC_010X, и останутся голые HWIDы.

P.S.: Я уже начал писать нечто наподобие документации по утилите, где будут описаны все особенности ее работы.
Но все как-то руки не доходят дописать до конца..... :)

Думаю я, что смысла нет особого этому процессу внимание повышенное уделять. :) Если имеет человек мозга немного умного и руки у него произрастают из места нужного - то сам он отлично в ней разберется, ибо нет сложного ничего в ней. Тут ситуация на сборки похожая складывается - напиши ты хоть 100 факов к ней, а все равно найдется товарищ криворукий, который сделает неправильно все, а потом еще автора в глючности (недоработке) несуществующей обвинять будет.

YikxX прав, только можно включать в архив программы содержимое шапки темы, там в принципе есть короткое описание и история изменений, чего достаточно. А то инет не всегда есть под рукой, а только скаченное приложение в архиве.

Mr dUSHA, YikxX,
Я бы просил Вас объянить мне следующее.

SamLab обнаружил на одной из мам BSOD и для устранения его в DP_MassStorage_wnt5_x86-32_810F1 AM2 были внесены следующие изменения:
|[AM2] added PCI\VEN_1002&DEV_4391&SUBSYS_11171043 in INI and INF'.
После обработки по умолчанию (включение обрезки СС_ суффиксов в HWID-ах контролеров) это изменение теряется...
При выключении обрезки изменение присутствует.
Количество выбранных *.sys в этих вариантах различается.

Являются ли оба эти варианта для правильной интеграции драйверов (как на текстовом, так и графическом этапах) равноценными???

Это нормальное явление, поскольку без обрезки SUBSYS или СС_010Х возможно будут выбраны разные драйверы для разных груп SUBSYS (или разных СС_010Х) одного и того же HWID-а.

Если вы об обрезке SUBSYS или СС_010Х, то используйте так, как вам это больше нравится.
Я лично всегда обрезал и обрезаю SUBSYS-ы, поскольку не вижу в них смысла для текстового этапа.

Для графического этапа вообще интеграции драйверов нет, как таковой. Суть процесса заключается в том, что вы посредством каких-либо утилит/фейксетапов указываете установщику дополнительный список папок с драйверами, в котором он может поискать подходящий драйвер для найденного им устройства, что он и делает в автоматическом режиме.
Повлиять на логику выборки подходящего драйвера на графическом этапе установки вы можете только непосредственной правкой INF-файла драйвера. Примером того может служить ваша цитата от SamLab, где он дописал в какой-то драйвер к голому HWID-у еще и SUBSYS, для того, чтоб установщик выбрал именно этот драйвер для того "проблемного" устройства.

Mr dUSHA, Спасибо.

Mr dUSHA, Boa Soft.
При получении MSST.ini методом Mr dUSHA, выполняя PrepareMsst.cmd оказывается, что путь к драйверам в MSST.ini \M, а в GUI нужен \D\M...
Нельзя-ли это поправить???

PS
Ещё один вопрос, при выполнении MSSTMake.exe [-S] [-A] ... и MSSTMake.exe [-S] ... результаты, или по крайней мере логи, должны совпадать??? или необязательно???
Имеется в виду один и тот же исходный набор драйверов.

Спасибо!
Это было ошибкой в программе. Уже исправил и перезалил.
На самом деле конечно результаты должны быть абсолютно идентичными, за исключением присутствующего или отсутствующего файла msst.ini.

Корневой папкой для сканирования (которую вы указываете утилите) должна быть DriverPacks_MSST, или просто та папка, в которой лежит дерево \D\M...
Например:
Если дерево выглядит так: C:\MyFolders\D\M\...
то для сканирования утилиту вы должны запустить так: MSSTMake.exe [params] C:\MyFolders\

Обновлена версия

Новое в версии 1.7.0.4:

1. Исправлена ошибка, приводившая к переполнению буфера при использовании программы с ключом -S, в результате чего генерировались совершенно неадекватные файлы.

Mr dUSHA, Теперь, при прямой подстановке, результат нормальный.
Есть ещё одна проблема, связанная с папкой \d\m\p. Драйвера в этой папке как заколдованные, и утилитой msstconvert правильно не формировались. После переименования папки "P" в "PE" проблема разрешилась. Результат:


Теперь же и у Вас результат несколько другой:



Не могли бы Вы найти время и разобраться с этим "заколдованным" драйвером?
В исходных DriverPacks_MSST это папка D\M\P

mercuryn, вам объяснить еще раз нам нужно чтоли, что msstconvert файл INI из драйвпака обрабатывает, а утилита из темы этой - файл INF из драйвера самого? Добавьте HWIDы недостающие из ini файла вы в inf драйвера самого - и получите тогда совпадение полное. Вот только зачем это вам, не пойму никак я...

Результат моей утилиты - это то, что реально прописано в INF-файлах драйверов, как и сказал выше YikxX.
Итак в этой папке мы имеем два INF-файла:

1. PBFSTTX2K.inf

перечисленные в нем HWID-ы:
PCI\VEN_105A&DEV_3376&CC_0104
PCI\VEN_105A&DEV_3373&CC_0104

используемый в нем драйвер: fasttx2k.sys

2. PBULSATA.inf

перечисленные в нем HWID-ы:
PCI\VEN_105A&DEV_3373&CC_0101

используемый в нем драйвер: ide376xp.sys

В точности всё это вы можете видеть в msst.ini созданном моей утилитой.

Единственный момент, который могу пояснить - это строка: TXTFILENAME = fasttx23
fasttx23 - это означает fasttx23.sys, то есть новое имя файла fasttx2k.sys, которое назначила ему утилита в процессе обработки дубликатов имен файлов.

А корректно ли описание этих драйверов в башратовском INI-файле - это вопрос не ко мне ;)

YikxX, а я к Вам и не обращался...

mercuryn, ой, простить прошу покорнейше меня, что побеспокоил я величество ваше ответом своим. Не велите казнить меня неразумного - не буду так больше делать я.

Вопрос задали вы и получили на него ответ развернутый (какая разница от кого) - что вам нужно еще?

YikxX,

Mr dUSHA, сегодня сделал два дистрибутива, используя ГУИ. Один - используя "старый" метод, второй - "новый" метод.
Целью было сравнение результатов генераций на одном системном блоке. Результаты схожие, хотя дистрибутивы незначительно отличаются (я не имею в виду 4 файла второго метода).
Но случился непредвидимый казус.
В перечень DP я добавил долгожданный DP_HID_wnt5_x86-32_81021. В своё время я намучился с "карандашом" на ноутбуках. К сожалению в этом DP оказался драйвер клавиатуры для Vista.
В итоге, с обоими дистрибутивами проблема в установке стандартных драйверов PS/2 клавиатур, при этом поиск обращается к C:\D\..., что уже неудобно...
По "новому" методу ситуация тупиковая, новый драйвер забил старый...
По "старому" методу ситуация лучше - в перечне драйверов клавиатуры оказались и старые, и новые драйвера с указанием версии. Выбрал старый - и всё в порядке.
Как мне кажется, вариант автоматической замены новыми версиями старых драйверов, достаточно неоднозначен...
Особенно это может сказаться на nVidia, где нередко использование новых драйверов может вызывать массу проблем. Да и приведенный пример показывает, что отслеживание гиганского объёма драйверов без средств автоматизации врядли возможен, а получение корректноного дистрибутива ОС для работы не является самоцелью, это всего лишь средство...
Нельзя-ли что-то сделать для сближения этих методов с целью получения двух вариантов ОС - с заменой и с добавлением драйверов?

Господа, будте любезны просветить, если ли смысл (и вообще возможность, необходимость) на текстовом этапе установки ОС установить драйв-пак на чипсет, проц или LAN?
Или возможна установка только MassStorage ?

На текстовом этапе драйверы ВООБЩЕ ни на что не ставятся.

тогда с какой целью интегрируется MassStorage?

чтобы при установке системы её было на что ставить...

Точно )))

так вот инсталятору на этом этапе не надо знать на какой чипсет ставится ОСь? если этого чипсета нет в драйверах дистриба проблем не будет?

Garkavuk, на текстовом этапе - не будет, а дальше сложно сказать.

ОК, пасиб, меня интересует только TextMode.

Я вот только не совсем понимаю, какое отношение имеет вообще эта ветка и утилита из шапки к пакету драйверов для мышек??? И о какой замене мышиных драйверов в "новом методе" вы говорите?

Этого тоже не понял к сожаленью.....

Mr dUSHA, к сожалению я ошибся, это относиться к ветке Fake-Setup Advanced при использовании Gui-интегратор пакета обновлений и адонов.
Но раз для Вас , извините, просто нет смысла дальше использовать Ваши, пока ещё слишком сырые и неописанные разработки...

mercuryn,
вроде говорилось уже о уважении участников форума и их труда

Mr dUSHA,
что то я не пойму
где должна появиться папка Z-MSST
я запускаю из коммандной строки MSSTMake.exe D:\mass
он отрабатывает все в коммандном окне написано какие Hwid found, add
и все никакой папки не создается ничего не происходит
файлы не создаются

ложил в апдейт пак вообще ничего не произошло (только MSSTMake.exe)

просьба обьяснить по порядку список действий

Папка Z-MSST создается в той же папке, где расположен сам MSSTMake.exe.

Первый шаг вы делаете правильно. Запуска "MSSTMake.exe D:\mass" вполне достаточно.
Далее сформированную папку кладете в "UpdatePack-XP\addons" откуда она будет интегрирована в дистрибутив.

Но не забывайте, что Z-MSST - это поддержка только для текстового этапа установки, то есть для того, чтоб установщик Windows увидел винчестер в вашей системе, и начал устанавливать ОС на него.

Естественно что на графическом этапе установки, когда установщик производит установку драйверов для всех устройств в системе, точно так же должны быть установлены драйвера и для дискового контролера, к которому подключен ваш винчестер.
Для этого вы должны предоставить установщику эту же папку с драйверами "D:\mass", из которой вы создавали аддон.
Сделать это можно несколькими способами, например:
- прописать список папок с драйверами в файл ответов winnt.sif, как описано в этой статье: Установка драйверов из winnt.sif;
- использовать какой-либо фейк-установщик/интегратор драйверов, которому вы укажете только путь к дереву папок с драйверами, а он самостоятельно составит список папок и пропишет этот список в реестр, откуда установщик Windows уже и будет его использовать при поиске драйверов для устройств.

Обновлена версия

Новое в версии 1.7.1.0:

1. Теперь при задании путя к папке с драйверами можно указывать не только абсолютный, но и относительный путь.
2. Реализована полная очистка рабочего каталога Z-MSST, если он уже существует.
3. Добавлен ключ командной строки '-BOA'

Mr dUSHA, при формировании MSST.ini d в конце секции "A6" после "DRVTYPE = 1" образовалась цепочка символов "1F 0A 0D 0A", хотя вроде должна быть "0D 0A 0D 0A". Это единственное место в INI.
При переименовании этой папки драйвера "A6" в "A61" программа выдаёт ошибку. При переименовании в "AF" опять эта цепочка символов.

Исправил, перезалил исправленую версию в шапку.

Mr dUSHA, Нормально.
Вопрос, а чем отличаются режимы -a и -boa, ведь если использовать PrepareMsst.cmd из ГУИ, то вроде отличий нет???

Благодаря MSST, сформированого утилитой, удалось победить десктоп Acer Aspire (Intel на NF чипсете). В биосе вклюбчен райд и заблокирован от отключения - прямая подлянка против установки XP.

Без учета PnPinterface установка оканчивалась BSOD на текстовом этапе. Так что, идем правильной дорогой :)

Boa Soft, Это не Acer Aspire M5640? HWID не такой - ACPI\NVRAID20\3&267A616A&0 или подобный? И еще - ничего не приходилось дополнительно переделать? Например строки вида SCSI\NVIDIA__Raid_Disk________ и им подобные перенести выше обычных nVidia HWID'ов?

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

Mr dUSHA, а если переставить строки, то все равно не поможет? Иными словами без добавления информации в реестр все равно не обойтись?

Перестановка строк - это не решение проблемы, а "танцы с бубном". Оно может работать, а может и не работать.
PnpInterface заставляет драйверы загружаться именно в нужный момент, а не когда попало.

-boa добавил для удобства и простоты интеграции с ГУИ.
С этим ключем START и FINISH не создаются вообще, но создается MSST.INI.

С текущей версией MSSTMake скрипт PrepareMsst.cmd может выглядеть следующим образом:
Все остальные действия утилита выполняет теперь сама, без помощи со стороны скрипта.

Основательно переработана и обновлена шапка.
Конструктивная критика, замечания, вопросы и предложения приветствуются :)

Mr dUSHA,
всмысле мне нужно закинуть на диск DP_Masstorage оригинал?
или что то другое дело сделать после апдейт пака

Удачная установка на Gigabyte GA-M55plus-S3G и Asus M2N32-SLI Deluxe. Тестил SATA, RAID, SATA+RAID режимы.

Mr dUSHA , правильно ли я понимаю, что если я хочу получить дистрибутив, который встанет на машину, винчестер которой не был виден оригинальным дистрибутивом, одной Вашей утилиты не достаточно? Разве я не могу на увиденный с Вашей помощью винчестер таки установить ОС, а потом накатить в уже установленную ОС все драйвера: видео, чипсет, сеть звук, а также контроллер диска? Если нет, то
расскажите, пожалуйста, поподробнее, чем в шапке, как довести дистрибутив до ума.

Нужно использовать интегратор драйверов для интеграции в дистрибутив нужных вам пакетов драйверов, в том числе и драйверов для дискового контролера. Попробуйте это: «Gui-интегратором пакета обновлений и аддонов»

aset, VMROL
С помощью Mr dUSHA мне удалось правильно разобраться в технологическом процессе подготовки дистрибутива с помощью ГУИ и .
Первое.
В папки GUITOOLS\DRIVERS\ переписать, как и требуется, упакованные драйвера и распакованный DP_MassStorage_wnt5_x86-32. Т.е. обычная подготовка.
Для обеспечения правильной работы этой утилиты необходимо очистить DP_MassStorage_wnt5_x86-32 (естественно распакованный) от драйверов W2000 и W2003 (если найдутся и 9x). Связанно это с тем, что распознать эти драйвера автоматически пока невозможно. После чистки запаковать очищенный распакованный DP_MassStorage_wnt5_x86-32 обратно, ну, добавив к оригинальному имени любой индекс, чтоб потом не запутаться. Упакованный DP_MassStorage_wnt5_x86-32 поместить в папку с остальными упакованными драйверами (взамен оригинального, но можно оставить и оригинальный).
Второе.
Выполнить утилиту MSSTMake.exe с помощью cmd, которые находятся в ГУИ. В образовавшейся папке Z-MSST появится msst.ini, который скопировать на уровень выше. Данная утилита заменяет утилиту msstconvert от Boa Soft.
Третье.
Переписать папку GUITOOLS и UpdateIntegrator.exe в подготовленный UpdatePack. При этом, аддон Z-FakeSetupAdv не нужен.
Практически, ГУИ готов к работе во всех трёх вариантах:
а. без интеграции драйверов текстового этапа;
б. интеграция драйверов новым методом;
в. интеграция драйверов старым методом.

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

По поводу использования UpdatePack и z_drv_inst, в z_drv_inst можно использовать эту утилиту аналогичным способом для получения msst.ini и папки Z-MSST (но с другим cmd). Но как использовать аддон Z-FakeSetupAdv и куда переписать Z-MSST, я четко себе не представляю.
Думаю, здесь своё слово должен сказать Mr dUSHA, и правильно расписать технологический процесс...

Скажу, но в уже в шапке темы аддона Z-FakeSetupAdv, когда добавлю функционал распаковки драйверов в него.

Где можно об этом почитать поподробнее?

mbgroot, Есть Перепакованные пакеты драйверов

katok888, Вы предлагаете совсем другой вариант набора драйверов, урезанный...
Не знаю.
Мне самому пришлось пройтись по всем драйверам DP_Masstorage вручную...
Но есть видимые признаки - если есть папка P1, P1K, P1S, то это означает, что K - драйвер, W2000, S - W2003. Такого типа папки можно удалять сразу (такая папку может быть и внутри папки).
Далее проверять inf на соответствие только W2000 и W2003. Но в папке могут быть несколько inf!
Если определить не удаётся, не трогайте драйвер...
Если не ошибаюсь, WXP имеет код 5.1, W2000 - 5.0, W2003 - 5.2, Vista - 6.0.
Комплексные драйвера для нескольких ОС не трогайте...
И успеха...
Для примера справка с моего DP, в отдельных папках часть инфов удалены...

Не ошибаетесь. Но драйвер для Win2000 явно определить никак нельзя, если только в комментария в самом inf-файле не будет предупреждение, наподобие: "This driver ONLY for Win2000!!!!"
Так что лучше сами inf-ы не трогать, а удалять только лишние папки.

В случае с башратовским пакетом достаточно только удалить папки с K и S в последнем символе названия. А такие папки есть только для двух вендоров: Promise (имя папки выглядит как Px) и Highpoint (имя папки выглядит как Hx).
У остальных вендоров драйвера универсальные, либо поддающиеся автоопределению принадлежности утилитой.

Mr dUSHA, почему после создания аддона, в файле setupreg.reg указывается именно ветка реестра \ControlSet001\, а не \ControlSet\ ? Что наиболее корректно использовать, или вообще без разницы?

В драйвере RAID для nForce 4 версии 04/24/2006,5.10.2600.0666 используется связка из nvatabus.sys и nvraid.sys (аналогично nvgts.sys и nvrd32.sys). Поэтому для nvatabus.sys лучше сделать исключение.. И вообще, может стоит добавить поддержку таких "ненужных" драйверов хотя бы через ключ? Например "/ALL" - интегрировать все драйвера. При установке такого "ненужного" драйвера появляется поддержка NCQ и hotplug. Горячим отключением, имея когда-то nForce4 Ultra, я пользовался постоянно.

Кстати, пытаясь интегрировать этот драйвер, я сначала подумал что утилита не работает. Может добавить логгинг? Или пусть просто создаст текстовый файл с указанием невозможности интеграции.
А я вообще бы посоветовал создать "свой" пакет с нуля, чем перелопачивать Башратовский, думаю будет проще.

Я, например, просто прошелся по башратовскому INI файлу и удалил все, где нашел DisableIfOS = WinXP соответственно вместе с папками/файлами.
Поддерживаю! Именно поэтому я сейчас не использую последнюю версию утилиты.
Тут не согласен. Имхо, достаточно очистить от дров Win2k и Win2k3 и полностью пересобрать (с удалением существующих) драйвера для nVidia.

Вот этим сейчас и занимаюсь усиленно.

YikxX, Debugger, меритесь, меритесь... Главное, чтоб результат был...
Один раз перелопатить MassStorage не проблема, потом можно только чуть изменить... После анализа всех инфов понял, что никакими скриптами не обойтись, разные производители, разные люди писали, не всегда полностью в общем виде и грамотно...
Вынужден это делать из-за широкого спектра мам разных производителей. Если бы не эта проблема, давно бы сократил, как многие, объёмы драйверов. А так живу без BSOD и других проблем...

Во-первых в SETUPREG.HIV есть только одна ветка - ControlSet001. А во-вторых CurrentControlSet как такового вообще не существует, это ссылка на одну из веток ControlSet00X, какую именно - определяется параметром HKLM\SYSTEM\Select\Current.

А разьве nvgts.sys (10.3.0.21) не поддерживает этого контролера, если он в RAID режиме???
Какой у него HWID?

Не забывайте также, что для рейдового шинного расширителя иденты:
*_NVRAIDBUS
*NVRAIDBUS
есть во всех драйверах, такчто скрестить их никак не получится.

Так никто ж вас не заставляет его удалять с драйвпака, откуда он поставится на "графическом этапе" установщиком ОС. :)

Не поддерживает. (BSOD после перезагрузки после граф. этапа) Правда я проверял более новую - 10.3.0.42, но они почти не отличаются. Остальное - здесь.

Такой ключ добавли. Будет в новой версии.
Также в новой версии будет генерация плагина интеграции MSST-драйверов для програмы "PE Builder".

То есть долой Юркешу, каждый сам для себя чтобы делал :) Интересно

Новая версия
1.8.0.0:

1. Добавлен ключ '-PE' для создания файла msst.inf, для использования аддона в качестве MSST-плагина в программе “PE Builder”.
2. Добавлен ключ '-N' отключающий игнорирование неклассифицированных MiniPort-драйверов.

Вопрос-предложение.
А если утилита с помощью какого-нибудь нового ключика будет создавать этот самый winnt.sif, чтобы не писать его вручную, то избавит ли это от необходимости использования всевозможных фейк-сетапов?

Это невозможно как минимум по трем причинам:
1. Утилита все-таки предназначена для обработки лишь MassStorage-драйверов, а не всех их разновидностей; ;)
2. Как будут располагаться относительно корня диска драйвера на устанавливаемой системе, утилита знать не может;
3. Бороться с неподписанными драйверами она тоже не будет, поскольку в процессе установки ОС участия не принимает.

Так, собственно, я и хочу добавлять на установочный диск только MassStorage-драйверы. Те, кто используют все остальные разновидности, могут из сформированного Вами winnt.sif копировать инфу в свой, если надо.
Во-первых, можно, например, договориться, что в корне установочного CD будет папка Drivers, в которую кладём драйвера. Те, у кого это не так, просто делают замену в winnt.sif текста Drivers на что-то своё. Во-вторых, Вы же знаете, куда при использовании Вашей утилиты попадают драйвера при обработке дистрибутива UpdatePack'ом :wink: . Можно в добавок к папке Drivers прописать в winnt.sif и это. Или же, как вариант, Ваша утилита подготавливает для последующего сжатия и копирования в I386 не только отобранные для TextMode файлов, а всех файлов (вернее, всех подписанных драйверов) и прописывает в winnt.sif, что на графическом этапе MassStorage-драйвера нужно искать тоже в I386.
Здесь да, но появится выбор: не хочешь фейк-сетапа - нет неподписанных драйверов, нужны кому-то неподписанные драйвера - используется фейк-сетап. Просто пока не хочется отказываться от нежелания использовать не родной установщик и от нежелания патчинга оригинальных .dll

с чего вы взяли "не родной установщик"?? Фейк-сетап сам Windows устанавливает, по-вашему?? Оригинальные dll патчатся в памяти. Если не хотите патчить uxtheme.dll и sfc_os.dll можно попросить автора чтобы вынес их патчинг в отдельный параметр ini-файла.

Еще один nLite я изобретать не намерен. :)

Не изобретайте велосипед ;) Этот выбор всегда был, и есть сейчас. Для этого ничего дополнительно придумывать не нужно.

"Не родных" установщиков не бывает.
В любом случае используется только оригинальный установщик (syssetup.dll), и переписывать его заново никто не собирается. Его только патчат для некоторого изменения функциональности, направленного на удобство и беспроблемность установки.
Все существующие Fake-setup, как и оригинальный setup.exe - это лишь маленькие надстройки над настоящим установщиком.
Просто оригинальный Майкрософтовский setup.exe сам не делает абсолютно ничего, в отличии от его самописных аналогов именуемых Fake-setup-ами.

Mr dUSHA,
т.е. выходит это не Fake Setup а улучшенный функционально Setup

Точнее сказать, новый дополнительный функционал. Надстройка над оригиналом, а не его замена.

Удачная установка на:
Gigabyte GA-EP35C-DS3R - на JMicron без PnP-твика не определяется винт в режиме AHCI, теперь полет нормальный.
Foxconn 6627MA-RS2H - на SiS'овском чипсете в обоих режимах (RAID и AHCI) без твика не определяется винт (черный экран с мигающим курсором). С твиком полет нормальный.

Специально проверял без твика и с твиком.

Добавлено:
Удачная установка на Intel SE7230NH1(-E) - на LSI MegaIDE без PnP-твика не определился RAID-массив.

Комментарии излишни...

Debugger, скажите пожалуйста, как включить данный твик и его включение сделает что-либо плохое для не-AHCI/RAID систем?

Grunger86, при использовании MSSTMake.exe в созданном MSST.INI там, где надо, строка с PNPINTERFACE присутствует... Плохого она ничего не делает, наоборот...

Grunger86, никак, твик будет добавлен куда надо при использовании для интеграции аддона, созданного этим конструктором. Нет, ничего плохого не сделает.

Только учтите, что расщиренный формат файла MSST.INI поддерживается только GUI интегратором, а аддоном для интеграции драйверов - нет.

Mr dUSHA, в драйвере на RAID от VIA есть такие строки:
Для чего они и на что влияют?

Mr dUSHA, ну так бы и написали, что "BusType", 0x00010001, 0x00000008 - это шина для RAID, а HKR, "Parameters\Device", "CreateInitiatorLU", 0x00010001, 0x00000001 - просто позволяет ОС посылать команды драйверу даже при отключенном устройстве. :)
Ненавижу документацию на инглише. :)

Меня же интересовало, нужны эти строки в реестре текстового режима или нет.

ИМХО в данном случае нет.
Но вообще в таких случаях нужно смотреть в txtsetup.oem из оригинального пакета драйвера от производителя, добавляет ли он такие параметры в реестр на текстовом этапе. :)

Mr dUSHA, при использовании этой утилиты с параметрами MSSTMake.exe -boa и MSSTMake.exe -s -boa должны-ли результаты совпадать, кроме естественно SUBSYS???

Не обязательно. с параметром -s возможно будет отобрано больше драйверов (отдельных SYS-файлов) и перераспределение HWID-ов между ними будет другим.

Mr dUSHA, а где можно поподробнее почитать про порядок использования Critical.inf?
Есть желание разворачивать заливку (образ установленной и настроенной ОС с программами) на нестандартных контоллерах...

1. Сыпать драйверы из создаваемой аддоном папки Drivers?
2. В реестр добавить путем подключения куста подготовленой системы?
3. Достаточно ли этого будет, чтобы система при загрузке определила нестандартный контроллер и пошла на миниустановку?

1. Я и сам не знаю, где толком это описано.... Я заливками сам не занимаюсь. Сделал эту функцию по просьбе Boa Soft.
Насколько я знаю, на других форумах, где ведется активное обсуждение заливок. Но там люди делают REG-файлы, фактически делающие то же самое.

Изначально идея была такая, чтоб интегрировать драйвера в образ с тем же конечным результатом, с каким это делает SysPrep, но в 1000 раз быстрее :) , и для того, чтоб отказаться от использования SysPrep вообще.

2. Не используйте Critical.inf, который создается утилитой версии 1.8.0.3, поскольку она содержит ошибку, из-за которой в Critical.inf добавляются не все нужные данные.

Сегодня вечером я выложу новую версию, где переписано много кода в утилите и исправлено множество ошибок.

Новая версия утилиты

2ALL: Так как было переписано огромное количество исходного кода утилиты, то возможно появление каких-то новых скрытых багов. Поэтому у меня просьба к общественности: протестировать утилиту во всевозможных режимах, с разнообразными наборами драйверов, и сообщить о найденных багах и неточностях в обработке и в результатах работы утилиты.

История изменений в версиях:

1.9.0.0:

1. Автоочистка всех создаваемых файлов от драйверных секций, на которые нет ссылок из [HardwareIdsDatabase] в TXTSETUP.
2. Множество багофиксов, оптимизаций и изменений в логике обработки дубликатов.
3. Улучшение информативности лога создаваемого утилитой.

Посмотрите на ру-боард`е в теме по клонированию и заливкам. Технология достаточно сложная, но зело полезная для массового производства. Для штучных установок потраченного времени не стоит.

Mr dUSHA, по функциям, относящимся к ГУИ-интегратору, проблем не замечено...

Mr dUSHA, При использовании утилиты MSSTMake версий 1803 и 1900 не попали в MSST.ini драйвера для матери GigaByte GA-K8N51PVM9-RH, SATA в BIOS установлен в режим RAID, вот ссылка на пост, где я все подробно описал

Mr dUSHA, А что значит неклассифицированные miniport драйверы?

Это то, что описано в разделе Обработка MiniPort-драйверов шапки. Этот механизм отключается ключем -N. Я сейчас внесу изменения в шапку для явного указания этого.

Просто шикарная утилита! :)

Вопрос: является ли обязательным значение "Tag" в получаемом CRITICAL.INF?

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

Просто я добавлял некоторые драйвера в реест без этих значений и все вроде всегда работало. Но может я что-то упускаю по незнанию :wink:

Параметр Tag определяет порядок загрузки драйвера в его группе. Для MassStorage драйверов есть две такие группы: "SCSI Miniport", "System Bus Extender".
Таким образом для определения порядка загрузки, драйвера в Windows группируются в два этапа: сначала по группах, а далее в каждой группе уже более точно параметром Tag. Такой механизм обеспечивает корректную загрузку взаимозависимых драйверов.

Mr dUSHA,
Если это действительно нужно, может в интегратор тоже добавить? Все равно обратную совместимость поддерживаю - "хавает" и старый тип MSST? сконвертированный с башратовского.

Mr dUSHA
Спасибо! Значит, наверно, есть смысл оставлять :) Хотя, как написал, я удалял все такие параметры для многих сервисов (при клонировании) и все вроде работало.

Mr dUSHA, Если из Башратовских драйверов удалить все лишние nvidia драйверы, оставить только папку NVTM и папку NV с драйверами, которые мне дал Boa Soft, то какие изменения нужно внести в файл DriverPack_MassStorage_wnt5_x86-32.ini, чтобы он правильно отработался потом утилитой MSSTMake?

Я ради интереса удалил из ini файла все секции nvidia драйверов кроме NVTM и запустил MSSTMake с ключом -n, в полученном MSST.INI присутствуют секции и для NVTM и для NV, я правильно сделал?

Утилита этот файл не использует вообще. Он просто не нужен. Вы его можете удалить.

Да на текстовом этапе я только видел, что у Интеловского iaStor он устанавливается из TXTSETUP.OEM, и кроме того там значение ставится не такое, как в INF-файле этого же драйвера.

---

Немного обновил версию утилиты:

1.9.0.2:

1. Добавлен оптимизатор файла NSST.INI, удаляющий лишние секции, чтоб после интеграции драйверов с помощью GUI-интегратора в TXTSETUP.SIF не переносился ненужный неиспользуемый мусор.
2. Мелкие косметические правки.

Mr dUSHA, Boa Soft,
:applause: ВЫ супер!!!
я сеня утер нос тех сервису по ремонту компов, там лежал комп моего друга с N-Force
и вот в тех сервисе Башрат, и хард естесственно не определяется они говорят надо хард выкидывать, а я взял MSSTMake+драйвера от Boa Soft и усе!!!
Большое спасибо!

что за драйверы?

Все, кто успел уже скачать из шапки версию 1902 - скачайте плиз обновленную 1903.
В формирователе MSST.INI была логическая ошибка, что в суме с оптимизатором дало баг, из-за которого пропадали и нужные секции в MSST.INI.
По возможности протестируйте интеграцию через MSST.INI от утилиты версии 1903 и отпишитесь плиз о багах, если они будут.

Вот здесь здесь он. И там далее в ветке обсуждение проблемы почитайте.

Mr dUSHA,
хотя вроде и 1900 нормально себя показала

Mr dUSHA, насколько я понял, изменения коснулись в основном Silicon - драйверов и удалению отладочной информации.
Прошу Вас рассмотреть следующее предложение.
В MSST.ini создавать шапку (заголовок), в которой указывать следующие данные:
1. Копирайт автора и версию программы;
2. Параметры, с которыми создан MSST.ini;
3. Количество обработанных inf (счётчик Вы убрали);
4. Количество включённых inf;
5. Дату и время создания ini;
6. Возможно, ещё какую-то другую информацию.
Это позволило бы не путаться с разными версиями ini в практической работе и различать их при различных вариантах отладки.
Например, при работе ГУИ-интегратора появляется информация о количестве обработанных драйверов, а информация в INI о количестве включённых INI позволила-бы вести контроль за этими параметрами...
PS
Возможно, эта идентификация касается и других создаваемых файлов подобного типа...

Это можно.
Как только я с Boa Soft согласую формат шапки, так и добавлю ее создание.

А где вы их взяли, можно линк ?

BXA, http://forum.oszone.net/post-955818-771.html

Mr dUSHA, есть ли смысл использовать последние версии утилиты, если не пользуешься ни ГУИ-интегратором, ни MSST.ini ? Есть ли что-нибудь полезное в последних версиях для тех, кто пользуется интегратором Башрата? Ну и наоборот соответственно - не добавит ли использование последних версий утилиты (которая все больше и больше "затачивается" под z_drv_inst и ГУИ-интегратор) глюков при неиспользовании последних?
Какую версию, в связи с вышеизложенным, посоветуете вы?

YikxX,
как раз таки использование Bashrat'a ограничивает определение и последующую установку на них ОС, а именно N-Force, и некоторых других еще
так как они используют еще кусты реестра для работы, а в Башрате этого нет

aset, я в курсе. :) Поэтому использую Башратовский интегратор лишь для драйверов, которым не нужен "PnP-твик". :) Для nForce использую эту утилиту.
Никогда не приходило в голову, что пакет DP_MassStorage можно разделить и на две части и на три и больше - в зависимости от нужд. ;)

В последних версиях я сильно перепотрошил обработку дубликатов, сделав обработку более быстрой и умной, и исправил несколько глюков, из-за которых некоторые драйвера не добавлялись.
Это все реализовалось в 1900.
А 1901, 1902, 1903 - там только оптимизации и багофиксы в создании MSST.INI.

Не добавит. Никакой заточки утилиты вцелом нет. Затачивается только функция генерации MSST.INI. В свою очередь эта функция получает данные для внесения в MSST.INI из общего сканера, собирающего информацию для TXTSETUP.

YikxX,
дак, надо было это указать) просто Вы указали Башрата как единственное средство, поэтому такой была моя реакция

Mr dUSHA
Для подготовки DriverPacks_MSST, по Вашим советам, достаточно удалить явные папки с драйверами, оканчивающиеся на "K" и "S". Но в результате работы утилиты в MSST.ini попадают и другие явные драйвера для W2000 и W2003:

Возможно они подходят и для XP? Но Q3 для 2003 и многие другие пропущены правильно...
Нужны ли эти 10 папок, или их лучше удалить???

aset, я же написал

Цитата:

Цитата YikxX есть ли смысл использовать последние версии утилиты »

разве из этого не следует, что утилитой я пользуюсь и уже давно? ;)

mercuryn, ориентируйтесь по ключу exc_disableIfOS="wxp" в INI-файле. Драйвера в перечисленных вами папках подходят как для WXP, так и для Win2k3

Для начала ответьте самому себе, нужны ли вам вообще эти драйвера? У вас есть компьютеры с дисковыми контролерами, поддерживаемыми этими драйверами?
Если точно нет, то удаляйте.

Mr dUSHA
Сделал небольшую рекламку здесь. Там толковые люди бывают, протестируют, может еще что предложат ;)

YikxX, Спасибо за совет. Башрат в последнем варианте DP_MassStorage_wnt5_x86-32_811C1 в своём ini файле "упорядочил" и разнообразил эти ключи:

При этом многие драйвера "w2k" определяются и как для wxp, и как только для w2k.
Как эти параметры правильно расшифровывать и понимать??? и можно ли на них ориентироваться???

mercuryn, в таком случае надо ориентироваться на exc_skipIfOS. Так как по сути одно и то же.
disable и skip - этот драйвер не интегрируется в эту (эти) системы.
replace - этот драйвер заменяет драйвера от МС при интеграции в эту (эти) системы.

YikxX, всё бы хорошо, но как понять такой вариант:
exc_disableIfOS="w2k"
exc_skipIfOS="wxp,w2k3"
для папки AT - ms_2_deviceName="ATI PCI IDE Bus Master (W2K)", где в inf две секции: для wxp и w2k.
Что-то в Башратовских ini DP_MassStorage_wnt5_x86-32_811C1 пока не всё в порядке...
Вы не находите, что ориентироваться на такой ini несколько бессмысленно???

Ничего не бессмысленно. Эти драйвера (ATI Bus Master и VIA Bus Master) всегда вызывали проблемы на ХР на некоторых материнках - то диск не видит, то тупо BSOD 0x0000007B выдает (поэтому я их из своего драйвпака убрал уже давно, т.к. встроенные в винду драйвера всяко лучше). Поэтому их просто задисэйблили. Можно считать, что для интегратора Башрата их просто не существует теперь - чего и добивались авторы пакета.
Хотя может это просто опечатка, но я склоняюсь к 1-му варианту.

Смысл в том. что на текстовом этапе он не интегрируется. А при установке PnP, если он подписан и новее встроенного в дистрибутив, то может и установится. интеграция раньше была, теперь убрали. Причины вам обьяснили в предидущем посте.

Уважаемые! Не бейте сильно :) , но не очень понял: можно ли как-то указать месторасположение папки Z-MSST? Запускаю как MSSTMAKE -S -C C:\TXTDRV и папка Z-MSST появляется в корне профиля действующего юзера (у меня в Администраторе, так как под ним работаю).

Это, конечно, вообще даже не проблема по сравнению с полезностью самой утилиты :) , но в первый раз пришлось папку поиском находить :D

Oleg_II, Папка появляется в текущем каталоге. Сделайте перед запуском CD в нужный каталог и все будет нормально.

В ручную - пока нет. Хотя я планирую это сделать.
Но папка создается в текущем каталоге. То есть если утилита у вас лежит в одной из папок, указанных в переменной PATH, то запустив консоль CMD и запустив там MSSTMAKE -S -C C:\TXTDRV, вы получите Z-MSST в том каталоге, который является текущим в консоли. Как правило, если это не переназначено вручную, при запуске консоли для нее устанавливается в качестве текущего именно корневой каталог действующего юзерского профиля.

Скажите при генерации адона с ключом -ВОА (полученную папку Z-MSST положил UpdatePack-XPSP3-Rus > Addons), нужно ли включать опцию в интеграторе: Интегрировать драйвера устройств в дистрибутив > Интегрировать все драйвера текстового этапа установки (метод из MSST.ini) или будет достаточным интегрировать ее в качестве адона.

Если интегрировать драйвера через ГУИ-интегратор, то аддон вообще класть в "UpdatePack-XPSP3-Rus > Addons" не нужно.

Mr dUSHA, Наличие даже краткой технологической документации избавило бы от большей части подобных вопросов...

Mr dUSHA, ковыряюсь потихоньку... и вот что заметил (DP_MassStorage_wnt5_x86-32_811r1.7z; MSSTMake.exe -boa -N -S; v.1, 9, 0, 6):
утилита не включила:
PCI\VEN_105A&DEV_8002,PCI\VEN_105A&DEV_8004,PCI\VEN_105A&DEV_8006 из D\M\P3\;
PCI\VEN_105A&DEV_6622 из D\M\P4\;
PCI\VEN_105A&DEV_3318,PCI\VEN_105A&DEV_6626 из D\M\P6\;
PCI\VEN_105A&DEV_3320 в msst.ini из D\M\PA\
... из D\M\Q4\

... хотя в ряде случаев дескрипторов устройств можно обноружить больше, чем в конвертированом DriverPack_MassStorage_wnt5_x86-32.ini

Совсем забыл об этом баге, хотя знаю уже давно. Там ИНФы не совсем стандартные, хотя и вполне в рамках документации по ИНФах в WDK.
Исправлю в следующей версии.

UPD

В исходнике утилиты баг исправил.

В папках D\M\PA\ и D\M\PAS\ кривые ИНФы.
Там для строк:
%PCI\VEN_105A&DEV_3320.DeviceDesc% = FasttrakPCI_S150SX4L , PCI\VEN_105A&DEV_3320
отсутствуют установочные секции "FasttrakPCI_S150SX4L". Так что по поводу этих драйверов вам уже не ко мне, а к Башрату за багофиксами.

Mr dUSHA, дублируются HWID-ы из D\M\I3 и D\M\I4, хотя, по описанной вами логике обработки дубликатов такого быть не должно...
Создаст ли это проблемы и будет ли во время тектстового этапа подхачен новейший драйвер?

Пропущены D\M\L2, D\M\D1 - почему?

D\M\D1 - percsas.inf - нет поддержки для ХР. Драйвер только для Win2000/2003
D\M\L2 - MRAID35X.inf - все аналогично, нет поддержки для ХР. Драйвер только для Win2000/2003

Так что в таких случаях смотрите также и в ИНФ-файлы драйверов, поскольку далеко не все, что отбрасывает утилита, является ее багом...

Дубликатов нет.
В плане дубликатов вам не стоит обращать внимание на содержимое msst.ini. Там обработка дубликатов HWID-ов частично опирается на работу GUI-интегратора. А из самого файла msst.ini удаляются только лишние секции целяком.

Всегда смотрите файл TXTSETUP, там действительно ничего лишнего нет.

Mr dUSHA, насчет D\M\L2 - MRAID35X.inf: там есть текст: NT.5.1, NT.5.2...

g7r7s7, для win2k соответствующая секция mraid2k_Inst есть, для Win2003 - Mraid35x_Inst - есть, для WinXP -
XPDRV - есть, но в отличие от остальных девственно пустая, о чем и говорит комментарий ";empty section". То есть опять же - пинайте разработчиков.

Mr dUSHA, за рараметр REPLACE тоже GUI-интегратор отвечает?

Да.
Утилита не поддерживает сверку по дистрибутиву, в который будет производится интеграция, поэтому параметры REPLACE, REMOVE, DISABLE всегда будут равны 0.
Если вам это нужно, то меняйте эти параметры в нужных вам секциях, и GUI-интегратор их обработает.

при удалении "лишних" драйверов по методу skipIfOS= из пакета DP_MassStorage_wnt5_x86-32 от Bashrat'a как поступать в такой ситуации...

[XX]
ms_count=2
ms_1_deviceName="xxxxxxxxxx"
ms_1_tag="xxxxxxxxx"
ms_1_sysFile="xxxxxx.sys"
ms_1_hwids="PCI\VEN_xxxxxxxx"
ms_1_isBusExtender=true
ms_1_exc_skipIfOS="w2k,w2k3"

ms_2_deviceName="yyyyyyyyyy"
ms_2_tag="yyyyyyyyyy"
ms_2_sysFile="yyyyyyyyy.sys"
ms_2_hwids="PCI\VEN_yyyyyyyyyy"
ms_2_isBusExtender=true
ms_2_exc_disableIfOS="w2k"
ms_2_exc_skipIfOS="wxp,w2k3"

только удалить файл yyyyyy.sys или еще нужно inf править, чтобы окончательно удалить следы этого драйвера??

AjaX_too, думаю MSSTMake сам разберется какие драйверы интегрировать, в соответствии с той ОС какую вы явно задали ключом. За исключением тех случаев, когда из inf-файла или PE-заголовка неясно, какой файл какой ОС принадлежит.

Можно кратко описать, что сие суффиксы означают и где можно посмотреть описания их значений?

AjaX_too, удаляете строки из ini-файла. ms_count=2 меняете на ms_count=1 Из папки с драйверами удаляете yyyyyyyyy.sys и yyyyyyyyy.cat, yyyyyyyyy.inf (если есть).

gabasov, CC_0101 - режим IDE, CC_0104 - режим RAID, CC_0106 - режим AHCI

Включение обрезки (ИМХО) лучше не включать, как и обрезку SUBSYS'ов. Уже были из-за этого косяки на южных мостах от ATI (SB600).

YikxX,
подскажите, а если inf файл общий для обоих драйверов, его нужно редактировать (удалять строки ссылающиеся на удалееные файлы yyyyyyyy), либо это лишниее и утилита просто не будет обрабатывать эти секции в случае отсутствия файла драйвера?

Debugger,
это понятно, просто хотелось бы исключить подобные случаи так как впоследствии эта же папка с драйверами будет добавляться в дистрибутив и не хотелось бы, чтобы там были лишние драйвера.

Не будет, если в заголовке файла драйвера либо в самом inf-файле указано, что он не для ХР. И при отсутствии файла драйвера тоже не будет.

В башратовском паке DP_MassStorage_wnt5_x86-32_811r1 следующие строки в ini:
[AT]
ms_count=2
ms_1_deviceName="ATI PCI IDE Bus Master (WXP)"
ms_1_tag="atiide"
ms_1_sysFile="atiide.sys"
ms_1_hwids="PCI\VEN_1002&DEV_4349"
ms_1_isBusExtender=true
ms_1_exc_skipIfOS="w2k,w2k3"

ms_2_deviceName="ATI PCI IDE Bus Master (W2K)"
ms_2_tag="atiide2k"
ms_2_sysFile="atiide2k.sys"
ms_2_hwids="PCI\VEN_1002&DEV_4349"
ms_2_isBusExtender=true
ms_2_exc_disableIfOS="w2k"
ms_2_exc_skipIfOS="wxp,w2k3"

соответсвенно при обработке башратовским интегратором драйвер ATI PCI IDE Bus Master (WXP) интегрируется в дистрибутив. Есть ли смысл оставлять его в обновленном паке либо все же баг с BSOD не пофиксили и могут быть вышеуказаные проблемы. Версия драйвера atiide.sys 1.0.0.3.

AjaX_too, у меня лично нет никакого желания разбираться "пофиксили баг" или нет. Просто IDE дров нет и все, так как они уже есть в дистрибутиве винды и все и так поставится.

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

Если под обработку первым попадет удаленный драйвер, то весь ИНФ будет отброшен, и второй не удаленный драйвер обработан не будет. Так что лучше всего просто закомментируйте в ИНФе все строки с ХВИДами, соответствующими отключаемому драйверу.

Debugger,
ну дык а если fake setup от Mr dUSHA пользоваться? Он отключает ранг понижения неподписаных драйверов...или я чего не понимаю?

Mr dUSHA,
спасибо, буду разбираться.

Покопался тут немного в changelog от DP_MassStorage_wnt5_x86-32_811r1:
Может быть это как то решает проблему описаную YikxX с ATI Bus Master и VIA Bus Master...

Fixed
'|[AM],[AM1],[AT],[AU],[E],[NV5],[NV6],[NVTM],[SIS3] and [V3] changed ms_1_isBusExtender=true'.

А, ну да, я и забыл :)

Может, и решает. Но пока не проверишь не поймешь.

Эти правки относятся к родному Башратовскому интегратору. Там составители пакета, добавляя эти драйверы в дистрибутив, не удосужились заглянуть в ихние ИНФы чтоб правильно определить их тип (SCSI Miniport или System Bus Extender).

Утилита из шапки темы изначально правильно определяет тип драйвера и создает правильные, соответствующие типу драйвера записи в TXTSETUP для корректной интеграции его в дистрибутив.

Существует ли реально (Башратовские кривые INI-файлы не в счет) данная проблема - сказать не могу, так как не имею такого железа и протестировать соответственно нет возможности...

Mr dUSHA,
Ну в приниципе если только эта проблема из-за Башратовского интегратора и его ini, а не кривого драйвера ATI и VIA, тогда при испоьзовании Вашей утилиты проблема пропадает на корню.
Рискнул оставить эти драйвера в своем паке, по возможности потестю.

AjaX_too, результаты тестов огласите, если будет возможность, хорошо?

YikxX,
Если будут установки на вышеуказанное железо обязательно отпишу.
Подскажите, у вас проблемы с этим железом возникали при интеграции драйверов графического режима Башратовским интегратором или каким то другим способом?

Драйверов текстового режима, т.к. БСОД вылетал прямо перед выбором разделов. :) Да, Башратовским - другими я не пользуюсь.

Новая версия:
1.9.1.0:

1. Добавлено формирование статистики в заголовках файлов Msst.ini, Msst.inf, Critical.inf.
2. Исправлена ошибка обработки INF-файлов, в которых несколько HWID-ов записано в одну строку через запятую.
3. Мелкие багофиксы и оптимизация кода.

Mr dUSHA , помоги разобраться. Использую твою утилиту впервые. Вот как я делаю распаковываю DriverPack_MassStorage_wxp_x86-32_117_Greg_B на системный диск в папку под названием DriverPacks_MSST и запускаю так:
C:\MSSTMake.exe [-WXP|[-BOA] <C:\DriverPacks_MSST>. Ничего не происходит. Что делаю не так?

Попробуй, переименуй .txt в аттаче в .bat, положи батник рядом с файлом MSSTMake.exe. Запусти. Должна появиться папка Z-MSST.

deviance, спасибо, я просто запускал через Пуск\Выполнить . Нащёт этого думал но впадлу было создавать батник

Mr dUSHA, может Вы добавите в статистику номер версии программы, с помощью которой получены результаты??? Ведь пределу совершенствования нет и это не последняя версия...

deviance, MSSTMake.exe -WXP -BOA "C:\DriverPacks_MSST" Лучше бы так - MSSTMake.exe -S -N -BOA C:\DriverPacks_MSST SUBSYS обрезать не рекомендуется, могут быть проблемы на чипсетах от ATI (там все построено на SUBSYS). -N нужен для драйверов nVidia, без этого ключа старые драйвера из дистриба на новые заменены не будут. Хотя, если не используется фейк-сетап от автора этой темы или не патчится setupapi.dll на предмет отключения рейтинга драйверов - то можно не использовать. Ключ -WXP - это опция включена по умолчанию, добавлять ключ смысла нет. Ставить путь в кавычки тоже смысла нет - в нем нет пробелов.

Проблем скорее всего не будет - уже оттестировано.

пока не замечал проблем. Вашей утилитой месяца 3 пользуюсь вкупе с GUI от Boa.

Новая версия:
9.1.4.0:

1. Добавлен ключ командной строки -R, включающий переименование дублирующихся SYS-файлов в самом пакете драйверов с соответствующей корректировкой их INF-файлов.
   Новые имена SYS-файлам присваиваются такие же, как и в аддоне.
   
   Кроме того с помощью этого ключа производится корректировка в INF-файлах имен сервисов к именам, соответствующим именам их SYS-файлов без расширений.
   Например, в Башратовском пакете присутствуют ошибки такого вида:
   - Драйвер iaStor.sys переименован в iaStor70.sys,
   - В его INF-файле внесены исправления в ссылках на этот SYS-файл (вписано его новое имя),
   - Но строки вида:
   AddService = iaStor, %SPSVCINST_ASSOCSERVICE%, iaStor_Service_Inst, iaStor_EventLog_Inst
   не изменены на:
   AddService = iaStor70, %SPSVCINST_ASSOCSERVICE%, iaStor_Service_Inst, iaStor_EventLog_Inst
   
   Строго говоря, ошибкой это не является, так как в документации WDK сказано, что имя сервиса может быть любым, и не обязательно должно быть привязано к имени SYS-файла.
   
   На практике же мы имеем в некоторых случаях не корректную работу драйвера iaStor.sys из-за не полной корректировки его установочного INF-файла, при его переименовании.
   Это подтверждено несколькими участниками нашего форума, наступившими на данные подводные грабли.
   
   Функциональность данного ключа командной строки корректирует имена сервисов во всех INF-файлах, которые обрабатывает, для предотвращения описанного выше бага, даже если не происходит переименования SYS-файла из-за нахождения дублирующихся имен.
   .
   
2. Мелкие не существенные фиксы в функции создания файла Critical.inf.
3. Введена новая, ИМХО более удобная, нумерация версий утилиты, которая теперь соответствует дате сборки.

Mr dUSHA,
спасибо, за пояснение, а то я думаю была 1,910 стала 9,140 рывок прямо)

Mr dUSHA, При использовании Гуи-интегратора нужно использование каких либо ключей командной строки кроме -BOA

т.е. при использовании Update Integrator'a от BoaSoft нужно измененный пакет masstorage запаковать и положить в DriverPacks_Zipped?

Mr dUSHA,
я понял так, что сначала ДП нужно обработать утилитой с ключом R, а потом уже натравливать утилиту на измененый ДП с нужными мне ключами для создания адона? Или утилита при использовании ключа R c другими ключами вместе сначала будет обрабатывать ДП, и только после этого создавать адон на основе измененого ДП?

Нет. Просто до тех ключей, что вы обычно используете, добавляете еще и -R. Утилита налету правит ДП и создает из него аддон за один проход. Далее вы этот ДП пакуете и используете для установки ОСи.

При повторном перезапуске утилиты на этом уже правленом ДП, ключ -R уже никаких действий не произведет, поскольку все и так было за первый раз исправлено... :)

Да, и еще один момент, о котором я забыл написать в шапке:
В каждой из папок ДП, в которой были внесены изменения в ИНФ-файлы, утилита создает бекапы оригинальных файлов, и скрипт UnDo.cmd, запуск которого возвращает все файлы в этой папке ДП к исходному состоянию.

Всю эту информацию я позже внесу в шапку.

Вот за это отдельное спасибо :)

Да, нужно (при условии, что в пакете есть косячные драйвера). Но, только один раз. До замены драйверпака.

А цифровые подписи от этого не слетают?

Естественно слетают! А как же без этого то?! ;)

to ALL: Кто растолкует в чем назначение секций [FloppyFiles.1], [FloppyFiles.2],...,[FloppyFiles.x] файла Dosnet.inf ?
Просто никак немогу вкурить, если файл прописан в секции [FloppyFiles.2] то он же дублируется в секции [Files] а если файл присутствует в [FloppyFiles.1] то в [Files] о нем нет упоминания, по крайней мере так делает данная утилита, напр. с файлом nvrd32.sys, который является BusExtender'ом и по идее должен пренадлежать секции [FloppyFiles.2]-именно там винда ищет SCSI и RAID классы устройсв, из-за чего на текстовом этапе устоновки форточек с HDD для nForce2/3 в режиме RAID емеем ошибку: Нуедается скопировать nvrd32.sys. :dont-know Я взял и перенес упоминание о nvrd32.sys из [FloppyFiles.1] в [FloppyFiles.2] продублировав эту-же строчку в [Files] - все гут.

ЗЫ: непонятно по какому принципу MSSTMake.exe определяет какому классу устройств:
1. IDE ATA/ATAPI контроллеры([FloppyFiles.1]) или
2. SCSI и RAID контроллеры([FloppyFiles.2])
пренадлежит тот или иной *.sys ?

Вот бы мне еще это кто растолковал...... Я этот тип установки не тестировал никогда...

В утилите формирование файла для Dosnet.inf сделано по образу и подобию примеров и статей из этого и других форумов.
Если сделано действительно неправильно, то укажите, где почитать адекватную информацию об этом, и я все поправлю.

Mr dUSHA,

[FloppyFiles.XXX] служат для предзагрузки файлов на начале текстового этапа

[Files] - служат для копирования при установке с HDD, по сети, из-под windows (syspart). При установке с CD не используется.

Корректно вносить файл надо в обе секции.

Boa Soft, а циферии(символы) эти после FloppyFiles.* чегонить значут ? Может быть это последовательность предзагрузки групп файлов каждой из секций на текстовом этапе установки???

ЗЫ: Допер, скорее всего это номер floppy'диска :)

ОК. Теперь все виды драйверов вносятся в эту секцию.
Возможно в этом у меня была ошибка, и Dilinjer не работало только потому, что драйвер был туда не внесен...

А как быть с FloppyFiles.1 и FloppyFiles.2?
Есть реально какая-то разница, в какую секцию вносить SCSI-минипорты, и в какую BusExtenders-драйверы?
Или эта нумерация - это только логическое разделение для удобства (а заодно и разделение файлов по занимаемому месту на физические дискеты, если создавать дискеты)???

Сейчас реализация такая, что BusExtenders-драйверы вносятся в секцию FloppyFiles.1, а SCSI-минипорты вносятся FloppyFiles.2, что кстати вполне логично, так как БасЕкстендеры должны загружаться первыми всегда.

- Да, так и есть, только что проверил, продублировал записи из секции [FloppyFiles.1] в [Files] - все ОК.

- самому интересно, как только появится подходящее железо обязательно проверю....

Тогда так и оставляю:
- БасЕкстендеры добавляются в Files и FloppyFiles.1;
- Минипорты добавляются в Files и FloppyFiles.2.

Загрузочный набор NT содержит несколько дискет (5?). Секции указывает принадлежность к дискете. Где- все равно. Лиж бы все загрузилось.

Немного уточню.

Читать [Files] - служат для копирования дистрибутива в локальный источник (папка LS s баксами на HDD) при установке с HDD, по сети, из-под windows (syspart). Оттуда будет уже копирование по директивам txtsetup.

А когда будет выпущена новая версия утилиты, учитывающая эти исправления.

P.S> Спасибо за "Продукт века".

Сегодня, через пару часиков ;)

---

UPD:
Обновил версию:

9.1.20.0:

1. Добавлен ключ командной строки -K, включающий только корректировку имен сервисов в INF-файлах, без переименования SYS-ов.
2. Исправлена ошибка в формировании файла DOSNET для BusExtender-драйверов.
3. В функции реализующей функционал ключей -R и -K добавлена поддержка INF-файл ов в кодировке UNICODE.

Всем привет.
Можна подробный хелп по использования єтой проги для чайников

to onis, так в шапке ж всё написано

Mr dUSHA, Создал MSST.ini с ключом -N утилитой v9.1.20.0 на пакете DP_MassStorage_wnt5_x86-32_901 и получил невозможность установки на текстовом этапе, ошибка при копировании NVATABUS4IN.sys из папки пакета ..D\M\NV4IN, я так понимаю потому что он не удовлетворяет условиям формата DOS имени 8.3. Попробовал сформировать MSST.ini без ключа -N разница в 4 драйвера и все от nvidia, но NVATABUS4IN.sys единственный из них у кого имя длиннее 8 символов. Почитал описание ключей и задался вопросом, если ключ -N не использовать, то на графическом этапе установки подхватятся те драйвера, которые не были включены при копировании на текстовом этапе без использования ключа -N для мам на базе этих контроллеров?

Alexis13,
при формировании образа включите Joilet и все будет нормально, либо гляньте на оригинальных образах какие параметры использует Microsoft.

AjaX_too,
проблема аналогичная Alexis13,

дистр создаю как у Microsofta
раньше ничего такого не было

aset,
эту ошибку видел единожды на предыдущей версии утилиты, после того как создал образ на базе оригинала проблемы не было, поэтому и не придал внимания этой ошибке. тут понятно, что это из-за 8.3 формата. проверьте наличие файла в I386, соответсвие его имени тому, что указано в txtsetup.sif

update: еще раз проверил свои образы, текстовый режим прошел без ошибок. повторюсь - версия утилиты 9.1.4.0 на последней щас нет возможности проверить. Создавал аддон с такими ключами MSSTMake.exe -S -N -R Если ничего не помогло, нужно Mr dUSHA звать.

Должны подхватиться. Исклучением будет только рейдовый режим работы контролера.
Для него нужна интеграция текстового этапа, так как там NVATABUS.sys будет работать не сам, а в связке с nvraid.sys. А без них на текстовом этапе система просто не увидит винчестер.
По поводу ошибки копирования толком сказать ничего не могу из-за отсутствия такого железа под руками сейчас.
Аддон я проверил, он формируется корректно.
У вас этот файл не копируется еще до этапа выбора раздела винчестера для установки, или уже после?

Mr dUSHA, тут даже дело не в железе. просто на текстовом этапе установщик не может найти файл NVATABUS4IN.sys так как при формате 8.3 он обрезается до NVATABUS.sys а в txtsetup.sif написано NVATABUS4IN.sys. Т.е. проблема возникнет на любой конфигурации. Ждем пока aset отпишеться как у него дела.

upd: точнее NVATA~01.SY_ (бывший NVATABUS4IN.sys) не распаковывается при 8.3. ТОлько что проверил конвертнув образ в 8.3 формат

Башрат с нвидиа-дровами как всегда жжот! :) А что, никому религия не позволяет переименовать этот драйвер и сервис в inf-е как положено? Руч-ка-ми.

тогда проще уж оригинальные дискетки от Nvidia c офф. сайта скачать.

Ок.
Добавлю в функцию обработки дубликатов имен SYS-файлов еще и обрезку имен до формата 8.3.

P.S.: Уже порядком поднадоело превращать утилиту в автоматический багофиксер косокривого башратовского пакета.....

Небольшое обновление утилиты из разряда "Автобагофиксер башратовского пакета" :) :

9.1.22.0:

1. Добавил обрезку длинных имен SYS-файлов к формату 8.3.

В версии 901 пакета всего три файла с длинными именами, но кто его знает, сколько их потом еще появится... :)

Mr dUSHA,
спасибо за помощь!

но, я решил проблему просто помнится с Nvidia еще раньше были проблемы и Boa Soft
выкладывал nvrd32 папку с драйверами и было сказано удалить все папки с Nvidia и оставить только одну с nvrd32 я так и сделал