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

Abbreviation of "microsecond" in sane.ds

by Alex Henrie

http://source.winehq.org/git/wine.git/blob/c72f9a0082c3cc07454fb93bca88e294… Is there a compelling reason why "microsecond" is abbreviated as "us" instead of "μs"? This library doesn't correspond to any Windows library, so we should be free to use the more correct abbreviation. Or can sane.rc only accept ASCII characters? -Alex

Feb. 23, 2015

Re: [2/2] version: Test for VerQueryValueA

by Mark Jansen

On Mon, Feb 23, 2015 at 9:47 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-02-18 um 22:41 schrieb Mark Jansen: >> + char preparedbuffer[] = { >> + 0x04, 0x01, 0x34, 0x00, 0x00, 0x00, 0x56, 0x00, 0x53, 0x00, 0x5f, 0x00, 0x56, 0x00, 0x45, 0x00, >> + 0x52, 0x00, 0x53, 0x00, 0x49, 0x00, 0x4f, 0x00, 0x4e, 0x00, 0x5f, 0x00, 0x49, 0x00, 0x4e, 0x00, >> + 0x46, 0x00, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00, 0xbd, 0x04, 0xef, 0xfe, 0x00, 0x00, 0x01, 0x00, >> + 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, >> ... > Is it possible to put the test data into dlls/version/test/version.rc in plain text instead of using an unreadable blob? If not, please add a comment to explain what is in the blob. No, this is not possible. This is simply a version info block (with only one entry in it to keep it small, but that doesnt influence the test), compiled in the reactos build environment. This does create a slightly different resource, but the resource is accepted by windows resource parser functions, and not by wine. (as this test shows). > >> + ret = VerQueryValueA(preparedbuffer, "StringFileInfo", (LPVOID*)&p, &len); >> + ok(ret, "VerQueryValue error %u\n", GetLastError()); >> + ok(len == 0, "VerQueryValue returned %u, expected 0\n", len); >> + ok(p != (char *)0xdeadbeef, "not expected 0xdeadbeef\n"); > Does p point to a 0 byte now? (i.e., ok(!*p, "Expected a terminated string\n"); or something like this.) No, p points to a data byte, but it can (should) not be read, since the returned length is 0. Trying to read it is exactly what is going wrong in the wine implementation, since it is a non-null byte. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJU6ukyAAoJEN0/YqbEcdMwivkQAIz6mLYCOP2607ACoDIuX58M > 5oaF83RA4wjqTAtOQYbIGFqTtM0kT5rANLgh5cMkgNETSttl8ZgJlyECUmz8ArHA > VQv0kr0VsgdurFmhoxA37Cw9kou4b2hgsyimfr0dvjahJAroZJgIzXSbtUVgMVQ3 > SUoluqPMSuXod/xW78lVwLI5HLm79/cJdizo+PiWLmLrlNiga6k295eKAfd5Tcco > qHo+bCf56s0FRlaD4eZ+5AWl5nDP0eP7aGpddBtk4a0Y5E/3npD+9KE2L/hIlTdy > kbSSW+NUfWAIUKzVFgVr9m/ejGjTMCb6ieHfuK/7S9oU6jCJyM/mwg++vsgdUJbI > ts03c3UXV/JXGuDSEkxqMNLdhVM0Jv9RLCz4GlwdH7LlSiO9UOGjUpMF2steuULm > FwirfHXCV1FyZBWIZyHfUw9wykoY4613S49Iq3EGZKKPQmzSi0p+Aygm2Mz6+LhM > ApI/rVpGs7rqTxYZWZEgcaadpCGlwczOrgbQYEEoxdaYMm8GbEWRyDXjsHiC9NF4 > RbWV+n69+wzC7bOIYqHQSkXEWNEuFlLjn4MElHCqBkGlwTsw9HIPofN6wDbORONt > xKP5s14VduDyJdT21jYLJJUvIxO3R7OSNxoWIoKBOofFlQeT0c6WHvnqSqW9e7ED > sX3108dzC77WwIVODqFm > =gsJF > -----END PGP SIGNATURE-----

Feb. 23, 2015

Re: [PATCH 2/3] ntdll/tests: Add tests for RtlIpv6StringToAddress (try 3)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-20 um 16:07 schrieb Mark Jansen: > Hey, > > I do not have the intention to rewrite the ipv4 tests now, i do have > another few tests lined up for different ipv6 functions (addr2str), > i'll look into rewriting the ipv4 then. > As for now, few tests are better than no tests, right? That's OK with me. I recommend to move the ipv4 test to the end of the patch series in this case. That way Alexandre can apply the ipv6 patch if he disagrees with the partial ipv4 test. > Broken means xp pro, 2003, vista and 2008 did not behave correct. What behaves correctly? Windows 7? >>> + if (ipv6_tests[i].ex_fails == 2) /* testing vs ex doesnt >make sense. */ >>> + continue; >> Please document why, it took me a while to come up with the guess above. (And I'm not even sure it's the real reason). You're also not checking the output IP for the IP tests from the non-ex tests here. Is there a reason for that? Are there any cases where -Ex returns a different IP than non-ex? > Because the function will succeed on ex, it is even in the ex-test table. > Cases like this are exactly why i didnt want it in one table in the first place. There's no problem with running a test or two twice in a situation like this. The reason why you need special handling for this test is that it is the only test that fails on base and succeeds on ex. Your way of handling this works reasonably well, it's just that the comment could be better. E.g. something like "Fails on base, succeeds on -Ex. Success case tested by -Ex test table." would be a better explanation why the test is skipped. Alternatively you can remove the test from the base table and test it with a separate function call in the base tests. > Probably not, but I was under the impression that windows doesnt run > on big endian machines. > If wine does run on big endian this might need an additional check, > however i do not have a b.e. machine to verify it on. Yeah, it is a fairly academic question. Even Windows NT on Power was little endian. I vaguely remembered that there were helper functions for manipulating IP addresses that take care of endianess. I didn't find any though, just the hostname resolving string-to-IP ones. > Ex doesnt write anything if it fails. This line from the -ex table suggests something else: > + { "[3ffe:2a00:100:7031::1].8080", STATUS_INVALID_PARAMETER, 0xbadf00d, 0xbeef, { 0xfe3f, 0x2a, 1, 0x3170, 0, 0, 0, 0x100 } }, This has a working address and broken port though. Things may be different if the address parsing fails. Please add an ip == 0xabab comparison in the part of the -ex test that runs the non-ex / IP address checks, and check the returned address in case the function succeeds. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU6vHGAAoJEN0/YqbEcdMwKnYP/A7urRWmo4/qu8xtXtXLYCoU QThhth9J4gMRFQUazH1JaocyeXcLeZ8fXSKSgV+2TM3b7qZIjJVljlNR6ySPJheS SMZ9dAmrngWZj418SMwqAYjyMeqNWDcn+/zRqr39AIgSh5J6K0YyV1XwzsJRUuV+ C7sEGzlCupiS1N5V0xB5OggE7E2cIFItbHjNhTPmO2YVht8fvf/8Z0CnlVtDPswp H6o7TgNqhCuZGD5K0sU+XHwMxN/bn8wJkG85OKA20CgS0nJPTPb8BkHaIGClx3dF zXNxS32fEEa3S1JlsRSb66c/0Whi3GyyrrKhN2aNKZI8t5tS5GzWPG4vwtVyDZnh 7BSzAl5TQDiLWLjFc5skPpNU3rvm8Vg13WYa1ahnw33hL23U52MJZZYQS84CoiVp rbeUqLWbu4tiTYsUgmfcvnKNfFOXLF1Pzd4fGEW5kI54t5NRvSWmWKqnsvglLYjJ Tp8juavhqMjv1WjZdz6N2VURKhR5mg44pAL9V0cbFcPsKikSSKXBAEwSAmwu1WN7 XYPPrQhlhmxGk9DUBOzM3V/gwNqm1z9K6ou7MJQrpudTFleWXn6gUOIZkX+lHaPl eHjMV5wXueIIrVFuGaEKcF+bVBdaziOEzu0XSUHCV2eD1vg5c0bN09YxkahxNm8w mfzirl4vY77ymgYPrWqb =wzpF -----END PGP SIGNATURE-----

Feb. 23, 2015

Re: [2/2] version: Test for VerQueryValueA

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-18 um 22:41 schrieb Mark Jansen: > + char preparedbuffer[] = { > + 0x04, 0x01, 0x34, 0x00, 0x00, 0x00, 0x56, 0x00, 0x53, 0x00, 0x5f, 0x00, 0x56, 0x00, 0x45, 0x00, > + 0x52, 0x00, 0x53, 0x00, 0x49, 0x00, 0x4f, 0x00, 0x4e, 0x00, 0x5f, 0x00, 0x49, 0x00, 0x4e, 0x00, > + 0x46, 0x00, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00, 0xbd, 0x04, 0xef, 0xfe, 0x00, 0x00, 0x01, 0x00, > + 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, > ... Is it possible to put the test data into dlls/version/test/version.rc in plain text instead of using an unreadable blob? If not, please add a comment to explain what is in the blob. > + ret = VerQueryValueA(preparedbuffer, "StringFileInfo", (LPVOID*)&p, &len); > + ok(ret, "VerQueryValue error %u\n", GetLastError()); > + ok(len == 0, "VerQueryValue returned %u, expected 0\n", len); > + ok(p != (char *)0xdeadbeef, "not expected 0xdeadbeef\n"); Does p point to a 0 byte now? (i.e., ok(!*p, "Expected a terminated string\n"); or something like this.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU6ukyAAoJEN0/YqbEcdMwivkQAIz6mLYCOP2607ACoDIuX58M 5oaF83RA4wjqTAtOQYbIGFqTtM0kT5rANLgh5cMkgNETSttl8ZgJlyECUmz8ArHA VQv0kr0VsgdurFmhoxA37Cw9kou4b2hgsyimfr0dvjahJAroZJgIzXSbtUVgMVQ3 SUoluqPMSuXod/xW78lVwLI5HLm79/cJdizo+PiWLmLrlNiga6k295eKAfd5Tcco qHo+bCf56s0FRlaD4eZ+5AWl5nDP0eP7aGpddBtk4a0Y5E/3npD+9KE2L/hIlTdy kbSSW+NUfWAIUKzVFgVr9m/ejGjTMCb6ieHfuK/7S9oU6jCJyM/mwg++vsgdUJbI ts03c3UXV/JXGuDSEkxqMNLdhVM0Jv9RLCz4GlwdH7LlSiO9UOGjUpMF2steuULm FwirfHXCV1FyZBWIZyHfUw9wykoY4613S49Iq3EGZKKPQmzSi0p+Aygm2Mz6+LhM ApI/rVpGs7rqTxYZWZEgcaadpCGlwczOrgbQYEEoxdaYMm8GbEWRyDXjsHiC9NF4 RbWV+n69+wzC7bOIYqHQSkXEWNEuFlLjn4MElHCqBkGlwTsw9HIPofN6wDbORONt xKP5s14VduDyJdT21jYLJJUvIxO3R7OSNxoWIoKBOofFlQeT0c6WHvnqSqW9e7ED sX3108dzC77WwIVODqFm =gsJF -----END PGP SIGNATURE-----

Feb. 23, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 7)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks again for your work! Am 2015-02-23 um 08:41 schrieb Alistair Leslie-Hughes: > +{ > + if (!This->comp_count) > + This->components = heap_alloc( sizeof(struct component *) * This->comp_count+1 ); > + else > + This->components = heap_realloc(This->components, sizeof(struct component *) * This->comp_count+1 ); > + > + This->components[This->comp_count] = item; > + This->comp_count++; > +} This still has no error checks. > @@ -369,9 +397,48 @@ static HRESULT WINAPI IDirectPlay8AddressImpl_GetComponentByIndex(IDirectPlay8Ad > const DWORD dwComponentID, WCHAR *pwszName, DWORD *pdwNameLen, void *pvBuffer, > DWORD *pdwBufferSize, DWORD *pdwDataType) > { > ... > + if (!pdwNameLen || !pdwBufferSize) > + return E_POINTER; In GetComponentByName you have additional checks for !pvBuffer. What is pwszName name used for? Are you supposed to write the name of the retrieved component (with proper length checks)? > case DPNA_DATATYPE_STRING: > + if(dwDataSize != ((strlenW((WCHAR*)lpvData)+1) * sizeof(WCHAR))) > + return DPNERR_INVALIDPARAM; I expect this also applies to DPNA_DATATYPE_STRING_ANSI. Please move it to a separate patch (preferably before the GetComponentByIndex changes), together with the tests for the length check. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU6uQ9AAoJEN0/YqbEcdMwW4wP/0wYOQ+Sw3FZw/TAQ682yMmb FJBuRuymWoQthCAnc7kS7wsDwz+erbNPqjFE/MUrbuTHeIRtRJegtMTcLsq/ycSx pzV9uaZoG9MkGMPky/TTgWAyOvWu6w1fVBgUunnQlX8okMk+HMve+qiayeuHSgj9 CyznrrG/gLsVamZfJidnpMlwJ3a2Az5GOYG3yoCKGEiBzthS8niRvf4PLrNa/T5s /YUcfoorChwNnTEu1F+BEJt/CJTFy+qnrGOplDo5cCG6XJ9cK10JEsXybShSA1LT byol2yxMHNR1MdKw/ZsDJiS8RDnCPKTZiaY45FB7BZkyle5J/jJ9wfkBX/L+ID3M mMM1qo5nKjjbiICMkYIRHO4LW9lyCT4FKBLkXwGWTo7Npxpb7iB5Jo2X5sl8o3K4 d1TL7kjdmIj3nz+TbPyVrZZHV4GkBJ3Wgmv1b+uNdPQ6SSotzy6I6FzG1YkivQvF mo8cFFJTs0OO/fUBN5wggkiU4YAheHn258wz7EcepyPMH431GsFp9QVcZbNEQVNi hEasoqLeql/GzI0ZRmOLTLdueVsajZGhoHLGgN10SSql60dfsPZhfpQMrhsX8HQf Ub5SXqAWAc3vZmvv1I1POyUATNxTV8WWZfSmd7QBv+4qsJX2hsXE3Y4/I8cmIv0I OonvF4surL4lU+vFIkJC =eOzT -----END PGP SIGNATURE-----

Feb. 23, 2015

Re: fltmgr.sys: add stub dll (try 2)

by Alistair Leslie-Hughes

On 11/02/15 08:15, Austin English wrote: > https://bugs.winehq.org/show_bug.cgi?id=23583 > > -- > -Austin > This file belongs in the "system32\drivers" directory. Best Regards Alistair Leslie-Hughes

Feb. 23, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 7)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11662 Your paranoid android. === w8 (32 bit address) === The test timed out

Feb. 23, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 6)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11659 Your paranoid android. === w2000pro (32 bit address) === address.c:100: Test failed: got 0x80070057 === wxppro (32 bit address) === address.c:100: Test failed: got 0x80070057 === w2003std (32 bit address) === address.c:100: Test failed: got 0x80070057 === wvistau64 (32 bit address) === address.c:100: Test failed: got 0x80070057 === w2008s64 (32 bit address) === address.c:100: Test failed: got 0x80070057 === w7u (32 bit address) === address.c:100: Test failed: got 0x80070057 === w8 (32 bit address) === The test timed out === wvistau64 (64 bit address) === address.c:100: Test failed: got 0x80070057 === w2008s64 (64 bit address) === address.c:100: Test failed: got 0x80070057

Feb. 23, 2015

Re: Want to work in your project in Google summer of code 2015

by Austin English

On Sat, Feb 21, 2015 at 9:27 PM, Shanti Swarup Tunga <b112041(a)iiit-bh.ac.in> wrote: > Sir > I Shanti Swarup Tunga , having good knowledge in C programming want to > work in your project . So kindly suggest me some prerequisite knowledge > to apply for your project. > > Hi Shanti, The information for Google Summer of Code can be found at: http://wiki.winehq.org/SummerOfCode You'd need to be knowledgeable about the win32 api, and potentially others depending on the project. You'll need to either pick or propose a project (the latter is preferred). You can search https://bugs.winehq.org for bugs that interest you. -- -Austin

Feb. 22, 2015

Want to work in your project in Google summer of code 2015

by Shanti Swarup Tunga

Sir I Shanti Swarup Tunga , having good knowledge in C programming want to work in your project . So kindly suggest me some prerequisite knowledge to apply for your project.

Feb. 22, 2015