I'm a Windows developer and am looking at using a RSP2 from a Windows store app. Windows store apps run in a sandboxed security context, and can't load/call arbitrary third party DLLs like older desktop programs can. This new security model is a good thing for improving system security, but it also means some of the capabilities Windows applications had in the past are no longer available.
The options for a Windows store app using special hardware include:
1) The app can open some USB device classes, and directly talk to the USB endpoints. The code that does this could be in a WinRT component DLL that is included with the app install package, but can't be installed as a DLL separate from the store app. This is especially easy if the USB device supports the enhanced GUID based interface strings.
2) I believe it's possible for a WinRT app to open a kernel device and send IOCTLs, if the device sets the correct security descriptor. If your hardware kernel driver was in the Microsoft downloadable driver library, it would automatically install when the hardware is plugged in, based on matching a PnP id. I'd have to research if the RSP2 driver was required to pass Microsoft driver certification tests to do this. Tests are not available for all types of devices. As the RSP2 is not an especially high bandwidth device, a UMDF driver might be appropriate.
Does SDRPlay have a strategy for how Windows Store apps will access their hardware? It might be possible to write a WinRT component wrapper around your current DLL library, which would require I ship your DLL as part of my product. Do the license terms of your driver interface DLL allow this kind of bundling?
Add useful snippets of code or links to entire SDR projects.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest