0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xff9aaaf4 (nil)) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 100"
????? !!!!
ahh fer xxxx's sake :)
this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80.
0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec10000 L"C:\windows\system32\cmd.exe" 0010:trace:heap:RtlFreeHeap (0x110000,00000002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec10000 type #0018 name #0001 lang 0000 level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x110000,00000002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (L"C:\windows\system32\cmd.exe.manifest",0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xffdc5f14 (nil))
... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be "themed".
... wossgoinon?! :)
l.
2009/1/22 Luke Kenneth Casson Leighton lkcl@lkcl.net:
0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xff9aaaf4 (nil)) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 100"
????? !!!!
ahh fer xxxx's sake :)
this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80.
0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec10000 L"C:\windows\system32\cmd.exe" 0010:trace:heap:RtlFreeHeap (0x110000,00000002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec10000 type #0018 name #0001 lang 0000 level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x110000,00000002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (L"C:\windows\system32\cmd.exe.manifest",0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xffdc5f14 (nil))
... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be "themed".
cmd.exe *may* have a manifest, it's just that it won't specify common controls v6 (which enables the theming code in >= XP). For example, patch.exe and install.exe in cygwin have .manifest files to tell Vista "I am *not* an installer!".
... wossgoinon?! :)
When Wine (or Windows >= XP) loads a process (exe or dll), it looks for a .manifest file in the folder where the exe is located. If it does not find one there, it looks for a RT_MANIFEST resource in the processes resource block. Failing that, it assumes that the process was not built with a manifest. NOTE: I'm not sure on the ordering of the check for a manifest file (i.e. which takes precedence -- external file or embedded resource).
In the trace log above, you can see that Wine is checking for an embedded manifest resource first, then the external .manifest file.
So the problem lies elsewhere... do you have any more information on the debug output?
- Reece
On Thu, Jan 22, 2009 at 6:59 PM, Reece Dunn msclrhd@googlemail.com wrote:
2009/1/22 Luke Kenneth Casson Leighton lkcl@lkcl.net:
0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xff9aaaf4 (nil)) attr=00000000 sharing=00000001 disp=1 options=00000010 ea=(nil).0x00000000 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 100"
????? !!!!
ahh fer xxxx's sake :)
this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80.
0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec10000 L"C:\windows\system32\cmd.exe" 0010:trace:heap:RtlFreeHeap (0x110000,00000002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec10000 type #0018 name #0001 lang 0000 level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x110000,00000002,00000060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x110000,00000002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (L"C:\windows\system32\cmd.exe.manifest",0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (L"C:\windows\system32\cmd.exe.manifest" 520 0xffdc5f14 (nil))
... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be "themed".
cmd.exe *may* have a manifest, it's just that it won't specify common controls v6 (which enables the theming code in >= XP). For example, patch.exe and install.exe in cygwin have .manifest files to tell Vista "I am *not* an installer!".
... wossgoinon?! :)
When Wine (or Windows >= XP) loads a process (exe or dll), it looks for a .manifest file in the folder where the exe is located. If it does not find one there, it looks for a RT_MANIFEST resource in the processes resource block. Failing that, it assumes that the process was not built with a manifest. NOTE: I'm not sure on the ordering of the check for a manifest file (i.e. which takes precedence -- external file or embedded resource).
In the trace log above, you can see that Wine is checking for an embedded manifest resource first, then the external .manifest file.
So the problem lies elsewhere... do you have any more information on the debug output?
hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it:
http://lkcl.net/subprocess.wine.trace
it's a trace+all so is about 15mb (sorry!)
i'm doing a rebuild back to msvcrt to see if the problem goes away.
reproducing this in c-code will be quite a bit of work - it's not like the other tests i did (the msvcrt ones) - it'll be about... 150 to 200 lines of c code, doing a CreateProcess and other tricks, and would take about a day to go through the python code, replicating the python subsytems being used _without_ the python.
and this is getting pretty draining - it's been a _lot_ of work.
l.
So the problem lies elsewhere... do you have any more information on the debug output?
hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it:
it's a trace+all so is about 15mb (sorry!)
i'm doing a rebuild back to msvcrt to see if the problem goes away.
http://lkcl.net/subprocess.wine.trace.msvcrt.native
and, once that's uploaded, i'll also do one:
http://lkcl.net/subprocess.wine.trace.msvcrt.builtin
but give me a few mins to do that one, it'll be there in a bit.
here's the python application that did that:
import subprocess
p = subprocess.Popen(["cmd", "/k" "echo", "hello"], stdout=subprocess.PIPE) (stdout, stderr) = p.communicate() print repr(stdout) print repr(stderr)
nice and short, isn't it? :)
the code that goes with that - in the python subprocess module - is a bit of a lairy hairy bundle of fun.
anyway, as you can see, open_osfhandle and CreateProcess all go swimmingly well - it's just that when you get msvcr80 involved it all goes pearshaped.
l.
On Thu, Jan 22, 2009 at 8:14 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
So the problem lies elsewhere... do you have any more information on the debug output?
hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it:
it's a trace+all so is about 15mb (sorry!)
i'm doing a rebuild back to msvcrt to see if the problem goes away.
sorry that's ... oh bugger it i'll log in to my server and correct it :)
and, once that's uploaded, i'll also do one:
anyway, as you can see, open_osfhandle and CreateProcess all go swimmingly well - it's just that when you get msvcr80 involved it all goes pearshaped.
ahh... correction... err... actually, builtin msvcrt _doesn't_ go according to plan!
the data is returned (echo hello) but the python process hangs - it never sees the results come back.
ahh xxxx-it i'm going to have to write a c test case, aren't i.
ahh... correction... err... actually, builtin msvcrt _doesn't_ go according to plan!
the data is returned (echo hello) but the python process hangs - it never sees the results come back.
correction: the reason for that was that my test case had "cmd /k echo test" not "cmd /c echo test".
so i needed to type "exit" return.
so, we conclude that the child process creation code using msvcrt is fine but with msvcr80 is buggered. i've found a test example (KB Q190351) which does a reaaasonable job - reading from the console of the child doesn't work.
so the code from Q190351 would be a _good_ one to use.
or write a test case based on Modules/posixmodule.c.
-
Luke Kenneth Casson Leighton -
Reece Dunn