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. 28, 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. 28, 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

Regression in msvideo patch

by Stephen Mollett

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: http://www.winehq.com/hypermail/wine-cvs/2002/11/0187.html Before this patch (2002-11-20 13:47:00 CST), frame preview works normally in VirtualDub. Afterwards, vdub crashes when seeking. Later cvs versions don't crash but don't display frames either. The console output from Wine includes: fixme:msvideo:DrawDibRealize (0x1, 0x8f4, 0), stub just once before a load of messages similar to: fixme:psapi:EnumProcessModules (hProcess=0xffffffff, 0x425cf000, 4096, 0x405c0038) fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x400000, "", 65212): stub fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x425e0000, "", 65212): stub fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x78000000, "", 65212): stub ... when a crash occurs; the later non-crashing versions just display loads of messages similar to the first one about DrawDibRealize. If you like, I can try to track down when the crashing behaviour changed to simple non-drawing. Regards, Stephen

Dec. 28, 2002

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

by Matt Chapman

Hi, I'm seeing some apps hang after playing an audio sample (even after the latest fix from Eric Pouech/Dan Kegel). I've tracked it down to the following. dwBufferSize is calculated from info->fragstotal * info->fragsize: wwo->dwBufferSize = info.fragstotal * info.fragsize; whereas dwPlayedTotal is calculated using info->bytes: wwo->dwPlayedTotal = wwo->dwWrittenTotal - (wwo->dwBufferSize - info->bytes); 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 Thus dwPlayedTotal never reaches dwWrittenTotal and the last buffer never gets marked as done. Using info->bytes for wwo->dwBufferSize does fix my problem, not sure if there's a better solution. Matt [Looking at the driver, it looks like the difference is a safety margin to stop the DSP when it reaches the end. Arguably the driver should just report 15 in fragstotal and not bother applications with the detail that its buffer is actually 18 frags in size...] Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.68 diff -u -r1.68 audio.c --- dlls/winmm/wineoss/audio.c 15 Dec 2002 02:59:13 -0000 1.68 +++ dlls/winmm/wineoss/audio.c 28 Dec 2002 09:56:46 -0000 @@ -1357,7 +1357,7 @@ /* Remember fragsize and total buffer size for future use */ wwo->dwFragmentSize = info.fragsize; - wwo->dwBufferSize = info.fragstotal * info.fragsize; + wwo->dwBufferSize = info.bytes; wwo->dwPlayedTotal = 0; wwo->dwWrittenTotal = 0; wwo->bNeedPost = TRUE;

Dec. 28, 2002

DirectSound and i810 soundcards

by Francois Gouget

There is a problem with Directsound and i810 soundcards. The test I just sent to wine-patches illustrates it very well. Basically sounds are being played too fast. Here's my understanding of the problem (if my memory and understanding of the logs is correct): 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? If you have an i810 soundcard you can reproduce by doing the following: * apply "Add WINETEST_INTERACTIVE" from wine-patches * apply "Add 'audiophile' DirectSound tests" from wine-patches * cd dlls/dsound/tests * make * WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c (you can also set WINETEST_DEBUG=2 to get more debug info about the test's buffer management, though this is probably not relevant here) Alternately, you can download the latest Windows test binaries from my site (http://fgouget.free.fr/wine/winetests.zip) and run them using Wine, or on Windows: set WINETEST_INTERACTIVE=1 dsound_test dsound Actually I would be interested in the results of this test on Windows: * the test tone is usually played three times. Are all three, and especially the first one, at the right pitch? * what is the output of the test? I'm interested in reported capabilities as stated by Windows and Wine for instance (to determine whether the primary buffer is emulated for instance). * what is the primary buffer's default format? 22050x16x2? (that's not supported by the sound card!) * does the winmm test work? set WINETEST_INTERACTIVE=1 winmm_test wave * in particular, what happens when the test tone is played with WAVE_FORMAT_DIRECT on Windows? (except Win9x platforms which don't support that flag) -- Francois Gouget fgouget(a)codeweavers.com

Dec. 28, 2002

Fwd: Get rid of W->A calls: GetPrinterDriverDirectory (2nd)

by Stefan Leichter

Hello Alexandre, why is this patch still waiting to be applied? If something is wrong please tell it loud on the mailing list. Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Fwd: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sat, 21 Dec 2002 09:52:30 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-devel(a)winehq.com Hello, is there any reason why this patch did not made it into CVS & 20021219? Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sun, 15 Dec 2002 10:24:44 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-patches(a)winehq.com Hello, after spending some days fixing the read-write errors on my DDYS-T18350 disk here a new patch Changelog ------------ moved implementation of GetPrinterDriverDirectory from ascii to unicode Index: dlls/winspool/info.c =================================================================== RCS file: /home/wine/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 15 Dec 2002 08:40:09 -0000 @@ -41,6 +41,7 @@ #include "winbase.h" #include "winerror.h" #include "winreg.h" +#include "winternl.h" #include "wine/windef16.h" #include "wine/unicode.h" #include "wine/debug.h" @@ -2390,23 +2391,23 @@ } /*************************************************************************** ** - * GetPrinterDriverDirectoryA [WINSPOOL.@] + * GetPrinterDriverDirectoryW [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { DWORD needed; - TRACE("(%s, %s, %ld, %p, %ld, %p)\n", pName, pEnvironment, Level, - pDriverDirectory, cbBuf, pcbNeeded); + TRACE("(%s, %s, %ld, %p, %ld, %p)\n", debugstr_w(pName), + debugstr_w(pEnvironment), Level, pDriverDirectory, cbBuf, pcbNeeded); if(pName != NULL) { - FIXME("pName = `%s' - unsupported\n", pName); + FIXME("pName = `%s' - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } if(pEnvironment != NULL) { - FIXME("pEnvironment = `%s' - unsupported\n", pEnvironment); + FIXME("pEnvironment = `%s' - unsupported\n", debugstr_w(pEnvironment)); SetLastError(ERROR_INVALID_ENVIRONMENT); return FALSE; } @@ -2414,10 +2415,16 @@ WARN("Level = %ld - assuming 1\n", Level); /* FIXME should read from registry */ - needed = GetSystemDirectoryA(pDriverDirectory, cbBuf); + needed = GetSystemDirectoryW( (LPWSTR)pDriverDirectory, cbBuf/sizeof(WCHAR)); + /* GetSystemDirectoryW returns number of TCHAR without '\0' + * adjust this now + */ needed++; + needed*=sizeof(WCHAR); + if(pcbNeeded) *pcbNeeded = needed; + TRACE("required <%08lx>\n", *pcbNeeded); if(needed > cbBuf) { SetLastError(ERROR_INSUFFICIENT_BUFFER); return FALSE; @@ -2427,25 +2434,41 @@ /*************************************************************************** ** - * GetPrinterDriverDirectoryW [WINSPOOL.@] + * GetPrinterDriverDirectoryA [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { - LPSTR pNameA = NULL, pEnvironmentA = NULL; + UNICODE_STRING nameW, environmentW; BOOL ret; - - if(pName) - pNameA = HEAP_strdupWtoA( GetProcessHeap(), 0, pName ); - if(pEnvironment) - pEnvironmentA = HEAP_strdupWtoA( GetProcessHeap(), 0, pEnvironment ); - ret = GetPrinterDriverDirectoryA( pNameA, pEnvironmentA, Level, - pDriverDirectory, cbBuf, pcbNeeded ); - if(pNameA) - HeapFree( GetProcessHeap(), 0, pNameA ); - if(pEnvironmentA) - HeapFree( GetProcessHeap(), 0, pEnvironmentA ); + DWORD pcbNeededW; + INT len = cbBuf * sizeof(WCHAR)/sizeof(CHAR); + WCHAR *driverDirectoryW = NULL; + + if (len) driverDirectoryW = HeapAlloc( GetProcessHeap(), 0, len ); + + if(pName) RtlCreateUnicodeStringFromAsciiz(&nameW, pName); + else nameW.Buffer = NULL; + if(pEnvironment) RtlCreateUnicodeStringFromAsciiz(&environmentW, pEnvironment); + else environmentW.Buffer = NULL; + + ret = GetPrinterDriverDirectoryW( nameW.Buffer, environmentW.Buffer, Level, + (LPBYTE)driverDirectoryW, len, &pcbNeededW ); + if (ret) { + ret = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + pDriverDirectory, cbBuf, NULL, NULL); + *pcbNeeded = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + NULL, 0, NULL, NULL); + } else + *pcbNeeded = pcbNeededW * sizeof(CHAR)/sizeof(WCHAR); + + TRACE("provided<%ld> required <%ld>\n", cbBuf, *pcbNeeded); + + if(driverDirectoryW) + HeapFree( GetProcessHeap(), 0, driverDirectoryW ); + RtlFreeUnicodeString(&environmentW); + RtlFreeUnicodeString(&nameW); return ret; } ------------------------------------------------------- -------------------------------------------------------

Dec. 28, 2002

Re: Documentation work -task list -man pages

by Tom Wickline

Dimitrie O. Paun wrote: > On December 26, 2002 05:31 pm, Tony Lambregts wrote: > >>I think that we should keep the documentation tasks togetther. If its OK >>with Dimi we can just use his page and give him diffs or we can split >>off the documentation section and he can link to it. > > > I am more than OK with it, I think it's the way to go. Having the TODO > split in 1000 places defeats the purpose of having a TODO list in the > first place. Moreover, look at the other TODOs: they don't change that > often... :) OK....... Fine with me can we just break this down to smaller task ? One huge task is a bit overwhelming to a would be helper. And if this was broke down to smaller task more people might want to take over a small manageable task IMHO. Tom

Dec. 28, 2002

Re: Changing FS type reported by Wine

by Derek Broughton

Greg Turner wrote: > On Thursday 26 December 2002 10:35 am, Derek Broughton wrote: > >>Duane Clark wrote: >> >>>Derek Broughton wrote: >>> >>>>Windows which _doesn't_ understand the concept of different file >>>>systems under a single drive. >> >>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. > > > Hmm, perhaps not out of the box, but surely, what with reparse-points, > DFS, "offline files", hard-links, and other such features, it's not so > simple as "fs(root)==fs(arbitrary_subdir(root)) && fs(root) in [fat, > ntfs]" in all cases, is it? And then there is support for netware, > appletalk, and even nfs.... > > Also, itsn't it totally possible, even limiting ones self to documented > functionality in the DDK, to produce 3rd-party FS drivers and install > them (note, that I didn't say easy :) )? The above just covers what > you can get from Microsoft... For example, doesn't Oracle provide some > FS driver (or perhaps they gave up on that plan...)? > > Regardless, I don't see anything wrong with the current approach, which > could be extended to support NTFS, or some new driver. Getting the > emulated FS type from the native FS type seems like a limitation more > than a feature to me... or am I missing the idea of this? > Tony seemed to think it was more difficult. 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.

Dec. 28, 2002

Re: Wine Contrib 0.6

by Tom Wickline

Francois Gouget wrote: > On Fri, 27 Dec 2002, Dimitrie O. Paun wrote: > > >>Folks, >> >>A new version of Wine-Contrib is available at: >> http://www.dssd.ca/wine/Wine-Contrib-0.6.html >>courtesy of Tom & Tony. > > > Thanks for the updated page Tom. Here are some comments I should have > sent a sooner. > Thanks, Ill send Dimi a patch in a day or so. Anyone else have ideas where we can improve this page ? Tom

Dec. 28, 2002

Re: tests: ok(0,"foo") prints a '\n'!

by Dmitry Timoshkov

"Francois Gouget" <fgouget(a)free.fr> wrote: > So if noone objects I'll send a patch that stops 'ok' from appending > this '\n', and adds a '\n' to all calls to ok. Actually, I would be > pretty happy if someone could come up with a perl script doing the > latter... > > Comments? Your explanations look very reasonable to me. Of course if somebody will come up with a script to automate the task it would be better. -- Dmitry.

Dec. 27, 2002

Re: Do not free the header while unmapping the xxxx_UNPREPARE messages

by Dmitry Timoshkov

"Eric Pouech" <eric.pouech(a)wanadoo.fr> wrote: > something like this would do Of course your patch works too. But I thought that you have something more sophisticated in mind. Nevertheless, Eric, since you are the author of that code I leave the decision what approach is better to you. -- Dmitry.

Dec. 27, 2002

Re: i would like to do some translation work where do i need to start ?

by Tom Wickline

Ezequiel Perez wrote: > Hi, I'm Ezequiel Perez > i would like to do some translation work where do i need to start? > I can translate it to the spanish language > I live in Buenos Aires, Argentina, my ICQ is 126918474, my MSN Messenger is > eazel7(a)msn.com > > Hello, From Francios post about Wine-Contrib .06 I will list a couple places you could look into. * translating the README and maintaining the translation * translating the Wine resources and messages it issues (but not the debug message of course) It might also be worth having a sort of 'QuickStart/Howto' document that would describe the basic instructions for installing and configuring Wine in a bit more details than the README while being much smaller than the Wine User Guide (it could actually be a chapter of that guide). Then that document could be translated in multiple languages which would at least make it easier for non-english speaking people to set up and install Wine. You may need to get with Tony Lambregts or one of the guy's who knows the in's and out's of just how you would go about this. Thanks for wanting to help with this project... Tom

Dec. 27, 2002

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

by Dimitrie O. Paun

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. (See my related post about maybe using > macros for that.) 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. -- Dimi.

Dec. 27, 2002

Re: Documentation work -task list -man pages

by Dimitrie O. Paun

On December 26, 2002 05:31 pm, Tony Lambregts wrote: > I think that we should keep the documentation tasks togetther. If its OK > with Dimi we can just use his page and give him diffs or we can split > off the documentation section and he can link to it. I am more than OK with it, I think it's the way to go. Having the TODO split in 1000 places defeats the purpose of having a TODO list in the first place. Moreover, look at the other TODOs: they don't change that often... :) > wine.texinfo is like a man page and it seems to be updated fairly well. > I don't agree with trying to get rid of it but I am not about to be the > one to maintain it either. No, it had no serious updates since '98. It's out-of-date, and unmaintained. It does need to be merged with the docs we have. Alexandre explained this some time ago. The TODO entry is still valid IMO. > I really dont know what to do about > installation-und-konfiguration.german. I am inclined to leave it for now Yes, it's a tough nut to break. Personally I think translated docs at this point hinder us a lot more than it helps. Most of our documentation is out-of-date, translating it just makes the problem worse. But that's just me... > > #7 and #8 I dont fully understand what needs to be done here. > > Can you fill me in on what needs to be done with these two ?? Yes, they need merging with the code, or in the documentation, as Tony already explained. > From what I can tell the man pages are the best of the lot. Yes, Alexandre takes care of those usually, these are the last things you should worry about. In other words: don't. :) > Right now we could use someone "New To Wine" to go through the users > guide one chapter at a time and report to us *anything* they don't > understand. That would be a superb test, indeed. But maybe we should first fix the gaping holes before we subject an unsuspecting individual to the task :) -- Dimi.

