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

[Brad Clements]

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 at murkworks.com
Thomas S. Strinnhed <thstr at serop.abb.se> wrote in message
news:374406DC.25705256 at 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 at 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