通过Windows上的ctypes将文件描述符传递给C库函数

use*_*419 6 python windows ctypes file-descriptor

我试图通过ctypes将文件描述符传递给C函数,在C函数中对fd执行写操作.在linux上它可以工作.在Windows上它没有,我不明白为什么(我没有在Windows上作为开发人员的经验)

//C func signature: 
void fun(struct bah *opaque, int fd)
Run Code Online (Sandbox Code Playgroud)

从python(细节ommited):

mylib.fun.argtypes = [POINTER(bah), c_int]
fh = open(filename,'wb')
#doesn't work on windows, works on linux/unix
mylib.fun(some_ctypes_struct, fh.fileno())
#doesn't work on windows
mylib.fun(bah_struct, ctypes.cdll.msvcrt._open(filename,_O_FLAGS_MASK, ACCMASK)
#doesn't work
mylib.fun(bah_struct, os.open(...))
Run Code Online (Sandbox Code Playgroud)

程序在write()s上死亡,失败的断言_osfile(fh)&FOPEN

cl.exe:16.00.40219.01 for x86 python 2.7.2 msc v.1500 32bit

我该怎么办呢?不,我不想将open()卸载到lib.我想以安全的方式传递已打开的文件描述符,与平台无关.


附加信息,以防万一:库是tinycdb,我将它快速移植到具有短cmake规范的窗口和几个脏补丁,以使getopt和dll导出工作.库和exe工具按预期工作(测试).tinycdb的python ctypes包装器可以按预期在linux上运行.窗户给了我眼球.他不会接受fd是一个有效的描述符,即使我在用自己的(msvcrt)_open libcall打开它之后传递它.


当然,如果我打开()/关闭()文件库中的文件但是我无法更改API,一切都有效.

jdi*_*tal 4

Windows 不像 Unix 那样使用文件描述,因此我假设文件描述符是由 C 运行时模拟的。如果您使用两个不同的 C 运行时(例如,如果您的 EXE 和 DLL 由不同的编译器编译,或者使用相同的编译器但具有不同的选项),则每个运行时将有自己的“文件描述符模拟”,您可以' t 将描述符从一个传递到另一个。