- wine-devel - winehq.org

RFC: winediag script
by Roderick Colenbrander 02 Dec '09

02 Dec '09

Hi, Over the years I have assisted a lot of people setting up Wine. In a lot of cases Wine doesn't work well because of missing libraries, pulseaudio, misconfigured display drivers and so on. I have written a script called 'winediag' which attempts to scan a system for the most common problems. Right now it contains mostly display driver related checks and a few basic audio / printing checks. I hope people have suggestions for most tests e.g. network tests (/etc/hosts, samba), more thorough driver checks and son. What do you guys think about it so far? (BTW I'm not a shell guru, so I would love to get some positive feedback) Thanks, Roderick Colenbrander

1 0

Re: [PATCH 1/2] msvcrt: Add test to check if signal(SIGBREAK, ...) works (todo_wine).
by James Mckenzie 02 Dec '09

02 Dec '09

Peter Rosin <peda(a)lysator.liu.se> >Subject: [PATCH 1/2] msvcrt: Add test to check if signal(SIGBREAK, ...) works (todo_wine). > > AUTHORS is not a developer editable file. Resubmit without this change. When you have submitted enough changes to Wine, you name will be added by AJ. James McKenzie

1 0

Valgrind cleanup status
by Dan Kegel 02 Dec '09

02 Dec '09

The logs of valgrind errors at http://kegel.com/wine/valgrind/logs/ are showing a nice downward trend: date files errors nonleak errors 2009-10-23 84 2383 339 2009-10-26 82 2344 319 2009-10-27 82 2318 294 2009-10-28 83 2325 294 2009-10-29 80 2279 253 2009-10-30 81 2304 280 2009-11-03 80 2612 301 2009-11-04 78 2290 276 2009-11-05 79 2295 268 2009-11-09 73 2215 254 2009-11-10 75 2266 296 2009-11-11 75 2236 263 2009-11-13 72 2264 234 2009-11-16 69 1724 222 2009-11-17 69 1711 221 2009-11-18 88 1736 253 2009-11-19 85 1696 247 2009-11-26 76 1628 168 2009-11-27 88 1797 302 2009-11-30 76 1779 288 2009-12-01 73 1723 230 The spike at 11-27 was when I started running with my heap tail corruption detection patch; those errors were present before, but not detected. Thanks to everyone who's been chipping away at these warnings. (Part of the decline has been knowing which suppressions to add, but that's ok, cleaner logs are good.) I'm mostly worried about nonleak errors for now, so I might be undercounting leak errors somewhat. As always, more help with these would be welcome. Some of the errors aren't that hard to deal with (but at the same time, some of them look easy but are subtle, so take care). - Dan

1 0

Re: [2/4] ntdll: add support for the HEAP_FREE_CHECKING_ENABLED style of heap overrun detection.
by Alexandre Julliard 02 Dec '09

02 Dec '09

Dan Kegel <dank(a)kegel.com> writes: > @@ -85,6 +85,7 @@ typedef struct > > #define ARENA_INUSE_FILLER 0x55 > #define ARENA_FREE_FILLER 0xaa > +#define ARENA_PAD_FILLER(address) (((int)(address) & 1) ? 0xee : 0xfe) Don't cast addresses to int. > +static PVOID HEAP_ValidateTail( const HEAP *heap, const void *arena, const void *p, SIZE_T size, SIZE_T filler_size ) > +{ > + unsigned char *tail = ((unsigned char *)p) + size; > + int j=0; Please use correct types. j should be a SIZE_T, tail should be a const pointer. > @@ -1477,7 +1561,9 @@ BOOLEAN WINAPI RtlFreeHeap( HANDLE heap, ULONG flags, PVOID ptr ) > pInUse = (ARENA_INUSE *)ptr - 1; > if (!(subheap = HEAP_FindSubHeap( heapPtr, pInUse ))) > { > - if (!find_large_block( heapPtr, ptr )) goto error; > + ARENA_LARGE *arena = find_large_block( heapPtr, ptr ); > + if (!arena) goto error; > + if (!validate_large_arena( heapPtr, arena, NOISY )) goto error; Validation should only happen when explicitly requested. > diff --git a/dlls/ntdll/tests/heap.c b/dlls/ntdll/tests/heap.c > new file mode 100644 > index 0000000..7cfa554 > --- /dev/null > +++ b/dlls/ntdll/tests/heap.c The tests should go with the existing heap tests in kernel32. > +static void test_free_overrun(void) > +{ > + if ((pRtlGetNtGlobalFlags() & FLG_HEAP_ENABLE_FREE_CHECK) == 0) { > + skip("\ > +Skipping heap free padding overrun test. To enable:\n\ > +on Wine, use gflags to enable global heap free checking, or set the following key:\n\ > +[HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager]\n\ > +\"GlobalFlag\"=dword:00000020\n\ > +On Windows, use gflags to enable heap free checking for ntdll_test.exe.\n"); > + return; You should create your own heap with checking enabled so that it can be tested in all cases. Also the patch is still too large, changes to sensitive areas like the heap code should be very small and focused. -- Alexandre Julliard julliard(a)winehq.org

2 3

New winetricks 20091125: new verbs ie7, alsa, fbo, pbuffer, ...
by Dan Kegel 02 Dec '09

02 Dec '09

Pie's in the oven, time for another winetricks release. Changes in this version: Add experimental dotnet35 verb Add IE7 verb. Based on a patch by Hans Leidekker. Add verbs alsa, audioio, coreaudio, esound, jack, nas, oss to override sound driver Add verbs backbuffer, fbo, pbuffer for setting offscreen rendering buffer Don't crash winecfg if native comctl32 is used Fix gecko to work with wine-1.1.33. Make vc2003toolkit and psdk2003 verbs run on windows On cleanup, remove $WINETRICKS_TMP, not just the files in it Sorted command menu Update Firefox to 3.5.5 Update mpc to latest version, move the exe to Program Files and add it to %PATH% 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, Erik Inge Bolsoe, and Hans Leidekker. This message posted in gmail (basic mode) in ie7 in wine.

3 3

Silencing RtlNtStatusToDosErrorNoTeb() a bit
by Wolfram Sang 02 Dec '09

02 Dec '09

Hi, while debugging an application (Project One, available at [1]), I noticed that wine (today's git) throws a lot of these fixmes: fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000109 Looking around, I found this page[2] stating that ERROR_MR_MID_NOT_FOUND is an expected return value for c0000109, so that the fixme is not needed here. I updated the if clause accordingly: diff --git a/dlls/ntdll/error.c b/dlls/ntdll/error.c index 9469f6f..e125163 100644 --- a/dlls/ntdll/error.c +++ b/dlls/ntdll/error.c @@ -68,7 +68,9 @@ ULONG WINAPI RtlNtStatusToDosErrorNoTeb( NTSTATUS status ) if (status < table->end) { DWORD ret = table->table[status - table->start]; - if (ret == ERROR_MR_MID_NOT_FOUND) FIXME( "no mapping for %08x\n", status ); + if (ret == ERROR_MR_MID_NOT_FOUND && + status != STATUS_MESSAGE_NOT_FOUND) + FIXME( "no mapping for %08x\n", status ); return ret; } table++; This solution has the advantage of being not very intrusive, but the disadvantage that it might be not nicely maintainable. Another &&-block has to be added for each other status found validly returning ERROR_MR_MID_NOT_FOUND. Another solution might be to define, let's say, ERROR_WINE_FIXME for all real fixmes and convert them to ERROR_MR_MID_NOT_FOUND. Something like (just a draft): #define ERROR_WINE_FIXME 0xffffffff DWORD ret = table->table[status - table->start]; if (ret == ERROR_WINE_FIXME) { FIXME( "no mapping for %08x\n", status ); ret = ERROR_MR_MID_NOT_FOUND; } return ret; [and lots of table entries changed] Well, this is pretty intrusive, but may be better distinguishing the different cases perhaps. Then again, this additional #define is polluting the ERROR_-namespace. I think I prefer the first version for now, perhaps there is no second status validly returning ERROR_MR_MID_NOT_FOUND? Any advice on how I should proceed? Thanks in advance, Wolfram [1] ftp://ftp.scs-trc.net/pub/c64/Tools/Graphics/Project1_V0.5.zip [2] http://support.microsoft.com/kb/113996

2 2

Re: [3/5] imagehlp: Implement ImageAddCertificate
by Alexandre Julliard 01 Dec '09

01 Dec '09

Owen Rudge <orudge(a)codeweavers.com> writes: > + sd = &nt_hdr.OptionalHeader.DataDirectory[IMAGE_FILE_SECURITY_DIRECTORY]; > + > + sd->Size = dwSize; > + sd->VirtualAddress = dwOfs; > + > + TRACE("size = %x addr = %x\n", sd->Size, sd->VirtualAddress); > + > + /* write the header back again */ > + count = SetFilePointer(handle, dos_hdr.e_lfanew, NULL, FILE_BEGIN); > + > + if (count == INVALID_SET_FILE_POINTER) > + return FALSE; > + > + count = 0; > + > + r = WriteFile(handle, &nt_hdr, sizeof nt_hdr, &count, NULL); The virtual address is not necessarily the same as the disk offset. Also you should check the various header sizes and magic numbers. The existing code is broken in that respect too, but as long as it was only reading it wasn't a big problem. Once we start modifying the file it needs to be much more robust. -- Alexandre Julliard julliard(a)winehq.org

2 1

Introducing WineTestBot
by Greg Geldorp 01 Dec '09

01 Dec '09

Or, for those who like to be buzzword compliant, the Wine Testing Cloud Service. Inspired by all the talk about testing during WineConf 2009, I set out to fill a gap in Wine testing. Most of the Wine developers don't have access to a battery of Windows machines to run the tests they write/modify on. As a result, there are quite a few regressions in the tests themselves. The WineTestBot provides a whole bunch of Windows machines, ready to accept and run your modified tests. In its current state you can submit Windows executables (most likely cross-compiled on a Linux box) to the bot, which will run it in VMs of your choice. So, how does this work in practice? First, go to https://winetestbot.geldorp.nl and click on "Register" to register an account. Once your account is approved (you'll receive a notification via email) you can log in. After log in, the menu in the sidebar changes to include an item "Submit job". This allows you to upload an .exe from your local system to the bot. You can pick the VMs (Windows versions) you want to run the test on. From the "Home" page you can see the status of your job, by clicking on the job id you get a bit more info about the progress. Once the test is completed, the stdout generated by the test is retrieved from each VM and made available via that web page. The tests are run on VMware ESX VMs, so it's probably not all that useful to run sound and DirectDraw tests on them. Also, no Win9x VMs are available. I haven't set up 64-bit VMs yet, but those should be easy to add. Before each test run, the VMs are reset to a clean snapshot, so no cruft from old tests will be left around. Your test shouldn't take more than 5 minutes, which is more than the WineTest framework allows anyway. For each Windows version, there is a "base" VM and there can be additional VMs too. The idea is that the base VM is running the most up-to-date and most often used variation of that Windows version, so running your test on the base VMs should give you a good indication on how the test behaves. Additionally, you can run your tests on the other variations too. So, for example for XP the base VM is XP Professional SP3, but there are additional VMs like SP2, Media Center Edition, and a non-English version available too. Obviously, even when you use all available VMs you'll cover a very small subset of all possible configurations (most notably you won't test on a single physical system) so please do check http://test.winehq.org after your patch has been accepted to see if you introduced failures on other machines. The plan for the future is to extend this a bit. Speaking from my own experience, I know that programmers like to be as lazy as possible. Which means that having to cross-compile your test before you can send it off to the bot will be seen as a bit of a hurdle. So the next step will be to allow you to upload the git diff instead of a Windows executable. The bot will apply your diff to a git tree and take care of creating the cross-compiled Windows executable, which it will then run on the Windows VMs. Step 3 will be to have the bot watch wine-patches for anything that might impact the tests and do the apply diff/cross-compile/run thing automatically. Obviously I'll be looking at Dan's patch watcher for this 3rd step. Security is a concern, but perhaps more for me than for you :-). I have to trust you not to abuse this system. If you want to do something naughty please do it on your own machine. There are some safeguards in the system, like the timeout. In general, you should not expect any privacy, I do have access to the consoles of the VMs and firewall logs. If you want to use this system for something else than Wine tests, please talk to me first. I'd like to thank Paul Vriens who acted as beta tester and made some valuable suggestions. I welcome feedback so if you have any ideas on how to improve this thing further please let me know. Ge.

5 6

Re: [PATCH] mshtml: check for NULL return from allocations
by Jacek Caban 01 Dec '09

01 Dec '09

Hi Marcus, Marcus Meissner wrote: > Hi, > > Coverity thinks we miss NULL checks and yes, we do. > Added some. > > (...) > > - wstrbuf_init(&buf); > + if (!wstrbuf_init(&buf)) > + return E_OUTOFMEMORY; > range_to_string(This, &buf); > - if(buf.buf) > - *p = SysAllocString(buf.buf); > + *p = SysAllocString(buf.buf); > wstrbuf_finish(&buf); > > TRACE("ret %s\n", debugstr_w(*p)); > + if (!*p) > + return E_OUTOFMEMORY; > return S_OK; > } This check is not meant to check allocation failure, but to check if range_to_string set it to NULL. We even have a tests for this. More error handling is a good thing to do, but this check should remain unchanged. Thanks, Jacek

1 0

Re: [PATCH 2/2] jscript: Added lastIndex tests.
by Paul Vriens 01 Dec '09

01 Dec '09

On 11/30/2009 09:12 PM, Jacek Caban wrote: > --- > dlls/jscript/tests/regexp.js | 66 > ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 66 insertions(+), 0 deletions(-) > > Hi Jacek, This one introduces test failures on Vista+ : http://test.winehq.org/data/tests/jscript:run.html Could you have a look? -- Cheers, Paul.

2 3

work underway: Dependency on openal incoming
by Maarten Lankhorst 01 Dec '09

01 Dec '09

Hi all, This message is mostly aimed towards package maintainers, since one of the discussions at wineconf last year was that package maintainers would like to hear in advance about changing dependencies. Wine's DirectSound implementation will, in the next release or the release after that, rely on OpenAL, the recommended library for linux or bsd's is openal-soft, and preferably a recent version, as old versions might miss certain experimental extensions that dsound will need. Mac users shouldn't need an external openal library, since it has its own openal implementation. Without openal at compile-time, dsound will still build, but report no sound devices found. Some games or other applications may refuse to run if no dsound devices are found, so its recommended that you build with openal. If openal is compiled in, but missing at runtime, dsound.dll will refuse to load, which probably means most games will not run either. Cheers, Maarten

3 5

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW
by Alexandre Hardy 01 Dec '09

01 Dec '09

Thanks Paul, Right! Tried to implement it too fast! Other parts of the test code dereference the function pointer and I took my lead from there without checking properly. As far as the length goes, I don't really know much about UNC pathnames, so I'm not sure what exactly the result should be. I will need to read up to find an example that I can guarantee the length of. Kind regards Alexandre On Tue, Dec 1, 2009 at 12:52 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 12/01/2009 08:44 AM, Alexandre Hardy wrote: >> >> + length = (*pGetLongPathNameW)(unc_path,NULL,0); > > Why the brackets around *pGetLongPathNameW? > >> + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname >> (length=%d)\n",length); > > You called the W-function so the ok text needs to be adjusted. You also know > the length so why not check explicitly? > > -- > Cheers, > > Paul. > -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

1 0

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW
by Paul Vriens 01 Dec '09

01 Dec '09

On 12/01/2009 08:44 AM, Alexandre Hardy wrote: > + length = (*pGetLongPathNameW)(unc_path,NULL,0); Why the brackets around *pGetLongPathNameW? > + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname (length=%d)\n",length); You called the W-function so the ok text needs to be adjusted. You also know the length so why not check explicitly? -- Cheers, Paul.

1 1

Re: [PATCH 4/5] dsound: Add support for OpenAL IDirectSoundCaptureBuffer
by Chris Robinson 01 Dec '09

01 Dec '09

Hi. On Monday 30 November 2009 1:56:20 pm Maarten Lankhorst wrote: > + if (This->playing) > + { > + pos2 = This->format->nSamplesPerSec / 100; > + pos2 *= This->format->nBlockAlign; > + pos2 += pos1; > + if (!This->looping && pos2 > This->buf_size) > + pos2 = 0; > + else > + pos2 %= This->buf_size; > + } Does non-looping capture let the write position get to This->buf_size? It looks like a position of This->buf_size should set the position to 0 too, if This->buf_size+1 would. > + if (format->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > + { > + WAVEFORMATEXTENSIBLE *wfe = (WAVEFORMATEXTENSIBLE*)format; > + if (!IsEqualGUID(&wfe->SubFormat, > &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) > + return DSERR_BADFORMAT; > + else if (format->cbSize < sizeof(WAVEFORMATEXTENSIBLE)- > sizeof(WAVEFORMATEX)) > + return DSERR_INVALIDPARAM; > + else if (format->cbSize > sizeof(WAVEFORMATEXTENSIBLE)- > sizeof(WAVEFORMATEX) > + && format->cbSize != sizeof(WAVEFORMATEXTENSIBLE)) > + return DSERR_CONTROLUNAVAIL; > + } You should probably check the cbSize before accessing the extended information, otherwise it may indicate that there isn't enough space for the extended information. Also, is it necessary to reject formats with a higher cbSize than needed (IIRC, Wine's tests showed some Windows versions allowed it)? > + buf_format = alGetEnumValue(fmt_str); Unfortunately, you can't call this function when a context is not set (it'll probably work on some systems, but technically shouldn't). And setting a context makes no sense for capture. Setting buf_format directly to the enum in the switches should be all you need to do.. just make sure to initialize it to 0 so the check won't use it uninitialized. > + This->dev = alcCaptureOpenDevice(This->parent->device, > This->format->nSamplesPerSec, buf_format, This->buf_size); Note that the buffer size given to OpenAL is in sample frames, not bytes. It's not a direct problem here, per se, but it may be an issue if a large size is requested (ie, where n samples would work, but n*2 or n*4 won't).

2 1

File owner permissions
by Ben Peddell 01 Dec '09

01 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What do you think is the best course of action for setting the owner permissions on a file: 1. Base the file owner permissions on the DACL permissions of the groups the file owner is a member of? (My patch or similar) 2. Change the file owner permissions only if they are listed in the DACL? (Paul Chitescu's patch or similar) 3. Allow the file owner read/write/traverse access (u+rwX) to their own files by default? (similar to #2) 4. Bypass the file-owner-permissions-cannot-be-overridden issue by having a third-party trustee (like SYSTEM) own and have full access to the files. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksUuqAACgkQTHDAI68NsunuQACePqDXjcfvvDXhoEI0rH4WB5Ri 3+YAnjqioPVg9li+Axbo3vUMueqn9phd =pNiD -----END PGP SIGNATURE-----

1 0

dual platform win32/linux malware
by Dan Kegel 01 Dec '09

01 Dec '09

The apocalypse approaches: http://ask.slashdot.org/article.pl?sid=09/12/01/0025213 Perhaps this will drive people towards using totally locked down systems...

2 1

re: RFC: EM_FORMATRANGE Patch for Wine-1.1.33
by Dan Kegel 01 Dec '09

01 Dec '09

I can't do a deep review, but I did see that you have some commented out code, and IIRC AJ doesn't like that. Better to remove it than comment it out. BTW, besides the three apps mentioned in http://bugs.winehq.org/show_bug.cgi?id=6254, what apps depend on this? - Dan

2 1

Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects
by Alexandre Julliard 30 Nov '09

30 Nov '09

Eric Pouech <eric.pouech(a)orange.fr> writes: > diff --git a/server/debugger.c b/server/debugger.c > index 795a24a..4458a3b 100644 > --- a/server/debugger.c > +++ b/server/debugger.c > @@ -677,6 +677,8 @@ DECL_HANDLER(get_exception_status) > if ((event = (struct debug_event *)get_handle_obj( current->process, req->handle, > 0, &debug_event_ops ))) > { > + NTSTATUS status = STATUS_PENDING; > + > close_handle( current->process, req->handle ); > if (event->state == EVENT_CONTINUED) > { > @@ -686,10 +688,10 @@ DECL_HANDLER(get_exception_status) > set_reply_data( &event->context, size ); > current->context = NULL; > } > - set_error( event->status ); > + status = event->status; > } > - else set_error( STATUS_PENDING ); > release_object( event ); > + set_error( status ); Releasing an object should never change the error code. Where do you see that happening? -- Alexandre Julliard julliard(a)winehq.org

2 2

Introducing WineTestBot
by Joerg-Cyril.Hoehle＠t-systems.com 30 Nov '09

30 Nov '09

Greg, Congratulations, that's a great service. >I know that programmers like to be as lazy as possible. >So the next step will be to allow you >to upload the git diff instead of a Windows executable. The next most wanted improvement! Step 3.5 suggestion: split that in two steps, allow us to upload the patch and download the .exe. >so it's probably not all that useful to >run sound and DirectDraw tests on them. Then we can take the .exe to machines with sound and DD/DX to complete the impact analysis. Regards, Jörg Höhle.

2 1

Re: [PATCH 1/3] ole32: Add test for CoLockObjectExternal with fLastUnlockReleases as FALSE.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/23/2009 04:07 PM, Rob Shearman wrote: > --- > dlls/ole32/tests/marshal.c | 38 +++++++++++++++++++++++++++++++++++++- > 1 files changed, 37 insertions(+), 1 deletions(-) > > Tested on XP. > Hi Rob, http://test.winehq.org/data/tests/ole32:marshal.html doesn't look too healthy. Not sure if this is the actual one as there were a few that touched marshal.c. Could you have a look? -- Cheers, Paul.

1 0

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
by Alexandre Julliard 30 Nov '09

30 Nov '09

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > } > > - *service->service_entry = new_entry; > - save_service_config(service->service_entry); > + err = save_service_config(&new_entry); > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > service_unlock(service->service_entry); This can't work, the strings have been freed already. -- Alexandre Julliard julliard(a)winehq.org

2 2

Fedora users, please test mci patch about time-out/hanging machine
by Joerg-Cyril.Hoehle＠t-systems.com 30 Nov '09

30 Nov '09

Hi, Testhq.org results from 17th of November about winmm:mci were striking: All machines producing a timeout had "f11" in their name. (Another day, some f11 machines passed the tests). http://test.winehq.org/data/4990ca0ea342bd115a9a46047b3b2de599cb916e/index_… Please test whether the following patch correlates with hanging machines. Not checking waveoutwrite's return code for sure has the potential to hang the play loop, waiting for a buffer to come back that was never sent out in case of error. But then, why did waveOutWrite fail? That's what I'd like you to investigate. Why Fedora 11? Below patch only adds error reporting to the mciplay loop. Feel free to add the same to the mcirecord loop. diff --git a/dlls/mciwave/mciwave.c b/dlls/mciwave/mciwave.c index cdf9146..fdb6b18 100644 --- a/dlls/mciwave/mciwave.c +++ b/dlls/mciwave/mciwave.c @@ -882,6 +882,7 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, &waveHdr[whidx], waveHdr[whidx].dwBufferLength, waveHdr[whidx].dwBytesRecorded); dwRet = waveOutWrite(wmw->hWave, &waveHdr[whidx], sizeof(WAVEHDR)); + if (dwRet) ERR("Write %d\n", dwRet); left -= count; wmw->dwPosition += count; TRACE("after WODM_WRITE dwPosition=%u\n", wmw->dwPosition); @@ -893,7 +894,8 @@ static DWORD WAVE_mciPlay(MCIDEVICEID wDevID, DWORD_PTR dwFlags, DWORD_PTR pmt, WAVE_mciPlayWaitDone(wmw); /* to balance first buffer */ /* just to get rid of some race conditions between play, stop and pause */ - waveOutReset(wmw->hWave); + dwRet = waveOutReset(wmw->hWave); + if (dwRet) ERR("Reset %d\n", dwRet); waveOutUnprepareHeader(wmw->hWave, &waveHdr[0], sizeof(WAVEHDR)); waveOutUnprepareHeader(wmw->hWave, &waveHdr[1], sizeof(WAVEHDR)); A future patch will abort the loop in case of error. However so far, when creating situations that hung on my (non-Fedora) machine (cf. bug #20664), the above ERR message was never triggered. So the cause of random mci time-out on test.winehq may as well lay elsewhere. Thanks for your help, Jörg Höhle

3 4

today's git broke winetricks gecko :-(
by Joerg-Cyril.Hoehle＠t-systems.com 30 Nov '09

30 Nov '09

Hi, >wine cmd /c echo yes now downloads gecko. Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why. >Any suggestions are welcome. Winecfg would be a better place to propose the installation of an optional component. Perhaps I'm a very atypical Wine user: - no MMORPG, no ie6 - My Wine is not used for anything online. Quite to the contrary, I have some iptables firewall rules to disable Wine IP traffic should anything ever manage to get in. - I never used winetricks. I sometimes peeked at it. When I needed Gecko long ago, I saw that the Wine source contains code to install it, downloaded Gecko.cab myself, modified the one registry entry to point to the .cab and let it install. Worked. IMHO, no general-purpose application should attempt to talk to the internet when it starts. Please leave that behaviour to viruses and trojans only (and alikes, e.g. Adobe's pdf). Maybe I'm too old-fashioned in this decade of "always online even in the subway" technical achievements. Or I've been in the privacy-protection (Datenschutz) and security business for too long. Regarding winecfg, it could display "no Gecko/HTML support, click here to install it (need be online)" in flashing red to attract the user's attention once you start it. I wouldn't mind. Regards, Jörg Höhle.

