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

Re: Mac OS X Port of WineLib

by Eric Pouech

> -> WSControl / WSAIoctl need to be adapted to MacOS X. > (ioctl() calls can be platform dependent, /proc/net/dev > on linux is probably different on OSX) that'd be an issue if you need those features... Some folks (R Lunnon for example) face similar issues on Solaris > -> Debugger seems tied completely to Intel architecture. > (Since we will be using WineLib, we probably don't need > winedbg, can use gdb?) you can use gdb. regarding winedbg, there are (at least two ways) of using it: - either as a real debugger. porting this to an non Intel arch may require quite some work - using winedbg as a remote nub for gdb (winedbg -- -gdb). in this case, porting it to a non Intel processor should be pretty much more easy (there are a couple of #ifdef to implement in winedbg/gdbproxy.c to implement) A+ -- Eric Pouech

Dec. 29, 2002

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

by Dimitrie O. Paun

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)]? 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. -- Dimi.

Dec. 29, 2002

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

by Dan Kegel

I wrote: > OK, so then I copied my system.reg to /usr/local/etc/wine.systemreg. > Now it finds that key (!) but unfortunately, the only change is ... Editing error... that should be > OK, so then I copied my system.reg to /usr/local/etc/wine.systemreg. > Unfortunately, the only change is ... -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 29, 2002

Win98 Compliance Status

by Mathew McBride

I downloaded and ran the Wine Comformance tests from http://fgouget.free.fr/wine/winetests.zip Dr. Watson (drwatson.exe) was enabled advapi32_test.exe/registry crash DrWatson: The application overflowed its temporary memory area. Module Name: ADVAPI32_TEST.E Application Name: Advapi32_test.exe dsound_text.exe I don't have msvcrtd.dll (where can I get it) REQUEST: Is it possible to compile these tests using mingw32. gdi32_test.exe/generated 2786 tests executed, 0 marked as todo, 0 failures kernel32_test.exe/alloc alloc.c:208: Test failed: GlobalReAlloc failed to convert FIXED to MOVEABLE: err or=87 alloc.c:213: Test failed: Converting from FIXED to MOVEABLE didn't REALLY work alloc.c:238: Test failed: Discarded memory we shouldn't have alloc.c:239: Test failed: GlobalUnlock Failed. alloc: 58 tests executed, 0 marked as todo, 4 failures. kernel32_test.exe/atom atom.c:55:WARNING: Unicode atom APIs are not supported on this platform atom: 163850 tests executed, 0 marked as todo, 0 failures. kernel32_test.exe/codepage 2 tests executed, 0 marked as todo, 0 failures kernel32_test.exe/directory 25 tests executed, 0 todo, 0 failures kernel32_test.exe/drive 80 tests executed,0 todo, 0 failures kernel32_test.exe/environ 19 executed, 0 todo, 0 failures kernel32_test.exe/file file.c:631: Test failed: WriteFile error 183 file.c:632: Test failed: expected number of bytes written 0 file.c:633:Current offset = 0100 file.c:634: Test failed: expected file offset 21 file.c:639: Test failed: WriteFile error 87 file.c:640: Test failed: expected number of bytes written 0 file.c:642: Test failed: expected file offset 517 file.c:656: Test failed: ReadFile error 0 file.c:657: Test failed: expected number of bytes read 0 file.c:658:Current offset = 0000 file.c:659: Test failed: expected file offset 21 file.c:661: Test failed: pattern match failed file: 487224 tests executed, 0 marked as todo, 10 failures. kernel32_test.exe/format_msg 58 executed, 0 todo, 0 failures kernel32_test.exe/generated 609 executed, 0 marked as todo, 0 failures kernel32_test.exe/locale locale.c:499: Test failed: GetDateFormat check DATE_YEARMONTH with null format e xpected ERROR_INVALID_FLAGS got return of '10' and error of '0' /locale: 105 tests executed, 0 marked as todo, 1 failure. kernel32_test.exe/path path.c:881:TMP=C:\WINDOWS\TEMP path.c:892:TMP=C:\WINDOWS path.c:902:TMP=C:\ path.c:912:TMP=C: 1702 executed, 0 todo, 0 failures kernel32_test.exe/process tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. 116 executed, 0 todo, 0 failures kernel32_test.exe/thread thread.c:430: Test failed: SetThreadPriorityBoost Failed thread.c:432: Test failed: GetThreadPriorityBoost Failed thread.c:434: Test failed: SetThreadPriorityBoost Failed thread.c:436: Test failed: GetThreadPriorityBoost Failed 86 executed, 0 todo, 4 failures msvcrt_test.exe/file 2 executed, 0 todo, 4 failures msvcrt_test.exe/scanf 8 tests executed, 0 todo, 0 failures netapi32_test.exe access.c:174:It appears there is no netapi32 functionality on this platform same error reported by all netapi32 tests. ntdll_test.exe/error 813 executed, 0 todo, 0 failures ntdll_test.exe/generated 1279 executed, 0 todo, 0 failures ntdll_test.exe/rtlbitmap, ntdll_test.exe/rtlst 1 executed, 0 todo, 0 failures

