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

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus(). (try 2)

by Adam Martinson

On 06/03/2011 09:14 AM, Adam Martinson wrote: > On 06/03/2011 03:41 AM, Dmitry Timoshkov wrote: >> Adam Martinson<amartinson(a)codeweavers.com> wrote: >> >>> Your previous quesion: >>> > How do the processes running in separate address spaces have >>> anything >>> to do with that? >>> >>> I thought I addressed that with this version of the patch, but if I'm >>> not checking address space correctly, please tell me the correct way. >>> PEB::InheritedAddressSpace doesn't work, I'm not sure what else I >>> should >>> be looking for. >> Fortunately win32 is not DOS. >> > Unfortunately that doesn't answer my question =P > > The issue is that Dragon NaturallySpeaking 7 setup doesn't have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but it uses InstallShield 6 as a child process, which does have it set. IS6 calls GlobalMemoryStatus() and passes the data back to DNS7 setup, and if you have more than 2GB RAM DNS7 setup thinks you have negative memory. Windows figures this out and rounds to 2GB, Wine does not. The unset IMAGE_FILE_LARGE_ADDRESS_AWARE flag is not inherited by the child process (I did check), so this leads me to believe Windows must be doing some sort of check like this when deciding to round. If there is a flaw in my logic or there is a better way to do this I am all ears.

June 3, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus(). (try 2)

by Adam Martinson

On 06/03/2011 03:41 AM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> Your previous quesion: >> > How do the processes running in separate address spaces have anything >> to do with that? >> >> I thought I addressed that with this version of the patch, but if I'm >> not checking address space correctly, please tell me the correct way. >> PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should >> be looking for. > Fortunately win32 is not DOS. > Unfortunately that doesn't answer my question =P

June 3, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx(). (resend)

by Adam Martinson

On 06/03/2011 03:37 AM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> The stuff in that block is for win2k+ mode only. Win9x doesn't add >> [Total|Avail]Phys to [Total|Avail]PageFile. If wine is in win9x mode it >> should behave like win9x, or it confuses old apps. This is needed for >> the 2nd patch, IIRC removing the photoshop 4 hack in >> GlobalMemoryStatus() screws up programs like Adobe Illustrator 8 in >> win98 mode without it. > You probably need to do what not Ex version does and merge both implementations. > I don't think merging the implementations makes sense in this case, the only difference is 32-bit vs 64-bit output values. GlobalMemoryStatusEx() handles the basic behavior, GlobalMemoryStatus() handles rounding, I don't see a compelling reason to change that.

June 3, 2011

Re: [PATCH 3/3] msvcrt: Improved tolower_l and toupper_l implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11457 Your paranoid android. === WNT4WSSP6 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === W2KPROSP4 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === WXPPROSP3 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === W2K3R2SESP2 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0

June 3, 2011

Re: [4/4] ws2_32: Avoid a crash with an optional pointer in WSAAsyncGetServByName.

by Andrew Nguyen

On 06/01/2011 11:09 AM, Alexandre Julliard wrote: > Andrew Nguyen <anguyen(a)codeweavers.com> writes: > >> On 06/01/2011 07:39 AM, Marvin wrote: >>> === WXPPROSP3 (32 bit sock) === >>> sock.c:501: Test failed: oob_server (218): unexpectedly at the OOB mark: 0 >>> sock.c:511: Test failed: oob_server (218): unexpectedly at the OOB mark: 0 >> >> The test failure is not related to my changes. > > I'm also seeing some random crashes here. For instance: > I sent two patches that fixed some questionable code within the sock tests, but now the tests just crash on the WXPPROSP3 test VM, which I'll have to investigate further.

June 3, 2011

mmdevapi buffering

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum wrote: >Then, GetCurrentPadding() returns "write - read" and GetBufferSize() returns the queue size limit. >As far as I can tell, this is entirely consistent with how Windows behaves. I added some lines to mmdevapi/tests/render.c to find out more about mmdevapi with the help of testbot. Here's a summary of the findings. - GetBuffer(SamplesPerSec/2) =0.5s worth of samples succeeds, i.e. huge buffers are supported (mmdevapi/tests/render.c:test_clock) - GetCurrentPadding increases from 0 by frames_written while the stream is not yet started (mmdevapi/tests/render.c:test_padding). -- That's what the tests already in Wine showed me. - After Initialize(duration=0.5s), 0.5s is the hard limit on how much you can feed into the engine (*both* in one call or split in two parts). I.e. the app will never be 2s in advance over the engine because it cannot write 4 x 0.5s. (More precisely, MSDN says the size is at least what was asked for and GetBufferSize yields the actual size.) - IAudioClock_GetPosition "arbitrary" units look like bytes. (MSDN says "e.g. bytes"). Position/GetFrequency yields seconds. - GetCurrentPadding appears to decrease by multiples of 10ms as time advances (sleep), e.g. by 4800 +/- 480 after sleep(100ms). Hence it is not related to a HW position pointer. Once started, GetCurrentPadding decreases in amounts directly proportional to elapsed time. Unlike Wine, it is *not* the case that it would decrease a lot when you feed it a lot. Omitting underruns, we can summarize as follows: GetCurrentPadding = ( sum(written) - (rate / playtime - late modulo 10ms) ) modulo GetBufferSize where <late> accounts for a little setup time after Start. - IAudioClock_GetPosition does not reveal a multiplicator, hence it could be related to either HW position or linear time, but not the 10ms chunks. To me, GetCurrentPadding clearly reasons it terms of the "front stage", i.e. the 10ms chunks that it feeds into the audio engine, regardless of how much the engine played. OTOH, GetPosition retrieves either an actual "back stage" HW position or simply returns wall clock time (MSDN says about GetPosition that high performance time and position "correlate" - as if it expresses time in "position" units, e.g. bytes - yet also "the sample currently playing through the speakers" - truly a HW position). - GetBuffer appears to use one main and one secondary buffer. The second one can hold at least as much as GetBufferSize * 15/16th. These buffers are not treated equally, e.g. no ping pong; the main one is used preferably, with varying offsets into it. - Native may copy data written to the secondary buffer somewhere else (GetBuffer returned the same pointer twice in a row with not enough time elapsed for the previously written data to be processed by HW). I'm unsure whether using one internal buffer of size 2xGetBufferSize would be enough to avoid copying (2x size resembles exclusive mode's ping pong). What was not tested: - native machine instead of testbot's vmware - rendering mode other than shared with 500ms duration - repeated start/stop - SetEvent - power suspend/resume (impossible with testbot) - CPU frequency scaling (not possible with vmware?) - duration of each call -- which one takes a long time to return, what is delegated to concurrent threads? - listening to sound -- only playing silence I believe reproducing timing is as important for Wine as producing the same functional output as native given some input. How does Wine differ? Compare testbot job 11396 with Wine's output below. - Given a 0.5s buffer, Wine accepts 4 times nearly GetBufferSize frames within 650ms. Native accepts that at most twice (0.5 prefill, then another nearly 0.5s fits within 0.650s playtime, e.g. after playing for 450ms). - Wine's GetCurrentPadding returns 0 three times after Start, ignoring the huge amount of data written so far. 0 => "can write GetBufferSize frames". - Wine's GetCurrentPadding was != 0 only after 500ms of playtime. - Wine's GetPosition is highly non-linear, initially incrementing by 22500 within 100ms, later only 4310-5000. This looks more like a fill pointer than actual play position or clock time. - I suggest having Wine's GetPosition return bytes too, not samples. render.c:565: Clock Frequency 48000 render.c:583: data at 0x12beb0 render.c:590: padding 24000 prior to start render.c:621: padding 0 past sleep #2 render.c:628: padding 0 past stop #1 render.c:634: position 24000 render.c:650: data at 0x12beb0 render.c:657: padding 24000 past reset+write render.c:672: position 24000 render.c:679: padding 0 past stop #2 render.c:684: position 24000 render.c:698: data at 0x12beb0 to fill (large 22500, 15/16 of 24000) render.c:710: hpctime 353 after 350ms - QueryPerformanceCounter render.c:722: padding 0 position 22500 iteration 0 render.c:730: data at 0x12beb0 (large 22500) render.c:743: hpctime 454ms render.c:722: padding 0 position 45000 iteration 1 render.c:730: data at 0x12beb0 (large 22500) render.c:743: hpctime 555ms render.c:722: padding 0 position 67500 iteration 2 render.c:730: data at 0x12beb0 (large 22500) render.c:743: hpctime 653ms render.c:722: padding 6119 position 83881 iteration 3 render.c:727: Test failed: GetBuffer large (22500) failed: 88890006 render.c:737: data at 0x12beb0 (small 17881) render.c:743: hpctime 755 render.c:722: padding 19690 position 88191 iteration 4 render.c:727: Test failed: GetBuffer large (22500) failed: 88890006 render.c:737: data at 0x12beb0 (small 4310) render.c:743: hpctime 853 render.c:722: padding 18732 position 93459 iteration 5 render.c:727: Test failed: GetBuffer large (22500) failed: 88890006 render.c:737: data at 0x12beb0 (small 5268) render.c:743: hpctime 954 render.c:722: padding 19691 position 97768 iteration 6 render.c:727: Test failed: GetBuffer large (22500) failed: 88890006 render.c:737: data at 0x12beb0 (small 4309) Regards, Jörg Höhle

June 3, 2011

Re: [1/5] wined3d: Add support for GL_ARB_timer_query.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd recommend to wait for Henri to return from vacation before applying these Am 02.06.2011 um 19:25 schrieb Adam Martinson: > --- > dlls/wined3d/directx.c | 1 + > dlls/wined3d/wined3d_gl.h | 19 +++++++++++++++++++ > 2 files changed, 20 insertions(+), 0 deletions(-) > > > <0002-wined3d-Add-support-for-GL_ARB_timer_query.patch> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN6KyMAAoJEN0/YqbEcdMw+doP/jwoZxrZSkkgguKyN0MKlpNl BaYc2Yc3uGdNrOLCk78X/Zu1otVVlNZJHR5xIID3ZaK0egjhHRXF7Ljhj36paduN u25lslD4iN1IRHocDm0C0IqmmX5Q8YMrGSf1Xxn19KFaWV7tTHqs5KE4Dz707lct 0R/doxjYyZ4uBiE9FIglnPm2DZsyZoi5RPlYZA2XSD5uC57hD8hdqQPmLGXw+O42 WpjvNsN+hDwghJOEBCyG93rsttU7Zb9CBAQJS/CqYegG0L6cbRAZHebj/kHgWT7M 4TBNlo0rElgcD3/2CXNK1jjDSvAKS1soicnv7ZtlKbbmEHPE4EaQ82giIkqJB2Vv NddGTh9JvINLVq8FBJwRs9CwAMhVjUeGvrI13tnSUSu4QdcMZ9fxlg2SIeslWNrB x34siT+Eo8hOY6ZP6nTbdScSoxkHvOm4T8xeGKgC0l+sdAdAP18sHV1SgwoSLth/ fk68H6j6unL2S5yaQmIwaC+EKLRQkG+/wlsoFltR0iOplsxYKtm7KvYet6UAQNol Pq7Z1d7KLlg7GnsKgcFVVtXXNgEcKaEchuxUzRKkQy46MbQsghJhDW4mr+8vGwNS bFWf2qxHP0D8b/VnK43tsIAoXb5iA92yAlrC0e3ssy2yMdjS3SiFvwOBQsMtqBrD V0X2LrLXsqM1n00U6mPN =1nqX -----END PGP SIGNATURE-----

June 3, 2011

winealsa.drv:mmdevapi input validation

by Joerg-Cyril.Hoehle＠t-systems.com

Andrew Eikum wrote: >Frankly, I see little reason to spend time implementing special handling >of exclusive mode unless we find an app that does something that requires it. Actually, I don't know whether any of the apps I own can use mmdevapi. I've been looking at it because I believe you are going to rewrite winmm to use it. >> if (AUDCLNT_STREAMFLAGS_EVENTCALLBACK&& SHAREMODE_EXCLUSIVE) >> { FIXME("unsupported")& return E_ } >Is it really better to outright fail on that combination instead of >having a (probably quite good) chance at just working? I fear it's quite low given the precise description that MSDN makes of the ping pong mode. That does not happen by chance. I suppose few apps will depend on exclusive mode because MSDN says that the user decides whether to grant it or not. At most, it'll be an option within an app's menu. Regards, Jörg

June 3, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus(). (try 2)

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > Your previous quesion: > > How do the processes running in separate address spaces have anything > to do with that? > > I thought I addressed that with this version of the patch, but if I'm > not checking address space correctly, please tell me the correct way. > PEB::InheritedAddressSpace doesn't work, I'm not sure what else I should > be looking for. Fortunately win32 is not DOS. -- Dmitry.

June 3, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx(). (resend)

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > The stuff in that block is for win2k+ mode only. Win9x doesn't add > [Total|Avail]Phys to [Total|Avail]PageFile. If wine is in win9x mode it > should behave like win9x, or it confuses old apps. This is needed for > the 2nd patch, IIRC removing the photoshop 4 hack in > GlobalMemoryStatus() screws up programs like Adobe Illustrator 8 in > win98 mode without it. You probably need to do what not Ex version does and merge both implementations. -- Dmitry.

June 3, 2011