13 25

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)
by Alexandre Julliard 30 Nov '09

30 Nov '09

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Added support for read/only Registry, similar to > unprivileged users > > Rationale: > This is a first step towards implementing shared wine prefixes with > most users being unprivileged and a single Administrator (power user, etc.) > capable of installing programs. I don't think it's a step in the right direction. What you need is proper access control with security descriptors, like we have for other objects. A single read-only bit cannot be extended to support this. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
by Nikolay Sivov 30 Nov '09

30 Nov '09

Ilya Shpigor wrote: > +static INT > +DATETIME_GetText (DATETIME_INFO *infoPtr, INT count, LPWSTR dst) > +{ > + WCHAR buf[80]; > + int i; > + > + if(!count) return 0; > + > + dst[0] = 0; > + for (i = 0; i < infoPtr->nrFields; i++) > + { > + DATETIME_ReturnTxt(infoPtr, i, buf, sizeof(buf)/sizeof(buf[0])); > + if ((strlenW(dst) + strlenW(buf)) <= count) > + strcatW(dst, buf); > + else break; > + } > + return strlenW(dst); > +} > I don't think it's a right way. You probably should use window text instead updating it on every change, see how GetWindowText is implemented. > @@ -674,6 +675,10 @@ static void test_wm_set_get_text(void) > ret = SendMessage(hWnd, WM_GETTEXT, sizeof(buff), (LPARAM)buff); > ok(strcmp(buff, a_str) != 0, "Expected text not to change, got %s\n", buff); > > + GetSystemTime(&stime); > + sprintf(time, "%d.%d.%d", stime.wDay, stime.wMonth, stime.wYear); > + ok(!strcmp(buff, time), "Expected %s, got %s\n", time, buff); > + > DestroyWindow(hWnd); > } > Test is definitely wrong. You can't expect DD.MMMM.YYYY pattern here, it's locale dependent.

2 4

Re: mciqtz32: Fix open/close omissions.
by Dmitry Timoshkov 30 Nov '09

30 Nov '09

You need to provide more information why is this change required, and what is the problem you are trying to fix. -- Dmitry.

1 0

Re: Implement a stub for PrintWindow in user32
by Dmitry Timoshkov 30 Nov '09

30 Nov '09

"Luke Benstead" <kazade(a)gmail.com> wrote: > +/************************************************************************ > + * PrintWindow (USER32.@) > + * > + */ > +BOOL WINAPI PrintWindow(HWND hwnd, HDC hdcBlt, UINT nFlags) > +{ > + return TRUE; > +} If this is a stub, it should not return TRUE, should print a FIXME, and probably set an appropriate last error. Besides, MSDN has a nice hint how to implement this API properly. -- Dmitry.

1 0

Re: wine.inf: Remove obsolete and duplicate entries.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 02:08 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Dear reviewers, > > Vitaliy Margolen wrote in the discussion of bug #20693: >> Those entries shouldn't be in the wine.inf in the first place >> (as Alexandre already said). If anything they should be removed >>from there to lessen the confusion. > > Here is a patch to remove those entries. Note that > I'm not familiar enough with the printing system or MS-Windows' > expected vital entries to judge whether the entries should be present > as default fallbacks on systems compiled without cups, > or which have no printer, > or because some apps on MS-Windows crash if they are not present > even when there's no printer > or whatever reason. I just trust your word. > > All I can see is that these entries about [HKLM\HARDWARE] do not make > it into system.reg on my Linux machine even though they are present in > wine.inf, I suppose because the dynamic device detection code > (hal/dbus) removes them (with no printer nor cups-dev installed). > > Regards, > Jörg Höhle > Hi Jörg, This was already (partly) done in commit d19e2ada9ce2d52d8b09e984fe5b12803bf6d4ca. -- Cheers, Paul.

1 0

Re: mciavi: Simplify play loop.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 01:51 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > in the future, MCIAVI will hopefully be able to drive the loop > with either audio or video turned on or off individually > (setaudio/setvideo off), like native (e.g. mciavi can play > the audio tracks only). > Here's a first step towards unification. > > Regards, > Jörg Höhle > Tabs and space mixtures here as well. -- Cheers, Paul.

1 0

Re: mciqtz32: Fix open/close omissions.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 01:47 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Regards, > Jörg Höhle > Hi Jörg, You're mixing tabs and spaces here. -- Cheers, Paul.

1 0

Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO
by Henri Verbeet 30 Nov '09

30 Nov '09

2009/11/30 Stefan Dösinger <stefan(a)codeweavers.com>: > I think this will break color_fill_fbo(). My general feeling is that I'm seeing to much variants of "if (swapchain->render_to_fbo)". Also, I think this patch has parts that can be separated like e.g. the surface_init_sysmem() bit. Out of curiosity, what would the performance impact be of always rendering to FBO?

2 2

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()
by Dan Kegel 29 Nov '09

29 Nov '09

On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent(a)vromman.org> wrote: > - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * > sizeof(GdiPath*)); > - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath)); > - PATH_InitGdiPath(pStrokes[0]); > - pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(INT)); > - pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(POINT)); > - pStrokes[0]->numEntriesUsed = 0; > + pStrokes = NULL; ... Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment? - Dan

3 4

RFC: EM_FORMATRANGE Patch for Wine-1.1.33
by James McKenzie 29 Nov '09

29 Nov '09

All: Time to beat on this patch again and make it better. I've also attached it to bug 6254. Please make comments constructive. I would like to get assistance where to break this down so that it will be 'easier to swallow' pieces as this is one huge patch that AJ has rejected before. James McKenzie

1 0

windows shutdown process
by Vincent Povirk 29 Nov '09

29 Nov '09

In order to find the correct fix for bug 18753, I've been examining the shutdown process on Windows. I have written a program that logs the messages sent to it, and I've run it on Windows 7. What I found was that a shutdown produces the following sequence of events: * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION message. We return 1, allowing the session to end. * We get another 0x3b message, which leads to a WM_ENDSESSION. * Nothing else happens, but for some reason the program exits. I added a trace after the message loop returns to see if the program gets a WM_QUIT. It doesn't. Apparently, my test program was killed. I tried changing the window proc so that it loops infinitely when it gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown". (Naturally, it responds the same way if I return 0 from WM_QUERYENDSESSION.) This leads me to believe that Windows 7, when shutting down, immediately kills any process that returns from a WM_ENDSESSION message. Does that seem sane? I've posted my test program (source code and .exe file) at http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if other Windows versions behave the same way Windows 7 does. -- Vincent Povirk

2 2

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
by Rob Shearman 28 Nov '09

28 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > --- ./dlls/kernel32/locale.c.orig 2009-11-02 05:45:10.000000000 +0200 > +++ ./dlls/kernel32/locale.c 2009-11-26 19:35:39.000000000 +0200 > @@ -3017,7 +3017,7 @@ > RtlInitUnicodeString( &keyName, szKeyName ); > InitializeObjectAttributes(&attr, &keyName, 0, hRootKey, NULL); > > - if (NtOpenKey( &hkey, KEY_ALL_ACCESS, &attr ) != STATUS_SUCCESS) > + if (NtOpenKey( &hkey, MAXIMUM_ALLOWED, &attr ) != STATUS_SUCCESS) > hkey = 0; > > return hkey; This is ugly. The function should be changed to allow the required access rights to be specified. -- Rob Shearman

1 0

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible
by Rob Shearman 28 Nov '09

28 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > @@ -376,7 +376,7 @@ > InitializeCriticalSection(&(*db)->cs); > > err = RegCreateKeyExW(HKEY_LOCAL_MACHINE, SZ_SERVICES_KEY, 0, NULL, > - REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, > + REG_OPTION_NON_VOLATILE, MAXIMUM_ALLOWED, NULL, > &(*db)->root_key, NULL); > if (err != ERROR_SUCCESS) > HeapFree(GetProcessHeap(), 0, *db); I'm not happy with this change because the code was written with the assumption that data it will always have permission to write data back to keys under root_key. The return value from save_service_config isn't always checked and thus this could lead to silent data loss. In any event, the use of MAXIMUM_ALLOWED should not be encouraged where at all possible [1] and instead the code should try the most permissions it needs and fall back to less as appropriate. > @@ -417,7 +417,7 @@ > break; > > WINE_TRACE("Loading service %s\n", wine_dbgstr_w(szName)); > - err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ | KEY_WRITE, &hServiceKey); > + err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ, &hServiceKey); > if (err == ERROR_SUCCESS) > { > err = load_service_config(hServiceKey, entry); This change is fine since hServiceKey is only every used with operations that require KEY_READ at the most. -- Rob Shearman [1] http://blogs.msdn.com/larryosterman/archive/2004/09/14/229658.aspx

1 0

Re: advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible
by Rob Shearman 28 Nov '09

28 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > Changelog: > advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible > > Makes read operation succeed on read/only Registry keys. Needs tests to show that this behaviour matches that on Windows. You should be able to achieve this by setting an appropriate security descriptor on the registry key before calling the function you are changing. However, the change to get_special_root_hkey looks fine to me. The rest of your patch isn't easy to review because you haven't generated the diff with the "-p" option. -- Rob Shearman

1 0

Wine programs - replicating bad design/bugs
by Jerome Leclanche 28 Nov '09

28 Nov '09

Ok, posting here to get a broader feedback on the issue. Recently, another bug* was closed about an enhancement to a wine program - a minor feature not present on Windows. This is an issue I've seen brought up before, and which I've brought up myself**. As far as the win32 api goes, I can totally agree on dysfunctions that need to be replicated. However I find this unnecessary for the wine programs (notepad, wordpad, regedit, any or more). The idea behind bug 20844 was to have a better integration with the desktop, where Shift-F3 is a common keybind for "Search previous...". The only problem with this kind of mindset is "where should we stop with new features?". IMHO, the issue behind the two bugs linked below is only a matter of better integration, better design. I can also understand how some developers' goal is to close bugs, sometimes disregarding the fact there is a problem to deal with before then. * http://bugs.winehq.org/show_bug.cgi?id=20844 ** http://bugs.winehq.org/show_bug.cgi?id=18622 J. Leclanche PS. In bug 18622, I'm not talking about a case-insensitive registry, but for the key being actually renamed.

2 2

Re: Corrections for signal handlers
by Markus Elfring 28 Nov '09

28 Nov '09

> And don't ask me to actually think about what I'm doing, I am still open for further discussions. > it's too hard to figure out how to print a string and a number without using printf(). This data display (e. g. for the input command and line number) is generally not a problem. But the situation is different in the context of a signal handler because of the limited set of async-signal-safe functions. Regards, Markus

1 0

Re: Corrections for signal handlers
by Markus Elfring 28 Nov '09

28 Nov '09

> Original printed more useful information. I am aware of the desire to get some data for easier program debugging conveniently. > Just dropping it in sake of "correctness" is wrong. I have got an opposite opinion. I am curious if more software developers would like to care for complete async-signal-safety. > You'll have to come up with something that prints the same This will not happen at the moment because of conflicting expectations. > or don't touch it. I assume that the involved implementation details will be reconsidered some day in the future. Regards, Markus

2 1

Re: Corrections for signal handlers
by Vitaliy Margolen 28 Nov '09

28 Nov '09

Markus Elfring wrote: > Hello, > > Some signal handler implementations are also affected by technical details that are described in an article by Justin Pincar. > https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+… > Your code looks even worse then your arguments for "correct" codding practices. > -static int watchdog; > +static sig_atomic_t watchdog; Don't do this, you've been told to leave it alone. > - fprintf( stderr, "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"); > + char const message[] = "wineserver crashed, please enable coredumps (ulimit -c unlimited) and restart.\n"; Should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); What's "(void)" doing here? Yes we do ignore returned states here and in 10000s or other places. Don't do that. > + (void) fsync(STDERR_FILENO); Why do you need sync here? > abort(); > --- a/tools/wmc/wmc.c Wine fix per program please. You'll have to split this into 3 separate patches. > static void segvhandler(int sig) > { > -<----->fprintf(stderr, "\n%s:%d: Oops, segment violation\n", input_name, line_number); > -<----->fflush(stdout); > -<----->fflush(stderr); > + char const message[] = "\nOops, segment violation\n"; Same as above - should be "static const char" in that exact order. > + > + (void) write(STDERR_FILENO, message, sizeof(message) - 1); > + (void) fsync(STDOUT_FILENO); > + (void) fsync(STDERR_FILENO); Remove bogus "(void)". > <----->abort(); > } Original printed more useful information. Just dropping it in sake of "correctness" is wrong. You'll have to come up with something that prints the same or don't touch it. Original used tabs (8-spaces) your patch uses 4-space indentation. Either keep the file's formatting or stick to 4-space indentation but DO NOT mix and match both inside one function. Same applies to tools/wrc/wrc.c Vitaliy.

1 0

re: Corrections for signal handlers
by Dan Kegel 28 Nov '09

28 Nov '09

I'm not sure this change does what you think: - fflush(stdout); ... + (void) fsync(STDOUT_FILENO); The real problem with your change is that *we don't care* whether the output of wineserver is garbled, because it is low priority debugging information, and I've never seen it garbled in practice. In short, it's not worth the time reviewing the patch. So while we appreciate your effort to improve the correctness of Wine's code, we would prefer it if you chose a more useful target. Also, Wine's patch review system is reputation-based. Your best avenue for getting pedantic corrections accepted is to get some pragmatic improvements accepted first. You might then be able to use some of your earned karma points on your favorite bikeshed problem. - Dan

1 0

Whitespace cleanups
by Nate Gallaher 28 Nov '09

28 Nov '09

I'm looking at working on a new area of wine (for me) and the file I'm going to be working with is rife with whitespace issues. Literal tabs are sprinkled around and the 80-col limit has been broken badly and often in easily fixable ways. I'm wondering what the acceptable approach is to these issues. I'd like to fix these issues before I start submitting functional patches. My question is this: Is it acceptable to fix the whole file in one patch (80-cols), or should I just fix the one function I'm planning on touching? Or should I grit my teeth and ignore the style issues entirely? Thanks, ~Nate

6 9

dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW
by Alexandre Hardy 28 Nov '09

28 Nov '09

The MSDN: http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx states that GetLongPathNameW returns the length of the string required to hold the pathname if the buffer is too small to hold the path. In the case where the buffer is too small, the filename should not be stored in the buffer. This ensures that the buffer is not written to (for UNC pathnames) if the buffer is not large enought to store the path. Kind regards Alexandre -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

2 1

Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e causes tooltip functions in e-Sword to stop functioning
by James McKenzie 27 Nov '09

27 Nov '09

All Commit 05c788ac6f464b75c2a55c847a91d3a79261ca8e richedit: Used ITextHost methods to avoid using window handle directly caused the tooltips popups to stop functioning in e-Sword. Has this been corrected in later Wine releases? I am at wine-1.1.14 with integrating the EM_FORMATRANGE patch. Thank you. James McKenzie

4 4

Re: [4/4] ntdll: partially support HEAP_DISABLE_COALESCE_ON_FREE, allows us to detect use-after-free
by Dan Kegel 27 Nov '09

27 Nov '09

Don't apply this one yet, just found a problem with it. On Tue, Nov 24, 2009 at 6:20 PM, Dan Kegel <dank(a)kegel.com> wrote: > This adds something like support for > HEAP_DISABLE_COALESCE_ON_FREE. > If the GlobalFlags registry entry has the > 200000 bit set, freed blocks are set > aside for a while rather than immediately > being released for reuse. This allows > us to poison them and check for use-after-free > or double-free errors, and report them as heap corruption. > > If you're running Valgrind, you get an immediate error > and stack trace for any of these heap corruption events, > which was the motivation for the patch series. > But the patches are useful even without valgrind. > > The number of blocks kept out of circulation is > 5000 by default, but can be set via an environment > variable. It ought to have a limit on number of bytes, > too, but this seemed enough for the moment. >

1 0

New valgrind results, this time with overrun checks and lots of new errors.
by Dan Kegel 27 Nov '09

27 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ is the first full run with the heap tail check enabled. Here are the first few new problems it found. Somehow, it found a bunch of invalid reads in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_crypt.txt all in a function called test_incorrect_api_usage(). Offhand that seems like something to suppress. The invalid write I already posted about is in http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advapi32_lsa.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advapi32_lsa.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-advpack_files.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-advpack_files.txt show an off-by-one buffer size issue (forgot to include space for nul char) in advpack (fix should be easy, anybody can grab this): Invalid write of size 2 at strcpyW (unicode.h:224) by lstrcpyW (string.c:104) by AdvInstallFileW (files.c:283) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513) Address 0x7f03d12e is 0 bytes after a block of size 30 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by AdvInstallFileW (files.c:282) by AdvInstallFileA (files.c:216) by test_AdvInstallFile (files.c:513) http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt show a more inscrutable error: Invalid write of size 4 at TAB_SetCurSel (tab.c:255) by TAB_WindowProc (tab.c:3367) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_CallProcAtoW (winproc.c:1023) by CallWindowProcA (winproc.c:2299) by tabSubclassProcess (tab.c:404) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by test_getters_setters (tab.c:752) by func_tab (tab.c:1174) by run_test (test.h:535) by main (test.h:585) Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd Nikolay touched that code back in March, perhaps he should have a look. etc. etc. Lots of triage to do. It'd be nice if somebody could volunteer to go through these, file bugs, and assign provision blame using 'git blame'... - Dan

3 7

Garmin watches and USB
by Chris Teague 26 Nov '09

26 Nov '09

I'm trying to get the Garmin ANT Agent 2.2.7 to run (http://www8.garmin.com/fitness/ant_product_page.jsp). This software talks over the ANT+ protocol (carried over USB) to the watch, to download Heart Rate and GPS info. I cannot get the program to install because it checks that the ANT dongle is plugged in before it will complete installation, and it won't detect it. I also cannot debug this .exe using IDA very effectively because it is a self-extracting zip executable. When I plug in the ANT dongle, it is recognized by Linux and mapped to ttyUSB0. The dongle came with the watch and is Garmin branded, but it's really a Dynastream ANT2USB chip. Below is what /var/log/messages shows when I insert the device. Nov 22 15:23:27 desktop kernel: [1982277.092697] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.335442] cp210x 4-1:1.0: cp210x converter detected Nov 22 15:23:27 desktop kernel: [1982277.452593] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.610343] usb 4-1: cp210x converter now attached to ttyUSB0 I'm trying to figure out exactly what the installer is looking for to see if the dongle is present. I get a "You must connect your USB ANT Stick.." message in a dialogbox, and a Retry button. I thought it was checking for the presence of a new COM port or maybe something in the Windows device tree? I have installed the app on a Windows box, copied over the directory to Linux and run the program successfully under Wine. I do not know if it is communicating with the ttyUSB0 device though, I suspect it is not and I test that out tonight. On Windows, inserting the USB Dongle does not create a new COM port - so my guess is that the software is not treating this as a virtual COM port. If so using the old dosdevices file won't work. Any suggestions for either of these problems: - debugging a self extracting zip installer - getting a Windows app to use ttyUSB0 instead of whatever Windows USB device it would normally read/write from Thanks for any ideas, Chris

5 5

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible
by Maarten Lankhorst 26 Nov '09

26 Nov '09

Paul Chitescu schreef: > Changelog: > kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever > possible > > In many places reading the Registry is enough to work even when write access > is denied. > Your patches cannot be applied with -Np1, consider using git for sending patches, rather than diffing them :)

2 1

Re: [PATCH] server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.
by Ben Peddell 26 Nov '09

26 Nov '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4 Oct 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which calculated the owner permissions solely based on the grant/deny permissions for the owner's SID. On 17 Oct 2007, in bug #10067, "Daniel" reported a bug about FAT32 support being broken in 0.9.47 (which included the above patch) On 21 Oct 2007, Rob Shearman submitted the patch "server: Fix file_set_sd to handle NULL DACLs.", which added support for setting permissions from NULL ACLs. On 21 Nov 2007, Rob Shearman submitted the patch "server: Add primitive support for setting and getting the security descriptor of files based on their Unix permissions.", which added the world permissions to the owner permissions. On 10 Mar 2009, in bug #17672, Nathan Lineback reported a bug about wine incorrectly setting permissions when installing Oracle DB. On 17 Mar 2009, in bug #17776, Richard Hendrikse reported a bug about FAT32 support being broken. On 5 Aug 2009, in bug #19588, Ken Sharp reported that wine was setting the wrong permissions in some cases. On 10 Nov 2009, in bug #20643, Marshall Davis reported that wine was removing owner permissions when World of Warcraft was giving only the users group permission to access the World of Warcraft directory. On 17 Nov 2009, I posted an initial patch here to take the permissions of the groups the user is a member of when calculating the UNIX mode. Rob Shearman replied: > While I agree that there is a problem that needs to be fixed, I'm not > sure this is the right approach. I think you need to take a step back > and consider the meanings of the different SIDs in a token by default > and how they map wine running inside the Unix permissions model. Later on 17 Nov 2009, I revised the patch to only look at the user's groups if the user was the owner of the file. If permissions should be revoked from a user when (1) they are the owner of the file, (2) they are not a trustee in the file's security descriptor, and (3) they are removed from all groups in the file's security descriptor, then there needs to be some other way of storing the owner of the file and the security descriptor in the filesystem (such as POSIX ACLs), and the owner in the security descriptor cannot be the UNIX owner of the file, as the UNIX owner permissions cannot be overridden by POSIX ACLs. In the meantime, the owner of the file cannot access the file when they are not a trustee in the security descriptor, even if token_access_check says they should be able to access the file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksO/KUACgkQTHDAI68NsunTzwCfVdptQ8sFkFr42r2KOJjvbE2p U7YAoIGowA5ncsgts+p+twCxNDrEedKd =knqg -----END PGP SIGNATURE-----

1 0

Ctrl/Shift don't autorepeat
by Nikolay Sivov 26 Nov '09

26 Nov '09

Hi, guys. I've noticed some problems with keyboard input while testing my favorite Listview control code. The problem is that Ctrl/Shift don't fire WM_KEYDOWNs properly: they don't trigger autorepeat. Is it a known input processing problem? P.S. Alt key is different cause it generates WM_SYSKEYDOWN which isn't supported by control yet.

4 6

My script for doing testing
by Jeremy White 25 Nov '09

25 Nov '09

So I have done my penance for failing to set up a cron to run testing. I've got routine testing going every night on 2 boxes. It seems solid. I see that many others have done this as well - test.winehq.org wine results are really looking good. As promised, I'm attaching the script I'm using. This is my crontab line: 06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git --tag jw-nv-32 e.g. run the script at 2:06 am Tuesdays through Saturdays. I don't want this to be a general call for everyone to run this script; rather, this might be a handy tool for developers who are already running winetest to save them a little hassle. My script probably has only one materially useful feature - it uses a trap to enforce a timeout. The rest is all pretty easy/obvious stuff. Also, I've only tested on Linux, not Mac. Sorry :-(. Cheers, Jeremy #!/bin/bash #---------------------------------------------------- # winetestcron # script to run the Wine tests in an unattended fashion # Intended to be run from cron. If you run it in the # crontab of the user that is logged in to DISPLAY :0, # it should work. Otherwise, you might want to do a # xauth extract /your/file in your .xsession, and an # xauth merge /your/file in this script. #---------------------------------------------------- function usage() { echo -n "$0 --repo /path/to/your/.git/dir " echo "[--tag tag-to-report] " echo -n " [--gecko gecko-path] " echo "[--timeout secs] [--update-repo]" echo " [--configure extra-configure-args]" echo "repo is mandatory, must give the location of a .git directory, and " echo "will not be changed by default. If you specify update-repo, then a " echo "git fetch will be done in your repository before running winetest. " echo "The working tree will not be changed in any case." echo "tag is the tag name to report; see common tags on test.winehq.org for guidance." echo "timeout sets an overall script timeout, in seconds. Default is $TIMEOUT" echo "gecko specifies a path to the Gecko CAB file. Default is $GECKO_LOCATION" echo "configure will pass through the options to ./configure" } function parse_args() { GOPT=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@"` GOPTERR=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@" 2>&1` eval set -- "$GOPT" if [ $? != 0 -o "$GOPT" != "$GOPTERR" ] ; then usage exit 1 fi while true ; do case "$1" in --repo) export REFERENCE_GIT="$2"; shift 2;; --tag) export TAG="$2"; shift 2;; --gecko) export GECKO_LOCATION="$2"; shift 2;; --configure) export CONFIG_EXTRAS="$2"; shift 2;; --update-repo) export UPDATE_REPO="y"; shift;; --) shift; break;; *) echo "Error: uknown option $@"; usage ; exit ;; esac done if [ $# -gt 0 ] ; then echo "Error: Unexpected parameters $@" usage exit 1 fi if [ ! -d "$REFERENCE_GIT" ] ; then echo "Error: --repo must point to the .git directory of a valid WineHQ clone." usage exit 1 fi } function cleanup { "$TESTDIR/wine/server/wineserver" -k find /tmp -maxdepth 1 -type d -name 'winetest*' -ctime +2 -exec rm -rf {} \; exit } #--- # Set defaults #---- export GECKO_LOCATION=/usr/share/wine/gecko/ export TIMEOUT=3600 export TAG=`echo -n \`whoami\`-\`uname -m\` | sed 's/_/-/g'` #--- # Validate arguments #---- parse_args "$@" #--- # Get going... #---- TESTDIR=`mktemp -d /tmp/winetest.XXXXXXXX` TMPGITDIR="$TESTDIR/wine" mkdir "$TESTDIR/gecko" if [ -f "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" ] ; then cp "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" "$TESTDIR/gecko/" else echo $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab not found. Bandwidth being wasted... ( cd "$TESTDIR/gecko" ; \ wget -o "$TESTDIR/wget.log" http://downloads.sourceforge.net/wine/wine_gecko-1.0.0-x86.cab \ ) fi if [ "$UPDATE_REPO" = "y" ] ; then git "--git-dir=$REFERENCE_GIT" fetch origin fi git clone --reference "$REFERENCE_GIT" git://source.winehq.org/git/wine.git "$TMPGITDIR" >"$TESTDIR/clone.log" 2>&1 cd "$TMPGITDIR" (./configure "$CONFIG_EXTRAS" && nice make ) > "$TESTDIR/build.log" 2>&1 export WINEPREFIX="$TESTDIR/.wine" export PATH="$TMPGITDIR:$PATH" export DISPLAY=:0 cd "$TESTDIR" # Set a trap to cleanup when a child exits. We either exit when # the Wine tests are complete, or the timeout happens; whichever # comes first set -m trap cleanup CHLD # Run the actual tests "$TMPGITDIR/wine" "$TMPGITDIR/programs/winetest/winetest.exe.so" -c -t "$TAG" >wine.log 2>&1 & # Set a timer to force an exit after $TIMEOUT sleep $TIMEOUT

