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

Re: README: add a note about 64-bit Wine needing 32-bit Wine to work

by Rosanne DiMesio

On Mon, 30 Nov 2015 13:40:51 +0800 Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > I'd argue that users should be strongly advised to use pre-built wine packages > because building a package requires a lot of intimate knowledge. --CentOS/RHEL/Scientific Linux packages are pure 64 bit. Users have been begging for months for proper packages. Red Hat has refused to provide them and now so have we. --FreeBSD packages both 32 and 64 bit Wine, but doesn't support WoW64. https://forum.winehq.org/viewtopic.php?f=2&t=25600 -- Rosanne DiMesio <dimesio(a)earthlink.net>

Nov. 30, 2015

Re: secur32: Remove a dead assignment (Clang)

by Lauri Kenttä

On 2015-11-29 23:31, André Hentschel wrote: > - pfQOP = &fQOP; Surely nobody would write that kind of dead assignment if there wasn't some intended function for it. I wonder if this was supposed to be: if (pfQOP) *pfQOP = fQOP; After all, the parameter is designated as _Out_ in MSDN. -- Lauri Kenttä

Nov. 30, 2015

Fwd: rsaenh: Remove dead assignments (Clang)

by Henri Verbeet

On 29 November 2015 at 23:39, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > This and advapi32 looks like was done on purpose. Why are you removing that? > Regardless of the merit of the various patches in this series, I think at best this kind of thing should get a "Deferred".

Nov. 30, 2015

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (try 2)

by Jacek Caban

