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 FILE* parameters.
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.
Can you
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
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? Its
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/)
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
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
boundary,
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
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 DLL boundaries
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.
So
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 suppose the
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 Hammond's
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 and link
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
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,
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 think of?
I
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
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
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 code
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
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, and there
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 a
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
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,
24 matches
Mail list logo
