Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

UWP and accessing driver

makrurisan_makkelnmakrurisan_makkeln Member - All Emails Posts: 99
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

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,447
    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://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v%3Dvs.85).aspx&data=02%7C01%7CDoron.Holan%40microsoft.com%7C170e888326da42488c4308d599453f48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583445050029660&sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&reserved=0


    ---
    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
    d
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467
    >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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Daniel_Kulas-2Daniel_Kulas-2 Member - All Emails Posts: 12
    "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: showlists.cfm?list=ntdev>
    >
    > 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://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467
    >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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,447
    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.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: >

    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 >

    --- 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
    d
  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 471
    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.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://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v%3Dvs.85).aspx&data=02%7C01%7CDoron.Holan%40microsoft.com%7C170e888326da42488c4308d599453f48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583445050029660&sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&reserved=0


    ---
    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

    ---
    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
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,447
    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-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://msdn.microsoft.com/en-us/library/windows/desktop/hh404235(v%3Dvs.85).aspx&data=02%7C01%7CDoron.Holan%40microsoft.com%7C170e888326da42488c4308d599453f48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583445050029660&sdata=w%2FBszI%2Fu8JKPAHJRrMKjImVqOuDVEg5Mwacs5OikNhk%3D&reserved=0


    ---
    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

    ---
    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 >

    ---
    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
    d
  • Muthu_KumarMuthu_Kumar Member Posts: 17

    Need MSFT signed SCCD file for "developer mode"?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467

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

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Muthu_KumarMuthu_Kumar Member Posts: 17

    Same subject and some good info are in this thread.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467
    edited October 26

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Muthu_KumarMuthu_Kumar Member Posts: 17

    ah!. will start a new thread...

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE