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

Mono 1.2.5.1 on Wine
by Kornél Pál Dec. 8, 2007

Dec. 8, 2007

Hi, I tried to run Mono 1.2.5.1 on Wine but it dies with the "Weird VirtualQuery result" error message. Are there any know bugs of Wine or Mono that prevent it from running? I would like to make Mono run on Wine and I am willing to contribute patches to Wine and Mono as well to achieve that. Kornél

2 1

re: Wine Problem
by Dan Kegel Dec. 8, 2007

Dec. 8, 2007

Pedro Ferreira wrote: > I installed a software that talks with the informix client 2.7.0 > everything was running fine, the instalation went with minor problems. > Until now > >when i stated a connection to the informix server wine simply stops Which version of Wine? Have you tested the connection using the ilogin.exe demo that comes with the informix SDK? If you don't have it, you can download a free trial of the 2.80 SDK, that's probably close enough. The procedure for testing the connection is described here: http://www.synametrics.com/ifmxODBC.htm BTW the right mailing list for this is probably wine-users, not wine-devel. - Dan

1 0

Re: [Wine] TortoiseCVS- Unimplemented functions in ntdll.dll causes program to terminate.
by James McKenzie Dec. 7, 2007

Dec. 7, 2007

Jean-Claude Gervais wrote: > Thank you, Austin! > > I installed Samba to obtain winbind and ntlm_auth, and it did change > the outcome a bit: > > Tortoise still checks out the first file and pops up an error dialog, > so there is no apparent difference, but the session output from Wine HAS > changed, it has gotten quieter: > > wine TortoiseAct.exe CVSCheckOut -f "C:\windows\Temp\TCV1.tmp" -h > 0x300b4 > fixme:actctx:parse_depend_manifests Could not find dependent assembly > L"Microsoft.Windows.Common-Controls" > fixme:richedit:RichEditWndProc_common WM_STYLECHANGING: stub > fixme:richedit:RichEditWndProc_common WM_STYLECHANGED: stub > wine: Call from 0x7bc38828 to unimplemented function > ntdll.dll.NtQueryEaFile, aborting > wine: Call from 0x7bc38828 to unimplemented function > ntdll.dll.NtSetEaFile, aborting > err:mmio:MMIO_ParseExtA No . in szFileName: "TCVS_Error" > > Sadly, it appears that it really is the two unimplemented functions > (NtQueryEaFile and NtSetEaFile) causing the problem. > > Thank you kindly for your help in any case and if you have any other > strategies or ideas to workaround this, I would gladly try them. > > Thanks again. > J > As others have stated here, please file a bug against ntdll.dll and name your program as the source of the problem. It may be possible to get your program to run with a minimum of effort, but this may take considerable effort. The more reports of problems with these functions, the more effort should be brought in to build and implement these functions. It also appears that you are using a program that is dependent on other functions that are implemented elsewhere in the Windows environment. James

2 1

Re: Monthcal lost focus fix
by Alexandre Julliard Dec. 7, 2007

Dec. 7, 2007

Gregor Brunmar <gregor.brunmar(a)home.se> writes: > diff --git a/dlls/comctl32/monthcal.c b/dlls/comctl32/monthcal.c > index 8a92d42..e826612 100644 > --- a/dlls/comctl32/monthcal.c > +++ b/dlls/comctl32/monthcal.c > @@ -1719,11 +1719,12 @@ MONTHCAL_Paint(MONTHCAL_INFO *infoPtr, WPARAM wParam) > > > static LRESULT > -MONTHCAL_KillFocus(const MONTHCAL_INFO *infoPtr) > +MONTHCAL_KillFocus(const MONTHCAL_INFO *infoPtr, HWND hFocusWnd) > { > TRACE("\n"); > > - InvalidateRect(infoPtr->hwndSelf, NULL, TRUE); > + if (infoPtr->hwndNotify != hFocusWnd) > + ShowWindow(infoPtr->hwndSelf, SW_HIDE); Is there a reason for removing the InvalidateRect completely? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] winealsa: Make widGetPos more accurate
by Alexandre Julliard Dec. 7, 2007

Dec. 7, 2007

Maarten Lankhorst <maarten(a)codeweavers.com> writes: > --- > dlls/winealsa.drv/wavein.c | 6 +++++- This doesn't work for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so capture.c && touch capture.ok capture.c:73: Test failed: waveInGetPosition(0): returned 2730 bytes, should be 0 capture.c:84: Test failed: waveInGetPosition(0): returned 2730 samples, should be 0 capture.c:96: Test failed: waveInGetPosition(0): returned 341 ms, should be 0 capture.c:108: Test failed: waveInGetPosition(0): SMPTE test failed capture.c:119: Test failed: waveInGetPosition(0): MIDI test failed capture.c:130: Test failed: waveInGetPosition(0): TICKS test failed [lots more of the same] -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: msi 2: Reimplement MsiGetProductCode
by Alexandre Julliard Dec. 7, 2007

