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

Re: wined3d performance patches

by Matteo Bruni

2011/6/6 Stefan Dösinger <stefandoesinger(a)gmx.at>: ... > Furthermore, Matteo says that not calling context_apply_draw_buffers every > time framebuffer() is run is a noticeable performance improvement too. Matteo, > did you test this with just patch 0005, or both 0005 and 0006? > Actually that was with your FBO dirty patches from your previous wined3d performance wine-devel email, so it should more or less match what happens with your current 0005 + 0006 patches (I didn't recheck with the newer ones though). I got a small but measurable (1 - 1.5%) overall improvement in d3d9 performances, so it looked to me like it is something worth optimizing.

June 6, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). (try 4 resend)

by Adam Martinson

On 06/06/2011 10:58 AM, Michael Stefaniuc wrote: > Hello Adam, > > Adam Martinson wrote: >> This is to work around apps which break COM rules by not implementing > you need to follow the Wine COM guidelines: > http://wiki.winehq.org/COMGuideline > >> IDropTarget::QueryInterface(). Windows doesn't expose this because it >> doesn't call CoMarshallInterface() in RegisterDragDrop(). >> >> Fixes bug 23861. >> --- >> dlls/ole32/ole2.c | 122 >> +++++++++++++++++++++++++++++++++++++++--- >> dlls/ole32/tests/dragdrop.c | 2 +- >> 2 files changed, 114 insertions(+), 10 deletions(-) >> Thanks, I'll take a look.

June 6, 2011

Re: [3/3] kernel32/heap: Add registry caps for reported memory. (resend)

by Andrew Nguyen

On 06/06/2011 11:03 AM, Adam Martinson wrote: > + /* Only check this once */ > + if (!cache_lastchecked) > + { > + HMODULE hadvapi32 = LoadLibraryA("advapi32.dll"); > +#define ADVAPI32_GET_PROC(func) typeof(func) * p ## func = (void*)GetProcAddress(hadvapi32, #func) > + ADVAPI32_GET_PROC(RegOpenKeyExA); > + ADVAPI32_GET_PROC(RegCloseKey); > + ADVAPI32_GET_PROC(RegGetValueA); I think you want to use NtCreateKey and NtQueryValueKey instead of dynamically loading advapi32 for registry functionality.

June 6, 2011

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

by Juan Lang

> GetVersionEx() is used in GlobalMemoryStatus() also, after these are in I'll > pull it out and make it static, and then just do it once and use it for > both. Okay, thanks. Unrelated nit on patch 3/3: + lpmemex->ullTotalVirtual = min((ULONG_PTR)si.lpMaximumApplicationAddress-(ULONG_PTR)si.lpMinimumApplicationAddress, ullTotalVirtualMax); /* FIXME: we should track down all the already allocated VM pages and subtract them, for now arbitrarily remove 64KB so that it matches NT */ This line is too long, please place the comment on a line by itself. Thanks, --Juan

June 6, 2011

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

by Adam Martinson

On 06/06/2011 11:02 AM, Juan Lang wrote: >> Ha! Quite right, thanks! > If that's what you want, then an easier check is to use GetVersion() > rather than GetVersionEx. (GetVersion()& 0x80000000) is true under > Win9x, false under any NT version. See many checks like this in e.g. > kernel32. > --Juan GetVersionEx() is used in GlobalMemoryStatus() also, after these are in I'll pull it out and make it static, and then just do it once and use it for both.

June 6, 2011

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

by Juan Lang

> Ha! Quite right, thanks! If that's what you want, then an easier check is to use GetVersion() rather than GetVersionEx. (GetVersion() & 0x80000000) is true under Win9x, false under any NT version. See many checks like this in e.g. kernel32. --Juan

June 6, 2011

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

by Adam Martinson

On 06/06/2011 10:50 AM, Juan Lang wrote: >> In NT4 mode: >> (osver.dwMajorVersion>= 5) is FALSE. >> (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) is TRUE. >> (osver.dwMajorVersion>= 5 || osver.dwPlatformId != >> VER_PLATFORM_WIN32_WINDOWS) is TRUE. >> Right? > Ah, right. Wrong with this comment, sorry about that. But my > original comment remains: why not just check dwPlatformId? > --Juan Ha! Quite right, thanks!

June 6, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). (try 4 resend)

by Michael Stefaniuc

