January 2016 - Wine-Devel - list.winehq.org

Re: Mac OS X beta packages!

by Aaryaman Vasishta

On Fri, Jan 1, 2016 at 7:24 AM, Michael Müller <michael(a)fds-team.de> wrote: > For user convenience, the package > also associates itself with all *.exe files, which means you can run > windows executables just by double-clicking on them. Not always, atleast in my case. I had a third party app installed which had already associated itself with *.exe files, and after installing the package it didn't change the default app to open by double clicking to wine. Instead I had to use the "Open with" option by right clicking on the .exe. > This might not work > for all executables though, since OS X doesn't seem to pass the current > working directory to the "Open With" handler. > Does that depend on the location of the executable or the executable itself? If it's the latter, can you give any example apps which have such executables? Cheers, Aaryaman

Jan. 1, 2016

Re: Mac OS X beta packages!

by Aaryaman Vasishta

Great! this will definitely make wine more popular for OSX users. I was able to get the pkg installed and running apps within a minute on OSX 10.10 :D (fwiw, used the PCIE SSD so your results may vary.) As for the package signing, many people won't find the unknown developer warning very friendly while opening the pkg. But on the other hand if we don't see those users complaining about it then it's not that big of an issue I feel. But I still think however that a developer license would be nice to have and could potentially broaden the audience even more. Cheers, Aaryaman On Fri, Jan 1, 2016 at 7:24 AM, Michael Müller <michael(a)fds-team.de> wrote: > Hi, > > we are happy to announce an initial version of our Mac OS X >= 10.8 > builds. So far the packages have not yet received that much testing, so > please give them a try, and report any issues you encounter. > > The packages are available at: https://dl.winehq.org/wine-builds/macosx > (Some mirrors don't show all files yet, just append random arguments to > the url like ?whereismypackage to trick the cache) > > For unexperienced users, it is recommended to install Wine using the > *.pkg files. Just double-click on the package, and the usual Mac OS X > installer wizard should open. As pointed out by Austin, I am not a > registered Apple Developer and therefore the packages aren't signed. > This will result in an error if you configured gate keeper to block > unsigned packages. The installation itself should be self-explaining, so > I will not go into too much detail here. It is possible to install the > package either for all users (needs administrator privileges), or just > for your current user. If you haven't installed XQuartz >= 2.7.7 yet > (our package supports the x11drv as well as the macdrv), the installer > will complain. Just install the missing dependency, and restart the > installation, if this is the case. > > After the installation is finished, you should find an entry "Wine > Staging" or "Wine Devel" in your Launchpad. By clicking on it, a new > Terminal window opens with a short introduction into some important wine > commands. You can now directly start wine/winecfg/... from the Terminal, > as the PATH variable is set correctly. For user convenience, the package > also associates itself with all *.exe files, which means you can run > windows executables just by double-clicking on them. This might not work > for all executables though, since OS X doesn't seem to pass the current > working directory to the "Open With" handler. > > Some experienced users on the other hand might prefer a raw wine version > without those gimmicks, so we also provide tarball archives. They > basically contain the same files (except packaging related stuff), and > can be unpacked in any directory. There is no need to set DYLD_* > environment variables, all paths are relative, so it should work as long > as the directory structure is preserved (you can skip the /usr prefix > though using --strip-components 1). Also make sure to install XQuartz >= > 2.7.7 in this case. > > For those who are wondering, here a couple more technical aspects: > > -------- Dependencies -------- > > The following dependencies are shipped as precompiled *.dylib-libraries > directly with Wine: > > * libjpeg-turbo > * liblcms2 > * liblzma > * libopenal-soft > * libtiff > * libxml2 > * libxslt > * [libtxc-dxtn-s2tc] > This is the patent free implementation of dxtn as used by many > linux distros. Only included in Wine Staging. > > -------- Scripts -------- > > You can find all scripts and build files at > https://github.com/wine-compholio/wine-packaging/tree/master/macosx > Those files allow you to build the packages on Debian Jessie as host > system, starting from a patched clang compiler (to support > ms_hook_prologue), tools necessary to create OS X packages, cross > compilation of the Wine build dependencies and finally cross compiles > Wine itself. You only have to provide MacOSX10.8.sdk.tar.xz and > xquartz-2.7.7.tar.xz, everything else is built from source. However, the > generated scripts are meant to be run inside our build VMs, so > realistically speaking it requires some effort to setup such a system > and is not suitable for an average user. > > ------------------------ > > There are also some features I am planning to implement in the future > (depending on how much time I have): > > -------- Auto updater -------- > > There is no common system to provide automatic updates for packages > besides the Store, so I think it would be good to come up with some > solution for this problem. Especially if the user installed the package > into his home directory, he could easily update it without entering a > password. I don't have much knowledge about objective-c or cocoa, so if > someone else wants to implement this, I am more then glad to add it as > an optional feature to the installer. > > -------- Desktop integration -------- > > So far Wine does not create desktop entries that are shown in Launchpad, > but instead creates useless entries at ~/.local/share/applications/. I > think it shouldn't be too hard to dynamically create a proper entry at > ~/Applications/ using a wrapper like I did for the main wine executable. > > -------- Package signing? -------- > > This is basically something I could fix in 5 minutes, but I don't feel > like paying 99$/year if I basically don't use Mac OS X myself. > > ------------------------ > > Happy new year and happy testing! :) > > Best regards, > Michael > > >

