«

Martin v. Löwis wrote:

> For developers that need msvcr71.dll on the target system which don't
> have a license to distribute it, the solution is simple: they just need
> to advise their users to install python-2.4.1.msi. This comes with
> msvcr71.dll included.

I understand this, and it's obviously a solution. Unfortunately it
defeats the whole point of me 'freezing' my code in the first place.

The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.

They would see a .exe file, a dll and a pyd, and then the actual
application files, and that was it. It may be fine for a 'knowledgeable'
user to install python etc., but not for everyone.

Michael.

Do Re Mi chel La Si Do wrote:
> Hi !
>
> This DLL come also with MS-JVM engine, who is free. Therefore...
>

This is very true (and the .NET suggestion as well). However, why should
I require an end-user to install MS-JVM or the .NET framework, purely
for a simple little launcher application ?

The main application it launches is Java, but there's no way it would
run on the MS-JVM, and .NET just gives a load more technology that we
don't really need (and is a bigger install than the entire application).

Michael.

Martin v. Löwis wrote:

>> What happens if I try to install Python2.4 on a system wich doesn't have
>> the dll?
>
> It will just work. Python installs the DLL if it is missing, and leaves
> it alone (just incrementing the refcount) if it is present on the target
> system.

installs it where? the MS docs seem to indicate that they want you to install
it in the program directory, rather than in a "shared" location:

http://support.microsoft.com/default...b;en-us;326922

</F>

I'm sorry that this is going to come out sounding like a flame, but it
seems to me that there today only a few technical problems remaining
with Python when built with mingw32.

If one of the people who has expressed such deep concern about this
"msvcr71.dll" problem would simply install the Free tools and start
putting patches on sourceforge, it's quite possible that for the next
2.4.x release the mingw32 "port" could be a first-rate one, and suitable
for the uses that the posters in this thread have mentioned.

Since mingw32 is Free (gpl and other licenses for tools, public domain
libraries and copyrighted headers with "no restrictions for programs"
built using the headers) anyone can install and use these tools and
mingw creates no new problems with distribution of the resulting binary,
whether the final product is Free or proprietary.

(Admittedly I don't know anything about whether "win32all" builds under
mingw32, and it's not clear whether binary compatibility with extensions
built by microsoft compilers is an easy goal either)

http://www.mingw.org/

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCW9BaJd01MZaTXX0RAjSUAJ9rQ9iPncKGReearcIiAG aiE2pVCgCfbx39
eRPFXirdDedIlhyhXrs42RU=
=QgCW
-----END PGP SIGNATURE-----

"Michael Kearns" <> wrote in message
news:425b8948$0$38045$.. .
>I understand this, and it's obviously a solution. Unfortunately it defeats
>the whole point of me 'freezing' my code in the first place.

>The main feature (for me) of the way I could use this, was to create a
>simple Java launcher that didn't require the user to install anything
>extra, or end up with a whole stack of unused data on their machine.

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. Doing so seems no
different to me than having to install (or upgrade) Shockwave, or Apple's
Quicksomething for Windows (not used so much anymore), or RealPlayer, or
the lastest upgrade for DirectX, or DivX, or a zip decoder, or any other
3rd party software, to run .xxx files or specialized .exe programs. (And I
left out the most direct analogy of a java system.)

In other words, it seems to me that most Windows users should be familiar
with the idea of having to install a player or platform to run something
built on top of that player or platform. Bundling a private Python
interpreter with every Python script is much like bundling a private
Shockwave player with every Schockwave script. I think most people would
prefer having one copy of each.

To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.

Terry J. Reedy

"Terry Reedy" <> writes:

[...]
> Also, I think it a bit 'anti-social' to hide usage of Python. If all
> Python Windows programs ran with a normal, communally installed Python,
> then users would gradually get the idea that having Python installed is
> much like having Shockwave and other utility platforms installed, and that
> is is part of a 'fully loaded' Windows system to have a .py player
> installed.

