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

Fixing up the code style
by Stefan Dösinger Feb. 22, 2014

Feb. 22, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After recently helping two contributors (the Pipelight guys and Martin Storsjö) through the maze of the Wine code style I think it's best to lift the ban against style-only patches and unify the code style once and for all. The basic reasoning is that from my point of view the lack of clarity wrt the code style and lack of automatic enforceability is causing more issues than the problems style-only patches cause with git blame. Finding a style-only change with git blame can be handled by running git blame again. Frustrating contributors on the other hand has no workaround. So I propose to agree on a code style for the entire project, fixing it up preferably with an automated tool and in the future enforcing the style with checks in the Testbot. Opinions? Wrt the code style I propose the style that is used in wineserver. It is the same one as the new style in the d3d code except for single-line if conditions. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJS/MQGAAoJEN0/YqbEcdMw7rMP+LAP5pnxyy9onITtJVe8swuy pKrS+U1NgLIru9yGuuxUsejUr8gY9hD27nSQQ2OddzSV3pEkY6vmqftSIFVT8Oli d0kEXbxZhlzRe9rCgEJGLGx73ap/LBOm0k3jtslOVONlIyH8AXdEG37a2P7s8SKV D9p0Sw7ggNRF8D0eIszSPKjfUfBYph+9XU1SDA9aEfokv6rs6AFt9xehCOUsdayZ gwqiigg70tkez81GhDRfuXWVn6pdsVpeLDjxF4P2XFMT00OInJIYBIy2w91sxgOs 3vos4X60+qg+sIGxAhxgfLilVQSbBOqvBz9QEUycOduzJK87sVfGtpsipCX4qW1Z QNE+SOINHjazNPB0mydO7s6rThOuZS2BU5nG+ZaXmbe5RBUXLMqqjUmIGL2ZYodJ zQ+3eOHC0H8fxaNhqwpRh5Gq8fVE+xcXauovLv0Ro+FskOitfazIBJEfktjJuXZ8 YZcmLqQAGCwd0Y9pTOTXldoR9ah1+gO7ya5n2ljR0+viAol6KQoUaD4dFNhEur4j cpmW2EDks/wPVrvjX2u8cphHGeOLSjDEErnE/PoX5w7jNarekRWSSalanYB+04SX rjxUXSVq30upNdJ07W2L8gLaHTgHq0rglR1ZrSYEDw5FtaG/Xs4W0YqyX5APl/+O Bj4qRaV70TNOicRNgaA= =DQdS -----END PGP SIGNATURE-----

9 12

Re: Windows sets CCS_VERT when TB_GETEXTENDEDSTYLE is set
by Marvin Feb. 22, 2014

Feb. 22, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=5092 Your paranoid android. === build (build) === Make failed

1 0

Re: ws2_32/tests: Add W2K error values as valid
by Marvin Feb. 22, 2014

Feb. 22, 2014

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://newtestbot.winehq.org/JobDetails.pl?Key=5087 Your paranoid android. === w2000pro (32 bit sock) === sock.c:613: Test failed: oob_server (444): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at C0000241 === wxppro (32 bit sock) === sock.c:613: Test failed: oob_server (b28): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 7C9010E6 === wvistau64 (32 bit sock) === sock.c:613: Test failed: oob_server (744): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock.c:613: Test failed: oob_server (750): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit sock) === sock.c:613: Test failed: oob_server (63c): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:613: Test failed: oob_server (750): unexpectedly at the OOB mark: 0

1 0

Re: Help about implementing WSACleanup (ws2_32)
by Bruno Jesus Feb. 22, 2014

Feb. 22, 2014

The attached patch implements a socket queue in the DLL side and implements WSACleanup. For now the socket list does not have any parameter but my target is to add more stuff to it and reduce the server calls. Any comments are appreciated. Best wishes, Bruno On Sun, Dec 29, 2013 at 4:21 PM, David Quintana (gigaherz) <gigaherz(a)gmail.com> wrote: > I have no knowledge about windows sockets, but DLLs are not shared across > processes. If a DLL wants shared memory it has to map it explicitly, like > everything else. On the other hand threads do share all memory, and windows > provides thread-local storage to allow thread-specific variables. > > On 29 Dec 2013 19:15, "Bruno Jesus" <00cpxxx(a)gmail.com> wrote: >> >> Hi, in an attempt to fix bugs 18670 and 26031 I would like to try >> implementing WSACleanup more properly. My limited knowledge in the >> interactions between the ws2_32 dll and wine server makes me think >> this is easy. >> >> The idea is to add the created socket in WSASocketW in a list and >> remove it from the list when closesocket is called. When the last >> WSACleanup is called it would iterate through the socket list and >> destroy the remaining sockets. >> >> When WSASocketW is called it calls the server to create the socket, >> when closesocket is called the server is also called and the function >> sock_destroy takes care of shutting down the socket. >> >> Currently I'm thinking about doing this in the dll side because the >> server is not aware of WSACleanup, but maybe it should because it >> needs to avoid calling any async operation completion. >> >> My questions are: >> 1) When I open 2 programs that use ws2_32 dll the global variables >> memory is not shared, right? Otherwise the WSAStartup/Cleanup count >> could be messed up if one application didn't call the Cleanup >> function. I hope this true so the socket list would not have to take >> care of different processes id. >> >> I understand that one application can have multiple threads and that's >> what the struct per_thread_data is about, but I hope the dll is not >> shared among different processes. >> >> 2) Is this a reasonable approach? If yes, is there any example of a >> critical protected list (add, iterate, remove items) that I could use? >> >> Best wishes, >> Bruno >> >> > -- universe* god::bigbang (void); //and then it all began...

