Вот оказывается есть такая мелкая проблемка — автоматическая инсталяция, так называемых, сетевых компонет совсем без использования активности пользоватея.


Озаботили тут меня этим вопросом — а я честно говоря и не знал, что это проблема... вернее, как-то раньше как-то кто-то за меня её решал , или ещё раньше так вопрос вообще не стоял — "без активности пользователя"... и выяснилось, что на самом деле эта проблемка имеет место быть. И в мсовских форумах и на OSR'е постоянно эти вопросы задают — "а как?". А ответов то и нет. Вернее есть но примерно такие — "а никак" или "а ручками"...

А суть самой проблемки в том, что для того чтобы сетевая компонета — Сервис, Протокол, Клиент, нормально функционировал, он должен быть "встроен" в NDIS стек. А это делается посредством "привязки" (такой старый русский термин) данного сервиса, протокола или клиента к сетевому оборудованию, к так называемому NIC'у. Эта привязка обычно описывается в INF файле, путем например указания сетевых сред и места в стеке, но подробно на том как это делеается, останавливаться не хочу, все довольно ясно расписано в документации. Можно сделать привязку и "чисто руками", и тут нет совсем ничего сложного — все делается в риестре, но все не документированно и поэтому для правильных ковбоев это не подходит. Но также есть ещё и специальный путь — с использованием INetCfg API, поищите в документации все описано. А в WDK есть даже спекиальный пример BindView — как раз постороенный на этом API и на SetupApi. И вообщем-то разработчику совсем ничего не стоит — написать программу из пять строчек... написать такой специальный инсталятор для только его компонент. Помню был даже написан некий такой "универсальный" инсталятор для сетевых протоколов — ProtInstall, посмотрите он есть в исходниках на NDIS.COM.


Все было бы ничего, но как всегда НО — но с появленим Vista и Server 2008 и активным расшинением 64-битности теперь встал вопрос о том как делать, так чтобы разные бинарники сетевой компоненты вставали соответсвенно на разные платформы и версии. Ну вот например официально существует IA64, AND64, I386 версии Vista. Как быть? Документация описывает то как создавать мультиплатформенные INF'ы. Эта возможность существовала давно, еще в Win2000 можно было использовать так называемые декорированные имена секций, например blabka.NT или blabla.NtX86, в ХР уже стало можно ещё больше... Ну так вот, дело то в том, что примеры из WDК и соответсвенно и ProtInsrall'еры не умеют работать с такими INF файлами.

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

В итоге я написал "универсальный" инсталятор для сетевых компонет, для всех версий NT и всех платформ. Он позволяет инсталировать не только протоколы но и сервисы, клиенты и пр.

Скачать можно тут :

Исходники собираются посредством BUILD.
Проект для Студии

Бинарники, лучше конечно стройте сами, но если не получается то:

32-бита платформа INTEL 32
64 бита платформа INTEL 64
64 бита платформа AMD64

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Вот оказывается есть такая мелкая проблемка — автоматическая инсталяция, так называемых, сетевых компонет совсем без использования активности пользоватея.

Всем большое спасибо за оценки, надеюсь что программка будет полезна... И ещё хотелось добавить — весьма приветствуются обнаруженные баги, и неработоспособность где-то как-то. Это даже нужно не столько мне, сколько, раз уж эта программа должна работать везде и всегда и её видимо будут пользовать многие люди, то естественно её было бы правильно протестировать как следует. Так что если появятся проблемы и будут найдены решения, то с удовольствем подправлю код...

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

Да забыл, ещё — это программа не делает чудес — она не запускает не подписанные драйвера в висте. Она их только устанавливает — да они установятся но не запустятся.

Для тех, кто не понял, зачем столько кода, я попробую пояснить, поскольку я по началу тоже не понял и потратил некоторое время на изучение опуса .
Все в конце концов сводится к вызову INetCfgClassSetup::Install. Что не удивительно. Вся фишка, что туда надо передать некое значение — pszwComponentId, откуда INetCfg дальше определит как инсталлировать таки драйвер. Так вот данный код в основном и занимается выцеплянием этого значения из целевого inf файла. Делается это довольно безхитростно — определяется нужная секция ( с учетом платформы ) и оттуда берется первый попавшийся компонент. Т.е обрабатывает сей код корректно только inf файлы устанавливающие один драйвер для одного устройства ( если речь идет об установке драйвера PnP NIC ). А теперь задумаемся: если мы пишем инсталлятор для своего собственного драйвера, для него же мы уже написали inf файл — мы ведь знаем этот pszwComponentId. Зачем его еще раз определять?.

