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

Re: msi: Fix use of uninitialized variable (Coverity) (Try 3)
by James Hawkins June 24, 2007

June 24, 2007

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > [Reverting to "Plan A":] > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 22:19:03.000000000 +0100 > @@ -4668,7 +4668,7 @@ > > res = env_set_flags(&name, &deformatted, &flags); > if (res != ERROR_SUCCESS) > - goto done; > + goto done2; > > value = deformatted; > > @@ -4676,8 +4676,14 @@ > root = HKEY_LOCAL_MACHINE; > > res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); > + /* > + * FIXME: RegCloseKey() should not be called with an invalid handle. > + * So should we simply "goto done2" here, if res != EXIT_SUCCESS, > + * or does RegOpenKeyEx() have any failure modes in which "env" does > + * get initialized? > + */ > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVE) > FIXME("Not removing environment variable on uninstall!\n"); > @@ -4686,14 +4692,14 @@ > res = RegQueryValueExW(env, name, NULL, &type, NULL, &size); > if ((res != ERROR_SUCCESS && res != ERROR_FILE_NOT_FOUND) || > (res == ERROR_SUCCESS && type != REG_SZ)) > - goto done; > + goto done1; > > if (res != ERROR_FILE_NOT_FOUND) > { > if (flags & ENV_ACT_SETABSENT) > { > res = ERROR_SUCCESS; > - goto done; > + goto done1; > } > > data = msi_alloc(size); > @@ -4705,12 +4711,12 @@ > > res = RegQueryValueExW(env, name, NULL, &type, (LPVOID)data, &size); > if (res != ERROR_SUCCESS) > - goto done; > + goto done1; > > if (flags & ENV_ACT_REMOVEMATCH && (!value || !lstrcmpW(data, value))) > { > res = RegDeleteKeyW(env, name); > - goto done; > + goto done1; > } > > size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR); > @@ -4719,7 +4725,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > if (!(flags & ENV_MOD_MASK)) > @@ -4749,7 +4755,7 @@ > if (!newval) > { > res = ERROR_OUTOFMEMORY; > - goto done; > + goto done1; > } > > lstrcpyW(newval, value); > @@ -4758,8 +4764,9 @@ > TRACE("setting %s to %s\n", debugstr_w(name), debugstr_w(newval)); > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > -done: > +done1: > RegCloseKey(env); > +done2: > msi_free(deformatted); > msi_free(data); > msi_free(newval); > This is uglier than the other patch. The only change needed in this entire function is to set env to NULL initially. There's nothing wrong with calling RegCloseKey(NULL-var) and it's done everywhere in the code base. -- James Hawkins

1 0

Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
by James Hawkins June 24, 2007

June 24, 2007

On 6/23/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > This patch should fix Coverity bug CID-562. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > > diff -urN a/dlls/msi/action.c b/dlls/msi/action.c > --- a/dlls/msi/action.c 2007-06-18 17:52:27.000000000 +0100 > +++ b/dlls/msi/action.c 2007-06-23 17:08:55.000000000 +0100 > @@ -4648,7 +4648,7 @@ > LPWSTR deformatted, ptr; > DWORD flags, type, size; > LONG res; > - HKEY env, root = HKEY_CURRENT_USER; > + HKEY env = NULL, root = HKEY_CURRENT_USER; > > static const WCHAR environment[] = > {'S','y','s','t','e','m','\\', > @@ -4759,7 +4759,7 @@ > res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size); > > done: > - RegCloseKey(env); > + if (env) RegCloseKey(env); > msi_free(deformatted); > msi_free(data); > msi_free(newval); > Please don't check env for NULL; RegCloseKey will just fail harmlessly if env is NULL. We spent a lot of time removing such checks. -- James Hawkins

4 3

Bugzilla mails and people replying to wine-bugs@winehq.com
by Tom Spear June 23, 2007

June 23, 2007

