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

[Thomas S. Strinnhed]

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 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