[Boa Soft]

Boa Soft, советую забыть про правильный парсинг инфов. »

Без этого нет смысла двигаться далее. Все остальные косяки можно/нужно решать на этапе создания индексов.

один и тот же драйвер от нвидиии выглядит одинаквово что для xp что для Семерки 64. »

Не совсем понял. Однозначно прописана 7 и виста:

Код:

%NVIDIA_A% = NVIDIA_SetA_Devices,NTamd64.6.0,NTamd64.6.1

Лучше возьмите пример с СЕМЛАБА. Я давно говорил наведите порядок чтобы прога нормально определяла драйвер нормальный. Вот с выходом 8-ки началось правильное движение в сторону порядка в DP. напишите Сему в приват, они с Бедпоинтером вроде все стабильно сделали... »

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

К тому же, у меня приоритет создания утилиты для тихой установки драверов при установке системы. А не очередной гуи оболочки. Оно будет, но после.

А тах исходники я вам выслал можете изучать )) »

Уже смотрю. Мне идея встроенного менеджера устройств понравилась. Можно добавить функционал для поиска и установки драйвера для выбранного в дереве устройства.

[SamLab]

SOLON7, Сделай поддержку папок-маркеров как мы с Поинтером в DPS сделали и больше от тебя особо ничего не нужно:
var ver_51x64="5x64";
var ver_51x86="5x86";
var ver_60x64="6x64|NTx64";
var ver_60x86="6x86|NTx86";
var ver_61x64="7x64|NTx64";
var ver_61x86="7x86|NTx86";
var ver_62x64="8x64|NTx64";
var ver_62x86="8x86|NTx86";
var ver_XXx64="Allx64";
var ver_XXx86="Allx86";
var ver_51xXX="AllXP";
var ver_60xXX="All6";
var ver_61xXX="All7";
var ver_62xXX="All8";

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

Boa Soft, Сейчас все больше вендоров вообще в инфах мало что указывают и некоторые пишут для какой винды дрова только в readme.txt и в таком случае кроме маркеров выхода нет т.к. в некоторых случаях только опытным путем и на основе предыдущих установок можно знать - поэтому в DPS сделали, что программа первым делом анализирует инф и если так информации нет или она не явная, то используется маркер - например Realtek в аудио-дровах вообще под 6.0 понимает все винды от висты и выше, а некоторые ставя 5.1 в инфе рядом делают коммент and later например - так что чисто на анализе inf никогда не сделаешь правильно пока авторы драйверов халатно будут относиться к конкретной прописи версии винды в инфах
Башратовские паки использовать себе дороже выйдет - для XP еще нормально, но для семерки там вообще просто сборник фалов непродуманный и без корректировки никуда, поэтому я решил со временем все паки с нуля самому делать и на Башрата сейчас смотрю только на предмет новых версий, которые я мало ли, но мог упустить для XP т.к. упор делаю на Win 7/8

[Boa Soft]

Boa Soft, Сейчас все больше вендоров вообще в инфах мало что указывают и некоторые пишут для какой винды дрова только в readme.txt и в таком случае кроме маркеров выхода нет т.к. в некоторых случаях только опытным путем и на основе предыдущих установок можно знать - поэтому в DPS сделали, что программа первым делом анализирует инф и если так информации нет или она не явная, то используется маркер - например Realtek в аудио-дровах вообще под 6.0 понимает все винды от висты и выше, а некоторые ставя 5.1 в инфе рядом делают коммент and later например - так что чисто на анализе inf никогда не сделаешь правильно пока авторы драйверов халатно будут относиться к конкретной прописи версии винды в инфах »

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

[SamLab]

Boa Soft, Не знаю как ваша программа, но исходя из принципов работы DPS, было решено в будущем делать драйвер-паки не разделяя по системам, а разделять по вендорам и типам - например пак DP_USB3_12101.7z - все драйвера под USB 3.0 в одном пакете, внутри подпапки по вендорам и внутри папок с вендорами уже разделение по маркерным папкам для разных систем - так анализ будет более четким + экономия места т.к. многие драйвера универсальные и сейчас просто дублируются в разных пакетах - вот пример пака с новой структурой http://rghost.ru/41009118 (версии драйверов не самые новые т.к. делал пока что чисто для анализа новой структуры)

