HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\the_device\aaa\bbb\Device Parameters "parameter"

Под админом понятно прочту. А под НЕ_админом? Именно прочесть параметры девайса с известным именем, не изменить

Прога C++ делает это как-то через ф-ции драйвера,
но при этом кушает 300мс на быстром компьютере. Борьба идет за ускорение запуска проги (VB, кот. это использует). Миллисекунды выливаются в ощутимые секунды на слабом компьютере.
Вроде бы я нашел место в реестре откуда можно прочесть в лоб...

Или это вообще неправильно: читать параметры девайса напрямую из реестра?

timtimДмитрий77,
это эмулятор с таблицей?

Нет, меня в основном интересуют модемы, COM-порты, виртуальные COM-порты.
Т.е. например внутренние имена портов могут быть BLA0, BLA1, а им соответствует параметр реестра PortName=COM10 или COM11.
Надо прочитать PortName.

Или скажем хочу узнать имена модемов в системе и на каких COM они. WMI, да, но опять же драгоценные миллисекунды, и в WMI есть глюк один.

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

>то антивирусу всё равно,
BelowZero, остынь уже. Некачественные антивирусы и вирусы - это проблемы тех кто их пишет/ставит/ловит. Мои программы работает со стандартными OS Windows от фирмы Microsoft, а не с лабораторией касперского.

Сейчас проверил на Win7 X64, под standard user, вроде проблем не возникает.
Даже KEY_WOW64_64KEY не нужен, видимо потому что это не SOFTWARE ветвь (девайс и его драйвер на x64 соответственно 64-битный).

AntonariyНи в коем случае заменять не нужно, обязательно подведут.
Я после этих слов в расстроенных чувствах.
Потому что уже заменил, протестировал в т.ч. на win7 x64 и был доволен весьма.
Что ж теперь "назад в будущее"?
AntonariyНужно собирать и использовать все способы...возвращают пустую строку
Как все сразу в моем случае...У меня то как раз пустые строки допустимы.
В принципе от "не администратора" я застрахован, т.к. ключевые компоненты проги, имеющие дело с настройками/реестром его требуют.

Смысл в чем...
Ядром системы является C++ компоненты.
(1)Например прога сохраняет и читает свои параметры через командную строку. (в HKCU)
(2)Другой компонент действует внешне точно также, но там речь идет не о проcто настройках а о драйвере (в HKLM)

Старый метод: запустить этот C++ на чтение (ShellAndContinue -с муляжной загрузкой процессора 100 либо 50%), сохранить то чего он вычитает из реестра в тестовухе и эту текстовуху прочитать через VB6. В случае драйвера C++ использует думаю какие-нибудь DeviceDeGet (на VB конечно осиливается и это но я бы не стал...это уровень до кот. вряд ли дорасту когда либо).

Естественно доверия к C++ больше чем к тому что могу родить сам, но "старый метод" дает задержки в 100-200-500мс, и оно набегает. Через VB напрямую из реестра через API читается 0-16-32мс и результат ощутим.
C (1) я справился -достаточно очевидно все хотя куча рутины, с (2) я задумался, отсюда этот топик/вопрос, хотя рутины никакой.
Antonariyвключая WMI
WMI я использую для чтения информации о модемах, установленных в системе. Глюк, про который я упомянул состоит в следующем. Есть в реестре Class, там папочки 000,001,002... Если в 000 будут испорченные данные, то WMI не способно прочитать 001,002 даже если там все корректно (это при том что "система" все равно правильно видит в панели управления и корректно работает с 001,002). В принципе я сам раньше "подставлял" пользователя под ситуацию когда он мог забабахать "брак" в 000 моей же прогой и это исправлено.
Но WMI читает очень долго, опять же, поэтому в мои планы таки входит (хоть и не сейчас) читать модемы на прямую из реестра.

AntonariyУ меня в одной программе для привязки к компу требуется получить серийный номер жесткого диска.
Жесткие диски и всякие ID это головная боль (но при этом самый надежный способ защиты). Думаю это отдельная тема и к вопросу не относится. Основная головная боль -не IDE/SATA а виртуальные машины, коего мракобесия сейчас по миру немерено. После любой переустановки "виртуальный жесткий диск" естественно летит вместе с вашей лицензией. Доп.защита: тупой (не наглый и не ругающийся на отсутствие инета) запрос на Web-сервер где хранится список неугодных ID. Дает возможность блокирнуть любой ID независимо от наличия ключа(любым примитивным способом). Нескольких любителей "оживших мертвых дисков" уже выловил.
Я этой темой в районе нового года занимался (про асинхронное чтение если помните).

AntonariyЭто не проблема. Клиенты звонят или пишут письма и мы деактивируем их серийники.
Это понятно что пишут. Какие-то "понять в чем дело не могут", какие-то с целью получить +1 лицензию.
Как деактивируете? Методом типа моего? Каждый раз безусловно получать подтверждение лицензии через инет как понимаете неправильно и чревато ложными срабатываниями.

AntonariyЗа 4 года единственное замеченное умышленное нарушение лицензии заключалось в том, что программу установили на сервер, а работу с ней организовали через терминалы, при том, что лицензия у нас персональная.
А как понимаете что через терминальные сессии?
Ну, понятно, персонально каждый терминал запустил по персональному экземпляру проги. А ID/серийник одинаковый.
Скажем так, я это специально не отслеживаю, но по переписке знаю что многие так делают/пытаются. Причем некоторые еще и права качают, почему что-то не работает, даже слегка устранял ряд проблем на эту тему (какие смог).
С другой стороны, если прога использует общие для всех "ресурсы", скажем работает "As service", общие девайсы и т.п. то особо превысить дозволенное и не получится. Но если "As Application", то какие-то ф-ции тиражировать терминалами таки можно.

Думаете, надо всерьез бороться с этим?
Как например понять, что прога запущена именно в терминале?

Если продолжить про терминалы/RDP,для решения нек. проблем на Win2003 обычно рекомендую /admin сессию. Но прикол в том что на всех Вистообразных, включая клиентские Vista/7 если проблема RDP с какой-то ф-цией существует, то через /admin она не решается, т.е. любой RDP работает аналогично терминальной сессии, пытался выяснять, но ответа не знаю пока.