wine-devel November 2015

wine-devel@winehq.org

69 participants
272 discussions

Re: Shell32: Check null handles before freeing
by Nikolay Sivov 01 Dec '15

01 Dec '15

On 25.11.2015 10:02, Olivier F. R. Dierick wrote: > Fix one of the error leak source that prevents the installer to succeed > (bug 36838). > > The original code did not check if the handles were null before freeing > them. For some reason they happen to be null and last error is set to > ERROR_INVALID_HANDLE. The game installer chokes at some point when the > last error is anything but zero and fails to complete the installation. > Checking if the handles are non-null before freeing them avoids this. > According to MSDN, it is not an error to have null values for those > handles. > > Signed-off-by: Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> > --- > dlls/shell32/changenotify.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > We most likely have many more places that do same thing, it will need tests for SHFree() and CoTaskMemFree(). If it turns out error is not changed on NULLs, it's easier to return early from SHFree or CoTaskMemFree than fix all places where those are used.

2 2

Make a 16-bit test in wine for krnl386.exe16
by Bruno Jesus 01 Dec '15

01 Dec '15

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). Any help is appreciated, thanks in advance, Bruno

7 11

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (try 2)
by Jacek Caban 30 Nov '15

30 Nov '15

Hi Zhenbo, On 11/04/15 15:34, Zhenbo Li wrote: > Try 2: > Thanks Nikolay & Jacek > Making the ERR() less verbose > > > Signed-off-by: Zhenbo Li <litimetal(a)gmail.com> > --- > dlls/mshtml/tests/xmlhttprequest.c | 41 +++++++++++++++++++++++++++++ > dlls/mshtml/xmlhttprequest.c | 53 > ++++++++++++++++++++++++++++++++++++-- > 2 files changed, 92 insertions(+), 2 deletions(-) Sorry for the delay, I was waiting for wine-devel discussion to come to conclusion, but failed to reply when it did. It would be nice to move it from pending state, although I'm not sure we can do that before code freeze. + + hres = IXMLDOMDocument_loadXML(xmldoc, str, &vbool); + SysFreeString(str); + if(hres != S_OK || vbool != VARIANT_TRUE) { + ERR("loadXML failed: %08x\n", hres); + IXMLDOMDocument_Release(xmldoc); + return hres; + } Note that if loadXML fails, you will return S_FALSE here, which I'm sure is desired. It would be nice to have a test for that. Also discussion with Nikolay convinced me that assert() would be a better way to handle IObjectSafety errors. Thanks, Jacek

3 4

Learning to Develop for the Wine Project
by David Reinert 30 Nov '15

30 Nov '15

Hello Friends, I am a current undergraduate senior Computer Science major looking to become familiar with and contribute to Wine. I just want to make sure I am doing all the best things I can do to familiarize myself with the project. I have over 3 years of experience coding in C/C++ and I have taken a course in Operating systems, but my familiarity with any MS-DOS/Windows based OS(DLLs, etc.) is next to none and I understand that the learning curve for Wine development is very steep. I've started by reading through the Wine Developer's Guide Wine Architecture section to try and gain an understanding of how the whole process operates. is this useful? Is there anything else that anyone would recommend I do to gain to good understanding of the project or should I just start writing patches and dive in head first? Any and all suggestions are welcome and Iwould appreciate any advice. Thanks, David Reinert

2 1

Wine devel packages ready for testing
by Michael Müller 30 Nov '15

30 Nov '15

