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

Re: Wine devel packages ready for testing

by Michael Müller

Am 30.11.2015 um 03:21 schrieb Austin English: > 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. Currently we install wine staging into /opt/wine-staging which seems to work. I would prefer to install the new packages into the home directory, so that also users without admin rights can install the package. The only problem are the dependencies since they usually do not use relative rpaths and they might contain the prefix embedded in the executables. Not sure if this is a problem, I need to test this. > 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. 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. I am sure this can be fixed though ;-). Signing the whole package is most probably a bit more difficult than just signing one executable, but I am sure this is doable. I guess it is necessary to pay 99$/year for the developer program to get your key signed, right?

Nov. 30, 2015

Learning to Develop for the Wine Project

by David Reinert

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

Nov. 30, 2015

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

by Nikolay Sivov

On 30.11.2015 21:03, Bruno Jesus wrote: > On Tue, Dec 1, 2015 at 1:17 AM, Austin English <austinenglish(a)gmail.com> wrote: >> On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >>> 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 >> It's at https://code.google.com/archive/p/win16test/downloads >> >> The initial problem IIRC was OpenWatcom's license, which isn't >> acceptable to Debian/Fedora/et al: >> https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License >> >> Dan speculated that AJ wouldn't add a patch that used OpenWatcom since >> it's not packaged in the major distributions, but AFAIK he never >> actually asked :). Perhaps an optional build of win16 tests if it's >> installed would be acceptable. >> >> I've also exported a copy to my Github account: >> https://github.com/austin987/win16test/ > Thanks for all answers, I installed OpenWatcom and was able to produce > the test I need and it works in Windows and not in Wine so the problem > was confirmed by tests (bug > https://bugs.winehq.org/show_bug.cgi?id=9919) > > I had a small problem tough, in the compiled version of the program > printf works in wine but does not in Windows (no, not a buffering > problem, fflush does not help). In Windows not a single line is > printed to the console, maybe that is correct, I don't know so I > changed to output a text file instead. Even if it's not possible for some reason, you can always make it write to a file directly. > > I tried compiling the win16 tests but there were too many compilation > errors, I'm probably doing something wrong. I'll be back to that in > some days. > > The question that remains, how to submit a patch that was tested with > an external (not wine test suite) program? (test attached) Currently the only way is to submit without it, and mention it in a mail. Hopefully in the future tests could be kept in similar separate repository, and built regularly.

Nov. 30, 2015

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

by Bruno Jesus

On Tue, Dec 1, 2015 at 1:17 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> 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 > > It's at https://code.google.com/archive/p/win16test/downloads > > The initial problem IIRC was OpenWatcom's license, which isn't > acceptable to Debian/Fedora/et al: > https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License > > Dan speculated that AJ wouldn't add a patch that used OpenWatcom since > it's not packaged in the major distributions, but AFAIK he never > actually asked :). Perhaps an optional build of win16 tests if it's > installed would be acceptable. > > I've also exported a copy to my Github account: > https://github.com/austin987/win16test/ Thanks for all answers, I installed OpenWatcom and was able to produce the test I need and it works in Windows and not in Wine so the problem was confirmed by tests (bug https://bugs.winehq.org/show_bug.cgi?id=9919) I had a small problem tough, in the compiled version of the program printf works in wine but does not in Windows (no, not a buffering problem, fflush does not help). In Windows not a single line is printed to the console, maybe that is correct, I don't know so I changed to output a text file instead. I tried compiling the win16 tests but there were too many compilation errors, I'm probably doing something wrong. I'll be back to that in some days. The question that remains, how to submit a patch that was tested with an external (not wine test suite) program? (test attached)

Nov. 30, 2015

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

by Austin English

On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > 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 It's at https://code.google.com/archive/p/win16test/downloads The initial problem IIRC was OpenWatcom's license, which isn't acceptable to Debian/Fedora/et al: https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License Dan speculated that AJ wouldn't add a patch that used OpenWatcom since it's not packaged in the major distributions, but AFAIK he never actually asked :). Perhaps an optional build of win16 tests if it's installed would be acceptable. I've also exported a copy to my Github account: https://github.com/austin987/win16test/ -- -Austin

Nov. 30, 2015

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

by Austin English

On Mon, Nov 30, 2015 at 8:20 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > 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. I don't think refused is accurate, deferred or delayed might be. -- -Austin

Nov. 30, 2015

Re: [PATCH] oleaut32/tests: Some tests for SafeArrayDestroyData()

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=18658 Your paranoid android. === wvistau64 (64 bit safearray) === No test summary line found === w2008s64 (64 bit safearray) === No test summary line found === w7pro64 (64 bit safearray) === No test summary line found === w864 (64 bit safearray) === No test summary line found === w1064 (64 bit safearray) === No test summary line found

Nov. 30, 2015

Re: [PATCH 1/2] ntdll/tests: Add SIMD exception test for floating point invalid operation fault (try 2).

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=18657 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:485: Test failed: 42: Wrong exception address 77BAED97/003D0001 === w7u (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 002F0000/002F0001 exception: unhandled exception 80000004 at 002F0000 exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/002F0001 === w1064 (32 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

Nov. 30, 2015

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

by Michael Stefaniuc

On 11/30/2015 03:20 PM, Rosanne DiMesio wrote: > 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. That's not "Red Hat". The Fedora and CentOS/EPEL Wine maintainers are not employed by Red Hat but are part of the community. The issue with EPEL is that RHEL7 dropped 32bit support. And CentOS7 took a long time to do a 32bit version. That's now out for 1 months or so and there the issue can be fixed properly now. > --FreeBSD packages both 32 and 64 bit Wine, but doesn't support WoW64. https://forum.winehq.org/viewtopic.php?f=2&t=25600 bye michael

Nov. 30, 2015

Re: [PATCH 1/2] ntdll/tests: Add SIMD exception test for floating point invalid operation fault.

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=18654 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:485: Test failed: 42: Wrong exception address 77BAED97/003D0001 === w7u (32 bit exception) === exception.c:485: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:485: Test failed: 42: Wrong exception address 77CDE34F/003D0001 === w1064 (32 bit exception) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

Nov. 30, 2015