Dec. 7, 2007

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Reimplement MsiGetProductCode. The test fails occasionally with something like: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so msi.c && touch msi.ok msi.c:1426: Test failed: Expected {E853FAEA-A4E2-11DC-A19E-001A923592CB}, got {E853FAAE-A4E2-11DC-A19E-001A923592CB} msi.c:1530: Test failed: Expected {E853FAEA-A4E2-11DC-A19E-001A923592CB}, got {E853FAAE-A4E2-11DC-A19E-001A923592CB} make: *** [msi.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Missing 32bit support libraries on x86_64 Debian
by Ben Hodgetts Dec. 7, 2007

Dec. 7, 2007

I just submitted this to the Debian tracker system, thought it may be useful to echo here in-case anyone else is using x86_64 Debian as it seems since Julliard put in a patch just before .42 to check more completely for dependencies it now shows that Debian (64) actually lacks certain deps for Wine. Ben H. --------------------------------------- Package: wine Version: All Severity: important Wine, when compiled from source (upstream source) shows that Debian is missing certain dependencies which cause loss of functionality in Wine on x86_64. These are libpng, libcups, libcapi20, libhal and openssl. This means that 32bit support packages need to be made for Debian for Wine to work properly (just like there is currently a lib32asound(-dev), etc to give ALSA support). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wine depends on: ii debconf [debconf-2.0] 1.5.17 Debian configuration management sy pn libwine <none> (no description available) ii xbase-clients 1:7.3+7 miscellaneous X clients - metapack Versions of packages wine recommends: ii msttcorefonts 2.4 Installer for Microsoft TrueType c pn wine-utils <none> (no description available)

1 0

Re: Assorted spelling fixes.
by H. Verbeet Dec. 7, 2007

Dec. 7, 2007

On 07/12/2007, Francois Gouget <fgouget(a)free.fr> wrote: > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > - * out. The nvidia driver only does that if the parameter is inout instead of out, hence the > - * inout. > + * out. The nvidia driver only does that if the parameter is in/out instead of out, hence the > + * in/out. I don't think that change is correct. GLSL function parameters can have qualifiers to specify how the parameter is used. The possible qualifiers are "in", "out" and "inout", where specifying no qualifier is the same as specifying "in". I suppose the first "inout" could be replaced with "in/out" without changing the meaning of the sentence too much, but the second one is a reference to the actual qualifier.

2 1

Re: (corrected) Add 18 pixel strike with japanese fonts to system.sdf Widths corrected and double checked for both strikes
by Huw Davies Dec. 7, 2007

Dec. 7, 2007

Aric Stewart wrote: > --- > fonts/system.sfd | 1587 > +++++++++++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 1341 insertions(+), 246 deletions(-) You seem to have changed a couple of glyphs in the 16 pixel strike too. Was that on purpose (and if so shouldn't it be a separate patch?). Huw.

2 2

Nifty new valgrind report script. New error in oleaut32. Call for volunteer(s).
by Dan Kegel Dec. 7, 2007

Dec. 7, 2007

I finally got tired of doing "history | grep diff" etc, and partially automated the daily valgrind run; the resulting script is at http://kegel.com/wine/valgrind/valgrind-daily.sh The results are now in directories named like http://kegel.com/wine/valgrind/logs-2007-12-06/ A summary of the new problems compared to last run are in files named like http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt And next to each individual result, there is a diff with the previous run, e.g. http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat.txt http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.t… To look at what changed since yesterday, start by looking at the day's summary file. In it, there's one line per test, followed by the changes in that test's results, if any. Lines that start with + indicate new problems (boo); lines that start with - indicate old problems that are now gone (yay!) Nearby lines that are identical except for one starting with + and one starting with - indicate a problem that moved, so ignore those. For example, in today's summary, http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt the first test with changes is in hlink: diff -u logs-2007-12-05/vg-hlink_hlink.txt logs-2007-12-06/vg-hlink_hlink.txt - Syscall param write(buf) points to uninitialised byte(s) That means the hlink test has one fewer error. Yay! The next test with changes is diff -u logs-2007-12-05/vg-ole32_moniker.txt logs-2007-12-06/vg-ole32_moniker.txt + Syscall param write(buf) points to uninitialised byte(s) - Syscall param write(buf) points to uninitialised byte(s) - Conditional jump or move depends on uninitialised value(s) The 'Syscall' error just moved, so that's not really a change. The 'Conditional' error went away, yay! The next test with changes is diff -u logs-2007-12-05/vg-oleaut32_varformat.txt logs-2007-12-06/vg-oleaut32_varformat.txt + Invalid read of size 2 That's a + with no matching -, so it's a new error, boo! Let's see if it's a real error, or just crap in the log. The first thing to check is the diff of that test's results with the last run: http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.t… It shows a fairly convincing new error: + Invalid read of size 2 + at VarFormatFromTokens (varformat.c:1888) + by VarFormat (varformat.c:2096) + by func_varformat (varformat.c:317) + by run_test (test.h:387) + by main (test.h:436) + Address 0x7F00AB01 is 15 bytes before a block of size 8 alloc'd + at RtlAllocateHeap (heap.c:1225) + by SysAllocStringByteLen (oleaut.c:357) + by VariantCopy (variant.c:722) + by VariantChangeTypeEx (variant.c:992) + by VarFormatFromTokens (varformat.c:1884) + by VarFormat (varformat.c:2096) + by func_varformat (varformat.c:317) + by run_test (test.h:387) + by main (test.h:436) Now, sometimes tests are flaky, and errors just happen to come and go, so this doesn't mean for sure it's a new error. But looking back a few days, I don't see it before. So it's probably a new error. Let's see, who's been submitting changes to oleaut32 lately? Only change in git since the last run seems to be http://www.winehq.org/pipermail/wine-cvs/2007-December/038491.html It's not clear how that patch could have caused the error offhand, but it's worth emailing the author and asking him to check, so I've cc'd him. And that's the only new error in the whole run. It's worth watching for new errors and alerting the authors, since the change is fresh in their mind, they'll probably be able to fix it quickly. Egg in the face is a dish best served warm. I'll try to keep running this script daily, but it'd be nice if somebody else took over (and possibly even increased the automation; I still have to do git pull, run the script, and upload by hand.) It doesn't help that valgrind only works well on some machines, but hey, what's life without challenges. - Dan

1 0