November 2009 - Wine-Devel - list.winehq.org

Infinite loop with translation DLL
by Uwe Bonnes Nov. 10, 2009

Nov. 10, 2009

Hello, around July 2009, I implemented a translation dll, allowing to run Win32 programms using ftd2xx.dll with Wine translating the calls to linux-libftd2xx. It was done while looking at dll/glu32. I was able to run mprog.exe (www.ftdichip.org) some time ago. Reapplying now, I hit an infinite loop with the first translated call. I short, ftd2xx.spec contains: @ stdcall FT_ListDevices(ptr ptr long) FTD2XX_FT_ListDevices and ftd2xx_main.c: extern FT_STATUS FT_ListDevices(PVOID, PVOID, DWORD); FT_STATUS WINAPI FTD2XX_FT_ListDevices( PVOID pArg1, PVOID pArg2, DWORD Flags ) { FT_STATUS res = FT_ListDevices(pArg1, pArg2, Flags); TRACE("res %s\n", res2string(res)); return res; } and dlls/ftd2xx/Makefile.in contains: EXTRALIBS = @FTD2XXLIBS@ with EXTRALIBS detected in configure.ac. MProig.exe calls FT_ListDevices(), which is resolves as FTD2XX_FT_ListDevices(). Then FTD2XX_FT_ListDevices() is entered and FT_ListDevices() resolves again to FTD2XX_FT_ListDevices(), resulting in an infinite loop. Can anybody help with the flaw in my implementation? Or did anything change in wine? The patches still linger on the mailing-list as "Stub implementation for ftd2xx.dll" Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Re: [PATCH] server, ntoskrnl: Implement support for IRP_MJ_CREATE requests.
by Vitaliy Margolen Nov. 10, 2009

Nov. 10, 2009

Charles Davis wrote: > Also, add stub handlers in mountmgr. > > This patch fixes an issue with the previous one where wine would hang if > ntoskrnl got a STATUS_BUFFER_OVERFLOW back from thes server. > --- > +int suspend_thread( struct thread *thread ); > +int resume_thread( struct thread *thread ); > +static void complete_open( struct open_call *open, unsigned int status ) > +{ ... > + resume_thread( open->call.thread ); > This static struct object *device_open_file( struct object *obj, unsigned int access, > unsigned int sharing, unsigned int options ) > { ... > + suspend_thread( current ); Looks like a hack to me. You shouldn't be suspending/resuming threads directly like this. They should block on open operation. Vitaliy.

2 1

Re: mciwave: Rework MCI notification system.
by Paul Vriens Nov. 10, 2009

Nov. 10, 2009

On 11/10/2009 12:56 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > same patch as yesterday, with more spaces and volatile and mciSave fix thrown out. > > I was about to resend > [PATCH 2] winmm: MCI Close all causes one notification per open driver. > which I rebased as well when I realised that it's independent on the code here > (but should logically follow the present patch as #2). So I'm not resending that anew. > Please include it as well. > > Likewise, yesterday's > PATCH mciwave: Stop must not reset current position. > is completely independent on the notification stuff, so I'm not resubmitting it, > even though I sent it in third position. > > Well, I'll wait and see what feedback I get and what appears in git. > > Regards, > Jörg Höhle > Hi Jörg, Please resend all patches you want to have committed in a series with the proper numbering. If they can be applied independently then numbering is (strictly speeking) not needed but it does show where you're going. I'm not sure if it's only me but I have a hard time keeping tracking of all the patches you sent and what (or not) to apply in what order. -- Cheers, Paul.

1 0

Cpp Check Nov. 7th
by chris ahrendt Nov. 10, 2009

Nov. 10, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 9, 2009

Nov. 9, 2009

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 Nov. 8, 2009

Nov. 8, 2009

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 Nov. 8, 2009

Nov. 8, 2009

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 Nov. 8, 2009

Nov. 8, 2009

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 Nov. 8, 2009

Nov. 8, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 7, 2009

Nov. 7, 2009

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 Nov. 6, 2009

Nov. 6, 2009

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 Nov. 6, 2009

Nov. 6, 2009

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 Nov. 6, 2009

Nov. 6, 2009

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