UWP and accessing driver

How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
Is the APi below the right one for Win10?
Device Access API
https://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v=vs.85).aspx

You don’t want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers.

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@x-publisher.com
Sent: Tuesday, April 3, 2018 2:28:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] UWP and accessing driver

How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
Is the APi below the right one for Win10?
Device Access API
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fhh404235(v%3Dvs.85).aspx&data=02|01|Doron.Holan%40microsoft.com|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&reserved=0


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

>How do we access a driver under UWP.

I *get* that getting rid of random IOCTLs and random interactions with the hardware is a specific goal, not a side-effect… but to me, if I need to ask MSFT permission for every single IOCTL I want to implement for every single customer and every single project (and that’s certainly the way I understand it’s supposed to work) this is just not going to happen.

I’d be (grudgingly) willing to jump through the hoops to use a custom capability from a UWP app if I could just generate a GUID and associate it with my Seller ID (or whatever). But asking MSFT’s blessing? If that’s really how this must work, I just don’t see it.

Peter
OSR
@OSRDrivers

“if I need to ask MSFT permission for every single IOCTL I want to
implement”

Wait, a custom capability means the ioctl’s you expose to a user app?

On Tue, Apr 3, 2018 at 8:48 AM, xxxxx@osr.com wrote:

> >How do we access a driver under UWP.
>
> I get that getting rid of random IOCTLs and random interactions with the
> hardware is a specific goal, not a side-effect… but to me, if I need to
> ask MSFT permission for every single IOCTL I want to implement for every
> single customer and every single project (and that’s certainly the way I
> understand it’s supposed to work) this is just not going to happen.
>
> I’d be (grudgingly) willing to jump through the hoops to use a custom
> capability from a UWP app if I could just generate a GUID and associate it
> with my Seller ID (or whatever). But asking MSFT’s blessing? If that’s
> really how this must work, I just don’t see it.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

>Wait, a custom capability means the ioctl’s you expose to a user app?

Well, you understand there ARE no IOCTLs in UWP, right? So, what we USED to do via custom IOCTLs from Win32, we are now get to do via Custom Capabilities in UWP.

Peter
OSR
@OSRDrivers

A custom capability describes the security for an object and access to it. It enables access to a driver or an RPC endpoint. It does not control what you once you have access to that resource (specific IOCTLs, RPC calls, etc). I think what Peter is referring to is that

  1. You have to provide a general description of what the custom capability exposes when you ask for the capability
  2. Microsoft must sign the capability file that grants the cap to the application
    d

From: xxxxx@lists.osr.com On Behalf Of xxxxx@gmail.com
Sent: Tuesday, April 3, 2018 2:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UWP and accessing driver

“if I need to ask MSFT permission for every single IOCTL I want to implement”

Wait, a custom capability means the ioctl’s you expose to a user app?

On Tue, Apr 3, 2018 at 8:48 AM, xxxxx@osr.commailto:xxxxx > wrote:
>How do we access a driver under UWP.

I get that getting rid of random IOCTLs and random interactions with the hardware is a specific goal, not a side-effect… but to me, if I need to ask MSFT permission for every single IOCTL I want to implement for every single customer and every single project (and that’s certainly the way I understand it’s supposed to work) this is just not going to happen.

I’d be (grudgingly) willing to jump through the hoops to use a custom capability from a UWP app if I could just generate a GUID and associate it with my Seller ID (or whatever). But asking MSFT’s blessing? If that’s really how this must work, I just don’t see it.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:>

To unsubscribe, visit the List Server section of OSR Online at http:>

— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx>

I’ve read that explanation of custom capabilities, but it seems like it’s a pretty poor fit for a pretty common case.

Let’s just take the example of software defined radios. Many SDR hardware devices have an API DLL than follows some public standard format. Win32 applications that want to process data from an SDR just have to call this API, and they work with any hardware. This means neither the hardware vendor nor the application vendor “owns” the API, it’s a defacto standard. Frequently, the SDR interface DLL uses USB endpoints internally to talk to the hardware, although they might also have a custom kernel driver that exposes IOCTls. It’s basically opaque to the application how the SDR interface works. A number of drivers I’ve written over the years for unusual hardware also had a user mode interface library, allowing the user-kernel boundary to be private.

I’d like to understand how the UWP model of things works for these kinds of scenarios? The link referenced below sure seems like it talks about the custom capability being owned by a specific company, who after receiving Microsoft’s blessing for the interface, has to grant permission to specific users (developers) of the custom capability.

This is not just how SDRs work, it’s how lots of things work, like for example the NA-VISA instrumentation interface, or the TWAIN scanner interface. The makers of the VISA instrumentation interface would almost certainly not want to expend engineering resources every time somebody wants to write a little application that uses the VISA interface. A HUGE part of Windows is based on interfacing between modules via DLLs, COM objects, and .Net objects. I also believe improving security is a really import goal, which is much of the motivation behind UWP.