Hi, at WineConf we discussed about providing binary packages and the idea was that Sebastian and I take care of this, since we already build packages for Wine Staging. We now altered our build system to work in a more general way and you can now try out the first packages. We already tested them shortly, but since we do not use all those distros on a daily basis, we might still have missed something. Before I tell you the distribution specific installation instructions, first a more general overview about how the packages work. There are already a lot of different Wine packages out there, so our goal was to choose names which are not yet used on any system. To keep the risk of name collisions as small as possible, we decided for the following approach: winehq-devel winehq-staging These are the names of the packages which are most suitable for average users. The package will provide programs in /usr/bin (or some other distro-specific default installation path) and provide all the usual wine-specifc commands, like "wine", "winegcc", "wineserver", ... and so on. It will also contain the manpages, and desktop files. In the background, those packages do not really contain the binaries but instead pull in additional dependencies, on Debian/Ubuntu the "wine-devel" package and on Fedora/Mageia the "wine-development" package. Those packages install wine in /opt/wine-devel. On the one hand this makes clear, that its not a distribution provided package, as all files reside in /opt, on the other hand it gives much more flexibility. A user can now decide whether to install the winehq-devel package, which symlinks all files to their usual locations in /usr/{bin, share} etc. or whether he wants to install multiple wine versions at the same time by using the underlying wine-devel/wine-development package. Besides the possibility of having multiple wine versions installed at the same time, this way we could even ship additional dynamically linked libraries without messing around with the rest of the system, for example if distribution packages are incompatible with wine. Below are the instructions how to install those packages on various distributions. Executing wine --version (or /opt/wine-devel/bin/wine --version) should afterwards show 1.8rc-1. If you find any bugs, please report them so that we can fix them. You can also take a look at the packaging files at https://github.com/wine-compholio/wine-packaging (or send a pull request if you want to contribute with your improvements). In case everything is working fine, we should add those packages on the download page, so that more users can try out the release candidates for 1.8. So, as a short summary, about what is already working, and what still needs to be done: - We'll now be able to provide 8 Ubuntu, 8 Debian, 4 Mageia and 2 Fedora packages per release (which means about 44 build tasks per week). - Fedora 23 packages are still missing, but will be added soon. - Crosscompiled Mac OS X packages will also be added soon. - Additional distributions can be added on request - but please try to contact your distribution first! ---- Ubuntu ---- # Add repository sudo add-apt-repository ppa:wine/wine-builds # Update packages sudo apt-get update sudo apt-get install --install-recommends winehq-devel # Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions. ---- Debian ---- # Enable 32 bit packages sudo dpkg --add-architecture i386 # Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key # Add repository to /etc/apt/sources.list or create a *.list # under /etc/apt/sources.list.d/ with the following content: deb https://dl.winehq.org/wine-builds/debian/ DISTRO main # with DISTRO being either wheezy, jessie, stretch or sid # Update packages sudo apt-get update sudo apt-get install winehq-devel # Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions. ---- Fedora ---- # Currently only Fedora 22 is supported, 23 will be added soon # Add repository dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/22/winehq.repo dnf apt-get install winehq-devel # Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions. ---- Mageia ---- # Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo rpm --import Release.key # If you are using Mageia 4 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/4/i586/ # If you are using 64-bit Mageia 4, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/ # If you are using Mageia 5 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/5/i586/ # If you are using 64-bit Mageia 5, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/ sudo urpmi.update -a sudo urpmi winehq-devel # Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions. ------------------ Regards, Michael

4 7

Re: [PATCH] ddraw/tests: Test color keys on cube map surfaces.
by Marvin 30 Nov '15

30 Nov '15

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=18665 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2252: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000 === w1064 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000

1 0

(OT) code siging on Mac OSX Re: Wine devel packages ready for testing
by Hin-Tak Leung 30 Nov '15

30 Nov '15

(going off topic) -------------------------------------------- On Mon, 30/11/15, Michael Müller <michael(a)fds-team.de> wrote: ... It is indeed difficult to sign executables without using any proprietary tools by Apple, but it seems like I found one which works. "codesign -vd wine" seems to like my signature, except that the tool slightly messed up the timestamp of the signature which now lies before the creation date of my self signed certificate. ... Can you tell me more about the open tool used for signing Mac OS X executables? I have been working on font signing in the recently open-sourced microsoft font validator (there is an official windows-only tool for signing fonts, but apparently an open-toolchain based tool also exist in somebody's hard disk) That although is part of an ISO standard for fonts, borrows heavily from microsoft's authenticode excutable signing infrastructure. For those who want to know. Hin-Tak

1 0

Re: rsaenh: Remove dead assignments (Clang)
by Nikolay Sivov 30 Nov '15

30 Nov '15

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?

4 3

Re: secur32: Remove a dead assignment (Clang)
by Lauri Kenttä 30 Nov '15

30 Nov '15

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ä

2 1

Re: wininet: Fix allocation error handling (Clang)
by Jacek Caban 30 Nov '15

30 Nov '15

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

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2015