Martin v. Löwis wrote:
>>> At first glance, this is a minor issue - passing FILE* pointers
>>> across
>>> DLL boundaries isn't something I'd normally expect people to do -
>>> but
>>> look further and you find you're opening a real can of worms. For
>>> example, Python has public APIs which take F
Neil Hodgson wrote:
>I suppose the answer (hmm, am I allowed to anser my own rhtorical
> questions?) is that it was originally developed on other operating
> systems and the Windows port has never been as much of a focus for
> most contributors.
That's certainly the case. It is all Mark Hammon
Martin v. Löwis:
> > Visual Basic never forced
> > use of a particular compiler or runtime library for extensions so why
> > should Python?
>
> Do you really not know? Because of API that happens to be defined
> the way it is.
It was rhetorical: Why should Python be inferior to VB?
I suppo
Neil Hodgson wrote:
>>At first glance, this is a minor issue - passing FILE* pointers across
>>DLL boundaries isn't something I'd normally expect people to do - but
>>look further and you find you're opening a real can of worms. For
>>example, Python has public APIs which take FILE* parameters.
>
Neil Hodgson wrote:
>>If pythonxy.dll
>>was statically linked, you would get all the CRT duplication
>>already in extension modules. Given that there are APIs in Python
>>where you have to do malloc/free across the python.dll
>>boundary, you get memory leaks.
>
>
>Memory allocations across DL
Neil Hodgson wrote:
>COM was partly just a continuation of the practices used for
> controls, VBXs and other forms of extension. Visual Basic never forced
> use of a particular compiler or runtime library for extensions so why
> should Python?
Do you really not know? Because of API that happen
Paul Moore:
> This has all been thrashed out before, but the issue is passing
> CRT-allocated objects across DLL boundaries.
Yes, that was the first point I addressed through wrapping CRT objects.
> At first glance, this is a minor issue - passing FILE* pointers across
> DLL boundaries isn't
Martin v. Löwis:
> Not sure whether this was a serious suggestion.
Yes it is.
> If pythonxy.dll
> was statically linked, you would get all the CRT duplication
> already in extension modules. Given that there are APIs in Python
> where you have to do malloc/free across the python.dll
> boundar
Martin v. Löwis:
> COM really solves all problems people might have on Windows.
COM was partly just a continuation of the practices used for
controls, VBXs and other forms of extension. Visual Basic never forced
use of a particular compiler or runtime library for extensions so why
should Pytho
On 2/9/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> COM really solves all problems people might have on Windows.
Taken deliberately out of context, that sounds rather like a claim
even Microsoft itself wouldn't make. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
Neil Hodgson wrote:
>>But that won't help when you need to deal with third-party
>>code that knows nothing about Python or its wrapped file
>>objects, and calls the CRT (or one of the myriad extant
>>CRTs, chosen at random:-) directly.
>
>
>Can you explain exactly why there is a problem here?
Neil Hodgson wrote:
>The postgres example is strange to me as I'd never consider passing
> a FILE* over a DLL boundary. Maybe this is a Unix/Windows cultural
> thing due to such practices being more dangerous on Windows.
In the specific example, Postgres has a PQprint function that can
print a
On 2/9/06, Neil Hodgson <[EMAIL PROTECTED]> wrote:
> Greg Ewing:
>
> > But that won't help when you need to deal with third-party
> > code that knows nothing about Python or its wrapped file
> > objects, and calls the CRT (or one of the myriad extant
> > CRTs, chosen at random:-) directly.
>
>C
Greg Ewing:
> But that won't help when you need to deal with third-party
> code that knows nothing about Python or its wrapped file
> objects, and calls the CRT (or one of the myriad extant
> CRTs, chosen at random:-) directly.
Can you explain exactly why there is a problem here? Its fairly
no
Martin v. Löwis:
> I don't think this would be good enough. I then also need a way to
> provide extension authors with an API that looks like the CRT, but
> isn't: they cannot realistically change all their code to use the
> wrapped objects. In a recent case, somebody tried to passed a FILE*
> to
Greg Ewing wrote:
> As far as I can see, Microsoft have created an intractable
> mess here. Their solution of "compile your whole program
> with the same CRT" completely misses the possibility that
> the "whole program" may consist of disparate separately-
> written and separately-compiled parts, a
Neil Hodgson wrote:
> You don't need to drop the CRT, just encapsulate it so there is one
> copy controlled by Python that hands out wrapped objects (file
> handles, file pointers, memory blocks, others?). These wrappers can
> only be manipulated through calls back to that owning code that then
Martin v. Löwis wrote:
> I withdraw that idea. It appears that the platform SDK doesn't
> (any longer?) provide an import library for msvrt.dll, and
> Microsoft documents mscvrt as intended only for "system
> components".
Insofar as it forms a base on which other separately-
compiled pieces of co
Martin v. Löwis:
> So ideally, Python should drop usage of the CRT entirely (but getting
> there will be a long process). Hopefully, P3k will drop usage of
> stdio for file objects, which will be a big step forward.
You don't need to drop the CRT, just encapsulate it so there is one
copy contro
Martin v. Löwis wrote:
> To do that, we would need to compile and link with the SDK
> header files and import libraries, not with the ones that
> visual studio provides.
I withdraw that idea. It appears that the platform SDK doesn't
(any longer?) provide an import library for msvrt.dll, and
Micros
Giovanni Bajo wrote:
>>I just came up with an idea how to resolve the VC versioning
>>problems for good: Python should link with mscvrt.dll (which
>>is part of the operating system), not with the CRT that the
>>compiler provides.
>
>
> Can you elaborate exactly on which versioning problems you th
Thomas Heller wrote:
> I'm not sure the platform SDK include files (.H and .IDL) are really
> compatible with VC7.1. I remember that we (on our company, building C++
> software) had to 'Unregister the PSDK Directories with Visual Studio'
> (available from the start menu) before building the stuff,
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I just came up with an idea how to resolve the VC versioning
> problems for good: Python should link with mscvrt.dll (which
> is part of the operating system), not with the CRT that the
> compiler provides.
Can you elaborate exactly on which versioning
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I just came up with an idea how to resolve the VC versioning
> problems for good: Python should link with mscvrt.dll (which
> is part of the operating system), not with the CRT that the
> compiler provides.
>
> To do that, we would need to compile an
24 matches
Mail list logo
