http://bugs.winehq.org/show_bug.cgi?id=20081
red-ray ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |ABANDONED
--- Comment #15 from red-ray ray@pobox.co.uk 2009-09-20 02:26:04 --- (In reply to comment #12) Thank you for your reply, it's good to actually get a comment that makes sense ! I suspected that different Wine hosts may have different mknod command line requirements and hoped that by using the mknod() function this would be reduced. What I am actually doing is reading MSRs with on Windows I do by calling my Kernel Driver which does an RDMSR instruction. With Wine I can not do this as Wine does not run my driver in Kernel mode and therefore RDMSR can not be used. I could argue that as I can do this on Windows then I should be able to do the same with Wine, but I realise this is never going to possible with Wine, so I needed to find another way.
I found on Linux I could do this my reading the type 202 devices, so this is what I do, but these devices need to be created which is why I need to use mknod. As you have pointed out I am going to have to do different things on different Wine hosts which is something I expected and internally my code is designed to make doing this easy and also to allow for not being able to read MSRs at all.
When I initially put in the request I felt it was a trivial addition to Wine and could bee no good reason what it would be rejected and I still feel this is the case. Further, as far as I know, i few Wine functions work of some hosts and not others already.
Given the hostile response this request has received I am totally losing interest in improving Wine, so will probably simply create a whinelib dll that exports the native functions I wish to use.