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
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 and link with the SDK
header files and import libraries, not
25 matches
Mail list logo
