[issue5116] expose _CrtSetReportMode via the msvcrt module

Changes by Mark Hammond mhamm...@users.sourceforge.net: -- components: +Windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5116 ___ ___ Python

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond mhamm...@users.sourceforge.net added the comment: I created bug 5116 with a patch to expose CrtSetDebugMode via the msvcrt module. I didn't attach it to this patch as it doesn't address the fundamental point in this bug, just offers a workaround to reinstate the default if desired

[issue5075] bdist_wininst should not depend on the vc runtime?

Mark Hammond mhamm...@users.sourceforge.net added the comment: Checked into trunk as r69094; merged to release26-maint as r69095, py3k as r69096 and release30-maint as r69097. -- resolution: accepted - fixed status: open - closed ___ Python tracker

[issue5076] bdist_wininst fails on py3k

Mark Hammond mhamm...@users.sourceforge.net added the comment: Checked into py3k as r6998; merged to release30-maint as 69099. I hope I got that right! -- resolution: accepted - fixed status: open - closed ___ Python tracker rep...@bugs.python.org

[issue5076] bdist_wininst fails on py3k

Mark Hammond mhamm...@users.sourceforge.net added the comment: Is it really useful to be have the same stub for 2.x and 3.x? I think it would be better if they mutually ignore each other, and be different. Good question! I'm not really aware of the complexities involved in merging between

[issue5075] bdist_wininst should not depend on the vc runtime?

Mark Hammond mhamm...@users.sourceforge.net added the comment: Ironically I just received personal mail: I have downloaded pywin32_212 [2.6] three times today. the download completes successfully. but on running the pywin installer i repeatedly get an error. Attached is a screen-shot

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Changes by Mark Hammond mhamm...@users.sourceforge.net: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566 ___ ___ Python-bugs-list mailing list

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: ack - I mis-clicked and accidentally removed message78811 and can't see how to reinstate it. The message isn't critical, but I'm sorry about that! ___ Python tracker rep...@bugs.python.org http

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: Checked in to the trunk as as r69038 and svnmerge'd: * release26-maint as 69040 * py3k as 69041 * release30-maint as 69043 -- resolution: accepted - fixed status: open - closed ___ Python

[issue5075] bdist_wininst should not depend on the vc runtime?

Mark Hammond mhamm...@users.sourceforge.net added the comment: Thanks for the merging advice! The patch to the build system is indeed trivial - unfortunately it also failed to work correctly due to install.c using freopen, a CRT function, to redirect the output. Interestingly, this probably

[issue5076] bdist_wininst fails on py3k

Mark Hammond mhamm...@users.sourceforge.net added the comment: Attaching an updated patch against the py3k branch which makes no attempt to work on py2k. Added file: http://bugs.python.org/file12886/wininst_py3k.patch ___ Python tracker rep

[issue5075] bdist_wininst should not depend on the vc runtime?

New submission from Mark Hammond mhamm...@users.sourceforge.net: After consideration of issue 4120 and issue 4566, it seems to me that executables created by bdist_wininst will have a manifest referencing the MSVC9 assembly, and thus will be in a similar position to the .pyd files in issue 4120

[issue5076] bdist_wininst fails on py3k

New submission from Mark Hammond mhamm...@users.sourceforge.net: bdist_wininst installers created by py3k fail due to PySys_SetArgv and Py_SetProgramName both being passed 'char *' strings instead of wide strings. The patch is against the svn trunk as currently Python 2.x and 3.x share the same

[issue2563] embed manifest in windows extensions

Mark Hammond mhamm...@users.sourceforge.net added the comment: Given bug 4120, this seems the most appropriate resolution... -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond mhamm...@users.sourceforge.net added the comment: Martin, Would you be happier if this functionality was exposed via _msvcrt and disabled in the test suite (either globally or selectively)? Obviously this is still not thread-safe, but it is closer towards putting this behaviour

[issue4893] Use separate thread support code under MS Windows CE

Mark Hammond mhamm...@users.sourceforge.net added the comment: Early windows CE devices were very crippled, and IIRC, only the Unicode version of the API existed, and (also IIRC) this was well before Python had builtin unicode. I agree with Martin; it is probably worth investigating how much

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: I've hacked together something that fixes the problem. I'm working on making it a real patch, but the basis is: * In DllMain (dl_nt.c), we call: case DLL_PROCESS_ATTACH: GetCurrentActCtx(PyWin_DLLhActivationContext

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond mhamm...@users.sourceforge.net added the comment: It would be interesting to know which tests actually fail. If the tests are explicitly checking a bad fd, then IMO it makes more sense for that test to simply be avoided in debug builds and nothing of value would be left untested

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond mhamm...@users.sourceforge.net added the comment: I guess another option is to expose it via msvcrt and let the test themselves disable it? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4804

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: Attaching a patch which works for me against python 2.6. Only ever tested on Vista (ie, where the function pointers etc all load) -- keywords: +needs review, patch Added file: http://bugs.python.org/file12536/bug4566.patch

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Changes by Mark Hammond mhamm...@users.sourceforge.net: Removed file: http://bugs.python.org/file12536/bug4566.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: Attaching a new patch with some typos in the comments corrected. While I'm here, I also meant to mention (again!): * No need to remove the the assembly from the sxs cache - the test fails correctly with VS2009 installed. FWIW, I

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Changes by Mark Hammond mhamm...@users.sourceforge.net: Removed file: http://bugs.python.org/file12537/bug4566.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4566

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: Uploading a corrected patch; some old docs I saw said DWORD, and I obviously neglected to fix every spot I used that, and I've changed 'Vista' to 'XP' in the patch comments. Added file: http://bugs.python.org/file12549/bug4566.patch

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond mhamm...@users.sourceforge.net added the comment: Can anyone point me at a test that failed in this case? A quick look over winsig.c shows no asserts. I didn't compare the vs2005 crt source though, so its highly likely I just missed it... On the broader point, it could be argued

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: I've no time to dig deeper now as I suspect testing will require removal of the vc9 assembly from the GAC and testing with a local one, but some comments: test.c's error is can't find the DLL - this will be as we attempt to load

[issue4566] 2.6.1 breaks many applications that embed Python on Windows

Mark Hammond mhamm...@users.sourceforge.net added the comment: I meant to mention: FWIW, *some* py2exe apps work fine with the old scheme - specifically, IIUC, any app will work fine so long as the .pyd files were next to the executable, which is next to the assembly. I understand

[issue4804] Python on Windows disables all C runtime library assertions

New submission from Mark Hammond mhamm...@users.sourceforge.net: This block in exceptions.c: #if defined _MSC_VER _MSC_VER = 1400 defined(__STDC_SECURE_LIB__) ... /* turn off assertions in debug mode */ prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0); #endif Does exactly what

[issue4015] [patch] make installed scripts executable on windows

Mark Hammond [EMAIL PROTECTED] added the comment: I can see how this might be useful, but I agree it should not happen by default, at least until it has been out for a while and feedback is clear that people do want it by default. I'd also like to find a way to pass all args, not just the first

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

Mark Hammond [EMAIL PROTECTED] added the comment: I don't see a problem with this and can see how it would help with private assemblies. -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4120

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Mark Hammond [EMAIL PROTECTED] added the comment: I'm skeptical about adding build_data support, as it's not obvious what files would need conversion. All .py files should be converted. I can't think why a project would use this 2to3 capability for scripts and packages, but not .py files

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Mark Hammond [EMAIL PROTECTED] added the comment: Thinking more about data_files, I'd agree that blindly converting all .py files and nothing more isn't as useful for install_data as the other commands. It might make more sense to allow data_files to specify a list of patterns

[issue4091] python dll not installed in windows system directory

Changes by Mark Hammond [EMAIL PROTECTED]: -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4091 ___ ___ Python-bugs-list mailing list

[issue4072] build_py support for lib2to3 is stale

Mark Hammond [EMAIL PROTECTED] added the comment: r=me - thanks. -- keywords: -needs review resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4072

[issue1284316] Win32: Security problem with default installation directory

Changes by Mark Hammond [EMAIL PROTECTED]: -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1284316 ___ ___ Python-bugs-list mailing

[issue4072] build_py support for lib2to3 is stale

New submission from Mark Hammond [EMAIL PROTECTED]: The way build_py uses lib2to3 is out of date. Instead of a dummy Options object a dict should be used, and it seems the 'fixers' must explicitly be loaded. I'm afraid I don't have a specific patch as I don't have a good test case

[issue4073] distutils build_scripts and install_data commands need 2to3 support

New submission from Mark Hammond [EMAIL PROTECTED]: The distutils commands 'build_scripts' and 'install_data' both may end up installing .py files. Such .py file should be able tobe run through lib2to3 in the same way supported by build_py. pywin32 has ended up with something like: class

[issue4038] py3k error in distutils file_copy exception handlers

Mark Hammond [EMAIL PROTECTED] added the comment: r66806 on the py3k branch. -- assignee: - mhammond resolution: accepted - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4038

[issue4001] 2to3 does relative import for modules not in a package.

Mark Hammond [EMAIL PROTECTED] added the comment: I must be going crazy, but I can't see r66707 in the trunk, the py3k branch, or anywhere else in the svn tree. Can you please lend me a clue-stick? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org

[issue4038] py3k error in distutils file_copy exception handlers

New submission from Mark Hammond [EMAIL PROTECTED]: All the exception handlers i dustutils.file_utils._copy_file_contents() are of the form: |except os.error as e: |(errno, errstr) = e This fails to unpack the exception in py3k. I'm attaching a patch that uses exception attributes rather

[issue4001] 2to3 does relative import for modules not in a package.

New submission from Mark Hammond [EMAIL PROTECTED]: Create an empty directory with only 2 files, foo.py and bar.py, both exactly 1 line: foo.py: |from bar import bar bar.py: |bar = bar Running 2to3 results in the following patch for foo.py: -from bar import bar +from .bar import bar However

[issue2532] file that breaks 2to3 (despite being correct python)

Mark Hammond [EMAIL PROTECTED] added the comment: pywin32 has a number of files that break in this way - often files generated by h2py.py -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2532

[issue3994] import fixer misses some symbols

New submission from Mark Hammond [EMAIL PROTECTED]: The following source file: import _winreg _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, foo) results in the following patch: -import _winreg -_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, foo) +import winreg +winreg.OpenKey

[issue3892] bsddb: test01_basic_replication fails on Windows sometimes

Mark Hammond [EMAIL PROTECTED] added the comment: Actually, I've decided to leave it alone. The buildbots most recent failure was: test test_bsddb3 failed -- Traceback (most recent call last): File S:\buildbots\python\trunk.nelson-windows\build\lib\bsddb\test\test_replication.py, line 315

[issue3892] bsddb: test01_basic_replication fails on Windows sometimes

Mark Hammond [EMAIL PROTECTED] added the comment: We are seeing one more error almost identical to the one I fixed (even the method name is the same), but its at line 315 - this is the last error in the Windows buildbot! Please let me know if you would like me to make a similar fix to this line

[issue3892] bsddb: test01_basic_replication fails on Windows sometimes

Mark Hammond [EMAIL PROTECTED] added the comment: I instrumented the code a little. The error is happening because self.client_startupdone never gets set to True. This is supposed to be set in the client_startupdone() method. It expects an event type of db.DB_EVENT_REP_STARTUPDONE, but we see

[issue3892] bsddb: test01_basic_replication fails on Windows sometimes

Mark Hammond [EMAIL PROTECTED] added the comment: As discussed with Barry on #python-dev, I committed r66498 which skips the failing assertion on Windows and replaces it with some noise to stderr. Note that only that one assertion fails - the rest of the test passes on Windows. Also, Brett

[issue3772] logging module fails with non-ascii data

Changes by Mark Hammond [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11370/logging_encoding.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3772

[issue3625] test issues on 64bit windows

Mark Hammond [EMAIL PROTECTED] added the comment: Thanks. Checked into the trunk in r65986 -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3625

[issue3640] test_cpickle crash on AMD64 Windows build

Mark Hammond [EMAIL PROTECTED] added the comment: Sorry for the initial noise - your analysis is correct, mine was flawed :) Simple recursion to a depth of 1000 does work fine on a 64bit build. cpickle.patch does make test_cpickle pass for me. FWIW, find_recursionlimit.py now causes

[issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4.

Changes by Mark Hammond [EMAIL PROTECTED]: -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3566 ___ ___ Python-bugs-list mailing list

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Mark Hammond [EMAIL PROTECTED] added the comment: MAL: This was already discussed on the PSF members mailing list. Yeah, but not specifically about VS2008 which this bug seemed to be specifically targetting. FWIW, this appears like *less* of a problem for 2.6 than for 2.4 and 2.5

[issue3640] test_cpickle crash on AMD64 Windows build

New submission from Mark Hammond [EMAIL PROTECTED]: [from python-dev] I've found a recursion related crash in test_cpickle on 64bit builds. Specifically, the 'cPickleDeepRecursive' is causing a stack overflow, and the debugger tells me the actual recursion depth was 629 at the crash

[issue3640] test_cpickle crash on AMD64 Windows build

Changes by Mark Hammond [EMAIL PROTECTED]: -- assignee: - mhammond keywords: +64bit ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3640 ___ ___ Python

[issue3625] test issues on 64bit windows

Mark Hammond [EMAIL PROTECTED] added the comment: I forgot about sys.maxsize - that makes things much cleaner, and even means I don't need to skip the check for insane amounts of memory. If you think this is OK, please also specifically say if you approve for me to check it into trunk for 2.6

[issue3107] test_list uses unreasonable amounts of memory on 64-bit Linux

Mark Hammond [EMAIL PROTECTED] added the comment: It looks like I made a dupe at http://bugs.python.org/issue3625, where I reported the same thing on 64bit windows (and 2 other cases that I'd be interested to know if cause problems for you too...) -- nosy: +mhammond

[issue3625] test issues on 64bit windows

New submission from Mark Hammond [EMAIL PROTECTED]: A number of tests are designed to be skipped on 64bits, but they don't detect 64bit windows builds as 64bits. Also, test_bytes.test_repeat() assumes sys.maxint bytes can't be allocated, which isn't necessarily true on Win64. I'm attaching

[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer

Mark Hammond [EMAIL PROTECTED] added the comment: Obviously IANAL, but my reading of eula.txt included with VS9 seems less restrictive than the 2003 one. It has 2 clauses that seem relevant: * [you must] require distributors and external end users to agree to terms that protect it at least

[issue1505257] winerror module

Mark Hammond [EMAIL PROTECTED] added the comment: pywin32 has a 'winerror' module, which is (basically) a h2py generated module from the same header (although initially generated roughly a decade ago and hand-tweaked since then). Its unfortunate pywin32 still hasn't adopted a package approach

[issue2981] confusing action of struct.pack and struct.unpack with fmt 'p'

Mark Hammond [EMAIL PROTECTED] added the comment: What should struct.calcsize() do with a 'p' format string? -- nosy: +mhammond ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2981

[issue2745] Add support for IsWow64Process

Mark Hammond [EMAIL PROTECTED] added the comment: I'm not sure if that is suggesting MS had no reason to add that API function, or those reasons don't apply to users of Python, but as its clear there is significant resistance I'm rejecting this report. -- resolution: - rejected status

[issue2745] Add support for IsWow64Process

New submission from Mark Hammond [EMAIL PROTECTED]: As per a thread on python-dev, I offered to add sys.iswow64process. I'm attaching a patch that does this (including news, docs and tests). I'm adding Martin to the nosy list as he has expressed reservations (It sounds like clutter of the sys

[issue2581] Vista UAC/elevation support for bdist_wininst

Mark Hammond [EMAIL PROTECTED] added the comment: Checked in as r62636 -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2581

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

Mark Hammond [EMAIL PROTECTED] added the comment: For those trying to follow along at home: best I can tell we have 3 other issues on this: #1092502 and #1389051 are dupes of an initial bug, but the fix for those bugs caused regressions reported in this bug and in #2632. To try and reduce

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

Changes by Mark Hammond [EMAIL PROTECTED]: -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2601 __ ___ Python-bugs-list mailing list Unsubscribe

[issue2601] [regression] reading from a urllib2 file descriptor happens byte-at-a-time

Changes by Mark Hammond [EMAIL PROTECTED]: -- resolution: - duplicate __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2601 __ ___ Python-bugs-list mailing list

[issue1092502] Memory leak in socket.py on Mac OS X

Mark Hammond [EMAIL PROTECTED] added the comment: FYI, #2632 is tracking a regression caused by this change. -- nosy: +mhammond _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1092502

[issue2563] embed manifest in windows extensions

Mark Hammond [EMAIL PROTECTED] added the comment: Note that we are actually using the linker to *generate* the manifest (something linkers pre VC2005 couldn't do), so if we could tell the linker to skip that manifest generation and embed it directly in the DLL, it would certainly be easier

[issue1232947] non-admin install may fail (win xp pro)

Mark Hammond [EMAIL PROTECTED] added the comment: I can repro this too using python-2.6a2.msi - after selecting just for me on XP running as a non-admin user, I see an error message regarding permissions. On vista, I get an elevation prompt (and if I hit allow, installation proceeds as if I had

[issue2581] Vista UAC/elevation support for bdist_wininst

New submission from Mark Hammond [EMAIL PROTECTED]: The attached patch adds basic UAC support to bdist_wininst created installers. A new option '--user-access-control' has been added to bdist_wininst, which is written to the INI file read by the installer. The installer reads this value

[issue2563] embed manifest in windows extensions

New submission from Mark Hammond [EMAIL PROTECTED]: The move to vs2008 has caused .manifest files to be created next to distutils created extensions modules, rather than being embedded as recommended by Microsoft. See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx The attached

[issue2513] 64bit cross compilation on windows

Mark Hammond [EMAIL PROTECTED] added the comment: Checked in r62197, including the patch from Thomas. Note I expanded the patch to the distutils doc (noting you need to build Python itself for the target platform before it works) and added a short entry to Misc/NEWS -- resolution

[issue1753245] Add RegEnableReflectionKey and RegDisableReflectionKey

Mark Hammond [EMAIL PROTECTED] added the comment: Been sitting here for a while without comment, so: Sending_winreg.c Committed revision 62180. -- resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org

[issue2513] 64bit cross compilation on windows

Mark Hammond [EMAIL PROTECTED] added the comment: I'd like to keep this issue specifically about cross-compilation in the current tree, and while some of the other ideas may have merit, let's not bog this issue down with them unless they directly impact the patch. Does anyone have any comments

[issue2513] 64bit cross compilation on windows

Mark Hammond [EMAIL PROTECTED] added the comment: Hi Marc-Andre, The PCBuild/README.txt file has some info about compatibility with VS versions (but probably needs to say more about x64 builds). There is also talk about releasing Profile Guided Optimization built binaries, which does require

[issue2513] 64bit cross compilation on windows

New submission from Mark Hammond [EMAIL PROTECTED]: I've taken the liberty of adding Trent, Christian and Martin to the nosy list as I know they are actively, if reluctantly interested in this. This patch allows the distutils to cross-compile on Windows. It has been tested on x86 and amd64

[issue1763] Winpath module - easy access to Windows directories like My Documents

Mark Hammond added the comment: I'm not sure why the approach of load-em-all is being taken. Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that list will grow too much, but the implementation as specified prevents the user from using other facilities available via the API

[issue1455] VS2008, quick hack for distutils.msvccompiler

Changes by Mark Hammond: -- nosy: +mhammond __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1455 __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue542314] long file name support broken in windows

Mark Hammond added the comment: I can confirm the code in question was removed and that long filenames are possible in 2.5. Eg: import os p = ?\\ + os.getcwdu() for i in range(10): p = os.path.join(p, 'x' * 100) os.mkdir(p) os.stat(p) print len(p) I don't think Python should

<    1   2