6 9

Re: openal32: Add alBufferSubDataEXT
by Chris Robinson 25 Nov '09

25 Nov '09

I'm not sure it's very appropriate to add this yet, since the extension isn't finalized. Until it's finalized, there could be changes that modify the API calls (I don't expect changes, but it's best to err on the side of caution, I think). The alBufferDataStatic patch is fine, though.

1 0

Re: wineserver: Added support for read/only Registry, similar to unprivileged users
by Paul Chitescu 25 Nov '09

25 Nov '09

On Wednesday 25 November 2009 06:36:46 pm Paul Chitescu wrote: > Changelog: > wineserver: Added support for read/only Registry, similar to unprivileged > users > [...] How to test (if it gets accepted): chmod -w $WINEPREFIX/system.reg $WINEPREFIX/userdef.reg What to expect: Major breakage :-( for now err:font:delete_external_font_keys Can't create Windows font reg key err:wineboot:start_services_process Unexpected termination of services.exe - exit code 5 err:font:update_reg_entries Can't create Windows font reg key err:font:delete_external_font_keys Can't create Windows font reg key err:font:update_reg_entries Can't create Windows font reg key err:winspool:WINSPOOL_EnumPrinters Can't create Printers key err:winspool:CUPS_LoadPrinters Can't create Printers key err:winspool:PRINTCAP_ParseEntry Can't create Printers key err:winspool:WINSPOOL_EnumPrinters Can't create Printers key err:menubuilder:init_xdg error looking up the desktop directory err:font:delete_external_font_keys Can't create Windows font reg key err:font:update_reg_entries Can't create Windows font reg key err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:open_mountmgr failed to open mount manager err 2

1 0

Re: Whitespace cleanups
by James Mckenzie 25 Nov '09

25 Nov '09

Nate/Nikolay: Make sure that your patch has no white space errors and stay away from tabs, unless the current file is using them. git -apply should run without any errors. Cleaning up whitespace errors outside of code you are fixing should be very conservative. AJ likes it that way... BTW, I found whitespace errors in the code I'm working on and had to fix them as well. James McKenzie -----Original Message----- >From: Nikolay Sivov <bunglehead(a)gmail.com> >Sent: Nov 25, 2009 7:55 AM >To: Nate Gallaher <ngallaher(a)deepthought.org> >Cc: wine-devel(a)winehq.org >Subject: Re: Whitespace cleanups > >Nate Gallaher wrote: >> I'm looking at working on a new area of wine (for me) and the file I'm >> going to be working >> with is rife with whitespace issues. Literal tabs are sprinkled >> around and the 80-col limit >> has been broken badly and often in easily fixable ways. I'm wondering >> what the acceptable >> approach is to these issues. >> >> I'd like to fix these issues before I start submitting functional >> patches. My question is this: >> Is it acceptable to fix the whole file in one patch (80-cols), >No. >> or should I just fix the >> one function I'm planning on touching? Or should I grit my teeth and >> ignore the style issues >> entirely? >Yes, in most cases. If you plan to rework the whole file with functional >patches feel free to touch >formatting a bit. The common rule is to preserve existing format and >remove things like spaces before >tabs or trailing spaces (the rest is done while committing automatically). > >What file are you talking about? > > >

1 0

Re: Patch Tracker?
by James Mckenzie 25 Nov '09

25 Nov '09

Austin English wrote: >Sent: Nov 24, 2009 2:09 PM >To: Nate Gallaher <ngallaher(a)deepthought.org> >Cc: wine-devel(a)winehq.org >Subject: Re: Patch Tracker? > >On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher ><ngallaher(a)deepthought.org> wrote: >> There's a new patch tracker? > >http://source.winehq.org/patches/ > Congratulations, Austin and Patch tracker team. James McKenzie

3 3

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
by chris ahrendt 25 Nov '09

25 Nov '09

Roderick Colenbrander wrote: > On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Roderick Colenbrander wrote: >>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >>>> Ok going through and looking at the next failure in wine tests I found this one : >>>> >>>> >>>> If you look at the code its: >>>> >>>> >>>> 779 color = getPixelColor(device, 160, 120); >>>> 780 red = (color & 0x00ff0000) >> 16; >>>> 781 green = (color & 0x0000ff00) >> 8; >>>> 782 blue = (color & 0x000000ff); >>>> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >>>> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >>>> >>>> >>>> but in MSDN it says : >>>> >>>> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >>>> >>>> Format of the rgb color is : >>>> >>>> 0x00bbggrr >>>> >>>> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >>>> the third byte contains a value for blue. >>>> >>>> The high-order byte must be zero. >>>> >>>> The maximum value for a single byte is 0xFF. >>>> >>>> so shouldn't it be something like this: >>>> >>>> red = color & 0x000000FF; >>>> green = ( color & 0x0000FF00 ) >> 8; >>>> blue = ( color & 0x00FF0000 ) >> 16; >>>> >>>> not the what is in the test? because of the following C action >>>> >>>> expression1 >> shift_value >>>> >>>> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >>>> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >>>> shift_value. If expression1 is signed, then the result is implementation specific. >>>> >>>> so the test seems to be assigning the wrong values to the RGB.... Correct? >>>> >>>> chris >>>> >>> We are creating the framebuffer in the ARGB format (see init_d3d9). >>> D3D supports a variety of formats and we don't use the gdi RGB macro. >>> >>> Roderick >>> >>> >> Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it >> to come back in the ARGB format??? Is that setup in the init_d3d9? >> >> chris >> > > The test passes properly on Wine + Nivida and I believe even on Intel. > There are just some bugs in the ATI drivers. That's the case with most > of the failing ddraw/d3d tests on ATI and other drivers. > > Roderick > > Oh I realise that... thats why I am trying to figure out where so I can open a bug with ATI... chris

1 0

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
by chris ahrendt 25 Nov '09

25 Nov '09

Roderick Colenbrander wrote: > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Ok going through and looking at the next failure in wine tests I found this one : >> >> >> If you look at the code its: >> >> >> 779 color = getPixelColor(device, 160, 120); >> 780 red = (color & 0x00ff0000) >> 16; >> 781 green = (color & 0x0000ff00) >> 8; >> 782 blue = (color & 0x000000ff); >> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >> >> >> but in MSDN it says : >> >> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >> >> Format of the rgb color is : >> >> 0x00bbggrr >> >> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >> the third byte contains a value for blue. >> >> The high-order byte must be zero. >> >> The maximum value for a single byte is 0xFF. >> >> so shouldn't it be something like this: >> >> red = color & 0x000000FF; >> green = ( color & 0x0000FF00 ) >> 8; >> blue = ( color & 0x00FF0000 ) >> 16; >> >> not the what is in the test? because of the following C action >> >> expression1 >> shift_value >> >> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >> shift_value. If expression1 is signed, then the result is implementation specific. >> >> so the test seems to be assigning the wrong values to the RGB.... Correct? >> >> chris >> > We are creating the framebuffer in the ARGB format (see init_d3d9). > D3D supports a variety of formats and we don't use the gdi RGB macro. > > Roderick > > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it to come back in the ARGB format??? Is that setup in the init_d3d9? chris

2 1

Next release
by Alexandre Julliard 24 Nov '09

24 Nov '09

Folks, I'll be out for the rest of the week, so there won't be a release this Friday. 1.1.34 will be released on December 4. And with the new patch tracker you can watch the patches pile up while I'm away ;-) -- Alexandre Julliard julliard(a)winehq.org

4 3

mapistub: add stubbed dll mapistub.dll
by Louis Lenders 24 Nov '09

24 Nov '09

I guess we can forward those functions to mapi32 later on. While running the app, no functions were called at all, it was even enough to copy a random dll into system32 , and call it mapistub.dll. That was enough to get the app going

1 0

Re: ole32: Fix circular reference count in default handler objects.
by Rob Shearman 24 Nov '09

24 Nov '09

2009/11/24 Rob Shearman <robertshearman(a)gmail.com>: > This is caused by caching a pointer and reference to the data cache's > IPersistStorage interface without managing reference counts > appropriately. > --- > dlls/ole32/defaulthandler.c | 22 ++++++++++++++++++++++ > 1 files changed, 22 insertions(+), 0 deletions(-) > > Fixes memory leaks in defaulthandler tests. May also fix bugs 12419 & 14863. I should also note that the rules for aggregating objects implemented by this patch are listed here: http://msdn.microsoft.com/en-us/library/ms686558(VS.85).aspx -- Rob Shearman

1 0

Re: wineserver: Mark registry hives clean after being loaded initially from file
by Alexandre Julliard 24 Nov '09

24 Nov '09

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -1393,6 +1393,7 @@ > fprintf( stderr, "%s is not a valid registry file\n", filename ); > return; > } > + make_clean( key ); It would be better to create them with the correct flags in the first place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: opengl32: fix wglCreateContextAttribsARB on nvidia
by Dmitry Timoshkov 24 Nov '09

24 Nov '09

"Roderick Colenbrander" <thunderbird2k(a)gmail.com> wrote: > +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code */ > +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x40000000) Using MAKE_HRESULT() with appropriate severity and facility would be cleaner IMO. -- Dmitry.

2 1

RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff
by chris ahrendt 24 Nov '09

24 Nov '09

Ok going through and looking at the next failure in wine tests I found this one : If you look at the code its: 779 color = getPixelColor(device, 160, 120); 780 red = (color & 0x00ff0000) >> 16; 781 green = (color & 0x0000ff00) >> 8; 782 blue = (color & 0x000000ff); 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); but in MSDN it says : This value is a 32-bit value used to specify an RGB color or CLR_INVALID Format of the rgb color is : 0x00bbggrr The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF. so shouldn't it be something like this: red = color & 0x000000FF; green = ( color & 0x0000FF00 ) >> 8; blue = ( color & 0x00FF0000 ) >> 16; not the what is in the test? because of the following C action expression1 >> shift_value Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of shift_value. If expression1 is signed, then the result is implementation specific. so the test seems to be assigning the wrong values to the RGB.... Correct? chris

2 1

Re: mapistub: add stubbed dll mapistub.dll
by Rob Shearman 24 Nov '09

24 Nov '09

2009/11/23 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk>: > This fixes http://bugs.winehq.org/show_bug.cgi?id=20050 > > The dll is present on my XP system This DLL is already partially implemented in a DLL called mapi32, so there should be no need to add this completely stubbed out. -- Rob Shearman

1 0

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.
by Paul Vriens 24 Nov '09

24 Nov '09

On 11/19/2009 01:23 PM, Austin Lund wrote: > - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& > - pFileStructA->uFileTime == pFileStructW->uTime2, > - "Last write time should match last access time!\n"); > - Hi Austin, Is there no other way to get around this? I think it's a bit of a shame having tests removed for that odd system that has a FAT filesystem on a NT4+ box. -- Cheers, Paul.

2 6

Re: [2/3] msi/tests: Test for SELECT table.column FROM table
by Nikolay Sivov 24 Nov '09

24 Nov '09

On Tue, Nov 24, 2009 at 11:14 AM, Nathan Gallaher <ngallaher(a)deepthought.org> wrote: > Make sure that mixing table columns returns the expected > data. eg: SELECT t1.action, t2.action FROM t1, t2 > should return distinct data. > > > + // Test that selection based on prefixing the column with the table + // actually selects the right data Cpp style isn't allowed, please resend it with plain C comments. Thanks.

1 0

Re: RFC : query.c d3d9 test...
by chris ahrendt 24 Nov '09

24 Nov '09

Roderick Colenbrander wrote: > On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> Am 23.11.2009 um 21:00 schrieb chris ahrendt: >>> The test fails with : >>> >>> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 >> This is Windows, right? Which GPU/driver? >> >> My guess is that its ok to modify the test to accept both results. Ie, ok(hr == S_OK | hr == S_FALSE, "..."); >> > > I see it all the time on my Radeon 3400 on Wine. > > Roderick > > this is the wine test I run on linux.... and I get this all the time on my Radeon as well... which is why I was asking here... do I need to open a bug on the test to fix it since what I documented is the correct behavior.... chris

1 0

Re: [PATCH] ole32: Some missing error checking in FileMonikerImpl_CommonPrefixWith (Coverity)
by Rob Shearman 23 Nov '09

23 Nov '09

2009/11/23 Marcus Meissner <marcus(a)jet.franken.de>: > if(mkSys==MKSYS_FILEMONIKER){ > HRESULT ret; > > - CreateBindCtx(0,&pbind); > + ret = CreateBindCtx(0,&pbind); > + if (FAILED(ret)) > + return ret; > > /* create a string based on common part of the two paths */ > > - IMoniker_GetDisplayName(iface,pbind,NULL,&pathThis); > - IMoniker_GetDisplayName(pmkOther,pbind,NULL,&pathOther); > + ret = IMoniker_GetDisplayName(iface,pbind,NULL,&pathThis); > + if (FAILED(ret)) > + return ret; pbind is leaked here. > + ret = IMoniker_GetDisplayName(pmkOther,pbind,NULL,&pathOther); > + if (FAILED(ret)) > + return ret; pbind and pathThis are leaked here. > > nb1=FileMonikerImpl_DecomposePath(pathThis,&stringTable1); > + if (FAILED(nb1)) > + return nb1; Ditto plus pathOther. > nb2=FileMonikerImpl_DecomposePath(pathOther,&stringTable2); > + if (FAILED(nb2)) > + return nb2; Ditto plus stringTable1. > > if (nb1==0 || nb2==0) > return MK_E_NOPREFIX; > > commonPath=HeapAlloc(GetProcessHeap(),0,sizeof(WCHAR)*(min(lstrlenW(pathThis),lstrlenW(pathOther))+1)); > + if (!commonPath) > + return E_OUTOFMEMORY; Ditto plus stringTable2. > > *commonPath=0; -- Rob Shearman

1 0

Re: msvcrt: Calculate floating point decimals in internally used long double precision.
by Austin English 23 Nov '09

23 Nov '09

On Mon, Nov 23, 2009 at 2:43 PM, Gregor Schneider <grschneider(a)gmail.com> wrote: > This patch proposes to calculate the fp digits in scanf with the internally > used long double precision instead of simple float accuracy. > With the current implementation small errors are added with each calculation > step originating from the used float type. > This becomes obvious when parsing to more precise fp types like double or > long double and outputting a large number of digits from the created number. > Example code like the following > > double d; > swscanf(L"3.1415", L"%lf", &d); > wprintf(L"%3.12f\n", d); > > produces an output of "3.141500000478", while "3.141500000000" would be the > expected result with this precision. The attached patch fixes this problem. Please add a testcase for this behavior, to prevent regressions. -- -Austin

1 0

RFC : query.c d3d9 test...
by chris ahrendt 23 Nov '09

23 Nov '09

Looking at the wine test results for the following test: query.c in the d3d9 tests directory... hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData on a ended query returned %08x\n", hr); hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData a 2nd time on a ended query returned %08x\n", hr); the MSDK says the following : IDirect3DQuery9::GetData Polls a queried resource to get the query state or a query result. For more information about queries, see Queries (Direct3D 9). Return Values The return type identifies the query state (see Queries (Direct3D 9)). The method returns S_OK if the query data is available and S_FALSE if it is not. These are considered successful return values. If the method fails when D3DGETDATA_FLUSH is used, the return value can be D3DERR_DEVICELOST. The test fails with : query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 which is a S_FALSE (1) which just means the data is not available... which according to the MSDN site is an ok value to return... and is a success... so not sure what is being tested here? Is this a valid test? Also reading the MSDN the D3DGETDATA_FLUSH is supposed to flush the query so the value its returning may be ok... So If I am understanding the above code the first one should return a S_OK saying that it flushed the query code.... Then the second call should return a S_FALSE because the query has nothing in it..... Thoughts? Explinations??? Inpuut... <G> Chris

3 3

Re: Add .cvsignore entries for .fake files
by Paul Chitescu 23 Nov '09

23 Nov '09

On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > Changelog: > Add .cvsignore entries for .fake files. What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with patch taken from wine-patches bounce. Whoever rejected with "fails to apply" please reply with the output.

4 4

re: winmm: Don't stop parsing after MCI's alias keyword.
by Dan Kegel 23 Nov '09

23 Nov '09

Joerg wrote: > I'm surprised that valgrind did not complain about the bug... Looks like I ignore files that only contain leak errors: http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-spl… on the theory that we're already overwhelmed dealing with non-leak errors. You can still see the leaks in the full log, http://kegel.com/wine/valgrind/logs/2009-11-19-08.35.log What do people think - should we focus on non-leak errors for a while (in which case I should suppress all leak errors), or should I stop ignoring modules that only have leak errors? Also, mci tests hang on my system and need to be killed, so I may be missing some errors because of that. (Finally, my automated runs are on hold while I add use-after-free detection. I'm lame, and use the same source tree for develoment and for the automated runs. One of these days I should separate them. Or somebody else could do the automated runs...) - Dan

2 1

Re: winspool: Don't use 16Bit gdi.exe function for DeviceCapabilitiesA/W
by Alexandre Julliard 23 Nov '09

23 Nov '09

Detlef Riekenberg <wine.dev(a)web.de> writes: > - if (!GDI_CallDeviceCapabilities16) > - { > - GDI_CallDeviceCapabilities16 = (void*)GetProcAddress( GetModuleHandleA("gdi32"), > - (LPCSTR)104 ); > - if (!GDI_CallDeviceCapabilities16) return -1; > - } > - ret = GDI_CallDeviceCapabilities16(pDevice, pPort, cap, pOutput, lpdm); > - > - /* If DC_PAPERSIZE map POINT16s to POINTs */ > - if(ret != -1 && cap == DC_PAPERSIZE && pOutput) { > - POINT16 *tmp = HeapAlloc( GetProcessHeap(), 0, ret * sizeof(POINT16) ); > - POINT *pt = (POINT *)pOutput; You can't remove the 16-bit conversion if you are still calling the existing driver. Probably a better approach is to first add a DrvDeviceCapabilities to the wineps driver. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Only require REG_OPTION_VOLATILE when creating a new key.
by Paul Vriens 23 Nov '09

23 Nov '09

Hi Alexandre, With this patch the following errors are introduced when starting anything on a clean .wine : err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\PARALLEL PORTS" err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\SERIALCOMM" -- Cheers, Paul.

1 0

[RFC] Handle process token groups in server/file.c::sd_to_mode
by Ben Peddell 23 Nov '09

23 Nov '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This proposed patch (which I believe will contribute toward solving bugs 17672, 19588 and 20643, and any others where the permissions are set too restrictive) exposes the token_sid_present call in token.c, and uses it to check the SIDs in the security descriptor against those in the process token. Are there any changes anyone can think of before I submit it to wine-patches? Is there a better (already exposed) way of checking a SID against the process token's group list? - ---- server/file.c | 6 ++++-- server/security.h | 1 + server/token.c | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBcpAACgkQTHDAI68Nsuny6ACfXu3vvWS6O27Z/mfozb4e/ZMG MYQAoItP8P75a3l54TYrLnQbk7lNyaaQ =7QsU -----END PGP SIGNATURE----- server/file.c | 6 ++++-- server/security.h | 1 + server/token.c | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/server/file.c b/server/file.c index a74de14..793c24a 100644 --- a/server/file.c +++ b/server/file.c @@ -485,7 +485,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) if (access & FILE_EXECUTE) denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH; } - else if (security_equal_sid( sid, owner )) + else if (security_equal_sid( sid, owner ) || + token_sid_present( current->process->token, sid, 1 )) { unsigned int access = generic_file_map_access( ad_ace->Mask ); if (access & FILE_READ_DATA) @@ -509,7 +510,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) if (access & FILE_EXECUTE) new_mode |= S_IXUSR|S_IXGRP|S_IXOTH; } - else if (security_equal_sid( sid, owner )) + else if (security_equal_sid( sid, owner ) || + token_sid_present( current->process->token, sid, 0 )) { unsigned int access = generic_file_map_access( aa_ace->Mask ); if (access & FILE_READ_DATA) diff --git a/server/security.h b/server/security.h index 39b1d2f..33cf5da 100644 --- a/server/security.h +++ b/server/security.h @@ -55,6 +55,7 @@ extern int token_check_privileges( struct token *token, int all_required, extern const ACL *token_get_default_dacl( struct token *token ); extern const SID *token_get_user( struct token *token ); extern const SID *token_get_primary_group( struct token *token ); +extern int token_sid_present( struct token *token, const SID *sid, int deny); static inline const ACE_HEADER *ace_next( const ACE_HEADER *ace ) { diff --git a/server/token.c b/server/token.c index ce896ac..461e79d 100644 --- a/server/token.c +++ b/server/token.c @@ -776,7 +776,7 @@ int token_check_privileges( struct token *token, int all_required, return (enabled_count > 0); } -static int token_sid_present( struct token *token, const SID *sid, int deny ) +int token_sid_present( struct token *token, const SID *sid, int deny ) { struct group *group;

3 7

Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.
by Ido Tal 22 Nov '09

22 Nov '09

Hi, I've just now tried to install firefox with winetricks and failed. A short scan reveals what the problem is (I think): the version winetricks is trying to install is 3.5.3. Looking at http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that it's not there anymore. Hope this helps... Ido

3 2

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.
by Charles Davis 22 Nov '09

22 Nov '09

Austin English wrote: > On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Dmitry Timoshkov wrote: >>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>> >>>>> You forgot to remove if (1). >>>>> >>>> It goes away in patch #3. I thought I already had this discussion with >>>> Paul. >>>> >>>> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >>>> but the EMF we're comparing it to only has one. That's because one of >>>> them is if(0)'d out because it crashes on Wine. So, if we try to compare >>>> the EMF we produced to the EMF we expect, it will fail. Last I checked, >>>> Alexandre doesn't like it when tests fail. All tests must pass on his >>>> box. >>> There are 2 solutions for that: >>> 1. use todo_wine in the test, and remove it in a patch with the fix >> The test will fail on Windows if I do that. > > That won't affect windows. It will only fail on wine if it passes. > You don't understand. The expected EMF bits contain TWO BitBlt() records, but the EMF produced by the test contains only one. It will contain only one on both Wine and Windows, because one of the calls to BitBlt() is if(0)'d out. So the test will fail on Windows if the call to compare_emf_bits() is marked todo_wine. Oh, and you didn't reply to all. Was that intentional?

2 1

Someone please update the german translation of Ubuntu download page
by Scott Ritchie 22 Nov '09

22 Nov '09

My German is inadequate and there are no instructions for Karmic users there at the moment. Thanks, Scott Ritchie

2 1

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.
by Dmitry Timoshkov 22 Nov '09

22 Nov '09

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) > + { > + dump_emf_bits(hMetafile, "emf_BitBlt"); > + dump_emf_records(hMetafile, "emf_BitBlt"); > + } You forgot to remove if (1). -- Dmitry.

2 3

Next step: detect double-frees and use-after-free
by Dan Kegel 22 Nov '09

22 Nov '09

Now that the heap tail check is more or less working, I'm on to implementing protection against double frees and use-after-free for recently freed blocks. The idea is that HEAP_MakeInUseBlockFree() will take the block it's called with, push it onto a FIFO, pull an old block off the FIFO, and mark that old block free. The blocks languishing in the FIFO will be marked inaccessible. If you try to free one, realloc one, or even get its size, you'll get an immediate error; if you write to one, you'll get an error when it comes out of the FIFO or when the heap is validated; and if you're running Valgrind, you'll get an immediate error on read or write to the freed block. The FIFO will be drained when the heap is destroyed. It will be implemented using a standard wine list in an optional fixed-sized block at the tail of each allocation. Remind me again why we didn't do this years ago...

1 0

Re: Difficulties with Regression Testing
by James Mckenzie 21 Nov '09

21 Nov '09

>From: Austin English <austinenglish(a)gmail.com> >Sent: Nov 19, 2009 10:31 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >Subject: Re: Difficulties with Regression Testing > >On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> All: >> >> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >> problems: >> >> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >> includes are not included. > >Try doing a make clean / make distclean. > I don't think this will do anything, but I'll try it. >> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >> the tools/subdirectory. > >IIRC, that was a file for the cryptui manager that AJ forgot to >include with the commit needing it. Try either putting it there >manually from another git branch, or using make -k. > Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. James McKenzie

2 2

UMR in CertIsRDNAttrsInCertificateName()
by Dan Kegel 20 Nov '09

20 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_cert.txt shows a new UMR (purify-speak for uninitialized memory read) error Conditional jump or move depends on uninitialised value(s) at strncmp (mc_replace_strmem.c:386) by find_matching_rdn_attr (cert.c:1877) by CertIsRDNAttrsInCertificateName (cert.c:1907) by testIsRDNAttrsInCertificateName (cert.c:2698) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:192) by RtlAllocateHeap (heap.c:1526) by HeapAlloc (heap.c:276) by GlobalAlloc (heap.c:369) by LocalAlloc (heap.c:969) by CRYPT_DecodeEnsureSpace (decode.c:218) by CRYPT_AsnDecodeName (decode.c:1918) by CryptDecodeObjectEx (decode.c:5909) by CertIsRDNAttrsInCertificateName (cert.c:1901) by testIsRDNAttrsInCertificateName (cert.c:2698) Juan, I think that's yours, could you have a look? - Dan

2 1

Re: [PATCH 2/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById
by Jacek Caban 20 Nov '09

20 Nov '09

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/htmldoc3.c | 58 > +++++++++++++++++++++++++++++++++++++++++++--- > dlls/mshtml/nsiface.idl | 33 ++++++++++++++++++++++++++ > dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++- > 3 files changed, 115 insertions(+), 5 deletions(-) [ object, + uuid(29fb2a18-1dd2-11b2-8dd9-a6fd5d5ad12f), + local + /* FROZEN */ +] This interface is not frozen, please change the comment to NOT_FROZEN so that I we will know that we have to check it for changes on the next Gecko update. + hres = IHTMLElement_get_tagName(elem2, &str); + ok(hres == S_OK, "IHTMLElement_get_tagName failed: 0x%08x\n", hres); + ok(!strcmp_wa(str, "A"), "Got wrong tag: %s\n", wine_dbgstr_w(str)); + SysFreeString(str); There is generic test_elem_tag that is meant for this. + /* getElementById with node name attributes */ + hres = IHTMLDocument2_QueryInterface(doc, &IID_IHTMLDocument3, (void**)&doc3); + ok(hres == S_OK, "Unable to get IHTMLDocument3: 0x%08x\n", hres); + if(FAILED(hres)) + return; + bstr = a2bstr("nm1"); + hres = IHTMLDocument3_getElementById(doc3, bstr, &elem); + SysFreeString(bstr); + IHTMLDocument3_Release(doc3); + ok(hres == S_OK, "getElementById failed: 0x%08x\n", hres); + if(FAILED(hres)) + return; Same here for get_doc_elem_by_id. + + hres = IHTMLElement_get_id(elem, &bstr); + ok(hres == S_OK, "IHTMLElement_get_id failed: 0x%08x\n", hres); + ok(!strcmp_wa(bstr, "fr1"), "Found ID should have been \"fr1\", was: %s", wine_dbgstr_w(bstr)); + SysFreeString(bstr); Same here for test_elem_id. Thanks, Jacek

2 1

re: Running server applications under Wine?
by Dan Kegel 20 Nov '09

20 Nov '09

임은지 wrote: > Is there anyone who uses Wine for server applications (game server, web server, etc.)? It's been done. See e.g. http://www.fpsadmin.com/forum/showthread.php?t=16481 for how one fellow ran a game server in wine. > Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. Yes, it would be interesting to run ab or dkftpbench against an http or ftp server running on wine. > What do you think about implementing wineserver kernel module or handling only performance critical items in kernel? There has long been talk of doing that. Linus is even willing to take patches to implement win32 APIs in the linux kernel. But it turns out to not be what most people need. If you want to do some server performance stress testing and file bugs for problems you find, by all means, go ahead! - Dan

2 3

New version of my test for bug 4543
by Charles Davis 20 Nov '09

20 Nov '09

Hi, This is a new version of my test for bug 4543. This time, I followed Dmitry's suggestion of using the existing functions for comparing the contents of EMFs. I can't build tests for Windows both due to bug 20763 and due to the fact that I don't have any Windows boxes, so once again I need people to run this test on Windows to make sure it's an accurate representation of Windows' behavior. The test currently succeeds on Wine. Thanks in advance. Chip >From 574bb4f7b2b90a209b1693b7f8048a2eb271ada8 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to an enhanced metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 125 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 125 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..3bd413b 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -1030,6 +1030,63 @@ static const unsigned char EMF_LINETO_MM_TEXT_BITS[] = { 0x14, 0x00, 0x00, 0x00 }; +static const unsigned char EMF_BITBLT[] = +{ + 0x01, 0x00, 0x00, 0x00, 0x6c, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x94, 0x00, 0x00, 0x00, 0x79, 0x00, 0x00, 0x00, + 0x20, 0x45, 0x4d, 0x46, 0x00, 0x00, 0x01, 0x00, + 0xa0, 0x01, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x04, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, + 0xfc, 0x01, 0x00, 0x00, 0x38, 0x01, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x60, 0xc0, 0x07, 0x00, + 0xc0, 0xc2, 0x04, 0x00, 0x4c, 0x00, 0x00, 0x00, + 0xbc, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x20, 0x00, 0xcc, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x64, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, + 0x8c, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, + 0x28, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, + 0xc4, 0x0e, 0x00, 0x00, 0xc4, 0x0e, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x4c, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x04, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, + 0x62, 0x00, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x3f, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x80, 0x3f, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x0e, 0x00, 0x00, 0x00, + 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x10, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00 +}; + + /* For debugging or dumping the raw metafiles produced by * new test functions. */ @@ -1382,6 +1439,73 @@ static int compare_emf_bits(const HENHMETAFILE mf, const unsigned char *bits, return 0; } + +/* tests blitting to an EMF */ +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; +#define BMP_DIM 4 + BITMAPINFOHEADER bmih = + { + sizeof(BITMAPINFOHEADER), + BMP_DIM,/* biWidth */ + BMP_DIM,/* biHeight */ + 1, /* biPlanes */ + 24, /* biBitCount */ + BI_RGB, /* biCompression */ + 0, /* biXPelsPerMeter */ + 0, /* biYPelsPerMeter */ + 0, /* biClrUsed */ + 0, /* biClrImportant */ + }; + void *bits; + BOOL ret; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + bmih.biXPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSX), 100, 3937); + bmih.biYPelsPerMeter = MulDiv(GetDeviceCaps(hdcDisplay, LOGPIXELSY), 100, 3937); + hBitmap = CreateDIBSection(hdcDisplay, (const BITMAPINFO *)&bmih, + DIB_RGB_COLORS, &bits, NULL, 0); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + hdcMetafile = CreateEnhMetaFileA(hdcBitmap, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + /* First fill the bitmap DC with something recognizable, like BLACKNESS */ + ret = BitBlt(hdcBitmap, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, BLACKNESS); + ok( ret, "BitBlt(BLACKNESS) failed\n" ); + + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt(SRCCOPY) failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, BMP_DIM, BMP_DIM, 0, 0, 0, WHITENESS); + ok( ret, "BitBlt(WHITENESS) failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), + "emf_BitBlt", FALSE) != 0) + { + dump_emf_bits(hMetafile, "emf_BitBlt"); + dump_emf_records(hMetafile, "emf_BitBlt"); + } + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); + DeleteDC(hdcDisplay); +#undef BMP_DIM +} + /* Test a blank metafile. May be used as a template for new tests. */ static void test_mf_Blank(void) @@ -2628,6 +2752,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

3 5

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.
by Paul Vriens 20 Nov '09

20 Nov '09

On 11/20/2009 04:21 PM, Charles Davis wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) Shouldn't you get rid of that '1 ||' ? -- Cheers, Paul.

1 1

what should happen when selecting no audio in winecfg?
by Joerg-Cyril.Hoehle＠t-systems.com 20 Nov '09

20 Nov '09

Hi, I've observed 2 seemingly opposed behaviours when no audio driver is selected in winecfg's audio tab (or when winecfg's audio tab had never been opened before in this .wine prefix): - On one hand, some tests and apps still manage to produce sound. - On the other hand (OTOH), some apps cease to produce sound -- this is a simple method worth trying when some apps hang with sound issues. So I'm left wondering what a) wine's default .wine creation behaviour or b) unselecting all audio drivers in the tab ought to do. Remember that when you first visit winecfg's audio tab, you get to see a note that a default driver was chosen, which lead me to believe that no driver at all is enabled until then. Thanks, Jörg Höhle.

1 0

Running server applications under Wine?
by 임은지 20 Nov '09

20 Nov '09

Is there anyone who uses Wine for server applications (game server, web server, etc.)? Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. What do you think about implementing wineserver kernel module or handling only performance critical items in kernel?

1 0

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory
by Jeff Zaroyko 20 Nov '09

20 Nov '09

On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: > Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 > > -- > -Austin > Does it really fix it, the function still remains unimplemented, crash or no crash... a bug will probably just be filed after it to say the function needs to be implemented if the app really uses it, so what is gained?

2 3

Re: New version of my test for bug 4543
by Charles Davis 20 Nov '09

20 Nov '09

Paul Vriens wrote: > On 11/19/2009 11:17 PM, Charles Davis wrote: >> Hi, >> >> This is a new version of my test for bug 4543. This time, I followed >> Dmitry's suggestion of using the existing functions for comparing the >> contents of EMFs. I can't build tests for Windows both due to bug 20763 >> and due to the fact that I don't have any Windows boxes, so once again I >> need people to run this test on Windows to make sure it's an accurate >> representation of Windows' behavior. The test currently succeeds on Wine. >> >> Thanks in advance. >> >> Chip >> >> >> >> > I'll give it a try on some of my (VMware) boxes tomorrow. > Thanks. I almost forgot: some of the test is if(0)'d out because it crashes on Wine (right now). So, you may wish to un-if(0) the crashing test when you run on Windows. I'm particularly interested in the EMF that the test produces on Windows (it should dump it to the console if you run with WINETEST_DEBUG=1), so that would be really helpful. Chip

1 0

Re: msi regression in today's git -- NEVER MIND
by Susan Cragin 19 Nov '09

19 Nov '09

I had a bad git. Re-did everything and now it works. Sorry about that. Susan -----Original Message----- >Installed Dragon NaturallySpeaking using clean prefix and today's git. >Instal went "without errors" but when I tried to open the program it said that the install hadn't completed correctly. >Specifically, iexplore.exe was missing. >I looked at the terminal output for the run but there wasn't anything interesting. > >Susan >

1 0

Write-past-end in FileMonikerImpl_DecomposePath()
by Dan Kegel 19 Nov '09

19 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-hlink_hlink.txt http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-hlink_hlink.txt shows a new error thanks to the heap tail check. Looks like a level-of-indirection-during-allocation error, 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR)); should be 1039 strgtable = CoTaskMemAlloc(len*sizeof(WCHAR *)); Ulrich, you were in there last, could you have a look? Invalid write of size 4 at FileMonikerImpl_DecomposePath (filemoniker.c:1056) by FileMonikerImpl_Construct (filemoniker.c:1375) by CreateFileMoniker (filemoniker.c:1443) by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) by MkParseDisplayName (moniker.c:1130) by HlinkCreateFromString (hlink_main.c:124) by test_persist (hlink.c:479) by func_hlink (hlink.c:1122) by run_test (test.h:535) by main (test.h:585) Address 0x7f04416c is 4 bytes inside a block of size 6 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by IMalloc_fnAlloc (ifs.c:186) by CoTaskMemAlloc (ifs.c:562) by FileMonikerImpl_DecomposePath (filemoniker.c:1039) by FileMonikerImpl_Construct (filemoniker.c:1375) by CreateFileMoniker (filemoniker.c:1443) by FileMoniker_CreateFromDisplayName (filemoniker.c:1484) by MkParseDisplayName (moniker.c:1130) by HlinkCreateFromString (hlink_main.c:124) by test_persist (hlink.c:479)

1 1

Re: winspool.drv: Acroread 9.2 relies on the buffer sizes returned by GetPrinterA and GetPrinterDriverA being large enough to hold their respective unicode versions' data.
by Detlef Riekenberg 19 Nov '09

19 Nov '09

On Do, 2009-11-19 at 13:18 +0000, Huw Davies wrote: > --- > dlls/winspool.drv/info.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) ANSI functions in winspool.drv have this behavior since w2k. We have already a test for EnumPrintersA/W [required by Outlook2003) I prefer to make such buffer size requirements also the default in Wine. We are able to simplify a lot of ANSI Functions, when we use this way. Alexandre, is this acceptable for you? -- By by ... Detlef

1 0

Problem to download git
by paulo lesgaz 19 Nov '09

19 Nov '09

Hello, when I try to download git, I have the following error. Is it for me only, or does it occur for anyone? I tried to download it several times. I obtain always the same error. dadam@analyst:~$ export http_proxy=”http://proxy.upf.pf:8080″ dadam@analyst:~$ git clone http://source.winehq.org/git/wine.git ~/wine Initialized empty Git repository in /home/dadam/wine/.git/ Getting alternates list for http://source.winehq.org/git/wine.git Getting pack list for http://source.winehq.org/git/wine.git Getting index for pack 0ece042377e5e1fe77ac71b065cf360c0244774e Getting index for pack 72c84da3f0d9b4fd0dad04f1ce7244dadce37a43 Getting index for pack 6c18f6d3a2d8e85a33e7981ead83b64e4c36bc8c Getting index for pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 Getting pack 7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75 which contains 7f5b24ed9186d457acd7803a97d4171f332c5fb2 error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack-7c2ab792c6e1c8f603b… transfer closed with 1152650 bytes remaining to read error: Unable to find 7f5b24ed9186d457acd7803a97d4171f332c5fb2 under http://source.winehq.org/git/wine.git Cannot obtain needed object 7f5b24ed9186d457acd7803a97d4171f332c5fb2 fatal: Fetch failed. D. Adam

3 3

GdiplusAbort type needs to be translated from C++ to C
by Vincent Povirk 19 Nov '09

19 Nov '09

The Windows SDK defines the following type: struct __declspec(novtable) GdiplusAbort { virtual HRESULT __stdcall Abort(void) = 0; }; I think that the following is a workable translation: diff --git a/include/gdiplustypes.h b/include/gdiplustypes.h index 4f97432..444123f 100644 --- a/include/gdiplustypes.h +++ b/include/gdiplustypes.h @@ -55,6 +55,18 @@ typedef BOOL (CALLBACK * ImageAbort)(VOID *); typedef ImageAbort DrawImageAbort; typedef ImageAbort GetThumbnailImageAbort; +struct GdiplusAbort; + +typedef struct gpabort_vtable +{ + HRESULT WINAPI (*Abort)(struct GdiplusAbort*); +} + +typedef struct GdiplusAbort +{ + struct gpabort_vtable *vtable_ptr; +} GdiplusAbort; + #ifdef __cplusplus } #endif I don't think I can provide a proper C++ definition because the abi depends on the compiler. Does this look correct? -- Vincent Povirk

2 2

msi regression in today's git
by Susan Cragin 19 Nov '09

19 Nov '09

Installed Dragon NaturallySpeaking using clean prefix and today's git. Instal went "without errors" but when I tried to open the program it said that the install hadn't completed correctly. Specifically, iexplore.exe was missing. I looked at the terminal output for the run but there wasn't anything interesting. Susan

1 0

UMR in CRYPT_RemoveStringFromMultiString()
by Dan Kegel 19 Nov '09

19 Nov '09

Hi Juan, http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_oid.txt says Invalid read of size 1 at memmove (mc_replace_strmem.c:613) by CRYPT_RemoveStringFromMultiString (oid.c:885) by CryptUnregisterDefaultOIDFunction (oid.c:1010) by test_registerDefaultOIDFunction (oid.c:437) by func_oid (oid.c:601) by run_test (test.h:535) by main (test.h:585) Address 0x7f040ed4 is 0 bytes after a block of size 44 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by CryptMemAlloc (main.c:125) by CRYPT_GetDefaultOIDDlls (oid.c:930) by CryptUnregisterDefaultOIDFunction (oid.c:1009) by test_registerDefaultOIDFunction (oid.c:437) This is near the code changed in crypt32: Don't copy past end of buffer when removing the last string in a multistring. - Dan

1 0

Re: Difficulties with Regression Testing
by James Mckenzie 19 Nov '09

19 Nov '09

Austin English wrote: > >On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >>>From: Austin English <austinenglish(a)gmail.com> >>>Sent: Nov 19, 2009 10:31 AM >>>To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>>Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>>Subject: Re: Difficulties with Regression Testing >>> >>>On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie >>><jjmckenzie51(a)earthlink.net> wrote: >>>> All: >>>> >>>> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >>>> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >>>> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >>>> problems: >>>> >>>> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >>>> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >>>> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >>>> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >>>> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >>>> includes are not included. >>> >>>Try doing a make clean / make distclean. >>> >> I don't think this will do anything, but I'll try it. > >Ah, Makefile.in...nm, misread that. Not sure then. > Thanks for the thought. It is absolutely strange as this just started happening. I correct the Git and it happens after a few more tries at git bisect. Maybe something did change the file between wine-1.1.10 and wine-1.1.11 that git bisect corrupts. I'll be looking at this after the long ride this weekend and over the holiday next weekend. >>>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>>> the tools/subdirectory. >>> >>>IIRC, that was a file for the cryptui manager that AJ forgot to >>>include with the commit needing it. Try either putting it there >>>manually from another git branch, or using make -k. >>> >> Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. > >Put it in dlls/cryptui/, or just use make -k to ignore it. > Thank you. I'll put it there and then try the build again. James McKenzie

1 0

Re: shell32: deal better with spaces in ASSOCSTR_COMMAND values
by Alexandre Julliard 19 Nov '09

19 Nov '09

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -324,7 +324,14 @@ static HRESULT ASSOC_GetExecutable(IQueryAssociationsImpl *This, > else > { > pszStart = pszCommand; > - pszEnd = strchrW(pszStart, ' '); > + for (pszEnd = pszStart; (pszEnd = strchrW(pszEnd, ' ')); pszEnd++) > + { > + WCHAR c = *pszEnd; > + *pszEnd = 0; > + if (SearchPathW(NULL, pszStart, NULL, pathlen, path, NULL)) > + break; > + *pszEnd = c; You have a redundant SearchPath call now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winspool.drv: Acroread 9.2 relies on the buffer sizes returned by GetPrinterA and GetPrinterDriverA being large enough to hold their respective unicode versions' data.
by Alexandre Julliard 19 Nov '09

19 Nov '09

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/winspool.drv/info.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) This doesn't work here: ../../../tools/runtest -q -P wine -M winspool.drv -T ../../.. -p winspool.drv_test.exe.so info.c && touch info.ok info.c:2269: Test failed: needed 38 != filled 21 info.c:2269: Test failed: needed 414 != filled 219 info.c:2269: Test failed: needed 438 != filled 239 info.c:2269: Test failed: needed 446 != filled 245 info.c:2269: Test failed: needed 426 != filled 231 info.c:2269: Test failed: needed 482 != filled 281 make: *** [info.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Difficulties with Regression Testing
by James Mckenzie 19 Nov '09

19 Nov '09

All: I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different problems: 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine includes are not included. 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in the tools/subdirectory. Can anyone confirm/deny that they are experiencing the same problems with a git build? Thank you.

2 1

Wine Icons - final round
by Joel Holdsworth 19 Nov '09

19 Nov '09

Hi All, I wanted to fill you in on the progress on the Tango icon set. You can see it here: http://www.airwebreathe.org.uk/wine-icon/ Please let me know what you think - or if you have any comments. After the last two rounds, I'm hoping that we should basically be at a stage where most people are happy. The main change since last time is that I've replaced the user32 icons with icons that are similar to the Windows 7/Vista standard - but Tango compliant. I was unable to clarify the license for the icon I was using for the ramdisk icon, so I redrew one of my own - a DIMM, which in the end is more suitable than the SOIC chip we had before. The other major change is that I've decided to hold off on cryptui.dll. I'm not happy with the artwork yet, and cryptui.dll needs to be modified so that it uses HICONs rather the HBITMAPs, which don't cope with different colour depths well. When everyone is happy, I really need to freeze the icons from further modifications, because I need to begin the laborious process of making 8 and 4-bit versions. If anyone would like to help with this I'd be happy to have some helpers. But for now let me know if you have any thoughts. Best Regards Joel Holdsworth

3 2

Re: Problem to download git
by James Mckenzie 19 Nov '09

19 Nov '09

> >> error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack- >>7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75.pack > >Is this on a Mac, by any chance? I had similar problems using >MacPorts's git with a proxy server. I also had Linux running in a VM >on that machine, and fetching from the Linux VM always succeeded. The >odd thing is, fetching from Linux also fixed the MacPorts git fetch >for me, at least until the next day's update. > >If this isn't on a Mac, I don't know what to tell you. Mine was. I don't think Dan has a Mac though. It looks like the Git server was being a problem last night. I had to pull a full git as I thought that I had messed mine up. More on this in a separate message. James McKenzie

1 0

Re: Problem to download git
by James Mckenzie 19 Nov '09

19 Nov '09

>On Wed, Nov 18, 2009 at 11:22 PM, Dan Kegel <dank(a)kegel.com> wrote: >> I'm having network errors with git tonight, too. e.g. >> >> $ git pull >> fatal: The remote end hung up unexpectedly >> >> >> > >Hangs up about half the time for me too tonight. > +1. The second pull worked. James McKenzie

1 0

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList
by Paul Vriens 19 Nov '09

19 Nov '09

On 11/13/2009 06:14 PM, Owen Rudge wrote: > --- > dlls/comctl32/tests/imagelist.c | 80 > +++++++++++++++++++++++++++++++++++++++ > 1 files changed, 80 insertions(+), 0 deletions(-) > Hi Owen, These tests introduce 3 failures on all 32bit XP boxes: http://test.winehq.org/data/tests/comctl32:imagelist.html Could you have a look? -- Cheers, Paul.

3 3

Test for Bug 4543: Testers needed
by Charles Davis 19 Nov '09

19 Nov '09

Hi, I have a test that I wrote from scratch for bug 4543. It tests the operation of BitBlt to a metafile, first from the screen then pure whiteness. Unfortunately, I have no Windows boxes to test on, so I need people to run my test on Windows. After all, I need to verify that this test is an accurate representation of Windows' behavior! Also, testing under Wine would be appreciated. As a Mac user, I don't think my system is representative of the vast majority of Wine users (who probably run Linux). I've attached the patch so you can build a gdi32_test.exe that contains my tests. Thanks in advance. Chip >From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..6bf25e4 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,74 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + *pi++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile; + HENHMETAFILE hMetafile; + ENHMETAHEADER emh; + BYTE *bits; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); + ok( ret, "BitBlt error %d\n", GetLastError() ); + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt error %d\n", GetLastError() ); + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); + + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); + + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); + if(!bits) + { + skip( "not enough memory for EMF bits\n" ); + return; + } + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); + for(i = 0; i < emh.nBytes; i++) + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); + + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; -- 1.6.5.2

3 14

Wineconf?
by Damjan Jovanovic 19 Nov '09

19 Nov '09

Hi Can someone please write a bit about Wineconf 2009, for those of us that didn't go? Also is there videos/presentations to see? Thank you Damjan Jovanovic

4 7

switching to redmine?
by Dan Kegel 19 Nov '09

19 Nov '09

http://yokozar.org/blog/archives/171 is a nice writeup (thanks Scott) of wineconf. It all sounds good except for that switching to redmine part... The current wiki and bugzilla are working reasonably well, doesn't seem worth the disruption to switch. I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist thingies. It's really hard to do all those jobs well. Sourceforge was the first, and it was really rough. Google Code is kind of ok, but it doesn't support git yet, and its svn has performance issues (for the moment). Launchpad is also kind of ok, and kind of supports git... Yet Another WBSM Thingy that I've never heard of seems unlikely to be as robust as the above systems. - Dan

3 2

Buffer overrun in LsaLookupNames2() found with valgrind+wine+new heap patch
by Dan Kegel 19 Nov '09

19 Nov '09

Here's the first error it helped Valgrind find in tonight's automated run: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so lsa.c && touch lsa.ok ... Invalid write of size 1 at memmove (mc_replace_strmem.c:613) by RtlCopySid (sec.c:376) by CopySid (security.c:905) by lookup_local_wellknown_name (security.c:2800) by lookup_name (lsa.c:308) by LsaLookupNames2 (lsa.c:411) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Address 0x7f03c550 is 6 bytes after a block of size 26 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by LsaLookupNames2 (lsa.c:402) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Offhand that looks like a real problem. Aric, you may have touched that code last, could you have a look? Oh, and here's a bit that was missing from the patch. - Dan

1 0

re: Problem to download git
by Dan Kegel 19 Nov '09

19 Nov '09

I'm having network errors with git tonight, too. e.g. $ git pull fatal: The remote end hung up unexpectedly

2 1

ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK
by Dan Kegel 19 Nov '09

19 Nov '09

(Without a change like this, Valgrind can't properly detect buffer overruns, but even without Valgrind, this change will improve Wine's ability to detect buffer overruns.) With this change, users can enable buffer overrun detection in Wine by setting WINE_GLOBAL_FLAGS=0x10. This is like the overrun detection in Windows enabled by setting NtGlobalFlags to 0x10, but checks 16 bytes rather than 8, and works for large allocations, not just small ones. With this enabled, a remarkable number of tests break. I'm posting this to wine-devel for review while I add valgrind annotations (which should make it easier to tell whether the errors it detects are real or spurious) and fix the spurious breakages. Note that this change is a no-op under normal circumstances; without setting WINE_GLOBAL_FLAGS, you shouldn't see any breakage.

2 4

Resetting screen resolution on crash
by Erich Hoover 19 Nov '09

19 Nov '09

I was reading the brief summary on WineConf ( http://yokozar.org/blog/archives/171) and saw an interesting item: > We need some help from Freedesktop.org for solving bug 10841. Essentially > we need a standard way of saying “hey reset the resolution when I’m done, > even if I crash.” I was “volunteered” for the task of approaching the > respective projects. I believe this is a case that we can detect on our own, attached is a small standalone example of using fork() in such a way that you could reset the screen resolution even if an application crashed. Erich Hoover ehoover(a)mines.edu

2 1

Re: [PATCH 6/6] msxml3: Implemented xmlnode_get_nodeTypedValue date related data types handling
by Paul Vriens 18 Nov '09

18 Nov '09

On 11/18/2009 12:51 AM, Piotr Caban wrote: > --- > dlls/msxml3/node.c | 67 ++++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/tests/domdoc.c | 72 > ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 139 insertions(+), 0 deletions(-) > > Hi Piotr, These new tests introduce failures on XP and W2K3: http://test.winehq.org/data/tests/msxml3:domdoc.html (These two are the only platforms in as of this writing). Could you have a look? -- Cheers, Paul.

1 0

Re: ole32: Add a test for freeing the parent of an open stream.
by Alexandre Julliard 18 Nov '09

18 Nov '09

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > From 1d583fc07db661bd0f0d0d00ea82c6208c3b744f Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue, 17 Nov 2009 11:20:34 -0600 > Subject: [PATCH 4/7] ole32: Add a test for freeing the parent of an open stream. It doesn't work here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so storage32.c && touch storage32.ok wine: Unhandled page fault on read access to 0x454556d6 at address 0x687dc2dd (thread 0045), starting debugger... Unhandled exception: page fault on read access to 0x454556d6 in 32-bit code (0x687dc2dd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687dc2dd ESP:0032f980 EBP:0032f9b8 EFLAGS:00010216( R- -- I -A-P- ) EAX:45455246 EBX:688587e4 ECX:00110058 EDX:00000100 ESI:45455246 EDI:00000011 Stack dump: 0x0032f980: 00000000 00000100 00000000 00000080 0x0032f990: 0032f9dc 0032f9b0 0032f9b8 7bc45af1 0x0032f9a0: 00000040 00040000 00141c80 7bc346cf 0x0032f9b0: 00141c58 688587e4 0032fa68 687dc339 0x0032f9c0: 45455246 00000002 0032f9dc 00000000 0x0032f9d0: 00000000 0032f9dc 00000000 00000000 Backtrace: =>0 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d(This=0x45455246, index=256, buffer="") [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32 (0x0032f9b8) 1 0x687dc339 StorageImpl_ReadDirEntry+0x39(This=0x45455246, index=2, buffer=0x32fa98) [/home/julliard/wine/wine/dlls/ole32/storage32.c:3127] in ole32 (0x0032fa68) 2 0x687d8268 StgStreamImpl_SetSize+0x98(iface=<register ESI not in topmost frame>, libNewSize=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:614] in ole32 (0x0032fb28) 3 0x687d86ee StgStreamImpl_Write+0x1ce(iface=0x141cd8, pv=0x6867cadc, cb=17, pcbWritten=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:420] in ole32 (0x0032fb78) 4 0x68662ea2 test_parent_free+0x222() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:1322] in ole32_test (0x0032fbc8) 5 0x6866deea func_storage32+0x14ca() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:2470] in ole32_test (0x0032fd98) 6 0x68671b40 run_test+0x130(name="storage32.c") [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:537] in ole32_test (0x0032fdd8) 7 0x68671d2e main+0x11e(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:586] in ole32_test (0x0032fe88) 8 0x686727b4 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0032feb8) 9 0x7b8768a5 start_process+0x55(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1025] in kernel32 (0x0032fee8) 10 0x7bc6de64 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc6e080 call_thread_entry_point+0x70(entry=0x7b876850, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2342] in ntdll (0x0032ffc8) 12 0x7bc4b20a in ntdll (+0x3b20a) (0x0032ffe8) 13 0x68027e4d wine_call_on_stack+0x1d() in libwine.so.1 (0x00000000) 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32: movl 0x490(%eax),%eax 3002 hr = BlockChainStream_ReadAt( -- Alexandre Julliard julliard(a)winehq.org

1 0

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

18 Nov '09

Hi Jörg > > 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. After a bit of mucking around I got sound to work on the Linux host where those VMware Server VMs run, and enabled sound in the VMs where possible. I could not find correct sound drivers for some of the old stuff (NT4 and below), so those still don't have sound, neither do the ESX VMs. Best regards, Ge.

3 2

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)
by Alexandre Julliard 18 Nov '09

18 Nov '09

Austin Lund <austin.lund(a)gmail.com> writes: > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50) && > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL, &filesystemflags, NULL, 0) && > + (filesystemflags & FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } Testing file system flags is not a good idea, that won't work on Wine. It's better to test the results of the actual call. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)
by Paul Vriens 18 Nov '09

18 Nov '09

On 11/18/2009 09:54 AM, Austin Lund wrote: > + TCHAR volumepathname[50]; Please don't use TCHAR's. > + BOOL testacl = FALSE; > + DWORD filesystemflags; > > if (!pGetSecurityInfo) > { > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50)&& > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL,&filesystemflags, NULL, 0)&& > + (filesystemflags& FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } GetVolumePathName is not available before W2K so you should use GetProcAddress here and bail out or skip() if the function is not available. It's also probably better to use the explicit A-versions for both calls. -- Cheers, Paul.

1 0

Re: Test for Bug 4543: Testers needed
by Charles Davis 18 Nov '09

18 Nov '09

Vincent Povirk wrote: > You still have the loop comparing to 0xff, and the test won't pass on > windows with the if(0). Whoops, that must have been an old version of the patch. I fixed the first one, and the second one should be fixed, too. Now the BitBlt(...,WHITENESS) call executes on Windows, but not on Wine. (There should be a function in wine/test.h for doing this.) Patch attached. > > On Tue, Nov 17, 2009 at 6:09 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> All right, this should be the last one. The tests pass on Wine, and >> should pass on Windows if you un-if(0) the call to BitBlt(..., >> WHITENESS). I still don't have any results for the many other Windows >> versions (95, 98, ME, NT4, 2000, Vista, Win7), so I'm going to wait for >> results from these other platforms before I send this to wine-patches. >> >> Chip >> >> >> From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001 >> From: Charles Davis <cdavis(a)mymail.mines.edu> >> Date: Tue, 17 Nov 2009 11:10:50 -0700 >> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >> To: wine-patches <wine-patches(a)winehq.org> >> Reply-To: wine-devel <wine-devel(a)winehq.org> >> >> --- >> dlls/gdi32/tests/metafile.c | 83 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 83 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >> index b559901..19401ed 100644 >> --- a/dlls/gdi32/tests/metafile.c >> +++ b/dlls/gdi32/tests/metafile.c >> @@ -665,6 +665,88 @@ static void test_SaveDC(void) >> DestroyWindow(hwnd); >> } >> >> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >> +{ >> + UINT *pi = (UINT *)data; >> + EMRBITBLT *emrbb; >> + >> + if(emfr->iType != EMR_BITBLT) return 1; >> + emrbb = (EMRBITBLT *)emfr; >> + >> + (*pi)++; >> + if(*pi > 2) return 1; >> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >> + if(*pi == 1) /* First BitBlt */ >> + { >> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >> + } >> + else >> + { >> + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >> + } >> + return 1; >> +} >> + >> +static void test_emf_BitBlt(void) >> +{ >> + HDC hdcDisplay, hdcMetafile, hdcBitmap; >> + HBITMAP hBitmap, hOldBitmap; >> + HENHMETAFILE hMetafile; >> + ENHMETAHEADER emh; >> + BYTE *bits; >> + BOOL ret; >> + UINT i; >> + >> + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); >> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >> + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); >> + >> + hdcBitmap = CreateCompatibleDC(hdcDisplay); >> + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); >> + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); >> + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); >> + hOldBitmap = SelectObject(hdcBitmap, hBitmap); >> + >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); >> + ok( ret, "BitBlt failed\n" ); >> + if(0) /* Crashes on wine */ >> + { >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >> + ok( ret, "BitBlt failed\n" ); >> + } >> + >> + hMetafile = CloseEnhMetaFile(hdcMetafile); >> + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); >> + >> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >> + ok( ret != 0, "GetEnhMetaFileHeader failed\n" ); >> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >> + >> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >> + if(!bits) >> + { >> + skip( "not enough memory for EMF bits\n" ); >> + return; >> + } >> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >> + for(i = 0; i < emh.nBytes; i++) >> + todo_wine ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >> + >> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); >> + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >> + >> + SelectObject(hdcBitmap, hOldBitmap); >> + DeleteObject(hBitmap); >> + DeleteDC(hdcBitmap); >> +} >> + >> static void test_mf_SaveDC(void) >> { >> HDC hdcMetafile; >> @@ -2628,6 +2710,7 @@ START_TEST(metafile) >> /* For enhanced metafiles (enhmfdrv) */ >> test_ExtTextOut(); >> test_SaveDC(); >> + test_emf_BitBlt(); >> >> /* For win-format metafiles (mfdrv) */ >> test_mf_SaveDC(); >> -- >> 1.6.5.2 >> >> >> > > > Chip >From 990018e6e74279c3243d2c3b48472e94d8839c8c Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 67 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 67 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..dbeff43 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,72 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + i = 0; + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; @@ -2628,6 +2694,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

1 0

Re: today's git broke winetricks gecko :-(
by James Mckenzie 18 Nov '09

18 Nov '09

Jacek Caban wrote: >Sent: Nov 17, 2009 7:40 AM >To: Tom Wickline <twickline(a)gmail.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, Vincent Povirk <madewokherd+8cd9(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: today's git broke winetricks gecko :-( > >Tom Wickline wrote: >> >> >> On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie >> <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51@earthlink.net>> wrote: >> >> >> > >> +1 as well. Not all UNIXes have Gecko support packages built for them >> >> >> +1 as well, I haven't tested the changes on OpenSolaris yet, but I >> plan to. :) > >Which makes -0 from both of you as you clearly don't understand the way >Gecko package works. These are .dll files so they are only arch >dependent from Wine point of view. Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands. James McKenzie

5 8

Re: flaky uninit variable in jscript
by Dan Kegel 17 Nov '09

17 Nov '09

There was a second new error in that file that is probably low hanging fruit: Conditional jump or move depends on uninitialised value(s) at invoke_constructor (function.c:243) by Function_value (function.c:521) by invoke_prop_func (dispex.c:259) by jsdisp_call (dispex.c:870) by disp_call (dispex.c:899) by new_expression_eval (engine.c:1568) by expr_eval (engine.c:42) by assign_expression_eval (engine.c:3110) by expr_eval (engine.c:42) by expression_statement_eval (engine.c:679) by stat_eval (engine.c:37) by exec_source (engine.c:473) by exec_global_code (jscript.c:107) by JScriptParse_ParseScriptText (jscript.c:717) by parse_script (run.c:765) by run_from_res (run.c:908) by run_tests (run.c:1057) by func_run (run.c:1095) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at invoke_constructor (function.c:227) Both are still happening as of the last run I have, http://kegel.com/wine/valgrind/logs/2009-11-17-07.31/vg-jscript_run.txt - Dan On Thu, Nov 5, 2009 at 7:25 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Jacek, > could you have a look at this? I think there are some variants that > aren't being > cleanly initialized. > > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/diff-jscript_run.txt > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/vg-jscript_run.txt > > Conditional jump or move depends on uninitialised value(s) > at VARIANT_ValidateType (variant.c:546) > by VariantClear (variant.c:599) > by exec_global_code (jscript.c:111) > by JScriptParse_ParseScriptText (jscript.c:717) > by parse_text (script.c:624) > by parse_inline_script (script.c:679) > by parse_script_elem (script.c:703) > by doc_insert_script (script.c:817) > by nsRunnable_Run (mutation.c:464) > by ??? > by ??? > by add_script_runner (mutation.c:196) > by push_mutation_queue (mutation.c:253) > by nsDocumentObserver_DoneAddingChildren (mutation.c:684) > by ??? > by ??? > by ??? > by ??? > by ??? > by ??? > Uninitialised value was created by a stack allocation > at exec_global_code (jscript.c:94) > > Thanks, > Dan >

1 0

re: Working on avifil32, sudden "non enough memory" error
by Dan Kegel 17 Nov '09

17 Nov '09

Julius wrote: >With one file however (GOODTIME.AVI from the win95 cd) I get this > error after about a second: > err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 > next block has PREV_FREE flag > non enough memory > > I have no idea where this comes from and why it happens. (It appears to > be unrelated to the memcpy call in avifile.c around line 1114.) With > +heap I also get this before the error: > HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. > (the assert fails) Sounds like heap corruption. You might want to cut down the file to the shortest one that causes the crash, then go after it (possibly using valgrind or the like) to look for the error. Does your implementation of avifil32 and friends work properly on windows?

3 3

Re: [PATCH 2/2] [Msvcrt]: in undname functions, no longer use a fixed-size array for storing internal information
by Paul Vriens 17 Nov '09

17 Nov '09