Hi Zhenbo, On 11/27/15 15:49, Zhenbo Li wrote: > 2015-11-14 17:33 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: >> > >> > Also, I found that there was a hidden bug: >> > As we will test these urls for responseXML: >> > static const char xml_url[] = "http://test.winehq.org/tests/xmltest.xml"; >> > static const char large_page_url[] = >> > "http://test.winehq.org/tests/data.php"; >> > >> > char large_page_url is not a valid xml file, but native mshtml.dll can >> > handle it properly. It shows we can't just past the responseText to >> > msxml3.dll. I'll check it more carefully it later. > Hi, sorry for my late reply. > I tested it on testbot, and found that Windows mshtml.dll would return > an empty xml object It looks better now. > > static BOOL doc_complete; > static IHTMLDocument2 *notif_doc; > +static BOOL ILLEGAL_XML; Using this global variable makes things harder to follow. Please add a new argument to test_sync_xhr instead. > @@ -334,8 +337,52 @@ static HRESULT WINAPI HTMLXMLHttpRequest_get_responseText(IHTMLXMLHttpRequest *i > static HRESULT WINAPI HTMLXMLHttpRequest_get_responseXML(IHTMLXMLHttpRequest *iface, IDispatch **p) > { > HTMLXMLHttpRequest *This = impl_from_IHTMLXMLHttpRequest(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + IXMLDOMDocument *xmldoc = NULL; > + BSTR str; > + HRESULT hres; > + VARIANT_BOOL vbool; > + IObjectSafety *safety; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + hres = CoCreateInstance(&CLSID_DOMDocument, NULL, CLSCTX_INPROC_SERVER, &IID_IXMLDOMDocument, (void**)&xmldoc); > + if(FAILED(hres)) { > + ERR("CoCreateInstance failed: %08x\n", hres); > + return hres; > + } > + > + hres = IHTMLXMLHttpRequest_get_responseText(iface, &str); > + if(FAILED(hres)) { > + IXMLDOMDocument_Release(xmldoc); > + ERR("get_responseText failed: %08x\n", hres); > + return hres; > + } > + > + hres = IXMLDOMDocument_loadXML(xmldoc, str, &vbool); > + SysFreeString(str); > + if(hres != S_OK || vbool != VARIANT_TRUE) { > + ERR("loadXML failed: %08x, returning an cmpty xmldoc\n", hres); > + } ERR is not appropriate here. Please use WARN instead. > + > + hres = IXMLDOMDocument_QueryInterface(xmldoc, &IID_IObjectSafety, (void**)&safety); > + if(SUCCEEDED(hres)) { Again, this error handling is more complicated than it needs to be. Please use assert(hres == S_OK) instead. > + hres = IObjectSafety_SetInterfaceSafetyOptions(safety, NULL, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER, > + INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER); > + IObjectSafety_Release(safety); > + if(FAILED(hres)) { Same here. Thanks, Jacek

Nov. 30, 2015

Re: [v2] ieframe: Don't release the advise sink in IOleObject::SetClientSite.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

Nov. 30, 2015

Re: wininet: Fix allocation error handling (Clang)

by Jacek Caban

Hi André, On 11/29/15 19:53, André Hentschel wrote: > diff --git a/dlls/wininet/cookie.c b/dlls/wininet/cookie.c > index 4784b33..0b7f5e1 100644 > --- a/dlls/wininet/cookie.c > +++ b/dlls/wininet/cookie.c > @@ -713,7 +713,8 @@ DWORD get_cookie_header(const WCHAR *host, const WCHAR *path, WCHAR **ret) > > *ret = header; > }else { > - res = ERROR_NOT_ENOUGH_MEMORY; > + LeaveCriticalSection(&cookie_cs); > + return ERROR_NOT_ENOUGH_MEMORY; How about returning res in the bottom of the function? Thanks, Jacek

Nov. 30, 2015

Re: Make a 16-bit test in wine for krnl386.exe16

by Michael Stefaniuc

On 11/30/2015 03:47 AM, Bruno Jesus wrote: > On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> On 29.11.2015 20:30, Bruno Jesus wrote: >>> >>> Hi all, I'm trying to create tests for GetPrivateProfileString16 but >>> it is not working as expected because the test is calling the kernel32 >>> version of the function instead of the krnl386.exe16. >>> >>> Is there any way to make a test that compiles and runs against krnl386 >>> instead of kernel32? >>> >>> I tried a few different things and the attached patch is the last >>> attempt (the tests are wrong but that is not the point yet). >>> >> >> I think the main problem is to actually be able to build NE binaries, >> for that you'll need tools that support this, for example openwatcom C >> compiler, or some old enough Visual C++, maybe version 5 or 4. > > So basically it is not possible to integrate such tests in wine as a > standard test like any other. Afair Dan Kegel worked on that back in the days. Might be still available somewhere on the net. The easiest would be to take that and make it a separate project aka keep it out of tree. Providing a prebuilt winetest16.exe would make it easy for people to test without having to go through the pain of setting the build environment up. bye michael

Nov. 30, 2015

Re: rsaenh: Remove dead assignments (Clang)

by Marcus Meissner

On Mon, Nov 30, 2015 at 01:39:09AM +0300, Nikolay Sivov wrote: > On 30.11.2015 0:31, André Hentschel wrote: > >Signed-off-by: André Hentschel <nerv(a)dawncrow.de> > >--- > > dlls/rsaenh/sha2.c | 21 --------------------- > > 1 file changed, 21 deletions(-) > > > >diff --git a/dlls/rsaenh/sha2.c b/dlls/rsaenh/sha2.c > >index 76e7184..71ebf23 100644 > >--- a/dlls/rsaenh/sha2.c > >+++ b/dlls/rsaenh/sha2.c > >@@ -369,9 +369,6 @@ void SHA256_Transform(SHA256_CTX* context, const sha2_word32* data) { > > context->state[5] += f; > > context->state[6] += g; > > context->state[7] += h; > >- > >- /* Clean up */ > >- a = b = c = d = e = f = g = h = T1 = 0; > > } > > > > #else /* SHA2_UNROLL_TRANSFORM */ > >@@ -449,9 +446,6 @@ void SHA256_Transform(SHA256_CTX* context, const sha2_word32* data) { > > context->state[5] += f; > > context->state[6] += g; > > context->state[7] += h; > >- > >- /* Clean up */ > >- a = b = c = d = e = f = g = h = T1 = T2 = 0; > > } > > > > #endif /* SHA2_UNROLL_TRANSFORM */ > >@@ -483,8 +477,6 @@ void SHA256_Update(SHA256_CTX* context, const sha2_byte *data, size_t len) { > > /* The buffer is not yet full */ > > MEMCPY_BCOPY(&context->buffer[usedspace], data, len); > > context->bitcount += len << 3; > >- /* Clean up: */ > >- usedspace = freespace = 0; > > return; > > } > > } > >@@ -500,8 +492,6 @@ void SHA256_Update(SHA256_CTX* context, const sha2_byte *data, size_t len) { > > MEMCPY_BCOPY(context->buffer, data, len); > > context->bitcount += len << 3; > > } > >- /* Clean up: */ > >- usedspace = freespace = 0; > > } > > > > void SHA256_Final(sha2_byte digest[], SHA256_CTX* context) { > >@@ -564,7 +554,6 @@ void SHA256_Final(sha2_byte digest[], SHA256_CTX* context) { > > > > /* Clean up state data: */ > > MEMSET_BZERO(context, sizeof(*context)); > >- usedspace = 0; > > } > > > > char *SHA256_End(SHA256_CTX* context, char buffer[]) { > >@@ -693,9 +682,6 @@ void SHA512_Transform(SHA512_CTX* context, const sha2_word64* data) { > > context->state[5] += f; > > context->state[6] += g; > > context->state[7] += h; > >- > >- /* Clean up */ > >- a = b = c = d = e = f = g = h = T1 = 0; > > } > > > > #else /* SHA2_UNROLL_TRANSFORM */ > >@@ -771,9 +757,6 @@ void SHA512_Transform(SHA512_CTX* context, const sha2_word64* data) { > > context->state[5] += f; > > context->state[6] += g; > > context->state[7] += h; > >- > >- /* Clean up */ > >- a = b = c = d = e = f = g = h = T1 = T2 = 0; > > } > > > > #endif /* SHA2_UNROLL_TRANSFORM */ > >@@ -805,8 +788,6 @@ void SHA512_Update(SHA512_CTX* context, const sha2_byte *data, size_t len) { > > /* The buffer is not yet full */ > > MEMCPY_BCOPY(&context->buffer[usedspace], data, len); > > ADDINC128(context->bitcount, len << 3); > >- /* Clean up: */ > >- usedspace = freespace = 0; > > return; > > } > > } > >@@ -822,8 +803,6 @@ void SHA512_Update(SHA512_CTX* context, const sha2_byte *data, size_t len) { > > MEMCPY_BCOPY(context->buffer, data, len); > > ADDINC128(context->bitcount, len << 3); > > } > >- /* Clean up: */ > >- usedspace = freespace = 0; > > } > > > > void SHA512_Last(SHA512_CTX* context) { > > > > This and advapi32 looks like was done on purpose. Why are you removing that? The usual idea in cryptography is to zeroize temporary components. The compiler will optimize away however if its just stack space :( Ciao, Marcus

Nov. 30, 2015

RE: kernel32/tests: Fix the argument order in some console font tests

by Hugh McMaster

On Sat, 28 Nov 2015 22:31:53 -0600, Marvin wrote: > > 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=18627 > > Your paranoid android. > > > === w8 (32 bit console) === > console.c:1445: Test failed: [13] Expected output count to be 0, got 2359244 > console.c:1445: Test failed: [15] Expected output count to be 0, got 2359244 > console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2359244 > console.c:1689: Test failed: [13] Expected output count to be 0, got 2359244 > console.c:1689: Test failed: [15] Expected output count to be 0, got 2359244 > console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2359244 > > === w864 (32 bit console) === > console.c:1445: Test failed: [13] Expected output count to be 0, got 2686924 > console.c:1445: Test failed: [15] Expected output count to be 0, got 2686924 > console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2686924 > console.c:1689: Test failed: [13] Expected output count to be 0, got 2686924 > console.c:1689: Test failed: [15] Expected output count to be 0, got 2686924 > console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2686924 > > === w1064 (32 bit console) === > console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 > console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 > console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 > console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 > console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed > console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 > console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 > console.c:1445: Test failed: [13] Expected output count to be 0, got 2752460 > console.c:1445: Test failed: [15] Expected output count to be 0, got 2752460 > console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2752460 > console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 > console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 > console.c:1689: Test failed: [13] Expected output count to be 0, got 2752460 > console.c:1689: Test failed: [15] Expected output count to be 0, got 2752460 > console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2752460 > console.c:2148: Test failed: [7] Expected count to be 0, got 1 > console.c:2214: Test failed: [7] Expected count to be 0, got 1 > console.c:2280: Test failed: [7] Expected count to be 0, got 1 > > === w1064 (64 bit console) === > console.c:1445: Test failed: [13] Expected output count to be 0, got 2037567264 > console.c:1445: Test failed: [15] Expected output count to be 0, got 2037567264 > console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 2037567264 > console.c:1689: Test failed: [13] Expected output count to be 0, got 2037567264 > console.c:1689: Test failed: [15] Expected output count to be 0, got 2037567264 > console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 2037567264 These are existing failures. -- Hugh McMaster

Nov. 30, 2015

Re: README: add a note about 64-bit Wine needing 32-bit Wine to work

by Dmitry Timoshkov

Sebastian Lackner <sebastian(a)fds-team.de> wrote: > >> programs/winemenubuilder/winemenubuilder.c: > >> fprintf(file, "Exec=env WINEPREFIX=\"%s\" wine %s %s\n", > >> > >> tools/wineapploader.in > >> exec wine "$appname" "$@" > > > > That's just a symlink to the launcher, and probably it should depend on > > actual build. > > > >> Not sure if there is a way to express it a bit better, but I think in general it > >> probably wouldn't hurt to have this documented somewhere in the source tree. > > > > Sure. > > > > Actually, when I think a bit more about it, instead of adding more documentation, > we probably just want to fix those few remaining symlink / wrapper script > problems. Of course it will still confuse unexperienced users who want to run > their 32-bit apps, but at least experienced users could use it as an (almost) > fully functional standalone Wine version then - of course at their own risk. ;) I'd argue that users should be strongly advised to use pre-built wine packages because building a package requires a lot of intimate knowledge. All these mixed WoW setups, "soft" dependencies (which are actually "hard" for production builds), multiarch nuances, and some other things that experianced packagers are aware about may easily cause endless headaches for a user. For instance using mixed WoW64 setup may actually break more things than fix, bugzilla has numerous bug reports about that. That's what actually needs to be added to the readme imho. -- Dmitry.

Nov. 30, 2015