Like I said, it is impossible to guarantee that the first inquiry will give you the device name. But, you can be notified asynchronously when the name is retrieved. You can register for notifications on the local bth radio handle and receive WM_DEVICECHANGE messages, see http://msdn.microsoft.com/en-us/library/aa362912.aspx. The GUID you will want to probably pay attention to is GUID_BLUETOOTH_RADIO_IN_RANGE
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bhaskar
Sent: Monday, July 07, 2008 4:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Identifying Miccrosoft Bluetooth Stack Presence
Even though the initial inquiry using BluetoothFindFirstDevice is
done, BluetoothGetDeviceInfo does not include szName field in the
first attempt.
In general from the Bluetooth icon in system tray, we get names of the
devices as the search is progressing. What might me the alternative
to retrieve names in the first attempt from the application
perspective (using Windows Bluetooth API)
Invoking BluetoothFindFirstDevice again doubles the inquiry time period.
On Thu, Jun 26, 2008 at 8:48 PM, Doron Holan wrote:
> If you know anything about bth inquiry, this is expected. The inquiry response from the remote radio does not include the name. the name must be queried for later after the inquiry is done. This has been addressed in Bluetooth 2.1 with EIR (extended inquiry response) where you get the name in the initial response, but both radios must comply for this to happen
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bhaskar
> Sent: Thursday, June 26, 2008 6:17 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Identifying Miccrosoft Bluetooth Stack Presence
>
> Thanks for the replies. Finally I am confining to
> BluetoothFindFirstRadio which returns immediately.
>
> I noticed the following while using Bluetooth APIs. The functions
> BluetoothFindFirstDevice BluetoothFindNextDevice returns
> BLUETOOTH_DEVICE_INFO.
>
> In the returned structures, the field name of the device is not
> getting filled up in the first attempt. All other details such as
> device address, class of device, etc. are getting filled up in the
> first attempt itself.
>
> The name field is only getting filled up on the second time call to
> the functions. Is this normal behavior or I need to set something
> in-order to retrieve the name in the first attempt.
>
> Regards.
>
> On Tue, Jun 24, 2008 at 9:10 PM, Doron Holan wrote:
>> The msft stack is not tied to a particular vendor’s hardware ID, so there is no way to search the tree and determine based on hw id alone that it is controlled by the msft stack. Why are you making a local copy of the guid? Just include the header and use the #define. BluetoothFindFirstRadio is doing exactly what you need, I do not see why you are going through these machinations…
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bhaskar
>> Sent: Tuesday, June 24, 2008 5:33 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Identifying Miccrosoft Bluetooth Stack Presence
>>
>> BluetoothFindFirstRadio is taking considerably less time compared to
>> BluetoothFindFirstDevice because it finds local devices.
>>
>> If I turn off the device, BluetoothFindFirstRadio returns device not available.
>>
>> As suggested, I tried the following snippet to enumerate the Bluetooth devices:
>>
>> HDEVINFO h_dev;
>> DWORD perr;
>> SP_DEVICE_INTERFACE_DATA iface_data;
>> BOOL rc;
>> const GUID guid =
>> {{0xe0cbf06c},{0xcd8b},{0xc4647},{{0xbb},{0x8a},{0x26},{0x3b},{0x43},
>> {0xf0},{0xf9},{0x74}}}; // Bluetooth Class GUID
>> h_dev = SetupDiGetClassDevs(&guid,
>> 0,
>> 0,
>> (DIGCF_PRESENT |
>> DIGCF_DEVICEINTERFACE));
>> if (h_dev == INVALID_HANDLE_VALUE) {
>> perr = GetLastError();
>> return (0);
>> }
>> iface_data.cbSize = sizeof(SP_INTERFACE_DEVICE_DATA);
>> rc = SetupDiEnumDeviceInterfaces( h_dev,
>> 0,
>> &guid,
>> 0,
>> &iface_data);
>> if (rc == FALSE) {
>> perr = GetLastError();
>> return (0);
>> }
>>
>> SetupDiEnumDeviceInterfaces returns Null and GetLastError indicates No
>> More Data Available.
>>
>> Do I need to do any other mandatory settings. Kindly provide a
>> pointer for finding BT Stack type and hardware ids using SetupDi API.
>>
>> Regards.
>>
>> On Mon, Jun 23, 2008 at 5:42 AM, Alexey Polonsky wrote:
>>> How about traversing the device tree using SetupDi API ?
>>> This way you can find out what BT stack or stacks are installed and for
>>> which hardware ids, you will also know what is the currently attached BT
>>> radio.
>>> Having multiple active BT radios is allowed by spec, but is not gonna fly,
>>> so no need to worry about that case 
>>>
>>>
>>> Bhaskar wrote:
>>>>
>>>> Here is the situation.
>>>>
>>>> I developed application using Windows Bluetooth API and tested on some
>>>> laptops with Windows XP SP2 and everything worked normally.
>>>>
>>>> When I tested the same on HP Compaq 6910p latop with Windows XP SP2,
>>>> BluetoothFindFirstDevice() failed returning E_HANDLE. After many
>>>> trials, I found that the laptop uses Widcomm bluetooth drivers. So I
>>>> switched to Widcomm SDK and it worked as expected.
>>>>
>>>> The aim is to make the same application work on machine with either
>>>> Microsoft Bluetooth or Widcomm stacks. Widcomm SDK provides
>>>> IsStackServerUp() API by which I can confirm if the Widcomm bluetooth
>>>> is present.
>>>>
>>>> I need to confirm this when I start the application so that I can call
>>>> corresponding API. If I use BluetoothFindFirstDevice(), it will take
>>>> around 9 seconds to complete.
>>>>
>>>> Is there any method like IsStackServerUp() in Windows so that I can
>>>> invoke Windows Bluetooth API to make the application work.
>>>>
>>>> Regards.
>>>>
>>>>
>>>> On Fri, Jun 20, 2008 at 10:55 PM, Doron Holan
>>>> wrote:
>>>>
>>>>>
>>>>> What do you mean by presence? The currently enabled and started
>>>>> Bluetooth radio? Or the fact that Microsoft drivers are on the disk and
>>>>> could possibly by controlling a bth radio sometime in the future (or on a
>>>>> disabled device)? If you can call BluetoothFindFirstDevice, the msft user
>>>>> mode infrastructure is present. If BletoothFindFirstDevice succeeds, the
>>>>> msft stack is up and running.
>>>>>
>>>>> d
>>>>>
>>>>> -----Original Message-----
>>>>> From: xxxxx@lists.osr.com
>>>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Bhaskar
>>>>> Sent: Friday, June 20, 2008 7:41 AM
>>>>> To: Windows System Software Devs Interest List
>>>>> Subject: Re: [ntdev] Identifying Miccrosoft Bluetooth Stack Presence
>>>>>
>>>>> Regrets. Its not unpredictable value. GetLastError() is returning
>>>>> E_HANDLE which is appropriate.
>>>>> But what I exactly searching for is the API confirming the presence of
>>>>> Microsoft Stack.
>>>>>
>>>>> Regards.
>>>>>
>>>>> On Fri, Jun 20, 2008 at 12:54 AM, Doron Holan
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> What do you mean by unpredictable values? The error code is different?
>>>>>> If there is no radio, you should never see success nor a handle returned to
>>>>>> you. If the error values are different, so what?
>>>>>>
>>>>>> d
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: xxxxx@lists.osr.com
>>>>>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>>>>>> xxxxx@gmail.com
>>>>>> Sent: Thursday, June 19, 2008 12:48 AM
>>>>>> To: Windows System Software Devs Interest List
>>>>>> Subject: [ntdev] Identifying Miccrosoft Bluetooth Stack Presence
>>>>>>
>>>>>>
>>>>>> Dear Team,
>>>>>>
>>>>>> I have a Bluetooth Application which needs to communicate with both
>>>>>> Microsoft and custom Bluetooth stacks. I used both APIs separately and able
>>>>>> to connect, communicate to the device.
>>>>>>
>>>>>> Now I need to identify the Bluetooth Stack type before starting the
>>>>>> application. In other custom Bluetooth APIs I find something like
>>>>>> IsStackServerUp () functions which will return either true or false so that
>>>>>> I can identify their stack presence.
>>>>>>
>>>>>> Can somebody provide a pointer in identifying Microsoft Windows
>>>>>> Bluetooth stack presence on the system.
>>>>>>
>>>>>> If I use APIs like BletoothFindFirstDevice (), this may block for few
>>>>>> seconds and on the systems using non-microsoft stack, the above function
>>>>>> will return with unpredictable value.
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> —
>>>>>> NTDEV is sponsored by OSR
>>>>>>
>>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>>> http://www.osr.com/seminars
>>>>>>
>>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>>
>>>>>>
>>>>>> —
>>>>>> NTDEV is sponsored by OSR
>>>>>>
>>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>>> http://www.osr.com/seminars
>>>>>>
>>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>>
>>>>>>
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>
>>>>>
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>>
>>>>
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer