Re: Bug in ddk headers when used from cygwin

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 4/9/2013 5:16 AM, Corinna Vinschen wrote:
> On Apr  8 13:54, Charles Wilson wrote:
> > But doesn't this mean that the cygwin's w32api package should
> > exclude all of the ddk headers; it's not simply a case that you
> > "shouldn't" use ddk/*.h, but that you actually cannot, because
> > compilation will fail.
>
> The absence of intrin.h was a bug, but otherwise you could still use
> the ddk headers for what they are supposed to be:  Writing device
> drives and other kernel stuff.  The difference is just that the ddk
> headers from mingw-w64 cannot be used together with the user space
> headers like windows.h, but that's not different from "upstream".

...but is it reasonable to create a *cygwin* device driver or kernel 
mode item?  If you're using the cygwin compiler, then you're linking 
against the cygwin dll -- which makes a bunch of usermode w32 calls 
under the hood.  If it's bad juju to mix ddk/ kernel mode stuff with 
w32api/ user mode stuff, then any "cygwin" device driver is, by 
definition, bad juju.

If I'm correct, then the *cygwin* w32api-headers package (and 
cygwin64-w32api-headers) should exclude ddk/ from their deliverable 
footprint, even if intrin.h is added back to the toplevel w32api/ 
include directory for other reasons. Of course mingw64-x86_64-headers 
and mingw64-i686-headers need to retain the ddk/ headers, for precisely 
the reason you indicate, and those two already provide the toplevel 
intrin.h file.

--
Chuck



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple