Pages

Showing posts with label wineconf. Show all posts
Showing posts with label wineconf. Show all posts

Saturday, December 3, 2016

World Wine News issue 403

Stefan Dösinger wrote an extensive summary of the talks at WineConf this month. He also recorded some Videos and did all the postprocessing to make them enjoyable online. We thankfully include it in this WWN:

On November 12th and 13th the Wine developers and a few users met in St. Paul, Minnesota for the annual project meeting WineConf. The conference featured technical presentations and discussions about changes to the way Wine’s development processes work. This renewed installment of World Wine News gives a short summary of the discussions and agreed decisions.


Alexandre Julliard: Keynote
You can see the keynote here !

Following the tradition, WineConf was kicked off by Alexandre Julliard, the maintainer and Benevolent Dictator for Life of Wine. After giving a slightly different keynote last year, he went back to his old keynote template full of statistics and commit graphs. It was delightful to see that the number of commits increased again last year, after being in decline for a while, even though it is still far away from where it used to be around 2010. The new patch sign off system is working well, and the experiences with the staging branch have been positive. Discussing the impact of these changes in detail was moved to separate sessions and is described in this summary in separate sections. The Wine developers decided to switch to time-based releases last year, so a code freeze will come soon, and Wine 2.0 will be released most likely in December or January. The expected main areas of development after 2.0 will be Aric’s HID support, the ongoing DirectX 11 work. Alexandre was hoping to merge the Android code CodeWeavers was working on before 2.0, but decided to postpone it because integrating the Java parts into the build system proved to be difficult.

Aric Stewart: HID Support
 
Aric Stewart presented his work on supporting the Windows human interface device layer in Wine. This is a low level interface that allows applications to talk to devices like joysticks, keyboards, gamepads, etc. Few applications use it to use joysticks, instead they use higher level libraries like DirectInput or XInput, which then talk to this lower level layer. Wine currently supports DirectInput, so joysticks and gamepads work in many games. Unfortunately XInput is missing. Aric’s plan is to provide the low level hid.dll and (re-)implement dinput and xinput on top of it. This puts all operating system abstraction code (Linux, OSX, Android specific joystick handling) into hid.dll and allows applications that talk directly to hid.dll to work. Those applications are rare, but they exist.

You can see Aric’s full presentation here !

Aric also sent a mail explaining the current status to wine-devel :


This means that applications that use hid.dll or direct device access to HID devices will start seeing and being able to interact with devices. This is very exciting but is just the very first step. Of course any application trying to do HID directly would be a wonderful test case, I am sure there are many many things that will need to be refined and added before a real application starts being happy....

Looking forward, the hope is that then we will be able to build RawInput support on top of HID, and also dinput and xinput support as well. As a fun challenge I have been working to get native dinput from DirectX 9 to work on Wine on top of HID and it is moving forward much better than I expect, with a lot of hacks at present. (native Dinput sees the gamepads and even start trying to read them, but current is not getting reports properly)

CodeWeavers Update
You can see the update here !

Jeremy White gave an update on CodeWeavers and its involvement in Wine: CodeWeavers had some ups and downs. They spent a lot of time last year on Android and had some business opportunity in China that didn’t work out. Google announced that Chromebooks would run Android apps, which is a very welcome development because they use a mouse and keyboard and mostly have Intel CPUs, which makes them a much better target for Windows applications than phones and tablets. Sadly the consumer sales are declining. The porting business is strong and increasing, which excitingly was the original business model behind CodeWeavers’ Wine engagement. Exciting opportunities in the pipeline that Jeremy White cannot talk about in detail yet. The company turned 20 this year, so next year it gets to drink :-) . [Under the rather strict US liquor laws.]

Consumer sales are about 10% Linux and 90% Mac, but there are some larger corporate customers that pay for Linux. Business interest in Linux is slightly increasing as companies migrate away from Windows XP or want to run Windows applications on embedded systems. CrossOver Android is in the Play Store as a technology preview. It is available for signed up beta testers only, and only works on tablets with an Intel CPU because Qemu is too slow to run applications in a useful manner on ARM-based tablets. Various companies have impressive ARM emulation demos, but they don’t hold up to closer scrutiny. Sadly Intel recently announced that they are dropping out of the mobile business. The bright side for CrossOver Android are Chromebooks, as mentioned above. Jeremy White says CodeWeavers should probably do a better job announcing its contributions to Wine, and crediting customers for key contributions. On the other hand, CodeWeavers overshadows Wine’s development already and Jeremy would love to have more non-CW contributions to Wine and a more widespread community. Due to having financial resources and being able to pay developers CodeWeavers can do the really tricky and annoying work, for example getting the copy protection and activation of Microsoft Office 2013 to work.