[Boa Soft]

Boa Soft, Не знаю как ваша программа, но исходя из принципов работы DPS, было решено в будущем делать драйвер-паки не разделяя по системам, а разделять по вендорам и типам - например пак DP_USB3_12101.7z - все драйвера под USB 3.0 в одном пакете, внутри подпапки по вендорам и внутри папок с вендорами уже разделение по маркерным папкам для разных систем »

Так наверное будет самое оптимальное решение. Только надеюсь, что это именно пример, а не будет место чипсета кучка отдельных для SMU, USB, логики чипсета, IR и прочего.

У меня сейчас сделанно так - каталогизатор выдирает из секции manufacturer все экстендеры (Ntx86.6.0,Ntx86.6.1 например ) и существующие для них hwid
А сама программа анализирует индекс и сопоставляет для соответствующих HWID экстендер с версией системы.

Что-то после чтения этого топика задумался, не поменять ли логику.
Например, каталогизатор индексирует и на основе экстендеров из секции manufacturer и наличия в пути к инфу папки (и прочих фильтров, которые можно задать вручную) формирует в индексе поле типа 6x64,7x64,8x64 а установщик просто сравнивает версию системы и это поле индекса. Тоесть, уже жестко ограничен круг систем, для которых этот дравер и не нужен дополнительный анализ этого поля. Ведь все равно, что каталогизатор формирует индекс за 30секунд или же за 60, а время поиска при установке более критично. И все эти типы можно задать битовой маской размером в WORD.
All6:= 6x64 or 6x86 или Allx64:=5x64 or 6x64 or 7x64 or 8x64. И вся проверка сведется к одной строке.

Тут правда есть еще подводный камень. Некоторые драйвера учитывают и воркстешн/сервер. А при указаной нотации систем это не учитывается. Хотя, особо страшного тут не будет - драйвер от сервера просто не установится на воркстейшн и наоборот (при условии, что это прописано в экстендерах а не в редми). С этим вот пока не ясно. Может добавить еще и 7x64S например - только для сервера.

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



Плюсик будет еще и в том, что

К стати, предлагаю всем авторам оболочек задуматся над двумя вопросами, которые я уже для себя решил.
Честь драверов имеют GENERIK HWID - типа CC_ и не могут быть однозначно отнесены кконкретной железяке. У меня они помечаются как только для ручной установки. Так же в оболочках желательно бы так же помечать их и не ставить автоматом, а только с ручным выбором.
Второе - некотрые дравера можно поставить, запустив оригинальный установщик в тихом режиме.
Я у себя предусмотрел и такой вариант - место запуска PnP апи для установки дравера можно просто запустить его сетап с нужными параметрами.

И, на последок, больной вопрос - панели. Особо атишные. Я видел, что реализован механизм башратовского finish для XP, в ХПшных пакетах и есть панели, а вот для 7/висты этого нет.

Так что предлагаю обьеденить усилия.

[SamLab]

Так наверное будет самое оптимальное решение. Только надеюсь, что это именно пример, а не будет место чипсета кучка отдельных для SMU, USB, логики чипсета, IR и прочего. »

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

Что-то после чтения этого топика задумался, не поменять ли логику. »

Судя по описанию должно быть более грамотно так

Некоторые драйвера учитывают и воркстешн/сервер »

Таких не много, но они есть - хотя по идее многие дрова сходны от сервера и воркстейшена, но можно и 7x64S добавить - хуже не будет

Плюс еще и в том, что сделав универсальный настраиваемый фильтр каталогизатора можно использовать любые пакеты драверов »

Безусловно и вариант получить ошибку на выходу уменьшается

Второе - некотрые дравера можно поставить, запустив оригинальный установщик в тихом режиме. »

Лишним не будет и иногда очень даже кстати придется

И, на последок, больной вопрос - панели »

Более чем больной вопрос - к тому же драйвера для многих встроенных аудио типа Conexant и т.д. без панели устанавливаются, но уровень звка выше 50% громкости не поднимается, а с панелями от 0 до 100% можно менять - вот такие фокусы

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

Сейчас кроме вас никто не занимается своими программами, кто-то не хочет, у кого-то времени нет, только вот я если когда найду какие ошибки, то вместе с BadPointer в DPS что-то меняем т.к. он начинал писать DPS и нынешний автор ArtX те секции практически не знает

