SF patch #103683: Alternative dll version resources.
Changes similar to the patch. MarkH should review.
File version and Product version text strings now 2.1a2.
64-bit file and product version numbers are now
PY_MAJOR_VERSION, PY_MINOR_VERSION, messy, PYTHON_API_VERSION
where
messy = PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL
Updated company name to "Digital Creations 2".
Copyright now lists Guido; "C in a circle" symbol used instead of (C).
Comments added so this is less likely to get flubbed again, and
#if/#error guys added to trigger if the version number manipulations
above overflow.
Wasn't built on Windows; not in config.c either.
Module init function missing DL_EXPORT magic.
test_xreadline output file obviously wrong (started w/ "test_xrl").
test program very unclear about what was expected.
(I had explicitly disabled it a while ago, possibly unecessarily, along with
rgbimg, audioop, and imageop, which are advertised as "not for 64-bit
platforms.)
ceval.c:
define recurion_limit (static), default value is 2500
define Py_GetRecursionLimit and Py_SetRecursionLimit
raise RuntimeError if limit is exceeded
PC/config.h:
remove plat-specific definition
sysmodule.c:
add sys.(get|set)recursionlimit
This patch makes it possible to use gnu-win32 and lcc-win32
(http://www.cs.virginia.edu/~lcc-win32/) compilers to build
extension modules. It adds compiler specific sections to
PC/config.h .
It also extends the Borland compiler section. This has then two parts,
one for Win32 and the other one for the rest. The Win32 part
should be almost complete.
*** This patch is not intended to make it possible to compile
Python with these compilers, it is intended to be able to
use these compilers to build extension modules. ****
comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)
Barry Scott). it appears to solve the problem on NT
and 2000, but not on Windows 95.
in other words, it's better than before, but not per-
fect. I'll leave the patch open for now.
pointed out some of the problems he had following the instructions,
and I stumbled into the others: MSVC has changed in several
respects, Python has changed the directories into which it builds
its own Windows outputs, and we grew the unusual scheme of
appending "_d" to the names of debug-mode output files.
This should all work with VC6 + CVS Python now. Some other Windows
geek please confirm! And the less you know, the better <0.5 wink>.
Explanations and examples for versions of MSVC before 6, and
versions of Python before 2.0b1, have been removed, because
they're too different and so confuse life. This last step I OK'ed
with Guido first (indeed, 'twas his idea!).
Trent Mick <trentm@activestate.com>:
Fix PC/msvcrtmodule.c and PC/winreg.c for Win64. Basically:
- sizeof(HKEY) > sizeof(long) on Win64, so use PyLong_FromVoidPtr()
instead of PyInt_FromLong() to return HKEY values on Win64
- Check for string overflow of an arbitrary registry value (I know
that ensuring that a registry value does not overflow 2**31 characters
seems ridiculous but it is *possible*).
Closes SourceForge patch #100517.
64-bit readiness (the config values are needed for patches that I will
be submitting later today. The changes are as follows:
- add SIZEOF_OFF_T #define's to PC/config.h (it was already in configure.in)
- add SIZEOF_TIME_T #define to PC/config.h and configure
Needed for some buffer overflow checking because sizeof(time_t) is
different on Win64.
- add SIZEOF_FPOS_T #define
Needed for the Win64 large file support implementation.
- add SIZEOF_HKEY in PC/config.h only
Needed for proper Win32 vs. Win64 handling in PC/winreg.c
- #define HAVE_LARGEFILE_SUPPORT for Win64
- typedef long intptr_t; for all Windows except Win64 (which defines it
itself)
This is a new ANSI (I think) type that is useful (and used by me) for
proper handling in msvcrtmodule.c and posixmodule.c
- indent the nested #ifdef's and #defines in PC/config.h
This is *so* much more readable. There cannot be a compiler
compatibilty issue here can there? Perl uses indented #defines and it
compiles with everything.
errors in some of the hash algorithms. For exmaple, in float_hash and
complex_hash a certain part of the value is not included in the hash
calculation. See Tim's, Guido's, and my discussion of this on
python-dev in May under the title "fix float_hash and complex_hash for
64-bit *nix"
(2) The hash algorithms that use pointers (e.g. func_hash, code_hash)
are universally not correct on Win64 (they assume that sizeof(long) ==
sizeof(void*))
As well, this patch significantly cleans up the hash code. It adds the
two function _Py_HashDouble and _PyHash_VoidPtr that the various
hashing routine are changed to use.
These help maintain the hash function invariant: (a==b) =>
(hash(a)==hash(b))) I have added Lib/test/test_hash.py and
Lib/test/output/test_hash to test this for some cases.
Python on UNIX now trusts PYTHONHOME unconditionally
Modules/getpath.c:
Landmark changed to os.py.
Setting PYTHONHOME now unconditionally sets sys.prefix
(and sys.exec_prefix). No further checks are done whether the
standard lib can be found in that location or not. This is in
sync with the PC subdir getpath implementations.
PC/getpathp.c:
Landmark changed to os.py.
PC/os2vacpp/getpathp.c:
Landmark changed to os.py.
Note: BAW's checkin on exceptions.c eliminates earlier concerns about
a bogus PYTHONHOME value leading to a core dump. Instead it causes a
useless sys.path and prevents imports.
Tim Peters
Guido van Rossum
Mark Hammond
Trent Mick
Jeremy Hylton
Fredrik Lundh
Greg Ward
Thomas Wouters
Fred Drake