From pranav.gadre at outlook.com Tue Dec 1 06:00:52 2020 From: pranav.gadre at outlook.com (Pranav Gadre) Date: Tue, 1 Dec 2020 11:00:52 +0000 Subject: [python-win32] How to copy an image using win32clipboard Message-ID: Hello, When we take a snip on windows OS, it automatically goes to clipboard. I want to access any copied image using win32clipboard. How do I do that? Please check this for more reference: Closed issue Thank you and pardon me for any missing things as I?m new to this mailing list. Regards, Pranav Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stimpy4516 at hotmail.com Tue Dec 1 09:10:09 2020 From: stimpy4516 at hotmail.com (Stimpy ******) Date: Tue, 1 Dec 2020 14:10:09 +0000 Subject: [python-win32] How to copy an image using win32clipboard In-Reply-To: References: Message-ID: Hi Pranav, Just resending this to the list. Here's a great resource: http://timgolden.me.uk/pywin32-docs/win32clipboard.html The document covers the win32clipboard module very well.The API you'll want to reference is the Win32 API. If you need to reference the protocol/steps in an even more verbose way, WinUser.h's MSDN pages' remarks section will fill any of those gaps. One such pearl is a warning about about clipboard data:? "Clipboard data is not trusted. Parse the data carefully before using it in your application." Tim's page does a good job with pointing you in the direction of getting more info about any of the given API functions. For example: https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getclipboarddata https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumclipboardformats Kind Regards, Adam B. Dodson From: python-win32 on behalf of Pranav Gadre Sent: Tuesday, December 1, 2020 6:00 AM To: python-win32 at python.org Subject: [python-win32] How to copy an image using win32clipboard ? Hello, ? When we take a snip on windows OS, it automatically goes to clipboard. I want to access any copied image using win32clipboard. How do I do that? Please check this for more reference: Closed issue Thank you and pardon me for any missing things as I?m new to this mailing list. Regards, Pranav ? Sent from Mail for Windows 10 ? From steven at manross.net Tue Dec 1 12:38:07 2020 From: steven at manross.net (Steven Manross) Date: Tue, 1 Dec 2020 17:38:07 +0000 Subject: [python-win32] How to copy an image using win32clipboard Message-ID: <9aff22e68a9748b789ec239e7eaaadea@manross.net> Based on reading http://timgolden.me.uk/pywin32-docs/win32clipboard__GetClipboardData_meth.html I would suggest that getting image data from the clipboard isn't implemented yet, but I do not know that for sure as I don't know when that document was updated. However, this python code seems to get text data just fine. import win32clipboard win32clipboard.OpenClipboard() var = win32clipboard.GetClipboardData() win32clipboard.CloseClipboard() print(var) I would also point out that it seems that the "CloseClipboard" is incredibly important as it seems that python takes an exclusive lock on the clipboard while the Clipboard is Opened. HTH Steven --------------- Date: Tue, 1 Dec 2020 11:00:52 +0000 From: Pranav Gadre To: "python-win32 at python.org" Subject: [python-win32] How to copy an image using win32clipboard Message-ID: Content-Type: text/plain; charset="windows-1252" Hello, When we take a snip on windows OS, it automatically goes to clipboard. I want to access any copied image using win32clipboard. How do I do that? Please check this for more reference: Closed issue Thank you and pardon me for any missing things as I?m new to this mailing list. Regards, Pranav From niko at pasanen.me Tue Dec 8 09:53:09 2020 From: niko at pasanen.me (Niko Pasanen) Date: Tue, 8 Dec 2020 16:53:09 +0200 Subject: [python-win32] win32process.CreateProcess: '%1 is not a valid Win32 application.' Message-ID: Hi all, I'm having some challenges using pywin32 to launch a 32-bit Windows application, but the tricky thing is that I cannot reproduce the problem on my machine or my coworkers (person B) machine, but only on some other persons' (person C) machine, so my changes to debug this are very rare & limited. The code that is not able to launch the exe is on Person C's computer ("testscript.py"): from pathlib import Path import win32process path_to_exe = Path(r"C:\path to some\folder\some.exe") (h_process, _, dw_process_id, _) = win32process.CreateProcess( None, # module name str(path_to_exe), # command line None, # Process handle not inheritable. None, # Thread handle not inheritable. 0, # Set handle inheritance to FALSE. 0, # Creation flags. None, # Use parent's environment block. str(Path(path_to_exe).parent), # If None - use parent's starting directory. win32process.STARTUPINFO(), ) # STARTUPINFO structure. You can see that there is only a simple call to win32process.CreateProcess. Here are the *combinations which do work*: 1) My machine & some.exe with win32process.CreateProcess 2) Person B & some.exe with win32process.CreateProcess 3) Person C & C:\Windows\system32\notepad.exe with win32process.CreateProcess 4) Person C & C:\Windows\SysWOW64\notepad.exe with win32process.CreateProcess 5) Person C & some.exe, launching directly by double-clicking So, for some reason Person C can launch some.exe without win32process.CreateProcess, and can launch 32-bit and 64-bit versions of notepad.exe with win32process.CreateProcess, *but launching some.exe with win32process.CreateProcess throws the error. *The some.exe is an old 32-bit app, which is not publicly available anywhere and of which source code I don't have. I've had time to debug with Person C to try to run the testscript.py with different versions of pywin32 (few latest), with a fresh install of Python 3.8.6 32-bit and also on a portable (WinPython) 3.7.x 32-bit, and it kept giving the same "%1 is not a valid Win32 application" error. PROCESS MONITOR logs ===================== I have also used the Process Monitor from Sysinternals to make a short recording with my machine on Person C's machine while running testscript.py. Here are the .dll/.pyd files (disregarding __init__ files) that were in the logs with at least once with "Result == SUCCESS". 1) The following DLLs on *both* machines with same path (mine & Person C) - "python.exe" PGHook.dll C:\Program Files (x86)\Avecto\Privilege Guard Client\PGHook.dll KernelBase.dll C:\Windows\SysWOW64\KernelBase.dll SHCore.dll C:\Windows\SysWOW64\SHCore.dll advapi32.dll C:\Windows\SysWOW64\advapi32.dll bcrypt.dll C:\Windows\SysWOW64\bcrypt.dll bcryptprimitives.dll C:\Windows\SysWOW64\bcryptprimitives.dll cfgmgr32.dll C:\Windows\SysWOW64\cfgmgr32.dll combase.dll C:\Windows\SysWOW64\combase.dll cryptbase.dll C:\Windows\SysWOW64\cryptbase.dll cryptsp.dll C:\Windows\SysWOW64\cryptsp.dll gdi32.dll C:\Windows\SysWOW64\gdi32.dll gdi32full.dll C:\Windows\SysWOW64\gdi32full.dll imm32.dll C:\Windows\SysWOW64\imm32.dll kernel.appcore.dll C:\Windows\SysWOW64\kernel.appcore.dll kernel32.dll C:\Windows\SysWOW64\kernel32.dll msvcp_win.dll C:\Windows\SysWOW64\msvcp_win.dll msvcrt.dll C:\Windows\SysWOW64\msvcrt.dll ntdll.dll C:\Windows\SysWOW64\ntdll.dll ole32.dll C:\Windows\SysWOW64\ole32.dll oleaut32.dll C:\Windows\SysWOW64\oleaut32.dll powrprof.dll C:\Windows\SysWOW64\powrprof.dll profapi.dll C:\Windows\SysWOW64\profapi.dll psapi.dll C:\Windows\SysWOW64\psapi.dll rpcrt4.dll C:\Windows\SysWOW64\rpcrt4.dll rsaenh.dll C:\Windows\SysWOW64\rsaenh.dll sechost.dll C:\Windows\SysWOW64\sechost.dll shell32.dll C:\Windows\SysWOW64\shell32.dll shlwapi.dll C:\Windows\SysWOW64\shlwapi.dll sspicli.dll C:\Windows\SysWOW64\sspicli.dll tzres.dll C:\Windows\SysWOW64\tzres.dll ucrtbase.dll C:\Windows\SysWOW64\ucrtbase.dll umpdc.dll C:\Windows\SysWOW64\umpdc.dll user32.dll C:\Windows\SysWOW64\user32.dll version.dll C:\Windows\SysWOW64\version.dll win32u.dll C:\Windows\SysWOW64\win32u.dll windows.storage.dll C:\Windows\SysWOW64\windows.storage.dll ws2_32.dll C:\Windows\SysWOW64\ws2_32.dll ntdll.dll C:\Windows\System32\ntdll.dll wow64.dll C:\Windows\System32\wow64.dll wow64cpu.dll C:\Windows\System32\wow64cpu.dll wow64win.dll C:\Windows\System32\wow64win.dll 2) The following DLLs with *different paths* (mine & Person C) - "python.exe" On my machine pywintypes37.dll C:\Windows\SysWOW64\pywintypes37.dll win32process.pyd C:\tmp\testfix\python\Lib\site-packages\win32\win32process.pyd python3.dll C:\tmp\testfix\python\python3.dll python37.dll C:\tmp\testfix\python\python37.dll vcruntime140.dll C:\tmp\testfix\python\vcruntime140.dll On Person C's machine pywintypes38.dll C:\Users\user\AppData\Local\Programs\Python\Python38-32\Lib\site-packages\pywin32_system32\pywintypes38.dll win32process.pyd C:\Users\user\AppData\Local\Programs\Python\Python38-32\Lib\site-packages\win32\win32process.pyd python3.dll C:\Users\user\AppData\Local\Programs\Python\Python38-32\python3.dll python38.dll C:\Users\user\AppData\Local\Programs\Python\Python38-32\python38.dll vcruntime140.dll C:\Users\user\AppData\Local\Programs\Python\Python38-32\vcruntime140.dll Seems that the DLLs listed here are essentially the same (also tested with the same Python 3.7 and actually the same dll's and wheels, too.) 3) The DLL's with that are loaded with "some.exe" (my PC only): PGHook.dll C:\Program Files (x86)\Avecto\Privilege Guard Client\PGHook.dll mfc42.dll C:\Users\me\OneDrive - Mycompany\Desktop\some\mfc42.dll CoreMessaging.dll C:\Windows\SysWOW64\CoreMessaging.dll CoreUIComponents.dll C:\Windows\SysWOW64\CoreUIComponents.dll KernelBase.dll C:\Windows\SysWOW64\KernelBase.dll SHCore.dll C:\Windows\SysWOW64\SHCore.dll TextInputFramework.dll C:\Windows\SysWOW64\TextInputFramework.dll WinTypes.dll C:\Windows\SysWOW64\WinTypes.dll advapi32.dll C:\Windows\SysWOW64\advapi32.dll bcrypt.dll C:\Windows\SysWOW64\bcrypt.dll bcryptprimitives.dll C:\Windows\SysWOW64\bcryptprimitives.dll cfgmgr32.dll C:\Windows\SysWOW64\cfgmgr32.dll combase.dll C:\Windows\SysWOW64\combase.dll cryptbase.dll C:\Windows\SysWOW64\cryptbase.dll cryptsp.dll C:\Windows\SysWOW64\cryptsp.dll gdi32.dll C:\Windows\SysWOW64\gdi32.dll gdi32full.dll C:\Windows\SysWOW64\gdi32full.dll iertutil.dll C:\Windows\SysWOW64\iertutil.dll imm32.dll C:\Windows\SysWOW64\imm32.dll kernel.appcore.dll C:\Windows\SysWOW64\kernel.appcore.dll kernel32.dll C:\Windows\SysWOW64\kernel32.dll msctf.dll C:\Windows\SysWOW64\msctf.dll msvcp_win.dll C:\Windows\SysWOW64\msvcp_win.dll msvcrt.dll C:\Windows\SysWOW64\msvcrt.dll ntmarta.dll C:\Windows\SysWOW64\ntmarta.dll ole32.dll C:\Windows\SysWOW64\ole32.dll oleaut32.dll C:\Windows\SysWOW64\oleaut32.dll powrprof.dll C:\Windows\SysWOW64\powrprof.dll profapi.dll C:\Windows\SysWOW64\profapi.dll rpcrt4.dll C:\Windows\SysWOW64\rpcrt4.dll rsaenh.dll C:\Windows\SysWOW64\rsaenh.dll sechost.dll C:\Windows\SysWOW64\sechost.dll shell32.dll C:\Windows\SysWOW64\shell32.dll shlwapi.dll C:\Windows\SysWOW64\shlwapi.dll sspicli.dll C:\Windows\SysWOW64\sspicli.dll tzres.dll C:\Windows\SysWOW64\tzres.dll ucrtbase.dll C:\Windows\SysWOW64\ucrtbase.dll umpdc.dll C:\Windows\SysWOW64\umpdc.dll user32.dll C:\Windows\SysWOW64\user32.dll uxtheme.dll C:\Windows\SysWOW64\uxtheme.dll win32u.dll C:\Windows\SysWOW64\win32u.dll windows.storage.dll C:\Windows\SysWOW64\windows.storage.dll wow64.dll C:\Windows\System32\wow64.dll wow64cpu.dll C:\Windows\System32\wow64cpu.dll wow64win.dll C:\Windows\System32\wow64win.dll comctl32.dll C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.18362.1198_none_bb60abf7ec91ff24\comctl32.dll These were alse accessed by some.exe but not found (on my machine): MFC42LOC.DLL C:\Windows\SysWOW64\MFC42LOC.DLL rpcss.dll C:\Windows\SysWOW64\rpcss.dll wow64log.dll C:\Windows\System32\wow64log.dll On person C's machine, I the Process Monitor did not have any logs from "some.exe", probably because it was not successfully launched *Question:* Is this somehow known behaviour or related to some bug in pywin32? How could I debug to find out what is the problem? As said, the debugging is difficult and must be done in well organized manner, since there are no problems on my computer, and I have to make appointments for testing anything. Regards, Niko Pasanen -------------- next part -------------- An HTML attachment was scrubbed... URL: From eryksun at gmail.com Tue Dec 8 17:35:54 2020 From: eryksun at gmail.com (Eryk Sun) Date: Tue, 8 Dec 2020 16:35:54 -0600 Subject: [python-win32] win32process.CreateProcess: '%1 is not a valid Win32 application.' In-Reply-To: References: Message-ID: On 12/8/20, Niko Pasanen wrote: > > path_to_exe = Path(r"C:\path to some\folder\some.exe") FYI, the constructor of pathlib.Path supports forward slash as the path separator, which avoids the need to use a raw string. A WindowsPath instance uses backslash when converting back to a string. > (h_process, _, dw_process_id, _) = win32process.CreateProcess( > None, # module name > str(path_to_exe), # command line Since you just have an executable path, pass it in lpApplicationName and leave lpCommandLine as None. This is simpler than manually quoting the path. If the string in lpCommandLine is an unquoted executable path, Windows will consume spaces in it until it finds a non-directory match. For example, if it's r"C:\path to\some folder\some.exe", it will use r"C:\path to\some" or r"C:\path to\some.exe" if either exists and is not a directory. If the matching file isn't a valid PE image, it does not continue parsing the command line to consume the next space as "some folder". It simply fails the call with ERROR_BAD_EXE_FORMAT. > 1) The following DLLs on *both* machines with same path (mine & Person C) > - "python.exe" ERROR_BAD_EXE_FORMAT occurs when mapping the executable image into the process VM during the NtCreateUserProcess system call. At this stage, no dependent DLLs are mapped into the process. That occurs after the process has already been created, during process initialization. If it were a dependent DLL problem, then CreateProcess would succeed, but the child process would abnormally terminate with a status code such as STATUS_INVALID_IMAGE_FORMAT (0xC000007B). From niko at pasanen.me Wed Dec 9 05:12:34 2020 From: niko at pasanen.me (Niko Pasanen) Date: Wed, 9 Dec 2020 12:12:34 +0200 Subject: [python-win32] win32process.CreateProcess: '%1 is not a valid Win32 application.' In-Reply-To: References: Message-ID: Dennis, Eryk, Thank you for your responses. The results for assoc and ftype are the same on my machine (should be tested on person C's pc, too). The space in filepath was one of my first guesses, but unfortunately I was not able to reproduce the error by putting a space in the filepath. But as Eryk you pointed out, there must be a file with a matching filename in order to get an error. This would explain why it is not reproducible. Here are some of my test results: Used test code =========== from pathlib import Path import win32process # from pywin32 (h_process, _, dw_process_id, _) = win32process.CreateProcess( None, # module name r"C:\tmp\first second\some.exe" , None, # Process handle not inheritable. None, # Thread handle not inheritable. 0, # Set handle inheritance to FALSE. 0, # Creation flags. None, # Use parent's environment block. None, # If None - use parent's starting directory. win32process.STARTUPINFO(), ) # STARTUPINFO structure. Test 1 ====== - Create broken exe with notepad (empty file) - Broken exe at: C:\tmp\first.exe (or C:\tmp\first without .exe) - Working exe at C\tmp\first second\some.exe -> The broken exe is found first: Traceback (most recent call last): File ".\testfix.py", line 5, in (h_process, _, dw_process_id, _) = win32process.CreateProcess( pywintypes.error: (193, 'CreateProcess', '%1 is not a valid Win32 application.') Test 2 ===== - Same as Test 1, but use quoted string as the lpCommandLine (r'"C:\tmp\first second\some.exe"') -> The C\tmp\first second\some.exe starts without problems. So the problem might be that on the Person C's computer, there is actually a file called "first" that is creating the error. The reason why I was using win32process.CreateProcess like this was that I'm actually using pywinauto, which uses win32process.CreateProcess. I'll have to still test this, but apparently this will fix some possible bugs. Thank you! - Niko -------------- next part -------------- An HTML attachment was scrubbed... URL: From eryksun at gmail.com Wed Dec 9 16:51:27 2020 From: eryksun at gmail.com (Eryk Sun) Date: Wed, 9 Dec 2020 15:51:27 -0600 Subject: [python-win32] win32process.CreateProcess: '%1 is not a valid Win32 application.' In-Reply-To: References:

Message-ID: On 12/9/20, Niko Pasanen wrote: > > So the problem might be that on the Person C's computer, there is actually > a file called "first" that is creating the error. The reason why I was > using win32process.CreateProcess like this was that I'm actually using > pywinauto, which uses win32process.CreateProcess. I'll have to still test > this, but apparently this will fix some possible bugs. Thank you! If you can't use lpApplicationName (preferred if the exact path is known) because you don't control the code, then just manually quote the executable path, e.g. pywinauto_call( f'"{exepath}"', ...). > The results for assoc and ftype are the same on my machine (should be tested > on person C's pc, too). The assoc and ftype commands have nothing to do with CreateProcess, so the suggestion to inspect them isn't particularly relevant. The only way the desktop shell's ".exe" file association might be relevant is if it's customized in some way to allow ShellExecuteEx to succeed even though CreateProcess on its own fails. The default association for ".exe" files defines a template command `"%1" %*`, which tells ShellExecuteEx to just call CreateProcess with the path of the executable and the command-line arguments. In theory the ".exe" association can be changed to proxy process creation with a launcher, but that would be a wonky thing to do, and it's not relevant to calling CreateProcess directly. FYI, assoc and ftype are old CMD shell builtin commands from NT 4.0 (1996) that get and set file associations and the "open" action of progids (f[ile]type program identifiers) in "HKLM\Software\Classes". These settings *might* be used by ShellExecuteEx. Nowadays these two commands are outdated and should not be relied on. "HKCU\Software\Classes" takes precedence, which these commands do not show. Numerous other registry keys for primary and fallback settings have also been added over the years, which these two commands also do not show. And, what's even more important is that the desktop shell was changed to cache and permanently store user choices separate from the default association selection algorithm. Cached choices and the pinned "UserChoice" are stored in "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\".