summaryrefslogtreecommitdiffstats
path: root/PC
Commit message (Collapse)AuthorAgeFilesLines
* Prevent possible buffer overflow exploits under Windows. As per (the very ↵Mark Hammond2000-10-071-9/+30
| | | | quick) patch Patch #101801.
* Remove some debugging messages - although this code is a complete hack, we ↵Mark Hammond2000-10-051-2/+2
| | | | dont need to announce it to the world every time they use freeze!
* Enable the binascii module for Win64. It builds and passes the test suite.Trent Mick2000-10-041-3/+1
| | | | | | (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.)
* Patch for [ Bug #113828 ] getpythonregpath with null data in registry keyMark Hammond2000-09-101-8/+14
| | | | | | If there was a NULL registry key, Python could barf. Also wraps some surrounding lines to 80 chars.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-013-28/+0
| | | | This should match the situation in the 1.6b1 tree.
* add user-modifiable recursion_limitJeremy Hylton2000-08-311-7/+0
| | | | | | | | | | | 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
* Registered modules could only exist in HKEY_LOCAL_MACHINE - now ↵Mark Hammond2000-08-221-3/+12
| | | | HKEY_CURRENT_USER can override.
* From Rene Liebscher:Mark Hammond2000-08-151-9/+146
| | | | | | | | | | | | | | 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. ****
* Patch #101032, from David Bolen:Mark Hammond2000-08-141-2/+5
| | | | Ensure the "proxied" command's return code bubbles back up.
* -- from Trent Mick: [Patch #101010] replace use of INT_PTRFredrik Lundh2000-08-071-2/+2
| | | | with uintptr_t (fix MSVC 5.0 build)
* Pragmas that instruct the linker to link against python20.lib (orGreg Ward2000-08-051-2/+4
| | | | | python20_d.lib) only active on MSVC++; different library formats needed for different compilers, and it's handled by the Distutils anyways.
* Allow any object supporting the buffer protocol to be written as a binary ↵Mark Hammond2000-07-281-7/+11
| | | | object.
* ANSIfication: remove very-old-varargs code, fix function declarations soThomas Wouters2000-07-223-4/+4
| | | | they include prototypes.
* Miscelaneous ANSIfications. I'm assuming here 'main' should take (int,Thomas Wouters2000-07-228-107/+92
| | | | | char**) and return an int even on PC platforms. If not, please fix PC/utils/makesrc.c ;-P
* Spelling fixes supplied by Rob W. W. Hooft. All these are fixes in eitherThomas Wouters2000-07-161-1/+1
| | | | | | | | | | 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 ;)
* Add "exceptions" to list of built-in modules for the sake ofGuido van Rossum2000-07-121-0/+1
| | | | | | sys.builtin_module_names. (Noticed by Toby Dickenson.) [Tim, please test!]
* - win95/98 helper for new os.popen codeFredrik Lundh2000-07-091-0/+60
| | | | | | this should be built as a console application (link with USER32.LIB), and installed in the same directory as the Python DLL.
* - removed barry's workaround, to make room forFredrik Lundh2000-07-081-30/+0
| | | | bill's more complete solution.
* - this is a tentative checkin of the #100764 patch (byFredrik Lundh2000-07-081-5/+37
| | | | | | | | 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.
* Squash signed-vs-unsigned warning. Also edits to bring into lineTim Peters2000-07-031-14/+33
| | | | with Python coding stds (max line length, C-style comments).
* Checked in a wrong version.Tim Peters2000-07-021-2/+2
|
* The example_nt directory was old enough to vote. Frank StajanoTim Peters2000-07-024-419/+152
| | | | | | | | | | | | | | | | 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!).
* Change copyright notice - 2nd try.Guido van Rossum2000-06-304-24/+0
|
* Change copyright notice.Guido van Rossum2000-06-304-88/+28
|
* Only include <basetsd.h> for VC 6.0 and higher.Guido van Rossum2000-06-301-0/+2
|
* As Neil Schemenauer points out, WITH_CYCLE_GC should be uncommented ifGuido van Rossum2000-06-301-1/+1
| | | | we want to have GC enabled in the beta.
* [*** Not tested as I don't have Windows running right now! ***]Fred Drake2000-06-302-4/+24
| | | | | | | | | | | | | | | 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.
* Python's .lib is now named Python20.libMark Hammond2000-06-301-2/+2
|
* Trivial commit to test Windows CVS capabilities.Guido van Rossum2000-06-301-2/+2
|
* final patches from Neil Schemenauer for garbage collectionJeremy Hylton2000-06-302-0/+9
|
* Bump version to 2.0b1. Change copyright to BeOpen, CNRI, SMC.Guido van Rossum2000-06-291-4/+4
|
* This patch extends PC/config.h and configure.in as appropriate forFred Drake2000-06-291-10/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* This patch addresses two main issues: (1) There exist some non-fatalFred Drake2000-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | 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.
* Finish converting the winreg extension to _winreg.Fred Drake2000-06-291-1474/+0
|
* Update the module name to _winreg, pending checkin of Paul Prescod'sFred Drake2000-06-291-3/+3
| | | | OO wrapper for this module.
* Trent Mick: familiar simple Win64 patchesGuido van Rossum2000-06-282-9/+8
|
* Changed the #error to a #warning when checking gcc versions, andFred Drake2000-06-281-1/+1
| | | | noted the minimum recommended version in the message.
* Patch from Rene Liebscher <R.Liebscher@gmx.de>, slightly modified andFred Drake2000-06-191-0/+8
| | | | | commented by Fred Drake, to prevent usage of sufficiently broken GCC versions.
* Cleanup a few docstrings.Mark Hammond2000-06-092-30/+34
|
* Patch from M.-A. Lemburg:Jeremy Hylton2000-05-262-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Trent Mick:Guido van Rossum2000-05-101-1/+4
| | | | | | | | | | | | | | Use "win32" for sys.platform on Win64 instead of "win32" because: 1. While it may be confusing to the Python scriptor on Win64 that he has to check for win*32*, that is something that he will learn the first time. It is better than the alternative of the scriptor happily using "win64" and then that code not running on Win32 for no good reason. 2. The main question is: is Win64 so much more like Win32 than different from it that the common-case general Python programmer should not ever have to make the differentiation in his Python code. Or, at least, enough so that such differentiation by the Python scriptor is rare enough that some other provided mechanism is sufficient (even preferable). Currently the answer is yes. Hopefully MS will not change this answer.
* Trent Mick:Guido van Rossum2000-05-081-3/+17
| | | | | | The following modules are specifically excluded in the Win64 build: audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit dependent. [They should probably be fixed! --GvR]
* Trent Mick:Guido van Rossum2000-05-081-23/+57
| | | | | | | | | | | | | | | | | | | | Changes to PC\config.[hc] for Win64. MSVC defines _WINxx to differentiate the various windows platforms. Python's MS_WINxx are keyed off of these. Note that _WIN32 (and hence MS_WIN32 in Python) are defined on Win32 *and* on Win64. This is for compatibility reasons. The idea is that the common case is that code specific to Win32 will also work on Win64 rather than being specific to Win32 (i.e. there is more the same than different in WIn32 and Win64). The following modules are specifically excluded in the Win64 build: audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit dependent. [They should probably be fixed! --GvR] The patch to config.h looks big but it really is not. These are the effective changes: - MS_WINxx are keyed off _WINxx - SIZEOF_VOID_P is set to 8 for Win64 - COMPILER string is changed appropriately for Win64
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-032-10/+14
| | | | | | | | | | For more comments, read the patches@python.org archives. For documentation read the comments in mymalloc.h and objimpl.h. (This is not exactly what Vladimir posted to the patches list; I've made a few changes, and Vladimir sent me a fix in private email for a problem that only occurs in debug mode. I'm also holding back on his change to main.c, which seems unnecessary to me.)
* Add definition of socklen_t so that socketmodule.c will compile on Windows.Guido van Rossum2000-04-241-0/+3
|
* Mark Hammond:Guido van Rossum2000-04-212-3/+10
| | | | | | | | | | | * Base address for all extension modules updated. PC\dllbase_nt.txt also updated. Erroneous "libpath" directory removed for all projects. * winsound module moved from a builtin module to an extension module. This was done primarily to avoid Python16.dll needing to pull in winmm.dll. Really dumb test added for winsound - but if nothing else it ensures the module imports.
* Remove _socket, select, soundex, and unicodedata. These have beenGuido van Rossum2000-04-061-10/+0
| | | | moved to their own DLLs, or are obsolete (soundex).
* Get rid of Win32s check.Guido van Rossum2000-04-041-17/+1
|
* Seems there was a version string here that still looked like 1.5.2.Guido van Rossum2000-03-301-2/+2
|
* Revamped path access again, by Mark Hammond, to be more robust in theGuido van Rossum2000-03-301-91/+193
| | | | | | | | | | | light of three different situations: (1) running from build; (2) running from installed; (3) running without being able to find an installation (e.g. as a COM object). The system paths in the repository are only used for (3); the path deduced from the installation location are used otherwise. PYTHONHOME overrides in all cases. Read the comments for more details.