This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |