What programming interfaces were new for Windows 7?
Windows 7 introduced new Ex versions of previous APIs to provide enhanced functionality. For example, the BluetoothAuthenticateDeviceEx function lets out-of-band data be passed into the function call for the device that is being authenticated. Similarly, the BluetoothRegisterForAuthenticationEx function includes pin request and numeric comparison functionality. Also, the BluetoothSendAuthenticationResponseEx function is called when an authentication request to send the numeric comparison response is received. For more information about the new Ex versions of these APIs, see “Bluetooth Functions” on the MSDN® Web site.
What programming interfaces were new for Windows Vista?
Windows Vista introduced a kernel-mode DDI for Bluetooth wireless technology, which provides access to SCO, SDP, and L2CAP. The DDI is included with Windows Driver Kit (WDK) build 6000, which was released with Windows Vista, and all later builds of the WDK. We do not intend to make the kernel-mode DDI available on earlier versions of Windows. The WLK can be used to verify that kernel-mode Bluetooth drivers comply with standard driver development practices and use the DDI correctly.
Windows Vista with SP2 and Windows 7 also support the user-mode RFComm and Bluetooth APIs. For more information, see ”Bluetooth” on the MSDN Web site.
The WDK includes documentation for the new kernel-mode DDI. For more information about how to download the WDK, see ”How to Get the WDK” on the WHDC Web site. The WLK includes documentation for Driver Test Manager (DTM). For more information about how to download the WLK, see “Windows Logo Kit” on the WHDC Web site.
How can Bluetooth and Wi-Fi radios coexist effectively?
Both Bluetooth and Wi-Fi radios operate in the 2.4-GHz frequency range, so they could momentarily try to use the same frequency. The frequency hopping technique that Bluetooth wireless technology uses prevents such a conflict from causing a complete connectivity loss, but it could reduce the transfer rates for both radios.
Version 2.0 of the Bluetooth specification supports AFH. With AFH, a Bluetooth radio senses traffic from other types of radios, marks the busy channels as ”noisy,” and avoids those channels as it hops frequencies. Windows Vista improves AFH even further by treating the ”air” as a shareable spectrum. This feature lets wireless technologies such as Wi-Fi adapters report which channels they intend to use. When the Bluetooth stack becomes active, it is notified of the reported in‑use channels and marks them as noisy.
How do I enable AFH in Windows?
Windows 8, Windows 7, and Windows Vista include a shared-spectrum model to support AFH for Bluetooth radios that are based on version 2.0 and later versions of the Bluetooth specification. However, this feature is disabled by default. For a system to support the shared spectrum model, the OEM must explicitly enable the feature and specify the width of the frequency band that should be blocked around an active Wi‑Fi channel. To specify the width of the frequency band, create a value of type REG_DWORD that is named ChannelAvoidanceRange under the following registry key:
HKLM\System\CurrentControlSet\Services\BthServ\Parameters
The ChannelAvoidanceRange value enables or disables spectrum sharing and specifies the width of the blocked frequency band. To enable spectrum sharing, set ChannelAvoidanceRange to the full width of the frequency band that should be blocked around an active Wi-Fi channel. The units are in MHz and can range from 20 to 40 (0.02 to 0.04 GHz). OEMs must determine an appropriate bandwidth based on a selected set of radios, antenna characteristics, and radio manufacturer feedback.
A new ChannelAvoidanceRange value takes effect only after the system has been rebooted. Ideally, the OEM should set the ChannelAvoidanceRange value during the preinstallation process.
For the Windows shared-spectrum model to work effectively, Wi-Fi miniport drivers must report their channel usage to the networking connections manager. The networking stack then passes the channel-use information to the Bluetooth stack.
How do I enable remote wake in Windows?
Windows 8, Windows 7, and Windows Vista with SP2 provide software support that lets Bluetooth-enabled keyboards and mouse devices wake the computer from sleep (S3) or hibernate (S4) system power states. For such a wake to be successful, the Bluetooth module must be self-powered and must have enough power to wake the computer. Even if Windows enables wake from the S4 system power state, the computer will not wake if the Bluetooth module has no power when the computer is in S4.
To enable Remote Wake in software, verify that the Bluetooth module can support wake and set the following registry values:
HKLM\System\CurrentControlSet\Services\Bthport\Parameters
\SystemRemoteWakeSupported : (DWORD) 1
HKLM\System\CurrentControlSet\Enum\USB\\
\Device Parameters\RemoteWakeEnabled : (DWORD) 1
HKLM\System\CurrentControlSet\Enum\USB\\
\Device Parameters\DeviceRemoteWakeSupported : (DWORD) 1
Note: If the Bluetooth radio’s property page in Device Manager has a Power Management tab, the radio can support wake. If no Power Management tab exists, the radio might support wake, but it is unlikely.
Bluetooth Host Radio Support Which Bluetooth host controllers does Windows support?
With Windows, a Bluetooth radio can be packaged as an external dongle or embedded inside a computer but it must be connected to one of the computer’s USB ports. The Bluetooth stack that is included with Windows 7 and Windows Vista does not support Bluetooth radio connections over PCI, I2C, serial, Secure Digital I/O (SDIO), CompactFlash, or PC Card interfaces. In Windows 8, radios connected over alternate transports can be added via a third-party bus driver. Refer to the Extensible Transport sections of the Bluetooth Devices Reference for more information.
In Windows Vista, can the Bluetooth stack be forced to load if Windows cannot match the device ID?
A new Bluetooth radio might not match any of the device IDs in the Bluetooth INF (Bth.inf) that is included with Windows. This prevents Windows from loading a Bluetooth stack for the device. IHVs should ensure that their radio works with the native Bluetooth stack in one of the following ways:
Create an INF for the radio that references Bth.inf. For an example of a vendor-specific INF file for a Bluetooth radio, see Appendix B.
Store an extended compat ID OS descriptor in the device firmware that specifies an appropriate compatible and subcompatible ID. For information about extended compat ID OS descriptors, see ”Microsoft OS Descriptors” on the WHDC Web site.
Force the Bluetooth stack to load.
.
The following procedure summarizes how to use Device Manager to force the Bluetooth stack to load for a new radio:
1. Run the Control Panel Device Manager application and identify the Bluetooth radio on the list of devices.
2. To run the Update Driver Software Wizard, right-click the Bluetooth radio item and select Update Driver Software.
3. Use the wizard to force the Bluetooth stack to install.
For a detailed description of this procedure, see Appendix A.
How do I ensure in-box support for Bluetooth radios in Windows Vista?
IHVs should take the following steps to ensure that their Bluetooth radios have in‑box support on Windows:
Ensure that the radio supports the extended compat ID OS feature descriptor. For details, see “Microsoft OS Descriptors” on the WHDC Web site.
Obtain a Windows logo for the Bluetooth radio hardware and the associated INF file. For an example of a vendor-specific INF file for a Bluetooth radio, see Appendix B.
Use the Windows Dev Center - Hardware Dashboard to make the INF file available through Windows Update.
It is no longer possible to add radios to the in-box Bth.inf file for Windows Vista.
Should third-party INF files use the Microsoft-defined class GUID?
IHVs should use the Microsoft-defined class globally unique identifier (GUID) ({e0cbf06c‑cd8b‑4647‑bb8a‑263b43f0f974}) for Bluetooth devices only in those INF files that reference the in-box Bluetooth INF file (Bth.inf). This means that the device uses the native Windows co‑installer, services, and notification area icon. IHVs that implement their own Bluetooth stack must create a vendor-specific class GUID and use the WLK test tools to ensure that the stack complies with the unclassified logo program.
Why is the Control Panel Bluetooth application missing in Windows 7?
In Windows 7, the Control Panel Bluetooth application was incorporated into Devices and Printers. Thus, adjusting the Bluetooth radio settings, managing Bluetooth devices, and adding new Bluetooth devices can only be performed from within Devices and Printers.
Why does the Bluetooth icon not appear in the taskbar?
If the Bluetooth icon does not appear in the taskbar, it could be due to one or more of the following reasons:
The Bluetooth radio is turned off.
The Bluetooth radio is in emulation mode.
In the Bluetooth Settings dialog, the Show the Bluetooth icon in the notification area check box is not selected.
Does Windows support Bluetooth radio firmware updates?
Currently, the Bluetooth stack that is included with Windows does not directly support firmware updates. However, for Bluetooth radios connected through a USB port, Windows does support firmware updates in compliance with the USB Device Firmware Update (DFU) specification. IHVs can create a user-mode utility that communicates with their Bluetooth radio over the DFU interface to perform the firmware update and restart the radio.
Does Windows support vendor-specific pass-through commands?
Windows 8, Windows 7, and Windows Vista with SP2 include support for vendor-specific pass-through commands. These kernel-mode interfaces are documented in the WDK.
Does Windows support vendor-supplied profiles?
Windows8, Windows 7, and Windows Vista support vendor-supplied Bluetooth profiles. However, Windows XP does not. The GUIDs for those profiles that have been standardized by the Bluetooth SIG are included in the in‑box INF file (Bth.inf).
When users pair a Bluetooth device with a computer, the device’s profiles are compared to the profiles that are listed in Bth.inf. If the device profile does not match one of those profiles, users receive a dialog box that asks them to provide appropriate vendor software.
Vendors that want a vendor-specific profile must use their own GUID and reference it in a vendor-specific INF file. This INF file can use Include and Needs directives to reference the appropriate Bth.inf sections and directives. For an example of a vendor-specific INF file, see Appendix B.
Why are only some Bluetooth profiles and protocols enabled by default?
The Bluetooth stack that is included with Windows provides in-box support for only some Bluetooth profiles. Vendors must implement the required services to support any other Bluetooth profiles, much as they do for USB and PCI. Windows can use the Bluetooth profiles that are enabled by default—referred to as supported profiles—to generate physical device objects (PDOs). This allows default loading of the drivers that are required to enable the profile. You can identify the supported profiles in the registry by looking at the SupportedServices and UnsupportedServices values under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Bthport \Parameters key.
Note: The Bthport key is added to the registry only after you install a Bluetooth device.
Table 5 lists the profiles in Bth.inf that Windows supports.
Table 5. Windows XP Bluetooth Profiles
Service ID
|
Description
|
{00001101-0000-1000-8000-00805f9b34fb}
|
SPP
|
{00001103-0000-1000-8000-00805f9b34fb}
|
DUN
|
{00001124-0000-1000-8000-00805f9b34fb}
|
HID
|
{00001126-0000-1000-8000-00805f9b34fb}
|
HCRP
|
Table 6 lists the unsupported Bluetooth profiles and protocols. Note that, in this context, “unsupported” means that Windows does not automatically generate a PDO or devnode or display the Add New Hardware Wizard. Therefore, some in-box profiles and protocols are handled as if they are unsupported. For example, SDP is an in-box protocol that has a Bluetooth service ID but does not require a PDO. The SDP protocol is therefore marked as unsupported in Bth.inf to prevent the creation of a PDO.
Table 6. Unsupported Bluetooth Profiles and Protocols
Service ID
|
In-box
|
Description
|
{0000110a-0000-1000-8000-00805f9b34fb}
|
No
|
Audio Source
|
{0000110c-0000-1000-8000-00805f9b34fb}
|
No
|
AV Remote Target
|
{00001001-0000-1000-8000-00805f9b34fb}
|
No
|
Browse Group Service
|
{00001111-0000-1000-8000-00805f9b34fb}
|
No
|
Fax Service
|
{0000111f-0000-1000-8000-00805f9b34fb}
|
No
|
Handsfree Audio Gateway
|
{00001112-0000-1000-8000-00805f9b34fb}
|
No
|
Headset Audio Gateway
|
{00001104-0000-1000-8000-00805f9b34fb}
|
No
|
Infrared Mobile Communication (IRMC) Sync Service
|
{00001107-0000-1000-8000-00805f9b34fb}
|
No
|
IRMC Sync Commands
|
{00001106-0000-1000-8000-00805f9b34fb}
|
Yes
|
Obex File Transfer
|
{00001105-0000-1000-8000-00805f9b34fb}
|
Yes
|
Object Push
|
{00001117-0000-1000-8000-00805f9b34fb}
|
No
|
PAN group ad hoc network (GN)
|
{00001116-0000-1000-8000-00805f9b34fb}
|
No
|
PAN network access point (NAP)
|
{00001115-0000-1000-8000-00805f9b34fb}
|
Yes
|
PAN U
|
{0000112e-0000-1000-8000-00805f9b34fb}
|
No
|
Phone book client equipment (PCE) service
|
{0000112f-0000-1000-8000-00805f9b34fb}
|
No
|
Phone book server equipment (PSE) service
|
{00001200-0000-1000-8000-00805f9b34fb}
|
Yes
|
PnP service
|
{00001002-0000-1000-8000-00805f9b34fb}
|
No
|
Public Browse Group Service
|
{00001000-0000-1000-8000-00805f9b34fb}
|
Yes
|
SDP
|
{0000112d-0000-1000-8000-00805f9b34fb}
|
No
|
Sim Access
|
If IHVs do not want Windows to automatically generate a PDO for their device, they can add the service GUID to the list of unsupported services. For examples, see Bth.inf.
Can Group Policy block Bluetooth radio installation?
For details on how to use Group Policy to block the installation of Bluetooth radios, see ”Step-by-Step Guide to Controlling Device Installation and Usage with Group Policy.”
How do I change the Device ID Profile record published by Windows 8?
The Device ID Profile defines an SDP record that can be used to provide identity information to remote devices. Previous and current Windows versions have used the Device ID record published on paired devices to provide device-specific Hardware IDs for generic Bluetooth services.
Beginning with Windows 8, Windows will also publish a local Device ID record to identify the Windows 8 device to remote Bluetooth devices. The default values can be adjusted by OEMs to better identify their specific Windows 8 device. These values are defined as in Table 7 under the HKLM\System\CCS\services\BTHPORT\Parameters registry key:
Table 7. Default Device ID record published by Windows 8
ValueName
|
Type
|
Description
|
Default Value
|
DIDVendorIDSource
|
DWORD
|
0x01 = Bluetooth SIG namespace
|
0x01
|
|
|
0x02 = USB Forum namespace
|
|
DIDVendorID
|
DWORD
|
OEM specified VendorID
|
0x06 – Microsoft Vendor ID
|
DIDProductID
|
DWORD
|
OEM specified ProductID
|
0x01 – Microsoft Windows
|
DIDVersion
|
DWORD
|
OEM specified product version
|
0x0800 – Windows 8
|
|
