Opening a handle to a device in Python on Windows

问题

I'm trying to use the giveio.sys driver which requires a "file" to be opened before you can access protected memory. I'm looking at a C example from WinAVR/AVRdude that uses the syntax:

 #define DRIVERNAME      "\\\\.\\giveio"
 HANDLE h = CreateFile(DRIVERNAME,
            GENERIC_READ,
            0,
            NULL,
            OPEN_EXISTING,
            FILE_ATTRIBUTE_NORMAL,
            NULL);

but this does not seem to work in Python - I just get a "The specified path is invalid" error, for both

f = os.open("\\\\.\\giveio", os.O_RDONLY)

and

f = os.open("//./giveio", os.O_RDONLY)

Why doesn't this do the same thing?

Edited to hopefully reduce confusion of ideas (thanks Will). I did verify that the device driver is running via the batch files that come with AVRdude.

Further edited to clarify SamB's bounty.

回答1:

Solution: in python you have to use win32file.CreateFile() instead of open(). Thanks everyone for telling me what I was trying to do, it helped me find the answer!

回答2:

I don't know anything about Python, but I do know a bit about drivers. You're not trying to 'open a file in kernel space' at all - you're just trying to open a handle to a device which happens to be made to look a bit like opening a file.

CreateFile is a user-mode function, and everything you're doing here is user-mode, not kernel mode.

As xenon says, your call may be failing because you haven't loaded the driver yet, or because whatever Python call you're using to do the CreateFile is not passing the write parameters in.

I've never used giveio.sys myself, but personally I would establish that it was loaded correctly by using 'C' or C++ (or some pre-written app) before I tried to get it working via Python.

回答3:

You're question is very confusing to say the least.

1> The code you pasted is using a trick to communicate with the driver using its 'DOSNAME' i.e.

\\.\DRIVERNAME

2> Have you created & loaded the 'giveio' driver ?

The reason the driver handles this calls is because of this

http://msdn.microsoft.com/en-us/library/ms806162.aspx

回答4:

It sounds to me like you're asking why os.open is not magically equal to calling CreateFile with a very specific set of parameters. Kostya's answer is practical in that it tells you that you can use the Win32 python bindings to call CreateFile which is a Win32 API, directly.

Anything other than doing direct CreateFile/readFile/writeFile IO is going to introduce another layer on top (the python file objects and their behaviours) that restricts you to the parameters that os.open supports. os.open creates a python file object, which is not exactly the same thing, and not intended to provide all of Win32 CreateFile's options.

That means, for example, that no exact analog of GENERIC_READ, or OPEN_EXISTING, or FILE_ATTRIBUTE_NORMAL are guaranteed to exist.

My best guess is that os.open is not intended to replace direct calls to CreateFile, for such odd purposes as the one you're using it for.

If you can read C, why not open up the sources for python and read the implementation of os.open. If you really must go through os.open, you're going to find out what parameters to pass to it, so that in the end, os.open's implementation (in C) calls CreateFile in Win32 API with the correct parameters above. All of that seems more like work, than just using Kostya's suggestion.

回答5:

I'm not sure if that's possible. As an alternative, you could write a C/C++ program that does all that kernel space work for you and interface with it in Python via the subprocess module or Python C/C++ bindings (and another link for that).

回答6:

There are 2 ways to do this.

The first way is using the win32 python bindings

h = win32file.CreateFile

Or using ctypes

来源：https://stackoverflow.com/questions/212715/opening-a-handle-to-a-device-in-python-on-windows

标签

python

windows

device