Dec. 27, 2002

tests: ok(0,"foo") prints a '\n'!

by Francois Gouget

I noticed that the oleaut32/safearray test uses statements such as: ok(a->cDims == i,"a->cDims not initialised?\n"); But it is not necessary to add a '\n' to ok statements. All it does is insert an extra '\n' after each test error. I could send a patch to fix this (small) issue, but I think this behavior of 'ok' is wrong. It goes against the convention established by all other functions such as printf, TRACE, ERR and even the test framework's own trace function. None of these appends a '\n'. 'ok' is the exception there and safearray is not the first test (nor the last) to get caught by this. So if noone objects I'll send a patch that stops 'ok' from appending this '\n', and adds a '\n' to all calls to ok. Actually, I would be pretty happy if someone could come up with a perl script doing the latter... Comments? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

Dec. 27, 2002

make uninstall trying to remove aclocal??

by Mark Knecht

Hi, I note that at the end of make uninstall the scripts seem to be attempting to remove a shared directory. I really am not sure this is a good idea, or at the least the desired action is not taking place... In my case the directory is actually a link, but I think you should not be removing it anyway. Thanks, Mark rm -f /usr/local/share/aclocal/wine.m4 rmdir /usr/local/share/aclocal rmdir: `/usr/local/share/aclocal': Not a directory make: [uninstall] Error 1 (ignored) [root(a)Godzilla share]# ls -al aclocal lrwxrwxrwx 1 root root 18 Dec 6 18:00 aclocal -> /usr/share/aclocal [root(a)Godzilla share]#

Dec. 27, 2002

Re: Couldn't find a decent font, aborting

by Mark Knecht

Eric, Thanks for the response. I'm just back from Christmas travels and trying to get caught up. As an experiment I took an older Redhat 7.0 machine and loaded the newest CVS on it. That machine ran wcmd just fine. However, on this RH 7.3 machine it does not. To me this is a problem to have a major distribution not run this part of Wine. Disappointing. Can you suggest a good site for getting more info on Linux fonts? I am no Linux guru and really just try to have it be a tool. I'm not a software guy. Thanks, Mark On Tue, 2002-12-24 at 08:27, Eric Pouech wrote: > > I've quickly searched through the Devel and User archives, and searched > > using Google, but found just about nothing on the subject. > wineconsole looks for a fixed size font which will fit the 80x25 console > on the screen. it doesn't seem to find one. > a possible workaround is to install more fixed size TTF fonts > A+ > -- > Eric Pouech > >

Dec. 27, 2002

WinXP conformance test update

by Dave Miller

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>dsound_test.exe dsound dsound: 63 tests executed, 0 marked as todo, 0 failures. C:\winetests>gdi32_test.exe generated generated: 2786 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe locale locale.c:154: Test failed: GetTimeFormat got '' instead of '4' locale.c:155: Test failed: GetTimeFormat: got 1 instead of 2 locale.c:181: Test failed: GetTimeFormat got '8.@:56AM' instead of '8.@:56.@:AM' locale.c:182: Test failed: GetTimeFormat: got 9 instead of 12 locale.c:190: Test failed: GetTimeFormat got '' instead of '3' locale.c:191: Test failed: GetTimeFormat: got 1 instead of 2 locale.c:474: Test failed: GetDateFormat got '5/4/2002' instead of '5/4/02' locale.c:475: Test failed: GetDateFormat: got 9 instead of 7 locale.c:499: Test failed: GetDateFormat check DATE_YEARMONTH with null format expected ERROR_INVALID_FLAGS got return of '10' and error of '0' locale: 109 tests executed, 0 marked as todo, 9 failures. C:\winetests>kernel32_test.exe path path.c:514: Test failed: GetLongPathNameA: wrong return code, 105 instead of 45 path.c:881:TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp path.c:892:TMP=C:\WINDOWS path.c:902:TMP=C:\ path.c:912:TMP=C: path: 1730 tests executed, 0 marked as todo, 1 failure. C:\winetests>kernel32_test.exe process tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. process.c:378: Test failed: StartupInfoA:lpTitle expected kernel32_test.exe process, got C:\winetests\kernel32_test.exe 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. process.c:530: Test failed: StartupInfoA:lpTitle expected kernel32_test.exe process, got C:\winetests\kernel32_test.exe 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. process: 116 tests executed, 0 marked as todo, 2 failures. C:\winetests>msvcrt_test.exe file file: 2 tests executed, 0 marked as todo, 0 failures. C:\winetests>msvcrt_test.exe scanf scanf: 8 tests executed, 0 marked as todo, 0 failures. C:\winetests>ntdll_test.exe error error: 813 tests executed, 0 marked as todo, 0 failures. C:\winetests>ntdll_test.exe generated generated: 1279 tests executed, 0 marked as todo, 0 failures. C:\winetests>ntdll_test.exe rtlbitmap rtlbitmap: 224 tests executed, 0 marked as todo, 0 failures. C:\winetests>ntdll_test.exe rtlstr rtlstr: 38 tests executed, 0 marked as todo, 0 failures. C:\winetests>oleaut32_test.exe safearray safearray.c:131: Test failed: SAC(20,1,[1,0]), result 8, expected 0 safearray.c:131: Test failed: SAC(21,1,[1,0]), result 8, expected 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 safearray: 348 tests executed, 0 marked as todo, 4 failures. C:\winetests>oleaut32_test.exe vartest vartest.c:1707: ======== Testing VarUI1FromXXX ======== vartest.c:1713:VarUI1FromI2: passing in NULL as return val makes it crash, needto write proper test. vartest.c:1797: ======== Testing VarUI2FromXXX ======== vartest.c:1802:VarUI2FromI2: passing in NULL as return val makes it crash, needs to be fixed. vartest.c:1874: ======== Testing VarUI4FromXXX ======== vartest.c:1877:VarUI4FromI2: passing in NULL as return val makes it crash, implement me. vartest.c:1952: ======== Testing VarI1FromXXX ======== vartest.c:2005: ======== Testing VarI2FromXXX ======== vartest.c:2048: ======== Testing VarI4FromXXX ======== vartest.c:2092: ======== Testing VarR4FromXXX ======== vartest.c:2139: ======== Testing VarR8FromXXX ======== vartest.c:2159: ======== Testing VarDateFromXXX ======== vartest.c:2209: Test failed: VarDateFromStr([7]="0.49") got 0.0340278 instead of 0.034028 vartest.c:2209: Test failed: VarDateFromStr([8]="0.5") got 0.00347222 instead of 0.003472 vartest.c:2209: Test failed: VarDateFromStr([9]="0.51") got 0.0354167 instead of 0.035417 vartest.c:2209: Test failed: VarDateFromStr([34]=" 1 2 ") got 37258 instead of 35797 vartest.c:2209: Test failed: VarDateFromStr([39]="1.2.3") got 0.0430903 instead of 0.04309 vartest.c:2209: Test failed: VarDateFromStr([69]=" 1999/ 11/21 11 :11:11am") got 36485.5 instead of 36485.5 vartest.c:2209: Test failed: VarDateFromStr([70]="11/11/1999 11:11:11Am") got 36475.5 instead of 36475.5 vartest.c:2209: Test failed: VarDateFromStr([71]="11/11/1999 11:11:11PM") got 36476 instead of 36476 vartest.c:2209: Test failed: VarDateFromStr([73]="11/11/1999 0:0:11am") got 36475 instead of 36475 vartest.c:2209: Test failed: VarDateFromStr([75]="11/11/1999 11:11:11am") got 36475.5 instead of 36475.5 vartest.c:2209: Test failed: VarDateFromStr([77]="11/11/1999 11:11AM") got 36475.5 instead of 36475.5 vartest.c:2209: Test failed: VarDateFromStr([78]="11/11/1999 1AM") got 36475 instead of 36475 vartest.c:2209: Test failed: VarDateFromStr([80]="11/11/1999 11:11:11") got 36475.5 instead of 36475.5 vartest.c:2209: Test failed: VarDateFromStr([89]="1 January 1999 11AM") got 36161.5 instead of 36161.5 vartest.c:2209: Test failed: VarDateFromStr([90]="4AM 11/11/1999") got 36475.2 instead of 36475.2 vartest.c:2209: Test failed: VarDateFromStr([109]="1.5") got 0.0451389 instead of 0.045139 vartest.c:2209: Test failed: VarDateFromStr([110]="2.5") got 0.0868056 instead of 0.086806 vartest.c:2209: Test failed: VarDateFromStr([111]="3.5") got 0.128472 instead of 0.128472 vartest.c:2209: Test failed: VarDateFromStr([112]="4.5") got 0.170139 instead of 0.170139 vartest.c:2224: ======== Testing VarBoolFromXXX ======== vartest.c:2284: ======== Testing VarBSTRFromXXX ======== vartest.c:2309: Test failed: d is 7.65432e+015, should be cvt. to 7.65432198765432e+15, but return val is "7.65432198765432E+15" vartest.c:2316: Test failed: d is -7.65432e+015, should be cvt. to -7.65432198765432e+15, but return val is "-7.65432198765432E+15" vartest.c:2309: Test failed: d is 8.76543e+016, should be cvt. to 8.76543219876543e+16, but return val is "8.76543219876543E+16" vartest.c:2316: Test failed: d is -8.76543e+016, should be cvt. to -8.76543219876543e+16, but return val is "-8.76543219876543E+16" vartest.c:2309: Test failed: d is 9.87654e+017, should be cvt. to 9.87654321987654e+17, but return val is "9.87654321987654E+17" vartest.c:2316: Test failed: d is -9.87654e+017, should be cvt. to -9.87654321987654e+17, but return val is "-9.87654321987654E+17" vartest.c:2309: Test failed: d is 1.98765e+018, should be cvt. to 1.98765432198765e+18, but return val is "1.98765432198765E+18" vartest.c:2316: Test failed: d is -1.98765e+018, should be cvt. to -1.98765432198765e+18, but return val is "-1.98765432198765E+18" vartest.c:2309: Test failed: d is 2.19877e+019, should be cvt. to 2.19876543219877e+19, but return val is "2.19876543219877E+19" vartest.c:2316: Test failed: d is -2.19877e+019, should be cvt. to -2.19876543219877e+19, but return val is "-2.19876543219877E+19" vartest.c:2360: Test failed: d is 7.65432e+015, should be cvt. to 7.65432198765432e+15, but return val is "7.65432198765432E+15" vartest.c:2366: Test failed: d is -7.65432e+015, should be cvt. to -7.65432198765432e+15, but return val is "-7.65432198765432E+15" vartest.c:2360: Test failed: d is 8.76543e+016, should be cvt. to 8.76543219876543e+16, but return val is "8.76543219876543E+16" vartest.c:2366: Test failed: d is -8.76543e+016, should be cvt. to -8.76543219876543e+16, but return val is "-8.76543219876543E+16" vartest.c:2360: Test failed: d is 9.87654e+017, should be cvt. to 9.87654321987654e+17, but return val is "9.87654321987654E+17" vartest.c:2366: Test failed: d is -9.87654e+017, should be cvt. to -9.87654321987654e+17, but return val is "-9.87654321987654E+17" vartest.c:2360: Test failed: d is 1.98765e+018, should be cvt. to 1.98765432198765e+18, but return val is "1.98765432198765E+18" vartest.c:2366: Test failed: d is -1.98765e+018, should be cvt. to -1.98765432198765e+18, but return val is "-1.98765432198765E+18" vartest.c:2360: Test failed: d is 2.19877e+019, should be cvt. to 2.19876543219877e+19, but return val is "2.19876543219877E+19" vartest.c:2366: Test failed: d is -2.19877e+019, should be cvt. to -2.19876543219877e+19, but return val is "-2.19876543219877E+19" vartest.c:2383: Test failed: d is 8.76543e+007, should be cvt. to 8.765432e+07, but return val is "8.765432E+07" vartest.c:2389: Test failed: d is -8.76543e+007, should be cvt. to -8.765432e+07, but return val is "-8.765432E+07" vartest.c:2383: Test failed: d is 9.87654e+008, should be cvt. to 9.876543e+08, but return val is "9.876543E+08" vartest.c:2389: Test failed: d is -9.87654e+008, should be cvt. to -9.876543e+08, but return val is "-9.876543E+08" vartest.c:2383: Test failed: d is 1.98765e+009, should be cvt. to 1.987654e+09,but return val is "1.987654E+09" vartest.c:2389: Test failed: d is -1.98765e+009, should be cvt. to -1.987654e+09, but return val is "-1.987654E+09" vartest.c:2409: Test failed: d is 0.2345, should be cvt. to 0.2345001, but return val is "0.2345" vartest.c:2433: Test failed: d is 654322, should be cvt. to 654322.2, but return val is "654322.3" vartest.c:2439: Test failed: d is -654322, should be cvt. to -654322.2, but return val is "-654322.3" vartest.c:2433: Test failed: d is 8.76543e+007, should be cvt. to 8.765432e+07, but return val is "8.765432E+07" vartest.c:2439: Test failed: d is -8.76543e+007, should be cvt. to -8.765432e+07, but return val is "-8.765432E+07" vartest.c:2433: Test failed: d is 9.87654e+008, should be cvt. to 9.876543e+08, but return val is "9.876543E+08" vartest.c:2439: Test failed: d is -9.87654e+008, should be cvt. to -9.876543e+08 , but return val is "-9.876543E+08" vartest.c:2433: Test failed: d is 1.98765e+009, should be cvt. to 1.987654e+09, but return val is "1.987654E+09" vartest.c:2439: Test failed: d is -1.98765e+009, should be cvt. to -1.987654e+09 , but return val is "-1.987654E+09" vartest.c:2494: ======== Testing Hi-Level Variant API ======== vartest.c:2561: Test failed: should be 5/11/94 7:58:42 AM vartest.c:2579:-------------- Testing different VARTYPES ---------------- vartest: 2281 tests executed, 0 marked as todo, 55 failures. C:\winetests>shell32_test.exe generated generated: 272 tests executed, 0 marked as todo, 0 failures. C:\winetests>shlwapi_test.exe generated generated: 19 tests executed, 0 marked as todo, 0 failures. C:\winetests>urlmon_test.exe generated generated: 4 tests executed, 0 marked as todo, 0 failures. C:\winetests>user32_test.exe generated generated: 1524 tests executed, 0 marked as todo, 0 failures. C:\winetests>wininet_test.exe generated generated: 252 tests executed, 0 marked as todo, 0 failures. wininet/http passes now. Lots of output http: 24 tests executed, 0 marked as todo, 0 failures.

Dec. 27, 2002

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

by Greg Turner

On Friday 27 December 2002 01:49 pm, Gerald Pfeifer wrote: > On Fri, 27 Dec 2002, Greg Turner wrote: > >>>> If we really want to use off_t in this file (instead of > >>>> cab_off_t) we need to #include sys/types.h, or we'll break > >>>> non-Linux systems. > >> > >> Short to medium term, do you agree with my fix (#include > >> <sys/types.h>) so that Wine also builds on non-Linux systems? > > > > Maybe. I don't object, since it should be harmless to add this, > > but I seem to be missing the point of why sys/types.h is needed at > > all. cab_off_t is just typedef'ed to UINT32, which should compile > > just fine with only winnt.h, I think. Is there a particular > > scenario you are encountering that fails? If so, what is the > > compile error? > > The following line is the problem: > > fol->offset[0] = base_offset + (off_t) > EndGetI32(buf+cffold_DataOffset); ^^^^^ > > 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. Although I never formally grepped for it, I made every attempt to convert all off_t's to cab_off_t's or signed integers as appropriate. 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... 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. A random thought: It's notable, that cab_off_t is unsigned, whereas off_t is signed. I began, but did not finish, the process of pouring over the source to ensure this is a nonissue. Perhaps, I might sleep easier if I just turned it back to a signed INT32, although if I recall, I used to think I had a good reason not to do that. Before I submit I'll take a look at that once more, as well. Thanks for spotting this, -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Dec. 27, 2002

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

by Patrik Stridvall

> On Fri, 27 Dec 2002, Greg Turner wrote: > >>>> If we really want to use off_t in this file (instead of > cab_off_t) > >>>> we need to #include sys/types.h, or we'll break > non-Linux systems. > >> Short to medium term, do you agree with my fix (#include > >> <sys/types.h>) so that Wine also builds on non-Linux systems? > > Maybe. I don't object, since it should be harmless to add > this, but I > > seem to be missing the point of why sys/types.h is needed at all. > > cab_off_t is just typedef'ed to UINT32, which should > compile just fine > > with only winnt.h, I think. Is there a particular scenario you are > > encountering that fails? If so, what is the compile error? > > The following line is the problem: > > fol->offset[0] = base_offset + (off_t) > EndGetI32(buf+cffold_DataOffset); > ^^^^^ > > 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? Since the type of fol->offset is cab_off_t presumably... That is how I fixed it in my tree.

Dec. 27, 2002

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

by Gerald Pfeifer

On Fri, 27 Dec 2002, Greg Turner wrote: >>>> If we really want to use off_t in this file (instead of cab_off_t) >>>> we need to #include sys/types.h, or we'll break non-Linux systems. >> Short to medium term, do you agree with my fix (#include >> <sys/types.h>) so that Wine also builds on non-Linux systems? > Maybe. I don't object, since it should be harmless to add this, but I > seem to be missing the point of why sys/types.h is needed at all. > cab_off_t is just typedef'ed to UINT32, which should compile just fine > with only winnt.h, I think. Is there a particular scenario you are > encountering that fails? If so, what is the compile error? The following line is the problem: fol->offset[0] = base_offset + (off_t) EndGetI32(buf+cffold_DataOffset); ^^^^^ 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? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Dec. 27, 2002

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

by Greg Turner

On Friday 27 December 2002 04:35 am, Gerald Pfeifer wrote: > On Thu, 26 Dec 2002, Greg Turner wrote: > >> If we really want to use off_t in this file (instead of cab_off_t) > >> we need to #include sys/types.h, or we'll break non-Linux systems. > > > > actually I don't think we really want to use off_t. [...] > > The easy version of the right fix is probably just to rename > > "cab_off_t" to something less confusing (i.e., cab_file_offset). > > The fancy fix would be to support huge files, which might be a bit > > of a project. > > Ah, I see. > > Short to medium term, do you agree with my fix (#include > <sys/types.h>) so that Wine also builds on non-Linux systems? > > Gerald Maybe. I don't object, since it should be harmless to add this, but I seem to be missing the point of why sys/types.h is needed at all. cab_off_t is just typedef'ed to UINT32, which should compile just fine with only winnt.h, I think. Is there a particular scenario you are encountering that fails? If so, what is the compile error? -- gmt "It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men." --Samuel Adams, Patriot

Dec. 27, 2002

Re: RtlUnicodeStringToInteger prototype (resending)

by Dan Kegel

Duane Clark wrote: > Dan Kegel wrote: > >> I sent this to wine-patches on the 25th, but it never appeared in the >> archive; >> is that list moderated? > > > Only for unsubscribed email adresses, or postings over a 200KB size > limit. And I did not see your patches among those being held. It must have been a mail problem on my system, then. Thanks. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 27, 2002

Re: Wine: several warnings in dlls/ntdll/tests/rtlstr.c

by Francois Gouget

Sent a fix for wcscmp vs. lstrcmpW. On Fri, 27 Dec 2002, Dan Kegel wrote: [...] > > rtlstr.c:170: warning: int format, different type arg (arg 3) > > rtlstr.c:175: warning: int format, different type arg (arg 3) > > rtlstr.c:176: warning: int format, different type arg (arg 3) > > rtlstr.c:178: warning: int format, different type arg (arg 3) > > rtlstr.c:179: warning: int format, different type arg (arg 3) > > rtlstr.c:181: warning: int format, different type arg (arg 3) > > rtlstr.c:182: warning: int format, different type arg (arg 3) > > rtlstr.c:184: warning: int format, different type arg (arg 3) > > rtlstr.c:185: warning: int format, different type arg (arg 3) 'ok' uses the standard glibc printf functions and thus does not support '%S' (unicode strings). Or if it does support '%S' it expects 32bit Unicode chars rather than 16bit ones so it won't work. Unfortunately, currently there is no good way of printing Unicode strings in tests. We may need a function similar to debugstr_w... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

Dec. 27, 2002

Re: Wine Contrib 0.6

by Francois Gouget

On Fri, 27 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > A new version of Wine-Contrib is available at: > http://www.dssd.ca/wine/Wine-Contrib-0.6.html > courtesy of Tom & Tony. Thanks for the updated page Tom. Here are some comments I should have sent a sooner. * Web site maintenance I think we should mention that we are in the process of redoing the web site and that we really could use some help. Maybe point to (some of) bugs 597, 598, 600, 601, 605, 607, 608, and especially the discussions that took place on wine-devel some time ago. Also, it would probably be better to send offers of assistance to wine-devel. * Cross referencing the Windows executables and libraries Bug 556 is somewhat related and I have been somewhat working on it :-) More precisely I think I need to upgrade my script to make it able to filter APIs that are missing in Wine using the MSDN and/or Sdk headers and/or Google, and just report those that match all of the above. Then it's a no brainer to add these. Once these are added, hopefully the list of missing APIs will be much smaller and it will be easier to handle them manually. * Documentation of the Windows API functions I think this would be nice. The main reason is that as MS moves to new APIs it tends to remove all documentation of the old ones (e.g. Win 3.1). However it is generally felt that this is not a priority and that actually implementing stuff and fixing bugs is more important; which is hard to argue against ;-) I don't know how to convey all this nicely. * Localization work Concerning the translation of the main documentation I think we are not ready for it yet. Currently we barely manage to maintain the English documentation so adding translations does not seem like a good idea. Unless the translators 'pledge' to also maintain the English documentation. However, I believe there is still useful localization work that can be done: - translating the README and maintaining the translation - translating the Wine resources and messages it issues (but not the debug message of course) It might also be worth having a sort of 'QuickStart/Howto' document that would describe the basic instructions for installing and configuring Wine in a bit more details than the README while being much smaller than the Wine User Guide (it could actually be a chapter of that guide). Then that document could be translated in multiple languages which would at least make it easier for non-english speaking people to set up and install Wine. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Dec. 27, 2002

Re: d3d three more renderstates for n2002

by György 'Nog' Jeney

>> with one of the last patches from the cvs the game Nascar 2002 now >> recognizes the d3d rasterizer in the config tool. The patch below adds >> three more handlers for the D3DRENDERSTATE. As d3d seems to me pretty >> undocumented i can only try to find things out using goolgle and see >> the example code there - a link to doku would be really appreciated. > > For the documentation, do a Google search on the .CHM files from the > various DirectX SDKs (as the relevant documentations are not to be found > anymore on MSDN's site, only DX8 / 9 is still there). Im not sure if your refering to the online documentation (if you are then your right), but at least the dx7a sdk is still availible from: http://download.microsoft.com/download/win98SE/DXSDK/7.0a/W9X/EN-US/dx7adxf… nog.

Dec. 27, 2002

Re: Standard way of printing RECT in trace statements?

by Dan Kegel

Francois Gouget wrote: > On Fri, 27 Dec 2002, Dan Kegel wrote: > [...] > >>I thought everyone always left NO_TRACE_MSGS undefined, >>so the rect2a function you favor gets called unconditionally, >>and its output filtered out. > > > No. Look at the TRACE macro again (include/wine/debug.h). The function > will only be called if __WINE_GET_DEBUGGING(dbcl,(dbch)) I stand corrected. Sweet. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 27, 2002