http://bugs.winehq.org/show_bug.cgi?id=20081 red-ray <ray(a)pobox.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |ABANDONED --- Comment #15 from red-ray <ray(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.