> There is at least one actual problem I came across in an application
> linked with MSVCR 8.0, loading the Python DLL linked against MSVCR
> 7.1. When running a Python file using one of the PyRun_File[1]
> functions, the passed file handle has to be created from the embedding
> application. This h
On 27 Dez., 05:49, Tim Roberts <[EMAIL PROTECTED]> wrote:
> It's true that mallocing in one CRT DLL and freeing in another can cause
> problems, but in Python, I don't think that can happen. Proper Python
> add-ins call Python APIs to create and destroy objects, so only the Python
> runtime will m
<[EMAIL PROTECTED]> wrote:
> I did, and determined that it's not possible. We would have to use
> assembly manifests, and can't, as the tool chain doesn't support them.
Ross Ridge writes:
> Your choice to use a tool chain that doesn't support side-by-side
> assemblies does not make it impossible.
On Dec 28, 2007 6:41 AM, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Ross Ridge writes:
> > As I said before, I know how futile it is to argue that Python should
> > change it's behaviour. I'm not going to waste my time telling you what
> > to do. If you really want to know how side-by-side installat
Ross Ridge wrote:
> Your choice to use a tool chain that doesn't support side-by-side
> assemblies does not make it impossible.
Christian Heimes <[EMAIL PROTECTED]> wrote:
> I'm looking forward to your contribution to solve the problem.
I find that highly unlikely. Regardless, as I said twice
Ross Ridge wrote:
>> I did, and determined that it's not possible. We would have to use
>> assembly manifests, and can't, as the tool chain doesn't support them.
>
> Your choice to use a tool chain that doesn't support side-by-side
> assemblies does not make it impossible.
I'm looking forward t
Ross Ridge writes:
> As I said before, I know how futile it is to argue that Python should
> change it's behaviour. I'm not going to waste my time telling you what
> to do. If you really want to know how side-by-side installation works,
> you can try reading the Windows SDK documentation.
<[EMAI
> As I said before, I know how futile it is to argue that Python should
> change it's behaviour. I'm not going to waste my time telling you what
> to do. If you really want to know how side-by-side installation works,
> you can try reading the Windows SDK documentation.
I did, and determined tha
Ross Ridge writes:
> No, that doesn't follow from the requirements given. The only exception
> for something that isn't a service or device driver is for backwards
> compatibility. Also, pretty much any DLL supports side-by-side
> installation.
<[EMAIL PROTECTED]> wrote:
>Hmm. How do I have to b
> No, that doesn't follow from the requirements given. The only exception
> for something that isn't a service or device driver is for backwards
> compatibility. Also, pretty much any DLL supports side-by-side
> installation.
Hmm. How do I have to build and install python25.dll exactly to make
t
<[EMAIL PROTECTED]> wrote:
> I think Python perfectly meets the specification (i.e. is designed
>for Windows XP) in this respect (*):
>- python25.dll is a shared component
>- it is not private to a single software vendor
>- it is not a control panel item
>- it is not a service or device driver
>- i
> It's one of Microsoft guidelines. The "'Designed for Microsoft Windows
> XP' Application Specification" only allows DLLs to be installed in the
> system directory if it's required for backwards compatiblity.
I guess you are referring to 2.6 here. I think Python perfectly meets
the specification
Ross Ridge writes:
> Whatever you want to call it, the Python DLL is not part of the operating
> system, it's not a driver and doesn't belong in the system directory.
<[EMAIL PROTECTED]> wrote:
>Is that just your personal opinion, or a guideline from the operating
>system vendor?
It's one of Micr
>> Instead of being upset about cutting your word (which was not my
>> intention, sorry about that), it would be nice if you could make a
>> statement concerning the problem I mentioned: Having an object being
>> created by one MSVC runtime, msvcr80.dll and passing it to another
>> one, msvcr71.dll
> Whatever you want to call it, the Python DLL is not part of the operating
> system, it's not a driver and doesn't belong in the system directory.
Is that just your personal opinion, or a guideline from the operating
system vendor?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/pyth
On 27/12/2007, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Indeed, pywin32 stops working :( I installed Python "just for me",
> > then I installed pywin32-210, and now Pythonwin.exe is not able to
> > start. So for this scenario it seems to be necessary, that the Python
> > DLL is installed
"Markus Gritsch" <[EMAIL PROTECTED]> wrote:
>
>Instead of being upset about cutting your word (which was not my
>intention, sorry about that), it would be nice if you could make a
>statement concerning the problem I mentioned: Having an object being
>created by one MSVC runtime, msvcr80.dll and pas
Chris Mellon <[EMAIL PROTECTED]> wrote:
>Python (when installed with "for everyone") is not (just) an
>application, it's a runtime.
Whatever you want to call it, the Python DLL is not part of the operating
system, it's not a driver and doesn't belong in the system directory.
> Indeed, pywin32 stops working :( I installed Python "just for me",
> then I installed pywin32-210, and now Pythonwin.exe is not able to
> start. So for this scenario it seems to be necessary, that the Python
> DLL is installed into the system32 folder.
>
> Maybe the Python installer should iss
On Dec 27, 12:30 am, "Markus Gritsch" <[EMAIL PROTECTED]> wrote:
> On 26/12/2007, Lie Ryan <[EMAIL PROTECTED]> wrote:
> > > On Dec 25, 2007 4:43 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> > > On 24/12/2007, Lie <[EMAIL PROTECTED]> wrote:
>
> > > > (good programs are not DLL implementation spec
On 26/12/2007, Lie Ryan <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 25, 2007 4:43 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> > On 24/12/2007, Lie <[EMAIL PROTECTED]> wrote:
> > >
> > > (good programs are not DLL implementation specific
> >
> > Assume an application embedding Python being compiled
On Dec 24, 2007 5:23 PM, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Chris Mellon <[EMAIL PROTECTED]> wrote:
> >What the python installer is doing is the Right Thing for making the
> >standard python dll available to third party applications.
> >Applications that want a specific version of a specific D
You have read access just not write! Because you need the DLLS in there!
On Dec 25, 2007 7:53 PM, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> * Stef Mientki (Tue, 25 Dec 2007 11:39:47 +0100)
> > Another reason "not to put the DLL in win/wys32":
> > on a lot of computers writing to win/sys32 or ev
* Stef Mientki (Tue, 25 Dec 2007 11:39:47 +0100)
> Another reason "not to put the DLL in win/wys32":
> on a lot of computers writing to win/sys32 or even the whole C-drive
> is prohibited !
No, definitely not. It's just not allowed for everyone.
Thorsten
--
http://mail.python.org/mailman/listinf
On 25/12/2007, Neil Hodgson <[EMAIL PROTECTED]> wrote:
> Markus Gritsch:
>
> > I assume that your Python applications are .py files. To be able to
> > run them it would be perfectly ok if the Python DLL would be located
> > beside the python.exe in the Python installation folder.
>
> Your Pyth
Markus Gritsch:
> I assume that your Python applications are .py files. To be able to
> run them it would be perfectly ok if the Python DLL would be located
> beside the python.exe in the Python installation folder.
Your Python application may not be being run by python.exe but as an
in-pro
Markus Gritsch wrote:
> On 25/12/2007, Tim Roberts <[EMAIL PROTECTED]> wrote:
>
>> Ross Ridge <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Chris Mellon <[EMAIL PROTECTED]> wrote:
>>>
What the python installer is doing is the Right Thing for making the
standard python dll available
On 24/12/2007, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> On 24/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> > * Markus Gritsch (Sun, 23 Dec 2007 18:28:41 +0100)
> > > On 23/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> > > > * Markus Gritsch (Sun, 23 Dec 2007 15:52:50 +0100)
> > >
Chris Mellon <[EMAIL PROTECTED]> wrote:
>What the python installer is doing is the Right Thing for making the
>standard python dll available to third party applications.
>Applications that want a specific version of a specific DLL should use
>the mechanisms available for doing so, instead of relyin
On 24/12/2007, Lie <[EMAIL PROTECTED]> wrote:
>
> (good programs are not DLL implementation specific
Assume an application embedding Python being compiled with MSVC 8.0.
It uses the runtime msvcr80.dll. If you now pass objects created in
your application to the Python interpreter which is compile
On 25/12/2007, Tim Roberts <[EMAIL PROTECTED]> wrote:
> Ross Ridge <[EMAIL PROTECTED]> wrote:
>
> >Chris Mellon <[EMAIL PROTECTED]> wrote:
> >>What the python installer is doing is the Right Thing for making the
> >>standard python dll available to third party applications.
> >>Applications that wa
Ross Ridge <[EMAIL PROTECTED]> wrote:
>Chris Mellon <[EMAIL PROTECTED]> wrote:
>>What the python installer is doing is the Right Thing for making the
>>standard python dll available to third party applications.
>>Applications that want a specific version of a specific DLL should use
>>the mechanis
Chris Mellon <[EMAIL PROTECTED]> wrote:
>What the python installer is doing is the Right Thing for making the
>standard python dll available to third party applications.
>Applications that want a specific version of a specific DLL should use
>the mechanisms available for doing so, instead of relyin
On Dec 25, 3:04 am, "Markus Gritsch" <[EMAIL PROTECTED]> wrote:
> On 24/12/2007, Chris Mellon <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 23, 2007 12:27 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> > > On 23/12/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > > Markus Gritsch wrote:
> > >
On 24/12/2007, Chris Mellon <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 12:27 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> > On 23/12/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > > Markus Gritsch wrote:
> > > > why does the Python installer on Windows put the Python DLL into the
> > >
On 24/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> * Markus Gritsch (Sun, 23 Dec 2007 18:28:41 +0100)
> > On 23/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> > > * Markus Gritsch (Sun, 23 Dec 2007 15:52:50 +0100)
> > > > why does the Python installer on Windows put the Python DLL int
On Dec 23, 2007 12:27 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote:
> On 23/12/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Markus Gritsch wrote:
> > > why does the Python installer on Windows put the Python DLL into the
> > > Windows system32 folder? Wouldn't it be more clean to place it
* Markus Gritsch (Sun, 23 Dec 2007 18:28:41 +0100)
> On 23/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> > * Markus Gritsch (Sun, 23 Dec 2007 15:52:50 +0100)
> > > why does the Python installer on Windows put the Python DLL into the
> > > Windows system32 folder?
> >
> > Are you sure it does
Markus Gritsch <[EMAIL PROTECTED]> wrote:
>... We are embedding Python into our application which
>gets compiled using MSVC 8.0. We like to link dynamically, so the
>Python interpreter is not statically linked into the program. The
>Python DLL from the Python installer in the Windows system32 fol
On 23/12/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Markus Gritsch wrote:
> > why does the Python installer on Windows put the Python DLL into the
> > Windows system32 folder? Wouldn't it be more clean to place it into
> > the Python installation folder beside the python.exe file?
>
> It'
Markus Gritsch wrote:
> why does the Python installer on Windows put the Python DLL into the
> Windows system32 folder? Wouldn't it be more clean to place it into
> the Python installation folder beside the python.exe file?
It's the easiest and best way to expose Python for 3rd party
applications
On 23/12/2007, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> * Markus Gritsch (Sun, 23 Dec 2007 15:52:50 +0100)
> > why does the Python installer on Windows put the Python DLL into the
> > Windows system32 folder?
>
> Are you sure it does?!
Yes.
Markus
--
http://mail.python.org/mailman/listinfo/py
* Markus Gritsch (Sun, 23 Dec 2007 15:52:50 +0100)
> why does the Python installer on Windows put the Python DLL into the
> Windows system32 folder?
Are you sure it does?!
Thorsten
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
why does the Python installer on Windows put the Python DLL into the
Windows system32 folder? Wouldn't it be more clean to place it into
the Python installation folder beside the python.exe file?
Kind regards,
Markus
--
http://mail.python.org/mailman/listinfo/python-list
44 matches
Mail list logo
