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

2009-01-02 Thread Mark Hammond
Mark Hammond 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 compiled

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

2009-01-02 Thread Mark Hammond
Changes by Mark Hammond : Removed file: http://bugs.python.org/file12537/bug4566.patch ___ Python tracker <http://bugs.python.org/issue4566> ___ ___ Python-bugs-list m

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

2009-01-02 Thread Mark Hammond
Mark Hammond 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.or

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

2009-01-02 Thread Mark Hammond
Mark Hammond 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 that if it is the

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

2009-01-09 Thread Mark Hammond
Mark Hammond 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 effort it is to get thread_nt.h

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

2009-01-13 Thread Mark Hammond
Mark Hammond 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 in the control of the app

[issue2563] embed manifest in windows extensions

2009-01-19 Thread Mark Hammond
Mark Hammond added the comment: Given bug 4120, this seems the most appropriate resolution... -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/

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

2009-01-26 Thread Mark Hammond
New submission from Mark Hammond : 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 - that unless the assembly is

[issue5076] bdist_wininst fails on py3k

2009-01-26 Thread Mark Hammond
New submission from Mark Hammond : 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 bdist_wininst

[issue5076] bdist_wininst fails on py3k

2009-01-27 Thread Mark Hammond
Mark Hammond 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 the various

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

2009-01-27 Thread Mark Hammond
Mark Hammond 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 of

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

2009-01-27 Thread Mark Hammond
Changes by Mark Hammond : ___ Python tracker <http://bugs.python.org/issue4566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/

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

2009-01-27 Thread Mark Hammond
Mark Hammond 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 <http://bugs.py

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

2009-01-27 Thread Mark Hammond
Mark Hammond 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 tra

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

2009-01-27 Thread Mark Hammond
Mark Hammond 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 means that if someone attempted

[issue5076] bdist_wininst fails on py3k

2009-01-27 Thread Mark Hammond
Mark Hammond 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 <http://bugs.python.org/issue5

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

2009-01-29 Thread Mark Hammond
Mark Hammond 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 <http://bugs.p

[issue5076] bdist_wininst fails on py3k

2009-01-29 Thread Mark Hammond
Mark Hammond 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 <http://bugs.python.org/

[issue5116] expose _CrtSetReportMode via the msvcrt module

2009-01-30 Thread Mark Hammond
New submission from Mark Hammond : In bug 4804, there is some debate about how desirable it is for Python to unconditionally disable all CRT assertions on Windows - however, there is agreement that exposing the ability to enable and disable these assertions via the msvcrt module is reasonable

[issue5116] expose _CrtSetReportMode via the msvcrt module

2009-01-30 Thread Mark Hammond
Changes by Mark Hammond : -- components: +Windows ___ Python tracker <http://bugs.python.org/issue5116> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

2009-01-30 Thread Mark Hammond
Mark Hammond 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. If there *was* ag

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

2009-01-31 Thread Mark Hammond
Mark Hammond added the comment: I believe your new patch suffers the same problem. Consider the blocks like: + /* turn off crt asserts on windows since we have no control over fd */ + Py_BEGIN_CRT_ERROR_HANDLING Py_BEGIN_ALLOW_THREADS size = write(fd, pbuf.buf

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

2009-02-01 Thread Mark Hammond
Mark Hammond added the comment: Fair enough - but assertions are still disabled while your "reference count" is >0, which is still while other arbitrary code is running. While I agree this is an improvement, I'm afraid I'm not playing close enough attention to under

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

2009-02-02 Thread Mark Hammond
Mark Hammond added the comment: > Python shouldn't (IMHO) crahs, even if you give bogus input to > python functions. But it doesn't actually crash does it? It throws an assertion dialog, which sucks when the machine is unattended - which is why it is a problem for the

[issue5182] str() on memoryview of bytearray failing on py3k

2009-02-07 Thread Mark Hammond
New submission from Mark Hammond : % py30 -c "str(memoryview(bytearray((1,2,3" Traceback (most recent call last): File "", line 1, in TypeError: __str__ returned non-string (type bytes) The expected behaviour is that a string representation be returned. --

[issue850997] mbcs encoding ignores errors

2009-02-14 Thread Mark Hammond
Mark Hammond added the comment: It is still present, but I'm not sure what problems can be seen due to this so can't comment on its desirability. It would also introduce a backwards compatability concern but I've not enough experience to know how much of a problem that would

[issue44078] Output relative path when using PurePath.relative_to

2021-05-08 Thread Mark Hammond
New submission from Mark Hammond : Comparing two paths, PurePath.relative_to fails with ValueError if the second path is not in the first. >>> Path('/a/b').relative_to('/a/b/c') Traceback (most recent call last): File "", line 1, in File "

[issue39631] Fix file association MIME type on Windows

2020-02-14 Thread Mark Hammond
Change by Mark Hammond : -- nosy: +mhammond ___ Python tracker <https://bugs.python.org/issue39631> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40740] Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7

2020-06-12 Thread Mark Hammond
Mark Hammond added the comment: Can we get this mentioned somewhere? Eg, https://www.python.org/downloads/release/python-390b3/ doesn't mention anything about minimum versions. https://www.python.org/downloads/windows/ also has prominent notices like "Note that Python 3.8.3rc1

[issue41526] Python 3.9.0rc1 "setup successful" dialog box overflow

2020-08-13 Thread Mark Hammond
Mark Hammond added the comment: Yes, while I appreciate the gesture, I am somewhat embarrassed these days - as you say, many others deserve this more than me these days. So please remove it. -- ___ Python tracker <https://bugs.python.

[issue41771] bdist_wininst doesn't execute postinstall script

2020-09-11 Thread Mark Hammond
New submission from Mark Hammond : install.c tries to dynamically load PyCFunction_New at https://github.com/python/cpython/blob/fb2718720346c8c7a0ad2d7477f20e9a5524ea0c/PC/bdist_wininst/install.c#L686 - however, since 3.8 this no longer exists - PyCFunction_New is a #define which calls

[issue41771] bdist_wininst doesn't execute postinstall script

2020-09-11 Thread Mark Hammond
Change by Mark Hammond : -- keywords: +patch pull_requests: +21265 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22210 ___ Python tracker <https://bugs.python.org/issu

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

2012-02-01 Thread Mark Hammond
Mark Hammond added the comment: ack - that is a really good point. IIRC it can be "*". I'll try and look at this over the next day or 2. -- ___ Python tracker <http://bugs.py

[issue13892] distutils handling of windows manifest isn't optimal

2012-02-03 Thread Mark Hammond
Mark Hammond added the comment: I thought this shouldn't be a problem - that as pythonxx.dll contains a manifest with the references and also contains hoops to ensure its "activation context" is used when loading dynamic modules, that things should work correctly. The scena

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

2012-02-03 Thread Mark Hammond
Mark Hammond added the comment: Actually, I think this is OK - the reference to the "x86" is in the tests and those tests don't actually perform a build, just check the manifest is detected and stripped (ie, the test should still work fine on 64bit boxes). Ideally the test c

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2012-02-03 Thread Mark Hammond
Mark Hammond added the comment: See also http://bugs.python.org/issue13038 - same exception but in a different content, but the underlying cause may be similar. -- nosy: +mhammond ___ Python tracker <http://bugs.python.org/issue8

[issue13938] 2to3 fails to convert types.StringTypes appropriately

2012-02-03 Thread Mark Hammond
New submission from Mark Hammond : test_types.py converts "types.StringTypes" to "str" - but types.StringTypes is a tuple, so expressions like "type(x) in type.StringTypes" fails after conversion with "TypeError: argument of type 'type' is not it

[issue8170] Wrong Paths for distutils build --plat-name=win-amd64

2012-02-26 Thread Mark Hammond
Mark Hammond added the comment: I don't quite understand how the order will be wrong. Which earlier entry is causing the problem? OTOH though, I also don't quite understand how the build would work at all if a 32bit Python is used to invoke distutils with --plat-name=win-amd64 as

[issue8170] Wrong Paths for distutils build --plat-name=win-amd64

2012-02-28 Thread Mark Hammond
Mark Hammond added the comment: Can't you just install a 64bit Python in a different directory and use that executable to build the 64bit installer? It seems less error prone and should work without manually copying stuff or changing any

[issue8170] Wrong Paths for distutils build --plat-name=win-amd64

2012-02-29 Thread Mark Hammond
Mark Hammond added the comment: Those instructions in section 5.4 do seem wrong. On first reading they imply that you need to start with a clean source tree on your 32bit Windows, then build the 64bit version of Python. So far so good. However, then you need to run python.exe - which must

[issue14302] Move python.exe to bin/

2012-03-16 Thread Mark Hammond
Mark Hammond added the comment: To clarify the second comment from Eric: it is actually the first of the proposals that I consider controversial - moving where python.exe lives (regardless of to where) will break 3rd party tools. If a decision was made to move it anyway, then renaming

[issue14302] Move python.exe to bin/

2012-03-16 Thread Mark Hammond
Mark Hammond added the comment: Tools that use the registry will typically look up the InstallPath key and look for python.exe there. They will not look in sub-directories (except some may look in PCBuild and PCBuild/amd64). It is exactly those tools I'm concerned

[issue33944] Deprecate and remove pth files

2018-07-01 Thread Mark Hammond
Mark Hammond added the comment: pywin32, up until recently, just listed 3 directories in its .pth file - these were for directories which pre-dated packages and were never converted. Eg, "import win32api" actually loads win32api.pyd from the "site-packages/win32" dire

[issue18491] Add "exe wrapper" functionality to Windows launcher

2013-07-18 Thread Mark Hammond
Mark Hammond added the comment: I don't understand the motivation for this - how will it be used in practice? -- ___ Python tracker <http://bugs.python.org/is

[issue18491] Add "exe wrapper" functionality to Windows launcher

2013-07-18 Thread Mark Hammond
Mark Hammond added the comment: Obviously I'm missing a little context, but it seems a little wrong for the same launcher to be doing this double-duty. It seems we only want to use the launcher in this way as it already has some of the interesting code we need - but the vast majori

[issue18491] Add "exe wrapper" functionality to Windows launcher

2013-07-19 Thread Mark Hammond
Mark Hammond added the comment: Vinay's idea makes sense to me. Paul can also subtly change the patch such that when SCRIPT_WRAPPER is defined, failure to find the wrapper is fatal and prints a message specific to this fact rather than just starting an interactive Python (assuming I rea

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

2012-06-26 Thread Mark Hammond
Changes by Mark Hammond : -- nosy: +mhammond ___ Python tracker <http://bugs.python.org/issue1677> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15321] bdist_wininst installers may terminate with "close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr"

2012-07-10 Thread Mark Hammond
New submission from Mark Hammond : Note the error message in the title is only for Python 2.x - Python 3.x shows an empty string instead, but otherwise seems identical. This was first brought to my attention via http://sourceforge.net/tracker/?func=detail&aid=352&group_id=78

[issue15751] Support subinterpreters in the GIL state API

2012-08-28 Thread Mark Hammond
Mark Hammond added the comment: The GIL state api was mainly interested in the case of a thread which has (possibly) never been seen before calling into Python. IIUC, the proposal here is so that a thread that *has* been seen before can be associated with a thread-state specified by the

[issue15751] Support subinterpreters in the GIL state API

2012-08-28 Thread Mark Hammond
Mark Hammond added the comment: To clarify, I wrote: > can be associated with a thread-state specified by the > embedding application Where I meant to say: Can be associated with an interpreter state and corresponding thread-state ... Or something like that - it's been a while

[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers

2014-04-26 Thread Mark Hammond
New submission from Mark Hammond: Python 3.3 and earlier have in methodobject.c: /* PyCFunction_New() is now just a macro that calls PyCFunction_NewEx(), but it's part of the API so we need to keep a function around that existing C extensions can call. */ #undef PyCFunctio

[issue19141] Windows Launcher fails to respect PATH

2013-10-03 Thread Mark Hammond
Mark Hammond added the comment: > I am trying to draw attention to the situation where the script has no > shebang line, and there is no other explicit configuration info for > py.exe. In that case, the user should just type "python scriptname.py" - py.exe is for cases wh

[issue1602] windows console doesn't print or input Unicode

2014-09-23 Thread Mark Hammond
Mark Hammond added the comment: > The crash you see is maybe not a crash at all. I'd call it a "crash" - the repl shouldn't exit. But it's not necessarily part of *this* bug. -- ___ Python tracker <h

[issue14302] Rename Scripts directory to bin and move python.exe to bin

2014-02-28 Thread Mark Hammond
Mark Hammond added the comment: I get the impression the first link just punted and the second supports the fact many people would see it as an improvement. So a patch that both works and addresses the concerns would probably be most welcome

[issue1386675] _winreg specifies EnvironmentError instead of WindowsError

2009-03-20 Thread Mark Hammond
Mark Hammond added the comment: oops - this slipped off my radar. I agree with *both* Frederic and Tony :) The module promises to raise an EnvironmentError, which is does. However, the main killer from my POV is that a 'winerror' attribute is likely to be of interest, and th

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

2009-04-01 Thread Mark Hammond
Mark Hammond added the comment: > It could also point to a "python launcher", which reads the first line What would that first line look like on Windows? o:\src\python-2.6-svn\PCBuild\python.exe would be appropriate for my machine, but I wouldn't really be happy with

[issue5731] bdist_wininst no longer works on non-Windows platforms

2009-04-09 Thread Mark Hammond
Mark Hammond added the comment: +1 on the idea - it's not the first time I've forgotten that works on platforms other than Windows. It appears the patch you attached is reversed though (or its just way too early for me...) -- ___ Pyth

[issue1109963] bdist_wininst ignores build_lib from build command

2009-04-23 Thread Mark Hammond
Mark Hammond added the comment: So it looks like I broke the ability to override --build-lib :( Without testing, I think you might also need to handle the cross-compile case - the version may be the same, but the platform different. I know distutils is a PITA so might make this difficult, but

[issue5799] Change ntpath functions to implicitly support UNC paths

2009-05-05 Thread Mark Hammond
Mark Hammond added the comment: Should the DeprecationWarning for splitunc be a PendingDeprectionWarning for 3.1 and get 'upgraded' in 3.2? -- ___ Python tracker <http://bugs.python.

[issue5799] Change ntpath functions to implicitly support UNC paths

2009-05-05 Thread Mark Hammond
Mark Hammond added the comment: This looks good to me. My take on Guido's earlier notes are that they caused a problem in practice, and the philosophical concerns added justification for removing it. I'm yet to meet a Windows user with a philosophical objection to this. I'm

[issue5799] Change ntpath functions to implicitly support UNC paths

2009-05-06 Thread Mark Hammond
Mark Hammond added the comment: Checked into the trunk as r72387 (after normalizing whitespace in ntpath.py after the precommit-hook failed). Thanks Larry and Eric! -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue6132] Implement the GIL with critical sections in Windows

2009-06-01 Thread Mark Hammond
Changes by Mark Hammond : -- nosy: +mhammond ___ Python tracker <http://bugs.python.org/issue6132> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8870] --user-access-control=force produces invalid installer on Vista

2010-06-01 Thread Mark Hammond
Mark Hammond added the comment: Is it possible the installer is being run from a network share? A comment from PC/bdist_wininst/install.c: // interesting failure scenario that has been seen: initial executable // runs from a network drive - but once elevated, that network

[issue8929] wininst: msvcr90 dependency in x64 build

2010-06-06 Thread Mark Hammond
Mark Hammond added the comment: A quick check of my tree shows that the 32 and 64 bit versions are the same in this regard - the raw stubs wininst-9.0.exe and wininst-9.0-amd64.exe do not depend on the CRT. A test install of 2.6.5-amd64, then using the 64bit versoion of 'depends

[issue8954] wininst regression: errors when building on linux

2010-07-12 Thread Mark Hammond
Mark Hammond added the comment: With the caveat that I haven't tested it (I'm currently traveling), the patch looks good to me. -- ___ Python tracker <http://bugs.python.