Jan. 1, 2016

Mac OS X beta packages!

by Michael Müller

Hi, we are happy to announce an initial version of our Mac OS X >= 10.8 builds. So far the packages have not yet received that much testing, so please give them a try, and report any issues you encounter. The packages are available at: https://dl.winehq.org/wine-builds/macosx (Some mirrors don't show all files yet, just append random arguments to the url like ?whereismypackage to trick the cache) For unexperienced users, it is recommended to install Wine using the *.pkg files. Just double-click on the package, and the usual Mac OS X installer wizard should open. As pointed out by Austin, I am not a registered Apple Developer and therefore the packages aren't signed. This will result in an error if you configured gate keeper to block unsigned packages. The installation itself should be self-explaining, so I will not go into too much detail here. It is possible to install the package either for all users (needs administrator privileges), or just for your current user. If you haven't installed XQuartz >= 2.7.7 yet (our package supports the x11drv as well as the macdrv), the installer will complain. Just install the missing dependency, and restart the installation, if this is the case. After the installation is finished, you should find an entry "Wine Staging" or "Wine Devel" in your Launchpad. By clicking on it, a new Terminal window opens with a short introduction into some important wine commands. You can now directly start wine/winecfg/... from the Terminal, as the PATH variable is set correctly. For user convenience, the package also associates itself with all *.exe files, which means you can run windows executables just by double-clicking on them. This might not work for all executables though, since OS X doesn't seem to pass the current working directory to the "Open With" handler. Some experienced users on the other hand might prefer a raw wine version without those gimmicks, so we also provide tarball archives. They basically contain the same files (except packaging related stuff), and can be unpacked in any directory. There is no need to set DYLD_* environment variables, all paths are relative, so it should work as long as the directory structure is preserved (you can skip the /usr prefix though using --strip-components 1). Also make sure to install XQuartz >= 2.7.7 in this case. For those who are wondering, here a couple more technical aspects: -------- Dependencies -------- The following dependencies are shipped as precompiled *.dylib-libraries directly with Wine: * libjpeg-turbo * liblcms2 * liblzma * libopenal-soft * libtiff * libxml2 * libxslt * [libtxc-dxtn-s2tc] This is the patent free implementation of dxtn as used by many linux distros. Only included in Wine Staging. -------- Scripts -------- You can find all scripts and build files at https://github.com/wine-compholio/wine-packaging/tree/master/macosx Those files allow you to build the packages on Debian Jessie as host system, starting from a patched clang compiler (to support ms_hook_prologue), tools necessary to create OS X packages, cross compilation of the Wine build dependencies and finally cross compiles Wine itself. You only have to provide MacOSX10.8.sdk.tar.xz and xquartz-2.7.7.tar.xz, everything else is built from source. However, the generated scripts are meant to be run inside our build VMs, so realistically speaking it requires some effort to setup such a system and is not suitable for an average user. ------------------------ There are also some features I am planning to implement in the future (depending on how much time I have): -------- Auto updater -------- There is no common system to provide automatic updates for packages besides the Store, so I think it would be good to come up with some solution for this problem. Especially if the user installed the package into his home directory, he could easily update it without entering a password. I don't have much knowledge about objective-c or cocoa, so if someone else wants to implement this, I am more then glad to add it as an optional feature to the installer. -------- Desktop integration -------- So far Wine does not create desktop entries that are shown in Launchpad, but instead creates useless entries at ~/.local/share/applications/. I think it shouldn't be too hard to dynamically create a proper entry at ~/Applications/ using a wrapper like I did for the main wine executable. -------- Package signing? -------- This is basically something I could fix in 5 minutes, but I don't feel like paying 99$/year if I basically don't use Mac OS X myself. ------------------------ Happy new year and happy testing! :) Best regards, Michael

Jan. 1, 2016

RE: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes

by Hugh McMaster

On Thursday, 31 Dec 2015 07:23:03 -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=19318 > > Your paranoid android. > > > === wvistau64 (32 bit msg) === > msg.c:10877: Test failed: expected PeekMessage to return FALSE, got 1 > msg.c:10889: Test failed: msg.message = 275 instead of WM_USER > msg.c:10891: Test failed: expected PeekMessage to return FALSE, got 1 > msg.c:10900: Test failed: msg.message = 1024 instead of WM_TIMER > msg.c:10902: Test failed: expected PeekMessage to return FALSE, got 1 > msg.c:13824: Test failed: 0: WaitForSingleObject failed > > === w1064 (32 bit msg) === > msg.c:6290: Test failed: Update region shouldn't be empty > msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 > msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different > msg.c:6296: Test failed: Regions are different These are pre-existing failures. -- Hugh McMaster

Jan. 1, 2016