Just curious how trivial it would be to add a note to the bugzilla mail template saying to post replies to comments in the bug? Something like the following: A bug you are watching, Bug #(bug number), has a new comment. To reply to this comment, click (bug link). Then the rest of the email as it currently appears. I'm asking because I have received several replies to the list recently, and once wine reaches 1.0, I'm sure many more people will join the list and do the same. I don't want comments to be lost due to them not being posted in the proper place, as everyone's input on a bug is important. -- Thanks Tom

3 3

Wine on SkyOS
by Tom Wickline June 23, 2007

June 23, 2007

Hello All, Looks as if SkyOS will soon support Wine! Internals - Many kernel updates like LDT support (required by Wine), updated signal handling, pthread support, and overall additional POSIX compatibility enhancements. http://www.skyos.org/?q=node/605 Tom

3 2

Re: msi: Fix use of uninitialized variable (Coverity)
by Paul Vriens June 23, 2007

June 23, 2007

Andrew Talbot wrote: > This patch should fix Coverity bug CID-562. Additionally, I have pinpointed > another suspected use-before-initialization bug, for future consideration. > > -- Andy. > --- > Changelog: > msi: Fix use of uninitialized variable (Coverity). > Wouldn't it be easier to set env to NULL when declaring it and do a: if (env) RegCloseKey(env); Cheers, Paul.

2 1

RegOpenKeyExW() Question
by Andrew Talbot June 23, 2007

June 23, 2007

Hi, I want to patch msi:action.c:ITERATE_WriteEnvironmentString() so that it only calls RegCloseKey(env), in the cleanup, if "env" has been initialized (to fix Coverity report CID-562). I can bypass the call to RegCloseKey() for any early exit that occurs prior to calling RegOpenKeyExW(), and I can include the call to RegCloseKey() for exits that occur after a successful call to RegOpenKeyExW(). However, the problem, for me, is what to do if the call to RegOpenKeyExW() fails: does the occurrence of this initialization depend on the reason for failure. In other words, do I need something like the following code to cater for the reason failure occurred? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) if (res == ERROR_INVALID_HANDLE || res == RtlNtStatusToDosError(STATUS_BUFFER_OVERFLOW || res == RtlNtStatusToDosError(STATUS_INVALID_PARAMETER)) goto done2; else goto done1; ... done1: RegCloseKey(env); done2: ... Or will the following code suffice? res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, &env); if (res != ERROR_SUCCESS) goto done2; ... done1: RegCloseKey(env); done2: ... Thanks, -- Andy.

2 2

gdiplus: graphics tests [try2]
by Misha Koshelev June 22, 2007

June 22, 2007

> Am Freitag, 15. Juni 2007 22:02 schrieb Jan Zerebecki: > > On Fri, Jun 15, 2007 at 01:36:09PM +0200, Alexandre Julliard wrote: > > > "Evan Stade" <estade at gmail.com> writes: > > > > +static const INT drawline_bmp1[192] = > > > > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xf > > > >fffffff, > > > > > > I don't think we want to do that sort of thing. We can't guarantee > > > that the results will be exact pixel for pixel, and we don't really > > > care. And even if we did, hardcoding the image in the source this way > > > is unmaintainable. > > > > > > If you want to check the results, you should write an app that draws > > > various things and check it visually against Windows, but I don't > > > think that's something that can be part of the regression test suite. > > May I suggest something like enclosing your gdiplus function calls in a regression test in a BeginPath(hdc) and EndPath(hdc) and then using GetPath to check that the paths created by your functions conform to those on native (you can take a look at what I am using right now in dlls/gdi/tests/path.c and some expansions here http://www.winehq.org/pipermail/wine-patches/2007-June/040679.html) I have found that it seems to be a good way to test at least the gdi functions without having to compare the visual result pixel by pixel while still being able to test the basic drawing primitives that are being used (btw you have to give the x&y coords +/- 1 or 2 when checking them b/c of floating point rounding diffs). The only downside for using this kind of framework would be that if anything changes in gdi32's path implementation it would affect your tests, but I think no matter what you do for a graphics regression tests for gdiplus changes in gdi32 would affect it. Just wanted to throw the idea out as I think a good conformance test is worth its weight in gold. Misha

