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

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

by André Hentschel

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). > > Any help is appreciated, thanks in advance, > Bruno Hi Bruno, winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code)

Nov. 29, 2015

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

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

Nov. 29, 2015

Re: Wine devel packages ready for testing

by Rosanne DiMesio

On Fri, 27 Nov 2015 02:37:04 +0100 Michael Müller <michael(a)fds-team.de> wrote: > - Additional distributions can be added on request - but please try to contact > your distribution first! > Any chance of adding RHEL/CentOS/Scientific Linux packages that will actually work (WoW64)? Red Hat has already refused. https://bugzilla.redhat.com/show_bug.cgi?id=1117422 -- Rosanne DiMesio <dimesio(a)earthlink.net>

Nov. 29, 2015

Re: contribute to wine

by Maik Wagner

Hello Abhijeet, On 11/29/2015 07:35 AM, Abhijeet Panda wrote: > I am a big fan of this program and I want to contribute a lot > to this. I have been through the getting started page. Is there anyone > who could tell me the projects which are open and I could contribute > to. > thank you > > I am definetely not a software developer and don't know that many programming languages but I am also a big fan of wine. I mainly write AppDB reports and send in bug reports when I encounter them, do tests etc. What I would suggest is following the bug reports on http://bugs.winehq.org and test the applications in question, maybe do regression tests, test staged patches etc. I am also in the middle of translating CrossOver into German. It's now at 93% currently. I think reading about the bugs and subscribing to bug reports would be a good starting point. Currently wine is in release candidate status and no more features are currently being added but development will definetely go on. Regards, Maik Wagner www.linuxandlanguages.com

Nov. 29, 2015

contribute to wine

by Abhijeet Panda

hello everyone, I am a undergrad student and have been using wine on my linux for a while. I am a big fan of this program and I want to contribute a lot to this. I have been through the getting started page. Is there anyone who could tell me the projects which are open and I could contribute to. thank you

Nov. 29, 2015

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

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=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

Nov. 29, 2015

Re: [PATCH 1/7] msctf: Add a partial implementation of ITfThreadMgrEx_ActivateEx().

by Matteo Bruni

2015-11-27 20:52 GMT+01:00 Marvin <testbot(a)winehq.org>: > 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=18605 > > Your paranoid android. > > > === w1064 (32 bit inputprocessor) === > inputprocessor.c:791: Test failed: Deactivation came unexpectedly Nope, that's a preexisting test failure.

Nov. 27, 2015

Re: [PATCH 1/7] msctf: Add a partial implementation of ITfThreadMgrEx_ActivateEx().

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=18605 Your paranoid android. === w1064 (32 bit inputprocessor) === inputprocessor.c:791: Test failed: Deactivation came unexpectedly

Nov. 27, 2015

Re: Wine devel packages ready for testing

by Aaryaman Vasishta

Thanks for the instructions! This will definitely help others to quickly get up to speed with the binary packages. 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? Cheers, Aaryaman On Fri, Nov 27, 2015 at 7:07 AM, Michael Müller <michael(a)fds-team.de> wrote: > 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 > > >

Nov. 27, 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>: > 2015-11-27 0:54 GMT-07:00 Alexandre Julliard <julliard(a)winehq.org>: >> Sebastian Lackner <sebastian(a)fds-team.de> writes: >> >>> @Alexandre: Just to make sure I tested it in practice, and it indeed solves >>> the bug. It would be acceptable but 1.8, but wouldn't solve >>> https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that >>> its technically not a Wine bug, but it could still be solved by being less >>> strict with extension filtering. Both MESA and NVIDIA return valid valid >>> function pointers in this case. >> >> Actually I would argue that it is a Wine bug. If you can get a valid >> function on Windows even when the extension is missing, you should get >> one on Wine. Conversely, if you get a NULL pointer on Windows for a >> missing function, you should get NULL on Wine too. >> >> This means that we have a responsibility to properly remap functions and >> extensions between the Windows and the Unix side. We can't simply >> forward to the Unix driver and hope that it happens to follow the >> Windows semantics. > > After giving it some thought, I think this could work. As long as > we're sure that suffixed functions behave identically to their > unsuffixed counterparts, we should be able to return a function > pointer to a suffixed function even though a unsuffixed function was > requested (as long as the suffixed function is advertised in the > extension list). > > This would match both: > - Windows returning function pointers for unsuffixed functions even > though the rest of the OpenGL version is not available > - GLX providing no guarantee that calling a function not defined in > the GL version or extension list won't crash the program, even though > an unsuffixed equivalent could work fine > > And it would cleanly resolve bugs 38480 and 39563. Sorry, I meant to say "even though a suffixed equivalent could work fine". -Alex

Nov. 27, 2015