Windows versions of Python---pros and cons?
Tom Loredo
Hi folks-
I've been using Python heavily on a Solaris box and a Mac for a
few years now. For reasons I'll spare you from, I now am venturing
into Windows territory (a Dell Inspiron 7500 laptop, if that matters).
I see at least two Windows versions of Python---that at Python.org,
and the ActiveState version. The obvious "pro" for the ActiveState
version is simplicity of the install (batteries included, etc.).
But what about after that? Are their substantial differences between
the versions that I will bump into down the line? In particular,
I write many C extensions; can one use distutils and the Borland
or gcc free compilers to build C extensions in both versions?
Thanks for your patience and advice for this PythonWin newbie!
-Tom Loredo
Fernando Pérez
> I've been using Python heavily on a Solaris box and a Mac for a
> few years now. For reasons I'll spare you from, I now am venturing
> into Windows territory (a Dell Inspiron 7500 laptop, if that matters).
If you're an old unix hand and want to preserve your sanity, you have two
options:
1- put linux on that laptop and be happy.
2- if (1) is not an option for some reason, put cygwin on it. At least you'll
have a decent working environment. If you have to work in the normal,
crippled windows environment, that laptop is going to suffer a painful death
after being hurled through the nearest window very soon :)
Cheers,
f.
Gerhard Häring
> My understanding is that for C extensions to work they must be built
> with the same compiler as that used to build the Python with which they
> will run. (I may be wrong. Someone please correct me if I am.)
You are wrong. As long as you link to the python{major}{minor}.dll you
are binary compatible, no matter which compiler you use. It's just a
matter of providing an additional compiler option to distutils, like in:
python setup.py build --compiler=mingw32
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Trent Mick
>
> Hi folks-
>
> I've been using Python heavily on a Solaris box and a Mac for a
> few years now. For reasons I'll spare you from, I now am venturing
> into Windows territory (a Dell Inspiron 7500 laptop, if that matters).
> I see at least two Windows versions of Python---that at Python.org,
> and the ActiveState version. The obvious "pro" for the ActiveState
> version is simplicity of the install (batteries included, etc.).
> But what about after that? Are their substantial differences between
> the versions that I will bump into down the line?
ActivePython should be 100% binary compatible with the Python installer
on python.org. If not, it is a bug. The only real "substantial"
difference, as far as your code is concerned, is the presence of some
Python extensions like PyWin32.
> In particular, I write many C extensions; can one use distutils and
> the Borland or gcc free compilers to build C extensions in both
> versions?
My understanding is that for C extensions to work they must be built
with the same compiler as that used to build the Python with which they
will run. (I may be wrong. Someone please correct me if I am.) Visual
C++ 6.0 is used to build ActivePython and a python.org's Python for
Windows. This means that you would have to build Python yourself from
source with your free compiler to be able to run your extensions built
with the free compiler.
Cheers,
Trent
--
Trent Mick
Tre...@ActiveState.com
Gerhard Häring
> [Pythonlabs and ActiveState Python] Are their substantial differences
> between the versions that I will bump into down the line?
No, none.
> In particular, I write many C extensions; can one use distutils and
> the Borland or gcc free compilers to build C extensions in both
> versions?
Yes, they're the same Python, ActiveState has just packaged a few more
goodies, and have a nicer installer. You can, however, manually get all
the extras that ActiveState packages from several places at the net.
ActiveState has just the advantage that they've already done that job
for you.
David LeBlanc
> > In particular, I write many C extensions; can one use distutils and
> > the Borland or gcc free compilers to build C extensions in both
> > versions?
>
> with the same compiler as that used to build the Python with which they
> will run. (I may be wrong. Someone please correct me if I am.) Visual
> C++ 6.0 is used to build ActivePython and a python.org's Python for
> Windows. This means that you would have to build Python yourself from
> source with your free compiler to be able to run your extensions built
> with the free compiler.
>
> Cheers,
> Trent
>
> --
> Trent Mick
> Tre...@ActiveState.com
>
It is always true (or has been historically) that you can't mix the output
of C++ compilers (due to name mangling not being standardized). It was, at
one time, true that Borland and Microsoft C compilers could use each other's
output, but that may no longer be so - MS may have changed it's .obj format.
If you have Borland C or GCC, I don't think it's all that hard to build
Python and friends (dunno about Mark Hammonds' COM extensions on Borland
though).
Dave LeBlanc
Seattle, WA USA
Michael Hudson
> * Trent Mick <tre...@ActiveState.com> [2002-06-19 15:46 -0700]:
> > My understanding is that for C extensions to work they must be built
> > with the same compiler as that used to build the Python with which they
> > will run. (I may be wrong. Someone please correct me if I am.)
>
> You are wrong. As long as you link to the python{major}{minor}.dll you
> are binary compatible, no matter which compiler you use.
Eh, that's a bit of a stretch isn't it? If your compilers have
different ideas about struct layout & so on it would certainly take
more effort than just linking the same libraries.
> It's just a
> matter of providing an additional compiler option to distutils, like in:
>
> python setup.py build --compiler=mingw32
I do think this works, though. I guess all compiler implementors on
Windows try to be compatible with MSVC.
Cheers,
M.
--
Well, you pretty much need Microsoft stuff to get misbehaviours
bad enough to actually tear the time-space continuum. Luckily
for you, MS Internet Explorer is available for Solaris.
-- Calle Dybedahl, alt.sysadmin.recovery
Fredrik Lundh
> > You are wrong. As long as you link to the python{major}{minor}.dll you
> > are binary compatible, no matter which compiler you use.
>
> Eh, that's a bit of a stretch isn't it? If your compilers have
> different ideas about struct layout & so on it would certainly take
> more effort than just linking the same libraries.
last time I checked, MSVC wasn't even compatible with
itself, if you mix /MD/MT/ML (i.e. runtime libraries).
different FILE* structures is a classic, for example.
</F>
John Roth
"Tom Loredo" <lor...@astro.cornell.edu> wrote in message
news:3D110B55...@astro.cornell.edu...
You should be able to use any compiler you want to - .dll's are
supposed to be language neutral, at least in the low level sense
of accessing them. As another poster pointed out, you might have
some problems with object files, since they aren't necessarily
compatible between different vendor's products.
John Roth
Chris Barker
> If you're an old unix hand and want to preserve your sanity, you have two
> options:
>
> 1- put linux on that laptop and be happy.
I have to concur. I am mostly a Linux user, but when I use Python on
Windows, I really have a hard time with it. It's nothing to do with
Python, and everything to do with Windows. Windows simply does not
provide a programing enviroment that will feel at all productive to
someone used to *nix. I run Linux on a Dell laptop, and am very happy
with it.
On that note: does anyone know if there is a way to turn a Python script
into something that acts like an application on Windows...without
resorting to Py2exe and the like. What I want is something just like:
chmod +x scriptname
and a #! line at the top
on Unix. I want it to work on the windows command line.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Tom Loredo
>
> If you're an old unix hand and want to preserve your sanity, you have two
> options:
>
> 1- put linux on that laptop and be happy.
Actually, I've reserved a big chunk of the disk for linux. Just gotta
decide which version (is there a "best" one for Python? E.g., Redhat
uses Python, but does their reliance on an old version still cause
problems?). I'll stay there when I'm developing for *me* on it!
> 2- if (1) is not an option for some reason, put cygwin on it.
Actually, I need to develop stuff that other Win32 users can use,
some probably distributed via the McMillan installer (which I presume
works as well with Active State as with the python.org version).
So I'm stuck here....
> If you have to work in the normal,
> crippled windows environment, that laptop is going to suffer a painful death
> after being hurled through the nearest window very soon :)
I've only had it two weeks, and only the power cord to the battery
charger has saved it! The fact that Dell shipped it with a defective
install of Win98 did not help its cause.
Thanks, to everyone!
-Tom
Fernando Pérez
> Fernando Pérez wrote:
>>
>> If you're an old unix hand and want to preserve your sanity, you have two
>> options:
>>
>> 1- put linux on that laptop and be happy.
>
> Actually, I've reserved a big chunk of the disk for linux. Just gotta
> decide which version (is there a "best" one for Python? E.g., Redhat
> uses Python, but does their reliance on an old version still cause
> problems?). I'll stay there when I'm developing for *me* on it!
Well, I'm a big fan of Mandrake over RedHat: more oriented towards
'workstation' users than 'server' users, more out-of-the box tools for
scientific use (lyx, gnuplot, octave, Numeric, Lapack,...). Plus redhat made
the most boneheaded decision on the planet with the two-version python setup,
which you'll have to duct-tape your way around.
_My_ (redhat fanatics, keep off :) simple experience so far is: everytime I
need to get something done on a mandrake machine, it works in under 15
minutes. Everytime I have to deal with a redhat machine, I'm pissed off after
two hours. But YMMV, as always.
>> 2- if (1) is not an option for some reason, put cygwin on it.
>
> Actually, I need to develop stuff that other Win32 users can use,
> some probably distributed via the McMillan installer (which I presume
> works as well with Active State as with the python.org version).
> So I'm stuck here....
Don't know if there's a misunderstanding here: cygwin is a unix-like
environment under Windows. So at least you'll have a terminal worthy of the
name, plus all the command-line tools you neeed on a day to day basis (grep,
sed, awk, etc.). I don't use it (I simply don't use windows except in rare
cases), but I've heard it's quite good and makes life under windows at least
bearable.
>> If you have to work in the normal,
>> crippled windows environment, that laptop is going to suffer a painful
>> death after being hurled through the nearest window very soon :)
>
> I've only had it two weeks, and only the power cord to the battery
> charger has saved it! The fact that Dell shipped it with a defective
> install of Win98 did not help its cause.
Well, if you do have to live with windows, I'd recommend at least using XP.
It's still an annoying crippled toy, but at least it _is_ much more stable
than Win9x, and when things crash they typically don't take down the whole
system with them. Don't expect unix-class stability, but it won't drive you
nuts like win9x will.
Best,
f
Chris Barker
Tom Loredo wrote:
> Redhat
> uses Python, but does their reliance on an old version still cause
> problems?.
They use 1.5, and all their scripts use "python" on the #! line, so if
you use a more recent version, you need to put python2 (or python2.2 or
whatever) on your #! lines. Nat a big deal, really, but a little
annoying. I'd love to see RedHat put python1.5 on THEIR #! lines, which
you wouldn't think would be difficult. Maybe RedHat 8.*, they have been
getting complaints.
> Actually, I need to develop stuff that other Win32 users can use,
> some probably distributed via the McMillan installer (which I presume
> works as well with Active State as with the python.org version).
> So I'm stuck here....
I'd do most of your coding under Linux, and just use Windows to test an
package it up, unless you're doing com or something Windows only.
> The fact that Dell shipped it with a defective
> install of Win98 did not help its cause.
Is there such a thing an a non defective Win98? Seriously, use Win2k if
you can, I still don't like it, but it provides a modicum of stability
and a almost usable command line.
Tom Loredo
>
> Don't know if there's a misunderstanding here:
Very likely! (On my part!)
> cygwin is a unix-like
> environment under Windows.
Okay, my concern was that it wouldn't work with or be able to produce
Windows binaries---like if I had to produce binary extension modules
to ship to others, or a McMillan-ized install that used PythonWin
and Tk or wxWindows. Cygwin is so huge that I got the impression
it was a self-contained "subenvironment" so to speak, so I didn't
realize I could use it to produce stuff that non-cygwin Windows users
could use.
> Well, if you do have to live with windows, I'd recommend at least using XP.
Well, there is now a recommendation each for WinXP and Win2k in this
thread. If anyone has tried both and can offer a comparison/recommendation,
I'm all ears. If I'm going to upgrade, I'd rather do it sooner than later.
Thanks again,
Tom
Chris Barker
> Well, there is now a recommendation each for WinXP and Win2k in this
> thread. If anyone has tried both and can offer a comparison/recommendation,
> I'm all ears. If I'm going to upgrade, I'd rather do it sooner than later.
This is getting kind of OT, but I'm seriously unthrilled with the
licencing/privacy/registration issues with XP, so I havn't tried it. I
also see no reason to, the only improvements I've heard about are better
integration of various (mostly MS) multi-media stuff with the desktop,
which is no use to me. I'm working on a largish Python project with two
other progammers. I'm on linux, one of them on win2k the other on XP, I
havn't see much functional difference.
If I had to use windows more, I would definately give cygwin a good
look-see. There is also at least one other package of *nix command line
tools for windows that looks like it's less of a complete environment,
but rather ports of the unix tools to windows.
Mark Hammond
> On that note: does anyone know if there is a way to turn a Python script
> into something that acts like an application on Windows...without
> resorting to Py2exe and the like. What I want is something just like:
Add the .py extension to your PATHEXT environment variable, and you can
execute "foo.py" at the command prompt. Like much of Windows, this is
based on the extension rather than file attributes.
Mark.
Bjorn Pettersen
[snip]
>
> On that note: does anyone know if there is a way to turn a
> Python script into something that acts like an application on
> Windows...without resorting to Py2exe and the like. What I
> want is something just like:
>
> and a #! line at the top
>
> on Unix. I want it to work on the windows command line.
If you use the ActiveState version (not sure about the python.org
version) this should work out-of-the-box. Just type the name of the
script, you can even leave out the .py extension. Someone else will
probably tell you how it works, I just know it's got something to do
with registering the .py extension as an executable extension in the
registry...
-- bjorn
Syver Enstad
>
> On that note: does anyone know if there is a way to turn a Python
> script
>
> into something that acts like an application on Windows...without
> resorting to Py2exe and the like. What I want is something just like:
>
> chmod +x scriptname
> and a #! line at the top
>
> on Unix. I want it to work on the windows command line.
>
Make a text file, save it as something.bat, put the line below in the
first line of the file.
@python -x "%~f0" %* & goto :EOF
or
@python -x -OO "%~f0" %* & goto :EOF
Put python code in the lines underneath.
If you're using emacs and want syntax highlighting:
Put
# Local Variables: ***
# mode:python ***
# End: ***
at the end of the file
I think that this only works on win2k because it uses extensions to
the batch language that is not part of win9x family of os'es.
--
Vennlig hilsen
Syver Enstad
Frédéric Cordonier
>* Trent Mick <tre...@ActiveState.com> [2002-06-19 15:46 -0700]:
>
>
>>My understanding is that for C extensions to work they must be built
>>with the same compiler as that used to build the Python with which they
>>will run. (I may be wrong. Someone please correct me if I am.)
>>
>>
>
>You are wrong. As long as you link to the python{major}{minor}.dll you
>are binary compatible, no matter which compiler you use. It's just a
>matter of providing an additional compiler option to distutils, like in:
>
> python setup.py build --compiler=mingw32
>
>Gerhard
>
>
Hello,
I am no windows or C++ specialist, but I happened to write extensions
for Python in the scope of unitary testing code for embedded systems.
I did extensions with both Borland C++ 5.01 and mingw32. Under windows,
it is always easier to link the project with a .lib file rather than
directly connecting to the .dll. The problem with Borland is that the
.lib for Pythonxx.dll is tricky to generate. In fact, Borland adds some
'_' to the exported symbols. You have to:
> impdef Python22.def Python22.dll
modify the Python22.def to add leading '_' to the symbols (I use gvim
that is really handy for this kind of tasks).
then
> implib Python22.lib Python22.def
For Mingw32, the .lib file can be generated with 'pexports' and 'dlltool'.
Moreover, I wrote extensions with SWIG using Borland. One problem I
encountered is that the main module entry is not exported correctly
(when importing the module, an exception is raised), because SWIGEXPORT
is not adapted (maybe specific to BC++5.01?).
You have to redefine it to
#define SWIGEXPORT(a) a _export FAR PASCAL
Last, using distutil with Borland is certainly possible, but not with
version 5.01 (my customer only has this version). Some linker options
used with '--compler=bcpp' are not known by 5.01. I had to patch
distutils to make it work. If ever someone needs it, I will go back to
my notebook to check what was done...
Fred.
Andreas Ames
Chris Barker <Chris....@noaa.gov> writes:
> resorting to Py2exe and the like. What I want is something just like:
>
> chmod +x scriptname
> and a #! line at the top
Alternatively you can use cygwin here. It comes with it's own python port.
cheers,
andreas
Trent Mick
> > Python script into something that acts like an application on
> >
> > chmod +x scriptname
> > and a #! line at the top
> >
>
> version) this should work out-of-the-box. Just type the name of the
> script, you can even leave out the .py extension. Someone else will
> probably tell you how it works, I just know it's got something to do
> with registering the .py extension as an executable extension in the
> registry...
As Mark Hammond mentioned, this is done by adding .py to your PATHEXT
env. var. ActivePython does that (and .pyc, .pyo, .pyw, .pys as well).
Chris Barker
> > On that note: does anyone know if there is a way to turn a
> > Python script into something that acts like an application on
> > Windows...without resorting to Py2exe and the like.
> If you use the ActiveState version (not sure about the python.org
> version) this should work out-of-the-box. Just type the name of the
> script, you can even leave out the .py extension.
Actually, I do use the ActiveState version, but *.py is associated with
PythonWin, rather than the python interpreter
Mark Hammond wrote:
> Add the .py extension to your PATHEXT environment variable, and you can
> execute "foo.py" at the command prompt. Like much of Windows, this is
> based on the extension rather than file attributes.
Which is really annoying, kind of like the Macintosh file creator
concept: I sometimes want the file to be edited, and sometime run...
Anyway, it looks like my best bet is to re-associate *.py with the
python interpreter, rather than pythonwin. I rarely have a use for
opening pythonwin from the command line, and in the GUI, I can use
openwith from the right button menu if I want to open a *.py file in pythonwin.
Now I have to figure out how to change my PATHEXT environment variable,
which is pretty OT for this group...
David LeBlanc
> Mark Hammond wrote:
> > Add the .py extension to your PATHEXT environment variable, and you can
> > execute "foo.py" at the command prompt. Like much of Windows, this is
> > based on the extension rather than file attributes.
Even cooler, you no longer need the .py extension (if you're on Win2000 at
least) and if you're in the same directory as the script you're trying to
execute. I'm not sure that even with a .py extension that it will do a path
search.
> Which is really annoying, kind of like the Macintosh file creator
> concept: I sometimes want the file to be edited, and sometime run...
>
> Anyway, it looks like my best bet is to re-associate *.py with the
> python interpreter, rather than pythonwin. I rarely have a use for
> opening pythonwin from the command line, and in the GUI, I can use
> openwith from the right button menu if I want to open a *.py file
> in pythonwin.
>
> Now I have to figure out how to change my PATHEXT environment variable,
> which is pretty OT for this group...
It's in your environment settings right under "path" :-)
> -Chris
>
Greetings fellow latte slurping moss backed emerald city dweller ;-)
P. Alejandro Lopez-Valencia
"Mark Hammond" <mham...@skippinet.com.au> escribió en el mensaje
news:3D125B79...@skippinet.com.au...
Ehem! :) This only works in WINNT class OSs that use cmd.exe as their
default command line processor. Lowly DOS32 OSs such as the Win98
mentioned by the OP, that only have command.com, just can't.
P. Alejandro Lopez-Valencia
"Tom Loredo" <lor...@astro.cornell.edu> escribió en el mensaje
news:3D110B55...@astro.cornell.edu...
>
> In particular,
> I write many C extensions; can one use distutils and the Borland
> or gcc free compilers to build C extensions in both versions?
Yes, as long as it be possible to convert the link libraries from one
format to the other. Everything is explained in the distutils
documentation (I'm surprised none has mentioned this yet!!!).
In the case of the Borland compilers, you process the MSVC6 import
libraries provided in the ${PYTHONHOME}/libs directory with COFF2OMF and
add the suffix "_bcpp", like so
c:\whatever\libs > coff2omf python22.lib python22_bcpp.lib
and add the resulting libraries to the same directory where the MSVC
import libraries are located originally. To compile your extension with
Borland C++ and distutils, you just type,
c:\foo\bar > python setup.py build --compiler=bcpp
Should know, I just compiled the latest numpy CVS snapshot with BCPP
ten minutes ago ;)
If you want to use mingw32 gcc, the process is *a lot" more complicated.
See the documents I mentioned above (basically you need to extract all
the export symbols from the DLL and then create an import library based
on the exports definition file).
Piet van Oostrum
PAL> "Mark Hammond" <mham...@skippinet.com.au> escribió en el mensaje
PAL> news:3D125B79...@skippinet.com.au...
>> Chris Barker wrote:
>>
>> > On that note: does anyone know if there is a way to turn a Python
PAL> script
>> > into something that acts like an application on Windows...without
>> > resorting to Py2exe and the like. What I want is something just
PAL> like:
>>
>> Add the .py extension to your PATHEXT environment variable, and you
PAL> can
>> execute "foo.py" at the command prompt. Like much of Windows, this is
>> based on the extension rather than file attributes.
PAL> Ehem! :) This only works in WINNT class OSs that use cmd.exe as their
PAL> default command line processor. Lowly DOS32 OSs such as the Win98
PAL> mentioned by the OP, that only have command.com, just can't.
In that case use a program like PythonLauncher, which allows you to make a
small .exe file for each Python script (just copy the generic program to
script.exe where script is your script name (minus the .py extension).
This has the additional advantage of properly redirecting I/O from the
command line, which isn't the case with the other suggestions.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van....@hccnet.nl
Trent Mick
> Actually, I do use the ActiveState version, but *.py is associated with
> PythonWin, rather than the python interpreter
No, ActivePython registers the "Open" action for .py to run with the
Python interpreter and also registers an "Edit" action to open in
PythonWin. "Open" should be the default action so that double-clicking
on a .py file will run it. You should be a ble to right-click on a .py
file and have "Open" and "Edit" options.
> Now I have to figure out how to change my PATHEXT environment variable,
> which is pretty OT for this group...
Win9x: autoexec.bat
WinME: dunno
WinNT/2000/XP: Start->Settings->Control Panel->System
->Advanced->Environment Variables
Cheers,
Dean Goodmanson
> > Now I have to figure out how to change my PATHEXT environment variable,
> > which is pretty OT for this group...
>
> Win9x: autoexec.bat
> WinME: dunno
> WinNT/2000/XP: Start->Settings->Control Panel->System
> ->Advanced->Environment Variables
>
WinME: MSConfig
Dean Goodmanson
> which is pretty OT for this group...
A clearer answer to my hasty response in Trent's direction:
WinME: Start , Run , MSConfig . (Also works in Win98.)
Andrae Muys
> Fernando Pérez wrote:
> >
> > Don't know if there's a misunderstanding here:
>
> Very likely! (On my part!)
>
> > cygwin is a unix-like
> > environment under Windows.
>
> Okay, my concern was that it wouldn't work with or be able to produce
> Windows binaries---like if I had to produce binary extension modules
> to ship to others, or a McMillan-ized install that used PythonWin
> and Tk or wxWindows. Cygwin is so huge that I got the impression
> it was a self-contained "subenvironment" so to speak, so I didn't
> realize I could use it to produce stuff that non-cygwin Windows users
> could use.
>
It is important to differentiate between the cygwin environment, and
the cygwin platform itself. At its core cygwin is a dll that provides
a port of most of the POSIX API to W32. On top of this, cygwin also
offers a host of other API's common on various unix platforms ported
to the cygwin.dll 'unix platform'. On top of these libraries the
cygwin environment is assembled out of all manner of common unix
programs, utilities, servers, etc built using these libraries and the
cygwin.dll.
The environment is huge. Considering that a full install includes
ports of XFree86, TeX, gcc & libs, python2.2, perl5.6.1, a full
install == a LOT of bytes :).
The libraries however are a fraction of this size, consider a ls -l
*.dll on /bin (where cygwin keeps the libraries, I assume for windows
compat' sake)
$ ls -l *.dll | awk 'BEGIN { sum = 0 } { sum = sum + $5 } END { print
sum }'
8931012
$ ls -l cygwin1.dll
-rwxr-xr-x 1 Administ None 895304 Jun 24 12:33 cygwin1.dll
$ ls -l *.dll
-rwxr-xr-x 1 Administ None 46592 Jan 21 04:51 cygXpm-X4.dll
-rwxr-xr-x 1 Administ None 41984 Jan 21 04:51
cygXpm-noX4.dll
-rwxr-xr-x 1 Administ None 58880 May 7 16:36 cygbz2-1.dll
-rwxr-xr-x 1 Administ None 635904 May 17 22:25 cygcrypto.dll
-rwxr-xr-x 1 Administ None 333824 Jun 19 08:16 cygdb2.dll
-rwxr-xr-x 1 Administ None 51200 Mar 17 16:24 cygexslt-0.dll
-rwxr-xr-x 1 Administ None 46080 Apr 25 2001 cygform5.dll
-rwxr-xr-x 1 Administ None 35328 Jan 9 16:11 cygform6.dll
-rwxr-xr-x 1 Administ None 18944 Feb 20 13:06 cyggdbm.dll
-rwxr-xr-x 1 Administ None 19968 Jan 13 11:29
cyghistory5.dll
-rwxr-xr-x 1 Administ None 22016 Dec 13 2001 cygintl-1.dll
-rwxr-xr-x 1 Administ None 21504 Jun 21 2001 cygintl.dll
-rwxr-xr-x 1 Administ None 82944 Oct 20 2001 cygitcl30.dll
-rwxr-xr-x 1 Administ None 35328 Oct 20 2001 cygitk30.dll
-rwxr-xr-x 1 Administ None 45568 Feb 8 10:00 cygjbig1.dll
-rwxr-xr-x 1 Administ None 121856 Feb 9 15:21 cygjpeg6b.dll
-rwxr-xr-x 1 Administ None 26624 Apr 25 2001 cygmenu5.dll
-rwxr-xr-x 1 Administ None 19968 Jan 9 16:11 cygmenu6.dll
-rwxr-xr-x 1 Administ None 159232 Apr 25 2001
cygncurses++5.dll
-rwxr-xr-x 1 Administ None 179200 Jan 9 16:11
cygncurses++6.dll
-rwxr-xr-x 1 Administ None 230912 Apr 25 2001
cygncurses5.dll
-rwxr-xr-x 1 Administ None 206848 Jan 9 16:11
cygncurses6.dll
-rwxr-xr-x 1 Administ None 15360 Apr 25 2001 cygpanel5.dll
-rwxr-xr-x 1 Administ None 11776 Jan 9 16:11 cygpanel6.dll
-rwxr-xr-x 1 Administ None 41105 Nov 22 2001 cygpcre.dll
-rwxr-xr-x 1 Administ None 40251 Nov 22 2001
cygpcreposix.dll
-rwxr-xr-x 1 Administ None 175104 May 8 05:10 cygpng10.dll
-rwxr-xr-x 1 Administ None 179200 May 24 12:23 cygpng12.dll
-rwxr-xr-x 1 Administ None 174080 Jan 21 11:05 cygpng2.dll
-rwxr-xr-x 1 Administ None 22528 Jun 9 15:50 cygpopt-0.dll
-rwxr-xr-x 1 Administ None 123904 Jan 13 11:29
cygreadline5.dll
-rwxr-xr-x 1 Administ None 68016 Nov 21 2001 cygregex.dll
-rwxr-xr-x 1 Administ None 159744 May 17 22:25 cygssl.dll
-rwxr-xr-x 1 Administ None 399360 Oct 20 2001 cygtcl80.dll
-rwxr-xr-x 1 Administ None 4608 Oct 20 2001
cygtclpip80.dll
-rwxr-xr-x 1 Administ None 10240 Oct 20 2001
cygtclreg80.dll
-rwxr-xr-x 1 Administ None 258560 Feb 10 18:36 cygtiff3.dll
-rwxr-xr-x 1 Administ None 637952 Oct 20 2001 cygtk80.dll
-rwxr-xr-x 1 Administ None 895304 Jun 24 12:33 cygwin1.dll
-rwxr-xr-x 1 Administ None 1277440 Mar 17 13:56 cygxml2-2.dll
-rwxr-xr-x 1 Administ None 155136 Mar 17 16:23 cygxslt-1.dll
-rwxr-xr-x 1 Administ None 15360 Mar 17 16:24
cygxsltbreakpoint-1.dll
-rwxr-xr-x 1 Administ None 50688 Mar 12 14:38 cygz.dll
-rwxr-xr-x 1 Administ None 49664 Feb 25 13:33 libW11.dll
-rwxr-xr-x 1 Administ None 749056 Aug 22 2001
libperl5_6_1.dll
-rwxr-xr-x 1 Administ None 771584 Jan 1 06:26
libpython2.2.dll
-rwxr-xr-x 1 Administ None 204288 Oct 20 2001 tix4180.dll
As you can see the cygwin dll is only ~900k, while even the entire
porting environment (excluding X11R6) is < 9Mb (X11R6 is just over
4Mb).
So in most situations this is not imposing a signifigant overhead.
Andrae Muys
David LeBlanc
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Andrae Muys
> Sent: Monday, June 24, 2002 18:51
> To: pytho...@python.org
> Subject: Re: Windows versions of Python---pros and cons?
>
>
> Tom Loredo <lor...@astro.cornell.edu> wrote in message
> news:<3D124575...@astro.cornell.edu>...
> > Fernando Pérez wrote:
> > >
> > > Don't know if there's a misunderstanding here:
> >
> > Very likely! (On my part!)
> >
> > > cygwin is a unix-like
> > > environment under Windows.
> >
> > Okay, my concern was that it wouldn't work with or be able to produce
> > Windows binaries---like if I had to produce binary extension modules
> > to ship to others, or a McMillan-ized install that used PythonWin
> > and Tk or wxWindows. Cygwin is so huge that I got the impression
> > it was a self-contained "subenvironment" so to speak, so I didn't
> > realize I could use it to produce stuff that non-cygwin Windows users
> > could use.
> >
If redistribution of executables that use the cygwin.dll is important, it
should be noted that you can only do this if it's a GPL app (or maybe even
that requires permission) - commercial redistribution definately requires a
licen$e from RedHat. At one time it was $100 per developer.