Итого: если Вы написали драйвер, сбилдили его под разные платформы, написали inf файл с поддержкой многоплатформенности. А теперь хотите программно его установить, все что Вам понадобится, это вызвать шесть основных функций:

1. SetupCopyOEMInf
2. CoCreateInstance( CLSID_CNetCfg, ....
3. INetCfgLock::AcquireWriteLock
4. INetCfg::Initialize
5. INetCfg::QueryNetCfgClass
6. INetCfgClassSetup::Install( L"I_know_my_components_id_very_well", ...

освободить мьютекс и интерфейсы я думаю никто не забудет

По поводу самого кода. Написан он довольно таки неряшливо и для такой судьбы " раз уж эта программа должна работать везде и всегда и её видимо будут пользовать многие люди " я бы его не рекомендовал.

PS:
чтобы понятно было о чем идет речь, я приведу кусок первого попавшегося мне inf файла для какой то железки:

[Manufacturer]
%ADP%= ADAPTEC, NTamd64, NTx86

[ADAPTEC]

[ADAPTEC.NTamd64]
;
; All Adaptec SAS Device IDs
;
%PCI\VEN_9005&DEV_0410.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_0410
%PCI\VEN_9005&DEV_0412.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_0412
%PCI\VEN_9005&DEV_041E.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_041E

[ADAPTEC.NTx86]
;
; All Adaptec SAS Device IDs
;
%PCI\VEN_9005&DEV_0410.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_0410
%PCI\VEN_9005&DEV_0412.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_0412
%PCI\VEN_9005&DEV_041E.DeviceDesc% = HostRAID_Inst,PCI\VEN_9005&DEV_041E

[Strings]
PCI\VEN_9005&DEV_0410.DeviceDesc = "Adaptec ASC-48300 SAS/SATA Host Adapter"
PCI\VEN_9005&DEV_0412.DeviceDesc = "Adaptec ASC-48300 SAS Host Adapter"
PCI\VEN_9005&DEV_041E.DeviceDesc = "Adaptec AIC-9410w SAS Controller"

pszwComponentId = PCI\VEN_9005&DEV_0410 для девайса, описанного как "Adaptec ASC-48300 SAS/SATA Host Adapter" и.т.д. В данном случае inf прописывает для разных железок одинаковую инсталляцию через секцию HostRAID_Inst, но они могли бы быть и разные.

Здравствуйте, TarasCo, Вы писали:

TC>Для тех, кто не понял, зачем столько кода, я попробую пояснить, поскольку я по началу тоже не понял и потратил некоторое время на изучение опуса.
TC>Все в конце концов сводится к вызову INetCfgClassSetup::Install. Что не удивительно. Вся фишка, что туда надо передать некое значение — pszwComponentId, откуда INetCfg дальше определит как инсталлировать таки драйвер.
TC>...Т.е обрабатывает сей код корректно только inf файлы устанавливающие один драйвер для одного устройства ( если речь идет об установке драйвера PnP NIC ).
TC>А теперь задумаемся: если мы пишем инсталлятор для своего собственного драйвера, для него же мы уже написали inf файл — мы ведь знаем этот pszwComponentId. Зачем его еще раз определять?.



А затем, что я больше не буду их писать, эти инсталляторы... Интересно но вы почти слово в слово цитируете мои текст.

TC> Итого: если Вы написали драйвер, сбилдили его под разные платформы, написали inf файл с поддержкой многоплатформенности. А теперь хотите программно его установить, все что Вам понадобится, это вызвать шесть основных функций:

...

TC>По поводу самого кода. Написан он довольно таки неряшливо и для такой судьбы " раз уж эта программа должна работать везде и всегда и её видимо будут пользовать многие люди " я бы его не рекомендовал.

Забавно, но почему-то все пишут и ... пишут умные критические посты... с описанием чудных простых способов... при этом не будучи в курсе, что для установки "подобных" inf-ов, приведенных в качестве неработающего.... Есть куда как более "простая", специальная... Даже более того, рекомендованная МСом и уже довольно давно существующая программа, под простым названием DpInst. Удивительно! Но она прекрасно устанавливает подобные аппаратные инфы... И другие — наример сетевых адаптеров... ... И вот она-то как раз и НЕ устанавливает ничего из сетевой подсистемы . ... А жаль, и иначе бы не нужно было писать подобные универсальные инсталяторы. Удивительно то, что вы потратив столько времени на "изучение опуса" но совершенно оказывается не владея сутью проблемы написали некое такое "критическое" замечание... Да... И вроде же описал все подробненько.

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

ps: Сейчас выложу новые исходники без ошибок.