If in UWP it’s impossible for different vendors to make modules that interact with each other, though high performance interfaces, many kinds of solutions will just never be UWP apps. I spent some time working on a UWP instrumentation data analysis program, and my experience was writing UWP apps was really painful when you wanted to use any previous interfaces.

Jan

From: xxxxx@lists.osr.com On Behalf Of xxxxx@microsoft.com
Sent: Tuesday, April 3, 2018 7:14 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UWP and accessing driver

You don’t want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developers.

Bent from my phone
________________________________
From: xxxxx@lists.osr.commailto:xxxxx > on behalf of xxxxx@x-publisher.commailto:xxxxx >
Sent: Tuesday, April 3, 2018 2:28:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] UWP and accessing driver

How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
Is the APi below the right one for Win10?
Device Access API
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fhh404235(v%3Dvs.85).aspx&amp;data=02|01|Doron.Holan%40microsoft.com|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&amp;sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&amp;reserved=0


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></https:></https:></https:></mailto:xxxxx></mailto:xxxxx>

It is a gap where you can?t grant access to everyone with a custom cap. We are considering addressing this in a future release.

d

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@pmatrix.com
Sent: Tuesday, April 3, 2018 3:58:10 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] UWP and accessing driver

I?ve read that explanation of custom capabilities, but it seems like it?s a pretty poor fit for a pretty common case.

Let?s just take the example of software defined radios. Many SDR hardware devices have an API DLL than follows some public standard format. Win32 applications that want to process data from an SDR just have to call this API, and they work with any hardware. This means neither the hardware vendor nor the application vendor ?owns? the API, it?s a defacto standard. Frequently, the SDR interface DLL uses USB endpoints internally to talk to the hardware, although they might also have a custom kernel driver that exposes IOCTls. It?s basically opaque to the application how the SDR interface works. A number of drivers I?ve written over the years for unusual hardware also had a user mode interface library, allowing the user-kernel boundary to be private.

I?d like to understand how the UWP model of things works for these kinds of scenarios? The link referenced below sure seems like it talks about the custom capability being owned by a specific company, who after receiving Microsoft?s blessing for the interface, has to grant permission to specific users (developers) of the custom capability.

This is not just how SDRs work, it?s how lots of things work, like for example the NA-VISA instrumentation interface, or the TWAIN scanner interface. The makers of the VISA instrumentation interface would almost certainly not want to expend engineering resources every time somebody wants to write a little application that uses the VISA interface. A HUGE part of Windows is based on interfacing between modules via DLLs, COM objects, and .Net objects. I also believe improving security is a really import goal, which is much of the motivation behind UWP.

If in UWP it?s impossible for different vendors to make modules that interact with each other, though high performance interfaces, many kinds of solutions will just never be UWP apps. I spent some time working on a UWP instrumentation data analysis program, and my experience was writing UWP apps was really painful when you wanted to use any previous interfaces.

Jan

From: xxxxx@lists.osr.com On Behalf Of xxxxx@microsoft.com
Sent: Tuesday, April 3, 2018 7:14 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UWP and accessing driver

You don?t want to use metadata or privileged apps. You want to use a custom capability and access it through Windows.devices.custom. See https://docs.microsoft.com/en-us/windows-hardware/drivers/devapps/hardware-support-app--hsa--steps-for-driver-developershttps:.

Bent from my phone
________________________________
From: xxxxx@lists.osr.commailto:xxxxx > on behalf of xxxxx@x-publisher.commailto:xxxxx >
Sent: Tuesday, April 3, 2018 2:28:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] UWP and accessing driver

How do we access a driver under UWP. I couldnt find something like DeviceIoControl under WinRT.
Is the APi below the right one for Win10?
Device Access API
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fhh404235(v%3Dvs.85).aspx&amp;data=02|01|Doron.Holan%40microsoft.com|170e888326da42488c4308d599453f48|72f988bf86f141af91ab2d7cd011db47|1|0|636583445050029660&amp;sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&amp;reserved=0


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:


NTDEV is sponsored by OSR

Visit the list online at: http:>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:>

To unsubscribe, visit the List Server section of OSR Online at http:>


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></https:></https:></https:></mailto:xxxxx></mailto:xxxxx></https:>

Need MSFT signed SCCD file for “developer mode”?

Need you resurrect thread that’s over a year old?

Peter

Same subject and some good info are in this thread.

Same subject and some good info are in this thread.

So, did you not bother to read the Community Guidelines before posting (as it asked folks to do on EVERY PAGE of this site)… or did you think that they didn’t apply to you?

Because I think the rules are pretty clear on this topic:

There are a number of other behaviors that are considered rules of “good conduct” for posting here on the forums. These include:

  1. Please do not revive “old” threads. Until we have the ability to block posts to “dead” (old, outdated) threads, we ask you to not reply to threads where the last post is more than a month old. If you have a comment/question/issue that’s raised in a “dead” thread, start a new thread (you can post a link to the old thread if you want) and ask your question there.

Soooo… ah…

Peter

ah!. will start a new thread…