I need to scan Wifi access point on Windows Mobile and connect the one of scanned results.
Currently I am using C# language, Windows Mobile 6.5 device, also to scan I am using the below code.
[DllImport(wlanapi.dll", SetLastError=true)]
I am using wlanapi.dll, but it seems that not possible to use on Mobile.
Does anyone know about the belows.
Could I use the dll in Windows Mobile 6.5 to scan and connect?
If the 1 is not possible, please let me know the different methods..
Please give me the clues.
wlanapi.dll doesn't exist in WinMo/WinCE. You have to use an API that is supported.
Most WinMo WiFi drivers (though probably not all) support the Wireless Zero Config (WZC) set of APIs. The native versions of these APIs, like WZCQueryInterface, are outlined in MSDN.
Microsoft does not provide any managed interface for these APIs, in fact the native documentation for them is pretty bad too. The definitive "example" of it's use is in the NETUI component source of Platform Builder. Gettign the eval version just for the source is very worthwhile if you plan to do much WinCE/WinMo development.
From a managed perspective I wrote an MSDN article back in '06 that talks about using the SDF for getting network info. The SDF has been reworked a lot since then, especially in the WZC area, but it's still pretty similar.
I did an updated blog post in '07 about custom-drawn ListBoxes, and while that's not what you're after, the data being displayed is wireless network info, which is in line with what you're after.
Related
How is VirtualHere able to virtualize USB devices on macOS without requiring the user to install kernel extensions?
As far as I am aware, there's no documented way to virtualize USB devices on macOS.
The USB/IP project, for example, only supports clients on Windows and Linux.
I understand this is proprietary software but it must be using some technique available to userspace?
Thanks
Really interesting.
Seems they are using the IOUSBHost.framework, which is at most undocumented.
Using it requires getting custom entitlement from Apple:
com.apple.usb.hostcontrollerinterface, which could possibly take a lot of time.
There are some traces that it could be used to create virtual devices, but no details about it.
You could try to use tools like classdump to get some information directly from the framework, or read some headers on github.
It would be great if someone could share any information about it with community, as Apple seems to be very lazy about doing this.
In Windows 8/8.1 it's now possible to enable/disable Bluetooth via the OS itself (see image below). This is awesome because it's device/driver-agnostic.
On Android, this is possible via BluetoothAdapter.enable() and BluetoothAdapter.disable(), but I haven't been able to find anything to do this on Windows (even though it seems like it's definitely possible).
So I've tried using:
BluetoothEnableIncomingConnections() - However, this only prevents new incoming connections. It doesn't disable existing ones.
devcon.exe - The problem with this method is that A. it is a non-redistributable binary B. it requires that you know he device ID ahead of time (so it's not device/driver-agnostic). Also, while it's not a dealbreaker, it'd be nice to not require elevation.
UI Automation - Simply launching the PC Settings app and toggling the switch with keyboard events is easy, but it's super ugly, both in terms of proper coding practices and in terms of user experience. That being said, this is the only way I've found to achieve the behavior I'm looking for so far.
I'm writing a native Win32 app in C++, so I'm not constrained to any Windows Store app requirements, although, it would be great if there was an approach that didn't require elevation.
TL;DR
Are there any APIs, WMI interfaces, or anything else available to achieve functionally equivalent results to flipping the Bluetooth toggle switch? If not, are there any alternative methods which yield similar results?
In win8.1 you should be able to call BluetoothEnableRadio to enable/disable the local radio.
Basically the manufacturers should include a method to accomplish this so you don't have to load a dll.
"Beginning with Windows 8.1 vendors are no longer required to implement radio on/off capability (for Bluetooth 4.0 radios) in a software DLL as described in this topic, because the operating system now handles this functionality. Windows 8.1 will ignore any such DLL, even if present."
check out this link which talks about it:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh450832%28v=vs.85%29.aspx
I know that in the constructor of the GeoCoordinateWatcher object there is the possibility to specify the accuracy (default or high), but for my university project I need to know more.
My professor asked me to search and specify also the algorithm or the heuristics used by the GeoCoordinateWatcher to choose his source.
I'm already aware of the MSDN article which says
Although the Location Service uses multiple sources of location information, and any of the sources may not be available at any given time (for example, no GPS satellites or cell phone towers may be accessible), the native code layer handles the work of evaluating the available data and choosing the best set of sources. All your application needs to do is to choose between high accuracy or the default, power-optimized setting. You can set this value when you initialize the main Location Service class, GeoCoordinateWatcher.
but I need to know more exactly how the native code layer handles the evaluation of the source.
Anyone can help me with this or point me to some more detailed article?
If you take a look into the source code of the System.Device assembly (by using a decompiler like dotPeek), you can see how it works.
In fact the GeoCoordinateWatcher is just a small wrapper that creates a COM object of type ILocation. This interface is part of the Location API, that Microsoft introduced with Windows 7. This itself is a part of the Sensor API, that also started with Windows 7.
If you dig a little bit through this documenation, you'll find this introduction article, which describes how this API works. One sentence within this introductions is:
Sensor manufacturers can create device drivers to connect sensors with
Windows 7. Sensor device drivers are implemented by using the Windows
Portable Devices (WPD) driver model, which is based on the Windows
User Mode Driver Framework (UMDF).Many device drivers have been
written by using these frameworks.
So the manufacturers of GPS devices will provide a windows driver that will be installed on a system. This driver will announce itself as a location device to the system.
When you create a GeoCoordinateWatcher it asks through the location api for the desired data. The operation system checks which drivers have announced itself for being capable and starts these drivers. These drivers will then open the connection to the device, reading the data and forward it to the desired consumers.
I'm trying to implement an AVRCP/A2DP connection between my Android phone and my car PC. The A2DP bit basically works out of the box so no issue there. I want the PC to be the AVRCP CT (controller) and the A2DP sink. The phone is the AVRCP TG (target) and the A2DP source.
Where I'm having trouble is getting any sort of AVRCP connection that I can use. Windows 7 comes with a toolbar application that at least provides the basic play/pause/skip/stop type functions. So it definitely works with the software I have without any extra drivers or otherwise. However my searching has produced little results on any way to do this or documentation on creating an L2CAP connection which I believe I need.
The 32feet.NET libraries don't support L2CAP connections unless you use a Broadcom/Widcomm stack. Buying a new BT USB device may be a viable solution but at the moment I'm trying to do this all in software :). i.e. like this although there a problems noted there that weren't solve (or reported as solved)
link: How can I establish an AVRCP connection from Windows 7 (controller) to phone (target) using L2CAP on Widcomm SDK?
I'd prefer to do it C# if possible but if I had some kind of library to interface with my code, that would be fine (like the 32feet.NET library which works quite well for the things it does work on.)
This is about the closest I've got but is all a bit Greek to me and not quite enough to get me started (I'm an embedded guy):
http://msdn.microsoft.com/en-us/library/windows/hardware/ff536674(v=vs.85).aspx
Is Bluetooth really such a mess on Windows that it seems to be from my searching? There are multiple different stacks that all seem to be significantly different in terms of the API etc.
Can anyone point me in the right direction? I've done a lot of searching/reading other posts here and elsewhere and not really made any progress.
Thanks
Christian
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.