December 2002 - Wine-Devel - list.winehq.org

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Dan Kegel

Dan Kegel wrote: > I have a windows-free installation of current CVS wine, > with wordpad.exe and the needed DLLs pulled in from a Windows ME > installation. wordpad works great. However, > ShellExecute(... "wordpad.exe", ".\\stl\\readme.wri" ...) is failing to > find wordpad.exe for me. I just submitted a patch to wine-patches that fixes this. This is the first functionality I've ever contributed to Wine. (Six whole lines! :-) I also noticed that ShellExecute will sometimes try to run the executable "C:\\Program" (the first word of "C:\\Program Files\\whatever..."). I fixed that for the case I touched, I think, but didn't do a general fix. When we finally have a conformance test for ShellExecute, it should verify that it never tries to run the first space-terminated fragment of the program name as an executable! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 29, 2002

Re: PATCH: dlls/cabinet/cabextract.c and off_t

by Gerald Pfeifer

On Fri, 27 Dec 2002, Greg Turner wrote: >> Here we use off_t (which requires sys/types.h), that's why I wrote >> "If we really want to use off_t in this file. Should this simply >> become cab_off_t? > Bingo. [...] So, yes, this is most certainly an error on my part, and > your fix is likely the correct one. Out of curiosity, what is your > platform? I am slightly surprised that off_t compiles at all without > sys/types.h, even on linux... I was seeing this on FreeBSD; on GNU/Linux you probably don't see that because sys/types.h and others are implicitly #included by lots of other headers (which is somewhat non-standard, though not forbidden). > Would you be so kind as to change that to cab_off_t, and then run the > compile again to make sure that we've really eliminated all the off_t's > in there? Let me know your results and I will submit a patch including > this, and the renaming I discussed before. It works fine. I am submitting this to wine-patches, so that Alexandre can unbreak the build as soon as possible, though of course of full fix like the one you mentioned would be better. ;-) Thanks for working on this with me! Gerald Index: cabextract.c =================================================================== RCS file: /home/wine/wine/dlls/cabinet/cabextract.c,v retrieving revision 1.1 diff -u -3 -p -r1.1 cabextract.c --- cabextract.c 19 Dec 2002 21:16:56 -0000 1.1 +++ cabextract.c 29 Dec 2002 22:52:16 -0000 @@ -472,7 +472,7 @@ BOOL cabinet_read_entries(struct cabinet } fol->cab[0] = cab; - fol->offset[0] = base_offset + (off_t) EndGetI32(buf+cffold_DataOffset); + fol->offset[0] = base_offset + (cab_off_t) EndGetI32(buf+cffold_DataOffset); fol->num_blocks = EndGetI16(buf+cffold_NumBlocks); fol->comp_type = EndGetI16(buf+cffold_CompType);

Dec. 29, 2002

Re: Make RECT === RECTL, fix compile warnings, use uniform format

by Dan Kegel

