Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths
Dan Kegel
dank at kegel.com
Sun Dec 29 12:43:20 CST 2002
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...
--
Dan Kegel
Linux User #78045
http://www.kegel.com
More information about the wine-devel
mailing list