User Support
 
Rosanne Dimesio gave an update of problems Wine users are facing and their most requested features. The most common request is support for the newest game. [Which, sorry, is a moving target and really hard to do]. A common issue is the lack of packages for stable branch in some distributions. Users are happy with the support of Microsoft Office 2007 and 2010. Few users want newer versions so far, because people who invest money into MS Office usually stay with this version – which is why we still have users running Office 97. This is likely to change when Microsoft breaks file format backwards compatibity.

Support for USB devices (especially HID) is a recurring source of pain. Aric’s work will hopefully help here.

Spammers are a constant problem on the forum and wiki. The wiki has been locked down and users have to request edit permissions before being able to edit. The captchas on the forum help against bots, but there are human spammers that can get past them.

Rosanne could really use help from other people with answering questions on the forum. There are some people who help (Thanks!), but more would be very welcome. We should probably do a better job explaining how non-coders can help out.

We want more users attending WineConf to get their perspective. For next year we will try to announce this in a better way. WineConf is open to everyone, users are very welcome! We would also like the input of people who develop software around Wine like PlayOnlinux. Travel sponsorship is available too, contact us if you would like to come and money is an issue for you.

If you want to represent Wine at an event or Linux user group near you please get in contact with us. Travel sponsorship is available for this too :-)

Sign-Off change review
 
There was quick consensus that the Sign-Off system is a major improvement. It allows people to send patches originally written by other people and maintain authorship information. Sebastian Lackner has brought in many patches from wine-staging, and Andrew Eikum has fixed and submittet Maarten Lankhorst’s pulseaudio driver.

Wine-Staging report
Erich Hoover gave an update on the state of the staging branch. Unfortunately Sebastian and Michael, the main maintainers of this branch, couldn’t come due to their time constraints.

Sebastian is doing most of the work and is turning into their Alexandre. He has been working very hard on getting things reviewed properly on wine-devel and make patches go into Wine directly. The number of commits that go into staging is declining, which is a win because it reduces the maintenance burden.

Existing patchsets in staging slowly make it into Wine. Two big sets that did not, so far, are the multi-threaded command stream and the Vulcan wrapper.

The overall consensus is that the staging branch is helping Wine. It is a place that collects unfinished patches. Those patches often point out ways to fix bugs (Jeremy called them breadcrumbs), and we really want to have this information, even if their author does not want to see them to conclusion. The staging maintainers try to provide incentives for people to finish the patches rather than just dropping them off.

Staging also provides a place to test in-development work and catch bugs early.

Direct3D Update
 
Stefan: Quit CodeWeavers about a year ago and moved to a different job, but is still hanging around Wine. Fixed a bunch of tests over the past year, and fixed two bugs that fell in line with the tests. Benchmarks not running because computers are sitting in a corner because doesn‘t have enough space in the shared house in Staines.

Józef is working on DirectX 11: A lot of work got upstreamed in the past months, but there are still many missing features. Compute shaders are missing, as are many view types. It also needs Matteo’s GL core context work on many drivers, which depends on the blitter rework Stefan was working on before he left. However, some games start showing signs of life. During the conference Andrew Wesie sent a set of patches to make Blizzard’s Overwatch run. In a way it also depends on the command stream, which would be very helpful to have tfor deferred contexts. [Editor’s note: Józef’s statement was deciphered from a really quiet recording with lots of background noise. It may be inaccurate in some parts.]

Henri is working on upstreaming the multithreaded command stream (Currently it’s in staging, but not the master branch). He wasn’t at WineConf, so we couldn’t really come to a conclusion when that work will be finished. It depends on Henri’s other tasks, CodeWeavers keeps dropping work at him that needs to be finished yesterday. Henri has made progress in the past months, merging the patches that unify 2D, Cube and Volume textures into one texture resource, but merging textures and buffers into one common resource is missing, and the blitter support in the current command stream code is a mess. The ETA depends on where Henri wants to go exactly.

Future WineConf
 
In 2012 and 2013 we experimented with joining FOSDEM to attract people who are not long-standing Wine developers to join the talks. This was successful in many ways, but we felt that it made discussing internal matters like the patch acceptance process more difficult. For this reason we went back to a “classic” WineConf in 2015 and 2016 and were again stuck with the feeling that it’s just the same people attending every year.

To address this we will try to more actively invite people from outside wine-devel. As mentioned in the User Support part of this summary, we would enjoy having more users of Wine around, and people who are building front-ends around Wine.

The next WineConf will in all likelyhood be in Poland, hosted by Jacek and Piotr Caban, and it will be somewhen in Fall 2017. If you are interested, come! We will announce more details once we have a specific date and exact location and hopefully won’t forget to announce it beyond wine-devel :-)

