С ветвлением по типу ОС разобрался.
А как быть если мне нужно, к примеру, start_code определить относительно другой записи в реестре? Т.е. алгоритм примерно такой: читается некоторое значение ключа в реестре и в зависимости от него определяется start_code. Такое в .INF возможно? Или я слишком много от него хочу? :о)
Как на основе параметров вызова CreateService() составить аналогичный по действию файл .INF ?
Т.е. есть вызов:
SC_HANDLE CreateService(
hSCManager, // handle to SCM database
"ServiceName", // name of service to start
"lpDisplayName", // display name
SERVICE_ALL_ACCESS, // type of access to service
SERVICE_KERNEL_DRIVER, // type of service
SERVICE_SYSTEM_START, // when to start service
SERVICE_ERROR_NORMAL, // severity of service failure
"BinaryPathName", // name of binary file
"PNP_TDI", // name of load ordering group
TagId, // tag identifier
"Tcpip\0", // array of dependency names
"ServiceStartName", // account name
"Password" // account password
);
как будет выглядеть соотв. .inf ?
[Win32] Вообще-то при установке девайса сервис - не единственная задача inf файла15.08.03 12:50 Автор: amirul <Serge> Статус: The Elderman
> Как на основе параметров вызова CreateService() составить > аналогичный по действию файл .INF ? > Т.е. есть вызов: > > SC_HANDLE CreateService( > hSCManager, // handle to SCM database > "ServiceName", // name of service to start > "lpDisplayName", // display name > SERVICE_ALL_ACCESS, // type of access to service > SERVICE_KERNEL_DRIVER, // type of service > SERVICE_SYSTEM_START, // when to start service > SERVICE_ERROR_NORMAL, // severity of service failure > "BinaryPathName", // name of binary file > "PNP_TDI", // name of load ordering group > TagId, // tag identifier > "Tcpip\0", // array of dependency names > "ServiceStartName", // account name > "Password" // account password > ); > > как будет выглядеть соотв. .inf ? Посему напишу только часть
В секции DDInstall.Services даешь директиву AddService со следующим синтаксисом:
Спасибо за ответ.
Есть еще вопрос. Можно ли в .INF создать ветвление, например, различные start_code при некоторых различных условиях? И если можно, то как передавать параметр выбора при установке. Можно ли создавать ветвления в зависимости от ОС, как?
Еще вопрос по .INF15.08.03 14:00 Автор: amirul <Serge> Статус: The Elderman
> Спасибо за ответ. > Есть еще вопрос. Можно ли в .INF создать ветвление, > например, различные start_code при некоторых различных Это смотря что ты собираешься ставить inf-ом. Вообще-то для установки устройств есть секция [Manufacturer], в которой перечисляются устройства, которые может ставить этот inf.
> условиях? И если можно, то как передавать параметр выбора > при установке. Можно ли создавать ветвления в зависимости > от ОС, как? Ветвления создаются при помощи т.н. decorated названий секций. Подробнее смотри в MSDN статью "Creating INF Files for Multiple Platforms and Operating Systems"
С ветвлением по типу ОС разобрался.
А как быть если мне нужно, к примеру, start_code определить относительно другой записи в реестре? Т.е. алгоритм примерно такой: читается некоторое значение ключа в реестре и в зависимости от него определяется start_code. Такое в .INF возможно? Или я слишком много от него хочу? :о)
Нельзя15.08.03 15:06 Автор: amirul <Serge> Статус: The Elderman
> С ветвлением по типу ОС разобрался. > А как быть если мне нужно, к примеру, start_code определить > относительно другой записи в реестре? Т.е. алгоритм > примерно такой: читается некоторое значение ключа в реестре > и в зависимости от него определяется start_code. Такое в > .INF возможно? Или я слишком много от него хочу? :о) Вернее, смотря чего ты хочешь. Может это можно сделать и по-другому. В принципе inf - это не исполняемый файл, и сам не может иметь какую то логику, но часто он выполняется в паре с co-installer-ом. А вот он может и выбирать и делать все остальное.
Нельзя15.08.03 15:15 Автор: Green Статус: Незарегистрированный пользователь
> Вернее, смотря чего ты хочешь. Может это можно сделать и > по-другому. В принципе inf - это не исполняемый файл, и сам > не может иметь какую то логику, но часто он выполняется в > паре с co-installer-ом. А вот он может и выбирать и делать > все остальное.
Ясно. Спасибо за ответы.
Просто, есть некий проект, инсталяция необходимых дров была в .EXE. Я хотел по аналогии создать .INF для большей гибкости (чтоб не пересобирать каждый рах этот Install.exe при изменениях), а далее (по завершению разработки) на основе этого .INF создать дистрибутив с помощью какого-либо InstallShield или т.п.