- wine-devel - winehq.org

Cpp Check Nov. 7th
by chris ahrendt 10 Nov '09

10 Nov '09

Well its been a few since I ran CPP Check and so I ran it today and got the following: New CPP Check Errors for the Wine Code: [/home/cahrendt/wine-git/dlls/comctl32/imagelist.c:1908]: (error) Uninitialized variable: bmi_buf [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szText [/home/cahrendt/wine-git/dlls/shell32/shellord.c:416]: (error) Uninitialized variable: szTitle [/home/cahrendt/wine-git/dlls/shell32/shellpath.c:1360]: (error) Uninitialized variable: InfoBuffer [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd [/home/cahrendt/wine-git/server/mapping.c:118]: (error) Uninitialized variable: page_size Chris

2 1

Re: [PATCH 4] mciwave: Rework MCI notification system.
by Vitaliy Margolen 10 Nov '09

10 Nov '09

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > + * Notifications in MCI work like a 1-element queue. > + * Each new notification request supersedes the previous one. > + volatile HANDLE hCallback; /* Callback handle for pending notification */ You do not need volatile here as AJ already explained. > + HANDLE old = InterlockedExchangePointer(&wmw->hCallback, NULL); > + if (old) mciDriverNotify(old,wDevID,MCI_NOTIFY_SUPERSEDED); > + mciDriverNotify(HWND_32(LOWORD(hWndCallBack)),wDevID,wStatus); Here and everywhere else in your patches, please add space before commas. > + if (wmw->hFile == 0)<----->return MCIERR_INTERNAL; /* FIXME: Save must work even after Open new. */ > . > - if (dwFlags & MCI_WAIT) > - { > - <->FIXME("MCI_WAIT not implemented\n"); > - } > - WAVE_mciStop(wDevID, 0, NULL); > + WAVE_mciStop(wDevID, MCI_WAIT, NULL); This looks like an unrelated change. Vitaliy.

1 1

Re: ntdll: fix memory leak in GetDiskFreeSpaceW
by Vitaliy Margolen 10 Nov '09

10 Nov '09

Dan Kegel wrote: > Found while valgrinding chromium's app_unittests. > > + done: > + RtlFreeHeap(GetProcessHeap(), 0, val.Buffer); > + You should us RtlFreeUnicodeString( &val ); instead. Vitaliy.

1 0

re: Question on using winedbg when program does not crash, just becomes unresponsive
by Dan Kegel 10 Nov '09

10 Nov '09

Susan asked: > [What can you do to get a backtrace of a hung app that won't hang when you run it in winedbg?] I ran into this last week and added a note to http://wiki.winehq.org/Backtraces "Alternately, instad of info process / attach, you can do 'bt all' to get backtraces of all threads in all running processes. This is handy when debugging hangs." That's not a very clear explanation, but what it means is: start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones...

3 3

The user32/win test crashes X on Intel cards
by Joerg-Cyril.Hoehle＠t-systems.com 09 Nov '09

09 Nov '09

Hi, >Marcus got the same issue and he had an Intel card too Charles Davis wrote: >This happens on Mac OS X, too. Check out >http://xquartz.macosforge.org/trac/ticket/293 Charles forgot to mention that it affects NVidia on the Mac, which I did not explicitly write in the above bug report (the Mac people will have guessed it from the "early 2009 Mac mini" comment). More precisely SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOMOVE); #if 0 SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); #endif SetWindowPos(hwnd, 0, -32769, -40000, -32769, -90000, SWP_NOSIZE); SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOSIZE); is enough to let the tests succeed with Version: 2.3.3.2 (2.3.3) Build Info: X11server-480700~6 OS Version: Mac OS X 10.5.7 (9J61) This hints that the bug is in the X server, not the individual drivers? Regards, Jörg Höhle

2 1

Re: To error out or to skip tests?
by Greg Geldorp 09 Nov '09

09 Nov '09

Hi Jörg > Failure to flag an error in such cases has known drawbacks: > - For several month, Austin did not notice that his BSD boxes had lost > sound. wave.ok simply reports "5 tests ok, 1 skipped" in joyfull > green, whereas it executed many tests half a year ago. > > - All those vmware boxes configured without sound and thus skipping > all but 5 wave.ok tests have for monthes *not* provided valuable > feedback to Wine. So they were actually *not* executing tests, when > they could have. > It's only when Paul tested one of my tests that he realized that > sound was not configured on one of his vmware boxes, promptly > configured the sound device, and the tests passed. > > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > They all have no sound configured. Mostly useless. A lot of those VMware boxes are mine. They come in two flavors. Some of them (starting with esx-) are ESX VMs, ESX is VMware's data center product, which simply doesn't support sound. The others (starting with gvg-) are Server VMs, which do support sound. The reason I didn't configure sound on them is because I'm simply not interested in sound. I'll consider enabling sound, but to be honest I'm a bit put off by your aggressive tone. Anyway, the end result is that there will always be ESX VMs that can't run sound tests. Best regards, Ge.

5 12

Question on using winedbg when program does not crash, just becomes unresponsive
by Susan Cragin 09 Nov '09

09 Nov '09

There is some sort of memory leak in Dragon NaturallySpeaking that makes the program become unresponsive (but not crash) after some minutes of using the Dictation Box. I have tried winedbg, SetOnFirstBreak but the program never actually crashes. Without SOFB, of course, winedbg goes for the first unhandled exception, which is harmless. I can't start winedbg right before the program crashes, because I don't know when it will do so. It just sort of wears down. There is nothing I do to make it become unresponsive. Any ideas?

1 0

To error out or to skip tests?
by Joerg-Cyril.Hoehle＠t-systems.com 09 Nov '09

09 Nov '09

Hi, I apologize for the numerous occurrances of red color on test.winehq due to my new winmm MCI tests. That was not expected. However, turning something green is not a goal in itself. For some time now I wanted to query wine-devel about this topic, independently of my patches, so here it goes. An analysis reveals that my tests implement a detector of vmware (virtualbox etc.) default installs, i.e. MS-Windows systems that have not been configured with sound. No real user's machines would be like that (except for a w95 box I tried with a broken soundcard). The revealing line is > Tests skipped: Please install audio driver. Tests will fail (18 errors) This goes hand in hand with "5 tests, 0 errors, 1 skip" in winmm:wave. Exactly those systems skipping the wave tests produce 18-19 MCI errors. Failure to flag an error in such cases has known drawbacks: - For several month, Austin did not notice that his BSD boxes had lost sound. wave.ok simply reports "5 tests ok, 1 skipped" in joyfull green, whereas it executed many tests half a year ago. - All those vmware boxes configured without sound and thus skipping all but 5 wave.ok tests have for monthes *not* provided valuable feedback to Wine. So they were actually *not* executing tests, when they could have. It's only when Paul tested one of my tests that he realized that sound was not configured on one of his vmware boxes, promptly configured the sound device, and the tests passed. The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! They all have no sound configured. Mostly useless. Therefore, I believe it's sometimes better to flag an error than to calmly skip something. Last year already, submitting the ICCVID patches, I was thinking: "iccvid.dll may not part of every installation, but we want feedback so we should compare behaviour with MS-Windows systems equipped with that library and ask people to install it if not present". Likewise, Wine should compare with systems similarly equipped: d3d8, d3d9, dplay, dmusic etc. Perhaps an easy change on test.winehq would be to augment the blue color indicator of skipped tests to the full rectangle surface instead of the current green? Of course, I'll change my tests to flag a single error on systems without sound. -- Or no error at all, if that's wine-devel consensus. What do you think? Jörg Höhle. There's only few real MCI test errors I saw on test.winehq: the system "fg_winxp-ie8" that yields 1 error instead of 18: mci.c:391: Test failed: not enough time elapsed 80ms -- a flakey test. And on the ME systems: mci.c:603: Test failed: mci re-auto-open status mode returned error: 275 mci.c:612: Test failed: mci auto-open pause returned error: 275 Luckily, there are a few machines that pass all tests.

4 3

Another article that makes me want Wine to run in a sandbox
by Dan Kegel 08 Nov '09

08 Nov '09

http://www.linuxinsider.com/rsstory/68566.html The article is about users who are willing to follow bogus instructions to solve a problem (or install something). It makes me want the average desktop to be really, really locked down... and for user-installed apps to run in a sandbox so they can't break the rest of the system. I am looking forward to hear what the discussion at http://sandboxing.org comes up with.

5 8

The user32/win test crashes X on Intel cards
by Francois Gouget 08 Nov '09

08 Nov '09

I hit this issue while trying to run winetest for WineConf. I looked into it and the crash is caused by this line in dlls/user32/tests/win.c: SetWindowPos(hwnd, 0, 32768, 40000, 32768, 40000, SWP_NOMOVE); More precisely it's the setting of the window width and height to 32768 x 40000 that causes the crash. Looking at the .xsession-errors file I see the window manager reporting the following X server error: Anomalie dans le gestionnaire de fenêtres : Unexpected X error: BadAlloc (insufficient resources for operation) serial 11940 error_code 11 request_code 53 minor_code 0) Is it possible that this is just an out of memory issue caused by the huge window size? According to my tests 32000x32000 (a tad < 3GB) works but 32767x32767 (a tad >3GB) cause the crash. Here's my configuration: * Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3 * VideoRAM: 256MB (according to /var/log/Xorg.0.log) * xserver-xorg-video-intel 2:2.9.0-1 Latest from Debian Testing. Debian Unstable does not seem to have a more recent driver. Marcus got the same issue and he had an Intel card too and we were the only two with this issue. So apparently this is Intel-specific. Does any one have an Intel card where this does not happen? What's your driver version? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 2

Re: d3d9: quiet a few very noisy fixme's
by Austin English 08 Nov '09

08 Nov '09

On Sun, Nov 8, 2009 at 6:14 AM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > These are spawned at huge rate in World in Conflict demo > (http://bugs.winehq.org/show_bug.cgi?id=11114) It'd be quicker/cleaner to just change them to warn's instead, IMHO. -- -Austin

2 1

Re: [PATCH] rpcrt4: compare networkoptions correctly (Coverity) (adjusted)
by Rob Shearman 08 Nov '09

08 Nov '09

2009/11/8 Marcus Meissner <meissner(a)suse.de>: > @@ -84,6 +84,17 @@ static RPC_STATUS RpcAssoc_Alloc(LPCSTR Protseq, LPCSTR NetworkAddr, > return RPC_S_OK; > } > > +static BOOL compare_networkoptions(LPCWSTR opts1, LPCWSTR opts2) > +{ > + if ((opts1 == NULL) && (opts2 == NULL)) > + return TRUE; > + if ((opts1 == NULL) && (opts2 != NULL)) > + return FALSE; > + if ((opts1 != NULL) && (opts2 == NULL)) > + return FALSE; > + return !strcmpW(opts1, opts2); > +} > + > RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > LPCSTR Endpoint, LPCWSTR NetworkOptions, > RpcAssoc **assoc_out) > @@ -97,8 +108,8 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > - { > + compare_networkoptions(NetworkOptions, assoc->NetworkOptions) > + ) { Looks good functionally, but please don't change the style. > assoc->refs++; > *assoc_out = assoc; > LeaveCriticalSection(&assoc_list_cs); Thanks, -- Rob Shearman

1 0

Re: winex11.drv: Implement FIXME in AlphaBlend
by Roderick Colenbrander 08 Nov '09

08 Nov '09

Hi Peter, I didn't see this patch before because I was away at that time. The SourceConstantAlpha part looks correct to me. It might make sense to calculate blendfn.SourceConstantAlpha / 255 before the loop, so that it isn't recalculated each time. The other half of your patch is a separate change and it would require a separate patch. The part looks suspicious though. I don't understand why you need special locking there. Roderick On Mon, Oct 26, 2009 at 4:39 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > > > commit df78de34a06e32be9f37a3b34fe68e5b088a8578 > Author: Peter Urbanec <winehq.org(a)urbanec.net> > Date: Mon Oct 26 21:29:00 2009 +1100 > > Implement source alpha plus SourceConstantAlpha combined transparency. > Add DIB locking to prevent node icon rendering errors in Fusion composition flow views. > > diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c > index 90503bf..26dc262 100644 > --- a/dlls/winex11.drv/xrender.c > +++ b/dlls/winex11.drv/xrender.c > @@ -1956,9 +1956,6 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > return FALSE; > } > > - if ((blendfn.AlphaFormat & AC_SRC_ALPHA) && blendfn.SourceConstantAlpha != 0xff) > - FIXME("Ignoring SourceConstantAlpha %d for AC_SRC_ALPHA\n", blendfn.SourceConstantAlpha); > - > if(dib.dsBm.bmBitsPixel != 32) { > FIXME("not a 32 bpp dibsection\n"); > return FALSE; > @@ -1979,11 +1976,35 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > if (blendfn.AlphaFormat & AC_SRC_ALPHA) > { > - for(; y >= y2; y--) > + if (blendfn.SourceConstantAlpha == 0xff) > { > - memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > + for(; y >= y2; y--) > + { > + memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > - dstbits += (top_down ? -1 : 1) * widthSrc; > + dstbits += (top_down ? -1 : 1) * widthSrc; > + } > + } > + else > + { > + /* Source alpha plus SourceConstantAlpha */ > + for(; y >= y2; y--) > + { > + int x; > + DWORD *srcbits = (DWORD *)((char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes) + xSrc; > + for (x = 0; x < widthSrc; x++) > + { > + DWORD argb = *srcbits++; > + BYTE *s = (BYTE *) &argb; > + s[0] = (s[0] * blendfn.SourceConstantAlpha) / 255; > + s[1] = (s[1] * blendfn.SourceConstantAlpha) / 255; > + s[2] = (s[2] * blendfn.SourceConstantAlpha) / 255; > + s[3] = (s[3] * blendfn.SourceConstantAlpha) / 255; > + *dstbits++ = argb; > + } > + if (top_down) /* we traversed the row forward so we should go back by two rows */ > + dstbits -= 2 * widthSrc; > + } > } > } > else > @@ -2006,6 +2027,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > > } > > + X11DRV_LockDIBSection( devDst, DIB_Status_GdiMod ); > dst_pict = get_xrender_picture(devDst); > > wine_tsx11_lock(); > @@ -2017,6 +2039,8 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > if(!src_format) > { > WARN("Unable to find a picture format supporting alpha, make sure X is running at 24-bit\n"); > + wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > return FALSE; > } > > @@ -2055,6 +2079,7 @@ BOOL CDECL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT wid > XDestroyImage(image); > > wine_tsx11_unlock(); > + X11DRV_UnlockDIBSection( devDst, TRUE ); > HeapFree(GetProcessHeap(), 0, data); > return TRUE; > } > > > >

2 1

Re: (retry) msctf/tests: handle an occassional unexpected SetFocus from wine
by Nicolas Le Cam 07 Nov '09

07 Nov '09

2009/11/7 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/msctf/tests/inputprocessor.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > Here are the results for 100 consecutive runs : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 77 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 1 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. I also did try to sleep between tests in case it could help but it doesn't seem so : $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 78 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 17 inputprocessor: 231 tests executed (0 marked as todo, 3 failures), 0 skipped. 3 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. For info, here is a run without your patch. $ for i in {1..100}; do wine msctf_test.exe.so >> msctf_tests.log 2>&1; sleep 1; done $ grep "tests executed" msctf_tests.log | sort | uniq -c | sort -nr 64 inputprocessor: 230 tests executed (0 marked as todo, 0 failures), 0 skipped. 18 inputprocessor: 236 tests executed (0 marked as todo, 4 failures), 0 skipped. 12 inputprocessor: 237 tests executed (0 marked as todo, 7 failures), 0 skipped. 3 inputprocessor: 234 tests executed (0 marked as todo, 4 failures), 0 skipped. 2 inputprocessor: 236 tests executed (0 marked as todo, 6 failures), 0 skipped. 1 inputprocessor: 238 tests executed (0 marked as todo, 8 failures), 0 skipped. If you need me to do more tests, just ask, I'm willing to go green ;) -- Nicolas Le Cam

1 0

Re: [PATCH] rpcrt4: Fixed incorrect NULL check condition (Coverity)
by Rob Shearman 07 Nov '09

07 Nov '09

2009/10/17 Marcus Meissner <marcus(a)jet.franken.de>: > Hi, > > Coverity spotted that this could lead to NULL dereference, > and yes, the && should be ||. This is not what was intended. The code inside the if block shouldn't execute if assoc->NetworkOptions is NULL and NetworkOptions isn't and vice-versa. The comparison should probably be split into a separate function. > @@ -97,7 +97,7 @@ RPC_STATUS RPCRT4_GetAssociation(LPCSTR Protseq, LPCSTR NetworkAddr, > if (!strcmp(Protseq, assoc->Protseq) && > !strcmp(NetworkAddr, assoc->NetworkAddr) && > !strcmp(Endpoint, assoc->Endpoint) && > - ((!assoc->NetworkOptions && !NetworkOptions) || !strcmpW(NetworkOptions, assoc->NetworkOptions))) > + (!assoc->NetworkOptions || !NetworkOptions || !strcmpW(NetworkOptions, assoc->NetworkOptions))) Thanks, -- Rob Shearman

1 0

libsmbclient and wine?
by Dan Kegel 07 Nov '09

07 Nov '09

Hi folks, it's often been said that wine can't use libsmbclient because of license problems. I'd like to look at that assumption a bit. - What would wine like to use libsmbclient for, if it could? - Would it suffice to just link it in to wineserver, or would it need to be invoked directly by all sorts of dlls? - Would we just use the system's libsmbclient (I hope so) rather than trying to import its source? Also, fwiw, I think the Samba guys are willing to multiplex their listening daemon so Wine could handle incoming named pipe requests if we want to. Thanks, Dan

3 2

Re: msctf/tests: handle an occassional unexpected SetFocus from wine
by Aric Stewart 07 Nov '09

07 Nov '09

Please disregard this. I was testing the wrong version on my winvista machine and this causes a failure. revised version coming. -aric Aric Stewart wrote: > --- > dlls/msctf/tests/inputprocessor.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > ------------------------------------------------------------------------ > >

1 0

Re: msctf/tests: handle an occassional unexpected SetFocus from wine
by Nicolas Le Cam 07 Nov '09

07 Nov '09

2009/11/7 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/msctf/tests/inputprocessor.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > > > Aric, is this for my versatile machine ? -- Nicolas Le Cam

1 0

Re: [CHANGE] Patch: regional settings update & translation
by Stefan Leichter 07 Nov '09

07 Nov '09

Am Friday 06 November 2009 21:49:26 schrieb lejcik: > Signed-off-by: lejcik <lejcik(a)host.sk> > --- > dlls/kernel32/nls/csy.nls | 38 +++++++++++++++++++------------------- > dlls/kernel32/nls/sky.nls | 42 > +++++++++++++++++++++--------------------- > 2 files changed, 40 insertions(+), 40 deletions(-) To get a patch accepted, you need the send it with your real name. Bye Stefan

1 0

Link to Test Runs
by Mike 06 Nov '09

06 Nov '09

Ok, I found this once before but I can't find it again. Where is the link to the test runs for different platforms, etc. I wanted to see if my tests passed Win 95. Sorry for asking questions that should probably be obvious, but we all start ignorant and some of us more ignorant and naive than others. Thanks, Mikey

2 1

Re: shell32/tests: Add Program Manager DDE Conformance Tests (try 2)
by Paul Vriens 06 Nov '09

06 Nov '09

On 11/03/2009 04:32 AM, Mike wrote: > These conformance tests are for the program manager dde. Basic operations are tested. The current wine implementation (shell32/dde.c) of the Program Manager DDE is stubbed. This conformance tests were run and passed on Win 98 SE and Win XP SP2. Related Bug #9159 > > > --- > dlls/shell32/tests/Makefile.in | 1 + > dlls/shell32/tests/progman_dde.c | 551 ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 552 insertions(+), 0 deletions(-) > create mode 100644 dlls/shell32/tests/progman_dde.c > > Hi Mikey, These new tests introduce test failures on different platforms: http://test.winehq.org/data/tests/shell32:progman_dde.html Could you have a look? -- Cheers, Paul.

2 1

Re: winmm/tests: Add MCI waveaudio tests.
by Paul Vriens 06 Nov '09

06 Nov '09

On 11/05/2009 02:35 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > this is the same as yesterday's patch except that I replaced the > ad-hoc skip auto-open test with one that specifically detects Wine's > missing auto-open functionality instead of another thing missing in Wine. > You will prefer that version; sorry for the quick-shot. > > Regards, > Jörg Höhle. > Hi Jörg, This one introduces several test failures: http://test.winehq.org/data/tests/winmm:mci.html I guess you already noticed, but could you have a look? -- Cheers, Paul.

1 0

Re: had trouble compiling today
by Susan Cragin 06 Nov '09

06 Nov '09

>Looks like a gcc compiler bug, so you will need to report it there >and/or to the Ubuntu bug tracker. > >Out of interest: > a/ did this work when you were running karmic? Yes. Worked always with Karmic. Worked yesterday with Lucid. But downloaded new gcc today, and new git. So it's one or the other. > b/ what does "gcc --version" produce? gcc (Ubuntu 4.4.2-1ubuntu3) 4.4.2 > c/ is this an incremental build from a previous build on karmic? Yes. (In fact, it's pre-alpha lucid.) It may well be that there is a new gcc that depends on a new something else that hasn't been released yet. > d/ what happens if you clean out all build files (running "git >clean -fxd" in ~/wine will do this if ~/wine is a clone of the wine >git repository) and do a build -- does that resolve the issue? Oh, that's a nice command. I'll have to remember that one. Nothing happens. >NOTE: You should still report this to gcc/Ubuntu. Noted. Reported. Bug filed. >- Reece As I was getting ready to send this I noted another gcc floating by aptitude, so I gave that one a spin. No luck. The problem persists, but I bet the developers know about it.

1 0

Wine on OpenBSD, Theo de Raadt
by Yann Droneaud 05 Nov '09

05 Nov '09

Hi, In a recent post ( <http://lwn.net/Articles/360312/> ), Theo de Raadt is criticising Linux page 0 handling. He argue that Linux allows page 0 mapping only for Wine. And OpenBSD won't allow page 0 mapping for security reasons (and performance reasons). Since Wine seems to be working on other *BSD and derivative systems, is this a problem ? Could someone comment on this issue. I don't find anything related on <http://wiki.winehq.org/OpenBSD> Regards. -- Yann Droneaud

5 7

had trouble compiling today
by Susan Cragin 05 Nov '09

05 Nov '09

It may be me. I've upgraded to Lucid Lynx. My compile failed. gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o int21.o int21.c int21.c: In function ‘INT21_GetDriveAllocInfo’: int21.c:3556: internal compiler error: in int_cst_value, at tree.c:8305 Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. make[2]: *** [int21.o] Error 1 make[2]: Leaving directory `/home/susan/wine/dlls/winedos' make[1]: *** [winedos] Error 2 make[1]: Leaving directory `/home/susan/wine/dlls' make: *** [dlls] Error 2 susan@ubuntu:~/wine$

2 1

Re: crypt32.dll: Initialize provider pointer to null before calling CryptAcquireContextW()
by Juan Lang 05 Nov '09

05 Nov '09

Hi Paul, I imagine this is to avoid checking prov if CryptAcquireContextW fails. In that case, wouldn't it be better to check the return value of CryptAcquireContextW? --Juan

2 2

Weird error for the advapi32/eventlog tests on Vista+ when running winetest
by Paul Vriens 05 Nov '09

05 Nov '09

Hi, Just noticed that we have 1 test failure on Vista+ for the advapi32/eventlog tests. I was sure I've tested these from Win95 up to Win7. When I run tests I want to do this as Administrator, so on Vista+ I select 'Run as Administrator' to start a command prompt, or to launch winetest. Running the mentioned crosscompiled tests is no problem unless you do this from the actual home directory (or any subdirectory) of the user that logged in. Winetest runs most of it's test in the %TEMP% directory and hence we see this failure. But I have no clue why (yet). Anyone? -- Cheers, Paul.

2 4

Comment request: wineconsole: Fix Alt+F10 sent when F10 pressed.
by Erich Hoover 04 Nov '09

04 Nov '09

I thought this patch was pretty straightforward, comments? http://www.winehq.org/pipermail/wine-patches/2009-October/080779.html Erich Hoover ehoover(a)mines.edu

1 0

Re: mshtml/tests: Fix events test when pointer is on a corner.
by Jacek Caban 04 Nov '09

04 Nov '09

Hi Nicolas, Nicolas Le Cam wrote: > Hi, > > Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having > errors on events tests. > > I just found that it only fails if pointer is on any corner. As I'm > always putting it on upper right corner when running winetest it was > always failing for me. > > Minimizing the test window fixed it for me. > Tested on Win2k SP4 and WinXP SP2 (both with IE6). > Minimizing window changes what we test and will break test interactive mode. We should change tests to accept cursor in left corner. Thanks, Jacek

2 4

Please write audio tests (was: Playing ULAW sample correctly?)
by Joerg-Cyril.Hoehle＠t-systems.com 04 Nov '09

04 Nov '09

Hi, >1. generate a PCM sine wave tone (like winmm/tests/wave.c); Actually any repetitive signal may not be good enough for general purpose, sine or square. Perhaps add some change in volume? For instance, there currently is a bug somewhere that causes Wine to repeat the first second of an intro animation's sound (bug #18182, comment #3) instead of continuing. This would probably not be detected. Also, the µ-law speech sample I fed to the MCI produces stuttering. Perhaps that would not be heard with a sine wave, if the periods match. Still it's better to have a test than currently no test at all! >It is also quite simple to generate sine waves without any trig. Code for sine is already in winmm/tests/wave.c No need to reinvent. Regards, Jörg Höhle

2 1

Re: winmm/tests: Add MCI waveaudio tests.
by Alexandre Julliard 04 Nov '09

04 Nov '09

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > +START_TEST(mci) > +{ > + HWND hwnd; > + hwnd = CreateWindowExA(0, "static", "winmm test", WS_POPUP, 0,0,100,100, > + 0, 0, 0, NULL); > + test_openCloseWAVE(hwnd); > + test_recordWAVE(hwnd); > + test_playWAVE(hwnd); > + test_asyncWAVE(hwnd); > + test_AutoOpenWAVE(hwnd); > + if(1) DeleteFile("tempfile.wav"); This fails to delete the file, probably because it's still open somewhere. -- Alexandre Julliard julliard(a)winehq.org

1 0

how to install a windows service in wine?
by Zhaohui Wang 04 Nov '09

04 Nov '09

Hi all I am using wine 1.1.32, can anyone tell me how to install a windows service(say NETBIOS) in wine? I saw there is a services.exe running, but I didn't find any document on winehq saying how to add new wine services. I appreciate your help Best Regards Zhao Wang

2 2

Re: mciwave: Eliminate superfluous logs.
by Alexandre Julliard 04 Nov '09

04 Nov '09

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > - WARN after ExitThread is superfluous (and not present in most other code) Most likely the ExitThread should be removed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mciwave: Use volatile on slot modified from recorder thread.
by Alexandre Julliard 04 Nov '09

04 Nov '09

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > From b45e51940a42016e25a5c3a144968d81248927ed Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?J=C3=B6rg=20H=C3=B6hle?= <hoehle(a)users.sourceforge.net> > Date: Mon, 2 Nov 2009 23:49:42 +0100 > Subject: [PATCH] mciwave: Use volatile on slot modified from recorder thread. That's wrong. If there is proper synchronization you don't need volatile, and if there isn't volatile won't magically fix it. -- Alexandre Julliard julliard(a)winehq.org

1 0

msi: Initialize string pointer to NULL
by Kirill K. Smirnov 04 Nov '09

04 Nov '09

Hi Nathan, >+ haystack_table_name = NULL; > r = table->ops->get_column_info( table, i, &col_name, NULL, > NULL, &haystack_table_name ); > if( r != ERROR_SUCCESS ) I'm afraid, but this patch silences valgrind only, but does not solves the problem. It seems to me, that if table->ops->get_column_info() succeeds, it initializes haystack_table_name, and if it fails, we do not use haystack_table_name at all (we immediately return from this function). Thus, the problem lies somewhere in get_column_info(). So it is useless (and harmful, because it confuses valgrind) to initialize it like this. -- Kirill

2 1

Re: crypt32: Implement CertAddEncodedCertificateToSystemStoreA/W
by Stefan Leichter 03 Nov '09

03 Nov '09

Am Tuesday 03 November 2009 23:32:42 schrieb Juan Lang: > These were too easy to pass up. > --Juan +BOOL WINAPI CertAddEncodedCertificateToSystemStoreW(LPCWSTR pszCertStoreName, + const BYTE *pbCertEncoded, DWORD cbCertEncoded) +{ [snip] + store = CertOpenSystemStoreA(0, pszCertStoreName); This looks wrong to me ... Bye Stefan

2 1

Playing ULAW sample correctly?
by Joerg-Cyril.Hoehle＠t-systems.com 03 Nov '09

03 Nov '09

Hi, Using the MCI, I've successfully played an ADPCM sample from Wikipedia, except at the very end of IMA ADPCM play: fixme:wavemap:wodWrite Not all src buffer has been written, expect bogus sound After play status length increased from 13813 to 13826! How comes? However, playing an ULAW sample, the same message occurs constantly (apparently once for each wavehdr played) and the sound is awfully chopped. The error could be anywhere (MCI, WAVE_MAPPER, gsm711 ACM, waveaudio ...). Are there audio tests in Wine beside winmm/wave.c? How is ulaw / how are the msacm/gsm711/gsm722/gsm602 tested? Does anybody know whether ULAW works in Wine? (Any app that uses it outside of MCI?) Thanks, Jörg Höhle

5 7

windows chromium testsuite valgrind warnings
by Dan Kegel 03 Nov '09

03 Nov '09

For what it's worth, here are the valgrind warnings from a run of my current subset of the chromium test suite under valgrind+wine: http://kegel.com/wine/chromium/valgrind-logs/errors.html Mostly they're leaks. That's good news. For the few nonleak warnings, I already filed http://bugs.winehq.org/show_bug.cgi?id=20567 for the des one in http://kegel.com/wine/chromium/valgrind-logs/base_unittests/RSAPrivateKeyUn… http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureCreato… and http://kegel.com/wine/chromium/valgrind-logs/base_unittests/SignatureVerifi… and http://bugs.winehq.org/show_bug.cgi?id=20553 for the first one in http://kegel.com/wine/chromium/valgrind-logs/unit_tests/TableViewTest.log and am puzzling over the crash later in TableViewTest (though maybe once I clear up the first error, the crash will go away). The leaks aren't quite as important. I filed a few so far: http://bugs.winehq.org/show_bug.cgi?id=20544 shell32 imagelist memory leak on unload? http://bugs.winehq.org/show_bug.cgi?id=20545 memory leak in MMDRV_Init on exit? http://bugs.winehq.org/show_bug.cgi?id=20548 Memory leak in pending overlapped I/O? http://bugs.winehq.org/show_bug.cgi?id=20551 user32 clipboard memory leaks http://bugs.winehq.org/show_bug.cgi?id=20552 Memory leak in alloc_thread_tls? and http://bugs.winehq.org/show_bug.cgi?id=20549 secur32 memory leak on exit? which is already closed (it's an upstream issue and/or notabug). Of those, I'm only worried about 20548 and 20551. - Dan

1 0

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)
by Charles Davis 03 Nov '09

03 Nov '09

Charles Davis wrote: > Hi, > > This patch series moves drive handling over to mountmgr. Mountmgr will > now associate UNIX device files directly to its created devices instead > of having ntdll handle converting something like \??\D: to > $WINEPREFIX/dosdevices/d::. This way, we can implement storage I/O > controls in mountmgr instead of ntdll, while the storage I/O controls > already in ntdll continue to work. > > It also allows drivers to associate UNIX device files to their device > objects, paving the way for separating the driver code from ntdll. > > Since nobody's said anything about my patches, I'll have to assume > they're good. (They work for me.) > > Chip > > I thought I fixed all the issues. What's wrong with my patches now? Chip

2 4

Re: eventlog tests and writing/clearing the logs
by Paul Vriens 02 Nov '09

02 Nov '09

On 11/02/2009 05:51 PM, mellery wrote: > Hi, > > Will this involve implementing advapi:RegisterTraceGuidsW, and can I > help at all? > > Thanks, > Mike Event tracing is totally different from event logging. Be my guest to pick that up ;) Maybe it's a good idea to split the advapi32/eventlog.c into eventlog.c and eventtrace.c once the tracing is fleshed out a bit more. Particularly if we move most of functionality to services.exe (as on Windows). -- Cheers, Paul.

1 0

eventlog tests and writing/clearing the logs
by Paul Vriens 02 Nov '09

02 Nov '09

Hi, I'm mostly done with the parameter tests and I'm starting to look what functional tests I can add. The biggest issues I have are: - Writing events needs to go a registered event source - Clearing an eventlog has to be with a registered event source - Registering our own event source can be done but needs a reboot to clear out any remnants. As we really want to test all of this, my proposal is to run these tests only in interactive mode. Doing so at least gives us some confidence that people know what they are doing. Worst case, they will have an extra event source that can only be deleted by removing some registry entries, a reboot and removal of the actual eventlog file (the registry removal will be part of the cleanup of course but you never know). Any thoughts on this? Correct approach? -- Cheers, Paul.

2 2

Re: gdi32: add testcases for copying an EMF from a NULL bitmap
by Nikolay Sivov 02 Nov '09

02 Nov '09

On Mon, Nov 2, 2009 at 8:27 AM, Austin English <austinenglish(a)gmail.com> wrote: > Testcase for bug 4553 Are you sure? I don't see any related patches here. > > -- > -Austin > Why there's no wine failure in this test?

2 1

Re: mciwave: Fix copy&paste errors and remove superfluous log.
by Paul Vriens 02 Nov '09

02 Nov '09

On 11/02/2009 02:56 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > - shareable is neither supported nor implemented by waveaudio (other MCIxyz support it); > Let mciOpen supply the same error code as MS-Windows. > - volatile dwPosition is recommended as the recorder thread callback updates it > (sometimes I think the whole structure should be declared volatile). > - WARN after ExitThread is superfluous (and not present in most other code) > -- should be ERR if at all. > - TRACE of wave format parameters is a duplicate and already logged a few lines earlier. > - TRUE (1) is not a valid return code in MMSYSTEM. > - INPUT/OUTPUTUNSPECIFIED is a typical example of copy&paste error. > > Later I'll fix the same in the other MCIxyz libraries (mcicda, mcimidi and mciwave are very similar, mciavi is different). I plan to patch the former 3 only. > > Regards, > Jörg Höhle > Hi Jörg, Doesn't the fact that you list 6 fixes mean you need to split up this patch? -- Cheers, Paul.

1 0

Remove NoAppDBEntry keyword?
by Austin English 02 Nov '09

02 Nov '09

Anyone opposed to removing that keyword? -- -Austin

2 1

Errors using Wordpad from Wine 1.1.6 after applying this patch
by James McKenzie 01 Nov '09

01 Nov '09

All: I've been attempting to bring Tony Rollo's EM_FORMATRANGE patch up to date and got to Wine 1.1.6. At the suggestion of Dylan Smith, I have been using Wordpad to test the patch after adding a little test because of poor display on the Print Preview. However, I've run into two what appears to be separate 'bugs'. The first occurs when I attempt to change the font size, I get an error "Invalid Number Format". The second is that I can change the displayed font one and only one time. I've reversed both of Andrey Turkin's patches that were applied between wine-1.1.5 and wine-1.1.6 but this did not resolve the error message and the inability to change fonts and actually introduced a possible third error where the font name is distorted where it shows a series of blocks and some other unintelligible data in the font display field on the screen. Any ideas on why this is happening? Patch attached with debugging code. James McKenzie

2 2

Re: [1/5] WineD3D: Add a parameter for SetRenderTarget viewport setup
by Stefan Dösinger 01 Nov '09

01 Nov '09

Am 01.11.2009 um 13:28 schrieb Stefan Dösinger: > <0001-WineD3D-SetRT-viewport-param.txt> Please use the other [1/5] patch - this one has a wrong patch description in the file

1 0

Re: dlls/winex11.drv/dib.c: initialize two warnings (RESEND)
by Alexandre Julliard 31 Oct '09

31 Oct '09

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > I looked into this in more detail, and now remember why I couldn't > do this. > > From X11DRV_GetDIBits() we invoke DIB_GetBitmapInfo() with these > two variables being passed by addresses which in turns forwards to > DIB_GetBitmapInfoEx(). And there we have a default case of > > ERR("(%d): unknown/wrong size for header\n", header->biSize ); > return -1; > > where indeed height and width are not initialized, so GCC 4.5 is right. No, because the error case causes the caller function to return without using them. The idea was to reorder the code so that gcc can figure this out, as it does already in the other cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Generate a WM_MOUSEMOVE event when warping the mouse
by Vitaliy Margolen 31 Oct '09

31 Oct '09

JesusFreke wrote: > --- > dlls/winex11.drv/mouse.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c > index 60351e5..7c24c64 100644 > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -1004,6 +1004,7 @@ BOOL CDECL X11DRV_SetCursorPos( INT x, INT y ) > XFlush( display ); /* avoids bad mouse lag in games that do their own mouse warping */ > cursor_pos = pt; > wine_tsx11_unlock(); > + queue_raw_mouse_message( WM_MOUSEMOVE, NULL, x, y, 0, GetCurrentTime(), 0, 0 ); > return TRUE; > } > Can you explain why do you need this patch? What exactly is it fixing? And have you run any tests to verify this? I'm guessing no, because you ignored that Wine will generate mouse-move event when this operation comes back to Wine from X server.

3 3

mciwave: need to serialize record and play
by Joerg-Cyril.Hoehle＠t-systems.com 31 Oct '09

31 Oct '09

Eric, I've not yet tested your patches but I thought to additionaly use STATUS_NOT_READY as an intermittent marker for work in progress, so other threads know something is going on and don't pull the carpet under the feet. What do you think? E.g. play; play from 0; play from 1000; play from 0; seek to 0; should be handled correctly (including NOTIFY ABORTED with play notify; play from 0 notify; play ... notify; seek notify). This may or may not eventually be completed by a critical section in record+play. I don't know yet. Eric, I can stop working on mciwave for the moment to avoid git conflicts and go check another D3D issue. Do you plan to work on - the record+play as well as - the 333ms issues? After the new notification system gets in play, I'll change mcimidi and mcicda. Because these are the interesting drivers, mciwave has just the advantage that it does not depend on other broken code (Timidity). BTW, I found the ADPCM and µ-law samples I use on http://en.wikipedia.org/wiki/Dct_(File_Format) Regards, Jörg Höhle.

2 3

re: Nate Gallaher : msi: Add tablename tracking to VIEW_find_column
by Dan Kegel 31 Oct '09

31 Oct '09

Hi Nate, your patch seems to have caused new valgrind warnings, could you have a look? Found via http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/diff-msi_db.txt Details at http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/vg-msi_db.txt Conditional jump or move depends on uninitialised value(s) at RtlFreeHeap (heap.c:1460) by msi_free (msipriv.h:1099) by VIEW_find_column (msiquery.c:82) by SELECT_AddColumn (select.c:392) by SELECT_CreateView (select.c:436) by INSERT_CreateView (insert.c:393) by sql_parse (sql.y:149) by MSI_ParseSQL (sql.y:960) by MSI_DatabaseOpenViewW (msiquery.c:137) by MsiDatabaseOpenViewW (msiquery.c:279) by MsiDatabaseOpenViewA (msiquery.c:110) by test_streamtable (db.c:1443) by func_db (db.c:8546) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at VIEW_find_column (msiquery.c:60) ... 2 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc_zero (msipriv.h:1082) by table_create_new_row (table.c:1504) by TABLE_insert_row (table.c:1712) by TABLE_modify (table.c:1860) by MSI_ViewModify (msiquery.c:623) by MsiViewModify (msiquery.c:644) by test_viewmodify_delete_temporary (db.c:5892) by func_db (db.c:8570) by run_test (test.h:535) by main (test.h:585) ... 4 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_create_table (table.c:664) by CREATE_execute (create.c:72) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_droptable (db.c:7073) by func_db (db.c:8580) by run_test (test.h:535) by main (test.h:585) ... 4 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_makestring (table.c:943) by get_tablecolumns (table.c:1016) by table_get_column_info (table.c:608) by msi_update_table_columns (table.c:1053) by TABLE_remove_column (table.c:2040) by TABLE_drop (table.c:2293) by DROP_execute (drop.c:60) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_dbmerge (db.c:7408) by func_db (db.c:8581) by run_test (test.h:535) by main (test.h:585) ... 224 bytes in 28 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_makestring (table.c:943) by get_tablecolumns (table.c:1014) by table_get_column_info (table.c:608) by msi_update_table_columns (table.c:1053) by TABLE_remove_column (table.c:2040) by TABLE_drop (table.c:2293) by DROP_execute (drop.c:60) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_dbmerge (db.c:7385) by func_db (db.c:8581) by run_test (test.h:535) by main (test.h:585)k It also fails here: db.c:5260: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 db.c:5336: Test failed: Expected 4, got 8 db.c:5337: Test failed: Unexpected data db.c:5352: Test failed: Unexpected data db.c:5378: Test failed: Expected 64, got 68 db.c:5379: Test failed: Unexpected data db.c:6993: Test failed: Expected "", got "grape" db.c:6994: Test failed: Expected 0, got 5 db.c:7052: Test failed: Expected "", got "grape" db.c:7053: Test failed: Expected 0, got 5

2 2

Re: msvcrt: do not overlap in strcpy (valgrind) (try 2)
by Vitaliy Margolen 31 Oct '09

31 Oct '09

André Hentschel wrote: > > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index 010e1a6..08eaf73 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -856,7 +856,7 @@ char * CDECL _ecvt( double number, int ndigits, int *decpt, int *sign ) > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + memmove( data->efcvt_buffer + 1, data->efcvt_buffer + 2, strlen(data->efcvt_buffer) ); You don't need additional strlen. You already have a length from snprintf (that's returned but not assigned to anything). Vitaliy.

2 2

d3d10
by "Luis C. Busquets Pérez" 31 Oct '09

31 Oct '09

Dear all, Since d3d10effect has advanced a lot during the latest weeks I was wondering what are the next steps that you are planning to develop. In particutar, I wonder about: 1. Do DepthStencil and RasterizerState present major differences in terms of capabilities compared to D3D9? I mean that coding ID3D10EffectDepthStencilVariable <http://msdn.microsoft.com/en-us/library/ee418970%28VS.85%29.aspx> is very easy once you have ID3D10DepthStencilState (just call ID3D10Device_CreateDepthStencilState for <http://msdn.microsoft.com/en-us/library/bb173546%28VS.85%29.aspx>ID3D10EffectDepthStencilVariable::GetDepthStencilState and <http://msdn.microsoft.com/en-us/library/bb173641%28VS.85%29.aspx>ID3D10EffectDepthStencilVariable::GetBackingStore <http://msdn.microsoft.com/en-us/library/bb173640%28VS.85%29.aspx> should only be recovering the data from a private variable). Furthermore, ID3D10Device::OMSetDepthStencilState is just a bunch of IWineD3DDevice_SetRenderState calls because I think that wined3d already implements all the required functionality, doesn't it?. ID3D10Device::OMGetDepthStencilState <http://msdn.microsoft.com/en-us/library/bb173593%28VS.85%29.aspx> would be a bunch of IWineD3DDevice_GetRenderState. ID3D10EffectRasterizerVariable. <http://msdn.microsoft.com/en-us/library/bb173640%28VS.85%29.aspx> presents the analogous thing (together with ID3D10Device::RSSetState), doesn't it? 2. For ID3D10EffectBlendVariable <http://msdn.microsoft.com/en-us/library/ee418962%28VS.85%29.aspx> I think that that is different. what are the major difficulties concerning the capabilities that D3D10 offers compared to D3D9 conerning blending and do you see them achievable beofre this year ends? 3. Last, for ID3D10Device::RSGetViewports/ID3D10Device::RSSetViewports and ID3D10Device::RSGetScissorRects/ID3D10Device::RSSetScissorRects, the difficulty may lay in accepting in the wine driver more thatn one rect/viewport. Do you agree? Are you planning an upgrade in wined3d to refer to *rect rather than rect in the stateblock definition? The analogous question applies to viewports. I was wondering all that because I am considering asking Santa for D3D10 games for next Christmas and would like to know the roadmap of wine D3D10 development.

2 1

Another virus-in-wine story
by Dan Kegel 31 Oct '09

31 Oct '09

This is about the fifth article of this sort, so it's not really news anymore, but it's still fun to read about. TFA is clueless about how to clean up a wine installation (he thought uninstalling wine would do it), buts lots of readers supply the missing clue. http://linux.slashdot.org/story/09/10/24/1759213/Now-Linux-Can-Get-Viruses-…

8 13

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 31 Oct '09

31 Oct '09

On Saturday 31 October 2009 11:10:35 Michael Martin wrote: > Understand, > I guess ill write some wine test to check different return values for differences on mapped files. > Can you give me a pointer on where this would best fit in? > kernel32/tests/file.c: test_CopyFileW, or should i make my own function for the tests? This likely also affects CreateFile, MoveFile, etc, so I would create a new function for it. -Hans

1 0

Re: comctl32/tests: make v6 functions inline
by Nikolay Sivov 31 Oct '09

31 Oct '09

2009/10/31 André Hentschel <nerv(a)dawncrow.de>: > So that there are no warnings if tests only use the constant variables in that header. > --- > dlls/comctl32/tests/v6util.h | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/v6util.h b/dlls/comctl32/tests/v6util.h > index 21a8e4f..ae3dbbe 100644 > --- a/dlls/comctl32/tests/v6util.h > +++ b/dlls/comctl32/tests/v6util.h > @@ -56,7 +56,7 @@ static const CHAR manifest[] = > "</dependency>\n" > "</assembly>\n"; > > -static void unload_v6_module(ULONG_PTR cookie) > +static inline void unload_v6_module(ULONG_PTR cookie) > You're using old source tree. Current prototype is: --- static void unload_v6_module(ULONG_PTR cookie, HANDLE hCtx) --- Why do you need such changes? I don't think inline it's useful here.

2 1

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 31 Oct '09

31 Oct '09

On Saturday 31 October 2009 05:22:31 you wrote: > I haven't came across an installer yet that fails on WINE because of this. > I have jumped ahead a bit here. > > Regardless, if a file has been mapped by using CreateFileMapping/MapViewOfFile > and the CopyFile api (having the last parameter as FALSE) is used in an attempt > to overwrite it, CopyFile will of course fail. > In Windows, XP and 2k at least, GetLastError in this case will return > ERROR_USER_MAPPED_FILE. Currently WINE does not return this error code, actually > it returns ERROR_ALREADY_EXISTS which is incorrect. So that would have to be > fixed in WINE to see the problem in an msi installer. > > Im assuming Im gonna have to create a test for for kernel32/file.c showing the > wrong error set for CopyFile failing in that case before this patch can be accepted? It would need a fix as well. There's no point in checking for this error if Wine doesn't return it. -Hans

1 0

Implement source alpha plus SourceConstantAlpha combined transparency.
by Jaime Rave 30 Oct '09

30 Oct '09

Anything wrong with this patch?? It helps a lot in MSN Messenger and some other programs. http://www.winehq.org/pipermail/wine-patches/2009-October/080539.html Jaime Rave Torrres

2 1

Re: [PATCH] MSI: Shedule rename operation also for ERROR_USER_MAPPED_FILE.
by Hans Leidekker 30 Oct '09

30 Oct '09

On Friday 30 October 2009 14:10:27 Michael Martin wrote: > Add check for ERROR_USER_MAPPED_FILE in addition to ERROR_SHARING_VIOLATION > when scheduling a rename operation. ERROR_USER_MAPPED_FILE can be set when > trying to overwrite true type fonts in windows. > For more info see http://support.microsoft.com/kb/944507 Which installer is affected by this? -Hans

1 0

Order of setting audio Play/Pause state and device opening
by Joerg-Cyril.Hoehle＠t-systems.com 30 Oct '09

30 Oct '09

Ken, I was please to see your recent changes to winecoreaudio. In my quest for audio bugs, when I reviewed the code, I found the following which I believe is wrong or I don't understand. Maybe you could look at it? BTW, the code and comments are the same in both wineoss.drv and winecoreaudio.drv. In audio.c/wodPause: /* The order of the following operations is important since we can't hold * the mutex while we make an Audio Unit call. Stop the Audio Unit before * setting the PAUSED state. That's indeed what the code below does. * Although we can be in PAUSED * state with the Audio Unit still running, Quite to the contrary, PAUSED state is only set after the unit stopped. * that's harmless because the * render callback will just produce silence. I can't comment on that. The code is (error checking not shown): status = AudioOutputUnitStop(wwo->audioUnit); OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PLAYING) wwo->state = WINE_WS_PAUSED; OSSpinLockUnlock(&wwo->lock); In audio.c/wodRestart: * In wodRestart, the order is reversed. Indeed. * This guarantees that we can't get into a situation where the state is * PLAYING but the Audio Unit isn't running. Quite to the contrary, PLAYING state is reached yet AudioOutputUnitStart is only called a few instructions afterwards. Likewise above, it's stopped and PLAYING state is only unset afterwards. OSSpinLockLock(&wwo->lock); if (wwo->state == WINE_WS_PAUSED) wwo->state = WINE_WS_PLAYING; OSSpinLockUnlock(&wwo->lock); status = AudioOutputUnitStart(wwo->audioUnit); Is my understanding wrong? Does the code need be changed to reflect the comments? Do the comments need correction? Thanks, Jorg Hohle

2 1

Re: wined3d: recognize Nvidia 8500 GT
by Roderick Colenbrander 30 Oct '09

30 Oct '09

We use this mechanism on purpose. We can't have hundreds of cards in the database. The real name isn't that important it is mostly cosmetic, so it is not a real bug. Roderick

2 1

Re: kernel32/tests: add more tests for Formatmessage{A,W} (try 2)
by Paul Vriens 30 Oct '09

30 Oct '09

On 10/29/2009 01:09 AM, Louis Lenders wrote: > changes: > > -fixed typo in ok-call > -removed FormatMessageW-tests (W behaves same as A) > -removed useless test for GetLastError in case FormatMessageA succeeds > > Hi Louis, These new tests introduce some test failures on several platforms: http://test.winehq.org/data/tests/kernel32:format_msg.html On Win9x/WinMe it seems like just another last error. There seems to be an issue with a particular test when run on a Windows box with no English locale (or something different about the locale): http://test.winehq.org/data/1be99033b1892aa59589e7997f4c5a0ce77e2b42/2000_w… On Vista/Win7/W2K8 there are also different last errors but some are not yet defined in our headers: 15100 : ERROR_MUI_FILE_NOT_FOUND 15105 : ERROR_MUI_FILE_NOT_LOADED Could you have a look? -- Cheers, Paul.

3 2

Re: msvcrt: dont overlap in strcpy (valgrind)
by Vitaliy Margolen 30 Oct '09

30 Oct '09

André Hentschel wrote: > here is a case where valgrind claims about "Source and destination overlap in strcpy". > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + { > + char *src = data->efcvt_buffer + 2, *dest = data->efcvt_buffer + 1; > + while ((*dest++=*src++) != 0); > + } You should use memmove instead. Vitaliy.

1 0

Re: [Bug 20505] After winetricks comctl32, wine does not work completely
by James Mckenzie 29 Oct '09

29 Oct '09

> >wine-bugs(a)winehq.org ha scritto: >> http://bugs.winehq.org/show_bug.cgi?id=20505 >> >> >> Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|RESOLVED |CLOSED >> >> >> >> >> --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-10-28 23:53:57 --- >> Closing invalid. >> > >This one happens here too, and it used to work before, so IMHO is a regression. > I beg to differ. The use of winetricks to get around shortcomings of Wine is not a Wine developer issue and should be addressed to Dan Kegel and Austin English. James McKenzie

3 2

Re: New valgrind results for Oct 26, 2009
by André Hentschel 29 Oct '09

29 Oct '09

Dan Kegel schrieb: > 2009/10/28 André Hentschel <nerv(a)dawncrow.de>: >> I think i found a false postitv. its http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-ntdll_env.txt >> the code in ntdll/tests/env.c looks like: >> ... >> name.Buffer = bn; >> ... >> value.Buffer = bv; >> ... >> nts = pRtlQueryEnvironmentVariable_U(small_env, &name, &value); >> ... >> if(memcmp(bv, bn, test->len*sizeof(WCHAR)) == 0) >> >> So valgrind thinks bn and bv are uninitialised, but thats wrong. >> Do you agree with me? > > I actually looked at this one for an hour the other day. > I think valgrind's probably right, but the test is confusingly written. So i send this issue to wine-devel to know what other devs think about it. -- Best Regards, André Hentschel

1 0

Re: crypt32: CryptUnprotectData: test zero-length payload
by Paul Vriens 29 Oct '09

29 Oct '09

On 10/28/2009 02:40 AM, Dan Kegel wrote: > Passes on Vista and on Wine (with one todo_wine). > Exposes http://bugs.winehq.org/show_bug.cgi?id=20495 > > (Note: 'make crosstest' doesn't work stunningly well in > crypt32 for me -- there were lots of undefined symbols -- > but fortunately the file this test is in compiles ok standalone. > Had to use LoadLibrary rather than GetModuleHandle, > else it failed to run standalone.) > > Hi Dan, Some testfailures on everything below W2K. Some tests were already skipped because of this. I tried several things but the last error is always set to RPC_X_WRONG_STUB_VERSION. Maybe we should test for that before we do any tests and bail out? Does this error make sense on 9x/Me/NT4? -- Cheers, Paul.

2 2

Re: [Bug 20505] After winetricks comctl32, wine does not work completely
by Massimo Del Fedele 29 Oct '09

29 Oct '09

wine-bugs(a)winehq.org ha scritto: > http://bugs.winehq.org/show_bug.cgi?id=20505 > > > Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > > > --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-10-28 23:53:57 --- > Closing invalid. > This one happens here too, and it used to work before, so IMHO is a regression. Max

1 0

Debug help needed : Unhandled page fault on read access to 0xffffffff]
by Philippe De Muyter 29 Oct '09

29 Oct '09

Hello Alexandre, It's a long time now since my last contrib to the wine project (1997), and I try to run a proprietary W31/W95 program without any success : It fails immediately with : wine: Unhandled page fault on read access to 0xffffffff at address 0x124f:0x000090f7 (thread 001c), starting debugger... At that stage I do not have any window of the windows program, only a window from wine stating : The program winevdm.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience. After I close this window, I get debug output from wine (appended below). I do not remember how I could find where the crash happens, and hence why, in the hope of fixing it. Could give me some hint ? Philippe Unhandled exception: page fault on read access to 0xffffffff in 16-bit code (124f:90f7). fixme:dbghelp:addr_to_linear Failed to linearize address 0112:0000674d (mode 0) fixme:dbghelp:addr_to_linear Failed to linearize address 0111:0000ef00 (mode 0) In 16 bit mode. Register dump: CS:124f SS:13bf DS:13bf ES:0000 FS:0033 GS:003b IP:90f7 SP:962c BP:9634 FLAGS:0202( R- -- I - - - ) AX:0c4e BX:0000 CX:16ff DX:19df SI:0c3b DI:ab5f Stack dump: 0x13bf:0x962c: ab5f 0001 0000 13bf 96e3 b3af 1217 9688 0x13bf:0x963c: 13bf 0000 0000 4eb2 4cf6 b811 0004 0000 0x13bf:0x964c: 036f 1457 0000 0001 aac9 1217 145f 018c 0277: sel=13bf base=0091c738 limit=0000fcdf 16-bit rw- Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000) 0x124f:0x90f7: movb %es:0x0(%bx),%bl Modules: Module Address Debug info Name (101 modules) ELF 7b800000-7b96f000 Deferred kernel32<elf> \-PE 7b820000-7b96f000 \ kernel32 ELF 7bc00000-7bcaf000 Deferred ntdll<elf> \-PE 7bc10000-7bcaf000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7dd50000-7dd82000 Deferred libcrypt.so.1 ELF 7dd82000-7dec7000 Deferred libcrypto.so.0.9.8 ELF 7dec7000-7df0a000 Deferred libssl.so.0.9.8 ELF 7df0a000-7df3c000 Deferred libcups.so.2 ELF 7df44000-7df5a000 Deferred shell.dll16.so PE 7df50000-7df5a000 Deferred shell.dll16 ELF 7df5a000-7df73000 Deferred spoolss<elf> \-PE 7df60000-7df73000 \ spoolss ELF 7df73000-7df92000 Deferred localspl<elf> \-PE 7df80000-7df92000 \ localspl ELF 7dfb6000-7e021000 Deferred rpcrt4<elf> \-PE 7dfc0000-7e021000 \ rpcrt4 ELF 7e021000-7e11a000 Deferred ole32<elf> \-PE 7e040000-7e11a000 \ ole32 ELF 7e144000-7e178000 Deferred uxtheme<elf> \-PE 7e150000-7e178000 \ uxtheme ELF 7e178000-7e1ac000 Deferred winspool<elf> \-PE 7e180000-7e1ac000 \ winspool ELF 7e1ac000-7e273000 Deferred comctl32<elf> \-PE 7e1c0000-7e273000 \ comctl32 ELF 7e273000-7e2cf000 Deferred shlwapi<elf> \-PE 7e280000-7e2cf000 \ shlwapi ELF 7e2cf000-7e45f000 Deferred shell32<elf> \-PE 7e2e0000-7e45f000 \ shell32 ELF 7e45f000-7e511000 Deferred comdlg32<elf> \-PE 7e470000-7e511000 \ comdlg32 ELF 7e511000-7e525000 Deferred win87em.dll16.so PE 7e520000-7e525000 Deferred win87em.dll16 ELF 7e525000-7e550000 Deferred ws2_32<elf> \-PE 7e530000-7e550000 \ ws2_32 ELF 7e550000-7e568000 Deferred winsock.dll16.so PE 7e560000-7e568000 Deferred winsock.dll16 ELF 7e568000-7e57d000 Deferred sound.drv16.so PE 7e570000-7e57d000 Deferred sound.drv16 ELF 7e57d000-7e591000 Deferred mouse.drv16.so PE 7e580000-7e591000 Deferred mouse.drv16 ELF 7e591000-7e5a6000 Deferred keyboard.drv16.so PE 7e5a0000-7e5a6000 Deferred keyboard.drv16 ELF 7e5a6000-7e5bb000 Deferred display.drv16.so PE 7e5b0000-7e5bb000 Deferred display.drv16 ELF 7e5bb000-7e5cf000 Deferred comm.drv16.so PE 7e5c0000-7e5cf000 Deferred comm.drv16 ELF 7e5cf000-7e5f5000 Deferred msacm32<elf> \-PE 7e5e0000-7e5f5000 \ msacm32 ELF 7e5f5000-7e6b1000 Deferred libasound.so.2 ELF 7e6ba000-7e6cf000 Deferred midimap<elf> \-PE 7e6c0000-7e6cf000 \ midimap ELF 7e6cf000-7e706000 Deferred winealsa<elf> \-PE 7e6e0000-7e706000 \ winealsa ELF 7e706000-7e7a1000 Deferred winmm<elf> \-PE 7e710000-7e7a1000 \ winmm ELF 7e7a1000-7e803000 Deferred winedos<elf> \-PE 7e7b0000-7e803000 \ winedos ELF 7e803000-7e809000 Deferred libxfixes.so.3 ELF 7e809000-7e813000 Deferred libxcursor.so.1 ELF 7e813000-7e81a000 Deferred libxrandr.so.2 ELF 7e81a000-7e823000 Deferred libxrender.so.1 ELF 7e823000-7e829000 Deferred libxxf86vm.so.1 ELF 7e829000-7e82d000 Deferred libxinerama.so.1 ELF 7e82d000-7e84e000 Deferred imm32<elf> \-PE 7e830000-7e84e000 \ imm32 ELF 7e84e000-7e867000 Deferred libxcb.so.1 ELF 7e867000-7e982000 Deferred libx11.so.6 ELF 7e982000-7e991000 Deferred libxext.so.6 ELF 7e991000-7e9aa000 Deferred libice.so.6 ELF 7e9aa000-7e9b3000 Deferred libsm.so.6 ELF 7e9b7000-7e9cf000 Deferred msacm32<elf> \-PE 7e9c0000-7e9cf000 \ msacm32 ELF 7e9d1000-7ea6d000 Deferred winex11<elf> \-PE 7e9e0000-7ea6d000 \ winex11 ELF 7eb25000-7eb46000 Deferred libexpat.so.1 ELF 7eb46000-7eb72000 Deferred libfontconfig.so.1 ELF 7eb72000-7eb85000 Deferred libz.so.1 ELF 7eb85000-7ebf4000 Deferred libfreetype.so.6 ELF 7ebf4000-7ebf7000 Deferred libxcb-xlib.so.0 ELF 7ebf7000-7ebfb000 Deferred libxau.so.6 ELF 7ec12000-7ec27000 Deferred system.drv16.so PE 7ec20000-7ec27000 Deferred system.drv16 ELF 7ec27000-7ec7d000 Deferred advapi32<elf> \-PE 7ec30000-7ec7d000 \ advapi32 ELF 7ec7d000-7ed1c000 Deferred gdi32<elf> \-PE 7ec90000-7ed1c000 \ gdi32 ELF 7ed1c000-7ee64000 Deferred user32<elf> \-PE 7ed40000-7ee64000 \ user32 ELF 7ee64000-7ee6e000 Deferred libnss_files.so.2 ELF 7ee6e000-7ee78000 Deferred libnss_nis.so.2 ELF 7ee78000-7ee80000 Deferred libnss_compat.so.2 ELF 7ee88000-7ee9e000 Deferred winevdm<elf> \-PE 7ee90000-7ee9e000 \ winevdm ELF 7efbd000-7efe2000 Deferred libm.so.6 ELF 7efe8000-7efff000 Deferred libnsl.so.1 ELF b7c84000-b7c88000 Deferred libdl.so.2 ELF b7c88000-b7dbb000 Deferred libc.so.6 ELF b7dbb000-b7dd2000 Deferred libpthread.so.0 ELF b7df0000-b7f2b000 Deferred libwine.so.1 ELF b7f2c000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000e 00000014 0 00000010 0 0000000f 0 00000011 00000018 0 00000017 0 00000013 0 00000012 0 00000019 (D) C:\windows\system32\winevdm.exe 0000001c 0 <== 0000001b 0 0000001a 0 0000001d 0000001e 0 Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000)

3 2

Re: [1/2] shell32/tests: Program Manager DDE Conformance Tests
by Vitaliy Margolen 29 Oct '09

29 Oct '09

Mike wrote: > Vitaliy, > > Thanks for the quick feedback. I'll make the changes you've suggested and > repost, probably next week. A couple quick questions about your comments: > > Indentation: >> Tabs should always be set to 8 spaces, not 4. For Wine >> please use 4-space >> indentations, no tabs please. >> > Your response was not clear. Is the correct indentation 8 spaces, no Ctrl-I (ascii 0x09)? No. Tab character (0x09) is 8 positions long, not 4. Please do not use it at all in Wine, unless it's a Makefile. Wine's default indentation is 4 spaces (0x20). > > Detecting Windows Version: >>> +int IsWin9x(void) >>> +{ >>> + return (GetVersion() & >> 0x80000000); >>> +} >> Don't add this sort of functions. All tests should work on >> all Windows >> versions. Or you should detect differences by other means. CSIDL_PROGRAM_FILES_COMMON is not supported in Win 95, 98, or ME and so the directory where things are created changes. What is the correct method to determine whether to use this or not for Wine Conformance Tests? If I recall correctly, this was the only change needed to make the test run in Win 98. If a call to SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES_COMMON failes assume it's win9x and use the CSIDL_PROGRAMS. Or check both places. Or something along these lines. Vitaliy.

1 0

for the record, my ole32 binary tree search patch is correct
by Vincent Povirk 29 Oct '09

29 Oct '09

I sent the following patch recently: commit ee6856d874d687c4504914e61bcde3e6b8823bca Author: Vincent Povirk <madewokherd(a)gmail.com> Date: Fri Oct 23 13:57:42 2009 -0500 ole32: Don't use IEnumSTATSTG to search for elements of storages. We use it to do a linear search of a binary tree, which is overkill. Replace it with a simple binary search. It was accepted and caused this bug: http://bugs.winehq.org/show_bug.cgi?id=20477 It actually turned out that the mistake was in a previous patch, but it didn't matter for reading files until we started to depend on the tree to be valid. Nonetheless, I've done a test to make sure we can really rely on the binary trees in storage files to be valid. I wrote two programs: one that reads the directory entries of a storage file and prints some information to stdout (useful for debugging), and one that swaps the left and right child of every directory entry, corrupting the trees in the file. It turns out that corrupting an msi file in this way makes it fail on both windows and on wine (although it crashes on wine; msi's error handling code is broken). Running the program again (thus swapping the children back to their original, correct position) makes it work. However, on an older version of Wine without my change, the corrupted msi file loads fine. This means that Windows does depend on the tree in a storage file to be correct, and Wine's behavior is now closer to Windows, even though it now fails in some cases when it used to succeed. (I think that current Wine without the fix for bug 20477 will load only the corrupted files, but I didn't test this.) I've attached my test programs so they're in the public record. -- Vincent Povirk

2 3

kernel32: add more tests for FormatMessage{A,W}
by Louis Lenders 28 Oct '09

28 Oct '09

>FormatMessage uses the same backend to find the requested resource as >FindResource does, so I'd guess that they both fail in the same way >when a resource id or a language does not exist in the module. I still fail to see how I can call FindResource for a missing message-id. In the end they both use LdrFindResource_U but I guess that's not what you meant to test. I still have tthe problem to first load the messagetable with FindResource, and I cannot use a call to FindResource to ask for a present or missing message-id. I'll resend the patch with your other two suggenstions, if the patch is not accepted i'll leave it to someone else (more experienced) to take this up

1 0

Re: [PATCH 01/12] d3d10: Fix a HeapFree() in d3d10_effect_Release().
by Stefan Dösinger 28 Oct '09

28 Oct '09

Am 27.10.2009 um 20:10 schrieb Rico Schüller: > Hi, > > this patch series implements a couple of ID3D10EffectVariable::As*() > functions (patches 2-11). Do we have any tests for the As* behavior? Most conversions don't make any sense, so if the app wants a constant buffer as a render target view returning a null obj is probably a sane thing. But ::AsString potentially makes sense for all objects, maybe in a similar way Object::ToString is used to obtain a String for debug output in Java. Also, do we know what happens if the object is "converted" back to its original state? E.g. constant_buffer = render_target_view::AsConstantBuffer(); render_target_view2 = constantBuffer::AsRenderTargetView? As far as I understand it, your code would return a null rt view. Is this correct?

4 4

CPPcheck October 27 Git
by chris ahrendt 28 Oct '09

28 Oct '09

Current Leaks: [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd Tool Leaks: [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:388]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/pe.c:1547]: (error) Memory leak: map Ignored Test Leaks: [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (error) Array index out of bounds [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1117]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1101]: (possible error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem Chris

1 0

kernel32: add more tests for FormatMessage{A,W}
by Louis Lenders 28 Oct '09

28 Oct '09

>FormatMessage uses the same backend to find the requested resource as >FindResource does, so I'd guess that they both fail in the same way >when a resource id or a language does not exist in the module. Parsing >an actual resource data is not necessary. ok, but isn't that test already in tests/resource.c? See code snippet below: Or do i get it wrong? rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_NEUTRAL, SUBLANG_NEUTRAL )); ok( rsrc != 0, "resource not found\n" ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_GERMAN, SUBLANG_DEFAULT )); ok( rsrc != 0, "resource not found\n" ); SetLastError( 0xdeadbeef ); rsrc = FindResourceW( GetModuleHandle(0), (LPCWSTR)MAKEINTRESOURCE(1), (LPCWSTR)RT_DIALOG ); ok( !rsrc, "resource found\n" ); ok( GetLastError() == ERROR_RESOURCE_TYPE_NOT_FOUND, "wrong error %u\n", GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceW( GetModuleHandle(0), (LPCWSTR)MAKEINTRESOURCE(2), (LPCWSTR)RT_MENU ); ok( !rsrc, "resource found\n" ); ok( GetLastError() == ERROR_RESOURCE_NAME_NOT_FOUND, "wrong error %u\n", GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT ) ); ok( !rsrc, "resource found\n" ); ok( GetLastError() == ERROR_RESOURCE_LANG_NOT_FOUND, "wrong error %u\n", GetLastError() ); SetLastError( 0xdeadbeef ); rsrc = FindResourceExW( GetModuleHandle(0), (LPCWSTR)RT_MENU, (LPCWSTR)MAKEINTRESOURCE(1), MAKELANGID( LANG_FRENCH, SUBLANG_DEFAULT ) ); ok( !rsrc, "resource found\n" ); ok( GetLastError() == ERROR_RESOURCE_LANG_NOT_FOUND, "wrong error %u\n", GetLastError() ); }

2 1

kernel32: add more tests for FormatMessage{A,W}
by Louis Lenders 28 Oct '09

28 Oct '09

>A couple of suggestions: >1. There is no point in testing last error if an API didn't fail Couldn't it be that the API sets ERROR_SUCCES if it doesn't fail? >2. It would be helpful to simultaneously test return values and >last error for FindResource, which should have similar behaviour >(and the bug) to FormatMessage Could you explain a bit more what exactly to test? I can load the whole messagetable with FindResource from kernel32, but that always succeeds of course. Using the MESSAGE_RESOURCE_BLOCK and MESSAGE_RESOURCE_ENTRY structures I could I load a messagestring I guess, but that doesn't test the behaviour of FindResource anymore. Or do i see things wrong here? Trying to load a non existing messagetable from another dll with FindResource gives ERROR_RESOURCE_TYPE_NOT_FOUND. Or is that not what you meant? >and drop FormatMessageW tests. Ok i'll do that

2 1

Re: [PATCH 5] winmm/tests: Add MCI waveaudio tests.
by Alexandre Julliard 28 Oct '09

28 Oct '09

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > -START_TEST(mci) > +#ifndef FULL_TEST > +/* Some tests hang or crash Wine. Enable once fixed. */ > +#define FULL_TEST 0 > +#endif Please don't introduce dead code. If the tests really can't work then don't add them at all until you have the corresponding fixes. -- Alexandre Julliard julliard(a)winehq.org

4 5

Extracting yet more wine tests from the chromium test suite
by Dan Kegel 28 Oct '09

28 Oct '09

http://kegel.com/wine/chromium/ now has a precompiled tarball containing 13 of chromium's test programs: app_unittests base_unittests courgette_unittests googleurl_unittests ipc_tests media_unittests net_unittests printing_unittests sbox_unittests sbox_validation_tests setup_unittests tcmalloc_unittests unit_tests (These are, more or less, all the ones that run in under a minute on Windows. There are some big tests left, but I figured this was enough to chew on for a while.) http://kegel.com/wine/chromium/failures.txt lists the 50 test cases which fail (but not crash) in which executable. http://kegel.com/wine/chromium/chromium-runtests.sh.txt has a little documentation, and shows how to skip the handful of tests that crash or hang. I'm slowly starting to file bugs and/or testcases for these, starting with http://bugs.winehq.org/show_bug.cgi?id=20495. (It took me a while to do that one today - writing the wine test case was easy, but figuring out why it passed but the real test didn't required pulling out the important part of the logs for both and flipping back and forth between them in an editor. Once I did that, it was trivial.) I don't actually expect the sandbox tests to work any time soon, but they're there if anyone's interested. - Dan

1 1

Re: [1/2] shell32/tests: Program Manager DDE Conformance Tests
by Vitaliy Margolen 28 Oct '09

28 Oct '09

Mike wrote: > Conformance Tests to test the Program Manager DDE. Currently stubbed in Wine, bug 9159. Has been tested on Win XP SP2 and Win 98 SE. > > --- > dlls/shell32/tests/Makefile.in | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/shell32/tests/Makefile.in b/dlls/shell32/tests/Makefile.in > index dd0587c..0cad860 100644 > --- a/dlls/shell32/tests/Makefile.in > +++ b/dlls/shell32/tests/Makefile.in > @@ -9,6 +9,7 @@ CTESTS = \ > appbar.c \ > autocomplete.c \ > generated.c \ > + progman_dde.c \ > shelllink.c \ > shellpath.c \ > shfldr_special.c \ > -- This can't work on it's own and should be merged with your next patch. > +HDDEDATA CALLBACK DdeCallback(UINT type, > + UINT format, > + HCONV hConv, > + HSZ hsz1, > + HSZ hsz2, > + HDDEDATA hDDEData, > + ULONG_PTR data1, > + ULONG_PTR data2) > +{ > + trace("Callback: type=%i, format=%i\n", type, format); > + return NULL; > +} > + Tabs should always be set to 8 spaces, not 4. For Wine please use 4-space indentations, no tabs please. > +int IsWin9x(void) > +{ > + return (GetVersion() & 0x80000000); > +} Don't add this sort of functions. All tests should work on all Windows versions. Or you should detect differences by other means. > +/* Transfer DMLERR's into text readable strings for Error Messages */ > +const char * GetStringFromError(UINT err) > +{ > + const char * retstr; > + switch (err) > + { > + case DMLERR_NO_ERROR: > + retstr = "DMLERR_NO_ERROR"; > + break; > + case DMLERR_ADVACKTIMEOUT: > + retstr = "DMLERR_ADVACKTIMEOUT"; > + break; > + case DMLERR_BUSY: Use ## macro for this instead. See examples throughout the code-base. > + window = FindWindow(NULL, winName); > + SendMessage(window, WM_SYSCOMMAND, SC_CLOSE, 0); You should explicitly specify A or W variant of the function in tests. > + path = (char *) malloc(MAX_PATH); Don't use malloc in tests, use HeapAllock instead. > + DdeExecuteCommand(instance, hConv, (char *) "[InvalidCommand()]", &hData, &error, DDE_TEST_MISC|testnum++); This is wrong - don't cast away const pointers. If you getting warnings that means you doing something wrong. Vitaliy.

1 0

re: d3d10: Parse local_variables.
by Dan Kegel 27 Oct '09

27 Oct '09

(Spotted by http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-d3d10_effect.txt ) Hi Rico, the patch commit b55641f14a210f689cde8b08750a78779657c06e Author: Rico Schüller <kgbricola(a)web.de> Date: Sun Oct 25 17:11:49 2009 +0100 d3d10: Parse local_variables. seems to have introduced the following valgrind error: http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-d3d10_effect.txt Invalid free() / delete / delete[] at notify_free (heap.c:222) by RtlFreeHeap (heap.c:1474) by d3d10_effect_Release (effect.c:1649) by test_effect_constant_buffer_type (effect.c:193) by func_effect (effect.c:1128) by run_test (test.h:535) by main (test.h:585) Address 0x7f03def0 is 104 bytes inside a block of size 112 alloc'd at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by D3D10CreateEffectFromMemory (d3d10_main.c:218) by test_effect_constant_buffer_type (effect.c:93) by func_effect (effect.c:1128) by run_test (test.h:535) by main (test.h:585) and a number of small leaks of the form 0 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by parse_fx10_body (effect.c:1280) by parse_fx10 (effect.c:1394) by fx10_chunk_handler (effect.c:1408) by parse_dxbc (effect.c:157) by d3d10_effect_parse (effect.c:1418) by D3D10CreateEffectFromMemory (d3d10_main.c:230) by test_effect_variable_element (effect.c:665) by func_effect (effect.c:1131) by run_test (test.h:535) by main (test.h:585) Could you have a look? Thanks, Dan

2 1

[RFC] mshtml/tests: Fix events test when pointer is on a corner.
by Nicolas Le Cam 27 Oct '09

27 Oct '09

Hi, Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having errors on events tests. I just found that it only fails if pointer is on any corner. As I'm always putting it on upper right corner when running winetest it was always failing for me. Minimizing the test window fixed it for me but I'm not sure it's the right fix, so I'm sending it to wine-devel. Tested on Win2k SP4 and WinXP SP2 (both with IE6). -- Nicolas Le Cam

1 0

New DOS drives handling patchset: testers wanted
by Charles Davis 27 Oct '09

27 Oct '09

Hi, Attached is my latest attempt at moving DOS drive handling completely over to mountmgr. You might remember my last patchset that tried this. That patchset was a real piece of crap. I tested it, and there were compile warnings, crashes, and mysterious "dangling FD object" problems that I'd rather avoid. I fixed all of those, and I must say that this is a vast improvement over that early attempt. But since this is such a major change, I want to make sure I have this absolutely right before I send it in. That's why I need people to test this for me, and report any problems, failed tests, etc. It works on my system, so it just might work on yours. Enjoy. Chip

1 0

Re: RFC: ntdll: Implement CDROM_GetInterfaceInfo() on Mac OS (try 2)
by Charles Davis 27 Oct '09

27 Oct '09

Charles Davis wrote: > Alexandre Julliard wrote: >> Charles Davis <cdavis(a)mymail.mines.edu> writes: >> >>> Here's a new version of my patch that's slightly less complicated. I >>> didn't get a response last time, so I'm sending it again. Please, >>> someone review my patch. I won't send it to wine-patches until I know I >>> have this right (yes, I am a bit of a perfectionist). >>> >>> To reiterate what I said about this patch last time, this patch will >>> implement the CDROM_GetInterfaceInfo() function on Mac OS, which allows >>> clients to, among other things, get a SCSI address to do whatever with. >>> (If this is over your head, you can stop reading now. :) >> That sort of thing should most likely be integrated with the >> diskarbitration stuff in mountmgr. >> > Really? I guess I could do it that way. But then how are > IOCTL_SCSI_GET_ADDRESS clients supposed to get the address? Oops, forgot to reply all again.

2 18

Re: [1/2] extrac32: Add command-line parsing
by Ilya Shpigor 27 Oct '09

27 Oct '09

Hi, What about this group of two patches? Is this correct or there are mistakes? -- Best regards, Ilya Shpigor.

1 0

New valgrind results for Oct 26, 2009
by Dan Kegel 27 Oct '09

27 Oct '09

http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/ has current results. I've tweaked the diff-* files to be brutally minimalist, so if there's a diff- file, it's more likely to be interesting. On the downside, you have to look at the non-diff file to see line numbers. One of these days I've got to make these clickable... Highlights: "New" errors: http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-d3d10_effect.txt has a new warning, see http://www.winehq.org/pipermail/wine-devel/2009-October/079467.html http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-mshtml_htmllocati… shows a bunch of "new" warnings, see http://bugs.winehq.org/show_bug.cgi?id=20485 Fixed: http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-gdiplus_image.txt shows that Kirill's patch did the trick http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-oleaut32_tmarshal… shows that Jeremy's patch helped http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-urlmon_url.txt and http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/diff-wininet_http.txt seem to show benefits from Hans' patch Thanks to everyone who fixed memory problems so far. There's lots more to do, check out your favorite module and see what dirt valgrind has on it!

1 0

Re: [PATCH 1] winmm/tests: Add MCI waveaudio tests.
by Alexandre Julliard 27 Oct '09

27 Oct '09

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > Hi, > > please excuse the cheap way of avoiding dead code, but I was afraid > that git rebase would cause me too many failures with my 30 subsequent > patches. The minor change of turning #if FULL_TEST into /* already cost > me 4 hours with git rebase fixing and assessing make; make mci.ok of every single patch. Code is just as dead within /* */ than within #ifdef, so I'm afraid it's not better. You'd probably have less trouble if you did this in smaller chunks, there's no need to add all the tests in a single patch. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 0/3] Use "__asm__" keyword instead of "asm"
by Yann Droneaud 27 Oct '09

27 Oct '09

Le lundi 26 octobre 2009 à 15:33 +0100, Yann Droneaud a écrit : > When using GCC in ansi/c99 mode, "asm" is not defined, one have > to use "__asm__" instead. > "__asm__" is already used in wine source code except in some > files. > I'm now thinking that configure should search which keyword to use depending on compile/flags used. Then declare a define, for example __ASM__, to be used in source code. For example: #define __ASM__(code) asm(code) else #define __ASM__(code) __asm__(code) Keywords asm/__asm__/__asm could be used as-is in compiler dependent code. Regards. -- Yann Droneaud

1 0

Re: kernel32: add more tests for FormatMessage{A,W}
by Dmitry Timoshkov 27 Oct '09

27 Oct '09

"Louis Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > The attached tests show that this is true for "non-special" language-id's, > but not for the special ones: > (LANG_NEUTRAL, SUBLANG_NEUTRAL), (LANG_NEUTRAL, SUBLANG_DEFAULT),(LANG_NEUTRAL, > SUBLANG_SYS_DEFAULT), and (DWORD)MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US) > > In the latter case the error is set to ERROR_MR_MID_NOT_FOUND A couple of suggestions: 1. There is no point in testing last error if an API didn't fail 2. It would be helpful to simultaneously test return values and last error for FindResource, which should have similar behaviour (and the bug) to FormatMessage, and drop FormatMessageW tests. -- Dmitry.

1 0

DirectX 10 status, do simple programs work yet?
by Warren Dumortier 26 Oct '09

26 Oct '09

I've searched and didn't found any recent topic concerning DirectX 10 in Wine. So i would like to know if there's already something running concerning DirectX 10? Like making very basic applications? The fact i would like to know that is because i'm curious what has alread been done! ;) Thanks, kind regards.

3 2

Re: appwiz: ignore Apps without title in the list(try 2)
by Vitaliy Margolen 26 Oct '09

26 Oct '09

André Hentschel wrote: > Also fixes Bug 20417 > Sorry, little blackout after vacation in try1... > --- > @@ -347,6 +347,12 @@ static void AddApplicationsToList(HWND hWnd, HIMAGELIST hList) > > while (iter) > { > + if(!strlenW(iter->title)) This is the same as "if (!iter->title[0])". Please don't use strlen to check for zero length strings. It's expensive if string isn't empty. Vitaliy.

2 1

Re: programs/extrac32: The debug channel is not used, remove it.
by Andrey Turkin 26 Oct '09

26 Oct '09

Don't do this please, initial part was just submitted, the channel will be used once other parts are in place. Francois Gouget wrote: > --- > programs/extrac32/extrac32.c | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/programs/extrac32/extrac32.c b/programs/extrac32/extrac32.c > index 7e8fbed..4e53af9 100644 > --- a/programs/extrac32/extrac32.c > +++ b/programs/extrac32/extrac32.c > @@ -21,9 +21,7 @@ > #include <windows.h> > > #include "wine/unicode.h" > -#include "wine/debug.h" > > -WINE_DEFAULT_DEBUG_CHANNEL(extrac32); > > int PASCAL wWinMain(HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, int show) > { >

2 2

tmarshal patch for consideration
by Jeremy White 25 Oct '09

25 Oct '09

On route to trying to fix the +heap warning, I actually fixed it first by using the attached patch. I believe this patch is correct; it makes any error in the marshaling process sufficient to prevent an actual invocation. However, it's a fairly fundamental behavior change, and I don't know this code, so I thought I'd see if anyone objected before I submitted it. As far as I can tell, the behavior currently is that if we can't demarshal a particular argument in a typelib, we go ahead and call the function anyway. This could conceivably have 'good' side effects if the arguments we can't demarshall aren't used by the caller. The new behavior would be to fail anytime we don't understand a parameter in the typelib. That seems better to me, but again, I'm really new to this code, so kibitzing appreciated. Cheers, Jeremy

1 0

Re: [oleaut32] StructArg tests cannot rely on an unpacked structure memcmp.
by Austin English 25 Oct '09

25 Oct '09

On Sat, Oct 24, 2009 at 5:13 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > Has the side effect of preventing a test failure which occurs only when running with +heap. Woohoo! Should fix: http://bugs.winehq.org/show_bug.cgi?id=14078 http://bugs.winehq.org/show_bug.cgi?id=17412 -- -Austin

2 1

Parsing output of wine's crash dump
by Dan Kegel 25 Oct '09

25 Oct '09

I've changed how the changes from the previous day's valgrind logs are displayed. The diffs are now named diff-foo rather than foo-diff, e.g. http://kegel.com/wine/valgrind/logs/2009-10-23-14.09/diff-kernel32_virtual.… are the new bits of http://kegel.com/wine/valgrind/logs/2009-10-23-14.09/vg-kernel32_virtual.txt I also filter them more heavily, and don't create a file if there are no differences. This makes it a lot easier to see where the changes are, you only have to scan the first few files in http://kegel.com/wine/valgrind/logs/2009-10-23-14.09 and they're less noisy than they used to be. It'd be easier, and I'd have better filtering, if there were some text marker at the end of the crash dump. Right now I use while (<STDIN>) { if ($skip) { $skip=0 if (/Threads:/); } if (!$skip) { $skip=1 if (/Register dump:/); print; } } to skip backtraces, but that leaves the thread info there, and diffs in that aren't very interesting.cd I see that "Register dump:" is printed in winedbg/be_i386.c; where is "Threads:" printed? (Not mdmp_dump(), that's something else, I think...)

1 0

New valgrind results for Oct 22, 2009
by Dan Kegel 24 Oct '09

24 Oct '09

http://kegel.com/wine/valgrind/logs/ is updated as usual, this time with all of the log files I used to generate. For instance, http://kegel.com/wine/valgrind/logs/2009-10-22-19.57-summary.txt is a diff of just the first line of each error, to give you a quick idea what changed. (The logs are pretty noisy - if there's a crash that happens every other day, you'll see lots of churn from all the warnings that follow, or would follow, the crash.) listview seems genuinely improved: http://kegel.com/wine/valgrind/logs/2009-10-22-19.57/vg-comctl32_listview.t… is a lot shorter than http://kegel.com/wine/valgrind/logs/2009-10-21-19.42/vg-comctl32_listview.t… The script also shows a diff from the previous day for each test's log, e.g. http://kegel.com/wine/valgrind/logs/2009-10-22-19.57/vg-comctl32_listview-d…

3 9

Re: Make RenderTextureEmulation configurable
by James McKenzie 24 Oct '09

24 Oct '09

Ove Kaaven wrote: > This makes it possible to work around bug 10080 without having to patch > the source code. > This is a hack to allow a work around to function. Much better to actually fix the problem permanently. Also, it is preferred to preface your patch with the affected area like this: [winex11.drv] Patch to fix problem in bug #xxxxxx. James McKenzie

4 6

First ever Vista box with no test failures
by Paul Vriens 24 Oct '09

24 Oct '09

Hi, Another milestone. This is a lucky shot though as we have still two intermittent test failures on Vista: kernel32:actctx ole32:clipboard -- Cheers, Paul.

2 1

Re: crypt32: Fix a test failure on systems with no c: drive
by Paul Vriens 23 Oct '09

23 Oct '09

On 10/23/2009 12:03 AM, Juan Lang wrote: > --Juan > > > > Wouldn't it be cleaner to change the use of the hardcoded c:\deadbeef.dbf? And yes, I should have done that when I wrote that piece ;) -- Cheers, Paul.

2 2

Unhandled page fault on read access to 0xffffffff
by Philippe De Muyter 23 Oct '09

23 Oct '09

Hello Alexandre, It's a long time now since my last contrib to the wine project (1997), and I try to run a proprietary W31/W95 program without any success : It fails immediately with : wine: Unhandled page fault on read access to 0xffffffff at address 0x124f:0x000090f7 (thread 001c), starting debugger... At that stage I do not have any window of the windows program, only a window from wine stating : The program winevdm.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience. After I close this window, I get debug output from wine (appended below). I do not remember how I could find where the crash happens, and hence why, in the hope of fixing it. Could give me some hint ? Philippe Unhandled exception: page fault on read access to 0xffffffff in 16-bit code (124f:90f7). fixme:dbghelp:addr_to_linear Failed to linearize address 0112:0000674d (mode 0) fixme:dbghelp:addr_to_linear Failed to linearize address 0111:0000ef00 (mode 0) In 16 bit mode. Register dump: CS:124f SS:13bf DS:13bf ES:0000 FS:0033 GS:003b IP:90f7 SP:962c BP:9634 FLAGS:0202( R- -- I - - - ) AX:0c4e BX:0000 CX:16ff DX:19df SI:0c3b DI:ab5f Stack dump: 0x13bf:0x962c: ab5f 0001 0000 13bf 96e3 b3af 1217 9688 0x13bf:0x963c: 13bf 0000 0000 4eb2 4cf6 b811 0004 0000 0x13bf:0x964c: 036f 1457 0000 0001 aac9 1217 145f 018c 0277: sel=13bf base=0091c738 limit=0000fcdf 16-bit rw- Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000) 0x124f:0x90f7: movb %es:0x0(%bx),%bl Modules: Module Address Debug info Name (101 modules) ELF 7b800000-7b96f000 Deferred kernel32<elf> \-PE 7b820000-7b96f000 \ kernel32 ELF 7bc00000-7bcaf000 Deferred ntdll<elf> \-PE 7bc10000-7bcaf000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7dd50000-7dd82000 Deferred libcrypt.so.1 ELF 7dd82000-7dec7000 Deferred libcrypto.so.0.9.8 ELF 7dec7000-7df0a000 Deferred libssl.so.0.9.8 ELF 7df0a000-7df3c000 Deferred libcups.so.2 ELF 7df44000-7df5a000 Deferred shell.dll16.so PE 7df50000-7df5a000 Deferred shell.dll16 ELF 7df5a000-7df73000 Deferred spoolss<elf> \-PE 7df60000-7df73000 \ spoolss ELF 7df73000-7df92000 Deferred localspl<elf> \-PE 7df80000-7df92000 \ localspl ELF 7dfb6000-7e021000 Deferred rpcrt4<elf> \-PE 7dfc0000-7e021000 \ rpcrt4 ELF 7e021000-7e11a000 Deferred ole32<elf> \-PE 7e040000-7e11a000 \ ole32 ELF 7e144000-7e178000 Deferred uxtheme<elf> \-PE 7e150000-7e178000 \ uxtheme ELF 7e178000-7e1ac000 Deferred winspool<elf> \-PE 7e180000-7e1ac000 \ winspool ELF 7e1ac000-7e273000 Deferred comctl32<elf> \-PE 7e1c0000-7e273000 \ comctl32 ELF 7e273000-7e2cf000 Deferred shlwapi<elf> \-PE 7e280000-7e2cf000 \ shlwapi ELF 7e2cf000-7e45f000 Deferred shell32<elf> \-PE 7e2e0000-7e45f000 \ shell32 ELF 7e45f000-7e511000 Deferred comdlg32<elf> \-PE 7e470000-7e511000 \ comdlg32 ELF 7e511000-7e525000 Deferred win87em.dll16.so PE 7e520000-7e525000 Deferred win87em.dll16 ELF 7e525000-7e550000 Deferred ws2_32<elf> \-PE 7e530000-7e550000 \ ws2_32 ELF 7e550000-7e568000 Deferred winsock.dll16.so PE 7e560000-7e568000 Deferred winsock.dll16 ELF 7e568000-7e57d000 Deferred sound.drv16.so PE 7e570000-7e57d000 Deferred sound.drv16 ELF 7e57d000-7e591000 Deferred mouse.drv16.so PE 7e580000-7e591000 Deferred mouse.drv16 ELF 7e591000-7e5a6000 Deferred keyboard.drv16.so PE 7e5a0000-7e5a6000 Deferred keyboard.drv16 ELF 7e5a6000-7e5bb000 Deferred display.drv16.so PE 7e5b0000-7e5bb000 Deferred display.drv16 ELF 7e5bb000-7e5cf000 Deferred comm.drv16.so PE 7e5c0000-7e5cf000 Deferred comm.drv16 ELF 7e5cf000-7e5f5000 Deferred msacm32<elf> \-PE 7e5e0000-7e5f5000 \ msacm32 ELF 7e5f5000-7e6b1000 Deferred libasound.so.2 ELF 7e6ba000-7e6cf000 Deferred midimap<elf> \-PE 7e6c0000-7e6cf000 \ midimap ELF 7e6cf000-7e706000 Deferred winealsa<elf> \-PE 7e6e0000-7e706000 \ winealsa ELF 7e706000-7e7a1000 Deferred winmm<elf> \-PE 7e710000-7e7a1000 \ winmm ELF 7e7a1000-7e803000 Deferred winedos<elf> \-PE 7e7b0000-7e803000 \ winedos ELF 7e803000-7e809000 Deferred libxfixes.so.3 ELF 7e809000-7e813000 Deferred libxcursor.so.1 ELF 7e813000-7e81a000 Deferred libxrandr.so.2 ELF 7e81a000-7e823000 Deferred libxrender.so.1 ELF 7e823000-7e829000 Deferred libxxf86vm.so.1 ELF 7e829000-7e82d000 Deferred libxinerama.so.1 ELF 7e82d000-7e84e000 Deferred imm32<elf> \-PE 7e830000-7e84e000 \ imm32 ELF 7e84e000-7e867000 Deferred libxcb.so.1 ELF 7e867000-7e982000 Deferred libx11.so.6 ELF 7e982000-7e991000 Deferred libxext.so.6 ELF 7e991000-7e9aa000 Deferred libice.so.6 ELF 7e9aa000-7e9b3000 Deferred libsm.so.6 ELF 7e9b7000-7e9cf000 Deferred msacm32<elf> \-PE 7e9c0000-7e9cf000 \ msacm32 ELF 7e9d1000-7ea6d000 Deferred winex11<elf> \-PE 7e9e0000-7ea6d000 \ winex11 ELF 7eb25000-7eb46000 Deferred libexpat.so.1 ELF 7eb46000-7eb72000 Deferred libfontconfig.so.1 ELF 7eb72000-7eb85000 Deferred libz.so.1 ELF 7eb85000-7ebf4000 Deferred libfreetype.so.6 ELF 7ebf4000-7ebf7000 Deferred libxcb-xlib.so.0 ELF 7ebf7000-7ebfb000 Deferred libxau.so.6 ELF 7ec12000-7ec27000 Deferred system.drv16.so PE 7ec20000-7ec27000 Deferred system.drv16 ELF 7ec27000-7ec7d000 Deferred advapi32<elf> \-PE 7ec30000-7ec7d000 \ advapi32 ELF 7ec7d000-7ed1c000 Deferred gdi32<elf> \-PE 7ec90000-7ed1c000 \ gdi32 ELF 7ed1c000-7ee64000 Deferred user32<elf> \-PE 7ed40000-7ee64000 \ user32 ELF 7ee64000-7ee6e000 Deferred libnss_files.so.2 ELF 7ee6e000-7ee78000 Deferred libnss_nis.so.2 ELF 7ee78000-7ee80000 Deferred libnss_compat.so.2 ELF 7ee88000-7ee9e000 Deferred winevdm<elf> \-PE 7ee90000-7ee9e000 \ winevdm ELF 7efbd000-7efe2000 Deferred libm.so.6 ELF 7efe8000-7efff000 Deferred libnsl.so.1 ELF b7c84000-b7c88000 Deferred libdl.so.2 ELF b7c88000-b7dbb000 Deferred libc.so.6 ELF b7dbb000-b7dd2000 Deferred libpthread.so.0 ELF b7df0000-b7f2b000 Deferred libwine.so.1 ELF b7f2c000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000e 00000014 0 00000010 0 0000000f 0 00000011 00000018 0 00000017 0 00000013 0 00000012 0 00000019 (D) C:\windows\system32\winevdm.exe 0000001c 0 <== 0000001b 0 0000001a 0 0000001d 0000001e 0 Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000)

1 0

Re: [PATCH 5/6] mshtml: Moved HTMLDocumentNode creating to HTMLWindow_Create.
by Andrey Turkin 23 Oct '09

23 Oct '09

This patch makes some tests (like urlmon's url test) to crash if Gecko isn't installed (dereference of NULL window->nswindow in update_window_doc called by HTMLWindow_Create(nswindow==NULL) called by HTMLDocument_Create)

1 0

Re: [PATCH 02/16] [WinMM, MMSystem]: use the new 16=>32 thunks for Aux driver type
by Steven Edwards 23 Oct '09

23 Oct '09

On Thu, Oct 22, 2009 at 4:09 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > 0 files changed, 0 insertions(+), 0 deletions(-) The winmm win16/32 separation has finally collapsed in on itself and this is the resulting Einstein-Rosen bridge. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: ntdll: add stub for RtlGetFunctionTableListHead
by Alexandre Julliard 22 Oct '09

22 Oct '09

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > --- wine-git/dlls/ntdll/ntdll.spec 2009-10-08 19:00:17.000000000 +0200 > +++ wine-build/dlls/ntdll/ntdll.spec 2009-08-27 14:23:39.000000000 +0200 > @@ -623,6 +623,7 @@ > # @ stub RtlGetFirstRange > # @ stub RtlGetFrame > @ stdcall RtlGetFullPathName_U(wstr long ptr ptr) > +@ stdcall RtlGetFunctionTableListHead() This doesn't exist on 32-bit. What do you need it for? -- Alexandre Julliard julliard(a)winehq.org

2 2

New valgrind results for Oct 21, 2009
by Dan Kegel 22 Oct '09

22 Oct '09

I added suppressions for a few frequent spurious warnings and reran, the updated results are in http://kegel.com/wine/valgrind/logs/2009-10-21-19.42.log and broken out by test in http://kegel.com/wine/valgrind/logs/2009-10-21-19.42/ Please send me the suppression record for any warnings that are spurious or benign, and mention the reason for each. There's also an overall diff from the previous run, http://kegel.com/wine/valgrind/logs/2009-10-21-19.42-diff.txt but reading it is kind of a slog. A few suggestions for people who would like to help fix these warnings: 1) Don't fix any error you don't fully understand. Many of these warnings are easy, but some are subtle. When in doubt, move on to an easier one. 2) Fixing leaks in test code is usually pretty safe, and it's easier to get Alexandre to accept simple patches to tests, so start with those if you don't have many patches under your belt. 3) the file http://kegel.com/wine/valgrind/logs/2009-10-21-19.42-count-by-file.txt lists how many warnings are in each test; pick one with just one error, and fix it. Voila, one less failing test! 4) the file http://kegel.com/wine/valgrind/logs/2009-10-21-19.42-count-by-error.txt lists how many of each warning there are. Pick a warning that happens a lot, and fix it. Voila, lots fewer warnings! 5) if you know a warning is spurious, send it to me along with the mangled version below it (that's in suppression format) and why it's spurious or benign or not our fault, and I'll add it to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… Have fun, be careful, and thanks to everyone who's pitching in! - Dan

4 4

Winetricks gdiplus no longer working?
by Scott Ritchie 22 Oct '09

22 Oct '09

Heard a report that the gdiplus verb no longer works because the files to be downloaded have been moved. Thanks, Scott Ritchie

2 1

Re: crypt32(4/5): Add tests for key usage in the base policy
by Paul Vriens 22 Oct '09

22 Oct '09

On 10/21/2009 03:28 AM, Juan Lang wrote: > --Juan > Hi Juan, This one introduces some failures on some boxes. Are they indeed missing the needed Verisign root certificate as stated in the logs? Which certificate is that btw? The tests fail on my NT4 box where I see several Verisign root certificates. -- Cheers, Paul.

2 3

Re: [TRY 2] [2/3] extrac32: Add command-line parsing
by Alexandre Julliard 22 Oct '09

22 Oct '09

Ilya Shpigor <shpigor(a)etersoft.ru> writes: > + /* Parse options */ > + for(i = 0; i < argc; i++) > + { > + if (argv[i][0] == '/') > + { > + for(j = 0; j < sizeof(sFlags) / sizeof(sFlags[0]); j++) > + if (!strcmpiW(argv[i], sFlags[j].wFlag)) > + { > + comp |= sFlags[j].nFlag; > + goto next; > + } > + } > + next: > + continue; > + } > + > + if ((comp & CMD_FLAGS) == EFLAGC) /* copy file */ > + { > + WINE_FIXME("/C not implemented\n"); > + } else if ((comp & CMD_FLAGS) == EFLAGD) /* display CAB archive */ > + { > + WINE_FIXME("/D not implemented\n"); > + } else if ((comp & CMD_FLAGS) == EFLAGE) /* extract CAB archive */ > + { > + WINE_FIXME("/E not implemented\n"); > + } else if ((comp & CMD_FLAGS) == 0) /* expand mode */ > + { > + WINE_FIXME("Expand mode not implemented\n"); > + } That parsing approach is not really appropriate here, the options are not just a bunch of flags, there are options with arguments, mutually exclusive modes, etc. Some sort of switch() statement would be more natural. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: New valgrind results for Oct 21, 2009
by Dan Kegel 22 Oct '09

22 Oct '09

It varies. I got a leakfix in yesterday, for instance. On Oct 22, 2009 5:51 AM, "Ben Klein" <shacklein(a)gmail.com> wrote: 2009/10/22 Dan Kegel <dank(a)kegel.com>: > 2) Fixing leaks in test code is usually pretty safe, and > it's easier to get Alexandre to accept ... I thought AJ didn't like leak fixes in the tests.

1 0

Re: user.exe: Forward WNetGetUser16 to WNetGetUserA of mpr.dll, based on a patch from Andrew Nguyen (2nd resend)
by Alexandre Julliard 22 Oct '09

22 Oct '09

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > --- wine-git/dlls/user32/Makefile.in 2009-07-03 22:00:44.000000000 +0200 > +++ wine-build/dlls/user32/Makefile.in 2009-10-04 10:53:16.000000000 +0200 Don't resend the same patch every day, that will only get you ignored. Anyway this should wait until user is properly separated so that user32 doesn't need to import mpr. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [TRY 2] [1/3] programs: initial add extrac32 utility
by Nikolay Sivov 22 Oct '09

22 Oct '09

Ilya Shpigor wrote: > ------------------------------------------------------------------------ > > Hi, Ilya. You need to include patched configure.ac as well with new WINE_CONFIG_MAKEFILE entry.

3 4

New winetricks 20091022: new verbs glsl-disable, glsl-enable, physx, mingw, mingw-gdb, cmake, dotnet11sdk, dotnet20sdk, vc2003toolkit, vc2005sp1, vc2008sp1
by Dan Kegel 22 Oct '09

22 Oct '09

Another fortnight, another winetricks. Eleven new verbs and spices, and a few bugfixes. Updates since 20091015: * Fix vc2005express verb (interactive mode) to work on windows * Add mingw and mingw-gdb (hey, we support cygwin. Equal time!) * Add cmake. Based on a patch by Mathieu Malaterre * Update gdiplus download link * Added a draft vc2008sp1 verb; works on Windows Vista. * Trim CR from output of cygpath, which screwed up bash strangely on windows. Updates since 20091007: * Added draft vc2008trial verb. Mostly debugged on Windows, not yet tested on Wine. * Add glsl-disable and glsl-enable verbs. Patch by Erik Inge Bolsø. * In dotnet20, be sure to sha1sum l_intl.nls, otherwise it may fail in weird ways * Add Nvidia physx (e.g. for Steam games). Patch by Erik Inge Bolsø. * Added dotnet11sdk, dotnet20sdk, and vc2003toolkit. Based on a change by mathieu.malaterre. * Add vc2005sp1 verb * Cygwin's download server seems to be compress now, so decompress any gzip-compressed .exe's upon download. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Thanks to Austin English, Mathieu Malaterre, and especially Erik Inge Bolsø.

1 0

RFC: ntdll: Implement CDROM_GetInterfaceInfo() on Mac OS (try 2)
by Charles Davis 22 Oct '09

22 Oct '09

Hi, Here's a new version of my patch that's slightly less complicated. I didn't get a response last time, so I'm sending it again. Please, someone review my patch. I won't send it to wine-patches until I know I have this right (yes, I am a bit of a perfectionist). To reiterate what I said about this patch last time, this patch will implement the CDROM_GetInterfaceInfo() function on Mac OS, which allows clients to, among other things, get a SCSI address to do whatever with. (If this is over your head, you can stop reading now. :) I'd like to re-emphasize that if I thought this would get in, I'd send it to wine-patches. But I don't, so I'm asking for your help. I understand if you have better things to do (and, to be honest, I know most of you do), but I'd really appreciate some input here. Please don't disappoint me this time. Thanks. Chip --- dlls/ntdll/cdrom.c | 354 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 353 insertions(+), 1 deletions(-)

2 1

Re: [2/2] mshtml: Add HTMLImageElementFactory::value for constructing IHTMLImgElement objects
by Jacek Caban 21 Oct '09

21 Oct '09

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/htmlimg.c | 46 > +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 45 insertions(+), 1 deletions(-) > > > + if(params->cArgs >= 2) { + width = params->rgvarg; + height = params->rgvarg + 1; + }else if(params->cArgs == 1) { + width = params->rgvarg; + height = ∅ + }else { + width = ∅ + height = ∅ + } Note that DISPPARAMS stores arguments in right to left order so you swap arguments here. Also you have to skip named args that are stored in first cNamedArgs of rgvarg table. How about: argc = params->cArgs - params->cNamedArgs; width = argc >= 2 ? params->rgvarg+argc-1 : ∅ height = argc >= 1 ? params->rgvarg+argc-2 : ∅ Also: + IHTMLImgElement_QueryInterface(img, &IID_IDispatch, (void**)&disp); IHTMLImgElement is a child interface of IDispatch, so you can use C cast here instead of QueryInterface here. Jacek

2 3

uninitialized memory errors in JScriptParse_ParseScriptText ?
by Dan Kegel 21 Oct '09

21 Oct '09

Hi Jacek! Please have a look at http://kegel.com/wine/valgrind/logs/2009-10-20-01.09/vg-jscript_run.txt There are a few interesting errors there. The first one (with a little context from http://kegel.com/wine/valgrind/logs/2009-10-20-01.09.log) is: valgrind ... wine jscript_test.exe.so run.c ... run.c:367: Test failed: lang.js: L"2.5*3.5 !== 8.75" ... Use of uninitialised value of size 4 at get_char_typeW (unicode.h:141) by isdigitW (unicode.h:165) by String_replace (string.c:968) by invoke_prop_func (dispex.c:257) by jsdisp_call (dispex.c:868) by disp_call (dispex.c:897) by call_expression_eval (engine.c:1604) by expr_eval (engine.c:42) by assign_expression_eval (engine.c:3108) by expr_eval (engine.c:42) by expression_statement_eval (engine.c:678) by stat_eval (engine.c:37) by exec_source (engine.c:472) by exec_global_code (jscript.c:106) by JScriptParse_ParseScriptText (jscript.c:715) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:187) by RtlAllocateHeap (heap.c:1429) by SysAllocStringLen (oleaut.c:233) by SysAllocString (oleaut.c:157) by to_string (jsutils.c:558) by String_replace (string.c:882) by invoke_prop_func (dispex.c:257) by jsdisp_call (dispex.c:868) by disp_call (dispex.c:897) by call_expression_eval (engine.c:1604) by expr_eval (engine.c:42) by assign_expression_eval (engine.c:3108) by expr_eval (engine.c:42) by expression_statement_eval (engine.c:678) by stat_eval (engine.c:37) by exec_source (engine.c:472) by exec_global_code (jscript.c:106) by JScriptParse_ParseScriptText (jscript.c:715) Removing the common bits, the core of that warning is Use of uninitialised value of size 4 at get_char_typeW (unicode.h:141) by isdigitW (unicode.h:165) by String_replace (string.c:968) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:187) by RtlAllocateHeap (heap.c:1429) by SysAllocStringLen (oleaut.c:233) by SysAllocString (oleaut.c:157) by to_string (jsutils.c:558) by String_replace (string.c:882) Thanks! - Dan

2 1

Re: rsaenh: Revert part of d3c482250a8232e9657ecefb3e61fff0194e3fbe
by Alexandre Julliard 21 Oct '09

21 Oct '09

Juan Lang <juan.lang(a)gmail.com> writes: > Commit d3c482250a8232e9657ecefb3e61fff0194e3fbe added a test that > showed that the default provider should accept RC2 keys of up to 128 > bits in length. The trouble is the fix was wrong: the default > provider in Wine was the base cryptographic provider, but it has been > the enhanced cryptographic provider for some time in Windows. The > enhanced provider in Wine already supported 128 bit RC2 keys, and the > test also used the default provider. Commit > 7a6381e852a4daf0bbc77ffcb9da3bd85002e1d8 made the enhanced provider > the default, so the test succeeds without this portion of the patch > applied. It fails for me: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so crypt.c && touch crypt.ok crypt.c:972: Test failed: CryptImportKey error 2148073481 make: *** [crypt.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: comctl32: Scroll listview when performing a marquee selection
by Nikolay Sivov 21 Oct '09

21 Oct '09

Owen Rudge wrote: > This patch adds support for scrolling a listview when performing a > marquee selection. In Windows, a listview will scroll around when > dragging and highlighting icons, picking up speed as you move the > mouse further past the window. > Hi, Owen. This patch is rather large, so few comments: > + RECT marqueeRect; /* absolute coordinates of marquee selection */ > + RECT marqueeDrawRect; /* relative coordinates for drawing marquee */ > + POINT marqueeOrigin; /* absolute coordinates of marquee click origin */ I don't think you need such duplication. Why not to use a single rectangle? Looks like you always offset it to listview origin, so these rectangle differ in offset only, that's why you introduced another iterator_* helper. If I'm right about that it's better to add another OffsetRect than consistently maintain two variables with same meaning.

2 3

Re: [PATCH] RESUBMIT: configure: also use LDFLAGS for DLL builds
by Alexandre Julliard 21 Oct '09

21 Oct '09

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > While one usually does not pass in LDFLAGS to dll building, one > probably should be able to. This should be passed from the makefile, not expanded inside LDDLLFLAGS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] programs: initial add extrac32 utility
by Austin English 21 Oct '09

21 Oct '09

2009/10/21 Ilya Shpigor <shpigor(a)etersoft.ru>: You need to add the program to configure.ac, as well as add Makefile.in -- -Austin

2 1

Please test on Windows: waveOutGet/SetVolume
by Ken Thomases 21 Oct '09

21 Oct '09

Hi, Can I ask folks with Windows available to them to run a test for me? I'm attaching a patch for the winmm wave.c test to test the behavior of waveOutSetVolume and waveOutGetVolume, in particular the difference between setting/getting the volume with a device identifier versus a handle to an open instance of the device. The new tests are designed to fail, in order to produce maximal diagnostic output. Thanks, Ken

1 0

Re: [shell32/tests] Fix a test failure on some Vista boxes
by Vincent Povirk 21 Oct '09

21 Oct '09

I actually left the order out of the original test intentionally. The order is completely predictable on Windows and Wine (the window docked first ends up closer to the edge), but X docks work differently. They are controlled by the window manager. If we ever need to create real X docks for appbars (unlikely because of how rarely they're used, but possible), the order will be defined by the window manager, and it won't be possible to reliably pass the test. On Wed, Oct 21, 2009 at 4:43 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > "Fixes" a long standing failure on at least my Vista box. After the removal > of windows[0] there are no ABS_POSCHANGED messages around like on other > boxes. > > Marked as broken() as there seem to be only 2 Vista boxes that have this > issue. I'm running Vista Ultimate maybe that's it? > > This failure has been discussed with Vincent in the past but the thought was > that we were removing the wrong window. The added tests shows however that > the order of the windows is correct when we start. > > Changelog > Fix a test failure on some Vista boxes > > -- > Cheers, > > Paul. > > > > -- Vincent Povirk

2 3

Re: [7/7] msi: Avoid accessing uninitialized memory.
by Juan Lang 21 Oct '09

21 Oct '09

Hi Hans, - size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR); + size += (lstrlenW(value) + 1) * sizeof(WCHAR); I don't see how you're avoiding accessing uninitialize memory here. Could you enlighten me? I think it's complaining about value, by the way, which could be NULL according to line 5034: if (flags & ENV_ACT_REMOVEMATCH && (!value || !lstrcmpW(data, value))) --Juan

2 1

Re: [PATCH 1/2] Patch for bug 20227
by Juan Lang 21 Oct '09

21 Oct '09

Hi Nate, the subject line isn't specific enough. We'd prefer you put a brief description of the change, rather than the bug that motivated it. E.g. your git commit tag for this, "Add tablename tracking to VIEW_find_column.", would be better. For your patch 2/2, you used "Test for bug 20227" as the git commit, which really isn't descriptive enough. Thanks. (Also, nit: > irregardless of any tablename modifier. irregardless is not a word. You probably mean either regardless or irrespective.) --Juan

1 0

Re: [1/2] (resend with array adaptation) user32/tests/class.c: Test extra value of standard dialog and edit classes
by Paul Vriens 21 Oct '09

21 Oct '09

On 10/21/2009 11:46 AM, Julius Schwartzenberg wrote: > This is the test for bug #2181. The patch will follow. Currently the > test checks the value of just two classes, it may be useful to extend > this in the future. The test passes on Windows for Workgroups 3.11, > Windows 98, Windows XP 32-bit and with the broken call on Windows XP > 64-bit. > > > > Hi Julius, Tests that fail on Wine should be marked todo_wine: class.c:866: Test failed: expected 6, got 4 You can remove the todo_wine again in the patch that fixes Wine. Another approach is maybe send the fix as patch1 and the test as patch2? -- Cheers, Paul.

2 2

Re: [1/3] programs: initial add extrac32 utility
by Nikolay Sivov 21 Oct '09

21 Oct '09

Ilya Shpigor wrote: > ------------------------------------------------------------------------ > > This is incomplete. How it's supposed to be built?

1 0

Re: [5/6] mshtml: Handle DISPATCH_CONSTRUCT flag for DispatchEx objects
by Jacek Caban 21 Oct '09

21 Oct '09

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/dispex.c | 16 ++++++++++++++-- > 1 files changed, 14 insertions(+), 2 deletions(-) > + if(This->data->vtbl && This->data->vtbl->value){ + IUnknown *unk; + IDispatchEx_QueryInterface(iface, &IID_IUnknown, (void**)&unk); That's what This->outer is for. Also, because the child object controls it, you don't have to QueryInterface for IHTMLImageElementFactory in the next patch. Jacek

1 0

valgrind results for 20 October 2009
by Dan Kegel 21 Oct '09

21 Oct '09

Fresh Valgrind results for the wine conformance tests are available at http://kegel.com/wine/valgrind/logs/2009-10-20-01.09/ This is from about six hours ago, so it doesn't include Alexandre's coming commits for the day. The code was compiled with -O0 -g to give detailed stacks. The run uses current valgrind from svn with a couple patches, mainly John Reiser's recent patch to make mmap/mprotect behave (needed since the merge of mac support). ole32/marshal.c hung, so I don't have any results from past that. I suppressed some of the benign warnings, but there are surely a bunch left (e.g. kernel32 tests of freeing an invalid pointer still show up), so you have to look at the test source before deciding whether a warning is valid. I suppressed all the "possible" leaks, so any leak that shows up in the log is quite probably a real leak (though possibly a benign one). Please have a look to see if your favorite module has easily-fixable problems.

4 7

Re: [PATCH 2/5] ddraw/tests: Check some more return values (LLVM/Clang).
by Paul Vriens 21 Oct '09

21 Oct '09

On 10/16/2009 10:38 AM, Henri Verbeet wrote: > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index d9b1c72..9104147 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -961,6 +961,7 @@ static BOOL D3D1_createObjects(void) > ddsd.dwWidth = 256; > ddsd.dwHeight = 256; > hr = IDirectDraw_CreateSurface(DirectDraw1,&ddsd,&Surface1, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface returned %#x.\n", hr); > if (!Surface1) { > skip("DDSCAPS_3DDEVICE surface not available\n"); > return FALSE; Hi Henri, This one currently fails on some Win9x/WinMe boxes (VMware only)? As there is a skip() afterwards it seems like the call doesn't always need to be succeeding? Should I just get rid of the ok() message and the assignment to hr? Or move the ok() till after the if()? -- Cheers, Paul.

2 1

NetFwService_create() is unused
by Francois Gouget 21 Oct '09

21 Oct '09

NetFwService_create() is unused in dlls/hnetcfg/service.c. I presume it's meant to be used somehow rather than removed? Maybe a patch is missing? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

1 0

valgrind results for 20 October 2009, take 2
by Dan Kegel 21 Oct '09

21 Oct '09

This time with today's commits, and skipping ole32/marshal, since that hangs. Results at http://kegel.com/wine/valgrind/logs/2009-10-20-09.31/ There are a few very common errors that I need to file bugs for and then suppress... but there are also quite a large number of valid-looking problems. I'll try one more run with -q to get rid of more gunk...

1 0

Re: [6/7] ole32: Don't use IEnumSTATSTGImpl to search in CreateStream.
by Vincent Povirk 20 Oct '09

20 Oct '09

DOH, looks like I mistitled this one. Should be OpenStream. On Tue, Oct 20, 2009 at 2:51 PM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > > > > -- Vincent Povirk

1 0

RFC: Implement CDROM_GetInterfaceInfo() on Mac OS.
by Charles Davis 20 Oct '09

20 Oct '09

Hi, This patch will implement CDROM_GetInterfaceInfo() (and its associated IOCTL) on Mac OS X. The problem is that it's big, it's complicated, and it uses I/O Kit. From what I've seen, Alexandre doesn't exactly like I/O Kit that much. Anyway, I want someone to review the patch. No, I could not find a system ioctl that did what I wanted. Perhaps I should hold off on this until we have that driver I mentioned earlier ready...? In any case, here's my current patch. Chip --- dlls/ntdll/cdrom.c | 428 +++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 411 insertions(+), 17 deletions(-)

1 0

ws2_32: Use the routing table information for gethostbyname('self') if the magic IP would otherwise be returned. [Try 2]
by Erich Hoover 20 Oct '09

20 Oct '09

After looking over my second attempt at this patch I see that I failed to gracefully handle the case when no routes are found. Am I missing anything else here? http://www.winehq.org/pipermail/wine-patches/2009-October/079872.html http://www.winehq.org/pipermail/wine-patches/2009-October/079873.html Erich Hoover ehoover(a)mines.edu

1 0

Re: [PATCH 4/8] msi: Fix merging string type checks.
by Alexandre Julliard 20 Oct '09

20 Oct '09

Hib Eris <hib(a)hiberis.nl> writes: > +static BOOL merge_type_match(LPCWSTR type1, LPCWSTR type2) > +{ > + const WCHAR szl[] = {'l', 0}; > + const WCHAR szs[] = {'s', 0}; > + const WCHAR szL[] = {'L', 0}; > + const WCHAR szS[] = {'S', 0}; > + > + if ((!StrCmpNW(type1, szl, 1) || !StrCmpNW(type1, szs, 1)) && > + (!StrCmpNW(type2, szl, 1) || !StrCmpNW(type2, szs, 1))) > + return TRUE; > + > + if ((!StrCmpNW(type1, szL, 1) || !StrCmpNW(type1, szS, 1)) && > + (!StrCmpNW(type2, szL, 1) || !StrCmpNW(type2, szS, 1))) > + return TRUE; > + > + return !StrCmpNW(type1, type2, 1); > +} Surely you don't need StrCmpNW to compare one character... -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: dlls/winex11.drv/dib.c: initialize two warnings (RESEND)
by Alexandre Julliard 20 Oct '09

20 Oct '09

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > I verified that I still need this patch originally sent on May 31st > to address to compiler warings with current versions of GCC 4.5.0. > > This seems to be the only invocation of DIB_GetBitmapInfo which > requires this kind of extra initialization. I expect you can avoid that by restructuring the code a little. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] Moving wprocs.dll16 out of winedos
by Alexandre Julliard 20 Oct '09

20 Oct '09

Eric Pouech <eric.pouech(a)orange.fr> writes: > .gitignore | 1 > configure | 15 > configure.ac | 1 > dlls/Makefile.in | 6 > dlls/winedos/Makefile.in | 3 > dlls/winedos/vxd.c | 1718 ----------------------------------- > dlls/winedos/wprocs.spec | 19 > dlls/wprocs.dll16/Makefile.in | 15 > dlls/wprocs.dll16/vxd.c | 1718 +++++++++++++++++++++++++++++++++++ > dlls/wprocs.dll16/wprocs.dll16.spec | 19 > 10 files changed, 1766 insertions(+), 1749 deletions(-) > delete mode 100644 dlls/winedos/vxd.c > delete mode 100644 dlls/winedos/wprocs.spec > create mode 100644 dlls/wprocs.dll16/Makefile.in > create mode 100644 dlls/wprocs.dll16/vxd.c > create mode 100644 dlls/wprocs.dll16/wprocs.dll16.spec I don't think we need a separate dll for this one. The plan is to fold it back into krnl386 once it's split off from kernel32. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] hlink: Use HLINKSETF flags in Hlink::fnSetMonikerReference
by Alexandre Julliard 20 Oct '09

20 Oct '09

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/hlink/hlink_main.c | 4 +- > dlls/hlink/link.c | 37 +++++++++++------- > dlls/hlink/tests/hlink.c | 98 > ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 123 insertions(+), 16 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so htmldoc.c && touch htmldoc.ok htmldoc.c:676: Test failed: mon == NULL make: *** [htmldoc.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32/font: Prevent possible buffer overrun
by Dmitry Timoshkov 20 Oct '09

20 Oct '09

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > Reported as http://bugs.winehq.org/show_bug.cgi?id=19819 > > Changelog: > - prevent possible buffer overrun > - while (!(*lpSrc>>index & 0x0001) && index<MAXTCIINDEX) index++; > + while (index < MAXTCIINDEX && !(*lpSrc>>index & 0x0001)) index++; 'index >= MAXTCIINDEX' won't trigger in that case: if (index >= MAXTCIINDEX || FONT_tci[index].ciCharset == DEFAULT_CHARSET) return FALSE; It would be simpler IMO to add one more item to FONT_tci[] instead. -- Dmitry.

2 1

Re: [4/9] WineD3D: Use the shader backend reported constant limit outside the shader backend
by Henri Verbeet 20 Oct '09

20 Oct '09

2009/10/20 Stefan Dösinger <stefan(a)codeweavers.com>: > -static void stateblock_savedstates_set_all(SAVEDSTATES *states, const struct wined3d_gl_info *gl_info) > +static void stateblock_savedstates_set_all(SAVEDSTATES *states, const IWineD3DDeviceImpl *device) Please don't do that.

1 0

Trying to fix some setupapi tests on Win9x/WinMe
by Paul Vriens 20 Oct '09

20 Oct '09

Hi, In an effort to get everything green I'm trying to fix some long standing setupapi test failures. In one of the tests, test_SetupDecompressOrCopyFile() in misc.c, we call SetupDecompressOrCopyFileA a few times. One of them fails as the target file is still open and doesn't allow reading from it (ERROR_SHARING_VIOLATION). This only happens when running winetest and not when running the single tests. Once all tests are finished that previously 'locked' file can be removed. I'm building my own winetest where I selectively removed some of the tests. If I remove for example comctl32/d3d9/fusion/kernel32/riched20 the setupapi tests succeed. Other combinations are however also possible to make the tests pass (for example everything up to d3d8). I do see that on Win98 several processes are started due to some tests needing functionality (like 'rpcss.exe', 'spool32.exe', 'pstores.exe', 'ddhelp.exe'). These processes however have only handles to the winetest results file and not to the mentioned setupapi test file. I'm a bit lost where I should be looking so any ideas, suggestions would be appreciated. I don't know when these tests started failing but I found some failures in test results as far back as May 30th 2008 (WinMe). It's also worth mentioning that not all Win9x/WinMe boxes fail and that the failures happen on both VMware and real boxes. Could it be that we are not cleaning up properly after some tests? Most things should however be cleaned up when we exit a test (like freeing libraries, closing open handles etc...), not? -- Cheers, Paul.

2 2

[PATCH 16/14] winmm: MCI Close all causes one notification per open driver.
by Joerg-Cyril.Hoehle＠t-systems.com 20 Oct '09

20 Oct '09

Paul Vriens asked: >Do all you previous patches still apply after several commits (patches >from Eric)? >I see that for now only "winecoreaudio: Move ERR&WARN out of OSSpinLock >sections" is applied. I don't know. They applied on git as it was over the week end. If there's a problem, I'll not be able to (git fetch &) resolve it until next week. I thought Eric's async patch in bug #20232 would not be submitted as he wrote: >the attached patch is a quick hack for testing purposes I wanted to test it on my side. Ouch. I already made the experience that it's usually better to *not* talk about bugs when I plan to fix them, as Eric's second patch (SYSINFO) which he wrote after I mentioned the bug clearly conflicts with my own. Both were written over the week-end. Sh*t happens. Mine passes the test suite, giving the expected return code :-P Regards, Jörg Höhle.

1 0

Re: winecoreaudio: Move ERR&WARN out of OSSpinLock sections.
by Vitaliy Margolen 20 Oct '09

20 Oct '09

Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Still a few occurances left in wid* functions. > Also, HeapFree occurs in such sections (which may also cause logging). > This is not unsafe as it is no requirement that spinlock sections should be quick. It's just adequate when contention is presumed low. > ------_=_NextPart_001_01CA50B7.60F14FE6 > Content-Type: application/text; > name="0002-mciwave-Pause-resume-is-not-accepted-from-every-sta.patch" > Content-Transfer-Encoding: base64 > Content-Description: 0002-mciwave-Pause-resume-is-not-accepted-from-every-sta.patch > Content-Disposition: attachment; > filename="0002-mciwave-Pause-resume-is-not-accepted-from-every-sta.patch" > > RnJvbSA0N2ZlZGZlMTBmY2Y1MmI2MGEzOTc1ZWY3YTFkMjI4NjJjNGE5MDJlIE1vbiBTZXAgMTcg Could you fix your mailer to report correct mime-types for your attachments. Vitaliy.

1 0

Re: dinput: Fix counting non maped axis as pov [try 2]
by Vitaliy Margolen 20 Oct '09

20 Oct '09

Ričardas Barkauskas wrote: > This time with patch. Sorry. > Fixes crash with dinput joystick test and pcsx2 lilypad plugin on my system.. > > - else if (tokens < 15) > + else if (tokens >=8 && tokens < 15) Nice catch, this is indeed a bug when token == -1. Vitaliy.

1 0

Re: [PATCH 3/5] [WinMM]: allow 32-bit mciLoadCommandResource to load out of 16 bit module
by Alexandre Julliard 19 Oct '09

19 Oct '09

Eric Pouech <eric.pouech(a)orange.fr> writes: > @@ -1566,7 +1554,41 @@ UINT WINAPI mciLoadCommandResource(HINSTANCE hInst, LPCWSTR resNameW, UINT type) > if (!(hRsrc = FindResourceW(hInst, resNameW, (LPWSTR)RT_RCDATA))) { > WARN("No command table found in resource\n"); > } else if ((hMem = LoadResource(hInst, hRsrc))) { > - ret = MCI_SetCommandTable(LockResource(hMem), type); > + if (!HIWORD(hInst)) { /* it's a 16bit resource, convert it */ > + const BYTE* ptr16 = LockResource(hMem); Please don't do that. 16-bit resources should always be loaded with 16-bit functions. Support for casting 16-bit instances to 32-bit is a hack that will have to be removed. -- Alexandre Julliard julliard(a)winehq.org

2 2

CPPCheck for Monday October 19th
by chris ahrendt 19 Oct '09

19 Oct '09

Errors: [/home/cahrendt/wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [/home/cahrendt/wine-git/dlls/ntdll/server.c:882]: (error) Resource leak: fd_cwd [/home/cahrendt/wine-git/dlls/winex11.drv/xfont.c:2963]: (possible error) Resource leak: fd Tools Errors: [/home/cahrendt/wine-git/tools/fnt2bdf.c:779]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/fnt2fon.c:388]: (error) Memory leak: file_lens [/home/cahrendt/wine-git/tools/sfnt2fnt.c:877]: (error) Resource leak: ofp [/home/cahrendt/wine-git/tools/widl/write_msft.c:2536]: (error) Resource leak: fd [/home/cahrendt/wine-git/tools/winedump/pe.c:1547]: (error) Memory leak: map Test Errors To Ignore: [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1117]: (error) Deallocating a deallocated pointer: stream2 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1101]: (possible error) Resource leak: stream3 [/home/cahrendt/wine-git/dlls/msvcrt/tests/file.c:1108]: (possible error) Resource leak: stream4 [/home/cahrendt/wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [/home/cahrendt/wine-git/dlls/rpcrt4/tests/server.c:1189]: (error) Array index out of bounds Chris

1 0

Re: [PATCH 03/14] mciwave: Do not lie about state when winmm fails in Pause or Resume.
by Christian Gmeiner 19 Oct '09

19 Oct '09

Patch is missing -- Christian Gmeiner, MSc

1 0

PATCH 0/14 mciwave aka. waveaudio patches
by Joerg-Cyril.Hoehle＠t-systems.com 19 Oct '09

19 Oct '09

Hi, Here's a series of patches to fix various bugs and increase compatibility. Alas, it is only yesterday night that I discovered that mciwave will only record samples in multiples of 333 milliseconds (from using 3 buffers / second). Thus in my testsuite, the comparisons against 2000ms give flaky results (sometimes 2333ms). However I don't want to delay the inclusion of the large testuite into Wine any further. I prefer 3 flaky test results than almost no test at all. Possibly the change of results between 2000 and 2333 is influenced by using MulDiv in patch 0007. More in the pipe: - notification fixes Yet to investigate: - safe concurrent operation, elimination of hangs etc. See bug 20232 - cause of samples sizes as multiples of 333ms only. Regards, Jörg Höhle

1 0

Re: [PATCH 1/4] comctl32/tooltips: Fix an obviously wrong structure size check (try2)
by Paul Vriens 19 Oct '09

19 Oct '09

On 10/15/2009 12:59 PM, Nikolay Sivov wrote: > Changelog: > - try2: fixed usage of W calls in tests, fixed some typos > - fix an obviously wrong structure size check > Hi Nikolay, I have been checking the failures for these tests. At first I just wanted to add some broken() statements. Looking at test.winehq.org I can see that the test failure output is different sometimes. Changing the following for every call: ti.cbSize = TTTOOLINFO[AW]_V2_SIZE - sizeof(void*); make the output consistent (still different from comctl32 > 5.81). What would be the best way to fix these tests? Add a define for the size of the struct that differs between "_WIN32_WINNT >= 0x0501" and the earlier versions and then have a second possible result (or broken())? Another thing is that this test doesn't have any ok()'s, what was the intention here?: 457 ti.cbSize = TTTOOLINFOA_V2_SIZE; 458 ti.uId = 0x1234ABCD; 459 ti.lParam = 0xaaaaaaaa; 460 r = SendMessageA(hwnd, TTM_SETTOOLINFOA, 0, (LPARAM)&ti); -- Cheers, Paul.

2 1

Re: Patch for bug 20227: msi: Table Join on two tables that have same (non-join) column name...
by Hans Leidekker 19 Oct '09

19 Oct '09

Hi Nate, Your patch applies with offsets, please rebase to current git. And get rid of this warning: db.c: In function ‘test_where_not_in_selected’: db.c:1576: warning: unused variable ‘count’ > + query = /*"Select IESTable.Action, IESTable.Condition from CATable, IESTable where "*/ > + "Select IESTable.Condition from CATable, IESTable where " > + //"CATable.Action = IESTable.Action and (CATable.Type = 51 or CATable.Type = 32) " > + "CATable.Action = IESTable.Action and CATable.Type = 32 " > + /*"order by IESTable.Sequence"*/; Please remove the commented strings. > static UINT ALTER_get_column_info( struct tagMSIVIEW *view, > - UINT n, LPWSTR *name, UINT *type, BOOL *temporary ) > + UINT n, LPWSTR *name, UINT *type, BOOL *temporary, > + LPWSTR *tableName) 'table_name' or just 'table' would be more in keeping with the existing style. > + printf("Returned entry: %s\n", buf); trace() is usually used for debug printing but you might want to turn this into a test instead, or just leave it out. And you should split off the tests to keep the patch size down. -Hans

2 2

acmMetrics(0,ACM_METRIC_MAX_SIZE_FORMAT,&size)
by Markus Stockhausen 19 Oct '09

19 Oct '09

Hi, maybe someone with deeper ACM knowledge can help me out. If I understand the above call correctly it should give the size of the largest WAVEFORMATEX structure of any driver. This should be more or less the maximum number of each second DWORD in the registry in the key Software \Microsoft\AudioCompressionManager\DriverCache\<driver name>\aFormatTagCache. In my Wine environment this gives me 50 because of driver msacm.msadpcm ( ... 0x32 0x00 0x00 0x00 ...). According to the bug I'm currently inspecting I have the feeling that in a Windows installation (even without additional acm drivers) this value could be larger than registry may tell. For that reason I ask if someone could run the attached testcase in an native environment and could tell me if he can see a difference between the result and the registry. Thanks in advance. Markus --- a/dlls/msacm32/tests/msacm.c +++ b/dlls/msacm32/tests/msacm.c @@ -485,6 +485,9 @@ static void msacm_tests(void) if (winetest_interactive) trace("enabled drivers:\n"); + rc = acmMetrics(0, ACM_METRIC_MAX_SIZE_FORMAT, &dwCount); + ok(1==0, "ACM_METRIC_MAX_SIZE_FORMAT=%u\n",dwCount); + rc = acmDriverEnum(DriverEnumProc, 0, 0); ok(rc == MMSYSERR_NOERROR, "acmDriverEnum() failed, rc=%08x, should be 0x%08x\n",

1 0

Have a feeling that the alsa cheese has been moved
by Susan Cragin 18 Oct '09

18 Oct '09

After using alsa very happily for several days or weeks, it no longer works for me. Changes I have noticed between the daily builds of 10/1 and 10/13 indicate that Ubuntu is working on alsa, and making changes. In the past, with my program, here's what happened. When sound didn't work, winecfg usually showed wave-in as "default." When it did, it showed as "dsnoop:0." Well, for a few days daily builds had been hell and sound didn't work at all. Then suddenly with today's daily build sound worked great -- once, with the wave-in showing "default." ??? Then the second time I logged in, it showed dsnoop and the message said the sound system wasn't being recognized.

1 0

Re: [1/1]oleaut32: Fix Testcases on NT4 and lower
by Nikolay Sivov 18 Oct '09

18 Oct '09

Wilfried Pasquazzo wrote: > A fix for my testcases of IPicture_Render method. > > affected files: oleaut32/tests/olepicture.c > > On older OS than Win2000 the testcase produces different results. > The method IPicture_Render isn't officially supported on those old OS, > therefore I just used the broken() statement with the results provided > by wines http://test.winehq.org/data/ to catch all of those errors. > > > Wilfried Pasquazzo > Hi. Maybe it's better to jump over tests basing on ::Render() return value? Or it claims that it succeeded?

2 1

Re: Debugging Xfire: need help
by Stefan Dösinger 18 Oct '09

18 Oct '09

Am 18.10.2009 um 16:24 schrieb Warren Dumortier: > I don't think it's worth to be tested, because if Xfire doesn't > crash (simply by not interacting with it) games are detected. > However i will try it, who knows! ;) An easier way to test is probably to disable Xfire In-Game, if you find out how to do that without using the normal options dialog. Game detection has nothing to do with hooking. Game detection just reads your registry keys, files on disk etc for known games. The hooking comes into action once you start a game. Xfire injects its DLL, hooks some calls, and then displays a message telling that Xfire- In-Game is enabled. That allows you to use Xfire features like the chat, screenshots and movie recording from inside the game, even if the game is running in fullscreen mode, and without tabbing out of the game. The Steam in-game overlay works in the same way. However, Steam only injects its DLL into games started by Steam, while Xfire injects its DLL into every running app, even if it was already running when Xfire was started.

1 0

Debugging Xfire: need help
by Warren Dumortier 18 Oct '09

18 Oct '09

Xfire was working until version 1.104, but since then it crashed on every Wine version, so the Xfire update broke it under Wine. Here's the problem: Xfire crashes every time you interact with it's GUI, well most of the time... When using the keyboard it crashes sometimes, but when using the mouse it crashes every time... I used winedbg to find the possible cause, but i can't figure it out myself, however here is the output: http://pastebin.be/21435 As you can see, it crashes in user32/button.c, because i clicked on a button. However it's the only thing i understand, can anyone help me? I'm really looking forward to get some help as i would really like to get it running. Thanks, kind regards.

2 1

Towards leveraging app build and unit tests as a way to test wine
by Dan Kegel 18 Oct '09

18 Oct '09

Wine is far enough along that it ought to be able to build and run unit test suites from apps like Inkscape, Firefox, and OpenOffice, so I'm trying to write scripts that download and build various apps unattended, and eventually run their own test suites. The scripts are written to run equally well on Windows and Wine. This is hard to do without something like Cygwin or Autohotkey; I'm using Cygwin for my scripts out of personal preference. I already did a build script for Inkscape using mingw; http://kegel.com/wine/inkscape-download-and-build.sh.txt Now I'm tackling Firefox. So far the script installs Visual C++ 2005 Express and the 2003 platform SDK; see http://kegel.com/wine/vc2005x.sh.txt Next step: grabbing firefox source and building. I'm also filing bugs as I go; 19673 Microsoft Platform Installer 2003 fails to install 19668 cmd /c doesn't wait for result before exiting? 19636 Vista SDK installer fails in "Microsoft VC Redist 2008" subinstaller 19615 Can't compile Inkscape with mingw on wine: fd leak? 19581 Visual Studio 2005: "cl : Command line error D8022 : cannot open 'foo.rsp' "; foo.rsp was created with FILE_ATTRIBUTE_TEMPORARY 19502 Visual Studio 2005 SP1 install seems to fail While one doesn't really need to build the apps under Wine to run their test suites, it's a pain to have to compile them on one system and ship them over to another. And supporting building might have a nice benefit: if it's easy to develop for Windows on Wine, more Windows developers might bother to test their apps on Wine. So I think it's worth the extra effort. - Dan

5 16

search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
by Dan Kegel 18 Oct '09

18 Oct '09

See http://bugs.winehq.org/show_bug.cgi?id=14980 Essentially, to run Office 2007, you have to set an override for riched20. Since Office installs a new, spiffier version of riched20 in its own private directory, and expects to find it there, isn't it a bug that we don't let it have it? Sounds like it's time to write a conformance test... sure would be nice if that override wasn't needed.

9 26

SCSITaskDevice vs our own driver
by Charles Davis 18 Oct '09

18 Oct '09

Hi, Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The way I see it, there are two ways to do this: 1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided by the driver (it's like a COM object). We have to get exclusive access (this requires all the handles to all device files to be closed, and the disk unmounted), and then we can send whatever SCSI commands we like. Pros: No kernel code. Somewhat familiar paradigm to Windows programmers. Cons: Complicated usage. Needs every handle to device files closed. 2. Write an I/O Kit driver that exports the functionality we want. This way, we can get whatever we want that isn't exported to userspace by the current drivers. We could add this funcionality as a set of system IOCTLs. Pros: Familiar paradigm to UNIX programmers. Fits in with the current FD-based code. We can implement other stuff, too (like drive locking). Cons: Kernel mode C++. Need I say more? So each method has its pros and cons. I'd like to hear which one you guys prefer. If you don't know, that's OK. I personally don't like either of them, so if you have an alternative, I'll be glad to hear it... unless I have to tear it down as unfeasible. My current patch does it the first way (except for closing the server-side FD, which isn't implemented), but I'd really like some input before I proceed with it. Thanks. Chip

4 6

Re: SCSITaskDevice vs our own driver
by Charles Davis 18 Oct '09

18 Oct '09

James McKenzie wrote: > Charles Davis wrote: >> Alexandre Julliard wrote: >> >>> Charles Davis <cdavis(a)mymail.mines.edu> writes: >>> >>> >>>> Eventually, I want to implement IOCTL_SCSI_PASS_THOROUGH on Mac OS. The >>>> way I see it, there are two ways to do this: >>>> >>>> 1. Use the SCSITaskDevice interface. This is a CFPlugIn object provided >>>> by the driver (it's like a COM object). We have to get exclusive access >>>> (this requires all the handles to all device files to be closed, and the >>>> disk unmounted), and then we can send whatever SCSI commands we like. >>>> >>> I don't think we can realistically require the device to be unmounted. >>> Most apps will want to check for files too. >>> >>> >> Good point. Based on what Ken and you said, I think we'll have to write >> our own driver. But, it's kernel-mode C++. I'm not sure you'd be willing >> to accept that solution, either. >> >> > Can the driver be written in 'c'? Does it absolutely have to be C++? > > James McKenzie > If it's an I/O Kit driver--yes it does have to be written in C++. And it has to be an I/O Kit driver if we want this integrated into the CD-ROM device file. If we don't, then we can write it in C. But then we'll have to figure out a way to get from the CD-ROM FD to an FD to our new device file.

1 0

Question -- Did Friday's git cause anyone sound problems on re-boot?
by Susan Cragin 17 Oct '09

17 Oct '09

I built and installed Friday's git, installed DNS and ran it without a problem, then re-booted and my sound had vanished. It does not appear to be a problem with my sound modules loading, or a conflict with pulseaudio (which I kill anyway). Alsamixer settings have been adjusted to the proper level. If anyone had a similar experience with Friday's git, and it's not just me, I'll investigate further. However, I suspect it's not a wine problem. Susan

1 0

Re: winecoreaudio: Quiet a noisy FIXME.
by Peter Dons Tychsen 17 Oct '09

17 Oct '09

On Thu, 2009-10-15 at 19:19 -0500, Ken Thomases wrote: > + static int once; > + > + if (!once++) FIXME("independent left/right volume not implemented > (%f, %f)\n", left, right); I know it is a detail, but is it not a bit misleading having a variable called "once" when it will trigger the code every 4294967295th time. Its not 100% wrong, but only 0.000000023% wrong :-) More correct would probably be: static int once; if(!once) {bla...bla; once=1}; Thanks, /pedro

2 1

Re: [PATCH 2/2] mshtml: Reimplement HTMLLocation::get_pathname
by Jacek Caban 16 Oct '09

16 Oct '09

Andrew Eikum wrote: > --- > dlls/mshtml/htmllocation.c | 27 ++++++--------------------- > dlls/mshtml/tests/htmllocation.c | 8 ++++---- > 2 files changed, 10 insertions(+), 25 deletions(-) > - hres = CoInternetParseUrl(doc_url, PARSE_PATH_FROM_URL, 0, buf, sizeof(buf), &size, 0); Please don't remove it. Using pluggable protocol has a visible on application and I've tested that it really should be called when I implemented it (altaught there is no test for it in Wine). Jacek

2 2

Re: [PATCH 1/2] mshtml: Reimplement IHTMLLocation::get_href
by Jacek Caban 16 Oct '09

16 Oct '09

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/htmllocation.c | 93 > +++++++++++++++++++++++++++++++++++-- > dlls/mshtml/tests/htmllocation.c | 4 +- > 2 files changed, 90 insertions(+), 7 deletions(-) What's IHTMLDocument2::URL value in these cases? I'd expect it to be the same, which proves that get_hres is not the right place to reformat URL. Also I think that what you can see is a result of using IUri interface for storing URL. Then the right way of fixing it would be to use it in our implementation (it was introduced in IE7 and our loading code is mostly compatible with IE6 ATM). We could add your code as a temporary hack if it would be needed for a real application. Is it a case? Thanks, Jacek

2 2

Re: comctl32: Ensure listview control has focus when marquee dragging
by Nikolay Sivov 16 Oct '09

16 Oct '09

Owen Rudge wrote: > This patch fixes an issue whereby a selection marquee would not > function correctly when the listview hadn't first been clicked on. > > --- > dlls/comctl32/listview.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > @@ -3631,6 +3631,9 @@ static LRESULT LISTVIEW_MouseMove(LISTVIEW_INFO *infoPtr, WORD fwKeys, INT x, IN > LVITEMW item; > ITERATOR i; > > + if (!infoPtr->bFocus) > + SetFocus(infoPtr->hwndSelf); > + Hi, Owen. This doesn't look right. Try with ControlSpy and you'll see WM_SETFOCUS sent just after LButton pressed on client area (not on item, that's important). LButtonUp event used to set focus item was under mouse pointer and it's released without any mouse movements (or maybe drag threshold doesn't count).

2 2

Re: winmm/tests: Don't complain for Wine drivers that allow multiple wave-out opens. (try 2)
by Allan Tong 16 Oct '09

16 Oct '09

> - todo_wine ok(ret == MMSYSERR_NOERROR || broken(ret == MMSYSERR_ALLOCATED), /* winME */ > - "waveOutOpen returns: %x\n", ret); > - if (ret == MMSYSERR_NOERROR) > + if (ret != MMSYSERR_NOERROR) > + { > + todo_wine ok(ret == MMSYSERR_NOERROR || broken(ret == MMSYSERR_ALLOCATED), /* winME */ > + "second waveOutOpen returns: %x\n", ret); > + } > + else > waveOutClose(handle2); Should there be an ok(TRUE) in the else clause to keep track that the test succeeded? - Allan

1 0

Betamax VoIP programs - a new try
by Pavel Troller 16 Oct '09

16 Oct '09

Hi! I'm making a new try to run Betamax group VoIP programs, like FreeCall, Nonoh etc. Nonoh has an outdated entry in AppDB, so I tried to make a new run with current wine (today's git, post-1.1.31). Freecall is not in AppDB at all. I tried both of them, with totally identical behaviour. The installation is smooth. The programs can run, but they can't logon to the provider, thus most of their functionality is unavailable. A further playing with menus etc. obviously makes them crash. The console output shows, that the program periodically tries to log on. The output is as follows: fixme:shdocvw:PersistStreamInit_InitNew (0x1ac700) fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections err:ole:ITypeInfo_fnInvoke did not find member id -514, flags 0x2! err:ole:ITypeInfo_fnInvoke did not find member id -504, flags 0x2! fixme:shdocvw:navigate_url Unsupported args (Flags 0x3382b4:3; TargetFrameName 0x3382a4:8) fixme:urlmon:URLMoniker_BindToObject use running object table fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:gdiplus:GdipCreateBitmapFromHBITMAP can only get image data from DIB sections fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER {25a207b9-ddf3-4660-8ee9-76e58c74063e}: stub fixme:hnetcfg:fw_app_get_Enabled 0x525b690, 0x3387b8 fixme:hnetcfg:fw_apps_Remove 0x525b678, L"C:\\Program Files\\FreeCall.com\\FreeCall\\FreeCall.exe" fixme:hnetcfg:fw_app_put_ProcessImageFileName 0x525b690, L"C:\\Program Files\\FreeCall.com\\FreeCall\\FreeCall.exe" fixme:hnetcfg:fw_app_put_Name 0x525b690, L"FreeCall" fixme:hnetcfg:fw_apps_Add 0x525b678, 0x525b690 fixme:hnetcfg:fw_profile_get_FirewallEnabled 0x529cfe0, 0x3389e4 err:ole:ITypeInfo_fnInvoke did not find member id -518, flags 0x2! err:ole:ITypeInfo_fnInvoke did not find member id -517, flags 0x2! fixme:keyboard:RegisterHotKey (0x1004a,0,0x00000000,123): stub fixme:keyboard:UnregisterHotKey (0x1004a,1): stub fixme:shdocvw:PersistStreamInit_InitNew (0x52ab208) err:ole:ITypeInfo_fnInvoke did not find member id -518, flags 0x2! err:ole:ITypeInfo_fnInvoke did not find member id -517, flags 0x2! fixme:dnsapi:dns_map_options option DNS_QUERY_RETURN_MESSAGE not implemented fixme:shdocvw:navigate_url Unsupported args (Flags 0x3347b0:3; TargetFrameName 0x3347a0:8) fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 fixme:system:SetProcessDPIAware stub! fixme:dwmapi:DwmIsCompositionEnabled 0x33dea8 fixme:iphlpapi:NotifyAddrChange (Handle 0x11d5e918, overlapped 0x11d5e920): stub fixme:iphlpapi:GetAdaptersAddresses no support for IPv6 addresses 0[52ace60]: IMM32: InitKeyboardLayout, aKeyboardLayout=04090409, sCodePage=1252, sIMEProperty=00090000 fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x1ac7a0)->((null) 1 0x33eb60 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 25 2 0x33eb74 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33eb74 (nil)) fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)->(0x33ebb0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 37 0 0x33ec3c (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 84 0 (nil) 0x33ec64) fixme:wininet:InternetLockRequestFile STUB fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:mshtml:HlinkTarget_SetBrowseContext (0x52a3dc0)->((nil)) fixme:urlmon:URLMoniker_BindToObject use running object table fixme:resource:GetGuiResources (0xffffffff,0): stub fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 0[52ace60]: IMM32: InitKeyboardLayout, aKeyboardLayout=04090409, sCodePage=1252, sIMEProperty=00090000 fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x1ac7a0)->((null) 1 0x33eb60 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 25 2 0x33eb74 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33eb74 (nil)) fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)->(0x33ebb0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 37 0 0x33ec3c (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 84 0 (nil) 0x33ec64) fixme:wininet:InternetLockRequestFile STUB fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 29 2 0x33f634 (nil)) fixme:shdocvw:DocHostUIHandler_GetDropTarget (0x1ac7a0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 84 0 (nil) 0x33f554) fixme:mshtml:HttpNegotiate_GetRootSecurityId (0x534e070)->(0x33efd8 0x33f21c 0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d0-0000-0000-c000-000000000046} 69 0 (nil) 0x33f55c) fixme:shdocvw:PropertyNotifySink_OnChanged unimplemented dispid 1005 fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d0-0000-0000-c000-000000000046} 69 0 (nil) 0x33f55c) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33f614 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 29 2 0x33f624 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 103 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({de4ba900-59ca-11cf-9592-444553540000} 2315 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 35 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 28 2 0x33f55c (nil)) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)->(0x33f638) fixme:shdocvw:InPlaceFrame_SetStatusText (0x1ac7a0)->((null)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 25 2 0x33f56c (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33f56c (nil)) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:wininet:InternetLockRequestFile STUB fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:InPlaceActiveObject_TranslateAccelerator (0x1ac700)->(0x15a350) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 21 2 (nil) (nil)) fixme:dnsapi:dns_map_options option DNS_QUERY_RETURN_MESSAGE not implemented fixme:mshtml:hidden_proc (0x502fc 49213 0 0) fixme:shdocvw:navigate_url Unsupported args (Flags 0x33b190:3; TargetFrameName 0x33b180:8) fixme:mshtml:hidden_proc (0x502fc 49213 0 0) fixme:mshtml:HlinkTarget_SetBrowseContext (0x532dd00)->((nil)) fixme:urlmon:URLMoniker_BindToObject use running object table fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 1 fixme:shdocvw:BindStatusCallback_OnProgress status code 2 fixme:shdocvw:BindStatusCallback_OnProgress status code 11 0[52ace60]: IMM32: InitKeyboardLayout, aKeyboardLayout=04090409, sCodePage=1252, sIMEProperty=00090000 fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x1ac7a0)->((null) 1 0x33d0f8 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 25 2 0x33d10c (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33d10c (nil)) fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)->(0x33d148) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 37 0 0x33d1d4 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 84 0 (nil) 0x33d1fc) fixme:wininet:InternetLockRequestFile STUB fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 29 2 0x33dbcc (nil)) fixme:shdocvw:DocHostUIHandler_GetDropTarget (0x1ac7a0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 84 0 (nil) 0x33daec) fixme:mshtml:HttpNegotiate_GetRootSecurityId (0x5356230)->(0x33d570 0x33d7b4 0) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d0-0000-0000-c000-000000000046} 69 0 (nil) 0x33daf4) fixme:shdocvw:PropertyNotifySink_OnChanged unimplemented dispid 1005 fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d0-0000-0000-c000-000000000046} 69 0 (nil) 0x33daf4) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33dbac (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 29 2 0x33dbbc (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({000214d1-0000-0000-c000-000000000046} 103 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->({de4ba900-59ca-11cf-9592-444553540000} 2315 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 35 0 (nil) (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 28 2 0x33daf4 (nil)) fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)->(0x33e720) fixme:shdocvw:InPlaceFrame_SetStatusText (0x1ac7a0)->((null)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 25 2 0x33e654 (nil)) fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 26 2 0x33e654 (nil)) fixme:wininet:InternetLockRequestFile STUB fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)->((null) 21 2 (nil) (nil)) Is there a chance to find, what's fatal for the logon process, eventually to make a quick-and-dirty fix? I actually don't need to call with the programs, I have asterisk for calling, but I need to be able to setup my account, which is possible ONLY from these clients (no chance to do it from their web). Because the AppDB entry for Nonoh is now unmaintained, I'm eventually ready to become a maintainer. Are there any special requirements needed to do such a job ? With regards, Pavel Troller

2 1

DirectX Emulation Question
by Paul Janoski 16 Oct '09

16 Oct '09

Can anybody please tell me how complete the DirectMusic wine emulation is on Linux. Thank You, Paul Janoski

3 2

Re: [1/2] oleaut32/tests: Testcase for IPicture_Render with icons, check for drawing size and position
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/14/2009 07:08 PM, Wilfried Pasquazzo wrote: > Yet another testcase+fix for a regression introduced > by one of my previous patches. > > --- > [1/2] oleaut32/tests: ... > > modified files: oleaut32/tests/olepicture.c > > Draws a icon and checks if it is scaled and positioned correctly. > Windows XP passes all tests. > Wine fails at the scaling test (marked with todo_wine). > --- > [2/2] oleaut32: ... > > modified files: oleaut32/olepicture.c > modified files: oleaut32/tests/olepicture.c > > Fix for Wine scaling of Icons when drawing. > Wine now passes the previously implemented scaling test. > todo_wine of scaling test removed. > > Fixes Bug: http://bugs.winehq.org/show_bug.cgi?id=20365 > > Note: I didn't remove the FIXME-Message, because this > implementation seems still not completely right. It does only allow > to draw the whole icon, because it ignores the src width and height > parameters. However it worked well like this for over 8 years and > it is very unlikely that any real application will want to draw only a > part of an icon. > --- > > > Wilfried Pasquazzo > Hi Wilfried, This patch causes test failures on NT4 and lower: http://test.winehq.org/data/tests/oleaut32:olepicture.html Could you have a look? -- Cheers, Paul.

2 1

Re: winmm/tests: Don't complain for Wine drivers that allow multiple wave-out opens.
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/16/2009 02:19 AM, Ken Thomases wrote: > - todo_wine ok(ret == MMSYSERR_NOERROR || broken(ret == MMSYSERR_ALLOCATED), /* winME */ > - "waveOutOpen returns: %x\n", ret); > - if (ret == MMSYSERR_NOERROR) > + if (ret != MMSYSERR_NOERROR) > + { > + todo_wine ok(ret == MMSYSERR_NOERROR, "second waveOutOpen returns: %x\n", ret); > + } > + else You removed the broken() statement for WinME. -- Cheers, Paul.

3 4

Re: winspool/tests: [Patch 3] Add tests for EnumPrintProcessors
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/14/2009 11:56 PM, Detlef Riekenberg wrote: > > > > Hi Detlef, This one introduces a test failure on NT4 (all?) Could you have a look? -- Cheers, Paul.

1 0

Re: [1/10] Check for ms_hook_prologue attribute support, make a first function hookable
by Stefan Dösinger 15 Oct '09

15 Oct '09

Am 13.10.2009 um 22:50 schrieb Nikolay Sivov: > Stefan Dösinger wrote: >> This makes use of the gcc attribute added to gcc svn yesterday: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00319.html >> ------------------------------------------------------------------------ > Hi, Stefan. Could you explain me briefly if you have time what this > is about? How this hook is about to work? > I guess it's something like hard wrapping for forwarding api calls > to something nondefault, or I'm wrong? CC'ing Wine-devel, since other people will probably have the same question. Steam has a feature which Valve calls "In Game Overlay". You can access certain Steam features, like the chat over voice chat from inside the game. This works without modifying the game. Other apps like Xfire have a similar feature. To make the overlay work, Steam injects a DLL into the game before it starts the game. It creates the process suspended, allocates remote memory, and puts some DLL load code there. Then it changes the entrypoint to that allocated area, which calls LoadLibrary and calls the GameOverlayRenderer.dll DllMain. Then it calls the original game entrypoint. This part works fine already. Now GameOverlayRenderer.dll has to intercept keyboard input, and it has to add its own graphics on top of the game graphics before the final result is sent to D3D. To do this, it tries to intercept calls like opengl32.wglSwapBuffers, IDirect3DSwapChain9::Present. Furthermore it hooks calls like LoadLibrary to find out if the game uses D3D9, and CreateProcess to catch children. Steam's hooker doesn't blindly replace code bytes like other apps do. It disassembles the code, and tries to preserve the instruction. It tries to free the first 5 bytes and places an unconditional immediate jump to its own code there. After this has done its business, it executes the replaced opcodes and jumps to the next instruction. Now Steam doesn't know all possible opcodes. For example, it doesn't know 89 e5 mov %esp, %ebp which is the same as 8b ec mov %esp, %ebp generated by MSVC. Furthermore, it can't deal with the LEA generated on OSX to align the stack, and it doesn't know an xor %eax, %eax used to clear the eax register, etc. Starting with WinXP SP2, microsoft added a 2 byte nop at the start of each function. It also adds 5 nops above the entrypoint. So many Win32 API functions look like this on Windows: 90 nop ; cc int 3 in some functions 90 nop ; cc int 3 90 nop ; cc int 3 90 nop ; cc int 3 90 nop ; cc int 3 func: 8b ff movl.s %edi, %edi. 55 pushl %ebp 8b ec movl.s %esp, %ebp MS' idea is to replace the 8b ff with a -5 byte jump, and replace the 5 nops with a JMP dst. They use this for hotpatching, to apply security fixes to Windows DLLs without restarting the app. They have special compiler and linker switches to create hotpatchable images. Since Steam makes a fairly reasonable assumption when it assumes that a function starts with 8b ff 55 ob ec, Alexandre and I agreed that it makes sense to do this for all Wine functions that Steam and other apps try to hook. However, the MSVC compile switches are pretty obscure. They only add the 8b ff, and they don't work together with / O2 (only /O1), and they break if you use the MSVC equivalent of -fomit- frame-pointer. So we and the gcc maintainer decided that we don't want to clone this feature 1:1 in gcc, instead we added a function attribute. The ms_hook_prologue attrib will make sure the 5 bytes before and after the function entrypoint look as the above code. This happens no matter what other options, attributes etc are used. If e.g. -fomit- frame-pointer is used, it generates this code: 90 90 90 90 90 func: 8b ff movl.s %edi, %edi. 55 pushl %ebp 8b ec movl.s %esp, %ebp ?? popl %ebp < other code > ret The first 5 bytes are marked as unspec volatile, so the optimizer will not try to optimize them away, even at -O6. If %ebp is pushed as part of <other code> the optimizer realizes this though. So gcc first dumps the 8b ff 55 8b ec, and then bothers about reconciling that with what the app actually wants. Currently only the 5 bytes after the function start are generated by gcc, it doesn't yet generate the nops. I am working on this, but it will take a bit longer because it needs some changes in the backend- frontend interaction when generating function alignment. Furthermore there's a bug in binutils that when you explicitly align a function with .align X, 0x90 (ie, you request that 0x90 bytes are used for alignment) it will optimize those nops into a single 3, 4, 5, ... byte nop.

2 1

Re: test {IDirect3DTexture8, IDirect3DSurface8}::UnlockRect for rectangles that are not locked
by Stefan Dösinger 15 Oct '09

15 Oct '09

Do I read this correctly that a double unlockrect call on a surface fails, while a double unlockrect call on a texture succeeds? From the context of the patch its a bit hard to read. Here are some more test suggestions: -> Create a texture, retrieve its surface, and call LockRect/ UnlockRect on the surface. Does this show the surface or texture behavior -> What happens if you have a texture, retrieve a surface and mix locks on the surface and texture? -> What is the d3d9 behavior?

1 0

re: Usual oss choices missing in winecfg, in today's git
by Maarten Lankhorst 15 Oct '09

15 Oct '09

Hi, The explanation is probably much simpler: OSS likely won't show up if the sound device is in use, since it claims total control. If anything in the background is using sound, it is possible to not see OSS at all. lsof /dev/dsp* /dev/snd/* probably tells you if anything uses it. Cheers, Maarten.

1 0

Usual oss choices missing in winecfg, in today's git
by Susan Cragin 15 Oct '09

15 Oct '09

Just built today's git, and am running DNS with alsa. (Thanks, Maarten.) Called up winecfg as usual and found there were no options under OSS Driver. No wave-out, no wave-in, no mixer devices. Nada. Peculiar, never saw this before. So I thought I'd call in.

2 1

Re: [PATCH] Add test case to user32 winetests for edit control context menu. Try 2
by Nikolay Sivov 15 Oct '09

15 Oct '09

Michael Martin wrote: > This patch adds test for edit control clipboard context menu. > The test passes on Windows XP as the WM_COMMAND message is not sent to > the edit control by its context menu. > Fails on wine because wine does incorrectly send that message. > This problem shows up using the edit class context menu on application > created with vb6.0, which leads to application crashing. > The code does not use WINE_TODO() because a simple fix for this will > be sent when > this problem is accepted. It isn't a point, your patch shouldn't break tests, resend with todo_wine please. > Mike > Attach your patch as a diff file, your message client formats it now.

1 0

Re: [PATCH 2/4] comctl32/tooltips: Test the way structure size field is validated (try2)
by Paul Vriens 15 Oct '09

15 Oct '09

On 10/15/2009 12:59 PM, Nikolay Sivov wrote: > Changelog: > - try2: skip for W call failure added > - test the way structure size field is validated > > > > Hi, + + /* 1. test size parameter validation rules (ansi messages) */ + hwnd = CreateWindowExA(0, TOOLTIPS_CLASSA, NULL, 0, + 10, 10, 300, 100, + NULL, NULL, NULL, 0); + + ti.cbSize = TTTOOLINFOA_V1_SIZE - 1; + ti.hwnd = NULL; + ti.hinst = GetModuleHandleA(NULL); + ti.uFlags = 0; + ti.uId = 0x1234ABCD; + ti.lpszText = NULL; + ti.lParam = 0xdeadbeef; + GetClientRect(hwnd, &ti.rect); + r = SendMessageW(hwnd, TTM_ADDTOOLA, 0, (LPARAM)&ti); Still some W-calls left. -- Cheers, Paul.

2 1

Re: [PATCH 1/4] comctl32/tooltips: Fix an obviously wrong structure size check
by Paul Vriens 15 Oct '09

15 Oct '09

On 10/15/2009 01:36 AM, Nikolay Sivov wrote: > Changelog: > - fix an obviously wrong structure size check > > > Hi Nikolay, +static void test_ttm_gettoolinfo(void) +{ + TTTOOLINFOA ti; + TTTOOLINFOW tiW; + HWND hwnd; + DWORD r; + + hwnd = CreateWindowExA(0, TOOLTIPS_CLASSA, NULL, 0, + 10, 10, 300, 100, + NULL, NULL, NULL, 0); + + ti.cbSize = TTTOOLINFOA_V2_SIZE; + ti.hwnd = NULL; + ti.hinst = GetModuleHandleA(NULL); + ti.uFlags = 0; + ti.uId = 0x1234ABCD; + ti.lpszText = NULL; + ti.lParam = 0xdeadbeef; + GetClientRect(hwnd, &ti.rect); + r = SendMessageW(hwnd, TTM_ADDTOOLA, 0, (LPARAM)&ti); The W-call won't work on Win9x/WinMe. diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c index 54600e8..6b483df 100644 --- a/dlls/comctl32/tooltips.c +++ b/dlls/comctl32/tooltips.c @@ -1076,7 +1076,7 @@ TOOLTIPS_AddToolA (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOA *lpToolInfo) } } - if (lpToolInfo->cbSize >= sizeof(TTTOOLINFOA)) + if (lpToolInfo->cbSize >= TTTOOLINFOW_V2_SIZE) Shouldn't that be "TTTOOLINFOA_V2_SIZE" ? @@ -1369,7 +1369,7 @@ TOOLTIPS_EnumToolsW (const TOOLTIPS_INFO *infoPtr, UINT uIndex, LPTTTOOLINFOW lp /* lpToolInfo->lpszText = toolPtr->lpszText; */ lpToolInfo->lpszText = NULL; /* FIXME */ - if (lpToolInfo->cbSize >= sizeof(TTTOOLINFOW)) + if (lpToolInfo->cbSize >= TTTOOLINFOA_V2_SIZE) lpToolInfo->lParam = toolPtr->lParam; And shouldn't this be "TTTOOLINFOW_V2_SIZE" ? -- Cheers, Paul.

2 3

Re: [PATCH 2/4] comctl32/tooltips: Test the way structure size field is validated
by Paul Vriens 15 Oct '09

15 Oct '09

On 10/15/2009 01:36 AM, Nikolay Sivov wrote: > Changelog: > - test the way structure size field is validated > > > > Hi Nikolay, Some more W-calls that won't suceed on Win9x/WinMe in the added tests. -- Cheers, Paul.

1 0

Re: [Fwd: [Bug 20285] cmd.exe does not treat tabs as parameter delimiters]
by Juan Lang 14 Oct '09

14 Oct '09

Hi Colin, > As requested by Austin, I'm forwarding this patch to > wine-patches at winehq.org. Please see the bug report for a test case. You just forwarded the wine-bugs email. This isn't the same as sending the patch. You must include the patch in your email. See http://wiki.winehq.org/SubmittingPatches for help with the process if you need more explicit instructions. Thanks, --Juan

1 0

Help me get a patch into Wine -> Mac cdrom issue
by Joerg-Cyril.Hoehle＠t-systems.com 14 Oct '09

14 Oct '09

Chip, I had hoped that your patch would allow mcicda to work, cf. bug #20323, alas it is not so. Instead I get to see ERR("This version of Mac OS X does not support IOCDAudioControl" on Leopard. I googled slightly and found a message from 2004: http://lists.apple.com/archives/darwin-drivers/2004/Jul/msg00049.html >IOCDAudioControl is deprecated if not obsolete. Therefore I believe the user should not be bothered with a reference to something deprecated half a decade ago and unavailable. A subsequent patch to a simple FIXME("NIY\n") would be enough. Please leave IOCDAudioControl in a comment in the code at most. Reading further, it looks like there's nothing to read audio CDs anymore. Instead, developers are recommended to take advantage of the cddafs, which mounts all audio tracks as "/Volumes/Audio-CD/01 Titel 1.aiff" and to play those files with CoreAudio instead. I've checked that mixed CDs with both data files and audio tracks let 2 CD icons appear on the Finder's desktop, e.g. /Volumes/ABC/ and /Volumes/Audio-CD/ So I wonder whether mcicda on Mac OS should forward calls to waveaudio and play .aiff files instead. I don't know how ntdll and the mountmgr etc. could be changed to accomodate the separation in two volumes, i.e. how to map both /Volumes/ABC and /Volumes/Audio-CD/ to D:\ Regards, Jörg Höhle.

5 6

Re: secur32: check for variable before freeing it
by Henri Verbeet 14 Oct '09

14 Oct '09

2009/10/13 Austin English <austinenglish(a)gmail.com>: > cred = schan_free_handle(i, SCHAN_HANDLE_CRED); > - pgnutls_certificate_free_credentials(cred->credentials); > + if(cred) pgnutls_certificate_free_credentials(cred->credentials); I don't think "cred" is ever supposed to be NULL. Could you add some traces to see where that handle comes from?

4 8

Locale related test request on Win7
by Nikolay Sivov 14 Oct '09

14 Oct '09

Hi. Could anyone with Win7 access run this for me and send a log back? This test requires Russian localization support to be installed. Thanks.

1 0

Re: [1/3] (resend) mshtml: Add test suite for IHTMLLocation
by Alexandre Julliard 14 Oct '09

14 Oct '09

"Andrew Eikum" <aeikum(a)codeweavers.com> writes: > + if(hres == S_OK){ > + if(test->hostname_ok) > + ok(str_eq_wa(str, test->hostname), "%s: expected retrieved hostname to be L\"%s\", was: %s\n", test->name, test->hostname, wine_dbgstr_w(str)); > + else > + todo_wine ok(str_eq_wa(str, test->hostname), "%s: expected retrieved hostname to be L\"%s\", was: %s\n", test->name, test->hostname, wine_dbgstr_w(str)); Please split the long lines like Detlef requested. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/10] Check for ms_hook_prologue attribute support, make a first function hookable
by Dmitry Timoshkov 14 Oct '09

14 Oct '09

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote: > -HRESULT WINAPI DirectInput8Create(HINSTANCE hinst, DWORD dwVersion, REFIID riid, LPVOID *ppDI, LPUNKNOWN punkOuter) { > +HRESULT WINAPI DECLSPEC_HOTPATCH DirectInput8Create(HINSTANCE hinst, DWORD dwVersion, REFIID riid, LPVOID *ppDI, > LPUNKNOWN punkOuter) { Probably DECLSPEC_HOTPATCH just should be a part of WINAPI. -- Dmitry.

2 1

Re: [4/10] OpenGL32: Give wglSwapBuffer a real function, make it hookable
by Roderick Colenbrander 14 Oct '09

14 Oct '09

You should also patch make_opengl because openg32.spec is automatically generated. Roderick On Tue, Oct 13, 2009 at 10:04 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >

2 1

Re: [PATCH 1/2] oleaut32/tests: Test return value of SysReAllocStringLen for the null terminator.
by Nikolay Sivov 13 Oct '09

13 Oct '09

Alexander Kochetkov wrote: > This test works fine under windows 98, XP and under wine. > And allways check for the null terminator. > > see bug 20334. > Hi, Alexander. You patches should not break test in order they are supposed to be applied: your test currently misses todo_wine here: --- + ok (str[STRING_SIZE] == 0, + "Expected null terminator, got 0x%04X\n", str[STRING_SIZE]); --- After that your second patch should remove this todo_wine marker. Without such simple rule last patch (2/2) can't be reverted without breaking tests. Another small issue is a trailing space in the same line --- 'ok (str[STRING_SIZE] == 0, ' --- it's not a big problem cause I believe patches are auto processed for such things before checking to tree, it will lead to a merge conflict in your local repo, that's all.

1 0

Business professors preaching Wine
by Zachary Goldberg 13 Oct '09

13 Oct '09

Thought you guys might enjoy this short story from my day: So I was in a class on product design (at the school of business @ the U of Penn) and my prof is going on about some software we'll need and how to use it. Out of the blue he says "And unfortunately it only works on Windows. But there is this great open source 'stuff' out there called Wine that acts like a middle layer between the now ubiquitous Intel hardware and the windows application to let it run on Linux". He went on like this about Wine, only partially accurate in technical fact, for about 5 minutes. Needless to say the entire classroom (of about ~50) now knows about Wine and that it can run Windows applications on Linux & Mac. I swear, I did not talk to him beforehand and encourage him to do this. Huzzah! -Z

1 0

Re: [1/3] mshtml: Add test suite for IHTMLLocation
by Nikolay Sivov 13 Oct '09

13 Oct '09

aeikum(a)codeweavers.com wrote: > --- > dlls/mshtml/tests/Makefile.in | 1 + > dlls/mshtml/tests/htmllocation.c | 383 > ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 384 insertions(+), 0 deletions(-) > create mode 100644 dlls/mshtml/tests/htmllocation.c > > diff --git a/dlls/mshtml/tests/Makefile.in b/dlls/mshtml/tests/Makefile.in > index 06c6824..dc86c18 100644 > --- a/dlls/mshtml/tests/Makefile.in > +++ b/dlls/mshtml/tests/Makefile.in > @@ -9,6 +9,7 @@ CTESTS = \ > dom.c \ > events.c \ > htmldoc.c \ > + htmllocation.c \ > misc.c \ > protocol.c \ > script.c > diff --git a/dlls/mshtml/tests/htmllocation.c > b/dlls/mshtml/tests/htmllocation.c > new file mode 100644 > index 0000000..c3a5e82 > --- /dev/null > +++ b/dlls/mshtml/tests/htmllocation.c > @@ -0,0 +1,383 @@ > +/* > + * Copyright 2009 Andrew Eikum for CodeWeavers > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. + * > + * This library is distributed in the hope that it will be useful, + * > but WITHOUT ANY WARRANTY; without even the implied warranty of + * > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * > Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public + * > License along with this library; if not, write to the Free Software + * > Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > Hi, Andrew. This series is broken, patch body is formatted.

2 1

Re: Help me get a patch into Wine
by Charles Davis 13 Oct '09

13 Oct '09

Keith Muir wrote: > Charles Davis wrote: >> Damn it, I keep forgetting to reply all. >> >> Charles Davis wrote: >> >>> Vitaliy Margolen wrote: >>> >>>> Charles Davis wrote: >>>> >>>>> Hi, >>>>> >>>>> My name is Charles Davis, but you all can call me "Chip". >>>>> >>>>> I'm new to Wine development, and frankly, I'm kinda scared because I've >>>>> heard and read that getting patches into Wine is very difficult. In >>>>> fact, every time I got ready to send this first patch, I chickened out >>>>> and couldn't do it. So, I want someone to review this patch to see if >>>>> there's anything wrong with it. >>>>> >>>>> >>>> Thanks for writing the patch. >>>> >>>> Few things about your patch: >>>> >>>>> + * Copyright 2008, 2009 Charles Davis >>>>> >>>> You need to add substantial amount of code to or be working for a long time >>>> on this file to add yourself to the copyright note. As for your contribution >>>> to the project, all authors are tracked and AUTHORS file updated automatically. >>>> >>> Oh. I see. But I have many more patches for this file. >>> >>>>> + switch(fmt->Format) >>>>> + { >>>>> + case IOCTL_CDROM_CURRENT_POSITION: >>>>> + memset(&data->CurrentPosition, 0, sizeof(data->CurrentPosition)); >>>>> + break; >>>>> + case IOCTL_CDROM_MEDIA_CATALOG: >>>>> + memset(&data->MediaCatalog, 0, sizeof(data->MediaCatalog)); >>>>> + break; >>>>> + case IOCTL_CDROM_TRACK_ISRC: >>>>> + memset(&data->TrackIsrc, 0, sizeof(data->TrackIsrc)); >>>>> + } >>>>> + /* We need IOCDAudioControl for IOCTL_CDROM_CURRENT_POSITION */ >>>>> + if (fmt->Format == IOCTL_CDROM_CURRENT_POSITION) >>>>> + { >>>>> + ERR("This version of Mac OS X does not support IOCDAudioControl\n"); >>>>> + return STATUS_NOT_SUPPORTED; >>>>> + } >>>>> >>>> This doesn't seems right. If it's not supported (aka error) you shouldn't be >>>> touching returned data. Also why are you zeroing return buffers? I don't see >>>> other implementations do it. >>>> >>> Good catch. I should have done the check first. >>> >>>>> + case IOCTL_CDROM_MEDIA_CATALOG: >>>>> + memset(&ioc, 0, sizeof(ioc)); >>>>> >>>> and >>>> >>>>> + case IOCTL_CDROM_TRACK_ISRC: >>>>> + memset(&ioc, 0, sizeof(ioc)); >>>>> >>>> You shouldn't need to zero buffer you pass to system ioctl. >>>> >>> Good point. >>> >>>>> + if((io = ioctl(fd, DKIOCCDREADMCN, &ioc.mcn)) == -1) break; >>>>> + if((io = ioctl(fd, DKIOCCDREADISRC, &ioc.isrc)) == -1) break; >>>>> >>>> Please keep formatting consistent with the rest of the function/file. Here >>>> you need to add space after "if". >>>> >>> You're right. I read about that, but that must have slipped by me. >>> >>>> Vitaliy. >>>> >>> Thanks for your input. >>> >>> Chip >>> >> >> >> >> >> >> > > The Julliard rank is something worth explaining. Wine developers have > long wondered exactly *HOW* Alexandre determines whether or not a > specific patch gets committed. The process is something as follows: > > * Does the patch use C++ style comments? Yes: REJECT > * Does the patch change coding style from the surrounding code? Yes: > REJECT > * Is the code obviously wrong in any way? Yes: REJECT > * Does it take more than a few seconds to see that the code is > correct? If today is a busy day: IGNORE > * Is the author on the s**t list? Yes: REJECT > * Are the planets aligned in just the right way and none of the > above reject? Yes : ACCEPT > > And of course now we need some sort of measurement for inclusion in the > crap list. For every 'good' patch set an author moves further off the > list, for every bad patch the author's reputation is diminished and put > further onto the list. Most Wine developers have come to realize that > that the Julliard Rank is very similar to Google's PageRank algorithm: > everybody who cares understands how it is 'supposed' to work but could > never replicate it in a million years. > OK, I've sent a better version of my patch to wine-patches. Now we'll see what AJ thinks of it. Again, thanks for your input, guys. And the fact that you said something really helped me. Chip

2 1

Re: rsaenh: Fix the accepted RC2 key length, based on a test case by Dan Kegel.
by Hans Leidekker 13 Oct '09

13 Oct '09

On Tuesday 13 October 2009 08:46:59 am Dmitry Timoshkov wrote: > + ret = pCryptImportKey(provider, (BYTE*)&key_blob, > + sizeof(BLOBHEADER)+sizeof(DWORD)+key_length, > + 0, CRYPT_IPSEC_HMAC_KEY, &hkey); > + ok(ret, "CryptImportKey error %u\n", GetLastError()); > + > + pCryptReleaseContext(provider, 0); You should clean up the key as well. -Hans

1 0

native retest needed: GetDeviceIdentifier()
by Markus Stockhausen 13 Oct '09

13 Oct '09

According to Stefans suggestion I have implemented a test for the string copies into the identifier structure. Test is designed to fail to give me a hint what is going on. Hopefully someone can post the results of a test run in native environment. Thank you

4 3

IsWindowUnicode() is always true after RegisterClassW
by Nikolay Sivov 13 Oct '09

13 Oct '09

Is it ok that IsWindowUnicode() returns 1 for windows created with -A calls? I've just another unrelated issue for Comboex and spotted then I'm apparently using unicode window (as reported by this call). But it was created with --- CreateWindowExA and class WC_COMBOBOXEXA --- Currently comboex code depends on being unicode window or not, so it could cause problems. Looking at user32 code: --- BOOL WINPROC_IsUnicode( WNDPROC proc, BOOL def_val ) { WINDOWPROC *ptr = handle_to_proc( proc ); if (!ptr) return def_val; if (ptr->procA && ptr->procW) return def_val; /* can be both */ return (ptr->procW != NULL); } --- If I'm creating with -A call def_val = = FALSE and the only reason why I got 1 from IsWindowUnicode is that ptr->procA is null. Further WINPROC_AllocProc() with both not null parameters is used for "builtin" user32 classes and default procedure. Since we're registering comctl32 classes as unicode with RegisterClassW, IsWindowUnicode() becomes noop for that, cause it's always unicode. This matches windows behavior actually (at least for ComboEx on XP SP2) and that's how it works. The question is how could I handle CB_GETLBTEXT properly for ComboEx? For Combobox it's obvious cause we know is it unicode or not, for Comboex caller should rely on IsWindowUnicode() for this control for buffer format or what? Any thoughts how to deal with this or am I missing something?

3 4

(no subject)
by KINEPOLIS MYSTERY SHOPPING 13 Oct '09

13 Oct '09

KINEPOLIS MYSTERY SHOPPING. RC: 2004/628/CM. Ref: MYT-200657778 www.kinepolis.com You have been chosen by 0ur HR Manager as one of our possible candidate suitable for employment and being one of our chosen candidates your first assignment as a company representative. Duties:- We want you to run a survey on two prominent companies in your area. 1st: The Money Gram Location: 2nd: The Western union Location *There has been reports about laps in the services of their Management and some of their staffs, *Their complains were based on reports which their customers forwarded anonymously and phone calls which were also made to the head Office. About Us: Kinepolis was founded in 1987 to help leading companies close the gap between the promise of service excellence and its actual delivery. Today, Kinepolis is one of the nation?s largest customer experience measurement and mystery shopping companies, and our Fortune 500 clients represent some of the most innovative and successful customer-focused organizations in the world. Simply put, our approach is designed to isolate the key behaviors that drive customer delight and show our clients how to leverage this information to increase customer loyalty and profitability. Since our inception, we?ve been helping good companies become great companies with our comprehensive arsenal of proven surveying, auditing, and management systems. Our programs allow our clients not only to gather incident-specific information about the moment of truth when a customer comes in contact with an organization, but also to track and trend attributes and behaviors that impact long-term guest value, satisfaction and advocacy. The Money Gram location was reported for evaluation for the following reasons: * Customers have reported their money missing * Slow services * Unbalanced transfer charges Second company was reported to be rendering *Poor services *Rudeness to customers *Excess charges *Late opening time and Closing before time. Your Secret Evaluation would be: * To make a transfer of fund from this Money Gram location or western union location to our Mystery shopper, and the funds would be picked up by another mystery shopper at the exact location Which a customer reported her funds missing. * You would have to record the time at which you go to the location and how many minutes it took you to get service. * The check for the sum of $5000.00 will be send to you, As soon as you receive the check , You will have to deposit the check at your bank and deduct your $500 and use the rest of the money for the services *** First Offer of Mystery Shopper *** Pay-check of $5000 on your name & you will be the one that will be cashing any pay-check issued on your name & you will deduct 10% of the first offer & the rest will be transfer to our Accounting Department by MONEY GRAM OR WESTERN UNION TRANSFER . *Upon receiving the funds, the locations address would be forwarded to you, and also the Name and address of whom the Mystery shoppers transfer would be made to. You would have to keep a comprehensive report on every activity you carry out. * You would also provide me with the name of the cashier that attended to you. Kindly send us your details below to world_service.web(a)w.cn via email in order to have payment issued to you as soon as possible. The payment will be in form of a CERTIFIED CHECK or MONEY ORDER and it will be delivered to you before the week runs out. Thank You. Mr. Frank Anderson. KINEPOLIS MYSTERY SHOPPING /Human resource Manager ================================ Your are expected to send the information below to us. FULL NAME -- FULL RESIDENTIAL ADDRESS -- CITY -- STATE -- ZIP CODE -- COUNTRY -- PHONE NUMBER -- GENDER -- MARITAL STATUS -- AGE -- NATIONALITY -- OCCUPATION -- Kindly send us your details above to world_service.web(a)w.cn Apply Now ...Part-Time Employment Offer...!

1 0

Re: Bug 6971 in RedOrchestra Game.
by James McKenzie 13 Oct '09

13 Oct '09

Loren Kraushar wrote: > Ok Just trying to put it out there I have seen endless sights for this > one problem and still no consistent fix. I was trying to see if you > geniuses could throw it in on the next fixed issues list. > > Thank you for the response master. Please keep the sarcasm to a mimimum. My responses are based upon my own experiences and those of others. First, if you have a patch with testcase, please put it on the wine-patches mailing list. Second, please monitor the wine-devel mailing list for any feedback as well as IRC channel #winehackers on irc.freenode.net. Third, I do not make the final decision as to code acceptance/rejection. This is reserved ENTIRELY to AJ. We have NO say so in this process. This is not liked but is, for the time being, accepted. It is good for one person to be able to make these decisions. He has HIGH standards for acceptance and there are legal and moral reasons for this. The project is always looking for new code and developers. James McKenzie P.S. The mailing lists are bottom post only, and that is for a good reason, it is the way we do things here and is per RFC 1855.

1 0

Ballooning "dlls" folder
by Erich Hoover 12 Oct '09

12 Oct '09

With the separation of the 16-bit APIs recently, the "dlls" folder has ballooned quite a bit. Is there any particular reason that the 16-bit and 32-bit DLLs are not in separate folders? Erich Hoover ehoover(a)mines.edu

2 1

Re: CPP Check 1.1.31
by Nikolay Sivov 12 Oct '09

12 Oct '09

James McKenzie wrote: > Nikolay Sivov wrote: > >> James McKenzie wrote: >> >>> Nikolay Sivov wrote: >>> >>> >>>> chris ahrendt wrote: >>>> >>>> >>>>> [/home/cahrendt/wine-git/dlls/kernel32/resource.c:1279]: (error) >>>>> Division by zero >>>>> >>>>> >>>> False positive I suppose: >>>> >>>> --- >>>> static const BYTE pad[] = { >>>> >>>> 'P','A','D','D','I','N','G','X','X','P','A','D','D','I','N','G' }; >>>> DWORD i; >>>> >>>> -> for ( i = 0; i < size / sizeof pad; i++ ) >>>> --- >>>> >>>> >>> Should pad be enclosed in parenthesis? >>> >>> James McKenzie >>> >>> >> No, why? >> >> >> > I was thinking that c specifies sizeof needs the parameter to be > enclosed in parathesis like this sizeof (pad) but I may be incorrect. > > James McKenzie > This is for type names, variables could be used without enclosing.

3 2

Re: ddraw.c: avoid memory overwrite in GetDeviceIdentifier()
by Stefan Dösinger 12 Oct '09

12 Oct '09

> diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 450d231..645fa8d 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c The visual.c file doesn't seem quite right for this test. There's no really matching file, but I think ddrawmodes.c is better, since that file mainly tests IDirectDraw behavior, while visual.c is mainly about d3d. > memcpy(DDDI->szDriver, deviceidentifier.szDriver, MAX_DDDEVICEID_STRING); > memcpy(DDDI->szDescription, deviceidentifier.szDescription, MAX_DDDEVICEID_STRING); It's probably worth testing what happens when the string is shorter than the max length(as it is most likely the case on all windows boxes). Are the remaining bytes in szDriver unchanged, as if you were using strcpy rather than memcpy. I can imagine that they're left untoched(strcpy), set to garbage(memcpy) or set to zero(memset, then strcpy)

1 0

Re: CPP Check 1.1.31
by Nikolay Sivov 12 Oct '09

12 Oct '09

James McKenzie wrote: > Nikolay Sivov wrote: > >> chris ahrendt wrote: >> >>> [/home/cahrendt/wine-git/dlls/kernel32/resource.c:1279]: (error) >>> Division by zero >>> >>> >> False positive I suppose: >> >> --- >> static const BYTE pad[] = { >> 'P','A','D','D','I','N','G','X','X','P','A','D','D','I','N','G' }; >> DWORD i; >> >> -> for ( i = 0; i < size / sizeof pad; i++ ) >> --- >> > Should pad be enclosed in parenthesis? > > James McKenzie > No, why?

1 0

Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
by Erich Hoover 12 Oct '09

12 Oct '09

I've been a bit busy lately, but I sent in a patchset at the end of September to fix the C&C3 LAN networking bug. If I could get some feedback on these patches then I would greatly appreciate it: http://www.winehq.org/pipermail/wine-patches/2009-September/079193.html[1/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079195.html[2/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079194.html[3/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079198.html[4/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079196.html[5/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079197.html[6/6] Erich Hoover ehoover(a)mines.edu

5 8

Re: comctl32: Remove trailing spaces in propsheet.c
by James McKenzie 12 Oct '09

12 Oct '09

Ričardas Barkauskas wrote: > Remove trailing spaces in comctl32's propsheet.c. > > These types of patches are highly discouraged unless this is causing a breakage with your compiler. If there is a breakage, file a bug with this patch attached for comments. Trailing spaces are not a problem with most forms of GNU c/C++ (gcc/g++) James McKenzie

1 0

Re: Wine MSSQL VB
by Nikolay Sivov 12 Oct '09

12 Oct '09

kumaresan c wrote: > Thanks. > You are right. As per that code there is no need to create DSN. > But I can't access even by creating DSN under wine and modify > the connection code as follows > > Db.open "DSN=ForLinux; User Id=sa; Password=kumaresan" > > > Ok, How to check whether the provider(oledb) works? > > or else What should I do to install oledb provider? > > --Kumaresan I'm not sure it will work through DSNs cause it requires some system support beside providers. You should install mdac as you did, and possibly override all oledb related modules, please use Wine user support forum http://forum.winehq.org/ for such questions, wine-devel isn't used for support.

1 0

Wine MSSQL VB
by kumaresan c 12 Oct '09

12 Oct '09

I have a program that accesses Mssql 2000 database from Windows 2003 server. Now I need to run this program in Linux. I setup wine, mdac28 etc. I can install the program with one error: ODBC's SQLRemoveDriverManager Failed. I can also create a system DSN in Linux using odbcad32.exe under wine. But when I run the program the following error occurs: Specifed SQL Server not found. The code I used is: Db.open "Provider=SQLOLEDB.1;Persist Security Info=True; User ID=sa; Initial Catalog=ForLinuxTest;Data Source=WINSERVER.VISUALWIN.TESTDOMAIN; Password=kumaresan" If I modify this code to use DSN, It looks for a unixODBC DSN instead of wine DSN. What should I do? Help me if you can............... ---Kumaresan.

2 1

Re: ddraw.c: avoid memory overwrite in GetDeviceIdentifier()
by Reece Dunn 12 Oct '09

12 Oct '09

+ * Fill result structure element by element to avoid memory overwrites + * du to size alignment. That should be "*due* to size alignment." - Reece

1 0

Re: [PATCH 07/11] Revert "winmm: Test opening the same device twice."
by Alexandre Julliard 12 Oct '09

12 Oct '09

Ken Thomases <ken(a)codeweavers.com> writes: > This reverts commit 6a7127bfc201ff7a218795c239d5b2571ea413d7 and part of > 9f32c0d9d60662ac8e00ce5cbd4aebd4fdf8dc89. > > It turns out that the issue isn't a limitation of winmm. It's just > individual low-level drivers that may fail to support opening the device > twice. So, there's no way to write the test (is it todo_wine or not? > depends on the driver). That's not a reason to remove it... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ddraw.h: disable DDEVICEIDENTIFIER size alignment
by Stefan Dösinger 12 Oct '09

12 Oct '09

Am 11.10.2009 um 17:44 schrieb Markus Stockhausen: > > <diff.patch> Did you compile this test with MSVC and the Microsoft headers on Windows?

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel