Mailing List Archive: PyRun_xxFile needs PyOpen_File, was Re: The Very High Layer and friends

I was going to post something about this today anyway. I'm calling
Python15.dll from a C++Builder application. Hence Borland's concept of FILE
* is NOT the same is python15.dll's concept.

It's always a "BAD" thing to pass dynamically allocated objects between
application and DLL unless they're guaranteed to be using the same compiler
and RTL, or unless their opaque objects "on the other side".

I think the best solution to this problem is to add some new calls to
python15.dll, such as:

FILE *PyOpen_File(char *path) - returns a file pointer opened by
python15.dll
int PyClose_File(FILE *) - closes same
int PyGetErrno() - for when PyOpen_File fails, msc's errno isn't the same
as borland's.

Perhaps also we need

PyMem_Alloc(int size) - use python15.dll memory allocation
PyMem_Free(int size) - "" """

For example, if I allocate memory in my .exe, and somehow expect python to
free it, that will cause a problem.

Comments?

--
Brad Clements,
bkc@murkworks.com
Thomas S. Strinnhed <thstr@serop.abb.se> wrote in message
news:374406DC.25705256@serop.abb.se...
> Thank you, makes sense.
>
> But how do I solve it? Can't really figure out from your reply if
> the problem lies in python15.dll or elsewhere. Can it be "tracked"
> in runtime?
>
> Regards
> -- Thomas S. Strinnhed, thstr@serop.abb.se
>
> Gordon McMillan wrote:
> >
> > The most likely cause is mismatching c runtime libs. The stock
> > python15.dll uses "Multithreaded DLL". You're using the right kind of
> > FILE, but you've opened it in one c runtime lib, and the other ends
> > up with a bad pointer.
> >
> > - Gordon

Hi

I'd love this if the calls were implemented, but hacking into
Python myself frightens me. As a "not so experienced programmer"
it becomes to big for me. Is there really no other way??

-- Thomas

Brad Clements wrote:
>
> I was going to post something about this today anyway. I'm calling
> Python15.dll from a C++Builder application. Hence Borland's concept of FILE
> * is NOT the same is python15.dll's concept.
>
> It's always a "BAD" thing to pass dynamically allocated objects between
> application and DLL unless they're guaranteed to be using the same compiler
> and RTL, or unless their opaque objects "on the other side".
>
> I think the best solution to this problem is to add some new calls to
> python15.dll, such as:
>
> FILE *PyOpen_File(char *path) - returns a file pointer opened by
> python15.dll
> int PyClose_File(FILE *) - closes same
> int PyGetErrno() - for when PyOpen_File fails, msc's errno isn't the same
> as borland's.
>
> Perhaps also we need
>
> PyMem_Alloc(int size) - use python15.dll memory allocation
> PyMem_Free(int size) - "" """
>
> For example, if I allocate memory in my .exe, and somehow expect python to
> free it, that will cause a problem.
>
> Comments?
>
> --
> Brad Clements,
> bkc@murkworks.com
> Thomas S. Strinnhed <thstr@serop.abb.se> wrote in message
> news:374406DC.25705256@serop.abb.se...
> > Thank you, makes sense.
> >
> > But how do I solve it? Can't really figure out from your reply if
> > the problem lies in python15.dll or elsewhere. Can it be "tracked"
> > in runtime?
> >
> > Regards
> > -- Thomas S. Strinnhed, thstr@serop.abb.se
> >
> > Gordon McMillan wrote:
> > >
> > > The most likely cause is mismatching c runtime libs. The stock
> > > python15.dll uses "Multithreaded DLL". You're using the right kind of
> > > FILE, but you've opened it in one c runtime lib, and the other ends
> > > up with a bad pointer.
> > >
> > > - Gordon