[issue459007] Document sys.path on Windows

2010-07-16 Thread Mark Hammond
Mark Hammond added the comment: FWIW, I think the rules are fairly well explained in the comments in PC/getpathp.c; last time I looked at this, the only thing I couldn't really decide was where in the official docs these comments should be put (after reformatting and minor rewordin

[issue27417] Call CoInitializeEx on startup

2016-06-29 Thread Mark Hammond
Mark Hammond added the comment: I've a few reservations here: * CoInitialize will load a number of COM DLLs into the process, which isn't free and will have some memory and performance costs for programs that don't use COM. I see around 10 such DLLs loaded. * pythoncom uses s

[issue27417] Call CoInitializeEx on startup

2016-06-30 Thread Mark Hammond
Mark Hammond added the comment: > > This may well break things like pythonwin until they also grow support > > for the new param > I expect that, which is why I'm only proposing it for 3.6 onwards. While > adding support for a new major version of Python should be f

[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer

2016-07-04 Thread Mark Hammond
Mark Hammond added the comment: While I agree the risk is fairly low and it will require effort to actually do, it still sounds worth fixing at some point. A user might be tricked into downloading a DLL - eg, Firefox will happily save it without any scary UI - it's just a file. Later the

[issue17290] pythonw - loading cursor bug when launching scripts

2013-02-25 Thread Mark Hammond
Mark Hammond added the comment: The problem is that Explorer displays the IDC_APPSTARTING icon when an app launches, until that app does something ui-ish (eg, creating a window, fetching a windows message). I could reproduce the problem on XP, and pushed a fix for the launcher to https

[issue17290] pythonw - loading cursor bug when launching scripts

2013-02-25 Thread Mark Hammond
Mark Hammond added the comment: If anyone would like to test the fix out, I've put a 32bit pyw.exe with the fix at http://starship.python.net/crew/skippy/downloads/pyw.exe -- ___ Python tracker <http://bugs.python.org/is

[issue1602] windows console doesn't print or input Unicode

2015-01-20 Thread Mark Hammond
Mark Hammond added the comment: > File redirection has nothing to do with win-unicode-console Thank you, that comment is spot on - there are multiple issues being conflated here. This bug is purely about the tty/console behaviour. -- ___ Pyt

[issue25148] Windows registry PythonCore key changed inconsistent with other releases

2015-12-19 Thread Mark Hammond
Mark Hammond added the comment: > The original naming ("3.5") can't be used because you can't > simultaneously install 32-bit and 64-bit per-user Pythons with the same > key name. They will be in different nodes - the 32bit version would be under Wow6432Node. The

[issue25148] Windows registry PythonCore key changed inconsistent with other releases

2015-12-19 Thread Mark Hammond
Mark Hammond added the comment: > and the launcher was actually updated to match the registry key > directly, rather than special-casing the "-32" suffix It appears this has broken the launcher. A freshly-built py.exe from Python 3.5 doesn't seem to find older 32bit versio

[issue25148] Windows registry PythonCore key changed inconsistent with other releases

2015-12-21 Thread Mark Hammond
Mark Hammond added the comment: It appears bdist_wininst wasn't updated for this so installed created by distutils don't work in 32bit versions - is there a different bug open for that? (Or I'm doing something wrong, but the installer fails and a quick scan of the source

[issue25921] project files for wininst-14.0*.exe don't exist

2015-12-21 Thread Mark Hammond
New submission from Mark Hammond: Revision 34b35aa1967d pushed new versions of wininst-14.8*.exe, but didn't include the VS project files required to build it, thus meaning it can't reasonably be built from the source tree. -- components: Build messages: 256823 nosy

[issue25921] project files for wininst-14.0*.exe don't exist

2015-12-21 Thread Mark Hammond
Mark Hammond added the comment: Awesome, thanks, sorry I missed that. -- ___ Python tracker <http://bugs.python.org/issue25921> ___ ___ Python-bugs-list mailin

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

2016-01-09 Thread Mark Hammond
New submission from Mark Hammond: The launcher was recently updated to look in PCBuild/win32 to support the win32 binaries being built in this directory instead of the top-level PCBuild directory. However, when this new launcher tries to find a binary for, say, Python 2.7, it doesn't fi

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

2016-01-09 Thread Mark Hammond
New submission from Mark Hammond: Binaries created by bdist_wininst fail on 3.5+ for 2 reasons: * The built binary links against the DLL version of the CRT. This means the binary will typically fail to start as the CRT DLL isn't found. * When looking for 32bit Python versions, it fai

[issue26070] Launcher fails to find in-place built binaries from earlier Python versions

2016-01-09 Thread Mark Hammond
Mark Hammond added the comment: > When is the launcher ever going to find Python built in-place? On the machine that built Python in-place :) I have a dev environment where all Python versions and pywin32 are built and that's the environment where py.exe is failing. My build scr

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

2016-01-10 Thread Mark Hammond
Mark Hammond added the comment: > Mark said the "built binary links against the DLL version of the CRT > but I just checked in 3.5.1 that you actually didn't switch that > one to link against vcruntime140.dll like you did with everything else Yeah, I didn't dig too mu

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

2016-01-10 Thread Mark Hammond
Mark Hammond added the comment: > > The directory of the DLL can be added to the search path if you > > use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an > > absolute path. > That sounds like the better fix then. I thought there was something

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

2016-01-11 Thread Mark Hammond
Mark Hammond added the comment: welp, I hadn't actually tested the patch on x64 yet ;) > #ifdef WIN_64 should read: > #ifdef _WIN64 WIN_64 is a Python invented name and this stub doesn't Python pull the headers in... -- ___ Pytho

[issue27966] PEP-397 documents incorrect registry path

2016-09-05 Thread Mark Hammond
New submission from Mark Hammond: Received via email: PEP-397 (PEP 397 -- Python launcher for Windows) says: """ The launcher installation is registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\SharedDLLs with a reference counter. """ There

<    1   2