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.
Related
For more details, I'm using BluetoothApis.h and WinSocks2.0 as well as C++/WinRT on a win32 app. I have all the connections finished but wanted to add a check for a Bluetooth low energy (BLE) capable radio before trying to connect. Unfortunately the C++/WinRT functions don't play very nice with win32 apps. Radio.GetRadiosAsync and BluetoothAdapter.GetRadioAsync both have to be compiled to a target architecture (see "Remarks" section on either page), which in my case, has to be a 32-bit machine due to a .dll that I am using, but if those functions don't work on 64-bit machines... I'm not familiar with how 64-bit machines run 32-bit apps.
My question is this; is there a way to check if a bluetooth radio is BLE capable? I've looked through the bluetoothApis.h and found how to get radios, but I couldn't find a way to check for BLE capability. I've also looked through the bluetoothLEApis.h but couldn't find anything related to the radio itself. If anyone has an idea, do tell.
After closer inspection, I noticed that there was another member function that can create a Bluetooth object.
The BluetoothAdapter class' GetDefaultAsync() function does NOT have the same restrictions as GetRadioAsync() does. This is enough to retrieve the information on the Bluetooth low energy capabilities that I need.
I want to write a Windows application which accesses the joystick. It is just a very simple application which reads the values and sends them to a server, so I am not using any game programming framework. However, I am confused about which API to use.
I looked at the Multimedia Joystick API, but this is described as superseded by DirectInput. So I looked at DirectInput, but this is also deprecated in favour of XInput.
However the XInput documentation talks only about Xbox360 controllers, and says it does not support "legacy DirectInput devices".
Have Microsoft consigned the entire HID Joystick usage type to the dustbin and given up on supporting them in favour of their own proprietary controller products, or am I missing something?
The most common solution is to use a combination of XInput and DirectInput so your application can properly access both type of devices. Microsoft even provides instructions on how to do this.
Please note that DirectInput is not available for Windows Store apps so if you intend to distribute through there, that's not an option.
XInput devices like the XBox 360 controller will also work with DirectInput but with some limitations. Notably, the left and right trigger will be mapped to the same axis instead of being independents, and vibration effects will not be available.
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.
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.
I need some advice on windows programming, MIDI and WDM. I am trying to write a small application that will sit in the sys tray and be advertised to the system as a MIDI In/Out device so that MIDI programs can send to it and it will convert the messages into a different format. I have been reading Cant's WDM book and scouring for information about writing device drivers, but don't know if I'm going down the right path.
I don't see yet how to:-
a) register my driver as MIDI capable (do I stick a ref to it in the registery and let the OS direct MIDI calls to the functionality in a dll?)
b) direct MIDI data through the my driver to my app, which is probably going to be too large to be a driver itself.
Any advice on where to start would be much appreciated.
thanks,
Pete
Windows MIDI drivers do not need to be implemented in the kernel, they can be implemented entirely in userspace as DLLs.
MSDN has some information about the functions you need to implement -
Audio Device Messages for MIDI - unfortunately it is somewhat lacking.
There used to be sample code for this kind of driver, as part of the NT4 DDK, but more recent releases of the DDK / WDK unfortunately don't include it any more.
Some better (though older) documentation and sample code can still be found after some searching:
Introduction to Multimedia Drivers (From NT4 DDK)
Sample MIDI Wine Driver for Mac OS X
Devices are enumerated (or simulated) by device drivers, not applications. What you see in the sys tray is an application icon. Hence, you will need to have both a driver and an app - you can't have one bit of compiled code acting as both.
On the driver side, you probably want to have a peek at the MSDN docs. This will answer part (a) of yopur question.
Assuming that you still would like to continue, (b) is best don by letting your application pull the data from the driver. That's far easier than the other way around - an application can trivially find a driver, but a driver has big problems finding a specific app (process)
If you are looking for a bit easier way to get started, there is a MIDI loopback driver out there, and the folks that make it also offer (or used to offer) a version of it that allows your program to communicate directly with the driver. This gives you the behavior you are looking for, where a program appears as a MIDI device. The loopback driver is at http://nerds.de/en/loopbe1.html. I don't see the developer page anymore, but if you contact them, you might be able to purchase a license to a driver that you can access directly without the loopback.