I want to Convert my existing app code which interact with Kernel mode driver(WDM driver). For IOCTL i’m using DeviceIoControl APIs.
For porting my app to UWP i’m using this link : https://learn.microsoft.com/en-us/cpp/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app?view=vs-2017 .
After applying changes in project properties as mentioned in link, i’m getting error as DeviceIoControl identifier not found. That’s issue i’m facing. Is there any sample app/API available instead of DeviceIoControl?
Actually, we added DeviceIoControl to the allow list in RS5. You need to get a HANDLE to the device first, and that will require two changes
Call CreateFileFromApp instead of CreateFile
The device being opened needs to grant access to app container. If
you own the driver and it is a custom device interface, you can use
a custom cap.
If you are accessing an in box defined device interface, you can’t get a direct HANDLE to the device. If your MSR access driver is a pnp driver you can use the guidance above.
You can't use DeviceIOControl from UWP apps. You can see the list of supported Win32 and COM APIs and this is not one of them. UWP apps have a more restricted security model to make it harder to use as a malware vector, so you can't interact with arbitrary kernel mode drivers.
There is a specific scenario where you can enable a custom capability and use Windows.Devices.Custom APIs. See CustomCapability sample. This is intended for hardware support aps generally. See Hardware Support App (HSA): Steps for Driver Developers.
As mentioned by #Xavier Xie, CreateFileFromApp and CreateFile2FromApp are available in later Win10 releases to get brokered device handles from app container. This is probably the easiest approach if you already have a lot of Win32 code that you want to port.
Device access also has UWP version in Windows.Devices.Custom. This also brokers the device handle but encapsulates it into a CustomDevice object which you can use to do IO control to your device.
Note: in both cases, the device handle gets brokered (ie. created in the runtime broker in medium IL, and marshaled into the app container) if the app its self doesn't have permissions to directly open the device. What this means is that the device interface will still need to be ACL'ed or otherwise granted access such that the app can open it.
The most current best way to grant access to an app to access your device is through a custom capability. The Device Access Broker will check the interface's DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities key for the app's PFN. In the legacy flow, Device Access will check DEVPKEY_DeviceContainer_PrivilegedPackageFamilyNames.
Related
By Google Home Sample App for Matter, it seems nothing we can know about the device clusters from the device after commissioning.
// commission
Matter.getCommissioningClient(context)
.commissionDevice(commissionDeviceRequest)
After commissioning, it did the addDeviceState.
val newDeviceState =
DeviceState.newBuilder()
.setDeviceId(deviceId)
.setDateCaptured(getTimestampForNow())
.setOnline(isOnline)
.setOn(isOn)
.build()
But why it knows there is a setOn() for the device? How to know what clusters the device has?
I have read the Google Play service Matter API but there are only commission and share APIs. Are there Matter devices setting function list?
As mentioned in https://developers.home.google.com/samples/matter-app?hl=en
Note: The sample app currently only supports devices that have the On/Off server attribute, for example lights, smart plugs, and fans.
Due to this, the app always assumes that any Matter device that is commissioned via GHSAFM supports the on/off cluster.
I am trying to figure out what the best way to communicate between a GUI and a Windows system service is. Named pipe seems to be a good option because it has built-in access control mechanism to protect the channel. I found that VPN apps actually use named pipe for communicating between their GUI with system services, such as ExpressVPN and NordVPN.
It seems that these VPN apps don't use basic Windows APIs for creating named pipes (i.e. CreateNamedPipe) but some other libraries or APIs because the behavior of these apps is almost the same: The system service, which is installed by the app, creates a named pipe with a name in this format: (app_id)(username):SingleInstanceIPCChannel or a random GUID string (e.g. 64de4b4e-96e2-4444-8946-f96888f5f3bd)
Anyone knows which library or APIs have this behavior?
specifically when using cast_api.addReceiverListener("YouTube"..... can I launch any activty besides youtube?
I don't want to write my own receiver application, what are the builtin receiver applications I can activate?
Is there a built in application to launch an arbitrary URL?
You cannot launch any application that you want. Currently, your device needs to be whitelisted for an application and outside of your own app that you may have registered through the whitelisting process, there are very few apps that are "openly" available to you, such as YouTube.
At the moment, if you want to do anything "interesting", even playing back a simple media file, you need to write your own receiver.
Finally, there is no application to launch an arbitrary URL; you need to write your own receiver and app to achieve that (unless you mirror your Chromecast tab).
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
I’m working on technical part of a project for big bank and looking for information about using Secure Element (SE) that is embedded into Google Nexus 4.
What is a process to get access to SE?
I mean how to initiate a process with Google.
You may try to contact them directly, but Google will not give you access to (embedded) SE: they don't want competitors on their wallet application (specially on Android systems).
You can do this, current android version(4.0.4) has enabled access to SE without having support of platform vendor.
Please refere
http://nelenkov.blogspot.sg/2012/08/accessing-embedded-secure-element-in.html
Depends what your ambition is, can you elaborate ? Loading an application of your own onto the secure element will require crypto keys that only Google can provide, and they probably never will, for many reasons.
Alternatively, you should be able to do the same with a SIM. It only takes a few tools to load and configure an application on a test SIM (with test SIM), then you can fit it into a phone and access it through the Open Mobile API (see the SEEK for Android open source project) which is available on many devices.