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.exeThanks for the --debugmsg +process tip (and I guess you also did relay?)!
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?
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...
--
Dan Kegel
Linux User #78045
http://www.kegel.com