2 2

Re: winealsa.drv: Fix missing unlock on the error path. Found by Smatch.
by Maarten Lankhorst June 22, 2007

June 22, 2007

That fix is correct, This->pcm is only ever changed inside the critical section Thanks, Maarten 2007/6/22, Michael Stefaniuc <mstefani(a)redhat.de>: > Maarten, > > is this the right fix or can the lock be moved below the > if (!This->pcm) > check? > > bye > michael > --- > dlls/winealsa.drv/dsoutput.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/winealsa.drv/dsoutput.c b/dlls/winealsa.drv/dsoutput.c > index 57b8968..9fc5020 100644 > --- a/dlls/winealsa.drv/dsoutput.c > +++ b/dlls/winealsa.drv/dsoutput.c > @@ -459,6 +459,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_GetPosition(PIDSDRIVERBUFFER iface, > if (!This->pcm) > { > FIXME("Bad pointer for pcm: %p\n", This->pcm); > + LeaveCriticalSection(&This->pcm_crst); > return DSERR_GENERIC; > } > > -- > 1.5.0.6 >

1 0

Failing assertion in dsound test, please confirm
by Alex Villacís Lasso June 22, 2007

June 22, 2007

I am experiencing a failing assertion in a dsound test. Could you please confirm if it is just me (and then it would be a configuration issue), or if anybody else is experiencing failing assertions: [alex(a)srv64 tests]$ WINETEST_INTERACTIVE=1 wine dsound_test.exe.so dsound ALSA lib conf.c:3939:(snd_config_expand) Unknown parameters 0 ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL default:0 fixme:wave:ALSA_AddCaptureDevice Add support for DSCapture dsound.c:973:DLL Version: 5.3.1.904 dsound.c:180:Testing IDirectSound fixme:dsalsa:SetFormat Your alsa dmix period size is excessively high, unfortunately this is alsa default, try decreasing it to 512 or 256 (but double the amount of periods) if possible fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {47d4d946-62e8-11cf-93bc-444553540000}, hres is 0x80004002 err:ole:CoGetClassObject class {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} not registered err:ole:CoGetClassObject no class object {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} could be created for context 0x1 dsound.c:938:*** Testing Primary Sound Driver - winealsa.drv *** dsound.c:475:Playing a 5 seconds reference tone at the current volume. dsound.c:478:(the current volume is -4651 according to DirectSound) dsound.c:480:All subsequent tones should be identical to this one. dsound.c:481:Listen for stutter, changes in pitch, volume, etc. ds3d.c:400:Requested format tag=0x0001 11025x16x2 avg.B/s=44100 align=4 ds3d.c:403:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 ds3d.c:453: Playing 5 second 440Hz tone at 48000x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x1 avg.B/s=8000 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x8x2 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x8x2 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x8x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x1 avg.B/s=16000 align=2 dsound.c:586:Got tag=0x0001 48000x16x1 avg.B/s=96000 align=2 dsound.c:607: Testing a primary buffer at 48000x16x1 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 dsound.c:582:Requested primary format tag=0x0001 8000x16x2 avg.B/s=32000 align=4 dsound.c:586:Got tag=0x0001 48000x16x2 avg.B/s=192000 align=4 dsound.c:607: Testing a primary buffer at 48000x16x2 with a secondary buffer at 11025x16x2 ds3d.c:453: Playing 1 second 440Hz tone at 11025x16x2 mixer.c:823: DSOUND_PerformMix: La declaración `device->playpos < device->buflen' no se cumple. wine: Assertion failed at address 0x600007f2 (thread 000f), starting debugger... dsound.c:582:Requested primary format tag=0x0001 11025x8x1 avg.B/s=11025 align=1 dsound.c:586:Got tag=0x0001 48000x8x1 avg.B/s=48000 align=1 dsound.c:607: Testing a primary buffer at 48000x8x1 with a secondary buffer at 11025x16x2 Unhandled exception: assertion failed in 32-bit code (0x600007f2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:600007f2 ESP:7ed516cc EBP:7ed516d8 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00002cd3 ECX:00002cd5 EDX:00000006 ESI:7ed51778 EDI:60298ff4 Stack dump: 0x7ed516cc: 60171fa0 60298ff4 7ed52b90 7ed51804 0x7ed516dc: 601738b1 00000006 7ed51778 00000000 0x7ed516ec: 00000068 7cae1278 00000000 00000000 0x7ed516fc: 601ae37d 7ed5173c 7cae1278 7cae12dc 0x7ed5170c: 7ed51814 60298ff4 00000062 7cae1278 0x7ed5171c: 7ed517e8 601a7d3b 7cae1278 00000062 Backtrace: =>1 0x600007f2 (0x7ed516d8) 2 0x601738b1 (0x7ed51804) 3 0x6016b3ce (0x7ed51848) 4 0x608bdfe8 DSOUND_timer+0x2108(timerID=0x1, msg=0x0, dwUser=0x167688, dw1=0x0, dw2=0x0) [/home/alex/install/wine-0.9.39-build/dlls/dsound/mixer.c:554] in dsound (0x7ed519b8) 5 0x60910b96 TIME_MMSysTimeThread+0x2e6(arg=0x0) [/home/alex/install/wine-0.9.39-build/dlls/winmm/time.c:181] in winmm (0x7ed51a18) 6 0x7bc5d19e call_thread_entry_point+0xe() in ntdll (0x7ed51a28) 7 0x7bc5de72 call_thread_func+0x42(rtl_func=<register EDI not in topmost frame>, arg=<register ESI not in topmost frame>) [/home/alex/install/wine-0.9.39-build/dlls/ntdll/thread.c:404] in ntdll (0x7ed51ac8) 8 0x7bc5e10f in ntdll (+0x4e10f) (0x7ed523c8) 9 0x601362fb (0x7ed524b8) 10 0x6021993e (0x00000000) 0x600007f2: ret Modules: Module Address Debug info Name (66 modules) ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 24d000- 2bd000 Deferred libgl.so.1 ELF 43e000- 45b000 Deferred ld-linux.so.2 ELF 45d000- 5b1000 Deferred libc.so.6 ELF 5b3000- 5dc000 Deferred libm.so.6 ELF 5de000- 5e3000 Deferred libdl.so.2 ELF 5fa000- 612000 Deferred libpthread.so.0 ELF 614000- 619000 Deferred libxxf86vm.so.1 ELF 640000- 645000 Deferred libxfixes.so.3 ELF 6b5000- 6bb000 Deferred libxdmcp.so.6 ELF 6bd000- 7bf000 Deferred libx11.so.6 ELF 802000- 805000 Deferred libxau.so.6 ELF 80c000- 81c000 Deferred libxext.so.6 ELF 8aa000- 8cb000 Deferred libexpat.so.0 ELF 926000- 92f000 Deferred libxrender.so.1 ELF a84000- a8e000 Deferred libxcursor.so.1 ELF a98000- b22000 Deferred libfreetype.so.6 ELF b24000- b53000 Deferred libfontconfig.so.1 ELF bbb000- bc6000 Deferred libdrm.so.2 ELF cef000- cf6000 Deferred libxrandr.so.2 ELF dfa000- dfd000 Deferred libxinerama.so.1 ELF 5cf0000- 5dce000 Deferred libasound.so.2 ELF 65f6000- 65ff000 Deferred libsm.so.6 ELF 6601000- 661b000 Deferred libice.so.6 ELF 6001d000-60131000 Deferred libwine.so.1 ELF 602cb000-6032b000 Deferred dsound_test<elf> \-PE 602e0000-6032b000 \ dsound_test ELF 6032b000-60371000 Deferred advapi32<elf> \-PE 60340000-60371000 \ advapi32 ELF 60371000-604ab000 Deferred user32<elf> \-PE 60390000-604ab000 \ user32 ELF 604ab000-60541000 Deferred gdi32<elf> \-PE 604c0000-60541000 \ gdi32 ELF 60541000-60597000 Deferred rpcrt4<elf> \-PE 60550000-60597000 \ rpcrt4 ELF 60597000-605b5000 Deferred iphlpapi<elf> \-PE 605a0000-605b5000 \ iphlpapi ELF 605c9000-605e2000 Deferred version<elf> \-PE 605d0000-605e2000 \ version ELF 60892000-608db000 Dwarf dsound<elf> \-PE 608a0000-608db000 \ dsound ELF 608db000-60968000 Dwarf winmm<elf> \-PE 608f0000-60968000 \ winmm ELF 60a46000-60a5e000 Deferred msacm32<elf> \-PE 60a50000-60a5e000 \ msacm32 ELF 60a5e000-60a84000 Deferred msacm32<elf> \-PE 60a70000-60a84000 \ msacm32 ELF 61d5f000-61d74000 Deferred midimap<elf> \-PE 61d70000-61d74000 \ midimap ELF 6a741000-6a74d000 Deferred libnss_files.so.2 ELF 6d8a4000-6d8d6000 Deferred winealsa<elf> \-PE 6d8b0000-6d8d6000 \ winealsa ELF 7525e000-752ec000 Deferred winex11<elf> \-PE 75270000-752ec000 \ winex11 ELF 757d6000-757ea000 Deferred lz32<elf> \-PE 757e0000-757ea000 \ lz32 ELF 77861000-7787e000 Deferred imm32<elf> \-PE 77870000-7787e000 \ imm32 ELF 79cd4000-79cd7000 Deferred iso8859-1.so ELF 79d6e000-79e0b000 Deferred ole32<elf> \-PE 79d80000-79e0b000 \ ole32 ELF 7b800000-7b924000 Deferred kernel32<elf> \-PE 7b820000-7b924000 \ kernel32 ELF 7bc00000-7bc96000 Dwarf ntdll<elf> \-PE 7bc10000-7bc96000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000010 00000012 0 00000011 0 0000000d (D) Z:\home\alex\install\wine-0.9.39-build\dlls\dsound\tests\dsound_test.exe 0000000f 15 <== 0000000e 0 -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1

Re: How to make your machine crash when running Wine
by gslink June 22, 2007

June 22, 2007

Most of the people here are probably smarter than to fall into this trap but I recently had several customers who did. Most of the time openGL just refuses to run but a couple of months ago RH did put out an update to some of the X code that did cause the machine to crash with Wine if you didn't replace the Nvidia driver. The customers were running some things under Wine that used hardware acceleration. If they had used hardware acceleration outside of Wine the machine would have crashed too. This is not a Wine problem but it is likely to be a source of regular complaints.

1 0

Re: dpnhpast: Add stub for DirectPlayNATHelpCreate
by Detlef Riekenberg June 22, 2007

June 22, 2007

On Fr, 2007-06-22 at 04:39 +0200, Alexander Nicolaysen Sørnes wrote: > +HRESULT WINAPI DirectPlayNATHelpCreate(const LPGUID pIId, void ** > ppvInterface) > { > - /* @stub in .spec */ > + FIXME("stub"); > + return E_FAIL; > } > -#endif The FIXME is missing the newline and it would be useful to dump the Parameters in the FIXME. -- By by ... Detlef

1 0

Re: [3/7] gdiplus: GdipReAlloc
by Alexandre Julliard June 22, 2007

June 22, 2007

"Evan Stade" <estade(a)gmail.com> writes: > This is only declared privately because it is not a function provided > by the dll. It follows the exported-function naming scheme however, > because it's a counterpart to GdipFree and GdipAlloc. Please don't do that, it's confusing. If there's no GdipReAlloc just use HeapReAlloc directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: [1/2] oleaut32: add PNG loading [try2]
by Dan Kegel June 22, 2007

June 22, 2007

Alexandre wrote: >> How can I improve this patch such that it will be accepted? > >The biggest problem is that the libpng versioning scheme is broken, so >we can't find the proper soname. This will need some more configure >magic. Looking at http://www.libpng.org/pub/png/libpng.html and http://www.linux-foundation.org/en/LibPng and /usr/include/png.h I get the impression that the libpng versioning scheme was cleaned up for the 1.2 series over four years ago. So perhaps we could just change configure.ac to check PNG_LIBPNG_VER_MAJOR and make sure it's exactly 1, and check PNG_LIBPNG_VER_MINOR and make sure it's 2 or greater. That would let us avoid the old broken libpng's, wouldn't it? - Dan

2 1

Re: [PATCH try2 4/4] gdi32: Call pMoveTo if available when emulating ArcTo/PolylineTo/PolyBezierTo.
by Alexandre Julliard June 22, 2007

June 22, 2007

Misha Koshelev <mk144210(a)bcm.edu> writes: > This sends proper position information to the GDI driver when we are emulating these functions. I don't think I agree with this one. If the driver needs to update the position then it should implement ArcTo etc. since it may need to distinguish that from an explicit MoveTo. Or if the generic implementation is really good enough in all cases then we shouldn't export a driver entry point at all. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: PATCH - implement LockWorkStation using xdg-screensaver on Linux
by Hans Leidekker June 21, 2007

June 21, 2007

On Tuesday 19 June 2007 20:08:50 Steven Edwards wrote: > Patch by Hans Leidekker It's your idea so you should get the credit. I was just helping out with the implementation. > This could be expanded for other platforms that use xdg stuff by > changing the #ifdef. I added the #ifdef to also deal with the MacOS > case. There will allways be Linux distributions that don't install the xdg tools by default, and it's not inconceivable that they will be supported on MacOS one day. So I think it's better to just try to run xdg-screensaver, warn when it fails, but ignore the error. From reading MSDN this is consistent with the semantics of LockWorkStation. I also think it's better to not lock the entire desktop when Wine runs in a virtual desktop. I remember looking for a way to know whether we are running in desktop mode and found this snippet from PaintDesktop(): HWND hwnd = GetDesktopWindow(); /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */ if (GetWindowThreadProcessId( hwnd, NULL )) ... I copied it but somehow it didn't work for me. -Hans

5 5

re: NULL ptr dereferences found with Calysto static checker
by Dan Kegel June 21, 2007

June 21, 2007

Domagoj wrote: > I've ran my static checker Calysto on Wine v0.9.35 and got > 78 bug reports:... > If you are interested in the reports, please: > 1) read > http://www.cs.ubc.ca/~babic/index_calysto_community.htm > 2) if the conditions are acceptable, let me know where to > send the reports. The conditions look very minimal, we should be fine with them. A check once a month should be fine. Just send the results to wine-devel(a)winehq.org. (There's some chance we'll ask you to switch to sending them somewhere else, but that will do initially.) For the moment just put the calysto.org link in the mail. Once it's clear the results are useful, somebody will link to calysto at least from our wiki. Say, whatever happened to Coverity's scans of Wine? I just logged in to the Wine results at http://scan.coverity.com, and the last scan seems to have been last July. Did they set up a new, private site for us? Paul V., do you know? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

9 11

Coverity status
by Paul Vriens June 21, 2007

June 21, 2007

Hi, I've been in contact with Coverity. People currently listed as Wine contacts are: - Jan Zerebecki - Paul Vriens The main page is changed so it reflects the new scan site http://scan2.coverity.com:7479 and there has just been a new run! Coverity is very busy setting up some proper communication channels and some means for the contacts to do some kind of user administration (limited of course). Apart from that a lot of the current manual tasks will be automated (like the counters on the page where Wine is listed http://scan.coverity.com/rung1.html) Cheers, Paul.

1 0

Re: winmm: Specify the arguments of the function in the function pointer
by Alexandre Julliard June 21, 2007

June 21, 2007

Michael Stefaniuc <mstefani(a)redhat.de> writes: > @@ -114,10 +114,10 @@ static BOOL MMDRV_GetDescription32(const char* fname, char* buf, int buflen) > DWORD dw; > BOOL ret = FALSE; > UINT u; > - FARPROC pGetFileVersionInfoSizeA; > - FARPROC pGetFileVersionInfoA; > - FARPROC pVerQueryValueA; > - HMODULE hmodule = 0; > + DWORD (WINAPI *pGetFileVersionInfoSizeA)(LPCSTR,LPDWORD); > + BOOL (WINAPI *pGetFileVersionInfoA)(LPCSTR,DWORD,DWORD,LPVOID); > + BOOL (WINAPI *pVerQueryValueA)(LPCVOID,LPCSTR,LPVOID*,UINT*); > + HMODULE hmodule = 0; It may have been done that way because local WINAPI pointers crash on old versions of gcc. But that whole function should probably be removed, dumping version info doesn't belong in winmm. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] oleaut32: add PNG loading [try2]
by Evan Stade June 21, 2007

June 21, 2007

On 6/19/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > Try2: This time the rowsize is correctly aligned (on 4-byte > boundaries) and palette-mode PNGs are allowed as well as RGB-mode > PNGs. > > Changelog: > *added support to decode some PNG files > *added check for png.h / dynamic loading of libpng.so > > configure.ac | 2 > dlls/oleaut32/olepicture.c | 205 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 207 insertions(+), 0 deletions(-) > > -- > Evan Stade > > Hi, How can I improve this patch such that it will be accepted? -- Evan Stade

2 1

Re: shell32: Make SHGetDesktopFolder use a cached instance of IShellFolder
by Alexandre Julliard June 21, 2007

June 21, 2007

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > + sf = LocalAlloc( LMEM_ZEROINIT, sizeof (IGenericSFImpl) ); > + if (!sf) > + return E_OUTOFMEMORY; > + > + if (InterlockedCompareExchangePointer((void *)&cached_sf, sf, NULL) != NULL) > + LocalFree( sf ); /* some other thread already been here */ > + else > + { > + sf->ref = 0; > + sf->lpVtbl = &vt_MCFldr_ShellFolder2; > + sf->pidlRoot = _ILCreateDesktop(); /* my qualified pidl */ > + sf->sPathTarget = SHAlloc( (lstrlenW(szMyPath) + 1)*sizeof(WCHAR) ); > + lstrcpyW( sf->sPathTarget, szMyPath ); > + } > + } You need to initialize the object completely before storing it as cached entry. -- Alexandre Julliard julliard(a)winehq.org

1 0

ntdll: Constify some variables (1 of 2)
by Andrew Talbot June 21, 2007

June 21, 2007

Please ignore this patch. Thanks, -- Andy.

1 0

Re: [kernel32][tests] Add test for GetShortPathNameW
by Dmitry Timoshkov June 21, 2007

June 21, 2007

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > + WCHAR PROG_FILES_DIR[MAX_PATH]; Looks like that this variable is not used anywhere. > static DWORD (WINAPI *pGetLongPathNameA)(LPCSTR,LPSTR,DWORD); > static DWORD (WINAPI *pGetLongPathNameW)(LPWSTR,LPWSTR,DWORD); > +static DWORD (WINAPI *pGetShortPathNameW)(LPWSTR,LPWSTR,DWORD); I don't see where pGetShortPathNameW is initialized. > + file = CreateFileW(short_path, GENERIC_READ|GENERIC_WRITE, 0, > + NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); > + ok(file != INVALID_HANDLE_VALUE, "File was not created.\n"); > + ret = WriteFile(file, "test", strlen("test"), NULL, NULL); > + ok(ret, "Can not open file!!\n"); The error message in ok() is not correct. > + CloseHandle(file); > + ret = DeleteFileW(short_path); > + ok(ret, "Can not delete file.\n"); > + GetTempPathW(MAX_PATH, path); > + lstrcatW(path, src); > + lstrcatW(path, backSlash); > + ret = RemoveDirectoryW(path); 'path' at this point already contains what you need, calling GetTempPathW and friends is not needed, and that would simplify the code a bit. > +static void test_GetShortPathNameW(void) > +{ > + WCHAR empty[MAX_PATH]; > + WCHAR pathE[] = {'p','a','t','h','t','e','s','t',0}; > + WCHAR pathRL[] = {0x0414,0x043B,0x0438,0x043D,0x043D,0x043E,0x0435,0x0418,0x043C,0x044F,0}; /* Long Russian name > */ > + WCHAR pathRS[] = {0x0418,0x043C,0x044F,0}; /* Short Russian name */ Do you really need the test to use cyrillic characters? That won't work if underlying unix locale is not russian regardless what you set the thread locale to. > + /* Not present in all windows versions */ > + if(pGetShortPathNameW) > + { > + SetLastError(0xdeadbeef); > + length = pGetShortPathNameW(NULL,NULL,0); > + if(GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + { > + skip("GetShortPathNameW is not implemented\n"); > + return; > + } Indentation inside of 'if(pGetShortPathNameW)' is completely messed up. -- Dmitry.

2 2

Re: [kernel32][tests] Add test for GetShortPathNameW
by Detlef Riekenberg June 20, 2007

June 20, 2007

On Di, 2007-06-19 at 13:18 +0400, Anatoly Lyutin wrote: > + { > + SetLastError(0xdeadbeef); > + length = pGetShortPathNameW(NULL,NULL,0); > + if(GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + { > + skip("GetShortPathNameW is not implemented\n"); > + return; Your indention looks wired -- By by ... Detlef

1 0

NULL ptr dereferences found with Calysto static checker
by Domagoj Babic June 20, 2007

June 20, 2007

Hi, I've ran my static checker Calysto on Wine v0.9.35 and got 78 bug reports: makedep: 1 sfnt2fnt: 4 winebuild: 6 winedump: 2 winegcc: 5 libwine: 60 If you are interested in the reports, please: 1) read http://www.cs.ubc.ca/~babic/index_calysto_community.htm 2) if the conditions are acceptable, let me know where to send the reports. Kind regards, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

1 0

On stuttering audio in quartz/DirectShow
by Alex Villacís Lasso June 20, 2007

June 20, 2007

Upon checking the source code of dlls/quartz I found out about the method SetSyncSource defined in the IBaseFilter interface: dsoundrender.c:static HRESULT WINAPI DSoundRender_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filesource.c:static HRESULT WINAPI AsyncReader_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filtergraph.c:static HRESULT WINAPI MediaFilter_SetSyncSource(IMediaFilter *iface, IReferenceClock *pClock) parser.c:static HRESULT WINAPI Parser_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) transform.c:static HRESULT WINAPI TransformFilter_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) videorenderer.c:static HRESULT WINAPI VideoRenderer_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) In particular, I see the following two things about sync sources: 1) I see no effort on part of filtergraph.c to add a sync source when simply asked to render a file 2) Even if it did, current implementation of videorenderer.c does nothing with its sync source So I have a couple of questions: 1) Am I right to assume that a sync source might be used to synchronize and (if necessary) drop frames at the videorenderer in order to maintain synchronization and avoid stuttering? 2) Could the sttutering really be solved by implementing the using and passing of a synchronization source (systemclock.c) in file rendering? If so, then the migration to DirectDraw would become just an optimization to increase the frame rate. Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

2 1