Are 2k/XP display drivers restricted to win32k.sys exports?

Discussion in 'Windows Vista Drivers' started by Steve Rencontre, Aug 22, 2007.

  1. I'm trying to write a display driver using the Windows 2000 model, but
    it seems that if I call any ntoskrnl.exe functions, GDI refuses to load
    my driver (and does so with the rather unhelpful statement that "It was
    written for a previous version of Windows").

    Unlike the miniport driver, where the docs explicitly say that only
    functions exported from videoprt.sys may be called, AFAICT the display
    driver docs are completely silent on the subject.

    Has anyone got chapter and verse on this before I commit to working
    around a problem which may not be what I think it is?

    Steve Rencontre, Aug 22, 2007
    1. Advertisements

  2. Only EngXxx can be called from a video driver graphics DLL.
    Maxim S. Shatskih, Aug 22, 2007
    1. Advertisements

  3. Steve Rencontre

    Tim Roberts Guest

    And that's interesting, because exactly the opposite is true. The display
    driver can only call functions from win32k.sys, and the system will refuse
    to load it if it tries. The miniport, however, is free to call whatever
    functions it wants.
    Tim Roberts, Aug 22, 2007
  4. Yes, I found this article which says the same:

    It would be nice if there was some formal statement from MS somewhere,
    but I guess display driver writing is a relatively specialist branch of
    what is a pretty specialist occupation anyway, and most of those who do
    it learned the hard way long ago :)

    Anyway, I've reworked my design to avoid needing forbidden functions,
    and all would now be well if only I could figure out why the compiler is
    linking to memcpy in ntoskrnl instead of inlining it as an intrinsic.
    But that's another matter...

    Steve Rencontre, Aug 22, 2007
  5. SR> Has anyone got chapter and verse on this before I commit to
    SR> around a problem which may not be what I think it is?

    The important thing to remember, that will help you to work out how
    you should be designing your drivers, is the history of the design of
    Windows NT. Originally, in Windows NT 3.5 and earlier, display
    drivers were loaded as DLLs in application mode, by the CSRSS
    process. Those drivers accessed the actual display adapter hardware
    by performing I/O operations, IOCTLs and so forth, on devices provided
    by the video drivers that operated in kernel mode. These I/O
    operations mediated access to the hardware, preventing unsafe
    operations and performing the necessary supervisor mode actions.
    (This is a common paradigm. The KGI project for Linux envisaged much
    the same separation.) Nowadays, in Windows NT 6, display drivers are
    loaded into kernel space and operate in kernel mode, but the design
    constraints from the original design still apply.

    The thing to remember is that *a display driver in theory isn't aware
    of whether it is loaded into application space in CSRSS or into kernel
    space*. In order for this ignorance to be possible, a display driver
    must only use the API provided to it by the Graphics Engine. It
    cannot make use of any APIs that are specific to either application
    mode or kernel mode, because it is, in theory, supposed to be agnostic
    about what space it is loaded into and where it is running.

    Furthermore, since display drivers originally ran as part of the
    server process that *served* the Win32 API, it made little sense for
    them to *call* the Win32 API. So the graphics engine provided its own
    API to do things that display driver DLL code would normally, if it
    had been running *outside* of the Win32 server process, have simply
    called Win32 API functions to perform. Display drivers didn't call
    the Win32 DeviceIOControl() function to send IOCTL requests to the
    video drivers, for example; they called EngDeviceIoControl(). The
    Eng*() API was the *only* API that display drivers could legitimately
    make use of.

    Conversely, a video driver is simply an ordinary kernel-mode device
    driver. The VideoPort*() API functions can be regarded as helper
    functions, to prevent needless duplication of code to perform certain
    things common to all video drivers. In practice, there is nothing
    stopping a video miniport driver from making direct use of kernel API
    functions, as several people have observed. However, Microsoft's
    documentation says that video miniport drivers should only call
    VideoPort*() API functions. This is not because a video miniport
    driver might (say) not be running in the kernel. It is simply to
    ensure that video miniport drivers are not coupled to any other system
    components, and thereby to ensure modularity; and to ensure that video
    miniport drivers do not accidentally provide mechanisms for subverting
    system security. (This latter isn't a purely hypothetical
    consideration. The history of graphics device drivers on various
    operating systems is replete with examples of drivers that simply hand
    over privileged mode access to applications-mode code, with no
    questions asked.)

    Of course, there are all sorts of complexities that are glossed over
    here, such as session space in the kernel and the ability for video
    drivers to be used directly by applications (via OpenGL drivers, for
    example). And there's also Windows NT 6's new display driver model.
    Ironically, it is based upon Microsoft realizing that what people had
    been saying from the start about the changes in Windows NT 4 (e.g.
    that dumping all of that code into kernel mode risked system
    stability) had been actually correct all along (despite Microsoft's
    protests to the contrary made at the time - It is interesting to
    contrast the Windows NT 4 technical articles in the MSDN Library with
    the Windows NT 6 technical articles.), and takes Windows NT back in
    the direction of the design that was employed by Windows NT 3.x,
    albeit using a more decentralized model this time around.
    J de Boyne Pollard, Aug 22, 2007
  6. [good stuff snipped]

    Many thanks for that detailed explanation. It all makes perfect sense
    /if/ you know the context, which sadly is completely lacking from the
    WDK. Although I was well aware of the shifting of graphics into the
    kernel - and the controversy that went with it - that was a l-o-n-g time
    ago and I wasn't trying to write a display driver then!

    I do think MS ought to add a line or two to the docs, but as I said in
    another post, I doubt that many people are coming to this cold. I mean,
    there's NVidia and AMD/ATI and Matrox and Via and... The list is short!

    Thanks once again,

    Steve Rencontre, Aug 23, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.