Привет.

Подойду к вопросу с предыстории. Постоянно занимаюсь работой с COM и LPT портами. Давно уже столкнулся с проблемой определения доступа к порту. По классике, все предлагают узнать список портов, и по очереди проверить их на возможность открытия, открывая и закрывая его. Очень часто замечал, что без исключения весь софт, который я видел, и который определял занят-ли порт для открытия, напрочь зависает при некоторых "мифических" обстоятельствах. Эти обстоятельства оказались банальны, порты открываются путём "CreateFile", а логика работы такова, что при открытии могут происходить события блокирующие CreateFile. В итоге функция "CreateFile" уходит в вечный цикл. Например ставим BlueTooth адаптер, берём телефон, находим адаптером его, резервируем виртуальный порт и запускаем, любой терминал который проверяет возможность открытия портов. В итоге на телефоне делается запрос пароля, и пока вы его не подтвердите мы получаем вечный цикл. Собственно я работаю параллельно с 20-30 портами, такая уж специфика работы, вокруг меня может быть до 100 устройств с автоматическим режимом поиска BlueTooth точек и активацией SPP. Ну и вставленный BT адаптер спокойно может автоматом всю эту сотню внести в список и назначить кучу портов. И не дай боже запустить софт с авто-определением доступа к порту.

Собственно я хотел бы доработать эту неполадку в своём софте, где часто надо автоматом узнать какие порты открыты. Я вижу два пути:

1. Как узнать сможет ли винда октрыть файл с именем "\\.\COMх", не производя это действие ? Ведь это очевидно, что внутри есть алгоритм проверки на предмет отсечения по доступу.

2. Где можно найти то ли в реестре, то ли вытащить более правильно флаг на предмет, что порт уже открыт ???

Спасибо за помощь.

насколько мне известно 

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

Простите, но именно блокируется. Из процедуры CreateFile никогда не выйдет, пока с той стороны не введут пароль. Мало того, если в отдельном потоке сделать CreateFile, и прибить поток, да и вообще закрыть приложение, пока не перевоткнуть BT адаптер более открыть этот порт нельзя. Это проверено десятки раз, на протяжении двух лет как наша компания производит эти модули, если надо могу записать видео. Проверено как на BlueSoleil так и на BluetoothBTW, драйверах. Разница лишь в том что в BlueSoleil таймаут ожидания на тишину ввода пароля 1 минута, а в BluetoothBTW ожидание 20 секунду. Но в любом случае это невероятно ужасные задержки, которые никак не могут устроить.
Тишина ввода пароля имеется в виду что девайс не отвечает. Ибо можно вводить цифру и удалять, на каждое данное действие на ту сторону отправляется пакет процесса, таким образом я могу навечно завесить порт, и помочь может только вытаскивание BT модуля на горячую.

Добавлено через 10 минут и 44 секунды

Выбор как OverLapped, так  синхронного режима не влияет на зависание и выход из CreateFile не осуществляется.

может чем то поможет 
http://forums.codeguru.com/showthread.php?...for-alternative
а вообще если виснет , то можно попробовать отследить кто именно замораживает систему (используя дебагер уровня ядра) , плюс проблема может быть именно в блютуз адаптере именно в его драйверах!!!

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


Спасибо ... Но по ссылке только конфигурация. Информации о том, открыт ли порт, в конфигурациях нет. Собственно с точки зрения работы COM порта это очевидно. Ему всё равно кто ему говорит отправить байтик, эта блокировка отдана операционной системе. Вот я и хочу узнать как получить этот статус блокировки ?

Добавлено через 4 минуты и 18 секунд

Это не проблема а логическое действие. Так себя будет вести как любой адаптер, так и любой драйвер. Иначе система паролей в протоколе SPP будет невозможна.

Нужно узнать как определить даст ли система открыть файл с данным именем не производя это действие. Фактически нужна одна из веток внутри CreateFile.

я думаю , что решать эту проблему путем winapi будет очень проблематично , ибо эта инициация  связи находится в введении блютуза, вот к нему и надо обращатся, может поможет эта ссылка http://people.csail.mit.edu/rudolph/Teachi...cles/BTBook.pdf или техдокументация на ваш адаптер блютуз...

Нет моего адаптера, есть совершенно любой адаптер производимый тысячами компаний с протоколом последовательного порта SPP. Для операционной системы это простой COM-PORT.


Как работает стек блютуза я отлично знаю. Я говорю про прокладку в операционной системе, а не про низкий уровень работы стека и конфигурации его на адаптере. Не важно блютуз это или USB переходник, или WiFi-SPP ... Всё это просто девайсы, которые подключены к компьютеру по соответствующему интерфейсу и они работают исправно. Стек SPP это простой протокол, а информацию открыл кто-то порт или нет находится только в операционной системе. SPP протокол не знает открыли его или нет.

Если вы откроете COM-порт в блютузе, и попытаетесь его открыть снова, то никаких пакетов в эфир не уйдёт, никаких запросов к адаптеру блютуза не будет. Просто операционная система увидит, что COMx уже открыт и даст отбой.

Проблема не в драйверах, они все работают одинаково и смысл у них простой, CreteFile("\\.\COMx") выполняет такие действия:
1. Проверить свободный ли порт COMx
 если свободный то:
2. Сделать согласование по SPP стеку
3. Запросить пароль ...
 если пароль подтвердили то:
4. Занять COMx, выделить handler
 выдать результат наружу

Вот мне нужен только первый пункт !!!

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

PS у CreteFile нет стандартных путей решения вашей проблемы... или создавать свой драйвер или пользоваться ф-ционалом предоставляемым блютуз

Нет такого единого функционала. Блютуз-адаптеры могут иметь совершенно разные драйвера и работать по разным протоколам. например BlueGiga работает по USB, и у него стандарт который поддерживается BlueSoleil'ом. А WaveSen (HC-05), так же работает по USB, но BlueSoleil'ом он не видится вообще, за-то BluetoothBTW видит и тот и другой. У них совершенно разные механизмы, которые пользователю дают только виртуальный комп-порт.


Это очень низко профессиональный подход, который привёл к подобной проблеме и в результате породил кучу недовольных пользователей который кричат, что залипают порты, например, на USB переходниках. Вынул переходник при открытом порте и он в системе залип. Благо эта проблема уже решена.


Я уверен, что есть не стандартный путь. Залипшие порты то же считали не решаемой проблемой, а всё свелось к тому, что просто не знали грамотно построенного алгоритма.

Спасибо, я всё же постараюсь поискать решение данной проблемы ещё.

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

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

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

Хм... Если у меня ОС зависает, то это значит ее написали  низко профессиональные программисты