File handles across dllsAuthor: Dave Date: 10.07.23 - 10:12pm So i prefer to compile my C Dlls with the /MT option. This compiles all of the VC runtime functions into the dll itself. Tonight I am playing around with PyRun_SimpleFileExFlags which takes a file pointer for the file to load. (Not sure why they dont offer a version which accepts a file path but..) So I have to open the file pointer in my dll (compiled with /MT) and pass it to the python311.dll also compiled with /MT Each dll internally has its own copy of the VC runtime functions. and kaboom the standard functions of fopen and ftell etc are not compatiable and crashing. like WTF. So after hours of head scratching the only thing I could think of is to compile both with /MD where they use the external VC runtime dll. and voila it works. Some more hunting turns up this article from MS: Potential errors passing CRT objects across DLL boundaries Each copy of the CRT library has a separate and distinct state, kept in thread local storage by your app or DLL. CRT objects such as file handles, environment variables, and locales are only valid for the copy of the CRT in the app or DLL where these objects were allocated or set. When a DLL and its clients use different copies of the CRT library, you can't expect these CRT objects to be used correctly when passed across the DLL boundary. Well I am not going to leave them compiling as /MD and requiring like 6 more external dlls that have to be installed. So I guess my copy of Python311.dll is going to get a new export which takes a file path and not just a file handle. pfft Edit: So, I guess I better compile the python311.dll with /MD for compatibility reasons. I dont know all the conditions of its use or architecture in a common install. This is a delicate design for integrators though...It requires I use not only /MD on my own tools, but also I compile against the same version of Visual Studio. Luckily I am already using VS2019. I ended up adding the new export below to python311.dll for my needs. It should probably have this export anyway honestly. But I dont want to link against it directly just in case the user hasnt installed my modified dll. PyAPI_FUNC(int) __stdcall PyRun_SimpleFilePath(char* fpath) { FILE* fp = fopen(fpath, "rb"); if (fp == NULL) return 0; return PyRun_SimpleFileExFlags(fp, fpath, 1, NULL); } Maybe I should just stick to the standard export and compile my helper dll with /MD...(I already have some dll mods I cant get around though) hummm Ok..I will abide by the /MD shared runtime requirement for now. It limits the complexity I must understand for the moment. Comments: (1)On 10.08.23 - 11:07am Dave wrote:
|
About Me More Blogs Main Site
|
||||||||||||||||||||||||||||||||