Does anyone have any recommendations on which version of the MSVC?90.DLL's need to be distributed with a Python 2.6.4 PY2EXE (0.6.9) based executable? (I assume I need just a matching pair of MSVCR90.DLL and MSVCP90.DLL?)
My understanding is that I need to match the version of the DLL's that my version of Python 2.6.4 was compiled against?
On my Windows 7 Professional (64-bit) workstation, I have the following sets of MSVC?9.DLL files to choose from.
<pyt...@bdurham.com> wrote: >Does anyone have any recommendations on which version of the >MSVC?90.DLL's need to be distributed with a Python 2.6.4 PY2EXE (0.6.9) >based executable? (I assume I need just a matching pair of MSVCR90.DLL >and MSVCP90.DLL?)
Either the one the came with your copy Microsoft Visual C++ or Python 2.6.4. Otherwise, you don't have the legal right to redistribute Microsoft's code.
> <pyt...@bdurham.com> wrote: > >Does anyone have any recommendations on which version of the > >MSVC?90.DLL's need to be distributed with a Python 2.6.4 PY2EXE (0.6.9) > >based executable? (I assume I need just a matching pair of MSVCR90.DLL > >and MSVCP90.DLL?)
> Either the one the came with your copy Microsoft Visual C++ or Python > 2.6.4. Otherwise, you don't have the legal right to redistribute > Microsoft's code.
Hi. I clearly haven't yet quite understood this very well.
Only this week I sent a py2exe-derived executable to someone else (a non-developer) and it would not run on their WinXP machine ("'The system cannot execute the specified program'") - my current favourite hypothesis is that my omission of this dll or something similar was to blame.
To diagnose what's wrong, I can't get access to the machine that gives the above error. To try and reproduce, I'm right now in the process of creating a bare-bones WindowsXP installed on a VM.
My questions are, sadly, legion:
1) I don't understand why the OP's question doesn't deserve a literal answer - isn't one of those DLLs in the WinSxS directory derived from his MSVC install? In which case does he have the rights to redistribute it?
Ross said:
> Either the one the came with your copy Microsoft Visual C++ or Python 2.6.4.
2) The required dlls come with Python? Whatwhatwhat? Is this if I download Python source to compile myself?
2b) Presumably these runtimes must come with Visual Studio express edition (the free one.) I assume I can just prise the required DLL off my filesystem after MSVS express edition has installed, rather than insisting that my users run the MSVC runtime installer at
3) The wxpython site describes that I have to use a manifest file as well as the DLLs, although I find no mention of the word 'manifest' on www.py2exe.org, excepting a vaguely worded news item. Other sites (eg. StackOverflow) report conflicting ideas of whether and when this manifest file is needed. Is there a simple answer to whether this is required?
4) The py2exe wiki says, of the msvc runtime dll version 7.1 (for versions of Python prior to 2.6) that:
"Since most Windows installations nowadays include this DLL by default, it may be unnecessary."
To what extent is this true? Does the same not also apply to the msvc runtime 9.0 dll? (for Python 2.6.4)
Malcome said:
> (I assume I need just a matching pair of MSVCR90.DLL and MSVCP90.DLL?)
5) Whatwhatwhat again? More than one DLL is required? Are there ever any more than these two?
Sorry to be dense. Terse links to useful sources of information appreciated. I've read the whole py2exe wiki and been googling the last hour.
Jonathan Hartley wrote: > Only this week I sent a py2exe-derived executable to someone else (a > non-developer) and it would not run on their WinXP machine ("'The > system cannot execute the specified program'") - my current favourite > hypothesis is that my omission of this dll or something similar was to > blame.
> To diagnose what's wrong, I can't get access to the machine that gives > the above error. To try and reproduce, I'm right now in the process of > creating a bare-bones WindowsXP installed on a VM.
MSVCR90 is a side-by-side assembly (SxS). You can't just copy a SxS assembly to another computer. You must at least ship the manifest file, too. The easiest way to get your program running is the installation of the MSVCR redistributable installer.
>1) I don't understand why the OP's question doesn't deserve a literal >answer ...
I gave what I thought was a simple, direct and literal answer.
>.. isn't one of those DLLs in the WinSxS directory derived from >his MSVC install?
I have no idea. He might not even have Microsoft Visual C++ installed on his machine.
>2) The required dlls come with Python? Whatwhatwhat?
The DLLs are required for Python to work, so yes the DLLs are included in the official binary Python distribution for Windows.
> Is this if I download Python source to compile myself?
No, the DLLs aren't included in the source distribution. However, if you compile the Python source yourself with a suitably licenced copy of Microsoft Visual C++ then you'd be allowed to redistribute the Microsoft Runtime DLLs as a part of your own binary Python distribution.
>2b) Presumably these runtimes must come with Visual Studio express >edition (the free one.)
I'd assume so, but you should check the the terms of the EULA for that particular product to make sure it also allows you to redistribute the runtime DLLs.
> I assume I can just prise the required DLL off my filesystem after >MSVS express edition has installed, rather than insisting that my users >run the MSVC runtime installer at
It would problably simpler to use the DLL included in the "redist" subdirectory of Microsoft Visual C++ installation. That is, assumming there is one, again you'll need to check the EULA. Sometimes Microsoft makes specific requirements on how its redistributables are packaged and installed, and that definately seems to be the case with Visual C++ 2008.
>4) The py2exe wiki says, of the msvc runtime dll version 7.1 (for >versions of Python prior to 2.6) that:
> "Since most Windows installations nowadays include this DLL by >default, it may be unnecessary."
>To what extent is this true?
It's less true for newer versions of Windows. I know there are a fair number of people running Windows Vista and Windows 7 who've run into problems with my own py2exe wrapped program because their machines don't already have MSVCR71.DLL installed in their system directories.
>Does the same not also apply to the msvc >runtime 9.0 dll? (for Python 2.6.4)
I'd assume the problem would be even worse. I don't think Microsoft allows the 9.0 runtime to be installed in system directory, so the specific version of the runtime would need to be already installed the WinSxS directory.
>Malcome said: >> (I assume I need just a matching pair of MSVCR90.DLL and MSVCP90.DLL?)
>5) Whatwhatwhat again? More than one DLL is required? Are there ever >any more than these two?
The "P" DLL is for C++ and so the original poster may not actually need it. I'm pretty sure Python itself doesn't need it, and py2exe shouldn't either, but wxPython, or more precisely wxWidgets, almost certainly does. So in your case you'll probably need to redistribute both DLLs.
> The "P" DLL is for C++ and so the original poster may not actually need > it. I'm pretty sure Python itself doesn't need it, and py2exe shouldn't > either, but wxPython, or more precisely wxWidgets, almost certainly does. > So in your case you'll probably need to redistribute both DLLs.
FYI, my experience is that an entire manifest must be distributed. As the manifest in question actually lists 3 DLLs, IIUC, you must ship all 4 files - the 3 DLLs and the manifest, even if only one of the DLLs is actually used.
This is from memory some time back though, so apologies in advance if I'm mis-remembering.
> Jonathan Hartley wrote: > > Only this week I sent a py2exe-derived executable to someone else (a > > non-developer) and it would not run on their WinXP machine ("'The > > system cannot execute the specified program'") - my current favourite > > hypothesis is that my omission of this dll or something similar was to > > blame.
> > To diagnose what's wrong, I can't get access to the machine that gives > > the above error. To try and reproduce, I'm right now in the process of > > creating a bare-bones WindowsXP installed on a VM.
> MSVCR90 is a side-by-side assembly (SxS). You can't just copy a SxS > assembly to another computer. You must at least ship the manifest file, > too. The easiest way to get your program running is the installation of > the MSVCR redistributable installer.
> Christian
Hey Christian,
Many thanks for that, but my issue is that my programs work fine for me on my computer - but then fail on other people's computers. I'd very strongly prefer for my users to not have to install the MSVCR redistributable installer as well as my program - it would be much better if I could bundle everything up into my py2exe package so that it 'just works' on any Windows computer. So I think that means I'm looking for a stand-alone DLL (or several, plus the manifest file, it sounds like) to bundle up with my py2exe.
> > The "P" DLL is for C++ and so the original poster may not actually need > > it. I'm pretty sure Python itself doesn't need it, and py2exe shouldn't > > either, but wxPython, or more precisely wxWidgets, almost certainly does. > > So in your case you'll probably need to redistribute both DLLs.
> FYI, my experience is that an entire manifest must be distributed. As > the manifest in question actually lists 3 DLLs, IIUC, you must ship all > 4 files - the 3 DLLs and the manifest, even if only one of the DLLs is > actually used.
> This is from memory some time back though, so apologies in advance if > I'm mis-remembering.
> Mark
Thanks to everyone who replied, especially Ross obviously for such comprehensive info.
I'll go percolate on what you wrote, and try some experiments on my new VM, see if it all makes sense for me when I put it into practice.
>Many thanks for that, but my issue is that my programs work fine for >me on my computer - but then fail on other people's computers. I'd >very strongly prefer for my users to not have to install the MSVCR >redistributable installer as well as my program - it would be much >better if I could bundle everything up into my py2exe package so that >it 'just works' on any Windows computer. So I think that means I'm >looking for a stand-alone DLL (or several, plus the manifest file, it >sounds like) to bundle up with my py2exe.
Microsoft's documentation describes several possible ways you can redistribute the Visual C++ runtime:
> >Many thanks for that, but my issue is that my programs work fine for > >me on my computer - but then fail on other people's computers. I'd > >very strongly prefer for my users to not have to install the MSVCR > >redistributable installer as well as my program - it would be much > >better if I could bundle everything up into my py2exe package so that > >it 'just works' on any Windows computer. So I think that means I'm > >looking for a stand-alone DLL (or several, plus the manifest file, it > >sounds like) to bundle up with my py2exe.
> Microsoft's documentation describes several possible ways you can > redistribute the Visual C++ runtime:
Am I right to infer that if I want to distribute a py2exe'd application legally, and have half a chance of it working on a non- developer's machine, then I have to:
a) Ask my users to run the Visual C++ redistributable installer, as well as download my program. This is really unfortunate, since one of the major disadvantages of coding something in Python as opposed to as a web application is the overhead of asking users to download and execute anything at all. Asking them to do it twice seems problematic. Most users would regard this as a deal-breaking hurdle, do you think?
or
b) Buy a copy of Visual Studio in order to acquire the rights to distribute msvcr.dll (etc.) along with my application.
This is kind of a shame, because it rules out the most obvious and desirable solution, which would be to distribute the DLLs which are required to give my Python application half a chance of running on my target user's PC's, without having to buy Visual Studio.
>Am I right to infer that if I want to distribute a py2exe'd >application legally, and have half a chance of it working on a non- >developer's machine, then I have to:
>a) Ask my users to run the Visual C++ redistributable installer, as >well as download my program. This is really unfortunate, since one of >the major disadvantages of coding something in Python as opposed to as >a web application is the overhead of asking users to download and >execute anything at all. Asking them to do it twice seems problematic. >Most users would regard this as a deal-breaking hurdle, do you think?
>or
>b) Buy a copy of Visual Studio in order to acquire the rights to >distribute msvcr.dll (etc.) along with my application.
If your users are paying to download your program then spending $1000 or whatever it is to buy Visual C++ doesn't seem to be unreasonable expense to make sure you're staying well within the right side of the law. If you're giving it away for free, or aren't expecting to make enough money to make spending $1000 worthwhile, then asking them to download something sepeately doesn't seem to be unreasonable either. I give my py2exe wrapped application for free so I'm not losing sleep just because a few people can't run it because they don't have 7.1 runtime already installed.
That said, you might have couple of other options. Microsoft's documentation says that with the Express edition, "it is recommended to redistribute Visual C++ libraries using the Visual C++ Redistributable Package." That suggests that you can redistribute the package with your application and have your installer run it automatically. My older copy of the Windows SDK includes the Visual C++ 2005 compilers with the C/C++ runtime merge modules, so lastest version of the SDK might include 2008 merge modules.
Whatever you do, make sure you install the runtime correctly. Part of the reason for the restrictions on redistributing the runtime is so people don't just bindly copy DLLs around. That leads to older DLLs overriding newer DLLs and makes it difficult for Micrsoft to make security fixes. In particular they don't want a repeat of the GDI+ fiasco, where a buffer overrun of the image processing routines resulted security vulnerabilities in a lot of third party applications that couldn't be easily fixed by deploying a patched DLL with Windows Update.
> >Am I right to infer that if I want to distribute a py2exe'd > >application legally, and have half a chance of it working on a non- > >developer's machine, then I have to:
> >a) Ask my users to run the Visual C++ redistributable installer, as > >well as download my program. This is really unfortunate, since one of > >the major disadvantages of coding something in Python as opposed to as > >a web application is the overhead of asking users to download and > >execute anything at all. Asking them to do it twice seems problematic. > >Most users would regard this as a deal-breaking hurdle, do you think?
> >or
> >b) Buy a copy of Visual Studio in order to acquire the rights to > >distribute msvcr.dll (etc.) along with my application.
> If your users are paying to download your program then spending $1000 or > whatever it is to buy Visual C++ doesn't seem to be unreasonable expense > to make sure you're staying well within the right side of the law. > If you're giving it away for free, or aren't expecting to make enough > money to make spending $1000 worthwhile, then asking them to download > something sepeately doesn't seem to be unreasonable either. I give > my py2exe wrapped application for free so I'm not losing sleep just > because a few people can't run it because they don't have 7.1 runtime > already installed.
> That said, you might have couple of other options. Microsoft's > documentation says that with the Express edition, "it is recommended to > redistribute Visual C++ libraries using the Visual C++ Redistributable > Package." That suggests that you can redistribute the package with your > application and have your installer run it automatically. My older copy > of the Windows SDK includes the Visual C++ 2005 compilers with the C/C++ > runtime merge modules, so lastest version of the SDK might include 2008 > merge modules.
> Whatever you do, make sure you install the runtime correctly. Part of > the reason for the restrictions on redistributing the runtime is so people > don't just bindly copy DLLs around. That leads to older DLLs overriding > newer DLLs and makes it difficult for Micrsoft to make security fixes. > In particular they don't want a repeat of the GDI+ fiasco, where a buffer > overrun of the image processing routines resulted security vulnerabilities > in a lot of third party applications that couldn't be easily fixed by > deploying a patched DLL with Windows Update.
1) Writing some games, which for the moment are free download, and hence have a high elasticity of demand. If I make the install fiddly, a lot of people won't bother.
2) About once a week the last couple of months I've had a friend phone to say 'can you write me a simple program to do X', where X is stuff like calling a web API to look up info for every postcode/zipcode in a database. This sort of thing is ideally suited to Python, but then when I come to send the program to my friend, it never works. These are non-technical users, so I'd rather send them a single executable that 'just works', rather than asking them to install Python and then coach them through running a script - they would HATE that as a solution.
In each case, at the moment, I don't even have an installer. If I have to create one just for tiny 50 line applications like case (2), then that seems a large and cumbersome hurdle, unless the process can be automated for future projects.
I feel like it would be a huge increase in Python's viability, usefulness and desirability if we could improve this situation.
Best regards, many thanks to everyone who has contributed to my understanding on this thread.
Jonathan Hartley <tart...@tartley.com> writes: > 2) About once a week the last couple of months I've had a friend phone > to say 'can you write me a simple program to do X', where X is stuff > like calling a web API to look up info for every postcode/zipcode in a > database. This sort of thing is ideally suited to Python, but then
ask 50 USD/program and after 20 times you can buy VC (if the quoted price of 1000 USD is correct).
In the past I helped people for free on/via Usenet with Perl programming issues (via as in: they emailed me because of something I posted on Usenet). Ditto for people who emailed me for help after a visit to my site. The past 1.5 year or so I ask book(s)[1] in return for such help, and now I have to make a bookcase soon :-)
> when I come to send the program to my friend, it never works. These > are non-technical users, so I'd rather send them a single executable > that 'just works', rather than asking them to install Python and then > coach them through running a script - they would HATE that as a > solution.
So you provide a very good solution to them, and hence they shouldn't have any problem with paying for such a service.
[1] really small stuff is 15 USD in books but everything above that is multiples of 35 USD/books. It's a nice way to create a library of technical books that way, while leaving plenty of room for books for leisure.
> FYI, my experience is that an entire manifest must be distributed. As > the manifest in question actually lists 3 DLLs, IIUC, you must ship all > 4 files - the 3 DLLs and the manifest, even if only one of the DLLs is > actually used.
You don't actually need to include all three DLLs. Just including the C runtime is fine, even though the others are also mentioned in the manifest.
> Does anyone have any recommendations on which version of the > MSVC?90.DLL's need to be distributed with a Python 2.6.4 PY2EXE (0.6.9) > based executable?
You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
> You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
Thank you for your answers. From my research and testing on this topic:
1. Can I safely place these 2 files in the same folder as my Py2exe generated EXE file or do I need to place the MSVCR90.DLL file in a specially named sub-folder?
2. Do I need to rename the Microsoft.VC90.CRT.manifest file to myapp.exe.manifest or can I leave it named as is?
3. Do I need to customize the contents of the Microsoft.VC90.CRT.manifest file for my EXE?
I've been experimenting with different answers to the above questions and multiple approaches seems to work. I suspect this is because all the workstations I have access to for testing already have the full set of MSVC*90.DLL's installed - and not because my multiple tests really work.
> Thank you for your answers. From my research and testing on this topic:
Unfortunately, I can't answer these questions for py2exe. In principle, it would hope that it is possible to include the DLLs *in* the executable, if the py2exe mode is used where it includes all DLLs.
> > You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
> Thank you for your answers. From my research and testing on this topic:
> 1. Can I safely place these 2 files in the same folder as my Py2exe > generated EXE file or do I need to place the MSVCR90.DLL file in a > specially named sub-folder?
> 2. Do I need to rename the Microsoft.VC90.CRT.manifest file to > myapp.exe.manifest or can I leave it named as is?
> 3. Do I need to customize the contents of the > Microsoft.VC90.CRT.manifest file for my EXE?
> I've been experimenting with different answers to the above questions > and multiple approaches seems to work. I suspect this is because all the > workstations I have access to for testing already have the full set of > MSVC*90.DLL's installed - and not because my multiple tests really work.
> Thanks so much for your help!
> Malcolm
I just created a VM containing a bare-bones install of Windows XP, precisely so that I can reproduce the errors my users see when MSVCR90.DLL is not installed.
It sounds like the wisest course of action is for me to use vcredist_x86.exe to install the required MSVC runtime on the user's machine (as opposed to trying to distribute MSVCR90.DLL with my application.) I can be sure that I have rights to distribute this, and I don't have to understand side-by-side DLL installation, and I'm delegating any tricky decisions to Microsoft, who are presumably best qualified to judge things like: what to do if other versions of the DLLs are already installed; how to register them to be shared between multiple applications; whether to update them if Windows Update decrees it, etc)
I'm going to try to run vcredist_x86.exe automatically (as opposed to asking my users to download and run it manually). I don't currently have any installer, so I'm going to run vcredist_x86.exe on my application start-up. Some logic like this seems to do this trick:
if platform.system() == 'Windows': command = [path.join('lib', 'vcredist_x86.exe'), '/q'] retcode = subprocess.call(command) if retcode != 0: sys.stderr.write( 'Return value %d from vcredist_x86.exe\n' % (retcode,))
This seems to work. My py2exe program will now run out of the box on a bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu' will uninstall the DLLs again)
However, this takes a few seconds to run. Is there a sensible way for me to only run this if the required DLL is not already installed? How should I be detecting that?
Also: Will this work on 64 bit machines? Or do I not need to worry about that?
> > > You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
> > Thank you for your answers. From my research and testing on this topic:
> > 1. Can I safely place these 2 files in the same folder as my Py2exe > > generated EXE file or do I need to place the MSVCR90.DLL file in a > > specially named sub-folder?
> > 2. Do I need to rename the Microsoft.VC90.CRT.manifest file to > > myapp.exe.manifest or can I leave it named as is?
> > 3. Do I need to customize the contents of the > > Microsoft.VC90.CRT.manifest file for my EXE?
> > I've been experimenting with different answers to the above questions > > and multiple approaches seems to work. I suspect this is because all the > > workstations I have access to for testing already have the full set of > > MSVC*90.DLL's installed - and not because my multiple tests really work.
> > Thanks so much for your help!
> > Malcolm
> I just created a VM containing a bare-bones install of Windows XP, > precisely so that I can reproduce the errors my users see when > MSVCR90.DLL is not installed.
> It sounds like the wisest course of action is for me to use > vcredist_x86.exe to install the required MSVC runtime on the user's > machine (as opposed to trying to distribute MSVCR90.DLL with my > application.) I can be sure that I have rights to distribute this, and > I don't have to understand side-by-side DLL installation, and I'm > delegating any tricky decisions to Microsoft, who are presumably best > qualified to judge things like: what to do if other versions of the > DLLs are already installed; how to register them to be shared between > multiple applications; whether to update them if Windows Update > decrees it, etc)
> I'm going to try to run vcredist_x86.exe automatically (as opposed to > asking my users to download and run it manually). I don't currently > have any installer, so I'm going to run vcredist_x86.exe on my > application start-up. Some logic like this seems to do this trick:
> if platform.system() == 'Windows': > command = [path.join('lib', 'vcredist_x86.exe'), '/q'] > retcode = subprocess.call(command) > if retcode != 0: > sys.stderr.write( > 'Return value %d from vcredist_x86.exe\n' % > (retcode,))
> This seems to work. My py2exe program will now run out of the box on a > bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu' > will uninstall the DLLs again)
> However, this takes a few seconds to run. Is there a sensible way for > me to only run this if the required DLL is not already installed? How > should I be detecting that?
> Also: Will this work on 64 bit machines? Or do I not need to worry > about that?
I was fooling myself with sloppy testing, this doesn't work at all. Obviously enough.
If the DLLs aren't installed, then my program can't be launched, and can't bootstrap itself by installing the required DLL's.
>> However, this takes a few seconds to run. Is there a sensible way for >> me to only run this if the required DLL is not already installed? How >> should I be detecting that?
Look at windows\winsxs\<crt folder>
>> Also: Will this work on 64 bit machines? Or do I not need to worry >> about that?
If you ship the 32-bit Python DLLs, and have a 32-bit installer, and install the 32-bit redist, it will work fine on a 64-bit machine as well.
If one of the components above is 64-bit, all of them will need to be 64-bit.
> If the DLLs aren't installed, then my program can't be launched, and > can't bootstrap itself by installing the required DLL's.
> I guess I really need an installer. Oh well.
You can perhaps modify the py2exe launcher to install vc_redist if needed.
<snipped> I'm going to try to run vcredist_x86.exe automatically (as opposed to asking my users to download and run it manually). I don't currently have any installer, so I'm going to run vcredist_x86.exe on my application start-up. Some logic like this seems to do this trick:
if platform.system() == 'Windows': command = [path.join('lib', 'vcredist_x86.exe'), '/q'] retcode = subprocess.call(command) if retcode != 0: sys.stderr.write( 'Return value %d from vcredist_x86.exe\n' % (retcode,))
This seems to work. My py2exe program will now run out of the box on a bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu' will uninstall the DLLs again) </snipped>
I'm surprised that this technique works because the Python interpreter itself needs to find the MSVC*90.DLL files before it can startup and run your program that installs the MSVC*90.DLL files. Sort of a chicken and egg scenario.
> <snipped> > I'm going to try to run vcredist_x86.exe automatically (as opposed to > asking my users to download and run it manually). I don't currently > have any installer, so I'm going to run vcredist_x86.exe on my > application start-up. Some logic like this seems to do this trick:
> if platform.system() == 'Windows': > command = [path.join('lib', 'vcredist_x86.exe'), '/q'] > retcode = subprocess.call(command) > if retcode != 0: > sys.stderr.write( > 'Return value %d from vcredist_x86.exe\n' % > (retcode,))
> This seems to work. My py2exe program will now run out of the box on a > bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu' > will uninstall the DLLs again) > </snipped>
> I'm surprised that this technique works because the Python interpreter > itself needs to find the MSVC*90.DLL files before it can startup and run > your program that installs the MSVC*90.DLL files. Sort of a chicken and > egg scenario.
> Malcolm
Yeah, I was still clearly a little fuzzy-headed from Christmas when I even thought to try that. It only appeared to work, I was trying it on another machine (not my bare-bones VM) and evidently the required msvcr90.dll was already installed elsewhere on that machine.
I'm just going to give in and stick the manifest and dll directly in with my application as described by others earlier, from the cheapest copy of Visual Studio I can lay my hands on.
Thanks to everyone for their help on this, it's been plaguing me for ages.
Jonathan Hartley Made of meat. http://tartley.com tart...@tartley.com +44 7737 062 225 twitter/skype: tartley
Jonathan Hartley <tart...@tartley.com> writes: > I guess I really need an installer. Oh well.
This need not be that much of a hurdle. Several solutions exist such as Inno Setup (my personal preference), NSIS, etc... which are not hard to create a solid installer with. I suspect your end users will appreciate it too since your application (even if trivial) will install/uninstall just like other standard applications. Combining py2exe with such an installer is a solid combination for deployment under Windows.
It could also help you over time since you'll have better control if needed over how future versions handle updates, can control menus, shortcuts, etc.. Even if a start menu shortcut just opens up a console window with your text based application, it's probably easier for users then telling them to open such a window manually, switch to the right directory, and start your script.
You can arrange to have the redist installer run from within your installation script, so it's a one-time hit rather than each time your application starts.
I tried on a fresh XP on VM. I moved all dlls in C:\WINDOWS\WinSxS which are in the file handles shown by Process Explorer including the 3 CRT dlls to the my dist folder and the two subfolders suggested by http://wiki.wxpython.org/py2exe. It didn't work out. My app couldn't start. Windows XP gave a cryptic error asking me to reinstall the app.
After installing vcredist_x86.exe, my app starts fine. There isn't a choice here. You HAVE TO bundle vcredist_x86.exe with your installer and convince your customers that it is necessary to increase the file size by 2MB.
If anyone figure out how to do as http://wiki.wxpython.org/py2exe, or on a Python compiled with a free GNU compiler, avoiding all these BS. I will pay him/her $10.
On Dec 30, 10:05 am, kakarukeys <kakaruk...@gmail.com> wrote:
> I tried on a fresh XP on VM. I moved all dlls in C:\WINDOWS\WinSxS > which are in the file handles shown by Process Explorer including the > 3 CRT dlls to the my dist folder and the two subfolders suggested byhttp://wiki.wxpython.org/py2exe. It didn't work out. My app couldn't > start. Windows XP gave a cryptic error asking me to reinstall the app.
> After installing vcredist_x86.exe, my app starts fine. There isn't a > choice here. You HAVE TO bundle vcredist_x86.exe with your installer > and convince your customers that it is necessary to increase the file > size by 2MB.
> If anyone figure out how to do ashttp://wiki.wxpython.org/py2exe, or > on a Python compiled with a free GNU compiler, avoiding all these BS. > I will pay him/her $10.
I have a method that does not involve installing the runtime and still works on a "virgin" machine.
The target machines are locked desktops and installing anything on them equals to a 2 month long approval process. "The Preventer of IT" strikes again :)
But anyway, the method involves editing python26.dll in order to remove dependency references and then dropping msvcr90.dll in the same directory as the py2exe produced executable. Here is dir /b:
lib/ msvcr90.dll python26.dll <-- tweaked UI.exe
The method works with a program using wxPython.
I have used Resource Hacker http://www.angusj.com/resourcehacker/ for actual editing. You have to find <dependency> section of the manifest and remove everything between <dependentAssembly> tags
