Duane Clark wrote:
Ignore the part about /usr/local/etc/system.reg.
OK, but I am still curious what's going on there.
trace:process:CreateProcessA app (null) cmdline "wordpad.exe readme.txt"
CreateProcess should check several places for an application, none of which include the registry key. So that call should fail, and it does.
Agreed.
trace:exec:SHELL_FindExecutable wordpad.exe 08073208:Call kernel32.SearchPathA(0040e4db "C:\",40582548 "wordpad.exe",40ca9be7 ".exe",00000100,40581af0,00000000) ret=40c8d43a 08073208:Ret kernel32.SearchPathA() retval=00000000 ret=40c8d43a trace:exec:SHELL_FindExecutable xlpFile=,extension=(null) warn:exec:SHELL_FindExecutable Returning 31 - No association
That call should have passed. It returns early at line 203, because xlpFile and the extension, returned from SearchPathA are null. That appears to be where things broke. Even if that passed, it does not appear that a check for the "App Patch" key is being done here, and it looks to me like it should be.
Is that enough to get you going further?
Thanks for the --debugmsg +process tip (and I guess you also did relay?)!
But if you also add +reg, you'll see that the App Paths key is indeed being searched by SearchPath():
trace:exec:ShellExecuteA trace:exec:ShellExecuteExA32 mask=0x00000000 hwnd=0x10023 verb=(null) file="wordpad.exe" parm=".\stl\readme.wri" dir="." show=0x00000001 class=not used trace:exec:ShellExecuteExA32 execute:'wordpad.exe','.\stl\readme.wri' trace:exec:SHELL_ExecuteA Execute wordpad.exe .\stl\readme.wri from directory . trace:reg:NtOpenKey ((nil),L"Machine\Software\Microsoft\Windows\CurrentVersion\App Paths",f003f,0x4078ebcc) trace:reg:NtOpenKey <- 0x74 trace:reg:NtOpenKey (0x74,L"setup.exe",f003f,0x4078ebc8) trace:reg:NtOpenKey <- (nil) trace:reg:NtOpenKey ((nil),L"Machine\Software\Wine\Wine\Config\AppDefaults",f003f,0x40790040) trace:reg:NtOpenKey <- (nil) trace:reg:NtQueryValueKey (0x14,L"wordpad.exe",2,0x40790134,80) trace:reg:NtQueryValueKey (0x14,L"*wordpad.exe",2,0x40790134,80) trace:reg:NtQueryValueKey (0x14,L"*",2,0x40790134,80) trace:file:CreateFileW L"C:\WINDOWS\SYSTEM\wordpad.exe" GENERIC_READ FILE_SHARE_READ OPEN_EXISTING attributes 0x0 warn:file:CreateFileW Unable to get full filename from L"C:\WINDOWS\SYSTEM\wordpad.exe" (GLE 2) trace:exec:SHELL_FindExecutable wordpad.exe trace:exec:SHELL_FindExecutable xlpFile=,extension=(null) warn:exec:SHELL_FindExecutable Returning 31 - No association
So it's *supposed* to be implemented already, but the implementation is broken, maybe. See http://www.winehq.com/hypermail/wine-patches/2002/02/0079.html (I would have thought it belonged right in ShellExecute rather than SearchPath, but as long as it works, I guess it doesn't matter.)
Anyway, I reproduced the problem with a trivial C program, compiled it with msvc4.0's cl.exe from wine :-), and verified that the program works fine under Windows, but not under Wine.
Here's the source:
#include <stdio.h> #include <windows.h> main() { int h; h = ShellExecute(NULL, "open", "wordpad.exe", NULL, NULL, SW_SHOWNORMAL); printf("ShellExecute returns %d\n", h); }
The executable is at http://www.kegel.com/shelltext.tgz
I'd like to create a conformance test for ShellExecute to check this...