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

Re: loader: Add Polish translation

by Frédéric Delanoy

2011/6/3 Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com>: > --- > loader/wine.pl.man.in | 327 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 327 insertions(+), 0 deletions(-) > create mode 100644 loader/wine.pl.man.in > > diff --git a/loader/wine.pl.man.in b/loader/wine.pl.man.in > new file mode 100644 > index 0000000..e4a14a8 > --- /dev/null > +++ b/loader/wine.pl.man.in > @@ -0,0 +1,327 @@ > +.\" -*- nroff -*- > +.TH WINE 1 "June 2011" "@PACKAGE_STRING@" "Windows On Unix" That line is not translated Also, you might want to alter the Makefile.in for install/uninstalls Frédéric

June 4, 2011

Re: dinput: Added a check for NULL callback in EnumDevices.

by Vitaliy Margolen

On 06/03/2011 04:19 PM, Lucas Fialho Zawacki wrote: > In the absence of this check apps passing a NULL pointer as callback to > EnumDevices segfault under Wine. Do you have an example of such application? And the bug in bugzilla? Vitaliy.

June 3, 2011

Re: [2/2] explorer: add a navbar to explorer

by Juan Lang

Hi Jay, +static const WCHAR ForwardButtonName[] = {'F','o','w','a','r','d','\0'}; Misspelled. --Juan

June 3, 2011

Re: [1/2] explorer: implement the explorer using IExplorerBrowser

by Juan Lang

Hi Jay, +static void MakeExplorerWindow(IShellFolder* startFolder, HINSTANCE hInstance) I know the general rule of thumb when modifying an existing file is to keep its style, but we also tend to stay away from this style of function naming. It looks too much like the functions could be Win32 API names. Preferred style is the "one true style" of function naming, e.g. make_explorer_window instead. As it happens, explorer.c is the odd man out in programs/explorer, and since it only has 4 functions at the moment, it's probably better to change them than to add more functions with this style. Thanks, --Juan

June 3, 2011

Re: [PATCH 1/4] winealsa.drv: Partially implement IAudioSessionManager2

by Andrew Eikum

On 06/03/2011 05:10 PM, Joris Huizer wrote: > I'm sorry if I'm wrong, but it seems to me in this and following > patches, the AudioSessionManager_Release() function is incomplete - I > think the dealing with ref == 0 is missing. Shoot, you're right. That's what I get for sending patches late on a Friday afternoon... I'll get that patched up on Monday. Thanks, Andrew

June 3, 2011

Re: [PATCH 1/4] winealsa.drv: Partially implement IAudioSessionManager2

by Joris Huizer

I'm sorry if I'm wrong, but it seems to me in this and following patches, the AudioSessionManager_Release() function is incomplete - I think the dealing with ref == 0 is missing. HTH, Joris

June 3, 2011

WineConf 2011 - Minneapolis, MN - October 1,2

by Jeremy White

Hi Folks, We have made arrangements for this year's WineConf to happen in Minneapolis, MN on Saturday October 1 and Sunday October 2. Minneapolis is the little known other city of the Twin Cities across the river from our home town, St. Paul. I've put some preliminary information up on the Wiki: http://wiki.winehq.org/WineConf2011 We thought that this year it would be fun to stay in downtown Minneapolis, as there is quite a bit to do there. Further, at that time of year, the weather has a good chance of being beautiful, so it will hopefully be a great time for all. I checked, and only very rarely has it been below freezing on October 1 <evil grin>. (Seriously, it's usually very nice. Really. Trust me). If you are interested in WineConf, and have contributed to Wine, but are not sure if you can afford the travel costs, please write to me. The Wine Party fund is used mostly to defray travel costs these days and we may be able to help. Note that most further communication will happen on the wineconf(a)winehq.org mailing list; if you're interested, you should subscribe. If you're coming, please hit the RSVP page: http://www.winehq.org/wineconf/rsvp/ Hope to see you in Minneapolis! Cheers, Jeremy

June 3, 2011

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

by Adam Martinson

On 06/03/2011 03:06 PM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote: >>> Adam Martinson<amartinson(a)codeweavers.com> wrote: >>> >>>> 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. >>> I'd suggest to write some tests and try to understand what does Windows >>> and at which step. >>> >> I don't know of any way to do this with the current testing framework, >> and I think the apps that require it (DNS7 is the only one I know of) >> give us a clear enough picture. If there are other apps that need >> specific things out of this kind of behavior then I'll try to figure >> out some way to incorporate it in the tests. > There's absolutely no reason for that flag to be inherited across > processes. You can't just try things at random until they happen to fix > your app, particularly not when the result is such a horrible mess. That > should be a hint that there's something wrong with your hypothesis. > Alright, I'll do some more research before going further.

June 3, 2011

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

by Adam Martinson

On 06/03/2011 02:36 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >>>> 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. >>> I'd suggest to write some tests and try to understand what does Windows >>> and at which step. >>> >> I don't know of any way to do this with the current testing framework, >> and I think the apps that require it (DNS7 is the only one I know of) >> give us a clear enough picture. If there are other apps that need >> specific things out of this kind of behavior then I'll try to figure out >> some way to incorporate it in the tests. > Start with writing a simple Windows app that replicates what DNS/IS6 are > doing. > Alright, I'll see what I can come up with over the weekend. >> Ah, I thought you were talking about >> <http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx>, so >> I was trying to figure out how to exclude system processes if it was >> called by an app process, etc, which seems like a reasonable thing to >> do. Attached is a version which should appropriately limit the scope. > You don't understand, it doesn't matter what DLLs are loaded in other > processes, that shouldn't have any influence on address space limitations > in current process. > No, I mean the process tree was something like wine-preloader -> DNS7 setup -> IS6. No point in checking system processes here, tho I think all of Wine's binaries set IMAGE_FILE_LARGE_ADDRESS_AWARE. What you're saying is correct, but we're talking about different things.

June 3, 2011

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

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote: >> Adam Martinson<amartinson(a)codeweavers.com> wrote: >> >>> 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. >> I'd suggest to write some tests and try to understand what does Windows >> and at which step. >> > I don't know of any way to do this with the current testing framework, > and I think the apps that require it (DNS7 is the only one I know of) > give us a clear enough picture. If there are other apps that need > specific things out of this kind of behavior then I'll try to figure > out some way to incorporate it in the tests. There's absolutely no reason for that flag to be inherited across processes. You can't just try things at random until they happen to fix your app, particularly not when the result is such a horrible mess. That should be a hint that there's something wrong with your hypothesis. -- Alexandre Julliard julliard(a)winehq.org

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: > >> 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. > > I'd suggest to write some tests and try to understand what does Windows > > and at which step. > > > I don't know of any way to do this with the current testing framework, > and I think the apps that require it (DNS7 is the only one I know of) > give us a clear enough picture. If there are other apps that need > specific things out of this kind of behavior then I'll try to figure out > some way to incorporate it in the tests. Start with writing a simple Windows app that replicates what DNS/IS6 are doing. > Ah, I thought you were talking about > <http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx>, so > I was trying to figure out how to exclude system processes if it was > called by an app process, etc, which seems like a reasonable thing to > do. Attached is a version which should appropriately limit the scope. You don't understand, it doesn't matter what DLLs are loaded in other processes, that shouldn't have any influence on address space limitations in current process. -- Dmitry.

June 3, 2011

Re : Re : ddraw: Add tests for Setcooperativelevel

by paulo lesgaz

Any reason it was not commited yet? A+ David ________________________________ De : paulo lesgaz <jeremielapuree(a)yahoo.fr> À : Stefan Dösinger <stefandoesinger(a)gmx.at>; wine-devel(a)winehq.org Envoyé le : Mer 1 juin 2011, 20h 37min 36s Objet : Re : ddraw: Add tests for Setcooperativelevel ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : wine-devel(a)winehq.org Cc : paulo lesgaz <jeremielapuree(a)yahoo.fr> Envoyé le : Mer 1 juin 2011, 15h 11min 25s Objet : Re: ddraw: Add tests for Setcooperativelevel On Wednesday 01 June 2011 08:01:57 paulo lesgaz wrote: >> Hi, >> >> any problem with the patch >> >> http://source.winehq.org/patches/data/74702 >I guess Alexandre was waiting for a reply from me or Henri. > >The tests themselves look ok, but I wonder what your ultimate goal is - is >there a game that has issues with DDSCL_CREATEDEVICEWINDOW? Yes, see bug 25660 My tests prove that DDSCL_CREATEDEVICEWINDOW+DDSCL_EXCLUSIVE+DDSCL_FULLSCREEN is allowed with a NULL window. That is what expected by Half life I demo. Currently, Wine returns DDERR_INVALIDPARAMS. Obviously, there are already tests that prove that DDSCL_EXCLUSIVE+DDSCL_FULLSCREEN fails with a null window. > Also the tests we >have are somewhat unsatisfying, we don't have a single test where >DDSCL_CREATEDEVICEWINDOW is supposed to succeed. Maybe it would be the subject of an another patch? A+ David

June 3, 2011

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

by Adam Martinson

On 06/03/2011 01:33 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> 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. > I'd suggest to write some tests and try to understand what does Windows > and at which step. > I don't know of any way to do this with the current testing framework, and I think the apps that require it (DNS7 is the only one I know of) give us a clear enough picture. If there are other apps that need specific things out of this kind of behavior then I'll try to figure out some way to incorporate it in the tests. >> 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. > Processes can't share their address spaces (using a shared memory mapping > doesn't count) with other processes, if they would do, you certainly would > be willing to use a different OS. > Ah, I thought you were talking about <http://msdn.microsoft.com/en-us/library/aa366912%28v=vs.85%29.aspx>, so I was trying to figure out how to exclude system processes if it was called by an app process, etc, which seems like a reasonable thing to do. Attached is a version which should appropriately limit the scope.

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: > 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. I'd suggest to write some tests and try to understand what does Windows and at which step. > 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. Processes can't share their address spaces (using a shared memory mapping doesn't count) with other processes, if they would do, you certainly would be willing to use a different OS. -- Dmitry.

June 3, 2011

Re:o

by Nick Burns

http://www.sisco.ch/indexz35X.php

June 3, 2011

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