Isn't it a bit harsh to call this 'anti-social'?

>
> If there is something about the default install of Python on Windows that
> makes it less desireable or less easy than other platforms, then maybe that
> can be fixed. To make installation easier, maybe someone could write a
> small .exe that could be frozen with scripts or run with installers and
> that would detect the presence/absence of the needed Python version and
> offer an auto download and install if needed.

Sure. Someone.

>
> At least one thing in Python's favor is the lack of having to 'register'
> before downloading (or after installation) and the ability to redistribute
> the installer free and without special license.

Thomas

Terry Reedy wrote:
> I guess I don't understand some people's determination to not have users
> install fully useable Python on their Windows machines.
[snip]
> To put it another way, needing a Python interpreter to run .py files is no
> different from, for instance, needing a movie player to run .mpg files, and
> all Windows users are or need to become familiar with that general concept.
>
> Also, I think it a bit 'anti-social' to hide usage of Python. If all
> Python Windows programs ran with a normal, communally installed Python,
> then users would gradually get the idea that having Python installed is
> much like having Shockwave and other utility platforms installed, and that
> is is part of a 'fully loaded' Windows system to have a .py player
> installed.
>
> If there is something about the default install of Python on Windows that
> makes it less desireable or less easy than other platforms, then maybe that
> can be fixed. To make installation easier, maybe someone could write a
> small .exe that could be frozen with scripts or run with installers and
> that would detect the presence/absence of the needed Python version and
> offer an auto download and install if needed.

I mostly agree with the sentiment, but it does break down a little in practice.
At least currently it does - like you said, this is fixable, but nobody has
signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a Python
runtime, if you will - that (1) gets installed to a "good" place (2) does so
without asking the user to do anything, (3) can coexist with different versions
of the runtime, and (4) is easily detectable by applications wanting to use it.

One other minor component is a small launcher executable, because on Windows
it's non-trivial to find out which "python.exe" in the task manager is running
which Python script. Anyway, each app would have a small launcher that
bootstraps the actual Python script[1]. (Or, if there's some way to trick the
task manager into displaying something besides "python.exe", that'd work too)

In order to "fit" into the expectations of a typical Windows user, an
application installer needs the ability to check for the presence of a
particular version of the Python runtime, and then install it if it's not
present, and do so without asking the user to do anything.

With that much in place, a lot of the need for freezing Python apps goes away
(definitely not all of it, but a lot of it). Here's stuff that still needs to be
considered though:

1) A way for apps to specify their compatibility with different versions of the
runtime - "I work with pyrt2.3.3 through 2.4.1"

2) A way for apps to register their dependency on that runtime, so that if the
user uninstalls it, there is at least an indication of what programs might break.

3) (this is a nice-to-have, but not 100% required) A way to download additional
libraries once and use them for multiple programs, e.g. the installer could see
if ctypes is present, and if not, go get it. Later programs would take advantage
of it already being installed. Like I said, not a 100% requirement, and some of
the ongoing work with code CPAN-like code repositories would shoehorn into this.

4) The security implications, e.g. an innocent app installs pywin32 and enables
Python client-side scripting in Internet Explorer, and later this is used as a
big door for malicious users to use.

Most of these tasks don't require a lot of work; indeed this has been on my "one
of these days" lists for awhile. The main reasons it hasn't been done yet:

1) The code freezing tools like py2exe are *very* good and convenient
(especially since loading code from zip archives was added - even if you include
all of Python, it's only a few files on disk, and now they're all in the same
directory)

2) Storage space and download speeds continue to increase at a rate much faster
than the rate at which the size of Python is growing - a download of a few MB
isn't too bad these days, who cares if your app takes 4MB on disk, and so what
if it doesn't fit on a floppy, for example.

3) As soon as you get started on such a project, almost immediately you will be
overwhelmed with a desire to create a CPAN-like system while you're at it, at
which point your project's status will shift from "making good progress!" to "in
quagmire, developers MIA".

