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