Full Article

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Friday, October 9, 2015

How Im Earning My Beer part 1

St. Stephen's CathedralI had the pleasure of attending WineConf 2015 in Vienna, Austria. The weather was better than I could have asked for, the food was excellent. The company of thirty five other contributors to Wine was encouraging and appreciated. It's the first WineConf in years and it was well overdue.

Photo credit: Marcus Meissner, WineConf 2015 Everyone's reports are trickling in and we're all scurrying to do the work asked of us to help move the project along. The coming weeks and months should reveal the community is more driven than ever. We've re-united with those who had trickled to Wine-Staging and there's a flurry of updates going to wiki pages, blogs, and articles all around. Not to mention the process changes, thinking around bugs and forums, and so much more.

My little piece has to do with what we are called to action over every time we meet.

Every WineConf, we fret over this page and it's various friends:

Wine's Conformance Test Results Page
Ideally, we would have every single test passing on each version of Windows that's running our tests AND we would have it passing on Linux and Mac systems. As you can see, we're a little remiss in Mac test results in the last two months. Wine's test suite isn't (wasn't) running successfully enough on any Mac to report its results.

This year's idea is that next year we *might* insist that before anyone can have a beer on Friday night, they have to fix one test on this page. Granted, I'm a little early and arguably submitting more tests to the page is not fixing tests themselves... but it is making it so everyone else has something to fix. Hopefully that's where I'm earning my beer... and I'm not even sure I want a beer, to be truthful. Maybe I want a nice glass of Wine, seriously.

It is not to say that I'm going it alone, getting Wine's tests to run on any system means that tests have to be written well by the Wine community. It means that I have to have a way to install dependencies on OS X. And, it means I drag my peers through reviewing the problems I'm seeing even if they are caused by my own human error.

For the Wine community, it means OS X results that run in some reliable fashion. It means a contribution in a different form. It's something I'm proud of because the task isn't all that easy. If you're looking for a way to contribute to Open Source, understand that contributions come in many forms. They come from community support, testing, spreading the word, development, and so much more. After I release this blog post into the world, the absolute best thing I can do is go back to WineHQ and ensure that my method of getting Wine's Conformance Tests to run is logged on one of the many wiki pages. With that, I will have come full circle and made a decent suggestion on how others can help too.


MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Thursday, September 24, 2015

WineHQ WineConf 2015 Group Photo

WineHQ WineConf 2015 Group Photo

From left top to right bottom: Sebastian Lackner, Aaryaman Vasishta, Austin English, Rosanne DiMesio, Ulrich Czekalla, Michael Stefaniuc, Henri Verbeet 

Aric Stewart, Piotr Caban, Jacek Caban, Caron Wills, Christian Inci, André Hentschel, Jeremy White, Alois Schloegl, Andrew Eikum, Huw Davies, Hans Leidekker, Robert (Focht)

Stefan Doesinger, Dmitry Timoshkov, Alexandre Julliard, Francois Gouget, Andrei Podoplelov, Nikolay Sivov, Michael Müller 

Marcus Meissner, Jactry Zeng, Qian Hong, Josh DuBois, Vincent Povirk, Józef Kucia, Matteo Bruni

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Wine Stable Release Changes

Hello,

At WineConf we had a fairly uncontroversial discussion about the Wine Stable release process. As the current process of feature based Wine releases isn't working(*) following changes were agreed upon.

Release Process Changes
------------------------
- - Switch to time based releases.
- - Major releases once a year in autumn/fall. Code freeze starts around mid/end of September.
- - Michael Stefaniuc will be the stable maintainer starting with 1.8.x. Other people are more than welcome to help out with Wine Stable. I'll document stuff and send out a request for help during the code freeze.
- - The stable release will be supported in bugzilla.
- - This changes take effect immediately. You can expect Alexandre to announce a code freeze in the next couple of weeks.
- - We will revisit this changes should the need arise, e.g. reduce the time between two major stable releases.

Discussion
-----------
The discussion was done based on slide 9 of Alexandre's keynote At the start Alexandre and others noted that we do not hear from users for whom 1.6 is just working. We are getting reports only about the stuff that breaks.

The discussion quickly geared to the changes accepted from above with the focus on implementation details:

- - 6 months better? No, the 12-18 months stable release cadence prior to 1.8 was ok. Can be reduced later on should the need arise.
- - Synchronize with (a) major distro? No, release dates can slip on both ends. Freeze should also not impact GSoC.
- - Nobody else volunteered during the discussion for the stable maintainer role.

For the more drastic proposal of removing the the Wine Stable version altogether, Alexandre made drafted a plan to follow a similar model to the Linux Kernel. One release for the risky stuff and every second release is for stabilization. He proposed also a two weeks "merge window" for risky stuff followed by two weeks for the fixes and the last two weeks of "freeze". This produced a loud outcry from most developers: it would be unworkable without a prior move to a git pull model to accept new features. This basically killed the proposal.

(*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It doesn't compiles on a modern distribution anymore.

bye,
Michael

MacOS and Windows software bundles, save up to 90% off the normal retail price only at BundleHunt.
 

Monday, May 25, 2015

GSoC 2015 WineHQ projects

This is from the WineHQ developers mailing list.

Matteo Bruni 

Hey all,

tomorrow the coding period of the Summer of Code begins and I though it might be a nice idea to let the community know about the projects we've got this year. Actually, I though it would be even better if the student themselves wrote a short summary of their own project for the mailing list.

So, with no authority backing me, I'm kindly asking that. No need to write anything too fancy, just a few lines explaining what are you going to work on over the summer and maybe what are the expected benefits for Wine.

Thank you!

Aaryaman Vasishta

Hello!
Thank you for inviting me to this opportunity! I will try my best to keep it short, though it might be a bit long for some. There's a TL;DR at the end, though. :)
A bit about myself. My name is Aaryaman Vasishta and I'm currently studying in my third year of Computer Engineering in Pune Institute of Computer Technology, India. My interests lie in game programming and computer graphics.

My project focuses on implementing the rendering backend for the D3DRM API [1].

D3DRM (Direct3D Retained Mode) is basically a scene graph API running on top of Direct3D's Immediate Mode API. You can say it's more like a rendering engine API which encapsulates Immediate Mode functionality in order to make it easier for programmers to develop 3D scenes using it, making it a possible competitor to OpenGL at the time.

At the moment wine's implementation of this API is mostly full of stubs, and there's quite a bit of work left before something can be drawn on the screen. My role here mainly focuses on implementing object Creation/Initialization functions for some of the main interfaces, mainly devices, textures and viewports, all of which are COM based. If time permits, I will also work on implementing some frequently used frames and lighting functions.
The API is quite old (it has been removed since DX 8 SDK, and the dll doesn't come included with vista onwards) but there are a few popular games that used it. Namely, Lego Rock Raiders and Steel Beasts, and applications as well, like FMS (Flying Model Simulator). So there is some merit in working on this. Implementing these functions will help accelerate further development of this API to get some long-awaited apps to run on wine (I can see quite a few threads on google of people trying to get FMS running, and a couple for LRR too, so there is some demand for it). As an added bonus, I also get to interact with wine's ddraw implementation for this one, which could potentially help ddraw's implementation via possible bug detection/fixes and implementing any ddraw functionality that d3drm requires.


TL;DR: I'm implementing a main chunk of a graphics API called Direct3D Retained Mode, which is based on Direct3D Immediate Mode. The API is mostly a stub in wine and this project should help get things going.

Thank you!
Aaryaman Vasishta

Zhenbo Li

 Hello!

I'm glad to working on Wine GSoC this year. My project's focus is IHMLTXMLHttpRequest. Many websites would use hacks to determine whether the browser was IE6.0 or IE 7+. As XMLHttpRequest object identifier was shipped in IE 7.0[0], the web developers would use ActiveX to access IXMLHttpRequest object. Wine IE implements some new features, so it is common that Wine IE is treated as a IE 7+ browser(like Firebug Lite[1])

Mozilla has implemented nsIXMLHttpRequest[2], and my approach is to call the wine-gecko functions from wine code. I can't tell how many applications' status on appdb will change from "garbage" to "silver/gold", but IMHO, implementing XMLHttpRequest is necessary to make wine IE more usable.

Thanks

 Iván Matellanes

 Hi all!

I'm looking forward to contributing to Wine.
My project consists on implementing part of the legacy Visual C++ iostream runtime, which was shipped with Visual Studio versions up to 6.0 and is currently a stub. I'll work on as many functions as time permits, and one of the key points is to reuse code from the modern Visual C++ runtime library that is already implemented.

Some old applications and games (like MS Reader and Tron 2.0) would benefit from this, as they would run with the built-in library. A quick search on Bugzilla for 'msvcirt' shows several bugs related to unimplemented functions.

Cheers,
Iván.

YongHao Hu

 Hi, all.

Sorry for the late reply. I am happy to join this discussion.

My project focuses on implementing all the functions from tr2 namespace, which was included in the header and being proposed for standardization. Though there are many methods to implement the functions like _File_size and _Equivalent etc, the hard part is finding the most appropriate one.

New applications like MSVC12[1] would benefit from this.


Thank you!

-----

The newest CodeWeavers coupon promo code is ( UNITY ) save 30% off CrossOver Mac or Linux today!