Dimitrie O. Paun wrote: > On December 28, 2002 04:10 pm, Dan Kegel wrote: > >>Decided to leave debugrect for later, too much of a pain for now. >>This patch just uses a uniform format for RECTs where possible. >>It reorders three or so TRACEs that had the coordinates in >>nonstandard order, too. Patch against current CVS attached. >>Should compile fine, but I haven't tested it (so do look it over :-) > > > Cool stuff. Can you please turn this thing: > > Index: dlls/comctl32/datetime.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/datetime.c,v > retrieving revision 1.34 > diff -d -u -r1.34 datetime.c > --- dlls/comctl32/datetime.c 2 Dec 2002 18:11:00 -0000 1.34 > +++ dlls/comctl32/datetime.c 28 Dec 2002 20:43:22 -0000 > @@ -1098,7 +1098,7 @@ > infoPtr->rcClient.bottom = HIWORD(lParam); > infoPtr->rcClient.right = LOWORD(lParam); > > - TRACE("Height=%d, Width=%d\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); > + TRACE("Height=%ld, Width=%ld\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); > > /* use DrawEdge to adjust the size of rcEdge to get rcDraw */ > memcpy((&infoPtr->rcDraw), (&infoPtr->rcClient), sizeof(infoPtr->rcDraw)); > > Into a standard [(%ld,%ld)-(%ld,%ld)]? Aw, let's leave that for when we do the debugrect() conversion. Or you can do it if you like. I think I'm done with RECT changes for a while. I'm trying to fix ShellExecute now, seems higher priority... > As for debugrect(), it seems like half of the printed rectangles are > in commctrl, so what we can do is use debugrect() in there without having > to introduce any infrastructure changes. We can do that after Alexandre > commits this change, so we don't cram too much stuff into one patch. OK. Yes, let's keep this first patch simple. (BTW it might worth looking into a change to debugrect() to get its storage on the stack, in a local variable of the TRACE() macro. That'd avoid possible thread clashes (if you have too many threads, the current way debugrect() gets storage might break...)) -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 29, 2002

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Dan Kegel

Duane Clark wrote: >> ... the App Paths key is indeed being searched by SearchPath() > > That was done inside CreateProcessA (note the relay Call and Ret pair), > and at least at first glance, appears to be looking for the App Path key > for "ListV", which is the name of my test application. Oh. Right. Looks like the functionality implemented by http://www.winehq.com/hypermail/wine-patches/2002/02/0079.html is the *other* use of "App Paths" I found a few links that mention both uses: http://www.oreilly.com/catalog/win95nut/chapter/ch03.html http://www.geocities.com/completehackz/registry.html http://students.cs.byu.edu/~apippin/aim/aimfaq.htm http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html… Maybe I'll try to code up the missing functionity. Thanks for helping me think about this stuff. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 29, 2002

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Duane Clark

Dan Kegel wrote: > > 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(): > That was done inside CreateProcessA (note the relay Call and Ret pair), and at least at first glance, appears to be looking for the App Path key for "ListV", which is the name of my test application. I am note real sure what the NtQueryValueKey calls are doing though. I still think the problem is later on, in SHELL_FindExecutable. I think the registry checks here are "red herrings". Then again, I could be completely wrong about that ;) Probably the best way to determine that is to modify your simple program to call CreateProcess directly, and see what happens then. 08073208:Call kernel32.CreateProcessA(00000000,40582788 "wordpad.exe readme.txt",00000000,00000000,00000000,00000000,00000000,0040e4db "C:\\",40581eb8,40581ea8) ret=40c8d29f trace:process:CreateProcessA app (null) cmdline "wordpad.exe readme.txt" trace:process:find_exe_file looking for "wordpad.exe" trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths",f003f,0x4057e998) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe",f003f,0x4057e994) trace:reg:NtOpenKey <- (nil) trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x4057fdf0) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe\\DllOverrides",f003f,0x4057fdec) trace:reg:NtOpenKey <- (nil) trace:reg:NtQueryValueKey (0x14,L"wordpad.exe",2,0x4057fee4,80,22) trace:reg:NtQueryValueKey (0x14,L"*wordpad.exe",2,0x4057fee4,80,24) trace:reg:NtQueryValueKey (0x14,L"*",2,0x4057fee4,80,2) trace:process:find_exe_file Trying built-in exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe" trace:process:find_exe_file Trying native exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe" trace:process:find_exe_file looking for "wordpad.exe readme.txt" trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths",f003f,0x4057e998) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe",f003f,0x4057e994) trace:reg:NtOpenKey <- (nil) trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Wine\\Wine\\Config\\AppDefaults",f003f,0x4057fdf0) trace:reg:NtOpenKey <- 0x4c trace:reg:NtOpenKey (0x4c,L"ListV.exe\\DllOverrides",f003f,0x4057fdec) trace:reg:NtOpenKey <- (nil) trace:reg:NtQueryValueKey (0x14,L"wordpad.exe readme.txt",2,0x4057fee4,80,44) trace:reg:NtQueryValueKey (0x14,L"*wordpad.exe readme.txt",2,0x4057fee4,80,46) trace:reg:NtQueryValueKey (0x14,L"*",2,0x4057fee4,80,2) trace:process:find_exe_file Trying built-in exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe readme.txt" trace:process:find_exe_file Trying native exe "C:\\WINDOWS\\SYSTEM\\wordpad.exe readme.txt" 08073208:Ret kernel32.CreateProcessA() retval=00000000 ret=40c8d29f

