Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
pyt...@bdurham.com
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.
Directory of C:\Program Files\Sony\VAIO Care
07/14/2009 01:18 PM 245,248 msvcm90.dll
07/14/2009 01:18 PM 851,456 msvcp90.dll
07/14/2009 01:18 PM 627,200 msvcr90.dll
3 File(s) 1,723,904 bytes
Directory of C:\Program Files\Sony\VAIO
Care\plugins\Microsoft.VC90.CRT
07/14/2009 01:18 PM 245,248 msvcm90.dll
07/14/2009 01:18 PM 851,456 msvcp90.dll
07/14/2009 01:18 PM 627,200 msvcr90.dll
3 File(s) 1,723,904 bytes
Directory of C:\Program Files (x86)\Sony\VAIOData Restore Tool
11/26/2008 10:26 AM 568,832 msvcp90.dll
11/26/2008 08:57 AM 655,872 msvcr90.dll
2 File(s) 1,224,704 bytes
Directory of C:\Program Files (x86)\Sony\VAIO Recovery\plugins
07/15/2009 05:21 PM 224,768 msvcm90.dll
07/15/2009 05:21 PM 568,832 msvcp90.dll
07/15/2009 05:21 PM 655,872 msvcr90.dll
3 File(s) 1,449,472 bytes
Directory of C:\Program Files (x86)\Sony\VAIO
Recovery\plugins\x64
07/15/2009 05:21 PM 627,200 msvcr90.dll
1 File(s) 627,200 bytes
Directory of C:\Program Files (x86)\Sony\VAIO VP Utilities
04/02/2009 07:12 PM 568,832 msvcp90.dll
04/02/2009 07:12 PM 655,872 msvcr90.dll
2 File(s) 1,224,704 bytes
Directory of
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.2
1022.8_none_750b37ff97f4f68b
09/04/2009 04:35 AM 245,248 msvcm90.dll
09/04/2009 04:35 AM 851,456 msvcp90.dll
09/04/2009 04:35 AM 627,200 msvcr90.dll
3 File(s) 1,723,904 bytes
Directory of
C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.3
0729.4926_none_08e1a05ba83fe554
06/10/2009 03:31 PM 245,760 msvcm90.dll
06/10/2009 03:31 PM 853,328 msvcp90.dll
06/10/2009 03:31 PM 623,440 msvcr90.dll
3 File(s) 1,722,528 bytes
Directory of
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.210
22.8_none_bcb86ed6ac711f91
09/04/2009 04:35 AM 224,768 msvcm90.dll
09/04/2009 04:35 AM 568,832 msvcp90.dll
09/04/2009 04:35 AM 655,872 msvcr90.dll
3 File(s) 1,449,472 bytes
Directory of
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.307
29.1_none_e163563597edeada
09/04/2009 04:19 AM 225,280 msvcm90.dll
09/04/2009 04:19 AM 572,928 msvcp90.dll
09/04/2009 04:19 AM 655,872 msvcr90.dll
3 File(s) 1,454,080 bytes
Directory of
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.307
29.4926_none_508ed732bcbc0e5a
06/10/2009 04:14 PM 225,280 msvcm90.dll
06/10/2009 04:14 PM 569,664 msvcp90.dll
06/10/2009 04:14 PM 652,608 msvcr90.dll
3 File(s) 1,447,552 bytes
Thank you,
Malcolm
Ross Ridge
>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.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Jonathan Hartley
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
Christian Heimes
> 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
Ross Ridge
>1) I don't understand why the OP's question doesn't deserve a literal
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.
Mark Hammond
> 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
Jonathan Hartley
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.
Jonathan Hartley
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.
Ross Ridge
>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:
http://msdn.microsoft.com/en-us/library/ms235299.aspx
From the sounds of things, if you only have Visual C++ 2008 Express your
only option may be to use Visual C++ Redistributable Package.
Jonathan Hartley
Hey. So I think I'm finally getting it.
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.
Ross Ridge
>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.
Jonathan Hartley
Thanks very much again Ross.
Yeah, I'm looking at two scenarios:
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.
John Bokma
> 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.
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
Martin v. Loewis
> 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.
Regards,
Martin
Martin v. Loewis
> 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.
Regards,
Martin
pyt...@bdurham.com
> 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
Martin v. Loewis
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.
Regards,
Martin
Jonathan Hartley
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?
Jonathan Hartley
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.
I guess I really need an installer. Oh well.
Martin v. Loewis
>> 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.
Regards,
Martin
pyt...@bdurham.com
<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
Jonathan Hartley
> Jonathan,
>
> <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)
>
> 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
tar...@tartley.com +44 7737 062 225 twitter/skype: tartley
David Bolen
> 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.
-- David
kakarukeys
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.
Waldemar Osuch
> 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
> 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.
>
> 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
Before:
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
version="9.0.21022.8" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
After:
<dependency>
<dependentAssembly>
</dependentAssembly>
</dependency>
Is the method elegant? Nope.
Does it work? It does for me.
Use it at your own risk etc. The regular disclaimers apply.
The approach was gleaned from a thread at PIL mailing list.
http://mail.python.org/pipermail/image-sig/2009-October/005916.html
waldemar
pyt...@bdurham.com
Thank your for sharing your technique - works great with 32-bit Python
2.6.4.
Has anyone tried this with a 64-bit version of Python?
Malcolm
Jonathan Hartley
> dependency references and then dropping msvcr90.dll in the same
> directory as the py2exe produced executable.
Clever idea Waldemar, thanks for that, but for the moment, using the
dll as a win32 assembly (ie. with a manifest file, as described by
others earlier in this thread) seems to work just as well.
>> > You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
So, for the record, I have included these two files in a directory
called 'Microsoft.VC90.CRT', which is in the same dir as my
executable, and that makes everything work, even on my 'bare bones'
windows XP virtual machine.
The end result is a small game some friends and I put together for the
PyWeek competition a few months ago. If anyone wants to see exactly
how the resulting dll and manifest look, you can download the Windows
binary under the 'featured downloads' from here:
http://code.google.com/p/brokenspell/
I appreciate David Bolen's comment that an installer isn't that hard
to put together: Acknowledged, but for the moment I still seem to be
getting away without needing one.
Best regards,
Jonathan