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

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

by Austin English

On Sun, Nov 29, 2015 at 8:46 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel <nerv(a)dawncrow.de> wrote: >> Am 29.11.2015 um 18:30 schrieb Bruno Jesus: >>> 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). >> >> Hi Bruno, >> >> winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code) >> > > Hi, I'm compiling a standard wine test so gcc is being used and it does > not recognize -m16. I then tried to change the Makefile compiler to > winegcc and I get: > > winegcc -c -o profile.o > ../../../../wine/dlls/krnl386.exe16/tests/profile.c -I. \ > -I../../../../wine/dlls/krnl386.exe16/tests -I../../../include > -I../../../../wine/include \ > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement \ > -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits > -Wunused-but-set-parameter \ > -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf \ > -fno-omit-frame-pointer -g -O0 -m16 -nodefaultlibs > gcc: error: unrecognized command line option ‘-m16’ > > So in the end winegcc is calling gcc. What about -nodefaultlibs? -- -Austin

Nov. 30, 2015

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

by Bruno Jesus

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.

Nov. 30, 2015

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

by Bruno Jesus

On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > Am 29.11.2015 um 18:30 schrieb Bruno Jesus: >> 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). > > Hi Bruno, > > winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code) > Hi, I'm compiling a standard wine test so gcc is being used and it does not recognize -m16. I then tried to change the Makefile compiler to winegcc and I get: winegcc -c -o profile.o ../../../../wine/dlls/krnl386.exe16/tests/profile.c -I. \ -I../../../../wine/dlls/krnl386.exe16/tests -I../../../include -I../../../../wine/include \ -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement \ -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter \ -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -g -O0 -m16 -nodefaultlibs gcc: error: unrecognized command line option ‘-m16’ So in the end winegcc is calling gcc.

Nov. 30, 2015

Re: Wine devel packages ready for testing

by Austin English

On Sun, Nov 29, 2015 at 4:25 PM, Michael Müller <michael(a)fds-team.de> wrote: > We added Fedora 23 yesterday and uploaded all builds for 1.8-rc2. The > instructions for Fedora 23 are basically the same as for Fedora 22, just > replace the version number in the url: > > dnf config-manager --add-repo > https://dl.winehq.org/wine-builds/fedora/23/winehq.repo > dnf apt-get install winehq-devel > > > Am 27.11.2015 um 20:19 schrieb Aaryaman Vasishta: >> How long until the cross compiled OSX packages arrive? Could you put up >> the scripts on GitHub or does it have to be fully working before you do so? > > All scripts can be found in the following two repositories: > https://github.com/wine-compholio/wine-packaging > https://github.com/wine-compholio/wine-build-tools > > We are planning to wait until the Mac OS X builds for wine-devel work, > before we add the scripts. Our current solution is to cross compile Wine > on Debian as host distribution and this requires a lot of additional > tools plus dependencies. Currently most of the tools and dependencies we > use for Wine Staging are precompiled binaries that were manually > compiled some time ago. This is not really a good solution as it > somewhat obfuscates the build process. We would like to find a better > solution for this. When we are done, we will add everything necessary > (excluding the OS X 10.8 SDK), but it might be a bit difficult to setup, > especially if you don't want to use a VM for building. I'm not sure where you plan on installing wine on OS X, but be aware that 10.11/El Capitan forbids installing into /usr (except /usr/local): https://support.apple.com/en-us/HT204899 I ran into that recently in my day job..You may also want to consider getting an Apple Developer Key so that packages can be signed and users can avoid scary warnings, but I don't know if that would work in your cross-compile setup. > Am 29.11.2015 um 16:05 schrieb Rosanne DiMesio: >> Any chance of adding RHEL/CentOS/Scientific Linux packages that will > actually work (WoW64)? Red Hat has already refused. > > We might want to consider this at a later point, but from my experience > with CentOS 6 and Wine Staging, you don't gain much by supporting > CentOS. The main repositories didn't provide all dependencies for Wine > (for example OpenAL) and the packages were often outdated and caused > crashes which were not reproducible on other distros. Many of these > problems were most probably solved in CentOS 7, but I think we should > prioritize our efforts. More people can benefit from OS X builds than > CentOS at the moment, so I think we should fix them first. > > Absolutely, having Mac OS X packages of vanilla Wine would be a huge help. Thanks for your work on this. -- -Austin