-Dave

[1] I built a hacky one of these launcher exe's for one project, and it was
fairly reusable for apps in the same vein. Basically, the exe would would look
to see what its name was, and then load a Python module of the same name. So if
you have MyGame.py, you'd just take the generic launcher.exe, copy it to the
same directory as your .py files, and rename it to MyGame.exe. On launch, it'd
load the interpreter, load MyGame.py, and pass it the command-line args.

Dave Brueck <> writes:

> Terry Reedy wrote:
>> If there is something about the default install of Python on Windows
>> that makes it less desireable or less easy than other platforms,
>> then maybe that can be fixed. To make installation easier, maybe
>> someone could write a small .exe that could be frozen with scripts
>> or run with installers and that would detect the presence/absence of
>> the needed Python version and offer an auto download and install if
>> needed.
>
> I mostly agree with the sentiment, but it does break down a little in
> practice. At least currently it does - like you said, this is fixable,
> but nobody has signed up to fix it yet.
>
> The main thing that's needed is a zero-input Python distribution - a
> Python runtime, if you will - that (1) gets installed to a "good"
> place (2) does so without asking the user to do anything, (3) can
> coexist with different versions of the runtime, and (4) is easily
> detectable by applications wanting to use it.

The effbot.exe platform (or how it's called) ?

> One other minor component is a small launcher executable, because on
> Windows it's non-trivial to find out which "python.exe" in the task
> manager is running which Python script. Anyway, each app would have a
> small launcher that bootstraps the actual Python script[1]. (Or, if
> there's some way to trick the task manager into displaying something
> besides "python.exe", that'd work too)

exemaker?

Thomas

Thomas Heller wrote:
> Dave Brueck <> writes:
>>Terry Reedy wrote:
>>>If there is something about the default install of Python on Windows
>>>that makes it less desireable or less easy than other platforms,
>>>then maybe that can be fixed. To make installation easier, maybe
>>>someone could write a small .exe that could be frozen with scripts
>>>or run with installers and that would detect the presence/absence of
>>>the needed Python version and offer an auto download and install if
>>>needed.
>>
>>I mostly agree with the sentiment, but it does break down a little in
>>practice. At least currently it does - like you said, this is fixable,
>>but nobody has signed up to fix it yet.
>>
>>The main thing that's needed is a zero-input Python distribution - a
>>Python runtime, if you will - that (1) gets installed to a "good"
>>place (2) does so without asking the user to do anything, (3) can
>>coexist with different versions of the runtime, and (4) is easily
>>detectable by applications wanting to use it.
>
>
> The effbot.exe platform (or how it's called) ?

Yep - something along those lines, plus some docs for app developers. I don't
know if it installs all the stdlib, or just what effbot apps need, but I assume
the former.

>>One other minor component is a small launcher executable, because on
>>Windows it's non-trivial to find out which "python.exe" in the task
>>manager is running which Python script. Anyway, each app would have a
>>small launcher that bootstraps the actual Python script[1]. (Or, if
>>there's some way to trick the task manager into displaying something
>>besides "python.exe", that'd work too)
>
>
> exemaker?

Something similar to that, yes. You'd need an option to generate a console
launcher or a Windows app launcher (maybe his latest version already has this?),
and a way to figure out which version of the runtime to use (rather than specify
the path ahead of time, you'd specify version requirements, and then at runtime
use registry entries to figure out where that runtime is), but the general idea
is the same.

-Dave

Mentre io pensavo ad una intro simpatica "Martin v. Löwis" scriveva:

>> What happens if I try to install Python2.4 on a system wich doesn't have
>> the dll?
> It will just work. Python installs the DLL if it is missing, and leaves
> it alone (just incrementing the refcount) if it is present on the target
> system.

OK, so the python installer _does_ ship this dll. So also the win
installer has the redistribution problem, or does they pay for
redistributing msvcr71.dll?

--
Computers follow your orders, not your intentions.

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org