Dec. 29, 2002

Re: Changing FS type reported by Wine

by Stephen Mollett

On Thursday 26 Dec 2002 23:24, Derek Broughton wrote: > I still don't see how, even > if you want to support all the third-party possibilities, it's possible > to have two files systems under one drive in Windows. On Windows 2000, it's possible to mount a FAT or FAT32 (or NTFS, of course) partition under an empty directory on an NTFS drive (Microsoft call it Mount Points; it's accessible from the disk administration MMC module - you can either assign a drive letter to a partition or mount it at a mount point or both). Stephen

Dec. 29, 2002

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

by Dan Kegel

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.) To get some insight on how this is supposed to work, I went to a real Windows Me system, searched the registry for references to "wordpad.exe", and removed them, one by one, testing after each deletion. The reference that mattered was [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE] @="C:\\Progra~1\\Access~1\\WORDPAD.EXE" So I ran "regedit foo.reg" to import the above registry key, and made sure it does show up in ~/.wine/system.reg. Still didn't work. I then ran wine --debugmsg +exec,+file,+reg setup.exe to see whether Wine was properly searching that registry key. Sure enough, Wine is trying to search that key, and it's not finding it. So... what's wrong? Best I can figure is there's something fishy about what registry file is being loaded. Here are the interesting bits of the log (word wrapped, unfortunately): --------------------- ... trace:reg:NtQueryValueKey (0x24,L"LoadWindowsRegistryFiles",2,0xbfffe7fc,1024) trace:reg:_w31_loadreg (void) trace:file:FILE_DoOpenFile reg.dat OF_READ OF_SHARE_COMPAT trace:file:FILE_DoOpenFile reg.dat 0000 trace:reg:NtOpenKey ((nil),L"Machine\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths",f003f,0xbfffbb08) trace:reg:NtOpenKey <- (nil) warn:file:FILE_DoOpenFile 'reg.dat' not found or sharing violation warn:file:FILE_DoOpenFile (reg.dat): return = HFILE_ERROR error= 2 trace:reg:NtQueryValueKey (0x24,L"LoadGlobalRegistryFiles",2,0xbfffe7fc,1024) trace:reg:NtQueryValueKey (0x24,L"GlobalRegistryDir",2,0xbfffe7fc,1024) trace:reg:SHELL_LoadRegistry GlobalRegistryDir is '/usr/local/etc'. warn:reg:_get_wine_registry_file_format_version Couldn't open /usr/local/etc/wine.userreg for reading: No such file or directory warn:reg:_get_wine_registry_file_format_version Couldn't open /usr/local/etc/wine.systemreg for reading: No such file or directory ... [snip] ... 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 <- (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 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 <- (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 trace:file:GetFileInformationByHandle 0xffffffff --------------------- OK, so then I copied my system.reg to /usr/local/etc/wine.systemreg. Now it finds that key (!) but unfortunately, the only change is that the line warn:reg:_get_wine_registry_file_format_version Couldn't open /usr/local/etc/wine.systemreg for reading: No such file or directory no longer shows up in the log. I'm pretty sure this is supposed to work, but I'm having trouble untangling it. Help would be greatly appreciated. If anyone's interested, I can send an executable that does the ShellExecute call in question so they can reproduce it themselves... Thanks, Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 29, 2002

Re: Regression in msvideo patch

by Duane Clark

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. It might also be worth mentioning that VirtualDub is a free download and under 1MB. With some initial tinkering, it at least plays mpegs great, though I really have not yet figured out how else to work it.

Dec. 29, 2002

File locking ... need info

by Mike Robinson

[Please reply e-mail; I don't yet subscribe.] I am interested in support for file-locking and locking of specified regions of a file, in order to support databases such as MS-Access and Paradox. But as I ponder the various likely-looking segments of the source-code, I really do not know where to begin ... nor what has been done in this area before. It is clear that an implementation of locking must work on SMB-shares and that it should "actually lock things" in that other Windows users should see the locks as they are placed and removed. It's also clear that implementing timeouts on these locks could be "problematic," since the Unix impl. of file locking is not quite the same as Windows expects. Pointers? Comments? War-stories? Advice? "Someone already did that"s?

Dec. 29, 2002

Re: Mac OS X Port of WineLib

by Marcus Meissner

On Thu, Dec 26, 2002 at 09:56:01PM -0500, ATMRD(a)aol.com wrote: > Hi, > I dont recall how I stumbled upon Wine and its existance, however I am > intersted in recent, if any, devlopments with the porting of Wine to OS X. I > checked the Wine site and most of the articles are dated with the lastest > date of Nov 2000. A lot has changed in OS X since that time and it appears > that a leats a couple of the main issues have been addressed during this > time. The main issues which seemed to be posted are as follows: I fixed the Linux/PowerPC port. So any PowerPC processor related issue is ok. > Current list of possible issues: > ================================ > -> Endianness. Since we are using WineLib, could > have resources written in native (big) endian format > with wrc. Any external data files such as cursors, bitmaps, sound > would have to be converted. The PUT_WORD/GET_WORD macros > need byte swapping turned off. (Did I miss anything?) Is ok. > -> Exception handling, Signal handling code Depends on MacOS X. > -> Memory alignment issues Should not be a problem. > -> According to "Inside MacOS X: Kernel Environment" > (<A HREF="http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf">http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf</A>) > pg. 34, Darwin supports Pthreads, "many of the POSIX APIs" > I haven't been able to find any lists of incompatibilities yet, > but I am afraid of the word "many". WINE needs a different kind of threading, this might be problematic. > -> Sound Support. Currently done with WineOSS (ties into > Linux OSS drivers) Doesn't seem to be a port of OSS > to MacOSX. Maybe need to do another layer specific to the > Mac(?) Err, we support audio drivers and have several others non-OSS already. No problem here, just implement a MacOS X sound driver. > -> Must ensure that behaviour of lower level UNIX resources > like sockets, threads, files are the way WINE expects it. This might be more difficult. Especially the memory management. > -> Presence of Assembly language in code will have to be written > in C or translated to PowerPC assembly. (assembly is generated > in spec.c files, as well as other places like in the server) Is done already, for the normal PPC32 ABI. Good luck. Ciao, Marcus

Dec. 28, 2002

Re: WinXP conformance test update

by Marcus Meissner

On Fri, Dec 27, 2002 at 05:57:18PM -0500, Dave Miller wrote: > These tests were run on Windows XP Professional using the latest > precompiled binaries. The results of any tests not listed on or not > matching http://fgouget.free.fr/wine/tests-en.shtml > C:\winetests>oleaut32_test.exe safearray > safearray.c:131: Test failed: SAC(20,1,[1,0]), result 8, expected 0 VT_I8 > safearray.c:131: Test failed: SAC(21,1,[1,0]), result 8, expected 0 VT_UI8 These results are different for Win2000, there it just returns 0. > safearray.c:131: Test failed: SAC(37,1,[1,0]), result 4, expected 0 > safearray.c:131: Test failed: SAC(38,1,[1,0]), result 4, expected 0 These have no VARTYPES in our wtypes.idl :/ Does anyone have reference to a newer idl reference? Ciao, Marcus

Dec. 28, 2002

Re: Make RECT identical to RECTL, fix compile warnings (resending)

by Dan Kegel

Dimitrie O. Paun wrote: > On December 27, 2002 01:29 pm, Dan Kegel wrote: > >>I think this patch touches every single TRACE >>statement that prints out a RECT. Many different >>formats are used... might be nice to standardize them >>sometime. ... > > Now that you've identified all these places, it seems to me > the perfect oportunity to standardise them. At the very least, > we should convert them all to a common format (say (x0,y0)-(x1,y1), > or anything you fancy) so we can more easily grep/sed for them > later. But I'd certainly prefer the debugrect() approach, provided > Alexandre accepts it. Note that some of these print out the corners, but others output one corner plus width and height. Will anyond mind terribly if we always just print out the corners? I think I'll start off by switching to the common format you suggest, and using just one macro to deal with arguments. e.g. RECT stuff[20]; ... TRACE("the 6th rect is (%ld,%ld)-(%ld,%ld)\n", RECT_LTRB(stuff+5)); That will make it trivial to switch to the debugrect() approach later, which as someone pointed out involves a bit more infrastructure work (because of the buffer it has to allocate). All we'll need is find . -name *.c | xargs perl -p -i.bak -e 's/(%ld,%ld)-(%ld,%ld)/%s/g' -e 's/RECT_LTRB/debugrect/g' Ok, off to do a little patch munging... I can resubmit the patch this weekend if I'm lucky. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 28, 2002

WinXP conformance test update

by David Miller

I noticed two tests were still missing information. Here are the results of those tests. C:\winetests>kernel32_test.exe file file.c:633:Current offset = 0015 file.c:658:Current offset = 0015 file: 487239 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe generated generated: 609 tests executed, 0 marked as todo, 0 failures.

Dec. 28, 2002

Re: Changing FS type reported by Wine

by Sylvain Petreolle

Why should we obey to all windows limitations ? Remember, Wine Is Not an Emulator. Other point, you can read&write on NTFS volumes using several tools as Ntfsdos from http://www.sysinternals.com > Surely from Windows p-o-v _no_ other return values should be > legitimate. > Can windows natively read any other types? I don't think so. > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas… > > Since it is hardcoded, I don't know how you would "set up new drive > > > letters for the specific file systems you needed." An option in > > ~/.wine/config, on the otherhand, would make this easy. > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 28, 2002

Re: Documentation work -task list -man pages

by Dimitrie O. Paun

On December 28, 2002 02:25 am, Tom Wickline wrote: > OK....... Fine with me can we just break this down to smaller task ? Of course, we must break it down further. It's just that I did not know how to do it, and I was hoping someone more familiar with the documentation will do it instead. -- Dimi.

Dec. 28, 2002

Re: DirectSound and i810 soundcards

by Ove Kaaven

On Sat, 28 Dec 2002, Francois Gouget wrote: > When DSound initializes it create a primary sound buffer and invokes > winmm to actually get access to a sound device. The default format of > the primary buffer is 22050x16x2 (i.e. 22050Hz, 16 bit sound, stereo). > This means the device it's going to get will be handled by msacm.drv > which will be responsible for performing the conversions on the fly. > > However during the primary buffer creation DSDB_MapPrimary gets invoked > in wineoss and does an mmap of the hardware sound buffer. > > So when we then play sound in a secondary sound buffer, this sound gets > mixed into the primary buffer, but because of the mmap this then goes > straight to the sound card with no further conversion. So you end up > with a chipmunk sound effect since you play a 22050x16x2 sound at > 48000x16x2. > > I will try to make more tests to confirm this but does it seem to make > sense? Should I look in some other direction? Any suggestion about a fix? I've been meaning to submit the winex wineoss modifications, but haven't got around to it yet, and it might be somewhat complicated by all the changes around it lately. But this particular issue doesn't take a big patch. Basically the 'true' sample rate should be propagated back to dsound, so that it knows that the primary buffer is 48kHz and can resample secondary buffers accordingly. No changes is needed to dsound for this, wineoss's wodOpen just need to modify its waveformat input parameter if the WAVE_DIRECTSOUND flag is present, then dsound will happily convert secondary buffers to that sample rate when mixing them into the primary buffer. (Primary buffers are different, but apps that writes directly into the primary buffer are few, and they should use GetFormat and resample on their own.)

Dec. 28, 2002