File handles across dlls


Author: 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:
Misc note, the .AddFile api also supports running compiled pyc files directly. So you don’t have to distribute source if you didn’t want to. You can compile with python -m py_compile file.py

 
Leave Comment:
Name:
Email: (not shown)
Message: (Required)
Math Question: 91 + 99 = ? followed by the letter: R 



About Me
More Blogs
Main Site
Posts: (All)
2024 ( 3 )
2023 (9)
     VB6 Virtual Files
     File handles across dlls
     python abort / script timeout
     py4vb
     VB6 Python embed w/debugger
     python embedding
     VB6 IDE Enhancements
     No Sleep
     A2W no ATL
2022 (4)
     More VB6 - C data passing
     Vb6 Asm listing
     Byte Array C to VB6
     Planet Source Code DVDs
2021 (2)
     Obscure VB
     VB6 IDE SP6
2020 ( 4 )
2019 ( 5 )
2018 ( 6 )
2017 ( 6 )
2016 ( 22 )
2015 ( 15 )
2014 ( 25 )
2013 ( 4 )
2012 ( 10 )
2011 ( 7 )
2010 ( 11 )
2009 ( 3 )