2 4

Why using WINE not ReactOS-programs?
by theUser BL Feb. 21, 2014

Feb. 21, 2014

What stands on the WINE main-side for one of the new features of WINE 1.7.13? »More Windows Media Player stubs.« So you do not only reimplementing the platform. You also reimplement the MediaPlayer, the InternetExplorer, Wordpad, etc. A month ago, I already asked in the forum, why you don't take ReactOS programs for WINE: http://forum.winehq.org/viewtopic.php?f=8&t=20836 There are programs under the GPL. But some are under the LGPL. For example mspaint: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/mspaint/ It can be possible, that there are programs for Windows, which makes use of mspaint and wants to start it, because it exists since Windows 95. So any Windows-developer can assume, that mspaint exists on the system. Same with some other programs. Greatings theuserbl

2 1

[idea]wine support for Chrome OS
by 中川祥 Feb. 21, 2014

Feb. 21, 2014

Now,we don't run wine in Chrome OS. Google also think they can run windows executable files. My idea is about how to use wine in the OS. Google Chrome has two types of extensions:one is the extension,that support only web technology.the other is PPAPI,Google Native Client. Here's the overview↓ https://developers.google.com/native-client/dev/overview For example,Flash Player uses PPAPI. C/C++ programs can be transformed and run in its sandbox. then we can run wine in Chrome OS. I think if wine supports Chrome OS,Google helps us.

3 5

Re: user32/tests: Add some SetDlgItemTextA tests
by Alexandre Julliard Feb. 21, 2014

Feb. 21, 2014

Bruno Jesus <00cpxxx(a)gmail.com> writes: > This patch was an attempt to reproduce the issue in bug 35621, I could > not get what I wanted but at least here I got the following error > covered in a todo: > > dialog.c:1022: Test failed: GetDlgItemText error, expected 102400, got > 80968. > dialog.c:1023: Test failed: Different text read. Works fine here: ../../../tools/runtest -q -P wine -T ../../.. -M user32.dll -p user32_test.exe.so dialog && touch dialog.ok dialog.c:1022: Test succeeded inside todo block: GetDlgItemText error, expected 102400, got 102400. dialog.c:1023: Test succeeded inside todo block: Different text read. make: *** [dialog.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: secur32: return success on graceful close of SSL connection
by Ken Thomases Feb. 20, 2014

Feb. 20, 2014

On Feb 20, 2014, at 3:41 PM, Aric Stewart wrote: > --- > dlls/secur32/schannel_macosx.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/secur32/schannel_macosx.c b/dlls/secur32/schannel_macosx.c > index 5d88223..1d1df26 100644 > --- a/dlls/secur32/schannel_macosx.c > +++ b/dlls/secur32/schannel_macosx.c > @@ -989,6 +989,8 @@ SECURITY_STATUS schan_imp_recv(schan_imp_session session, void *buffer, > else > TRACE("Read %lu bytes before would block\n", *length); > } > + else if (status == errSSLClosedGraceful) > + return SEC_E_OK; > else > { > WARN("SSLRead failed: %ld\n", (long)status); Every other path has a log line. You could add one to this case, but it's probably just sufficient to put an "or" clause in the noErr condition: if (status == noErr || status == errSSLClosedGraceful) TRACE("Read %lu bytes\n", *length); -Ken

1 0

FFE (force feedback) file format reverse engineered
by Elias Vanderstuyft Feb. 20, 2014

Feb. 20, 2014

Hi, Two weeks ago, I started working on reverse engineering the FFE file format, because the functionality to load and write is currently not available in Wine: http://wiki.winehq.org/ForceFeedbackSummerOfCode2005Summary " Missing functionality: - Reading and writing FF effects to files (IDirectInputDevice8::WriteEffectToFile and IDirectInputDevice8::EnumEffectsInFile) have not been implemented. They are stored in a RIFF file, the details of which are undocumented. Given the nature of RIFF, it should be relatively simple (albeit time-consuming) to determine the exact format of the effect files. " So I wrote a Python program that can read and validate FFE files, based on my assumption of the file format structure. In the Python file: - I tried to maximally expose the relation of the FFE file contents and the RIFF structure. - Every single bit in the FFE file will be tested/validated, and the program will throw a 'Warning' when something odd/against my assumptions, occurred with the file of interest. I did not yet implement write functionality in the Python file, but it should not be difficult (~inverse operation of read). For the CustomForce effect, my assumptions are hypothetical: there was no way to test it, because: - I did not find any file containing such effect - I couldn't create such file, because FEdit.exe does not support CustomForce effects to be created. This should be a starting point to implement these read and write stubs in Wine. I don't have time to do that now, so, maybe someone else is interested to do so? Any feedback is welcome, Best regards, Elias

2 3

Re: [3/3] gdi32/tests: Avoid using GetGlyphIndices directly.
by 中川祥 Feb. 20, 2014

Feb. 20, 2014

What a phrase it is! By the way,please replay to my patches 102290 and 102289. Please comment if they are safe,if true,they will be comitted. 2014-02-19 21:02 GMT+09:00 Akihiro Sagawa <sagawa.aki(a)gmail.com>: > > This makes NT4 happy. > --- > dlls/gdi32/tests/font.c | 45 ++++++++++++++++++++++++++++----------------- > 1 file changed, 28 insertions(+), 17 deletions(-) > > > > >

2 1