Dec. 29, 2002

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Dan Kegel

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

Dec. 29, 2002

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Duane Clark

Duane Clark wrote: > > According to MSDN: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… > > CreateProcess should check several places for an application, none of > which include the registry key. So that call should fail, and it does. By the way, since many things are "inadvertently" left out of the MSDN, it might be worth testing whether that is really the way CreateProcess works on Windows. In fact, that would make a good test case to add to Wine, if you really wanted go for it.

Dec. 29, 2002

Re: Problem with ShellExecute and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

by Duane Clark

Dan Kegel wrote: > I have a windows-free installation of current CVS wine, > with wordpad.exe and the needed DLLs pulled in from a Windows ME > installation. wordpad works great. However, > ShellExecute(... "wordpad.exe", ".\\stl\\readme.wri" ...) is failing to find wordpad.exe for me. > (The call in question is issued by the msvc4.0 setup.exe. > The current directory when I run this is /mnt/cdrom, and stl/readme.wri is > indeed there.) Ignore the part about /usr/local/etc/system.reg. With a few more traces, I see the first attempt to execute, triggered by the execfunc at line 608 of ShellExecuteExA32. This is just a test to see if the command line can be executed as is. trace:exec:ShellExecuteExA32 mask=0x00000000 hwnd=(nil) verb="open" file="wordpad.exe" parm="readme.txt" dir="C:\\" show=0x00000005 class=not used trace:exec:ShellExecuteExA32 execute:'wordpad.exe','readme.txt' trace:exec:SHELL_ExecuteA Execute wordpad.exe readme.txt from directory C:\ 08073208:Call kernel32.CreateProcessA(00000000,40582788 "wordpad.exe readme.txt",00000000,00000000,00000000,00000000,00000000,0040e4db "C:\\",40581eb8,40581ea8) ret=40c8d29f trace:process:CreateProcessA app (null) cmdline "wordpad.exe readme.txt" trace:process:find_exe_file looking for "wordpad.exe" According to MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… CreateProcess should check several places for an application, none of which include the registry key. So that call should fail, and it does. 08073208:Ret kernel32.CreateProcessA() retval=00000000 ret=40c8d29f Next comes the test at line 614 of ShellExecuteExA32, which calls SHELL_FindExecutable. 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?

Dec. 29, 2002

Re: Regression in msvideo patch

by Eric Pouech

Stephen Mollett wrote: > Hi, > > [Following on from a thread on wine-users] > > I've had some problems recently with running the VirtualDub video > post-processing package on Wine. It used to work, but then stopped working > (it no longer displays the frame previews when seeking in a video file) > recently. > > I've done a regression test and narrowed the problem down to the patch > described in: > could yc could you send me the two traces (before and after the patch) with -debugmsg +msvideo... (if you have a large band connection - or you can put it on a server somewhere - having another pair of traces with -debugmsg +relay,+msvideo would be just fine) A+ -- Eric Pouech

Dec. 29, 2002

Re: Another Wine OSS hang-at-end-of-playback bug

by Eric Pouech

Matt Chapman wrote: > Thus the assumption is that, at beginning and end of playback, > info->fragstotal * info->fragsize == info->bytes, so that > wwo->dwPlayedTotal == wwo->dwWrittenTotal. > > But, for my soundcard (ymfpci driver), after asking for 15 frags * > 1024 bytes the situation is: > > fragments = 15, fragstotal = 18, fragsize = 1024, bytes = 15612 > > i.e. info->fragstotal * info->fragsize = 18432, info->bytes = 15612 > this sounds a bit crazy from the API point of view but if the driver is really implemented like this your patch would be fine. IMO, we should anyway add a comment for this behavior in the code so that we don't loose track of this interesting "feature" -- Eric Pouech

Dec. 29, 2002