Nov. 30, 2015

Re: rsaenh: Remove dead assignments (Clang)

by Nikolay Sivov

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?

Nov. 29, 2015

Re: Wine devel packages ready for testing

by Michael Müller

We added Fedora 23 yesterday and uploaded all builds for 1.8-rc2. The instructions for Fedora 23 are basically the same as for Fedora 22, just replace the version number in the url: dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/23/winehq.repo dnf apt-get install winehq-devel Am 27.11.2015 um 20:19 schrieb Aaryaman Vasishta: > How long until the cross compiled OSX packages arrive? Could you put up > the scripts on GitHub or does it have to be fully working before you do so? All scripts can be found in the following two repositories: https://github.com/wine-compholio/wine-packaging https://github.com/wine-compholio/wine-build-tools We are planning to wait until the Mac OS X builds for wine-devel work, before we add the scripts. Our current solution is to cross compile Wine on Debian as host distribution and this requires a lot of additional tools plus dependencies. Currently most of the tools and dependencies we use for Wine Staging are precompiled binaries that were manually compiled some time ago. This is not really a good solution as it somewhat obfuscates the build process. We would like to find a better solution for this. When we are done, we will add everything necessary (excluding the OS X 10.8 SDK), but it might be a bit difficult to setup, especially if you don't want to use a VM for building. Am 29.11.2015 um 16:05 schrieb Rosanne DiMesio: > Any chance of adding RHEL/CentOS/Scientific Linux packages that will actually work (WoW64)? Red Hat has already refused. We might want to consider this at a later point, but from my experience with CentOS 6 and Wine Staging, you don't gain much by supporting CentOS. The main repositories didn't provide all dependencies for Wine (for example OpenAL) and the packages were often outdated and caused crashes which were not reproducible on other distros. Many of these problems were most probably solved in CentOS 7, but I think we should prioritize our efforts. More people can benefit from OS X builds than CentOS at the moment, so I think we should fix them first.

Nov. 29, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Alex Henrie

2015-11-27 12:15 GMT-07:00 Alex Henrie <alexhenrie24(a)gmail.com>: > And it would cleanly resolve bugs 38480 and 39563. Correction: Substituting suffixed function pointers for unsuffixed ones should fix bug 39563, but it would not fix 38480. Since bug 39563 probably doesn't affect the proprietary driver and there is an easy workaround for the open source driver, it's probably not worthwhile to pursue this solution. So, unless more compelling evidence is presented, I'm with Henri: I'd prefer to refocus our efforts on improving the Nouveau driver's performance or petitioning Nvidia to finish implementing the extensions that they partially support. Just reverting the patch is not a palatable solution. -Alex

Nov. 29, 2015

Re: winspool: Remove dead code (Clang)

by Alex Henrie

- if(WINSPOOL_GetStringFromReg(hkeyPrinter, NameW, ptr, left, &size)) { - if(space && size <= left) { - pi4->pPrinterName = (LPWSTR)ptr; - ptr += size; - left -= size; - } else + if(WINSPOOL_GetStringFromReg(hkeyPrinter, NameW, buf, left, &size)) { + if(space && size <= left) + pi4->pPrinterName = (LPWSTR)buf; + else Could you indent this better? -Alex

Nov. 29, 2015

Scan-build report uploaded

by André Hentschel

Hi, in case someone is interested, i've uploaded a scan-build here: http://dawncrow.de/scan-build-2015-11-28-143038-14935-1/index.html Wine source is 1.8-rc2

Nov. 29, 2015

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

by Nikolay Sivov

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

Nov. 29, 2015