This is the mail archive of the
mailing list for the Cygwin project.
Attn: JonY -- Re: Bug in ddk headers when used from cygwin
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Fri, 26 Apr 2013 16:12:12 -0400
- Subject: Attn: JonY -- Re: Bug in ddk headers when used from cygwin
- References: <51625CAE dot 2030703 at cwilson dot fastmail dot fm> <20130408074801 dot GA10199 at calimero dot vinschen dot de> <51630442 dot 4080805 at cwilson dot fastmail dot fm> <20130409091609 dot GI10126 at calimero dot vinschen dot de> <51641548 dot 2060700 at cwilson dot fastmail dot fm> <20130409135842 dot GC15271 at calimero dot vinschen dot de>
Hey, JonY ---
On 4/9/2013 9:58 AM, Corinna Vinschen wrote:
On Apr 9 09:19, Charles Wilson wrote:
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.
Well, actually I don't really care one way or the other. You may want
to discuss this with JonY.
Any thoughts on this -- the idea that the cygwin (and cygwin64) package of
should be stripped of any ddk-related items, as they can't actually be
mixed with the usable-from-cygwin user mode w32 items?
Arguably this might break some things -- such as the (old version of)
csih/getVolInfo -- but they are actually already broken, with the (bug
or compile failure) just waiting to be exposed.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple