February 2015 - Wine-Devel - list.winehq.org

Re: [3/6] dxgi: Add missing dxgi 1.2 structs and interfaces [try 2]
by Stefan Dösinger Feb. 13, 2015

Feb. 13, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martell, Looks pretty good, you missed two things: Am 2015-02-12 um 20:34 schrieb Martell Malone: > +interface IDXGIOutputDuplication : IDXGIObject { { placement. > + [in, out] UINT *_countmode, [in, out] UINT *mode_count; After that go ahead and resubmit patches 1-3. Again I recommend to have a look at git send-email. It's quite simple: What it essentially comes down to is adding this to wine_src/.git/config: [sendemail] from = Martell Malone <martellmalone(a)gmail.com> to = wine-patches <wine-patches(a)winehq.org> smtpserver = smtp.googlemail.com chainreplyto = false thread = false smtpencryption = tls smtpuser = martellmalone(a)gmail.com suppresscc = self The password was in my case automagically managed by the KDE keychain. Then you just do "git send-email origin". I recommend a sanity check with --dry-run first. Feels almost like pushing :-) . -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU3bobAAoJEN0/YqbEcdMwCO4P/RlJWBhdZlgs2P8uYZosElTi ofQ2gQNX3Qo53vqwVgtNsmoFyAUHcqUX5euoACeDwjoGpOIe0cJ98ON2sJHADRqa nUPNjPrh/Xo/5WYhQs04hWGRbaFQTCgS+gjuld2ePqIgnAtl880G8GCptD0elcX2 blwa5nPOcxjzaqWX/BB159oioyfWy/IFC5B55Tb7WshSxpkSwgvWkIQsaO2ttF4B 3reG4z1xvgNJZfNH2MzND+d3EJrIq2iydr9dAS4ph1biEbSnlisFR1PwlVFXI7XT CGCmJD7eSM5hU3nRFWB8stEUSumwm8IPQXpcN8PSdzjcWwXuJ1lk6t4t2IlPIuET knXI4D+4XgduVKjBGDxp75fRDL6RmwaRckTnuCLUiCVDcr+bIPHuC1FKFpGxB4Vu q8FZ4wuo4vTegZ9niwi5FPZxc86zLvh3R1qv8mugLJPGbdl+6HYz6aZVtQRXewAe nDZg5nE/DxVrzFF/Ehg9gGHtmwkQeNpxbGK+vsv+qU1sqaod7+FQeTDkfCcs/Ola /7OIdJctBmjpPUGVamVTPUlrRwVNVSboZjDgwN32uBJ/opRFR331HreGL3Aj5UZ1 1EgCcv3tKC8YgiXF7YCrft8EtZFYu/PyZZm0KSjucpGbyviPf03pfNfaj5zPrlMv k1sPLynBjlhOiOO1HRI8 =3BtO -----END PGP SIGNATURE-----

2 6

Re: comctl32: SysDateTimePick32 control add Alt+down hot key like windows
by Marvin Feb. 13, 2015

Feb. 13, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11515 Your paranoid android. === w2000pro (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid The test timed out === wxppro (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid === wvistau64 (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid The test timed out === w2008s64 (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid === w7u (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid The test timed out === w8 (32 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid The test timed out === wvistau64 (64 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid === w2008s64 (64 bit datetime) === datetime.c:795: Test failed: Expected MonthCal to be valid

1 0

3DC format test failures
by Stefan Dösinger Feb. 12, 2015

Feb. 12, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Matteo, I'm getting test failures in test_3dc_formats on various machines. Do you have any idea how to change the test without reducing its usefulness? It seems that we're seeing all possible swizzles on Windows. Geforce 9600, Windows 7: visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x007f7f7f, case 0. visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x007f7f7f, case 1. Radeon X1600, Windows 7: visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x007fffff, case 0. visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x007fffff, case 1. This one smells like an implementation problem: Wine or r300g. Looks like the draw fails. visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x00ff00ff, case 0. visual.c:16804: Test failed: Expected color 0x003f3f3f or 0x007f0000, got 0x00ff00ff, case 1. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU3JdCAAoJEN0/YqbEcdMwK1EP/RqbMOXv8wkirSvrudJuzOdk /R68iLVBN3wJSuTnGz+gJz4RR3N3hdN3YeI3M+eTHoyqk/4JhKDKSE8M/W94ILEh BYH1m98D/EpphSwkiREcRma4eAFkC3K4U0zvxjOLkLq0BLaK6vAD6BuK97jORqmh i8oZS4vIpayq5DSvi+niNz5Wk/JLo8fu/6049kmY0r7asSYOcl8LEAgynUKRiKDT 6wyEsnC2Y5lKJ4zRMHGmxi/68R3CsxgAODIIW/JKC6/XskEydAM5TZ+h4lOLj0zU fzAkJRwBpwP4nS3XEI2bbMyA5ZLCLfa7Qo+otuUwU6vL6+6v6uwBRWNJtW+rQydk 2ceSfEj+FaoUqlqI8iySRmVkivYDKyp4wZL8/2WlAqstvC40cbYKRsa9YtMZFZF8 WpJip57t2pjAHdHCnAaA5qD7ulrjleAnMq7Yw3WqusA7NWPGWB8W02oKWuzfXYK3 C2byraxi5HQaHfxi5c60+WdJyzKGUhDn9PBdDRHmWJF77msk9x4ktl/DvtBF9XNZ X549ff8otGpJvczCDJZObvLU4qvQmPw6raHda+8qtGj4HcqVu3rq+WNv7+7zvmxk myLKNhYNhxSYzwwLHOTO3XGac2VJ/Gl4BEiBCn1chIAuZRGd2iWB4DMD0ptq4ovw 0CiBK8gTt/f5TsLTTzTl =ZgiK -----END PGP SIGNATURE-----

2 2

Problem in compiling wine on 64 bit system
by Ali Aminian Feb. 12, 2015

Feb. 12, 2015

Hello Changhui Liu thanks for your reply I finally managed to compile 32 bit wine on 64 bit Ubuntu 14.04 by installing a 32 bit Ubuntu under schroot. wine has a very good documentation on it but it would be better if the documentation said how to install 32 bit Ubuntu under schroot using "Ubuntu image", because downloading base Ubuntu system takes a little time if you don't have access to high speed internet. I also still have problem compiling wine the "shared WoW64 setup" way but i guess compiling the two version separately is sufficient.

1 0

Re: [PATCH] winepulse: add audio driver
by Andrew Eikum Feb. 12, 2015

Feb. 12, 2015

On Wed, Feb 11, 2015 at 10:15:28AM +0100, Maarten Lankhorst wrote: > This is a squash of all the winepulse related patches in repo.or.cz/w/wine/multimedia.git > Thanks Maarten. This has received a lot of testing by myself and by a large number of end-users, as many distros ship this by default. It will also materially improve the experience for users with high latency audio devices, especially USB devices, which the alsa-pulse plugin can't properly support (see [1] for a recent discussion). Pending any code review feedback, I'd like to see this merged. [1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-October/02204… Andrew

1 0

wine 1.8 schedule
by Bessières, Marc Feb. 12, 2015

Feb. 12, 2015

Hello, According to [1] the criteria for Wine 1.8 is the CSMT patch set. At FOSDEM 2015 Stefan Doesinger said at one moment something like CSMT is not ready yet(I don't remember exactly how he formulated it as he wasn't talking specifically about CSMT). Wine 1.6 was released in July 2013 [2] so more than 18 months ago. And 1.6 took 15 months to be released. A lot of good work has been put into 1.7 branch > git rev-list wine-1.6..wine-1.7.35 | wc -l 7708 Currently still a lot of people are using the 1.6 branch. So on the forum Roseanne often has to ask people to upgrade from the stable branch to the development one. On bugzilla, the triagers very often have to close bugs reported on 1.6 and already close in 1.7 (latest example a few hours ago [3]) I do not deny that the work to release is negligible (for example I see that in bugzilla there are 71 bugs tags as regressions [4] for 1.7). Maybe not having the CSMT patch set would also not be the best PR possible. But the number of commits and bugs solved is clearly good PR and good for the users. I'm not asking for an immediate release for sure, but to start a discussion on: - maybe a change of criteria for wine-1.8 - a rough schedule for wine-1.8 in order to give most of Wine users the best of what is being produced by you guys. Cheers, Marc [1] http://wiki.winehq.org/WineReleaseCriteria [2] https://www.winehq.org/news/2013071801 [3] https://bugs.winehq.org/show_bug.cgi?id=38023 [4] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&b…

6 6

Re: cryptui: add CryptUIWizDigitalSign stub
by Dmitry Timoshkov Feb. 12, 2015

Feb. 12, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +33 stdcall CryptUIWizDigitalSign(long ptr wstr ptr ptr) Appropriate .spec type for HWND is not ptr. -- Dmitry.

3 4

Re: [PATCH 6/6] wined3d: Set z = 0.0 via the projection matrix instead of depth clamping.
by Matteo Bruni Feb. 12, 2015

Feb. 12, 2015

2015-02-11 21:53 GMT+01:00 Stefan Dösinger <stefan(a)codeweavers.com>: > This works on cards that don't implement ARB_depth_clamp like r500 > cards. > > Note that texturing is influenced by position.w, not position.z. > --- > dlls/wined3d/directx.c | 7 ------- > dlls/wined3d/state.c | 33 ++++++++++----------------------- > dlls/wined3d/wined3d_gl.h | 2 -- > 3 files changed, 10 insertions(+), 32 deletions(-) It's probably hard to measure and not going to really matter in practice but toggling the depth clamping (where supported) might be slightly faster than updating the projection matrix. I'm not NACKing the patch though.

2 2

Re: crytpui: add CryptUIWizDigitalSign stub (try 2)
by Dmitry Timoshkov Feb. 11, 2015

Feb. 11, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +33 stdcall CryptUIWizDigitalSign(long ptr wstr ptr ptr) ... > +BOOL WINAPI CryptUIWizDigitalSign(DWORD flags, HWND parent, LPCWSTR title, PCCRYPTUI_WIZ_DIGITAL_SIGN_INFO info, > + PCCRYPTUI_WIZ_DIGITAL_SIGN_CONTEXT *context) What's the difference with previous version? -- Dmitry.

1 0

Re: [PATCH 5/6] d3d8/tests: Test rhw depth clip with z enabled but no depth buffer set.
by Marvin Feb. 11, 2015

Feb. 11, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11495 Your paranoid android. === w8 (32 bit visual) === visual.c:4139: Test failed: Expected color 0x0000ff00 at 80, 60, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 560, 60, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 80, 180, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 560, 180, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 80, 300, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 560, 300, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 80, 420, got 0x00ff0000. visual.c:4139: Test failed: Expected color 0x0000ff00 at 560, 420, got 0x00ff0000.

1 0

Re: [PATCH 4/6] d3d9/tests: Test rhw depth clip with z enabled but no depth buffer set.
by Marvin Feb. 11, 2015

Feb. 11, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11494 Your paranoid android. === w8 (32 bit visual) === visual.c:15503: Test failed: Expected color 0x0000ff00 at 80, 60, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 560, 60, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 80, 180, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 560, 180, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 80, 300, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 560, 300, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 80, 420, got 0x00ff0000, test 0. visual.c:15503: Test failed: Expected color 0x0000ff00 at 560, 420, got 0x00ff0000, test 0.

1 0

Re: [PATCH 2/6] dxgi: Add interface for IDXGISurface1 [try 2]
by Stefan Dösinger Feb. 11, 2015

Feb. 11, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martell, This patch (and http://source.winehq.org/patches/data/108999) look good to me from a content point of view. The E-Mail submission is a bit broken though. If I pipe the raw mail into git am I get a commit message that has some HTML and other junk in it. I recommend to set up git send-email. It will create the proper numbering for you and make sure that there are no line wraps or HTML junk in the mail. If you want to send only some part of your patches with send-email you can e.g. create a temporary branch, cherry-pick what you want to send, and then send from that branch. Also I recommend to send one patch after another, wait for it to be applied, then send the next one. Cheers, Stefan Am 2015-02-10 um 13:11 schrieb Martell Malone: > I'm going to take this slowly, with this there should be no issues > with he first 2 patches. > > I went with dxgi: in this commit message as that's what henri said > > The prefix for the dxgi IDL patches should be "dxgi:", for the > d3d11 one it should be "d3d11:". > > > Before I resubmit 4 and 6 however I need to know if I should have > "include:" or "dxgi:" + "d3d11:" in them as these create new files -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU20OEAAoJEN0/YqbEcdMwYhQP/3+K4X1/NH/K5ke0MdCCXzNO af8QxlcLJjNg6XH6bParDEDvs4u9pax3oGULzT07uu9hNpk1/zkssxV6tc3wJIs+ Sxx2A/EOU2ggtJJ5Dn3RPRKFJAiXJCwRClJcePj94lp5S11zNpoBcEJyn9Y9rZZc afvK2cPjj5w5ym8b2Ml9us16JbmN+JyAIr7gX59jZy+67+W6GpZdbB1/OV55Up4y bJH0Sl83vh6GzsZi0QyQ/oRE8OWxhYstOTmPEUMFX66qJh4wzgOy5+oRRmro0PoR X9bshnHGwQPEZs74UtCxpPusyGL6ApcZ5TAdsXiy+J6qhsnhv+bGLbQqwOp0RtPn mMs8V4S50h+84vvO/v/JhsPxMyKt0dC8HqhsHYn9Zl4Idv3bT6Q3wTbaovVKRbTM X0nB6HVoQPVKPRRXnRo2g8DTumrW4Qyg44Ymx3RsW8BNmnPy7YdJFjYIlW0fMwPP Q7MhrKv2lvJy7239Cm+iR1huYkMZgND+u7c45qTl+03SagOy5T+E4PzsZvAaf08O 89v1D1ogIgyvSnswuhY1o3XgQ4hMEm/I9BDespEXk9iedXwK9H4/+kvW+5kgvHJs TaDc0MNA97IiGz+Nvv4LEKk7kydqFmsIgaeKuTibrUs1+vyFWsCMHz+kcmxvA3Db uW3zEYIjKdG+i2xmwmmp =OaYZ -----END PGP SIGNATURE-----

1 0

Re: version: Fix wrong length reported when selecting a block.
by Stefan Dösinger Feb. 11, 2015

Feb. 11, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-02-09 um 23:20 schrieb learn_more: > From: Mark <learn0more(a)gmail.com> We need to know your full name to accept your patch to be able to show where our code comes from. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2z8oAAoJEN0/YqbEcdMw/tYP/RxWhEnR4ZbwplYloK3vcq6H P08nlylTgQ+MfjUwReQxuPoVU3FNTx2+zD1omcJ37NJvorMONu6EUJ8OtCcBGmWO wmii92XCOZJkZOaOAO5pd/ziSamZeeQNVVG1fhW+NkcEF2Jp/PtuPwWF/eZ4UL9V Rz0mrf/BUZ6xCmCPz8hRO22foMCHpIArVtke1j/9GN0df5LB2bLpMlvcmQrR/YT2 r12xz4+z4FeyBFGS1wZ5s7U6LawlUVR6YUJtCwcBmxrmYAY3byiYoX8fXbYJt+CI rAoXo427GKLf27SArsT21Q2aFYzRff3hm5YQUDO2idm07bmiTTj5rdDAekq7DQKT 3m28wBBjrSyjbJCKAXRBJyvC2au0WdC0cTh/1Ji5FtOC0Csl6pJ2ST3iIrSvNgw/ AJgbizBGTsb9Wgtm1nH+AEJn9w7enqR1BGzIL4WNSNrsoyvSyO2WWR9Cc0demOle 2Z12gKTbiTWxssezxTqvpTWrX6Cqym2gJW8ZbRpK2J/INZbpqH889UwWC3LMw/8v rUDx23MV985/h2AS6h2takGDmvtKU/Wdv6zluaYdA9fpkmM7waLS5G5Lgrjx17rz H8JvB7VbLuf6eIzxVnlsZE6NJo+HXghoZyD00hKvM9zh1wRhNgMfcWgNfA47W1+w 9+id7LnpWmtcTEA99AuH =+oRF -----END PGP SIGNATURE-----

1 0

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog() (try 3)
by Nikolay Sivov Feb. 11, 2015

Feb. 11, 2015

This is better, but still not quire right. > +CRITICAL_SECTION setuplog_critical; Take a look at how critical section data is initialized in wine code, name needs to be adjusted to let's say 'setupapi_cs'. > + if (MessageString) > + { > + len = lstrlenA(MessageString) + 1; > + msg = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (msg == NULL) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + MultiByteToWideChar(CP_ACP, 0, MessageString, -1, msg, len); > + } That's not how A->W conversion works, we have tons of examples for that. > OsVersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFOW); > if (!GetVersionExW(&OsVersionInfo)) > return FALSE; > + InitializeCriticalSection(&setuplog_critical); > SETUPAPI_hInstance = hinstDLL; > break; > case DLL_PROCESS_DETACH: > if (lpvReserved) break; > + DeleteCriticalSection(&setuplog_critical); > if (CABINET_hInstance) FreeLibrary(CABINET_hInstance); > break; You won't need these calls once you init it like the rest of Wine code does. Also what about closing files on DLL_PROCESS_DETACH? > + SetLastError(ERROR_ALREADY_EXISTS); > + return TRUE; Is it really important for some application to set this error on success? In general you only need to set it if call failed. > + setupact = CreateFileW(path, GENERIC_WRITE, FILE_SHARE_WRITE | FILE_SHARE_READ, > + NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); Did you check what happens if multiple processes are logging?

2 3

Re: [PATCH 5/5] d3d9/tests: Test upload of user memory textures.
by Stefan Dösinger Feb. 11, 2015

Feb. 11, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-10 um 20:14 schrieb Matteo Bruni: > + hr = IDirect3DDevice9Ex_CreateTexture(device, 33, 33, 1, 0, D3DFMT_L8, > + D3DPOOL_SYSTEMMEM, &texture, &mem); > ... > + hr = IDirect3DDevice9Ex_SetTexture(device, 0, (IDirect3DBaseTexture9 *)texture); > + ok(SUCCEEDED(hr), "SetTexture failed (0x%08x)\n", hr); Am I missing something, or are you texturing from system memory here? I am surprised this is working. I'll test it on my collection of Windows boxes to be sure. I think it would be a good idea to test the UpdateTexture / UpdateSurface codepath with user memory textures and a strange pitch like in your test. This doesn't have to be part of this patch though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2yz/AAoJEN0/YqbEcdMw/nMP/i61GWBL1ZajYzvS2iohebWp 6nE9k6Yh9OziU7LjJZfkWekvNPGPd8UYN2B5CzdqM6LPdBM3PFj3UFAROzECAPjn JpLHncb8gh25CXFAV0V/rdlaoXuYIKkxQDiZMyiDEP01gZNLTX+bt1rdWmK6JNtJ czFYyoSKyWyzbiUOQSAKponMxYbd2rK3B714Xsn50CRJdA6z26DSgqMfHabZcrl1 R+PWOfwDh7n6es7ax5rVWDNIvip1bFoU97wTahfIxIoL227eSTsFwwRo1pNsLnd4 9KsQmIWdKzIMZqPPkhnKGZz1Gu79Q3GJnlLjbWODYL5fgfbI+Bcv6npMZqHtctvb yFn86dVX2t6WTAMBmC4J3PVm+Igrzlk7nQt6l4X4KeMf7HYP9wDtOh/FIt4TV4qy 7Zu7JpuRDk5yKgnE/y7eew6YHyQGmVy59Y4IL7CR2EiwAevZr/HblvBjmsJ+CfSF NHF1QZkt/VH4v3D2XQzrW9Pln9H5m3luFTzA5cVOsv1v4r62uAY69tJLUmVRguyx icxFGbcuUKPtiFu4ER9Q0dZXx2gscy7agLYGbbwvsNFapBG2dTPaS1qJVyXe7/kD ML82rlfGImYupx6aSE/GAvD/IWaZgICt+XqPj5PnOIBz/mN9o9KziewCSg53Xp+2 Ai+BIdMBa8KOiK2MGPrH =Jvrb -----END PGP SIGNATURE-----

1 0

Re: [PATCH] user32: use InvalidateRect to repaint buttons
by Dmitry Timoshkov Feb. 10, 2015

Feb. 10, 2015

Mark Harmstone <hellas(a)burntcomma.com> wrote: > At present, whenever a button needs to be redrawn user32 calls its own > internal function. This causes problems if the button is subclassed, as > the superclass then won't receive the WM_PAINT message - this is why > themed buttons lose their theme when you click on them. This patch changes > it to instead call InvalidateRect, which will force a WM_PAINT message > to be sent to the topmost class. Did you run 'make test' with your changes? -- Dmitry.

1 0

Re: [PATCH 3/5] wined3d: Set the surface pitch for user-memory surfaces.
by Henri Verbeet Feb. 10, 2015

Feb. 10, 2015

On 10 February 2015 at 20:14, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + { > surface->resource.size = wined3d_format_calculate_size(texture_resource->format, > texture_resource->device->surface_alignment, width, height, 1); > + surface->pitch = wined3d_format_calculate_pitch(texture_resource->format, width); > + } > A small comment mentioning that user memory surfaces don't have the regular surface alignment probably wouldn't hurt.

1 0

Re: connect: add IsInternetConnectedStub
by Bruno Jesus Feb. 10, 2015

Feb. 10, 2015

On Tue, Feb 10, 2015 at 4:03 PM, Austin English <austinenglish(a)gmail.com> wrote: > > https://bugs.winehq.org/show_bug.cgi?id=26759 Isn't it better to simply add a note like "faking success" and return S_OK? Because returning false will probably not have a useful effect in the application. I didn't test the application though. > -- > -Austin > Best regards, Bruno

2 1

Re: vbscript: Added InStrRev implementation.
by Marvin Feb. 10, 2015

Feb. 10, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11485 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 2/6] dxgi: Add interface for IDXGISurface1 [try 2]
by Jacek Caban Feb. 10, 2015

Feb. 10, 2015

On 02/10/15 13:11, Martell Malone wrote: > Before I resubmit 4 and 6 however I need to know if I should have > "include:" or "dxgi:" + "d3d11:" in them as these create new files We already have both variants in Git history and there was never a problem with it. If you ask me, use whatever you prefer. Jacek

3 2

Re: mshtml: Fix fire BeforeNavigate event for app: protocol
by Jacek Caban Feb. 10, 2015

Feb. 10, 2015

On 02/09/15 07:08, Changhui Liu wrote: > - if(window->doc_obj && window->doc_obj->webbrowser && window == window->doc_obj->basedoc.window) { > + if(window->doc_obj && window->doc_obj->webbrowser && > + ((window == window->doc_obj->basedoc.window) || (window->parent == window->doc_obj->basedoc.window))) { > DWORD post_data_len = request_data ? request_data->post_data_len : 0; > void *post_data = post_data_len ? request_data->post_data : NULL; > const WCHAR *headers = request_data ? request_data->headers : NULL; The change on its own is wrong. There is nothing special about direct child of top HTML window. Ideally, we should call FireBeforeNavigate2 for all HTML windows, but use super_navigate only for the main one. This means that the if you change should not check which window we're in at all. However, for other windows, we need to pass proper frame name there. Let me know if you need more details. Cheers, Jacek

1 0

Re: [2/6] dxgi: Add interface for IDXGISurface1
by Stefan Dösinger Feb. 10, 2015

Feb. 10, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martell, There are a few things in Henri's list of fixes that are still missing here: Am 2015-02-09 um 10:28 schrieb Martell Malone: > Subject: [PATCH 2/6] dxgi: Add interface for IDXGISurface1 "include:" instead of "dxgi". > + uuid( 4ae63092-6327-4c1b-80ae-bfe12ea32b86), You have an extra space here. > + [out] HDC* hdc HDC *hdc, or even better HDC *dc. We avoid the Hungarian notification Microsoft once used, e.g. things like DWORD dwNumber. HDC hdc is the same kind of thing, although it's a bit of a special case. Patch 3: > +typedef struct DXGI_OUTDUPL_MOVE_RECT { > + POINT SourcePoint; > + RECT DestinationRect; > +} DXGI_OUTDUPL_MOVE_RECT; { placement . You also have FOO* bar; vs FOO *bar; issues in this patch. > + [in] IUnknown* pDevice, > + [in] IUnknown* pWindow, > + [in] const DXGI_SWAP_CHAIN_DESC1* pDesc, pStuff The same things also occur in patches 4, 5, and 6. Patch 4: > + [size_is(count_levels)] const D3D_FEATURE_LEVEL* levels, > + UINT count_levels, You are mixing count_* and *_count in patches 4, 5 and 6. For consistency's sake please make this *_count consistently. Patch 6: > +} > \ No newline at end of file Is this intentional? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2eMXAAoJEN0/YqbEcdMwUmYP/A8I/1UBVqcynhIJ5qIvVTl4 sf3XQcWTmgI40JurL4D1mIaQMH+VeulQ7Jeroo9L9/WhIw1RRJ7R0jFULxZIu9tP VX5AyTVjd555jbt9DvlbmkaAicb0UuX7xSO5OelkkdwtdfuDCKnDq2+LxzXA2fXw y98vlT98meapIP5BzERMyAAyM0AkvpAMaxkBabE9w9Mj6IJUWteHQEwa2iavu0HR wBr/KotHXu/nqVD41PTYnAsyQoWeBNPBghg4RyqI42YKiOnDxuApOT9nAgewwHPA VghOW/hdlZahCZc+/Vst01pD7Sa7vS/Nuq4iDfJJVofSsXgwIdl5KT63eAOzR4Dl MefDKrEBmdTh44K/JeyCey1Rb4o6fNtPCQJV6lqXQkiHVeE/8IW8qPLectwuGPVd UtC7Fy38iR4UpDJBmPGypdZaFJzS2ZF1hO+mA/jJhOnefyL31vCeFWU+bf5ISuwo TDEGu7G/8yBpY+HKHr+++IwJlJKkEngf98ksjnyRC1PpIner05XHUDeu1PIll/FS T3aveyW5lWsyVGCyyovHLQIxfkaV6JPqR/AsuTuhDmhZu4ZQPoGLH5kpfrAhgVMA TeLGoR6RtTMOyFLob4sRI9nBR89H/UiEQ++fGbp/YXsOLnOZBJvn6y8AYh6zaeD5 6smvq4QiqsuQQS3tSC+f =CmBk -----END PGP SIGNATURE-----

2 3

Problem in compiling wine on 64 bit system
by Ali Aminian Feb. 10, 2015

Feb. 10, 2015

Hello wine community I have some difficulty compiling wine on 64 bit ubuntu 14.04. I'm following the guide in http://wiki.winehq.org/Wine64 which i also replicate here: cd $HOME mkdir wine64 cd wine64 ../wine-git/configure --enable-win64 make > make.log 2>&1 cd .. mkdir wine32 cd wine32 ../wine-git/configure --with-wine64=../wine64 make > make.log 2>&1 #make install #cd ../wine64 #make install I can build the wine64 without any difficulty except that after configuration it prompts me that i don't have libhal, but i just ignored that. But when i get into win32 it gives me numerous warning that 32-bit development files not found, and some option will be disabled. for example: ************************************************************************************************** configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: pcap 32-bit development files not found, wpcap won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: lib(n)curses 32-bit development files not found, curses won't be supported. configure: libsane 32-bit development files not found, scanners won't be supported. configure: liblcms2 32-bit development files not found, Color Management won't be supported. configure: libz 32-bit development files not found, data compression won't be supported. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: libcups 32-bit development files not found, CUPS won't be supported. configure: fontconfig 32-bit development files not found, fontconfig won't be supported. configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported. configure: libtiff 32-bit development files not found, TIFF won't be supported. configure: libmpg123 32-bit development files not found (or too old), mp3 codec won't be supported. configure: libopenal 32-bit development files not found (or too old), OpenAL won't be supported. configure: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported. ******************************************************************************************************** [important] and when i try to install 32 bit version of these libraries using aptitude (since using apt-get just says unmet dependencies and exits) it tries to remove my 64 bit version of the same library. for example: ***************************************************************************************************** ali(a)ali-Vostro-1520:~/other_drive/wine32$ sudo aptitude install libxi-dev:i386 The following NEW packages will be installed: libxi-dev:i386{b} 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 204 kB of archives. After unpacking 638 kB will be used. The following packages have unmet dependencies: libxi-dev : Conflicts: libxi-dev:i386 but 2:1.7.1.901-1ubuntu1 is to be installed. libxi-dev:i386 : Conflicts: libxi-dev but 2:1.7.1.901-1ubuntu1 is installed. The following actions will resolve these dependencies: Remove the following packages: 1) libatspi2.0-dev 2) libgtk2.0-dev 3) libxi-dev 4) libxtst-dev Accept this solution? [Y/n/q/?] y ******************************************************************************************************** [important] In one of these 32 bit installation aptitude removed my wine1.7 package and now i can't even install wine from official wine repository. so my questions are: 1_how you guys setup your environment for wine development? 2_how you deal with package managers when it acts weird?

2 1

Re: [PATCH 3/5] opengl32: Introduce wrappers for glGetIntegerv and glGetStringi. (v2)
by Alexandre Julliard Feb. 10, 2015

Feb. 10, 2015

Matteo Bruni <mbruni(a)codeweavers.com> writes: > @@ -834,6 +849,9 @@ PROC WINAPI wglGetProcAddress( LPCSTR name ) > *func_ptr = driver_func; > } > > + if (!strcmp(name, "glGetStringi")) > + return (void *)glGetStringi; It seems to me you could handle this one through the extension table instead of special casing it. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] winecfg: Double click in dlls list to edit overides; fix indent. (try 2)
by Andrew Eikum Feb. 10, 2015

Feb. 10, 2015

On Fri, Feb 06, 2015 at 10:23:15AM +0800, Hao Peng wrote: > Add a feature to winecfg. User can double click in dlls list to edit overides of selected item. > > the indent of code here mixed with tabs, 4 spaces and 8 space. I formated it to match the style of the rest code. > Usually we don't take patches that change nothing except formatting. I think your first patch was rejected because it adds even more inconsistent formatting. The indent is too small. The "case CBN_DBLCLK" line should be indented the same as the "case LBN_SELCHANGE" line. Instead it's indented 8 spaces when it should be indented 16 spaces. Andrew

1 0

Re: [2/6] dxgi: Add interface for IDXGISurface1
by Jacek Caban Feb. 10, 2015

Feb. 10, 2015

Hi Martell, On 02/09/15 10:28, Martell Malone wrote: > + uuid( 4ae63092-6327-4c1b-80ae-bfe12ea32b86), > + local, > + pointer_default(unique) > +] > +interface IDXGISurface1 : IDXGISurface Once again, please make sure that your patches builds before sending patches. ../tools/widl/widl -o dxgi.h -m32 -I. -I../include -D__WINESRC__ dxgi.idl dxgi.idl:175: error: syntax error, unexpected aKNOWNTYPE, expecting tIMPORT Jacek

2 1

Re: rpcrt4: add a stub for I_RpcBindingInqLocalClientPID
by Dmitry Timoshkov Feb. 9, 2015

Feb. 9, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +RPC_STATUS WINAPI I_RpcBindingInqLocalClientPID(RPC_BINDING_HANDLE ClientBinding, unsigned long *ClientPID) > +{ > + FIXME("%p %p: stub\n", ClientBinding, ClientPID); > + return RPC_S_INVALID_BINDING; > +} This can't work under all platforms for obvious reasons. -- Dmitry.

2 1

Problem in compiling wine on 64 bit system
by Ali Aminian Feb. 9, 2015

Feb. 9, 2015

Hello wine community I have some difficulty compiling wine on 64 bit ubuntu 14.04. I'm following the guide in http://wiki.winehq.org/Wine64 which i also replicate here: cd $HOME mkdir wine64 cd wine64 ../wine-git/configure --enable-win64 make > make.log 2>&1 cd .. mkdir wine32 cd wine32 ../wine-git/configure --with-wine64=../wine64 make > make.log 2>&1 #make install #cd ../wine64 #make install I can build the wine64 without any difficulty except that after configuration it prompts me that i don't have libhal, but i just ignored that. But when i get into win32 it gives me numerous warning that 32-bit development files not found, and some option will be disabled. for example: ************************************************************************************************** configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: pcap 32-bit development files not found, wpcap won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: lib(n)curses 32-bit development files not found, curses won't be supported. configure: libsane 32-bit development files not found, scanners won't be supported. configure: liblcms2 32-bit development files not found, Color Management won't be supported. configure: libz 32-bit development files not found, data compression won't be supported. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: libcups 32-bit development files not found, CUPS won't be supported. configure: fontconfig 32-bit development files not found, fontconfig won't be supported. configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported. configure: libtiff 32-bit development files not found, TIFF won't be supported. configure: libmpg123 32-bit development files not found (or too old), mp3 codec won't be supported. configure: libopenal 32-bit development files not found (or too old), OpenAL won't be supported. configure: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported. ******************************************************************************************************** [important] and when i try to install 32 bit version of these libraries using aptitude (since using apt-get just says unmet dependencies and exits) it tries to remove my 64 bit version of the same library. for example: ***************************************************************************************************** ali(a)ali-Vostro-1520:~/other_drive/wine32$ sudo aptitude install libxi-dev:i386 The following NEW packages will be installed: libxi-dev:i386{b} 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 204 kB of archives. After unpacking 638 kB will be used. The following packages have unmet dependencies: libxi-dev : Conflicts: libxi-dev:i386 but 2:1.7.1.901-1ubuntu1 is to be installed. libxi-dev:i386 : Conflicts: libxi-dev but 2:1.7.1.901-1ubuntu1 is installed. The following actions will resolve these dependencies: Remove the following packages: 1) libatspi2.0-dev 2) libgtk2.0-dev 3) libxi-dev 4) libxtst-dev Accept this solution? [Y/n/q/?] y ******************************************************************************************************** [important] In one of these 32 bit installation aptitude removed my wine1.7 package and now i can't even install wine from official wine repository. so my questions are: 1_how you guys setup your environment for wine development? 2_how you deal with package managers when it acts weird?

1 0

(no subject)
by The Cheese Feb. 9, 2015

Feb. 9, 2015

Hi, I'm a newbie. I would really like to help with the development of Wine in any capacity I can. The thing is, I looked over the bugzilla and various ways to get the stacktrace, etc. However, finding the cause simply by looking at address calls and returns eludes me. Is there something which might help me get there faster, for eg: reading up on instruction sets on x86 chipsets etc? I've already looked over the winedev-guide. Thanks for any help.

2 1

Re: [PATCH 1/4] wine-headers: add a winapifamily header
by Martell Malone Feb. 9, 2015

Feb. 9, 2015

> > First, the 1/4 patch is really something you'll have to convince > Alexandre of it's the right thing to do. The easiest way is probably > to ask him about it on IRC. The amount of advice I can give on that > one is limited, but it would probably help if you could show why Wine > needs the winapifamily mechanism. The best way to do that may very > well just be to show that applications need e.g. the > WINAPI_FAMILY_DESKTOP_APP constant to compile against the Wine > headers. > I will ask him on IRC. Yes well it would be more correct to have the header in the case where a program uses that ifdef So this would match the official instructions from MS on using different api's I could also imagine that you'll be asked to partition the > other Wine headers as well if we're going to have this mechanism in > Wine. I.e., I don't think it makes a lot of sense to only do this for > a couple of dxgi headers, but not for anything else. The prefix for > the subject should be "include:". I'd move this patch to the end of > the series. > Initially I would have only done the dx stuff because mingw-w64 shares those headers. Essentially they Jacek Caban pulls in the d3d11 headers and idls from wine in to mingw-w64 to update. I could update the mingw-w64 project with the changes but I didn't want to leave wine out of the loop. I do understand that all headers would need to be partitioned to support this eventually. I was hoping the start would be with directx > The comment is pretty superfluous. > I can take it out. In patch 2/4, you have unrelated style changes for e.g. > IDXGIDevice2::OfferResources() > . I happen to like the new style better, > but please don't do that. First add the new stuff, then send a patch > to make the existing stuff consistent with dxgi.idl at the end of the > series. > Sure I can do that Some general style stuff: > - I think "{" on the same line for enum/struct/interface declarations is > ugly. > - Use "DXGI_OUTDUPL_DESC *desc" instead of "DXGI_OUTDUPL_DESC* desc", > etc. > - There are a couple of parameter naming issues. e.g. "pDevice", > "colorSpace", "pStats", "Data", etc. > - I prefer the order of things to be macros/constants, enums, > structs, interfaces, functions instead of having those interleaved > through the header. > - "FLOAT" -> "float", "LPCWSTR" -> "const WCHAR *" > - "num_*" -> "*_count" > > The prefix for the dxgi IDL patches should be "dxgi:", for the d3d11 > one it should be "d3d11:". > Seems easy enough to follow :) On Fri, Feb 6, 2015 at 1:05 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I had a look at this series, and have a couple of comments. > > First, the 1/4 patch is really something you'll have to convince > Alexandre of it's the right thing to do. The easiest way is probably > to ask him about it on IRC. The amount of advice I can give on that > one is limited, but it would probably help if you could show why Wine > needs the winapifamily mechanism. The best way to do that may very > well just be to show that applications need e.g. the > WINAPI_FAMILY_DESKTOP_APP constant to compile against the Wine > headers. I could also imagine that you'll be asked to partition the > other Wine headers as well if we're going to have this mechanism in > Wine. I.e., I don't think it makes a lot of sense to only do this for > a couple of dxgi headers, but not for anything else. The prefix for > the subject should be "include:". I'd move this patch to the end of > the series. > > > +/* wine wants all the api's by default so we set to desktop + app */ > > +#ifndef WINAPI_FAMILY > > +#define WINAPI_FAMILY WINAPI_FAMILY_DESKTOP_APP > > +#endif > The comment is pretty superfluous. > > In patch 2/4, you have unrelated style changes for e.g. > IDXGIDevice2::OfferResources(). I happen to like the new style better, > but please don't do that. First add the new stuff, then send a patch > to make the existing stuff consistent with dxgi.idl at the end of the > series. > > Some general style stuff: > - I think "{" on the same line for enum/struct/interface declarations is > ugly. > - Use "DXGI_OUTDUPL_DESC *desc" instead of "DXGI_OUTDUPL_DESC* desc", > etc. > - There are a couple of parameter naming issues. e.g. "pDevice", > "colorSpace", "pStats", "Data", etc. > - I prefer the order of things to be macros/constants, enums, > structs, interfaces, functions instead of having those interleaved > through the header. > - "FLOAT" -> "float", "LPCWSTR" -> "const WCHAR *" > - "num_*" -> "*_count" > > The prefix for the dxgi IDL patches should be "dxgi:", for the d3d11 > one it should be "d3d11:". >

3 5

Re: setupapi: fix string conversion in SetupGetInfInformationA()
by Jacek Caban Feb. 8, 2015

Feb. 8, 2015

Hi Pierre, On 02/08/15 19:59, Pierre Schweitzer wrote: > inf = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!inf) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; You don't need to call SetLastError here. It's already set by HeapAlloc on failure. Jacek

2 2

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog() (try 2)
by Nikolay Sivov Feb. 7, 2015

Feb. 7, 2015

This one is clearly broken regarding critical section usage.

1 0

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Nikolay Sivov Feb. 7, 2015

Feb. 7, 2015

Hi, Pierre. Some comments for your patch. > --- a/dlls/setupapi/Makefile.in > +++ b/dlls/setupapi/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > diskspace.c \ > fakedll.c \ > install.c \ > + log.c \ > misc.c \ > parser.c \ > query.c \ I'm not sure you need a new file for that. It depends on how much will be possibly added in the future, but general rule I think is to try to find a room in existing files. > +#include "wine/debug.h" > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > +#include "setupapi.h" > +#include "winnls.h" Looks like you don't need all of those. > +HANDLE setupact = INVALID_HANDLE_VALUE; > +HANDLE setuperr = INVALID_HANDLE_VALUE; Should be static. > + LPWSTR msg = (LPWSTR)MessageString; I see what you want to do, but it's a bit ugly imho. > + if (MessageString) > + { > + len = lstrlenA(MessageString) + 1; > + msg = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, MessageString, -1, msg, len); > + } Please check for memory allocation failure. > + ret = WriteFile(setupact, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); > + ret = WriteFile(setuperr, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); You can probably do strlenW() once. > + GetWindowsDirectoryW(path, MAX_PATH); Same, you need to get this path once. > + if (setupact != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setupact); > + setupact = INVALID_HANDLE_VALUE; > + } > + > + if (setuperr != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setuperr); > + setuperr = INVALID_HANDLE_VALUE; > + } You can just CloseHandle() unconditionally. I think it also makes sense to SetupCloseLog() on PROCESS_DETACH, but that's easy to test. Another thing to test is to see what happens in multithreaded case, if it works correctly on windows you need to protect those handles in SetupOpenLog/SetupCloseLog, maybe somewhere else too.

2 1

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Marvin Feb. 7, 2015

Feb. 7, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11472 Your paranoid android. === wvistau64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w7u (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w8 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === wvistau64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87

1 0

Re: server: Filter WM_QUIT message in PeekMessage call if PM_QS_POSTMESSAGE was not specified
by Marvin Feb. 6, 2015

Feb. 6, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11458 Your paranoid android. === w7u (32 bit msg) === msg.c:12112: Test failed: unexpected hwnd 0017014A msg.c:12134: Test failed: bad time 309ee/309fe

2 1

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph Feb. 6, 2015

Feb. 6, 2015

Am 2015-02-06 12:07, schrieb Nikolay Sivov: > On 06.02.2015 14:02, Patrick Rudolph wrote: >> Am 2015-02-06 09:22, schrieb Nikolay Sivov: >>> On 06.02.2015 11:12, Patrick Rudolph wrote: >>>> Hi guys, >>>> I tried WoW as it seems to be in a good shape, but run into same >>>> issues. >>>> I hope you can clarify. >>>> I've got an game that has two executables, 32bit and 64bit. It >>>> places a >>>> 32bit version of xinput1_3.dll in the same folder on startup. >>>> Trying to start the 32bit version works fine, however starting the >>>> 64bit >>>> version doesn't work. >>>> For me it looks like the ntdll load_dll is the fault. >>>> It searches for builtin xinput1_3 and finds the 32bit dll in the >>>> game >>>> folder. It fails to open it (wrong ARCH) and that's it. >>>> Instead of trying other directories it tries to load native. >>>> Again it opens the first file found in the given path, it's the same >>>> file again, it fails to open it and the application terminates. >>>> >>>> Why doesn't it check for correct ARCH ? >>>> Why doesn't it walk all directories / all path given, instead of >>>> just >>>> using the first file found ? >>> >>> What do you mean by that? It doesn't check usual System32 dir for 64 >>> bit dll, is that what you expect? >>> >> Why doesn't it check for files in syswow64 ? > > Because syswow64 is a directory for 32bit system dlls/exes. So for > 64bit process it doesn't make much sense to look for dependencies > there. So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ? > >>> >>>> Does Windows 64bits behave the same ? >>> >>> Does this game work in Windows with same conditions? Or any minimal >>> test case for that matter, like 64bit exe + 32bit dll with >>> appropriate >>> name, is that what you see? >>> >> I guess it is working, why should a vendor release a non functional >> game ? >> But I cannot test it, as I do not own a Windows. > > Maybe you just need 64bit version of xinput then? I can't place it in the same folder as there's already a 32bit version. Why doesn't it take the 64bit version in system32. > >>> >>>> Regards >>>> >>>> >>

3 2

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph Feb. 6, 2015

Feb. 6, 2015

Am 2015-02-06 09:22, schrieb Nikolay Sivov: > On 06.02.2015 11:12, Patrick Rudolph wrote: >> Hi guys, >> I tried WoW as it seems to be in a good shape, but run into same >> issues. >> I hope you can clarify. >> I've got an game that has two executables, 32bit and 64bit. It places >> a >> 32bit version of xinput1_3.dll in the same folder on startup. >> Trying to start the 32bit version works fine, however starting the >> 64bit >> version doesn't work. >> For me it looks like the ntdll load_dll is the fault. >> It searches for builtin xinput1_3 and finds the 32bit dll in the game >> folder. It fails to open it (wrong ARCH) and that's it. >> Instead of trying other directories it tries to load native. >> Again it opens the first file found in the given path, it's the same >> file again, it fails to open it and the application terminates. >> >> Why doesn't it check for correct ARCH ? >> Why doesn't it walk all directories / all path given, instead of just >> using the first file found ? > > What do you mean by that? It doesn't check usual System32 dir for 64 > bit dll, is that what you expect? > Why doesn't it check for files in syswow64 ? > >> Does Windows 64bits behave the same ? > > Does this game work in Windows with same conditions? Or any minimal > test case for that matter, like 64bit exe + 32bit dll with appropriate > name, is that what you see? > I guess it is working, why should a vendor release a non functional game ? But I cannot test it, as I do not own a Windows. > >> Regards >> >>

2 1

How WINE implements BitBlt function?
by John Found Feb. 6, 2015

Feb. 6, 2015

This question arouse when I have made some tests in assembly language. I have wrote a program that to allocate some memory bitmap, fill it with some image and then draw it on a window. The in-memory processing is pretty fast so the main time consuming operation is the drawing of the bitmap on the window. The code is the same for the Windows and Linux version of the program and only the code that draws the bitmap on the window differs. In the Windows version it uses DIB and BitBlt function and in the Linux version it uses XImage bitmap and XPutImage function from XLib. I expected to have some similar performance of both programs, but was surprised, that in WINE, the Windows version performs approximately by 50% faster (150fps) than the Linux version (90..100fps) and the Linux version loads the CPU much higher than the Windows one. So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? -- John Found <johnfound(a)asm32.info>

4 11

ntdll load_dll broken WoW behavior
by Patrick Rudolph Feb. 6, 2015

Feb. 6, 2015

Hi guys, I tried WoW as it seems to be in a good shape, but run into same issues. I hope you can clarify. I've got an game that has two executables, 32bit and 64bit. It places a 32bit version of xinput1_3.dll in the same folder on startup. Trying to start the 32bit version works fine, however starting the 64bit version doesn't work. For me it looks like the ntdll load_dll is the fault. It searches for builtin xinput1_3 and finds the 32bit dll in the game folder. It fails to open it (wrong ARCH) and that's it. Instead of trying other directories it tries to load native. Again it opens the first file found in the given path, it's the same file again, it fails to open it and the application terminates. Why doesn't it check for correct ARCH ? Why doesn't it walk all directories / all path given, instead of just using the first file found ? Does Windows 64bits behave the same ? Regards

2 1

Re: include: add msasn1.h
by Charles Davis Feb. 5, 2015

Feb. 5, 2015

> On Feb 5, 2015, at 1:20 PM, Austin English <austinenglish(a)gmail.com> wrote: > +typedef unsigned long ASN1uint32_t; > +typedef signed long ASN1int32_t; This won’t do what you (apparently) expect on 64-bit. At the very least, you should use ULONG/DWORD and LONG here. > +#ifndef WINAPI > +#define WINAPI __stdcall > +#endif This is most certainly wrong for Wine. I think you should include “windef.h” if you need WINAPI. I’m beginning to wonder if you copied this header (as well as <hidpi.h>) directly from Microsoft’s SDKs. You’ve been around long enough to know that that’s a big no-no around here. Chip

2 3

Re: [PATCH] dsound/tests: Add a test for SetFX.
by Marvin Feb. 5, 2015

Feb. 5, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11445 Your paranoid android. === w2000pro (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wxppro (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wvistau64 (32 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w2008s64 (32 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w7u (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === w8 (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wvistau64 (64 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w2008s64 (64 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078

1 0

Re: [PATCH 1/2] ntdll: Support 64-bit Mac OS. (try 2)
by Alexandre Julliard Feb. 5, 2015

Feb. 5, 2015

Charles Davis <cdavis5x(a)gmail.com> writes: > +/********************************************************************** > + * NtCurrentTeb (NTDLL.@) > + * > + * FIXME: This isn't exported from NTDLL on real NT. This should be > + * removed if and when we can set the GSBASE MSR on Mac OS X. > + */ > +TEB * WINAPI NtCurrentTeb(void) > +{ > +#ifdef __APPLE__ > + return pthread_getspecific( teb_key ); > +#elif defined(__GNUC__) > + struct _TEB *teb; > + __asm__(".byte 0x65\n\tmovq (0x30),%0" : "=r" (teb)); > + return teb; > +#else > +# error Please define retrieving the current TEB for your platform > +#endif > +} You can't do it that way: ../../../wine/dlls/ntdll/signal_x86_64.c:3481:31: error: redefinition of ‘NtCurrentTeb’ In file included from ../../../wine/include/windef.h:258:0, from ../../../wine/dlls/ntdll/signal_x86_64.c:59: ../../../wine/include/winnt.h:2288:84: note: previous definition of ‘NtCurrentTeb’ was here -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] jscript: Don't use builtin property for a few more constructors.
by Marvin Feb. 5, 2015

Feb. 5, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11440 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/4] wine-headers: add a winapifamily header
by Stefan Dösinger Feb. 5, 2015

Feb. 5, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, These patches are much more readable than the previous submissions! Am 2015-02-05 um 11:48 schrieb Martell Malone: > +#define WINAPI_PARTITION_DESKTOP 0x1 > +#define WINAPI_PARTITION_APP 0x2 > + > +#define WINAPI_FAMILY_APP WINAPI_PARTITION_APP > +#define WINAPI_FAMILY_DESKTOP_APP (WINAPI_PARTITION_DESKTOP \ > + | WINAPI_PARTITION_APP) This matches the definition of the Windows Kit 8.0 headers. In Windows Kit 8.1 this header looks quite different. Do you know what the intention of this is? Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU01O3AAoJEN0/YqbEcdMwJp4P+QHvB3snnXN2MC17+ZZxsjIz ZyUB28KCTlZJnXhQKEA/VOAOLrgGZOYWLd/qkW7gfRt1BSyiSS7hkuJAsdSkH43C AvXtY+HOumbewEkLl/MHfdk2yUgyzrgmv629jimeb83HnlzQG++b77WFSOQsYe4n T0kSibogJteL0TMgfHI1W5KtRJe95z8JpxBtIiPHGMlSSZHKLPEBDN8Tv8xSpkcw rHFW/HBxqeWLSpaz/YUAcMNDYNrIMY7DzgPW0MQRBewmQxRFc3hotyV2fnv7nUyZ nhlFruERczDBVOVYG1WIZ+28zawqMC9G93n+Emjl6szWRr4I/JtuB+ewHejr8HF4 8H35Ein5kQHSgkIeKPEarp9JwgbWpGOaWInLi8Y6K597oGJknzSv2snhenbOvx2T OUfbdmTgcwlIDsCN1dFzlVoAMV7UExDvx10H7rmdM7Ls0nhsL5TO0/jT25nbKMJa 5pyag4LISSQmKqLXTy24gRk27NplpiTwXNi37BQSw5BV0HJndSMxXfZgWE4jxQrL 9xYPvtEgaHofqdL3eo1M3FDownTmj7RJ4OAVuqgdAqfl7PfTKukgXXPuz9pQUuHL VHJ8CaUYcT41pdspys3iEZWGUMAui0kCzoisOKJPQpoTQ499r0uQysBkwNBeqPyh qfVxUc/oUsQlGkQtaA/N =OVYb -----END PGP SIGNATURE-----

2 2

Re: d3dx9_36: add D3DXDisassembleShader stub (try 2)
by Stefan Dösinger Feb. 5, 2015

Feb. 5, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-05 um 05:14 schrieb Austin English: > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL > colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) Please no LPCRAP: LPCSTR -> const char * LPD3DXBUFFER * -> ID3DXBuffer ** It is even written this way in our header. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0yySAAoJEN0/YqbEcdMwXNsP/RgpIfaoj7Xhc0QXmCfH4Idh 9A9ohj99ZYAgK4QRaxXwNU9Uoys4TpJVxTDZ31C8WgnSosY+RUPt5hHx64Qe7LY+ wCwDC4wGJGZGVdPmlmTdahhQi9G8BauTs9uHcVvMZThllgfhgGHPOjn90muzcSyx PcXd2cOVnzJwaUNmJ7BrFt1luzqdRUW+v0xu31a8wsFFeIMQGA99DEeDu2ZOiu6/ UWArtccpb0QrDP/A4C5+YAuMcQHeQvWbGMrsCnrm3DBCJN46AIlLcQzw73Leq17Q aY3g6uct8SpCXD8p+KNXfe6FU/qe52QFHjI6yVS9FgjYuHwkjUuIH2CN4au7Dq22 WMt9NZI/fys+MZ5ThKmd6W10kMUpbcHHQxWbDf2zbzaGOxWX+vULNVQhMoCppCF6 0PsYhz+A5HadKgbkk28bhoIVDLefEevw/ov4X1veXEwO/0Xyb/YeLF5XiykM2LQG q6cIAik1kpawJ+YIZYILSZUjgxFmR2q5UF+qotucNdQhbNwfai0MdMMxFZMtxeUD OWwEpILVCp8JLPnTaXYt7D231TPsvLdh0hWMUy6Sk0pOsi8wVf5tO21UO3UT9Vas 7GDaW04KyzKBfD6ArONETOKHGYeozvghmPCmTrA/c8JZ69JBCuA+qk4KdjJ4RvKB rTs9Aao9URRAA9Q4PBM/ =c5KR -----END PGP SIGNATURE-----

2 3

Re: d3dx9_36: add a stub for D3DXDisassembleShader
by Dmitry Timoshkov Feb. 4, 2015

Feb. 4, 2015

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall D3DXDisassembleShader(ptr long ptr ptr) ... > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) LPCSTR -> spec -> str -- Dmitry.

2 1

Re: ieframe:add app: protocol support to make mshtml trigger BeforeNavigate2 event when handle app: hyperlink
by Jacek Caban Feb. 4, 2015

Feb. 4, 2015

Hi Changhui, On 01/15/15 02:39, Changhui Liu wrote: > Hi, this verify test need the user click the app: hyperlink in browser, > so it is hard to write a test in dlls/ieframe/tests. > > I upload the test html file and a test exe here: > http://www.imakevideo.com/app.html > http://www.imakevideo.com/mfc_web.zip > > To run the test, extract mfc_web.zip, then run the mfc_web.exe, click > the Go button; > A message "BeforeNavigate2 app:xxx" will popup when click the > app: hyperlink > if the BeforeNavigate2 event was triggered as like IE in windows, or > nothing. It doesn't seem right. There is nothing special about app: protocol handling, BeforeNavigate2 should be called in this case the same way as for any other protocol. You need to find the real reason why it's not called instead of calling it in an error case. The bug is likely to be in mshtml. Jacek

2 4

Re: jscript: Don't use builtin property for exposing Boolean constructor.
by Marvin Feb. 4, 2015

Feb. 4, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11427 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 3/3] dwrite/tests: Fix couple of leaks when creating test font instance (resent)
by Marvin Feb. 4, 2015

Feb. 4, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=11425 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/3] dwrite: No need for return value in collection_find_family()
by Alexandre Julliard Feb. 4, 2015

Feb. 4, 2015

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1424,11 +1424,14 @@ static HRESULT WINAPI dwritefontcollection_GetFontFamily(IDWriteFontCollection * > return create_fontfamily(This->family_data[index], iface, family); > } > > -static HRESULT collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) > +static void collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) Returning the index instead would probably make the code cleaner. -- Alexandre Julliard julliard(a)winehq.org

1 0