On 11/15/2009 10:07 PM, Eric Pouech wrote: > > (fix for #20681) Hi Eric, This new test fails on all 32bit systems: http://test.winehq.org/data/tests/msvcrt:cpp.html The only box where there are no failures is a 64bit one, but no tests are actually run there ;) Could you have a look? -- Cheers, Paul.

2 1

Re: ddraw/tests: Fix test failure for D3DFMT_A2R10G10B10 pixel format in GetDC tests
by Stefan Dösinger 17 Nov '09

17 Nov '09

Am 17.11.2009 um 12:16 schrieb Austin Lund: >>> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt> >> Where did this test fail? On Wine or Windows? If it was on windows, which windows version and GPU did you use? >> > > WinXP SP2 running in Virtual box 3.0.8 with guest additions installed: > > http://test.winehq.org/data/d51b4e19fb99e30eadd6207d8dba7b0d36363c3d/xp_apl… VirtualBox uses Wine's ddraw/d3d infrastructure. It is likely that you tested the new test against an old Wine prior to when this test and fixes were committed. Your patch contradicts the behavior I saw on a Geforce 7400 Go on Windows Vista, and on a Radeon 9000 Mobility on Windows XP. As such I don't think we should enable GetDC on this format unless we find evidence on a real system that A2R10G10B10 allows GetDC calls. If we find such a system the test should be changed to accept both outcomes(ie, comment out the A2R10G10B10 test)

1 0

new crash in urlmon/misc test?
by Dan Kegel 17 Nov '09

17 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/diff-urlmon_misc.txt http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-urlmon_misc.txt show the new crash Unhandled exception: page fault on read access to 0xf0f0f0f0 in 32-bit code (0x0c530e3b). Register dump: CS:0023 SS:002b DS:002b ES:0000 FS:000b GS:0013 EIP:0c530e3b ESP:7f21fc48 EBP:7f21fc58 EFLAGS:00000084( - -- S - -P- ) EAX:f0f0f0f0 EBX:0ce3cff4 ECX:0cf416a0 EDX:00000409 ESI:7f21fe70 EDI:7bf00de0 Stack dump: 0x7f21fc48: 0cda560d 0cdfd62d 00000000 f0f0f0f0 0x7f21fc58: 7f21fc98 0cde15cd f0f0f0f0 7bf00de0 0x7f21fc68: 0cf0cebd 0cf34f5a 7f03f380 0cf41ff4 0x7f21fc78: 0cda560d 0cddff10 00000000 0cf36569 0x7f21fc88: 0cf3616c 00000409 0ce3cff4 0ce3cff4 0x7f21fc98: 7f21fcd8 0cde1b39 00000409 00000000 Backtrace: =>0 0x0c530e3b strlenW+0x15(str=0xf0f0f0f0) [include/wine/unicode.h:216] in libwine.so.1 1 0x0cde15cd CompareStringW+0xc6(lcid=1033, style=0, str1=0xf0f0f0f0, len1=-1, str2=0xcf365bc, len2=-1) [dlls/kernel32/locale.c:2737] in kernel32 2 0x0cde1b39 lstrcmpW+0x7a(str1=0xf0f0f0f0, str2=0xcf365bc) [dlls/kernel32/locale.c:2892] in kernel32 3 0x0cf0ef56 test_FindMimeFromData+0x119() [dlls/urlmon/tests/misc.c:623] in urlmon_test 4 0x0cf134b6 func_misc+0x44() [dlls/urlmon/tests/misc.c:1349] in urlmon_test - Dan

2 1

new valgrind results...
by Dan Kegel 17 Nov '09

17 Nov '09

Yesterday's valgrind results are at http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/ These were done with updated suppressions; see http://code.google.com/p/winezeug/source/list?path=/trunk/valgrind/valgrind… so don't get too excited about errors going away. (I really should include a histogram of used suppressions so we can know which ones still need fixing.) I now terminate hung tests (or those that just take too long) with SIGALARM, which shows up as "Command terminated by signal 14". For instance, see the bottom of http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-ole32_marshal.txt With luck, my automated script will now need no babying, and results will show up 'promptly' five hours after Alexandre commits. (I used to run tests in parallel to reduce that lag; perhaps I'll try doing that again sometime, carefully.)

1 0

Re: wineserver: Preserve existing UNIX permission bits unless a matching ACCESS_ALLOWED is specified in an ACL, always preserve directory bit
by Paul Vriens 17 Nov '09

17 Nov '09

On 11/17/2009 04:48 PM, Paul Chitescu wrote: > > --- ./file.c.orig 2009-08-19 14:25:58.000000000 +0300 > +++ ./file.c 2009-11-17 17:26:31.000000000 +0200 Patches should be relative to the root. -- Cheers, Paul.

1 0

Re: gdi32/tests: simplify testcase
by Paul Vriens 17 Nov '09

17 Nov '09

On 11/17/2009 05:14 PM, André Hentschel wrote: > + for(i=0;i<sizeof(TestName)/sizeof(TestName[0]);i++) > + { > + lstrcpyA(lf.lfFaceName, TestName[i]); Hi André, Even though it would slightly change the size of the patch, I wouldn't mind some indentation here (and it would be more in line with the style of the file). You should also try to keep with the current style in that file (meaning a space after the semi-colon) with respect to the for() statement. -- Cheers, Paul.

2 1

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
by Paul Vriens 17 Nov '09

17 Nov '09

On 11/14/2009 05:31 PM, Mikey Alexander wrote: > /* Timeout on DdeClientTransaction Call */ > #define MS_TIMEOUT_VAL 1000 > /* # of times to poll for window creation */ > -#define PDDE_POLL_NUM 50 > +#define PDDE_POLL_NUM 150 > /* time to sleep between polls */ > -#define PDDE_POLL_TIME 200 > +#define PDDE_POLL_TIME 300 Hi Mikey, Just raising the timeout was not enough to fix the test failures so something else must be going on? Some of the test results on test.winehq.org now show a general timeout for these tests (there is a hardcoded 120 second timeout for every test module). -- Cheers, Paul.

2 3

Owen Rudge : shell32: Implement SHGetImageList and remove todo_wine from imagelist tests.
by Nikolay Sivov 17 Nov '09

17 Nov '09

Hi, Owen. There's a mistake here. + hNew = ImageList_Duplicate(iImageList == SHIL_LARGE ? hLarge : hSmall); + + /* Get the interface for the new image list */ + if (hNew) + { + ret = HIMAGELIST_QueryInterface(hNew, riid, ppv); + + if (!SUCCEEDED(ret)) + ImageList_Destroy(hNew); + } After duplication hNew already has refcount == 1, after HIMAGELIST_QueryInterface is goes to 2, and it isn't what you want. To hide checking riid just remove condition before ImageList_Destroy.

1 0

Re: today's git broke winetricks gecko :-(
by Ben Klein 17 Nov '09

17 Nov '09

2009/11/17 Juan Lang <juan.lang(a)gmail.com>: >> If a previously-optional component is now deemed to be mandatory, and >> that component *on its own* happens to double the download size >> required to install Wine, I consider that a problem. Not everyone has >> a cable or ADSL2+ connection. > > Yes, but it's not updated as frequently. What guarantee is there of this in the future? In fact, if you can guarantee that there will never be another update to Gecko, then the argument on the size of Gecko disappears. > The development version of Wine is updated roughly every > two weeks, so if a user is willing to download a development version > approximately that often, why should a single, equally sized download > be an impediment? Gecko is not a core part of Wine. It is only needed for an MSHTML implementation. There are plenty of apps in existence that do not and will not have any use for Gecko. I argue that the size of Gecko is a good reason to not require it to be installed for those users who *know* they don't need it. >>>wine cmd /c echo yes now downloads gecko. >> How can you possibly justify this? > > Is this to me? I didn't say that. No, you didn't. But how can you support a scheme where running "wine cmd /c echo yes" prompts for Gecko download? 2009/11/17 Marcus Meissner <marcus(a)jet.franken.de>: > On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote: >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. > > I btw thought of actually building wine-gecko using mingw instead of > just distributing the .cab. > > Just did not have the time to try it in the .spec file. > > This is also the 1 problem I see with distro inclusion here, so far > I just have it in my openSUSE buildservice repos. If Gecko is to be included as a requirement in the current fassion, I argue that it should be made packageable/installable from wine-git. I support Vincent's suggestion of "--disable-gecko-downloader", and would also like to see "--enable-gecko"/"--disable-gecko" to build the .cab file (on "make") and install it to the correct location (on "make install"). Or perhaps, a "make gecko"/"make install-gecko" pair (which would be more convenient for me as a package maintainer).

5 4

Re: today's git broke winetricks gecko :-(
by James Mckenzie 17 Nov '09

17 Nov '09

Nate Gallaher wrote: >Vincent Povirk wrote: >> It also seems to me that a --disable-gecko-downloader configure switch >> that would disable the dialog COMPLETELY (even "when needed") would >> put gecko on equal footing with optional library requirements. It >> would mean: >> * You can warn about the perils of not having gecko at configure time. >> * If gecko is installed properly, it's used properly, installed at >> prefix creation time. >> * If gecko is not installed properly, programs that need it will >> simply fail, and you'll see an ERR in the console, as well as a nice >> "HTML rendering is disabled" message you wouldn't get from other >> components. >> >> > > >I would just like to second Vincent's suggestion. > +1 as well. Not all UNIXes have Gecko support packages built for them James McKenzie >

3 2

Re: WGL: add initial WGL_ARB_create_context support
by Alexandre Julliard 17 Nov '09

17 Nov '09

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > This patch adds an initial implementation of WGL_ARB_create_context > which is required for OpenGL 3.x support. I have tried some basic GL3 > samples which work and the initial Wine tests. It doesn't work here: ../../../tools/runtest -q -P wine -M opengl32.dll -T ../../.. -p opengl32_test.exe.so opengl.c && touch opengl.ok opengl.c:562: Test failed: wglCreateContextAttribs with major version=0 should fail! X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 34 () Value in failed request: 0x0 Serial number of failed request: 370 Current serial number in output stream: 373 make: *** [opengl.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById
by Alexandre Julliard 17 Nov '09

17 Nov '09

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/mshtml/htmldoc3.c | 26 ++++++++++++++++++++++---- > dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++++++++- > 2 files changed, 50 insertions(+), 5 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c && touch dom.ok dom.c:5401: Test failed: Got wrong tag: L"OPTION" make: *** [dom.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw/tests: Fix test failure for D3DFMT_A2R10G10B10 pixel format in GetDC tests
by Stefan Dösinger 17 Nov '09

17 Nov '09

Am 17.11.2009 um 10:38 schrieb Austin Lund: > > <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt> Where did this test fail? On Wine or Windows? If it was on windows, which windows version and GPU did you use?

1 0

Re: [PATCH] jscript: Implement decodeURIComponent
by Jacek Caban 16 Nov '09

16 Nov '09

Hi Andrew, Andrew Eikum wrote: > --- > dlls/jscript/global.c | 104 > ++++++++++++++++++++++++++++++++++++++++++++- > dlls/jscript/tests/api.js | 20 +++++++++ > 2 files changed, 122 insertions(+), 2 deletions(-) > + while(*ptr == '%') { + if(hex_to_int(*(ptr+1)) < 0 || hex_to_int(*(ptr+2)) < 0) { + WARN("Invalid hex sequence: 0x%x 0x%x\n", *(ptr+1), *(ptr+2)); + SysFreeString(str); + return E_FAIL; URIError should be thrown here. If it's not, then you should put FIXME here. Same for other places where you return E_FAIL. + } + ptr += 3; + ++buf_len; + } + octets = heap_alloc(buf_len); You don't check allocation failure and leak octets here. You may avoid dynamic allocation at all by processing one utf8 char at the time. Then you know that it's not longer than 4 bytes. Ecma specification describes it well, although you may simplify the algorithm by checking number of bytes from the first byte, fetching bytes to the array and then use MultiByteToWideChar for conversion to UTF-16 and validation. Thanks, Jacek

2 1

Re: WineD3D: fix bug 20522
by Alexandre Julliard 16 Nov '09

16 Nov '09

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > This patch fixes bug 20522 which was uncovered by 32-bit dibsection > support. I have added a test to show that the patch is correct. Like > with Blt the results varry depending on the drivers. It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok visual.c:2349: Test failed: got R 80 G 00 B 00, expected R 00 G FF B 00 make: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32/listview: use the infile ImageListRelease
by Nikolay Sivov 16 Nov '09

16 Nov '09

Hi, Andre. Could you please wait with that? I have some similar patches already sent... On 11/16/09, André Hentschel <nerv(a)dawncrow.de> wrote: > Otherwise Apps crash on exit(e.g. uninstaller) > --- > dlls/comctl32/imagelist.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/comctl32/imagelist.c b/dlls/comctl32/imagelist.c > index 82d2664..44084fd 100644 > --- a/dlls/comctl32/imagelist.c > +++ b/dlls/comctl32/imagelist.c > @@ -81,6 +81,7 @@ static INTERNALDRAG InternalDrag = { 0, 0, 0, 0, 0, 0, > FALSE, 0 }; > > static HBITMAP ImageList_CreateImage(HDC hdc, HIMAGELIST himl, UINT count, > UINT width); > static HRESULT ImageListImpl_CreateInstance(const IUnknown *pUnkOuter, > REFIID iid, void** ppv); > +static ULONG WINAPI ImageListImpl_Release(IImageList *iface); > > static inline BOOL is_valid(HIMAGELIST himl) > { > @@ -716,7 +717,7 @@ ImageList_Destroy (HIMAGELIST himl) > DeleteObject (himl->hbrBlend50); > > /* Free the IImageList instance */ > - IImageList_Release((IImageList *) himl); > + ImageListImpl_Release((IImageList *) himl); > return TRUE; > } > > -- > > Best Regards, André Hentschel > > >

2 1

Re: [PATCH 2/2] dsound: Simplify duplex code
by Alexandre Julliard 16 Nov '09

16 Nov '09

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -48,37 +50,20 @@ typedef struct IDirectSoundFullDuplexImpl > > /* IDirectSoundFullDuplexImpl fields */ > DirectSoundDevice *renderer_device; > - DirectSoundCaptureDevice *capture_device; > - > - LPUNKNOWN pUnknown; > - LPDIRECTSOUND pDS; > - LPDIRECTSOUND8 pDS8; > - LPDIRECTSOUNDCAPTURE pDSC; > + IDirectSoundCapture *capture_device; > + > + const IUnknownVtbl *lpUnkVtbl; > + const IDirectSoundVtbl *lpDSVtbl; > + const IDirectSound8Vtbl *lpDS8Vtbl; > + const IDirectSoundCaptureVtbl *lpDSCVtbl; > + LONG unk_ref; > + LONG ds_ref; > + LONG ds8_ref; > + LONG dsc_ref; > } IDirectSoundFullDuplexImpl; > > -typedef struct IDirectSoundFullDuplex_IUnknown { > - const IUnknownVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IUnknown; > - > -typedef struct IDirectSoundFullDuplex_IDirectSound { > - const IDirectSoundVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSound; > - > -typedef struct IDirectSoundFullDuplex_IDirectSound8 { > - const IDirectSound8Vtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSound8; > - > -typedef struct IDirectSoundFullDuplex_IDirectSoundCapture { > - const IDirectSoundCaptureVtbl *lpVtbl; > - LONG ref; > - IDirectSoundFullDuplexImpl *pdsfd; > -} IDirectSoundFullDuplex_IDirectSoundCapture; > +#define ICOM_THIS_MULTI(impl,field,iface) \ > + impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) Please define inline functions instead of ICOM_THIS_MULTI. Also the IUnknown vtable is most likely unnecessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] user32: Free window text to prevent leak in case whenWM_NCDESTROY doesn't get to default procedure
by Dmitry Timoshkov 16 Nov '09

16 Nov '09

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > This fixes a leak spotted by valgrind. > > Changelog: > - free window text to prevent leak in case when WM_NCDESTROY > doesn't get to default procedure Then WM_NCDESTROY handler should be removed from DefWindowProc to avoid a confusing duplication. -- Dmitry.

2 1

Re: [PATCH] winex11.drv: check for org = NULL (Coverity)
by Roderick Colenbrander 16 Nov '09

16 Nov '09

Hi Marcus, A couple of hours ago I submitted a patch rewrites the function. It suffers from the same 'issue'. This and any other wgl function are called from gdi32/opengl.c which perform magic to arrive here and in case of wglsharelists it also performs the filtering. Roderick On Sun, Nov 15, 2009 at 7:28 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > Coverity spotted some inconsistencies in "org" NULL > checking. > > org originates via Windows code (I think) so we better check it. > > Ciao, Marcus > --- > dlls/winex11.drv/opengl.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index 45da479..774b205 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -1918,11 +1918,15 @@ BOOL CDECL X11DRV_wglShareLists(HGLRC hglrc1, HGLRC hglrc2) { > > if (!has_opengl()) return FALSE; > > + if (NULL == org) { > + ERR("Could not share display lists, original context required.\n"); > + return FALSE; > + } > if (NULL != dest && dest->ctx != NULL) { > - ERR("Could not share display lists, context already created !\n"); > + ERR("Could not share display lists, context already created!\n"); > return FALSE; > } else { > - if(org && dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > + if(dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^ (GetObjectType(dest->hdc) == OBJ_MEMDC)) { > WARN("Attempting to share a context between a direct and indirect rendering context, expect issues!\n"); > } > > -- > 1.5.6 > > >

2 2

re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.
by Dan Kegel 16 Nov '09

16 Nov '09

Hi Ben, did you see http://bugs.winehq.org/show_bug.cgi?id=15679 http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html ? IMHO the way the Samba sources merged the fd and filename version of the calls makes for less duplication of code. (I tried to do it the other way first, and it seemed ugly.) - Dan

2 1

Re: user32: Destroy EDITSTATE structure in the WM_NCDESTROY messageprocessing
by Dmitry Timoshkov 16 Nov '09

16 Nov '09

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > + SendMessageA(hWnd, WM_SETTEXT, 0, (LPARAM)str); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, str), "Wrong contents of edit: %s\n", buf); > + lstrcpy(buf, ""); > + SendMessageA(hWnd, WM_DESTROY, 0, 0); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, str), "Wrong contents of edit: %s\n", buf); > + lstrcpy(buf, ""); > + SendMessageA(hWnd, WM_NCDESTROY, 0, 0); > + SendMessageA(hWnd, WM_GETTEXT, MAXLEN, (LPARAM)buf); > + ok(!lstrcmp(buf, ""), "Wrong contents of edit: %s\n", buf); You should check return values of each SendMessage above. -- Dmitry.

1 0

[Fwd: Interesting Problem Building Wine for Regression Test]
by James McKenzie 16 Nov '09

16 Nov '09

All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? Just as a followup, I rebased my local git and received error messages relating to tools/Makefile.in. Forced a regit in the branch I had been working in and the builds are working again. Funny thing is that I did nothing to this file. James McKenzie

1 0

winscard: add pcsc-lite helpers for upcoming(?) implementation
by Joerg-Cyril.Hoehle＠t-systems.com 16 Nov '09

16 Nov '09

Hi, looking for PCSC-card-reader support in Wine, I came across old mails from 2007. http://www.winehq.org/pipermail/wine-devel/2007-May/057052.html What's the current state of PCSC support in Wine? When I recently looked, winscard seemed full of stubs. OTOH, there's a company http://www.starmoney.de/index.php?id=243 that seems to use Wine (and Darwine?) with card readers to make its software available for Linux & Mac. Also seems ~2007. I believe that a winscard<->PCSC<->PCSC-Lite bridge would be much easier to achieve than USB support in Wine. Thanks for your help, Jörg Höhle

4 3

Interesting Problem Building Wine for Regression Test
by James McKenzie 16 Nov '09

16 Nov '09

All: I continue to work with Tony Rollo's code as presented in bug 6254. I've found a problem with Wordpad's Print Preview between wine-1.1.10 and wine-1.1.11 and I attempted to run a regression test and end up with errors in makedep.c as follows: makedep.c:21:20: error: config.h: No such file or directory makedep.c:23:23: error: wine/port.h: No such file or directory makedep.c:35:23: error: wine/list.h: No such file or directory makedep.c:42: error: field ‘entry’ has incomplete type makedep.c:53: error: variable ‘sources’ has initializer but incomplete type makedep.c:53: error: ‘sources’ has an incomplete type makedep.c:54: error: variable ‘includes’ has initializer but incomplete type the list of errors continues but they are all related to the first three lines. These files exist in the include directory. What makes troubleshooting these errors difficult is that wine-1.1.10 AND wine-1.1.11 from the same git repository will build without these errors. What I did was: git bisect start git bisect good wine-1.1.10 git bisect bad wine-1.1.11 and I received the bisect message that there were 240 more changes to check. I do have an idea what commit caused the problem and attempted to manually backout the change, but the build also failed. I diffed the configure line and found no major differences between the configure on the build that finishes and the one that errors. Any idea on what I am doing incorrect? James McKenzie

1 0

[RFC] Extended Attributes for Dos Attributes, Creation Time, etc.
by Ben Peddell 16 Nov '09

16 Nov '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What are your thoughts on using Extended Attributes for items such as: * Dos Attributes (like samba's "store dos attributes = yes") * File Creation Times (like samba's proposed user.crtime) * An option for alternate storage of NT ACLs (like samba's "vfs object = acl-xattr") Are Extended Attributes acceptable? Or should they never touch the wine source? Where would the portability functions for Extended Attributes on Linux, Mac OS X, FreeBSD and Solaris belong? I would think in libport. Attached is a patch to add extended attribute portability functions for fgetxattr, fsetxattr and fremovexattr to libport. Please give me any comments on this patch, and the idea of using extended attributes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksAm/4ACgkQTHDAI68NsumFzwCbBDcRbB8kFXroLeskA+hzgswu i0UAn3NHbau8AjSgtoruggBH3py+orcZ =tEvP -----END PGP SIGNATURE----- >From 2ef84c7f8c849db18ce15366e72c6787fa83597d Mon Sep 17 00:00:00 2001 From: Benjamin Peddell <klightspeed(a)netspace.net.au> Date: Mon, 16 Nov 2009 01:23:28 +1000 Subject: [PATCH] Add Extended Attribute support to libport --- configure | 178 ++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 45 ++++++++++++ include/config.h.in | 39 ++++++++++ include/wine/port.h | 36 +++++++++ libs/port/Makefile.in | 3 + libs/port/fgetxattr.c | 96 +++++++++++++++++++++++++ libs/port/fremovexattr.c | 75 +++++++++++++++++++ libs/port/fsetxattr.c | 102 ++++++++++++++++++++++++++ 8 files changed, 574 insertions(+), 0 deletions(-) create mode 100644 libs/port/fgetxattr.c create mode 100644 libs/port/fremovexattr.c create mode 100644 libs/port/fsetxattr.c diff --git a/configure b/configure index 15652b4..c9322b3 100755 --- a/configure +++ b/configure @@ -5747,6 +5747,7 @@ for ac_header in \ sys/errno.h \ sys/event.h \ sys/exec_elf.h \ + sys/extattr.h \ sys/filio.h \ sys/inotify.h \ sys/ioctl.h \ @@ -5782,6 +5783,7 @@ for ac_header in \ sys/utsname.h \ sys/vm86.h \ sys/wait.h \ + sys/xattr.h \ syscall.h \ termios.h \ unistd.h \ @@ -12084,6 +12086,9 @@ for ac_func in \ chsize \ dlopen \ epoll_create \ + extattr_delete_fd \ + extattr_get_fd \ + extattr_set_fd \ ffs \ finite \ fnmatch \ @@ -12105,6 +12110,7 @@ for ac_func in \ lstat \ memmove \ mmap \ + openat \ pclose \ pipe2 \ poll \ @@ -12137,6 +12143,7 @@ for ac_func in \ tcgetattr \ thr_kill2 \ timegm \ + unlinkat \ usleep \ vsnprintf \ wait4 \ @@ -12262,6 +12269,81 @@ fi fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing fgetxattr" >&5 +$as_echo_n "checking for library containing fgetxattr... " >&6; } +if test "${ac_cv_search_fgetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + ac_func_search_save_LIBS=$LIBS +cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ + +/* Override any GCC internal prototype to avoid an error. + Use char because int might match the return type of a GCC + builtin and then its argument prototype would still apply. */ +#ifdef __cplusplus +extern "C" +#endif +char fgetxattr (); +int +main () +{ +return fgetxattr (); + ; + return 0; +} +_ACEOF +for ac_lib in '' attr; do + if test -z "$ac_lib"; then + ac_res="none required" + else + ac_res=-l$ac_lib + LIBS="-l$ac_lib $ac_func_search_save_LIBS" + fi + if ac_fn_c_try_link "$LINENO"; then : + ac_cv_search_fgetxattr=$ac_res +fi +rm -f core conftest.err conftest.$ac_objext \ + conftest$ac_exeext + if test "${ac_cv_search_fgetxattr+set}" = set; then : + break +fi +done +if test "${ac_cv_search_fgetxattr+set}" = set; then : + +else + ac_cv_search_fgetxattr=no +fi +rm conftest.$ac_ext +LIBS=$ac_func_search_save_LIBS +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_fgetxattr" >&5 +$as_echo "$ac_cv_search_fgetxattr" >&6; } +ac_res=$ac_cv_search_fgetxattr +if test "$ac_res" != no; then : + test "$ac_res" = "none required" || LIBS="$ac_res $LIBS" + +fi + + +for ac_func in \ + fgetxattr \ + fremovexattr \ + fsetxattr \ + +do : + as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh` +ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var" +eval as_val=\$$as_ac_var + if test "x$as_val" = x""yes; then : + cat >>confdefs.h <<_ACEOF +#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1 +_ACEOF + +fi +done + + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing gethostbyname" >&5 $as_echo_n "checking for library containing gethostbyname... " >&6; } if test "${ac_cv_search_gethostbyname+set}" = set; then : @@ -12616,6 +12698,102 @@ $as_echo "#define HAVE_ONE_ARG_MKDIR 1" >>confdefs.h fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fgetxattr takes six arguments" >&5 +$as_echo_n "checking whether fgetxattr takes six arguments... " >&6; } +if test "${wine_cv_six_arg_fgetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fgetxattr(0, "foo", "foo", 3, 0, 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_six_arg_fgetxattr=yes +else + wine_cv_six_arg_fgetxattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_six_arg_fgetxattr" >&5 +$as_echo "$wine_cv_six_arg_fgetxattr" >&6; } +if test "$wine_cv_six_arg_fgetxattr" = "yes" +then + +$as_echo "#define HAVE_SIX_ARG_FGETXATTR 1" >>confdefs.h + +fi + +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fsetxattr takes six arguments" >&5 +$as_echo_n "checking whether fsetxattr takes six arguments... " >&6; } +if test "${wine_cv_six_arg_fsetxattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fsetxattr(0, "foo", "foo", 3, 0, 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_six_arg_fsetxattr=yes +else + wine_cv_six_arg_fsetxattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_six_arg_fsetxattr" >&5 +$as_echo "$wine_cv_six_arg_fsetxattr" >&6; } +if test "$wine_cv_six_arg_fsetxattr" = "yes" +then + +$as_echo "#define HAVE_SIX_ARG_FSETXATTR 1" >>confdefs.h + +fi + +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether fremovexattr takes three arguments" >&5 +$as_echo_n "checking whether fremovexattr takes three arguments... " >&6; } +if test "${wine_cv_three_arg_fremovexattr+set}" = set; then : + $as_echo_n "(cached) " >&6 +else + cat confdefs.h - <<_ACEOF >conftest.$ac_ext +/* end confdefs.h. */ +#include <sys/xattr.h> +int +main () +{ +fremovexattr("foo", "foo", 0); + ; + return 0; +} +_ACEOF +if ac_fn_c_try_compile "$LINENO"; then : + wine_cv_three_arg_fremovexattr=yes +else + wine_cv_three_arg_fremovexattr=no +fi +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $wine_cv_three_arg_fremovexattr" >&5 +$as_echo "$wine_cv_three_arg_fremovexattr" >&6; } +if test "$wine_cv_three_arg_fremovexattr" = "yes" +then + +$as_echo "#define HAVE_THREE_ARG_FREMOVEXATTR 1" >>confdefs.h + +fi + { $as_echo "$as_me:${as_lineno-$LINENO}: checking for an ANSI C-conforming const" >&5 $as_echo_n "checking for an ANSI C-conforming const... " >&6; } diff --git a/configure.ac b/configure.ac index a5f1b8a..c0f5380 100644 --- a/configure.ac +++ b/configure.ac @@ -384,6 +384,7 @@ AC_CHECK_HEADERS(\ sys/errno.h \ sys/event.h \ sys/exec_elf.h \ + sys/extattr.h \ sys/filio.h \ sys/inotify.h \ sys/ioctl.h \ @@ -419,6 +420,7 @@ AC_CHECK_HEADERS(\ sys/utsname.h \ sys/vm86.h \ sys/wait.h \ + sys/xattr.h \ syscall.h \ termios.h \ unistd.h \ @@ -1684,6 +1686,9 @@ AC_CHECK_FUNCS(\ chsize \ dlopen \ epoll_create \ + extattr_delete_fd \ + extattr_get_fd \ + extattr_set_fd \ ffs \ finite \ fnmatch \ @@ -1705,6 +1710,7 @@ AC_CHECK_FUNCS(\ lstat \ memmove \ mmap \ + openat \ pclose \ pipe2 \ poll \ @@ -1737,6 +1743,7 @@ AC_CHECK_FUNCS(\ tcgetattr \ thr_kill2 \ timegm \ + unlinkat \ usleep \ vsnprintf \ wait4 \ @@ -1757,6 +1764,16 @@ then AC_CHECK_LIB(poll,poll,[AC_DEFINE(HAVE_POLL,1) AC_SUBST(LIBPOLL,"-lpoll")]) fi +dnl Check for -lattr for the old attr package +AC_SEARCH_LIBS(fgetxattr,attr) + +dnl Check for xattr functions which may rely on -lattr on Linux +AC_CHECK_FUNCS(\ + fgetxattr \ + fremovexattr \ + fsetxattr \ +) + dnl Check for -lnsl for Solaris AC_SEARCH_LIBS(gethostbyname, nsl) @@ -1816,6 +1833,34 @@ then AC_DEFINE(HAVE_ONE_ARG_MKDIR, 1, [Define if mkdir takes only one argument]) fi +dnl Check xattr functions +AC_CACHE_CHECK([whether fgetxattr takes six arguments], + wine_cv_six_arg_fgetxattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fgetxattr(0, "foo", "foo", 3, 0, 0);]])], + [wine_cv_six_arg_fgetxattr=yes],[wine_cv_six_arg_fgetxattr=no])) +if test "$wine_cv_six_arg_fgetxattr" = "yes" +then + AC_DEFINE(HAVE_SIX_ARG_FGETXATTR, 1, [Define if fgetxattr takes six arguments, as in Mac OS X]) +fi + +AC_CACHE_CHECK([whether fsetxattr takes six arguments], + wine_cv_six_arg_fsetxattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fsetxattr(0, "foo", "foo", 3, 0, 0);]])], + [wine_cv_six_arg_fsetxattr=yes],[wine_cv_six_arg_fsetxattr=no])) +if test "$wine_cv_six_arg_fsetxattr" = "yes" +then + AC_DEFINE(HAVE_SIX_ARG_FSETXATTR, 1, [Define if fsetxattr takes six arguments, as in Mac OS X]) +fi + +AC_CACHE_CHECK([whether fremovexattr takes three arguments], + wine_cv_three_arg_fremovexattr, + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <sys/xattr.h>]],[[fremovexattr("foo", "foo", 0);]])], + [wine_cv_three_arg_fremovexattr=yes],[wine_cv_three_arg_fremovexattr=no])) +if test "$wine_cv_three_arg_fremovexattr" = "yes" +then + AC_DEFINE(HAVE_THREE_ARG_FREMOVEXATTR, 1, [Define if fremovexattr takes three arguments, as in Mac OS X]) +fi + dnl **** Check for types **** AC_C_CONST diff --git a/include/config.h.in b/include/config.h.in index 16b2e90..1c6ec57 100644 --- a/include/config.h.in +++ b/include/config.h.in @@ -93,9 +93,21 @@ /* Define if you have EsounD sound server */ #undef HAVE_ESD +/* Define to 1 if you have the `extattr_delete_fd' function. */ +#undef HAVE_EXTATTR_DELETE_FD + +/* Define to 1 if you have the `extattr_get_fd' function. */ +#undef HAVE_EXTATTR_GET_FD + +/* Define to 1 if you have the `extattr_set_fd' function. */ +#undef HAVE_EXTATTR_SET_FD + /* Define to 1 if you have the `ffs' function. */ #undef HAVE_FFS +/* Define to 1 if you have the `fgetxattr' function. */ +#undef HAVE_FGETXATTR + /* Define to 1 if you have the `finite' function. */ #undef HAVE_FINITE @@ -156,9 +168,15 @@ /* Define to 1 if you have the <freetype/tttables.h> header file. */ #undef HAVE_FREETYPE_TTTABLES_H +/* Define to 1 if you have the `fremovexattr' function. */ +#undef HAVE_FREMOVEXATTR + /* Define to 1 if the system has the type `fsblkcnt_t'. */ #undef HAVE_FSBLKCNT_T +/* Define to 1 if you have the `fsetxattr' function. */ +#undef HAVE_FSETXATTR + /* Define to 1 if the system has the type `fsfilcnt_t'. */ #undef HAVE_FSFILCNT_T @@ -561,6 +579,9 @@ /* Define to 1 if you have the <OpenAL/al.h> header file. */ #undef HAVE_OPENAL_AL_H +/* Define to 1 if you have the `openat' function. */ +#undef HAVE_OPENAT + /* Define if OpenGL is present on the system */ #undef HAVE_OPENGL @@ -699,6 +720,12 @@ /* Define to 1 if the system has the type `sigset_t'. */ #undef HAVE_SIGSET_T +/* Define if fgetxattr takes six arguments, as in Mac OS X */ +#undef HAVE_SIX_ARG_FGETXATTR + +/* Define if fsetxattr takes six arguments, as in Mac OS X */ +#undef HAVE_SIX_ARG_FSETXATTR + /* Define to 1 if the system has the type `size_t'. */ #undef HAVE_SIZE_T @@ -855,6 +882,9 @@ /* Define to 1 if you have the <sys/exec_elf.h> header file. */ #undef HAVE_SYS_EXEC_ELF_H +/* Define to 1 if you have the <sys/extattr.h> header file. */ +#undef HAVE_SYS_EXTATTR_H + /* Define to 1 if you have the <sys/filio.h> header file. */ #undef HAVE_SYS_FILIO_H @@ -984,12 +1014,18 @@ /* Define to 1 if you have the <sys/wait.h> header file. */ #undef HAVE_SYS_WAIT_H +/* Define to 1 if you have the <sys/xattr.h> header file. */ +#undef HAVE_SYS_XATTR_H + /* Define to 1 if you have the `tcgetattr' function. */ #undef HAVE_TCGETATTR /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H +/* Define if fremovexattr takes three arguments, as in Mac OS X */ +#undef HAVE_THREE_ARG_FREMOVEXATTR + /* Define to 1 if you have the `thr_kill2' function. */ #undef HAVE_THR_KILL2 @@ -1005,6 +1041,9 @@ /* Define to 1 if you have the <unistd.h> header file. */ #undef HAVE_UNISTD_H +/* Define to 1 if you have the `unlinkat' function. */ +#undef HAVE_UNLINKAT + /* Define to 1 if you have the `usleep' function. */ #undef HAVE_USLEEP diff --git a/include/wine/port.h b/include/wine/port.h index 61c8399..6568dae 100644 --- a/include/wine/port.h +++ b/include/wine/port.h @@ -48,6 +48,9 @@ # include <unistd.h> #endif +#ifdef HAVE_SYS_XATTR_H +# include <sys/xattr.h> +#endif /**************************************************************** * Type definitions @@ -117,6 +120,18 @@ struct statvfs #define mkdir(path,mode) mkdir(path) #endif +#ifdef HAVE_SIX_ARG_FGETXATTR +#define fgetxattr(fd,name,val,size) fgetxattr(fd,name,val,size,0,0) +#endif + +#ifdef HAVE_SIX_ARG_FSETXATTR +#define fsetxattr(fd,name,val,size,opts) fsetxattr(fd,name,val,size,0,opts) +#endif + +#ifdef HAVE_THREE_ARG_FREMOVEXATTR +#define fremovexattr(fd,name) fremovexattr(fd,name,0) +#endif + #if !defined(HAVE_FTRUNCATE) && defined(HAVE_CHSIZE) #define ftruncate chsize #endif @@ -328,6 +343,21 @@ int symlink(const char *from, const char *to); int usleep (unsigned int useconds); #endif /* !defined(HAVE_USLEEP) */ +#ifndef HAVE_FGETXATTR +size_t fgetxattr (int fd, const char *name, void *value, size_t size); +#endif /* !defined(HAVE_FGETXATTR) */ + +#ifndef HAVE_FSETXATTR +#define XATTR_CREATE 1 +#define XATTR_REPLACE 2 +size_t fsetxattr (int fd, const char *name, const void *value, size_t size, + int opts); +#endif /* !defined(HAVE_FSETXATTR) */ + +#ifndef HAVE_FREMOVEXATTR +size_t fremovexattr (int fd, const char *name); +#endif /* !defined(HAVE_FREMOVEXATTR) */ + #ifdef __i386__ static inline void *memcpy_unaligned( void *dst, const void *src, size_t size ) { @@ -470,6 +500,12 @@ extern unsigned char interlocked_cmpxchg128( __int64 *dest, __int64 xchg_high, #define strerror __WINE_NOT_PORTABLE(strerror) #define strncasecmp __WINE_NOT_PORTABLE(strncasecmp) #define usleep __WINE_NOT_PORTABLE(usleep) +#undef fgetxattr +#define fgetxattr __WINE_NOT_PORTABLE(fgetxattr) +#undef fsetxattr +#define fsetxattr __WINE_NOT_PORTABLE(fsetxattr) +#undef fremovexattr +#define fremovexattr __WINE_NOT_PORTABLE(fremovexattr) #endif /* NO_LIBWINE_PORT */ diff --git a/libs/port/Makefile.in b/libs/port/Makefile.in index c4c0127..e046562 100644 --- a/libs/port/Makefile.in +++ b/libs/port/Makefile.in @@ -8,6 +8,9 @@ MODULE = libwine_port.a C_SRCS = \ ffs.c \ + fgetxattr.c \ + fremovexattr.c \ + fsetxattr.c \ fstatvfs.c \ futimes.c \ getopt.c \ diff --git a/libs/port/fgetxattr.c b/libs/port/fgetxattr.c new file mode 100644 index 0000000..196d11a --- /dev/null +++ b/libs/port/fgetxattr.c @@ -0,0 +1,96 @@ +/* + * fgetxattr function + * + * Copyright 2009 Benjamin Peddell + * + * 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 + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FGETXATTR + +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fgetxattr (int fd, const char *name, void *value, size_t size){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + size_t attrsize = -1; + off_t pos; + struct stat statbuf; + int attrfd; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } + attrfd = openat(fd, name, O_XATTR | O_RDONLY); + if (attrfd >= 0){ + ret = fstat(attrfd, &statbuf); + if (ret >= 0){ + attrsize = (size_t)statbuf.st_size; + if (attrsize >= 0 && attrsize <= size){ + pos = 0; + while (pos < attrsize){ + ret = read(attrfd, value + pos, attrsize - pos); + if (ret > 0){ + pos += ret; + } else { + attrsize = pos; + } + } + } else { + errno = ERANGE; + } + } + close(attrfd); + } + if (attrsize >= 0){ + return attrsize; + } else { + return (size_t)ret; + } +/* FreeBSD extattr_get_fd support */ +#elif defined(HAVE_EXTATTR_GET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_get_fd (fd, namespace, name + nameofs, value, size); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FGETXATTR */ diff --git a/libs/port/fremovexattr.c b/libs/port/fremovexattr.c new file mode 100644 index 0000000..b752fb8 --- /dev/null +++ b/libs/port/fremovexattr.c @@ -0,0 +1,75 @@ +/* + * fremovexattr function + * + * Copyright 2009 Benjamin Peddell + * + * 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 + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FREMOVEXATTR + +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fremovexattr (int fd, const char *name){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_UNLINKAT) && defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + int attrfd; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } + attrfd = openat(fd, ".", O_RDONLY | O_XATTR); + if (attrfd >= 0){ + ret = unlinkat(attrfd, name, 0); + close(attrfd); + } else { + ret = attrfd; + } + return ret; +/* FreeBSD extattr_delete_fd support */ +#elif defined(HAVE_EXTATTR_SET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_delete_fd (fd, namespace, name + nameofs); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FREMOVEXATTR */ diff --git a/libs/port/fsetxattr.c b/libs/port/fsetxattr.c new file mode 100644 index 0000000..7640f81 --- /dev/null +++ b/libs/port/fsetxattr.c @@ -0,0 +1,102 @@ +/* + * fsetxattr function + * + * Copyright 2009 Benjamin Peddell + * + * 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 + */ + +#include "config.h" +#include "wine/port.h" + +#ifndef HAVE_FSETXATTR +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#ifdef HAVE_SYS_EXTATTR_H +# include <sys/extattr.h> +#endif +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif +#include <errno.h> + +size_t fsetxattr (int fd, const char *name, const void *value, size_t size, + int opts){ +/* Solaris openat(fd,path,O_XATTR) support */ +#ifdef defined(HAVE_OPENAT) && defined(O_XATTR) + int ret; + size_t attrsize = -1; + off_t pos; + struct stat statbuf; + int attrfd; + int flags = O_XATTR | O_WRONLY | O_CREAT; + if (strchr(name, '/') != NULL){ + errno = EINVAL; + return -1; + } else if (strncmp (name, "SUNW", 4) == 0){ + errno = EINVAL; + return -1; + } else if (opts & XATTR_CREATE && opts & XATTR_REPLACE){ + errno = EINVAL; + return -1; + } else if (opts & XATTR_CREATE){ + flags |= O_EXCL; + } else if (opts & XATTR_REPLACE){ + flags &= ~O_CREAT; + } + attrfd = openat(fd, name, flags, 0666); + if (attrfd >= 0){ + pos = 0; + attrsize = size; + while (pos < attrsize){ + ret = write(attrfd, value + pos, attrsize - pos); + if (ret > 0){ + pos += ret; + } else { + attrsize = pos; + } + } + close(attrfd); + } else { + ret = attrfd; + } + if (attrsize >= 0){ + return attrsize; + } else { + return (size_t)ret; + } +/* FreeBSD extattr_set_fd support */ +#elif defined(HAVE_EXTATTR_SET_FD) + int nameofs; + int namespace; + if (strncmp (name, "user.", 5) == 0){ + namespace = EXTATTR_NAMESPACE_USER; + nameofs = 5; + } else if (strncmp (name, "system.", 7) == 0){ + namespace = EXTATTR_NAMESPACE_SYSTEM; + nameofs = 7; + } else { + errno = ENOENT; + return -1; + } + return extattr_set_fd (fd, namespace, name + nameofs, value, size); +#else + errno = ENOSYS; + return -1; +#endif +} + +#endif /* HAVE_FSETXATTR */ -- 1.6.4.4

1 0

Re: wined3d: Fix some typos
by Roderick Colenbrander 15 Nov '09

15 Nov '09

Hi Anders, Your patch changes to two different dlls in one patch. In general a patch should only change one thing. It would be nice if you could separate it because else I'm not sure if it will be added. Roderick On Sun, Nov 15, 2009 at 9:12 PM, Anders Jonsson <anders.jonsson(a)norsjonet.se> wrote: > Fixes some typos in comctl32 and wined3d. > > >From 0656be69a97b7aae11b760fc4a436eb30191d527 Mon Sep 17 00:00:00 2001 > From: Anders Jonsson <anders.jonsson(a)norsjonet.se> > Date: Sun, 15 Nov 2009 21:05:22 +0100 > Subject: Fix some typos > > --- > dlls/comctl32/updown.c | 4 ++-- > dlls/wined3d/state.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/updown.c b/dlls/comctl32/updown.c > index a212073..773d359 100644 > --- a/dlls/comctl32/updown.c > +++ b/dlls/comctl32/updown.c > @@ -550,7 +550,7 @@ UPDOWN_Buddy_SubclassProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > * > * Sets bud as a new Buddy. > * Then, it should subclass the buddy > - * If window has the UDS_ARROWKEYS, it subcalsses the buddy window to > + * If window has the UDS_ARROWKEYS, it subclasses the buddy window to > * process the UP/DOWN arrow keys. > * If window has the UDS_ALIGNLEFT or UDS_ALIGNRIGHT style > * the size/pos of the buddy and the control are adjusted accordingly. > @@ -659,7 +659,7 @@ static HWND UPDOWN_SetBuddy (UPDOWN_INFO* infoPtr, HWND bud) > * 'delta' amount according to the 'action' flag which can be a > * combination of FLAG_INCR and FLAG_DECR > * It notifies the parent as required. > - * It handles wraping and non-wraping correctly. > + * It handles wrapping and non-wrapping correctly. > * It is assumed that delta>0 > */ > static void UPDOWN_DoAction (UPDOWN_INFO *infoPtr, int delta, int action) > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index 94fe19e..6df6e54 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -1636,7 +1636,7 @@ static void state_wrap(DWORD state, IWineD3DStateBlockImpl *stateblock, struct w > stateblock->renderState[WINED3DRS_WRAP13] || > stateblock->renderState[WINED3DRS_WRAP14] || > stateblock->renderState[WINED3DRS_WRAP15] ) { > - FIXME("(WINED3DRS_WRAP0) Texture wraping not yet supported\n"); > + FIXME("(WINED3DRS_WRAP0) Texture wrapping not yet supported\n"); > } > } > > -- > 1.6.3.3 > > > > >

1 0

Implementing a cooling-off list in the heap
by Dan Kegel 15 Nov '09

15 Nov '09

Valgrind has a nice option --freelist_vol which is the total size of blocks to hold on the freed block queue. It does this to help detect double free errors. Where in Wine's heap would one want to keep a free list like that? My first idea is to just add another element to the freeList array; rather than putting freed blocks into the normal element by size, they'd all go into the purgatory element until it filled up, after which they would be transferred to the normal free list according to their size. (Now off to ride the new light rail. In Los Angeles, any time they open a new one, it's cause for celebration... you kinda have to go there and see if some of the improbability will rub off on you.)

1 0

Re: ddraw/tests: Add test for refcounts of surface objects.
by Stefan Dösinger 15 Nov '09

15 Nov '09

Am 15.11.2009 um 20:55 schrieb Vincent Povirk: > > > <0001-ddraw-tests-Add-test-for-refcounts-of-surface-object.txt> I think we already have tests for that - see IFaceRefCount() in dsurface.c

2 1

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failues
by Greg Geldorp 15 Nov '09

15 Nov '09

> I think you misunderstood me. The window is created but as you're > searching for a "Startup" window's title it fails on localized > systems. So the test is not completely correct and only work on > English system. That's why I proposed to skip the two tests on (and > only on) such systems. I haven't tested this, but perhaps it's possible to use SHGetSpecialFolderPath(..., CSIDL_STARTUP, ...) to obtain the (localized) file system location of the "Startup" folder, then use the last part of that path as the window title to search for. E.g. on English Windows the path retrieved by the call would be "C:\Documents and Settings\<username>\Start Menu\Programs\Startup", taking the last component would result in "Startup". On Dutch Windows the path would be "C:\Documents and Settings\<username>\Menu Start\Programma's\Opstarten", resulting in a last component of "Opstarten" which most likely is also the window title. Greg.

1 0

Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
by Nicolas Le Cam 15 Nov '09

15 Nov '09

2009/11/14 Mikey Alexander <firesword14(a)yahoo.com>: > Fixes a memory leak, non connection to the progman dde on early windows, and timeout problems with the conformance tests. > > --- > dlls/shell32/tests/progman_dde.c | 25 +++++++++++++++++-------- > 1 files changed, 17 insertions(+), 8 deletions(-) > Hi Mikey, There's also a test failure on localized Windows (see http://test.winehq.org/data/8a17a028b73d1ccc5b7ebaa9e135a1bfbf159615/2000_w… for example) because the window doesn't have the expected title. I tried to skip the ShowGroupTest call at line 510 (before your patch) but then the next call fails. Is there a better solution than skipping those two calls ? If not I'll just send a skipping patch. -- Nicolas Le Cam

2 2

Working on avifil32, sudden "non enough memory" error
by Julius Schwartzenberg 15 Nov '09

15 Nov '09

Hi, I'm working on fixing some things in avifil32. Several problems should be gone when using the attached four patches and most AVI files play back properly. With one file however (GOODTIME.AVI from the win95 cd) I get this error after about a second: err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 next block has PREV_FREE flag non enough memory I have no idea where this comes from and why it happens. (It appears to be unrelated to the memcpy call in avifile.c around line 1114.) With +heap I also get this before the error: HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. (the assert fails) The whole output is here: http://haar.student.utwente.nl/~julius/avifile-heaperr.log.gz What could I try to figure out the cause of this problem? I can provide both the file and my test program if necessary. Note that on MS Windows XP it all works without problems. Thanks in advance, Julius From a5fdf2316923e9b4fd254e571b5f70cb5a5ee87f Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:18:26 +0100 Subject: avifile: Fix header for audio stream --- dlls/avifil32/avifile.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 49e141f..4ecc6f6 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1816,7 +1816,15 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) if (FAILED(hr)) return hr; }; - + if (pStream->lpFormat != NULL && pStream->sInfo.fccType == streamtypeAUDIO) + { + WAVEFORMATEX *wfx = pStream->lpFormat; + wfx->nBlockAlign = wfx->nChannels * wfx->wBitsPerSample / 8; + pStream->sInfo.dwSampleSize = wfx->nBlockAlign; + TRACE("Block size reset to %u, chan=%u bpp=%u\n", wfx->nBlockAlign, wfx->nChannels, wfx->wBitsPerSample); + pStream->sInfo.dwScale = 1; + pStream->sInfo.dwRate = wfx->nSamplesPerSec; + } if (mmioAscend(This->hmmio, &ck, 0) != S_OK) return AVIERR_FILEREAD; } -- 1.6.3.3 From 84a0ee0327569c91c74d99be3c124c09cfc45cb9 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:28:19 +0100 Subject: avifile: Fix header suggested buffersize --- dlls/avifil32/avifile.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 4ecc6f6..c40cbd9 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1652,7 +1652,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) This->fInfo.dwCaps = AVIFILECAPS_CANREAD|AVIFILECAPS_CANWRITE; This->fInfo.dwLength = MainAVIHdr.dwTotalFrames; This->fInfo.dwStreams = MainAVIHdr.dwStreams; - This->fInfo.dwSuggestedBufferSize = MainAVIHdr.dwSuggestedBufferSize; + This->fInfo.dwSuggestedBufferSize = 0; This->fInfo.dwWidth = MainAVIHdr.dwWidth; This->fInfo.dwHeight = MainAVIHdr.dwHeight; LoadStringW(AVIFILE_hModule, IDS_AVIFILETYPE, This->fInfo.szFileType, @@ -1754,8 +1754,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) pStream->sInfo.dwRate = streamHdr.dwRate; pStream->sInfo.dwStart = streamHdr.dwStart; pStream->sInfo.dwLength = streamHdr.dwLength; - pStream->sInfo.dwSuggestedBufferSize = - streamHdr.dwSuggestedBufferSize; + pStream->sInfo.dwSuggestedBufferSize = 0; pStream->sInfo.dwQuality = streamHdr.dwQuality; pStream->sInfo.dwSampleSize = streamHdr.dwSampleSize; pStream->sInfo.rcFrame.left = streamHdr.rcFrame.left; @@ -1905,6 +1904,13 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) } } + for (nStream = 0; nStream < This->fInfo.dwStreams; nStream++) + { + DWORD sugbuf = This->ppStreams[nStream]->sInfo.dwSuggestedBufferSize; + if (This->fInfo.dwSuggestedBufferSize < sugbuf) + This->fInfo.dwSuggestedBufferSize = sugbuf; + } + /* find other chunks */ FindChunkAndKeepExtras(&This->fileextra, This->hmmio, &ck, &ckRIFF, 0); -- 1.6.3.3 From c6437174e6c2241b95b0d9b30ae6d2cac8218cdc Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:32:33 +0100 Subject: avifile: Fix playback of fixed sample size audio stream --- dlls/avifil32/avifile.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index c40cbd9..5fa45ae 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1093,6 +1093,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; + if (!buffer) + buffersize = samples; + while (samples > 0 && buffersize > 0) { if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); @@ -1102,11 +1105,12 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, size = min((DWORD)samples, (DWORD)buffersize); size = min(size, This->cbBuffer - offset); - memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); - + if (buffer) + memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; offset = 0; - buffer = ((LPBYTE)buffer)+size; + if (buffer) + buffer = ((LPBYTE)buffer)+size; samples -= size; buffersize -= size; @@ -1117,7 +1121,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, *samplesread += size / This->sInfo.dwSampleSize; } - if (samples == 0) + TRACE("Returning %d/%d\n", bytesread ? *bytesread : -1, samplesread ? *samplesread : -1); + + if (samples == 0 || !buffer) return AVIERR_OK; else return AVIERR_BUFFERTOOSMALL; -- 1.6.3.3 From 9a429b3146f6718b3742816e2ff163e65e1ad748 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 15 Nov 2009 17:07:52 +0100 Subject: Fix ticking problem which occured when reading through a block --- dlls/avifil32/avifile.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 5fa45ae..88bf2ab 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1089,6 +1089,7 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert start sample to block,offset pair */ AVIFILE_SamplesToBlock(This, &block, &offset); + TRACE("block=%d, offset=%d\n", block, offset); /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; @@ -1097,6 +1098,7 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, buffersize = samples; while (samples > 0 && buffersize > 0) { + LONG blocksize; if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); if (FAILED(hr)) @@ -1104,7 +1106,10 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, } size = min((DWORD)samples, (DWORD)buffersize); - size = min(size, This->cbBuffer - offset); + blocksize = (BYTE*)This->lpBuffer[1]; +/* blocksize = This->cbBuffer; */ + TRACE("blocksize = %u\n",blocksize); + size = min(size, blocksize - offset); if (buffer) memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; -- 1.6.3.3

1 0

avifile bugfixes
by Julius Schwartzenberg 15 Nov '09

15 Nov '09

Here are some bugfixes for avifile that Maarten mainly did during WineConf. The behaviour corresponds to what native avifil32 does. I will add tests to show this and submit the patches then. (Maybe avifil32 does a few more hacks like these, I'll add those too when I find them when creating tests.) If anyone has any comments on the patches as they are now already, please let me know. Thanks! Julius From 2e9c13211c0343fd59faf835a1d954416ab46203 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:18:26 +0100 Subject: [PATCH 1/3] avifile: Fix header for audio stream --- dlls/avifil32/avifile.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 49e141f..4ecc6f6 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1816,7 +1816,15 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) if (FAILED(hr)) return hr; }; - + if (pStream->lpFormat != NULL && pStream->sInfo.fccType == streamtypeAUDIO) + { + WAVEFORMATEX *wfx = pStream->lpFormat; + wfx->nBlockAlign = wfx->nChannels * wfx->wBitsPerSample / 8; + pStream->sInfo.dwSampleSize = wfx->nBlockAlign; + TRACE("Block size reset to %u, chan=%u bpp=%u\n", wfx->nBlockAlign, wfx->nChannels, wfx->wBitsPerSample); + pStream->sInfo.dwScale = 1; + pStream->sInfo.dwRate = wfx->nSamplesPerSec; + } if (mmioAscend(This->hmmio, &ck, 0) != S_OK) return AVIERR_FILEREAD; } -- 1.6.3.3 From 969620de75ae75d13cf5f443842cee8bf28c4362 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:28:19 +0100 Subject: [PATCH 2/3] avifile: Fix header suggested buffersize --- dlls/avifil32/avifile.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index 4ecc6f6..c40cbd9 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1652,7 +1652,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) This->fInfo.dwCaps = AVIFILECAPS_CANREAD|AVIFILECAPS_CANWRITE; This->fInfo.dwLength = MainAVIHdr.dwTotalFrames; This->fInfo.dwStreams = MainAVIHdr.dwStreams; - This->fInfo.dwSuggestedBufferSize = MainAVIHdr.dwSuggestedBufferSize; + This->fInfo.dwSuggestedBufferSize = 0; This->fInfo.dwWidth = MainAVIHdr.dwWidth; This->fInfo.dwHeight = MainAVIHdr.dwHeight; LoadStringW(AVIFILE_hModule, IDS_AVIFILETYPE, This->fInfo.szFileType, @@ -1754,8 +1754,7 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) pStream->sInfo.dwRate = streamHdr.dwRate; pStream->sInfo.dwStart = streamHdr.dwStart; pStream->sInfo.dwLength = streamHdr.dwLength; - pStream->sInfo.dwSuggestedBufferSize = - streamHdr.dwSuggestedBufferSize; + pStream->sInfo.dwSuggestedBufferSize = 0; pStream->sInfo.dwQuality = streamHdr.dwQuality; pStream->sInfo.dwSampleSize = streamHdr.dwSampleSize; pStream->sInfo.rcFrame.left = streamHdr.rcFrame.left; @@ -1905,6 +1904,13 @@ static HRESULT AVIFILE_LoadFile(IAVIFileImpl *This) } } + for (nStream = 0; nStream < This->fInfo.dwStreams; nStream++) + { + DWORD sugbuf = This->ppStreams[nStream]->sInfo.dwSuggestedBufferSize; + if (This->fInfo.dwSuggestedBufferSize < sugbuf) + This->fInfo.dwSuggestedBufferSize = sugbuf; + } + /* find other chunks */ FindChunkAndKeepExtras(&This->fileextra, This->hmmio, &ck, &ckRIFF, 0); -- 1.6.3.3 From 39d6ecab76989b93d35a0568e105fd306fa32706 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Sun, 8 Nov 2009 15:32:33 +0100 Subject: [PATCH 3/3] avifile: Fix playback of fixed sample size audio stream --- dlls/avifil32/avifile.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c index c40cbd9..5fa45ae 100644 --- a/dlls/avifil32/avifile.c +++ b/dlls/avifil32/avifile.c @@ -1093,6 +1093,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, /* convert samples to bytes */ samples *= This->sInfo.dwSampleSize; + if (!buffer) + buffersize = samples; + while (samples > 0 && buffersize > 0) { if (block != This->dwCurrentFrame) { hr = AVIFILE_ReadBlock(This, block, NULL, 0); @@ -1102,11 +1105,12 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, size = min((DWORD)samples, (DWORD)buffersize); size = min(size, This->cbBuffer - offset); - memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); - + if (buffer) + memcpy(buffer, ((BYTE*)&This->lpBuffer[2]) + offset, size); block++; offset = 0; - buffer = ((LPBYTE)buffer)+size; + if (buffer) + buffer = ((LPBYTE)buffer)+size; samples -= size; buffersize -= size; @@ -1117,7 +1121,9 @@ static HRESULT WINAPI IAVIStream_fnRead(IAVIStream *iface, LONG start, *samplesread += size / This->sInfo.dwSampleSize; } - if (samples == 0) + TRACE("Returning %d/%d\n", bytesread ? *bytesread : -1, samplesread ? *samplesread : -1); + + if (samples == 0 || !buffer) return AVIERR_OK; else return AVIERR_BUFFERTOOSMALL; -- 1.6.3.3

2 2

Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY
by Ilya Shpigor 15 Nov '09

15 Nov '09

Please don't commit this test. Instead use or comment next try: user32: Destroy EDITSTATE structure in the WM_NCDESTROY message processing -- Best regards, Ilya Shpigor.

1 0

commit 70ae1ba4 caused regression in dinpu9
by Vitaliy Margolen 15 Nov '09

15 Nov '09

Markus, You patch caused regression: http://bugs.winehq.org/show_bug.cgi?id=20711 Please take a look. Vitaliy.

1 0

Implementing FLG_HEAP_ENABLE_TAIL_CHECK
by Dan Kegel 15 Nov '09

15 Nov '09

Running Chromium's test suite under valgrind+wine did find a handful of interesting Wine problems, and one or two Chromium problems, but it seems to miss a whole bunch of problems Purify catches. Thinking about it a bit, I realized that Valgrind replaces the linux heap with one that puts guard bytes before and after each allocation, and marks those guard bytes as inaccessible. Valgrind's replacement heap also keeps freed blocks out of circulation for a while, marking them completely inaccessible so that references to freed blocks are caught. At the moment, nothing does this when running win32 apps under wine+valgrind; sure, wine informs Valgrind about the allocations made by the NT heap, but it doesn't put any guard bytes around them. So, how can we achieve this on Wine? The Wine philosophy is to look for how Windows likes to do things, and sure enough, there are ways to tell the Windows kernel to do similar things. http://technet.microsoft.com/en-us/library/cc736347(WS.10).aspx describes the gflags utility, used to set registry flags that end up controlling the NtGlobalFlags field of each processes' PEB. FLG_HEAP_ENABLE_TAIL_CHECK tells the heap to add guard bytes at the end of each allocation. FLG_HEAP_PAGE_ALLOCS tells the heap to add a whole guard page at the end of each allocation. (The /backwards option to gflags modifies this to put the page at the beginning of the allocation, but I don't know what NtGlobalFlags value this corresponds to.) I don't see any option there for "keep newly freed blocks out of circulation for the moment"; FLG_HEAP_DISABLE_COALESCING is kind of close. I'm tempted to try implementing enough of this so Wine+Valgrind can catch more of the Chromium errors that Purify can. Thoughts? - Dan

1 0

today's git broke winetricks gecko :-(
by Dan Kegel 13 Nov '09

13 Nov '09

Hi Jacek, as of today, "winetricks gecko" triggers the download dialog box :-( Presumably this was caused by http://www.winehq.org/pipermail/wine-cvs/2009-November/061489.html Even if I rearrange the script so there are no invocations of wine before unpacking gecko, it still puts up the dialog box when I run regedit to tell wine about the gecko I unpacked! Got any suggestions? - Dan

6 19

Re: (try 2) user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().
by Rob Shearman 13 Nov '09

13 Nov '09

2009/11/12 Rico Schüller <kgbricola(a)web.de>: > Hi, > > this patch adds a check for PTITLEBARINFO in GetTitleBarInfo() to avoid a > crash. This fixes bug 20249 . > > Try 2 improvement: > - do not print the null pointer, it's useless > > Cheers > Rico > > --- > dlls/user32/nonclient.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) You could easily add a testcase for this behaviour. -- Rob Shearman

2 1

Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY
by Nikolay Sivov 13 Nov '09

13 Nov '09

On 11/13/09, Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > Hi, > > There is a problem to get edit control text after It has processed > WM_DESTROY > message. Perhaps, problem with EDITSTATE structure what contain this text. > WM_DESTROY cause destroying this structure. This is currently a place where control releases its data, and that's fine in that sense. > > Is it possible to solve this problem properly without hacks? > Yes, if destruction itself is made on WM_NCDESTROY for example, or even DestroyWindow knows Edit class and handles its specific data releasing internally. > -- > Best regards, > Ilya Shpigor. >

1 0

Re: [try 3] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList
by Alexandre Julliard 13 Nov '09

13 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; It doesn't make sense to check the interface pointer, it can't be NULL. Also please don't resend the full series once again, when things don't get committed on the first try you need to proceed in smaller steps. -- Alexandre Julliard julliard(a)winehq.org

1 0

What to do when un-nominating bugs for 1.2
by Dan Kegel 12 Nov '09

12 Nov '09

In the gcc world, when a bug is targeted for release X and doesn't make it in time, it is retargeted for release X+1. So when 1.0 rolled around, I retargeted the leftover 1.0-targeted bugs at 1.2. Can we do the same this time, and retarget 1.2 bugs for 1.4 if they're not going to be fixed for 1.2? The only time one should simply remove the 1.2 target is if we decide the bug really isn't even a candidate for 1.4 (or was nominated for 1.2 in error).

4 4

Re: user32: Add argument check for PTITLEBARINFO in GetTitleBarInfo().
by Paul Vriens 12 Nov '09

12 Nov '09

On 11/12/2009 07:43 PM, Rico Schüller wrote: > + if(!tbi) { > + TRACE("Invalid TITLEBARINFO: %p\n", tbi); Hi Rico, So your printing the NULL pointer? -- Cheers, Paul.

2 1

Re: comctl32/tests: Move message testing helpers to header
by Nikolay Sivov 12 Nov '09

12 Nov '09

Ignore this one, it's a old patch which is wrong but wants to live so much that I send it accidentally. Forget about it.

1 0

Question about GetTokenInformation and memory leaks
by Dan Kegel 12 Nov '09

12 Nov '09

I've never used the security apis, so I'm pretty unfamiliar with them. Valgrinding chromium's sandbox_unittests.exe shows the leak 16 bytes in 1 blocks are definitely lost in loss record 123 of 728 at RtlAllocateHeap (heap.c:1423) by RtlAllocateAndInitializeSid (sec.c:156) by NtQueryInformationToken (nt.c:379) by GetTokenInformation (security.c:676) by ATL::CAccessToken::GetInfoConvert<ATL::CSid,_TOKEN_PRIMARY_GROUP> (atlsecurity.h:754) by ATL::CAccessToken::GetPrimaryGroup (atlsecurity.inl:3623) by sandbox::RestrictedTokenTest_CustomInit_Test::TestBody (restricted_token_unittest.cc:92) The test in question is on line 92 of http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/restricted_toke… Can someone familiar with this stuff have a look? I suspect it's a problem with the test, but can't figure out what's going on. I would have thought the destructors for ATL::CAccessToken and ATL::CSid would have freed everything. (I think the code leaks token_handle, but fixing that doesn't get rid of the reported leak.) - Dan

3 4

Re: [try 2] [PATCH 01/12] comctl32: Add basic structure for IImageList interface
by Alexandre Julliard 12 Nov '09

12 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > @@ -2926,10 +2927,295 @@ ImageList_SetColorTable (HIMAGELIST himl, UINT uStartIndex, UINT cEntries, CONST > HRESULT WINAPI > ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID riid, void **ppv) > { > - FIXME("STUB: %s %p %s %p\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%s,%p,%s,%p)\n", debugstr_guid(rclsid), punkOuter, debugstr_guid(riid), ppv); > + > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; You should be checking the clsid here. The iid is checked in QueryInterface. > @@ -2948,6 +3234,38 @@ ImageList_CoCreateInstance (REFCLSID rclsid, const IUnknown *punkOuter, REFIID r > HRESULT WINAPI > HIMAGELIST_QueryInterface (HIMAGELIST himl, REFIID riid, void **ppv) > { > - FIXME("STUB: %p %s %p\n", himl, debugstr_guid(riid), ppv); > - return E_NOINTERFACE; > + TRACE("(%p,%s,%p)\n", himl, debugstr_guid(riid), ppv); > + > + *ppv = NULL; > + > + /* TODO: IID_IImageList2 support */ > + if (!IsEqualIID(&IID_IImageList, riid)) > + return E_NOINTERFACE; This one is redundant too. > @@ -30,6 +30,9 @@ > /* the ones with offsets at the end are the same as in Windows */ > struct _IMAGELIST > { > + const struct IImageListVtbl *lpVtbl;/* IImageList vtable */ > + LONG ref; /* reference count */ > + > DWORD magic; /* 00: 'SAMX' */ > INT cCurImage; /* 04: ImageCount */ > INT cMaxImage; /* 08: maximages */ Please update the comment since the offsets no longer match Windows. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/9] avrt: Add stub for Av(Set, Revert)MMThreadCharacteristics
by Alexandre Julliard 12 Nov '09

12 Nov '09

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > +HANDLE WINAPI AvSetMmThreadCharacteristicsW(LPCWSTR TaskName, LPDWORD TaskIndex) > +{ > + FIXME("(%s,%p): stub\n", debugstr_w(TaskName), TaskIndex); > + > + if (!TaskName) > + { > + SetLastError(ERROR_INVALID_TASK_NAME); > + return NULL; > + } > + if (!TaskIndex) > + { > + SetLastError(ERROR_INVALID_HANDLE); > + return NULL; > + } > + return (HANDLE)(LONG_PTR)-1; -1 is not a good choice for a valid handle value. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] d3d9: Accept the geforce 8 fog+srgb result
by Henri Verbeet 12 Nov '09

12 Nov '09

2009/11/12 Stefan Dösinger <stefan(a)codeweavers.com>: > - ok(color_match(color, 0x00808080, 1), > + ok(color_match(color, 0x00808080, 1) || broken(color_match(color, 0x00bcbcbc, 1)), Just because drivers hack around HL2 doesn't mean it's broken.

1 0

Bugging people about test failures
by Paul Vriens 12 Nov '09

12 Nov '09

Hi, I hope people don't mind me sending the occasional email about failing tests on Windows. The test.winehq.org pages are usually very red so it can be a bit hard sometimes to spot any 'regressions' in the conformance tests. I haven't payed much attention for 2 weeks and that (partly) results in what can be currently seen on test.winehq.org. I have of course limits in what I can fix so I need other people (especially the authors) to help me out here. Thanks to Juan and Rob for fixing loads of the failures already. Oh, and btw. not fixing your newly introduced failing tests in a timely matter (or at least paying attention to them) can even effect your Julliard ranking ;) -- Cheers, Paul.

1 0

Re: [try 2] [PATCH 03/12] comctl32: Implement Add, ReplaceIcon, GetImageCount, SetImageCount in IImageList
by Henri Verbeet 12 Nov '09

12 Nov '09

2009/11/11 Owen Rudge <orudge(a)codeweavers.com>: > @@ -2985,15 +2985,37 @@ static ULONG WINAPI ImageListImpl_Release(IImageList *iface) > static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > HBITMAP hbmMask, int *pi) > { > - FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > - return E_NOTIMPL; > + HIMAGELIST This = (HIMAGELIST) iface; > + int ret; > + > + if (!This || !hbmImage || !pi) > + return E_FAIL; I don't know if you have tests for the other parameters, but "iface" should never be NULL for COM methods.

1 0

Still a crash in the rpcrt4 tests
by Paul Vriens 12 Nov '09

12 Nov '09

Hi Rob, There is still a crash in the rpcrt4 tests on NT4+. These 2 tests both crash actually: 886 x = echo_ranged_int(0); 887 ok(x == 0, "echo_ranged_int() returned %d instead of 0\n", x); 888 x = echo_ranged_int(100); 889 ok(x == 100, "echo_ranged_int() returned %d instead of 100\n", x); but only in the "ncalrpc_basic" case. -- Cheers, Paul.

2 1

Re: d3d8/tests: Avoid a crash, when CreateTexture failed
by Henri Verbeet 11 Nov '09

11 Nov '09

2009/11/6 Henri Verbeet <hverbeet(a)gmail.com>: > If changing the usage makes it work, that's ok. Maybe try just passing > 0 for usage. The texture doesn't have to be lockable, all we care > about is having a unique texture pointer for the > SetTexture()/GetTexture() calls. > I.e., does the attached patch work for you?

2 1

What's the use of volatile in Wine code?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Nov '09

11 Nov '09

Hi, AJ wrote in http://www.winehq.org/pipermail/wine-devel/2009-November/079575.html >If there is proper synchronization you don't need >volatile, and if there isn't volatile won't magically fix it. However, mcimidi has in its code since pre 1999: :/* it seems that in case of multi-threading, gcc is optimizing just a little bit : * too much. Tell gcc not to optimize status value using volatile. : */ :while (((volatile WINE_MCIMIDI*)wmm)->dwStatus == MCI_MODE_PAUSE); The comment is right. Any C compiler is allowed to optimize this into an endless loop without volatile. But I'd rather see the following: :volatile dwStatus = NOT_READY; /* one central declaration */ :... :while (wmm->dwStatus == PAUSE) ; /* what, busy wait!?! */ So what's the use of volatile? When is it appropriate in Wine? I found this article from MSDN about memory acquire and release semantics, volatile and multiple processors very interesting. MS-VC changed the code generator for 'volatile' between 2003 and 2005 to accomodate multi-processor systems: http://msdn.microsoft.com/en-us/library/ms686355(VS.85).aspx Regards, Jörg Höhle

4 3

Fun new valgrind warnings in rpc code?
by Dan Kegel 11 Nov '09

11 Nov '09

As of today, six tests: http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_marshal.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_ndr_marsha… http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-ole32_moniker.txt http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/diff-rpcrt4_server.txt all report the new valgrind warning Syscall param socketcall.send(msg) points to uninitialised byte(s) at send (socket.S:100) by rpcrt4_conn_write (rpc_binding.h:170) by RPCRT4_SendWithAuth (rpc_message.c:841) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f037e28 is 40 bytes inside a block of size 60 alloc'd at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by RPCRT4_SendWithAuth (rpc_message.c:800) by RPCRT4_Send (rpc_message.c:983) by process_bind_packet (rpc_server.c:281) by RPCRT4_process_packet (rpc_server.c:412) by RPCRT4_worker_thread (rpc_server.c:435) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:187) by RtlAllocateHeap (heap.c:1429) by I_RpcAllocate (rpcrt4_main.c:574) by RPCRT4_ReceiveWithAuth (rpc_message.c:1160) by RPCRT4_Receive (rpc_message.c:1298) by RPCRT4_io_thread (rpc_server.c:453) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) I don't think that happened before today. Rob/Hans, could you have a look?

2 1

Any Wineconf results?
by Nikolay Sivov 11 Nov '09

11 Nov '09

Hi, guys. Unfortunately, but as I expected, I wasn't able to participate in Wineconf2009 (I'm business tripping for 3 weeks in central Asia now). I'd like to read something about decisions if any you've made at this conf, some principle ideas or something. Wiki page doesn't talk too much - but thanks for Michael's slides about wine-oopses. All I'm able to find is Marcus' flickr photoset and I'm not satisfied with that :). I've noticed some 1.2 target bugs dropping and a bunch of rpcrt4 and sound patches, and that's great. Anyway thanks for this year, all of you, it's really interesting to contribute here.

2 1

Re: Owen Rudge : comctl32: Add support for scrolling during marquee selection.
by Nikolay Sivov 11 Nov '09

11 Nov '09

On Wed, Nov 4, 2009 at 10:26 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: e1f3edef3e491095dd73548b711bddf14ee73ef0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=e1f3edef3e491095dd73548b7… > > Author: Owen Rudge <orudge(a)codeweavers.com> > Date: Mon Nov 2 10:58:26 2009 -0600 > > comctl32: Add support for scrolling during marquee selection. > > --- Hi, Owen. I've tested this a bit and it flickers like hell in some cases. Looks like list requests redraw even if selection doesn't change (pointer is still over already selected item). Other things: - selection logic is wrong when some items are already selected before marquee. On native it deselects those items, your code leave them as is. This is visible in regedit (report mode listview) - select first entry and start selection -> first item remains selected. - sometimes I get corrupted focus rectangle - moving pointer down causes bottom side to clear, rectangle contains three side after that (it could be a problem for my virtual box of course, or some embedded video drivers, but I don't see a problem moving up for example).

2 1

Re: Cpp Check Nov. 7th
by chris ahrendt 11 Nov '09

11 Nov '09

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> Alexandre Julliard wrote: >>> chris ahrendt <celticht32(a)yahoo.com> writes: >>> >>>> 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 >>> These are once again all false positives. I don't think there's any >>> point in continuing to post such reports, at least not until cppcheck >>> becomes more reliable. >>> >> Will report them to CPPcheck >> >> are you sure though all of these are false positives? > > Yes, there isn't a single legitimate bug in there. > Ticket open... chris

1 0

howto document for valgrinding application test suites (starting with chromium)
by Dan Kegel 11 Nov '09

11 Nov '09

http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html shows (using Chromium as an example) how windows developers can find memory errors in their windows code by running their test suites under valgrind+wine. It's still an early draft; I expect to improve it as I gain experience tracking down the problems that happen when running this test suite under valgrind+wine. Chromium makes a great example because it has a really good test suite, and, um, because it's my day job :-) This is currently an experiment. If it works out, I might get to do a lot more along these lines. - Dan

2 1

hang in mci tests?
by Dan Kegel 11 Nov '09

11 Nov '09

Hi Joerg, I had a new hang on yesterday's git under valgrind: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok preloader: Warning: failed to reserve range 00110000-68000000 mci.c:186: Test failed: mci close all notify (without buffer) returned error: 281 mci.c:190: Test failed: mci close all notify (with output buffer) returned error: 281 mci.c:199: Test failed: mci sysinfo waveaudio quantity open, expected output buffer '0', got: '1' mci.c:279: Test failed: mci status position gave 2333, expected 2000, some tests will fail mci.c:288: Test failed: recorded 74662 bytes, expected 64000 mci.c:298: Test failed: recorded 37331 samples, expected 32000 mci.c:330: Test failed: mci status length gave 2333, expected 2000, some tests will fail. mci.c:333: Test failed: mci incorrect cue output returned: MCIERR_EXTENSION_NOT_FOUND mci.c:148: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command play mci.c:149: Test failed: PeekMessage should succeed for command status mci.c:437: Test failed: Expected full pathname from info file: tempfile.wav err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable ... 1600 dup lines removed ... ALSA lib ../../../src/pcm/pcm.c:7228:(snd_pcm_recover) underrun occured 16 bytes in 1 blocks are definitely lost in loss record 148 of 913 by: RtlAllocateHeap (heap.c:1421) by: mciSendStringW (mci.c:1319) by: mciSendStringA (mci.c:1448) by: test_openCloseWAVE (mci.c:164) by: func_mci (mci.c:652) I had to kill it; dunno if the leak was because I interrupted it or not. - Dan

2 1

Amicus curiae: winenas.drv: Remove broken driver
by Michael Stefaniuc 11 Nov '09

11 Nov '09

Hello Alexandre and Maarten, as you guys where discussing right now on irc about it I'm rushing this email out. On 11/07/2009 02:45 PM, Maarten Lankhorst wrote: > --- > From 88fde5ad95a33dc2da29757605891ccc5047c12f Mon Sep 17 00:00:00 2001 > From: mlankhorst <mlankhorst(a)eee.(none)> > Date: Sat, 7 Nov 2009 13:34:54 +0000 > Subject: [PATCH] winenas.drv: Remove broken driver Data: ----- wine-bugs, wine-devel, wine-users archives from May 2008 to October 2009. Total of 133699 emails and 8313 bugs.winehq.org attachments. Tools: wineoops --------------- - Wine crashes parsed: select count(*) from crash; 2711 - Nr of crashes with module info associated: select count(*) from (select crash_id from crash_modules group by crash_id); 2319 - List of all the Wine audio drivers loaded: select count(*) as nr, name from crash_modules, module where module_id=id and name like "wine%" group by name order by nr desc; 1367|winealsa 156|wineoss 12|wineesd 4|winepulse 3|wineal 3|wineasio 3|winecoreaudio 2|winejack 1|winenas The one crash that has winenas in it is from May 2009. bye michael

1 0

new Lucid gcc compiles wine o
by Susan Cragin 11 Nov '09

11 Nov '09

Lucid has fixed the bug I mentioned earlier, and now Wine can be compiled in pre-alpha Lucid Lynx, providing all updates are as-of today, ll/11. In case anyone is interested, the working gcc is: gcc (Ubuntu 4.4.2-1ubuntu4) 4.4.2

1 0

new invalid read errors in winhttp
by Dan Kegel 11 Nov '09

11 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/diff-winhttp_notificat… http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/vg-winhttp_notificatio… has a bunch of new errors, all of which seem to look like this: Invalid read of size 4 at check_notification (notification.c:65) by send_callback (session.c:56) by close_connection (request.c:978) by release_object (handle.c:79) by task_thread (request.c:181) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f21f8f8 is not stack'd, malloc'd or (recently) free'd but I don't see any recent changes in that area? - Dan

1 0

[Fwd: 64bit wine]
by Michael Stefaniuc 11 Nov '09

11 Nov '09

3 4

Where to receive MCI PostMessageW notifications?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Nov '09

11 Nov '09

Hi, the MCI relies on notification to implement auto-open correctly. When the command is done, it must send out a notification via PostMessageW. The receiver then ought to call mciClose. One possible implementation would be to have auto-open start a thread that does nothing else but wait for this message to arrive, then call mciClose. I wonder if there's something more lightweight than a thread (this is not Erlang) that could be used inside Wine. What could be used that reacts asynchronously to PostMessageW? Currently, the missing auto-open functionality causes - unclosed files (some seen as error messages when Wine exits) (here it is essential that the notification works 100%) - some application hangs, some of them in Bugzilla. Thanks, Jörg Höhle

2 1

Re: shell32: Use Unicode for GetFileNameFromBrowse
by Alexandre Julliard 11 Nov '09

11 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > For some reason, we have implemented the GetFileNameFromBrowse > function in shell32 with ANSI functions. According to MSDN, the > function should use Unicode, and IE7 (which uses the function for its > File -> Open routine) expects this. This patch fixes that. It should probably be an AW function instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface
by Henri Verbeet 11 Nov '09

11 Nov '09

2009/11/10 Owen Rudge <orudge(a)codeweavers.com>: > +static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > + HBITMAP hbmMask, int *pi) > +{ > + FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > + return E_NOINTERFACE; > +} This is minor at this point, but E_NOTIMPL is usually a more appropriate return code for stubs.

1 0

Re: [PATCH 01/16] comctl32: Add class factory for IImageList interface
by Alexandre Julliard 11 Nov '09

11 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > These patches finish the implementation of the IImageList v6 interface > in comctl32. This doesn't seem to match Windows, even independently from the structure layout issue. There's no DllGetClassObject or clsid registration on Windows, it's not handled as a standard COM dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

MCI and application-level thread-safety?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Nov '09

11 Nov '09

Hi, So far my my patches have dealt only with "internal thread consistency", i.e. to avoid bogus conditions that result by using threads *internal* to the MCI. I wonder whether the individual MCI devices must protect themselves from application-level threads, i.e. an application issuing commands to the same device from several threads? (Also needed for auto-close...) This for sure would require the addition of critical sections which currently only mciavi32 has. These have to be thought about very carefully to avoid dead-locks (give me Erlang or Occam, or queues like in the audio drivers instead of this lock-based error-prone stuff!). Regards, Jörg Höhle

1 0

Re: Cpp Check Nov. 7th
by chris ahrendt 11 Nov '09

11 Nov '09

Alexandre Julliard wrote: > chris ahrendt <celticht32(a)yahoo.com> writes: > >> 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 > > These are once again all false positives. I don't think there's any > point in continuing to post such reports, at least not until cppcheck > becomes more reliable. > Will report them to CPPcheck are you sure though all of these are false positives? chris

2 1

re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface
by Dan Kegel 11 Nov '09

11 Nov '09

As Nikolay pointed out, the change > /* the ones with offsets at the end are the same as in Windows */ > struct _IMAGELIST > { >+ const struct IImageListVtbl *lpVtbl;/* IImageList vtable */ >+ LONG ref; /* reference count */ >+ > DWORD magic; /* 00: 'SAMX' */ is wrong because it changes offsets... but it also breaks those comments. (Can you put the vtable at the end?)

2 1

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface
by Nikolay Sivov 11 Nov '09

11 Nov '09

On Wed, Nov 11, 2009 at 12:11 AM, Owen Rudge <orudge(a)codeweavers.com> wrote: > --- > dlls/comctl32/imagelist.c | 322 > ++++++++++++++++++++++++++++++++++++++++++++- > dlls/comctl32/imagelist.h | 3 + > 2 files changed, 319 insertions(+), 6 deletions(-) > After that: --- diff --git a/dlls/comctl32/imagelist.h b/dlls/comctl32/imagelist.h index 73ccd8a..51b8635 100644 --- a/dlls/comctl32/imagelist.h +++ b/dlls/comctl32/imagelist.h @@ -30,6 +30,9 @@ /* the ones with offsets at the end are the same as in Windows */ struct _IMAGELIST { + const struct IImageListVtbl *lpVtbl;/* IImageList vtable */ + LONG ref; /* reference count */ + DWORD magic; /* 00: 'SAMX' */ INT cCurImage; /* 04: ImageCount */ INT cMaxImage; /* 08: maximages */ --- let's pray that nobody depends on structure layout :). If it'll be a problem the possible solution could be to use two structure types - one for traditional API and one for com-based. Choosing one of it could be done possibly in ImageList_Create checking for manifest enabled in activation context. All traditional calls should check for that then and apply an offset to pointer to get HIMAGELIST without vtbl. We'll see...

1 0

Wine 64-bit in Fedora ...
by Michael Stefaniuc 11 Nov '09

11 Nov '09

Fedora includes now a 64-bit Wine package (at least in F11) which of course breaks existing Wine setups. "yum install wine" will install the 64-bit version... Looks like we had our WineConf too late for this. I have opened https://bugzilla.redhat.com/show_bug.cgi?id=533988 for this problem. The quick fix is to just remove the wine*.x86_64 rpms and install the wine*.i586 instead. bye michael

5 6

Re: setupapi: add stub and some tests for SetupGetInfFileListW [resend]
by Henri Verbeet 10 Nov '09

10 Nov '09

2009/11/9 Stefan Leichter <Stefan.Leichter(a)camline.com>: > my crystal ball is still not working, therefore resending unchanged > Try http://source.winehq.org/patches/ And indeed, the patch doesn't apply: diff -urw wine-git/dlls/setupapi/install.c wine-build/dlls/setupapi/install.c --- a/wine-git/dlls/setupapi/install.c +++ b/wine-build/dlls/setupapi/install.c Note that you're also adding whitespace errors.

3 4

Re: [PATCH 16/16] comctl32/tests: Remove todo_wine from SHGetImageList tests
by Paul Vriens 10 Nov '09

10 Nov '09

On 11/10/2009 07:12 PM, Owen Rudge wrote: > --- > dlls/comctl32/tests/imagelist.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > Hi Owen, This patch suggest that one of the previous patches in this series makes the tests succeed or actually fail as they are inside a todo_wine(). -- Cheers, Paul.

2 1

Re: rsaenh/tests(3/5): Add round-trip test of RSA
by Paul Vriens 10 Nov '09

10 Nov '09

On 11/05/2009 07:11 PM, Juan Lang wrote: > --Juan > > Hi Juan, This one introduces some test failures on Win9x and WinMe: http://test.winehq.org/data/tests/rsaenh:rsaenh.html Could you have a look? -- Cheers, Paul.

1 0

Re: [8/9] widl: Add support for varargs functions.
by Paul Vriens 10 Nov '09

10 Nov '09

On 11/07/2009 03:55 PM, Rob Shearman wrote: > --- > dlls/rpcrt4/tests/server.c | 3 ++ > dlls/rpcrt4/tests/server.idl | 2 + > tools/widl/header.c | 68 ++++++++++++++++++++++------------------- > tools/widl/parser.l | 1 + > tools/widl/parser.y | 12 +++++-- > 5 files changed, 51 insertions(+), 35 deletions(-) > hi Rob, Either this one or "widl: Implement [range] attribute." introduced quite some test failures: http://test.winehq.org/data/tests/rpcrt4:server.html Could you please take a look? -- Cheers, Paul.

1 0

Re: [2/3] oledb32: Add test for marshalling IDBProperties.
by Paul Vriens 10 Nov '09

10 Nov '09

On 11/07/2009 01:29 PM, Rob Shearman wrote: > --- > dlls/oledb32/tests/Makefile.in | 5 +- > dlls/oledb32/tests/marshal.c | 272 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 275 insertions(+), 2 deletions(-) > create mode 100644 dlls/oledb32/tests/marshal.c > Hi Rob, The test results for these new tests don't look too great: http://test.winehq.org/data/tests/oledb32:marshal.html Could you have a look? -- Cheers, Paul.

1 0

Infinite loop with translation DLL
by Uwe Bonnes 10 Nov '09

10 Nov '09

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 10 Nov '09

10 Nov '09

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 10 Nov '09

10 Nov '09

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

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