Problem
When VxKex-NEXT redirects BluetoothApis → kxuser, applications that call the classic Bluetooth discovery functions fail with "The procedure entry point BluetoothFindNextDevice could not be located in the dynamic link library kxuser.dll" (or similar).
These functions are available on Windows 7 (in bthprops.cpl / BluetoothApis.dll) since XP SP2 / Vista, but they are currently not exported from kxuser.dll.
Only the newer GATT functions are present in blutooth.c / kxuser.def:
Requested change
Please add stubs or (preferably) proper forwarders for the classic Bluetooth device enumeration family:
BluetoothFindFirstDevice
BluetoothFindNextDevice
BluetoothFindDeviceClose
BluetoothFindFirstRadio
BluetoothFindNextRadio
BluetoothFindRadioClose
- (and any other closely related classic APIs if easy)
The simplest and most correct approach would be to forward them to the real system implementation in bthprops.cpl / BluetoothApis.dll, similar to how other forwarders are done in VxKex.
Why it matters
Some applications (including certain launchers and tools) call these functions even if they don't heavily rely on Bluetooth. Because of the DLL redirect, they crash or show entry-point errors under VxKex-NEXT.
Environment
- Windows 7 SP1 x64
- Latest VxKex-NEXT release
Thank you!
Problem
When VxKex-NEXT redirects
BluetoothApis→kxuser, applications that call the classic Bluetooth discovery functions fail with "The procedure entry point BluetoothFindNextDevice could not be located in the dynamic link library kxuser.dll" (or similar).These functions are available on Windows 7 (in
bthprops.cpl/BluetoothApis.dll) since XP SP2 / Vista, but they are currently not exported fromkxuser.dll.Only the newer GATT functions are present in
blutooth.c/kxuser.def:Requested change
Please add stubs or (preferably) proper forwarders for the classic Bluetooth device enumeration family:
BluetoothFindFirstDeviceBluetoothFindNextDeviceBluetoothFindDeviceCloseBluetoothFindFirstRadioBluetoothFindNextRadioBluetoothFindRadioCloseThe simplest and most correct approach would be to forward them to the real system implementation in
bthprops.cpl/BluetoothApis.dll, similar to how other forwarders are done in VxKex.Why it matters
Some applications (including certain launchers and tools) call these functions even if they don't heavily rely on Bluetooth. Because of the DLL redirect, they crash or show entry-point errors under VxKex-NEXT.
Environment
Thank you!