Hello Adam, Adam Martinson wrote: > This is to work around apps which break COM rules by not implementing you need to follow the Wine COM guidelines: http://wiki.winehq.org/COMGuideline > IDropTarget::QueryInterface(). Windows doesn't expose this because it > doesn't call CoMarshallInterface() in RegisterDragDrop(). > > Fixes bug 23861. > --- > dlls/ole32/ole2.c | 122 > +++++++++++++++++++++++++++++++++++++++--- > dlls/ole32/tests/dragdrop.c | 2 +- > 2 files changed, 114 insertions(+), 10 deletions(-) >

June 6, 2011

wined3d performance patches

by Stefan Dösinger

Hi, This is intended mostly for the other d3d developers, but since we have quite a number of them now so individual CCs are a lot of work :-) I attached the patches I currently have in my tree to give an update on what I've been working on recently. The main aim of those patches is to reduce draw overhead a bit, thus improving game performance. The patches need some cleanup, but for that I first need a patch Matteo is working on. Feedback is welcome. I'm also interested in test results, e.g. if the changes break a game, or the performance impact. If those patches cause a 5% performance increase I am happy. Patches 1-3: Mostly unrelated. I haven't sent them yet because patch 3 breaks Unigine Heaven, and patches 1 and 2 make little sense without 3. Patch 4: This removes a hack for a driver bug workaround. I have to do more testing on my old machines to find out if the bug is really fixed in newer nvidia drivers. Patches 5, 6: They keep track of changes to the framebuffer setup so we don't have to run through the code that figures out which FBO to bind every draw. Patch 5 gets rid of the ordering assumption. Patch 6 applies the FBO only when needed. They aren't ready yet. In patch 6 the FBO may have to be reapplied when the pixelshader changes. To implement that I need some draw buffer tracking infrastructure Matteo is working on. Also clears can be integrated. fbo- clear.diff is a half-baked attempt to do this. I dropped it when I realized I was duplicating Matteos work. After that I have to double-check that I took care of all situations where the FBO may have to be updated. Furthermore, Matteo says that not calling context_apply_draw_buffers every time framebuffer() is run is a noticeable performance improvement too. Matteo, did you test this with just patch 0005, or both 0005 and 0006? Patch 0007: Sampler map optimization, it has a lengthy description in the patch file Patch 0008: A tiny fix, it results in a pretty small improvement on OSX. On Linux+Nvidia it is not noticeable. Patch 0009: At first I tried to skip the render target dirtification entirely via a flag in the d3ddevice, but it was pretty tricky and ugly. Just making it cheaper gets us ~2/3rd of the way too. (Draw overhead tester performance without this: 259 fps. Complete disabling of the dirtification calls via a hack: 275. With this patch: 269) 0010: An unrelated cleanup Patches 11, 12: Preparation for including clears in the fbo dirtification patches. See fbo-clear.diff. More work on performance is obviously required, for example *) Separate vertex declaration, vertex shader and pixel shader states *) Speed up sampler preloading. This will be easier once we have a tree-like state structure. *) Write more tests for other common operations, like clears, blits, shader changes, texture changes, vertex buffer changes, dynamic resource loading *) Test our shader's GPU-side execution performance *) See if we can do something about locking *) Isolate bottlenecks in the GPU drivers and get them fixed.

June 6, 2011

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

by Juan Lang

> In NT4 mode: > (osver.dwMajorVersion>= 5) is FALSE. > (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) is TRUE. > (osver.dwMajorVersion>= 5 || osver.dwPlatformId != > VER_PLATFORM_WIN32_WINDOWS) is TRUE. > Right? Ah, right. Wrong with this comment, sorry about that. But my original comment remains: why not just check dwPlatformId? --Juan

June 6, 2011

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

by Adam Martinson

On 06/06/2011 10:45 AM, Juan Lang wrote: >> I'm removing part of the comment because it no longer applies. We're not >> just using the XP behavior for everything anymore, now we're using the 9x >> behavior when it's appropriate. > When is it appropriate, and when not? I don't know, and your patch > doesn't explain that. See below for more on why it's confusing. > >> if (osver.dwMajorVersion>= 5 || osver.dwPlatformId == >> VER_PLATFORM_WIN32_NT) >> would be equivalent. The stuff in that block is only for NT/2k+. In 9x >> more we *don't* do that. > Let me say it again: the condition you've written doesn't return TRUE > when running NT4 mode. Why is that, and what's that got to do with > Win9x? If this wasn't intended, then your check if wrong. If it was, > then the commit message is wrong. In either case, something is wrong > with your patch as it is. > --Juan In NT4 mode: (osver.dwMajorVersion>= 5) is FALSE. (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) is TRUE. (osver.dwMajorVersion>= 5 || osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) is TRUE. Right?

June 6, 2011

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

by Juan Lang

> I'm removing part of the comment because it no longer applies. We're not > just using the XP behavior for everything anymore, now we're using the 9x > behavior when it's appropriate. When is it appropriate, and when not? I don't know, and your patch doesn't explain that. See below for more on why it's confusing. > if (osver.dwMajorVersion >= 5 || osver.dwPlatformId == > VER_PLATFORM_WIN32_NT) > would be equivalent. The stuff in that block is only for NT/2k+. In 9x > more we *don't* do that. Let me say it again: the condition you've written doesn't return TRUE when running NT4 mode. Why is that, and what's that got to do with Win9x? If this wasn't intended, then your check if wrong. If it was, then the commit message is wrong. In either case, something is wrong with your patch as it is. --Juan

June 6, 2011

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

by Adam Martinson

On 06/06/2011 10:23 AM, Juan Lang wrote: > Hi Adam, > perhaps I'm just being obtuse, but I don't see how Dmitry's comment > has been addressed for this patch. I'm confused by the commit comment > ("Emulate Win9x if appropriate") and the change itself: > > /* Win98 returns only the swapsize in ullTotalPageFile/ullAvailPageFile, > WinXP returns the size of physical memory + swapsize; > - mimic the behavior of XP. > > You are removing the part of the comment explaining what the code > actually does, which I find confusing. If you're part of the "the > code is the documentation" crowd, just remove the entire comment. If > not, please add a brief explanation. > I'm removing part of the comment because it no longer applies. We're not just using the XP behavior for everything anymore, now we're using the 9x behavior when it's appropriate. > Note: Project2k refuses to start if it sees less than 1Mb of free swap. > */ > - lpmemex->ullTotalPageFile += lpmemex->ullTotalPhys; > - lpmemex->ullAvailPageFile += lpmemex->ullAvailPhys; > - > - /* Titan Quest refuses to run if TotalPageFile<= ullTotalPhys */ > - if(lpmemex->ullTotalPageFile == lpmemex->ullTotalPhys) > + if (osver.dwMajorVersion>= 5 || osver.dwPlatformId != > VER_PLATFORM_WIN32_WINDOWS) > > This change is confusing to me. dwPlatformId == VER_PLATFORM_WIN32_NT > for NT4, Win2k, XP, etc. dwMajorVersion is never greater than 4 on > Windows 9x. In other words, do you mean to exclude NT4 here, or not? > If so, then the first check should suffice. If not, then the second > check should. But in either case, what does this have to do with > being "appropriate" for Win9x emulation? > --Juan if (osver.dwMajorVersion >= 5 || osver.dwPlatformId == VER_PLATFORM_WIN32_NT) would be equivalent. The stuff in that block is only for NT/2k+. In 9x more we *don't* do that.

June 6, 2011

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

by Juan Lang

Hi Adam, perhaps I'm just being obtuse, but I don't see how Dmitry's comment has been addressed for this patch. I'm confused by the commit comment ("Emulate Win9x if appropriate") and the change itself: /* Win98 returns only the swapsize in ullTotalPageFile/ullAvailPageFile, WinXP returns the size of physical memory + swapsize; - mimic the behavior of XP. You are removing the part of the comment explaining what the code actually does, which I find confusing. If you're part of the "the code is the documentation" crowd, just remove the entire comment. If not, please add a brief explanation. Note: Project2k refuses to start if it sees less than 1Mb of free swap. */ - lpmemex->ullTotalPageFile += lpmemex->ullTotalPhys; - lpmemex->ullAvailPageFile += lpmemex->ullAvailPhys; - - /* Titan Quest refuses to run if TotalPageFile <= ullTotalPhys */ - if(lpmemex->ullTotalPageFile == lpmemex->ullTotalPhys) + if (osver.dwMajorVersion >= 5 || osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS) This change is confusing to me. dwPlatformId == VER_PLATFORM_WIN32_NT for NT4, Win2k, XP, etc. dwMajorVersion is never greater than 4 on Windows 9x. In other words, do you mean to exclude NT4 here, or not? If so, then the first check should suffice. If not, then the second check should. But in either case, what does this have to do with being "appropriate" for Win9x emulation? --Juan

June 6, 2011

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

by Adam Martinson

On 06/03/2011 03:29 PM, Adam Martinson wrote: > 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. > > I'm sure this isn't a surprise, but looks like my premise was wrong: <http://nuance.custhelp.com/app/answers/detail/a_id/3784/~/installation-retu…>. Since Windows doesn't figure it out I guess we don't need to either xD We can probably use the same workaround as for Photoshop 4 in 3/3.

June 6, 2011

Re: [PATCH 9/9] ddraw: Separate IDirectDrawSurface4 vtable.

by Jesse Allen

2011/6/6 Ričardas Barkauskas <rbarkauskas(a)codeweavers.com>: > This patch is quite big, but unfortunately I again have no idea how I > could split this properly. Suggestions are welcome. > > Ričardas Barkauskas > REalm > > I don't know how to make it any more straight forward than this. We need to split out IDirectDrawSurface4. Are you going to continue to do test work on this version of DDraw surface? Jesse

June 6, 2011

Re: [PATCH 1/5] wined3d: Don't clamp vertex depth values.

by Henri Verbeet

On 6 June 2011 10:18, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> We may need it for D3DUSAGE_DONOTCLIP vertex buffers, so I kept the >> extension for the moment. > OK. Do you have a test for this or plan to write one? Otherwise I can do that the next time I boot Windows. > I was going to wait for an actual application to use it, but if you can write a test that's fine.

June 6, 2011

mmdevapi/tests: Fix wrong buffer unit and memory leaks.

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

Hi, >* nBlockAlign is wrong since data is counted in frames, not bytes. I forgot to comment that I introduced the 10x multiplicator to convince myself that GetData accepts buffer sizes larger than the default 10ms chunk returned by GetDevicePeriod. That is reasonable, but not guaranteed when I read MSDN (the API would work with small buffers too). Regards, Jörg Höhle

June 6, 2011

Re: [PATCH 1/5] wined3d: Don't clamp vertex depth values.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 06.06.2011 um 09:40 schrieb Henri Verbeet: > We may need it for D3DUSAGE_DONOTCLIP vertex buffers, so I kept the > extension for the moment. OK. Do you have a test for this or plan to write one? Otherwise I can do that the next time I boot Windows. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN7I1lAAoJEN0/YqbEcdMwXikQAJdb2SaxU0EQa3AEHgH0tCRc IEUNvRpD+KPzjFlRLaXwkNyuTRnEiFznAO2/oz6uojjGzBp7gpU9h8lzg4KYXU1O 3et3rTbe/ZCAs1cyEV8z7qPdMn7/ubpm++VvLs1aIMxaCo4HTAhO69nnQQT0bzI+ ry6BIN573p7u3jySyi1hkUovsF+kfLq02u2JuGVlMdpYbLnzHpwHeZTkywv+AQzC aV6p0HovBfz5oPSzYzYANFp/Ser3IChr4ivaR3xaRiuU4C8tQFYWk9SCn1VHhHJK smSfFW6gfaon9Af/NVgtFV6ZG6Qw0kct/jguQ9cdBzJvnwYuyVo0RMOVQgT2eb2k LBMO8YYHKDZ9482q+vOu4JWDIZbVkr7C4xkfF+pu0Sc/EzHzIDr9rcdmODjmjXgd bB4LuLcf+YxkhGyXZMDjbNg54xpxjZKadOgHs+yh0vsIHcK05qcc1sYDc62eFKOH M9dB/hETO/fKdz/RPgFmyVDmgj8jQPE5jjgRjCGaJ86hgzb2vr1lUkzd9JoBSu0r aupP4uTVrtFn8CSgWb20vtLFgSVpolg60rUg/IGywBMGtGiE9aSvekS1XcRDn2H5 8o1SwRcszzzGivJRO2flIQ3X1x3I2Sl4os+H9owv/YodvyvXAbLE7/Wt2gSTeqW9 3BClLE6IiWB0Hrku5j+8 =C51I -----END PGP SIGNATURE-----

June 6, 2011

DVD/CD-ROM recognized as network drive/floppy disk on MacOS

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

Hi, perhaps I should turn this into a bug report, but I'm hoping for a quick fix. Using wine-1.3.21 on Mac OS X 10.5.8, I observed that winecfg reported a data DVD as "network drive" and a data CD-ROM as "floppy disk". An audio CD was correctly reported. This is probably caused by the recent changes in volume management? Thanks for your help, Jörg Höhle

June 6, 2011

Re: [PATCH 1/5] wined3d: Don't clamp vertex depth values.

by Henri Verbeet

On 6 June 2011 09:11, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> Since we report D3DPMISCCAPS_CLIPTLVERTS. > Do we still need GL_ARB_depth_clamp after this change? > We may need it for D3DUSAGE_DONOTCLIP vertex buffers, so I kept the extension for the moment.

June 6, 2011

Re: [PATCH 1/5] wined3d: Don't clamp vertex depth values.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 05.06.2011 um 22:48 schrieb Henri Verbeet: > Since we report D3DPMISCCAPS_CLIPTLVERTS. Do we still need GL_ARB_depth_clamp after this change? -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN7H3AAAoJEN0/YqbEcdMw5bwP/2Tne/S6K+XYvL+5snYlrA7i 8i+eADNKVT5MmUJ6F6EZNDJ/esFbU2vfmIoFMlbDZ/l5seubIz1bMjvwteEiqOPo FakpButx8UKh08aGGw/utk3uVTu44ryEnTiNrSoEmx9h2ybym7JdBb/iAEf/nb17 qxI5V4dJf2beB+RQJ88ldtghn++VpDiFOo0t+TlOAe/sDcXTrT+25JtEJF23TxkL amfzjAYEV/f8hXuji2yAU1YOoRFZPfsFOjR+0snnlmXSbMUu5jwJAb+kM0nItlKQ JJGhI4QPOoqyNrltfKmbA3OOpTiihQQ8DYnd8y3PDrzFxftbdmjOHecgIFMxAifZ bOWDlVUctocidCxwUZB83kwhXX4MRVy9iFq0vbrl8omMgnoWC/hoQvO84gLG4E/c LBsIuOl/foLUbye6kk2cPT84hyJdQK4de852dk796zKSUxivCiKEI2L84H/Gi5uO 7l7YPIV9zAeqRV5YFyNgmZsF2ROyy0wQcOx0jt6lp0FTRi2mMKv04L7pdSM/dWO5 AXX/0KDQrZgWMHT/zZzC/LUAxvtBNTezBsk8IHhGvp7yXsKaIGmBbXFpkMANTOJM yVMRwF/VJhbCZXNmAIrrL9Gim/LDp6rcFnQPTYGWe4DJJ+b9gwn6hLbSF2PSEw/Z 9Cqfg2hhtJpfqmx7sjna =5kPk -----END PGP SIGNATURE-----

June 6, 2011

testbot flakiness?

by Dan Kegel

https://testbot.winehq.org/JobDetails.pl?Key=11509 shows failures and crashes, but the nearly identical https://testbot.winehq.org/JobDetails.pl?Key=11510 does not. (The latter one just adds a call to GetProcessMemoryInfo() in the xyz() logging function.) And the failure shown by the first patch has a last error on creating the batch file of 8, ERROR_NOT_ENOUGH_MEMORY, which is suspicious. Not quite sure what's going on there.

June 5, 2011

Re: [PATCH 1/4] shell32/tests: basic tests of IKnownFolderManager

by Vincent Povirk

+ OleInitialize(NULL); Any particular reason you're using this instead of CoInitialize? I don't think there's anything wrong with it, but CoInitialize is more common. + todo_wine + ok(cat==KF_CATEGORY_FIXED, "invalid folder category: %d\n", cat); You'd be using cat uninitialized when the function is not implemented in Wine. I suggest initializing it to 0 or something. Same with redirectionCapabilities later. + ok(lstrcmpW(sWinDir, folderPath)==0, "invalid path returned: %s\n", wine_dbgstr_w(folderPath)); It might be useful to print sWinDir as well. If there's some situation where it's the right path but not quite the same string, that'd be good to know. + /* try to set new path */ + hr = IKnownFolder_SetPath(folder, 0, sTempDir); + todo_wine + ok(hr == S_OK, "setting path failed: 0x%08x\n", hr); I'd suggest making up + registering your own known folder to test this feature, rather than using a standard one. I worry someone could end up with a broken Windows install if we fail to put it back somehow.

June 5, 2011

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

by Lucas Zawacki

Ok, I didnt know and that changes everything. From now on I'll keep that in mind. Sorry for the noise. 2011/6/4 Vitaliy Margolen <wine-devel(a)kievinfo.com>: > On 06/04/2011 01:32 PM, Lucas Zawacki wrote: >>> >>> Sometimes apps depend on the crash. Since your change comes with a >>> test case, it looks reasonable to me, although you might check the >>> specific HRESULT rather than just FAILED. >> >> Exactly, it's not a crash on Windows. I'll resend it with an explicit >> test. >> >> I was thinking of this more as "janitorial" work as opposed to fixing >> a buggy app, maybe my comment worded it badly. > > AJ was explicit about such checks: unless you have an application that > breaks because of this don't add any null checks. They needlessly slowdown > Wine. And won't guard you against invalid pointer anyway. > > Vitaliy. >

June 5, 2011