[SamLab]

Boa Soft, Еще мы с BadPointer в DPS учли, что если допустим для Win7 драйвер есть, а для Win8 нет - на восьмерке предлагается драйвер от Win7, а вот если ситуация обратная и в Win7 нет, а для Win8 есть, то не предлагается

[BadPointer]

Что-то после чтения этого топика задумался, не поменять ли логику. Например, каталогизатор индексирует и на основе экстендеров из секции manufacturer и наличия в пути к инфу папки (и прочих фильтров, которые можно задать вручную) формирует в индексе поле типа 6x64,7x64,8x64 а установщик просто сравнивает версию системы и это поле индекса. Тоесть, уже жестко ограничен круг систем, для которых этот дравер и не нужен дополнительный анализ этого поля. Ведь все равно, что каталогизатор формирует индекс за 30секунд или же за 60, а время поиска при установке более критично. И все эти типы можно задать битовой маской размером в WORD. All6:= 6x64 or 6x86 или Allx64:=5x64 or 6x64 or 7x64 or 8x64. И вся проверка сведется к одной строке. »

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

Насчет скорости, количество записей в индексах не должно влиять на скорость подбора. В случае с DPS, я использую hash-таблицы что позволяет зная требуемый HWID, сразу найти все нужные строки в индексах. Например, в индексах на миллион записей, при необходимости найти HWID, проге требуется в среднем проверить 3-4 записи и если среди них нет совпадения, то значит в остальных записях тоже нет. Правда из-за ограниченности JavaScript, hash-таблицы увеличивают скорость подбора всего в 4 раза, хотя в других языках программирования весь процесс подбора мог выполнится за доли секунды.

К стати, предлагаю всем авторам оболочек задуматся над двумя вопросами, которые я уже для себя решил. Честь драверов имеют GENERIK HWID - типа CC_ и не могут быть однозначно отнесены кконкретной железяке. У меня они помечаются как только для ручной установки. Так же в оболочках желательно бы так же помечать их и не ставить автоматом, а только с ручным выбором.

Можно привести конкретный пример? Например фрагмент лога DPS, где приводится информация о устройстве(секция DeviceInfo).

Второе - некотрые дравера можно поставить, запустив оригинальный установщик в тихом режиме. Я у себя предусмотрел и такой вариант - место запуска PnP апи для установки дравера можно просто запустить его сетап с нужными параметрами. И, на последок, больной вопрос - панели. Особо атишные. Я видел, что реализован механизм башратовского finish для XP, в ХПшных пакетах и есть панели, а вот для 7/висты этого нет.

Я заметил что при установке через devcon видеодрайвера NVIDIA, запускается файл setup.exe c определенными параметрами(я подменял setup.exe своей заглушкой чтобы увидеть с какими параметрами его запускали) в тихом режиме. Если устанавливать через DPInst, то этого не происходит. Поэтому в первом случае установка происходит успешно и устанавливается панель NVIDIA с прогой nView. Во втором случае только драйвер и в последнее время при установке происходил BSOD.

Именно поэтому при интеграции в дистрибутив и установке через DPInst(в DIA) требуется finisher. Так как DriverX и DPS используют devcon, все должно ставится нормально без дополнительных действий.

Я реализовал папки маркеры в DPS, поскольку SamLab продемонстрировал что иногда при недостаточной информации в inf может приводить к неверному выбору. Но мне лично эта фича не нравится так же как мне не нравится и finisher. Хотя эти средства и решают проблему, в идеале нужно решить общую системную проблему вместо того чтобы вручную решать множество вторичных проблем индивидуально. Переход на devcon сделал ненужным finisher и ручную установку.

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

[SamLab]

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

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

[BadPointer]

Драйверпаки и так раскидываются по папкам Drv6, Drv7, DrvX, что приводит к тому что один и тот же драйвер дублируется несколько раз. С повсеместным использованием маркеров дублирование увеличивается еще больше, теперь уже внутри драйверпаков.

Разделение по папкам Drv6, Drv7, DrvX выполняет двойную функцию: можно легко удалить драйверпаки для определенных систем; и программы учитывали имя папки для определения совместимости драйвера(DIA до сих пор учитывает).

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