Announcement

Collapse
No announcement yet.

The 2010s Were Very Successful For Wine Thanks To CodeWeavers + Valve's Steam Play

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by duby229 View Post
    First of all, every single time anybody has ever come anywhere close to 100% passing every test was done on nvidia hardware..
    https://test.winehq.org/data/c84fa0a...4/version.html
    This here is the current windows 10 perfect pass notice the GPU is vga in other words windows running in software GPU mode. Out of the wine test bot history there has not been a single case that nvidia hardware has ever got a clean sweep. Intel , AMD and windows is software rendering mode have at different times got clean sweeps of the wine test suite when the test suite is running under windows.

    The highest pass rate of wine having testsuite run against wine on Linux has been with Intel hardware followed by AMD followed by Nvidia with mesa software rendering tail of the hunt.

    Originally posted by duby229 View Post
    The problem with that is that nvidia hardware is not compliant with opengl specs.
    Nvidia is not compliant with direct x specifications in a repeatable way either. Yet for some reason it popular yet it has random breakage patterns shown by the wine testsuite..

    Originally posted by duby229 View Post
    Second of all due to wines "one behavior to rule them all" philosophy that specifically means that anything outside of expectations, which includes everything that's not nvidia, basically everything that is standards compliant, will fail tests..
    So doubling down on garbage.

    Originally posted by duby229 View Post
    Third of all your point that applications will often times run different code paths depending on what hardware is detected also makes a great argument for exactly why wines tests are synthetic and don't make any real world sense.
    Wine testsuite does not just accept one answer as correct. Wine tests has a list of correct answers a function can provide that we know that applications will have different code paths to handle. When it errors out if you are running the real application the wine test is based on the program will fail because error is a code path that should not happen for the application and it has no code path to handle it.

    https://test.winehq.org/data/c84fa0a...dex_Win10.html

    In the name strings with cw-gtx fillowed by number is Nvidia notice all those cannot run dx7 applications properly. cw-rx is amd runs more than Nvidia test with less problems. All the newtb-w1064 are windows in software mode no GPU drivers. Yes on average more test pass before you install Nvidia or AMD drivers so you improve speed while dropping application compatibility.

    So another lot of total bull by you not backed by any of the wine testing numbers. You can roll the dice multi times with Nvidia and AMD GPU drivers fairly much will just keep on moving the failure points around.

    One of the things wine test suite tell you don't buy a Nvidia gpu for windows 10 if you want to run old Dx7/dx4 games its not going to run. Buy Intel or Amd if you want to run old games with Windows 10.

    Its about time you drop your idea that wine favours Nvidia. Wine tests don't and wine current functional code don't.

    Last edited by oiaohm; 01-15-2020, 04:23 AM.

    Comment


    • #52
      The REAL problem here is not that the test fails, it is what happens WHEN the test fails.

      Example:
      I run application A on Windows 10. This application have an error in API function "foo". This makes windows display a dialogue box 2 pixels wider than it should be if you had followed the API 100% correct. No big deal, none even notices.
      Problem:
      I run the same application under Wine. The API function "foo" generates a exception error, and wine crashes. The application is then useless. I then figure out how this could work, and submit a patch. The patch fails winetest because it would be using a "wrong api call in function foo", and the patch is discarded as "Failed".
      I argue this, and gets told off with something like: "But this is not the correct usage of the api call... The app is faulty! (And winetest clearly show this!)".

      I know the solution is not to allow "any" code, cos the example fix above might just aswell break a lot of other apps in the process, and thus should have some guards against this.

      If enough of this non-correct api function "foo" is used (loads of different applications actually - as in REAL ones - or drivers for that matter), the dev's come up with solutions of various kinds, and we sometimes see fixes 4-5 years after the first bugreport. So if we are to agree on something, i will agree this would be better with more manpower.

      Lots of errors/bugs/problems under windows too, it just seems as when it comes to wine, when things kinda does not work 100%, they don't work AT ALL, and it is relatively hard to fix this if it means needing "incorrect" calls. This is typical for game engines. You could have a game engine doing some optimization that is not the correct usage of the api (to speed up performance or something), that works perfectly fine under windows, but when it comes to wine it is blatantly shut down because it "fails winetest due to incorrect api usage". Given that loads of game uses the same game engine (UT4, Unity+++), you suddenly have loads of games not working at all, and no way to fix it cos the devs refuses to cater to "incorrect api usage". WHAM, we get hacks/patches/tweaks/DXVK/Proton/Staging to remedy such things.

      Comment


      • #53
        Originally posted by Cybmax View Post
        Example:
        I run application A on Windows 10. This application have an error in API function "foo". This makes windows display a dialogue box 2 pixels wider than it should be if you had followed the API 100% correct. No big deal, none even notices.
        Problem:
        I run the same application under Wine. The API function "foo" generates a exception error, and wine crashes. The application is then useless. I then figure out how this could work, and submit a patch. The patch fails winetest because it would be using a "wrong api call in function foo", and the patch is discarded as "Failed".
        I argue this, and gets told off with something like: "But this is not the correct usage of the api call... The app is faulty! (And winetest clearly show this!)".
        This is what I call lost in translation. You patch was faulty because it had no test case that showed that the behaviour could happen under windows. This has been a common problem to get patches out of staging into mainline. Person wrote patch to fix application and did not write patch for test suite to confirm that it was a valid possible windows behaviour. Adding patch to test-suite makes sure behaviour you have implemented in fact matches Windows behaviour.

        Originally posted by Cybmax View Post
        I know the solution is not to allow "any" code, cos the example fix above might just aswell break a lot of other apps in the process, and thus should have some guards against this.
        Test suite is guard against you implementing random stuff that don't have a real behaviour on a real install of windows. Not implementing tests is fairly much way of getting patches rejected for failing testsuite. I will give that some wine developers are not very clear that the problem is that you need to write a test or two with your patch and submit the patch to test suite before you submit the application fixing patch.

        Originally posted by Cybmax View Post
        If enough of this non-correct api function "foo" is used (loads of different applications actually - as in REAL ones - or drivers for that matter), the dev's come up with solutions of various kinds, and we sometimes see fixes 4-5 years after the first bugreport. So if we are to agree on something, i will agree this would be better with more manpower.
        This is not just manpower this is a little it of education being "Don't skip out on writing tests" and "Test for feature normally need to be mainline before feature is implemented with wine".l This difference is why some people submit a test then patch and basically get it straight in really quickly and the bug gets closed really quickly and then you have the ones linger until the maintainers of staging get around to writing the test case for it and get it mainlined. It would be good for the staging maintainers workload if this was not going on.

        Originally posted by Cybmax View Post
        Lots of errors/bugs/problems under windows too, it just seems as when it comes to wine, when things kinda does not work 100%, they don't work AT ALL, and it is relatively hard to fix this if it means needing "incorrect" calls. This is typical for game engines. You could have a game engine doing some optimization that is not the correct usage of the api (to speed up performance or something), that works perfectly fine under windows, but when it comes to wine it is blatantly shut down because it "fails winetest due to incorrect api usage". Given that loads of game uses the same game engine (UT4, Unity+++), you suddenly have loads of games not working at all, and no way to fix it cos the devs refuses to cater to "incorrect api usage". WHAM, we get hacks/patches/tweaks/DXVK/Proton/Staging to remedy such things.
        What you are writing is not exactly true. Wine excepts test suite patches testing for what microsoft would call incorrect api usage. Shot down by winetest is simple because winetest that does not have a test that has that as valid application behaviour.

        Wine developers don't refuse to cater for "incorrect api usage". They are just have a process you have to follow.

        I am sorry it is in the documentation for developers.

        https://wiki.winehq.org/Wine_Develop...formance_Tests

        If you have read the wine developers guide you will notice they get very particular about Conformance Tests. So the need to write Conformance Tests are documented. No Conformance test you checking what you have implemented bug shot down by testbot for being broken.

        If someone can work out how to write the in way that is more clear that writing conformance tests is not an optional thing with wine could save a lot of problems.

        Lot of open source applications writing conformance tests is after the fact as in you submitted patch to add feature then you submit patch with conformance test to confirm it works. With wine it before the fact model as in you submit the conformance test then you submit the patch that fixes the conformance test failure.

        There are stability advantages to the second model. Yes sending you patch to staging instead of writing a conformance test is just putting more work on the over worked staging people.
        Last edited by oiaohm; 01-15-2020, 12:36 PM.

        Comment


        • #54
          Originally posted by Cybmax View Post
          The REAL problem here is not that the test fails, it is what happens WHEN the test fails.

          Example:
          I run application A on Windows 10. This application have an error in API function "foo". This makes windows display a dialogue box 2 pixels wider than it should be if you had followed the API 100% correct. No big deal, none even notices.
          Problem:
          I run the same application under Wine. The API function "foo" generates a exception error, and wine crashes. The application is then useless. I then figure out how this could work, and submit a patch. The patch fails winetest because it would be using a "wrong api call in function foo", and the patch is discarded as "Failed".
          I argue this, and gets told off with something like: "But this is not the correct usage of the api call... The app is faulty! (And winetest clearly show this!)".

          I know the solution is not to allow "any" code, cos the example fix above might just aswell break a lot of other apps in the process, and thus should have some guards against this.

          If enough of this non-correct api function "foo" is used (loads of different applications actually - as in REAL ones - or drivers for that matter), the dev's come up with solutions of various kinds, and we sometimes see fixes 4-5 years after the first bugreport. So if we are to agree on something, i will agree this would be better with more manpower.

          Lots of errors/bugs/problems under windows too, it just seems as when it comes to wine, when things kinda does not work 100%, they don't work AT ALL, and it is relatively hard to fix this if it means needing "incorrect" calls. This is typical for game engines. You could have a game engine doing some optimization that is not the correct usage of the api (to speed up performance or something), that works perfectly fine under windows, but when it comes to wine it is blatantly shut down because it "fails winetest due to incorrect api usage". Given that loads of game uses the same game engine (UT4, Unity+++), you suddenly have loads of games not working at all, and no way to fix it cos the devs refuses to cater to "incorrect api usage". WHAM, we get hacks/patches/tweaks/DXVK/Proton/Staging to remedy such things.
          Yup, I pretty much agree whole-heartedly. In your problem scenario, that is exactly what I was refering to as "one behavior to rule them all" because that is the end result. It either works their way or it doesn't work at all, which usually means it doesn't work at all, because real world applications don't work like that. Real world applications don't use API's perfectly and they also have different execution paths which may get taken depending on what hardware is detected. The wine tests don't reflect that at all and so are totally synthetic which effectively keeps wine broken.

          Comment


          • #55
            Well.. i do NOT wonder WHY there is so little manpower on the wine dev team tho.
            1. Using a mailing list.. christ.. it's 2020. GET OVER IT.. modernize. Using crap with extremely strict formatting rules to even submit TO the list = ppl wont bother.
            2. Writing those conformance tests would need yet another thing to do for ppl WILLING to help, but do not have 20+ years of WINE programming expertise. Loads of ppl are willing to contribute, but if you are able to get over #1 hurdle, you are sure to be shot down by #2, cos it's yet another learning curve to get to.

            As to #1, sure.... rules are rules. I mean, it's not like GIT have any OTHER means of reviewing patches/submitions other than the 1990'ies version of "Wow, we have interweb!" aka. "mailing-list" Yeah, the kernel dev's still use it.. loads of age-old project still uses this. I've seen "cost issues", "loosing history" and so on as excuses for not using something else... But for me that did not consider programming 30+ years ago, it sure seems like having the "postit notes" version of Facebook... I mean, i am kinda GLAD the days of dialing BBS's is over, although it WAS really exiting at the time when those nifty ASCII symbols ended up making something nifty

            Its "their" project, and we currently do not have any alternatives, so i am pleased the Steam Proton team are able to get around stuff, aswell as other patch contributors submitting to staging and/or other projects.

            Comment


            • #56
              Originally posted by Cybmax View Post
              Well.. i do NOT wonder WHY there is so little manpower on the wine dev team tho.
              1. Using a mailing list.. christ.. it's 2020. GET OVER IT.. modernize. Using crap with extremely strict formatting rules to even submit TO the list = ppl wont bother.
              2. Writing those conformance tests would need yet another thing to do for ppl WILLING to help, but do not have 20+ years of WINE programming expertise. Loads of ppl are willing to contribute, but if you are able to get over #1 hurdle, you are sure to be shot down by #2, cos it's yet another learning curve to get to.

              As to #1, sure.... rules are rules. I mean, it's not like GIT have any OTHER means of reviewing patches/submitions other than the 1990'ies version of "Wow, we have interweb!" aka. "mailing-list" Yeah, the kernel dev's still use it.. loads of age-old project still uses this. I've seen "cost issues", "loosing history" and so on as excuses for not using something else... But for me that did not consider programming 30+ years ago, it sure seems like having the "postit notes" version of Facebook... I mean, i am kinda GLAD the days of dialing BBS's is over, although it WAS really exiting at the time when those nifty ASCII symbols ended up making something nifty
              There's nothing wrong with mailing lists, you're just trying to piss at stuff for no reason. Just because it's an old concept doesn't make it bad. These days, you can filter messages the way you want and customize it on your end (email client).

              You also don't need 20 years of WINE programming expertise to write tests. You need knowledge mostly of Windows APIs and how they work. The reality is that most people are not qualified to do that.

              They add a stupid hack or fix for their app without understanding why it doesn't work in the first place. Which breaks other apps (but not like they give a shit, since their app works!). And they never bother to send a proper implementation of that.

              The only issue I see with wine is sometimes that patches go completely overlooked and not reviewed. Especially those touching more, uhm, "sensitive" parts of wine.

              Comment


              • #57
                Originally posted by Weasel View Post
                There's nothing wrong with mailing lists, you're just trying to piss at stuff for no reason. Just because it's an old concept doesn't make it bad. These days, you can filter messages the way you want and customize it on your end (email client).
                Well, since i am a novice just trying to help, i find crawling through mailing lists horrible vs. things like eg. github. It is a LOT easier (for ME) to look at PR's there, test stuff, update, give feedback vs reading mail threads weed out patches, give feedback and hope it just down drown in the noise. If you honestly mean mailing lists are BETTER, i don't know what to say.... however, if you just mean that mailing lists are "meh.. they are usable"? Why settle for "worse"?

                But if the purpose is to set the bar high to contribute? Sure, the mailing list and an extreme rigid submit system is the way to go. I get that. If you have little manpower, and do not want every joe-bob to submit useless patches that probably do not work - Make it so cumbersome that only a properly interested person will continue. No problem seeing that tho

                I would not mind a hint of an amazing mailing-list reader that would allow for sorting, saving inline text as patches+++ stuff really made for managing mailing lists a HELL of a lot easier than using Thunderbird or some webmail. PS. Must support imap, and preferably not so hard to configure so that i give up way before i can even get something downloaded.

                Comment


                • #58
                  Originally posted by Weasel View Post
                  They add a stupid hack or fix for their app without understanding why it doesn't work in the first place. Which breaks other apps (but not like they give a shit, since their app works!). And they never bother to send a proper implementation of that.
                  Weasel is well and truly on the right track here just did not think quite far enough. Problem is it worse than just breaks other applications. You risk nuking the application you were attempting to fix. The is a very big different with wine between working for now and truly working.

                  https://www.bleepingcomputer.com/new...wine-and-dxvk/

                  This is a classic recent example. Dxvk did not run tests to make sure the optimisation they were doing matched windows. So the patches to make Battlefield V run results in its end users banned for cheating.

                  This is not the first time this happened. Last time this happened was before wine testbot was mandatory on releases and it happened to normal wine users that was over a decade and a half ago.

                  Originally posted by Cybmax View Post
                  Writing those conformance tests would need yet another thing to do for ppl
                  The reality is like it or not if you will not write conformance tests wine are better off without you. Wine project can win agreements we can say to a vendor who as banned people that the behaviour can happen under windows this is what the conformance test shows so the user you banned was just unlucky. No conformance test that program a person spent like 60+ dollars for is now a total brick even if they go back to windows because the account was deleted.

                  Wine project rules are not the way the are for no reason.

                  Originally posted by Cybmax View Post
                  Well, since i am a novice just trying to help, i find crawling through mailing lists horrible vs. things like eg. github. It is a LOT easier (for ME) to look at PR's there, test stuff, update, give feedback vs reading mail threads weed out patches, give feedback and hope it just down drown in the noise. If you honestly mean mailing lists are BETTER, i don't know what to say.... however, if you just mean that mailing lists are "meh.. they are usable"? Why settle for "worse"?
                  Github is not a option as a primary operation location for wine. That is Microsoft and remember Wine at some point could be in legal dispute with Microsoft anything provided by Microsoft is off the table, Even before github was acquired by Microsoft its hosting was azure so Microsoft.

                  We have not had anyone offer to set up hosted gitlab on codeweavers servers. Gitlab has historically moved their hosting around sometime conflicting with wine project requirements that why self hosting by a company trust-able to the wine project is how it has to be yet project would need the labour to-do that.

                  https://source.winehq.org/patches/
                  This here came about because we had someone with the skills who was outside codeweavers who came up with this solution. It is getting a bit long in the tooth I give you as it was being used by wine project before github or gitlab existed.

                  Originally posted by Cybmax View Post
                  But if the purpose is to set the bar high to contribute? Sure, the mailing list and an extreme rigid submit system is the way to go. I get that. If you have little manpower, and do not want every joe-bob to submit useless patches that probably do not work - Make it so cumbersome that only a properly interested person will continue. No problem seeing that tho
                  Not that the project wants it be hard but you need the people with the skill, time and labour to make it easy, Basically this here is all caused by lack of resources and the limitations on what resources the project can directly use.

                  Originally posted by Cybmax View Post
                  I would not mind a hint of an amazing mailing-list reader that would allow for sorting, saving inline text as patches+++ stuff really made for managing mailing lists a HELL of a lot easier than using Thunderbird or some webmail. PS. Must support imap, and preferably not so hard to configure so that i give up way before i can even get something downloaded
                  One of the shocking realities is a lot of wine developers don't read the mailing list at all. This was shown the few times when a patch was being rejected for some reason and forgot to include the author in the CC about why and they came on irc asking about why their patch did not go in. If have not worked out the patches link above is a wine server side mailing list reader that pulls out submitted patches and give the status.

                  Wine mailing lists are a lot lighter used than people would think.

                  https://wiki.winehq.org/Submitting_Patches

                  You never read this did you Cybmax or did not read it carefully. Notice nothing there says you have to read the mailing list. You submit stuff to mailing list and watch status by patches you not the maintainer of wine don't have to read the mailing list. If there is something wrong with your patch you will be emailed about it.


                  Comment


                  • #59
                    Originally posted by oiaohm View Post

                    Weasel is well and truly on the right track here just did not think quite far enough. Problem is it worse than just breaks other applications. You risk nuking the application you were attempting to fix. The is a very big different with wine between working for now and truly working.

                    https://www.bleepingcomputer.com/new...wine-and-dxvk/

                    This is a classic recent example. Dxvk did not run tests to make sure the optimisation they were doing matched windows. So the patches to make Battlefield V run results in its end users banned for cheating.

                    This is not the first time this happened. Last time this happened was before wine testbot was mandatory on releases and it happened to normal wine users that was over a decade and a half ago.
                    This has happened several times with "plain" wine aswell, and this is all dependant on the anti-cheat software in use. If a anti-cheat software is checking against know HASH of the .dll's or other file checks which anti-cheat software sometimes do, this WILL fail nevertheless. Why did it happen (and will do again) recently with DXVK? Because the performance of DXVK is a lot better than WineD3D atm + it is included with Steam Proton, and thus is a LOT more widely used atm. Saying this is because of lack of tests is just pure and utter bullshit. Overly eager anti-cheat and companies enforcing strict rules.. No mater what you do, wine is NOT M$, and if you check for it, there is absolutely no problem detecting that a app/game is run under wine. And if that is enough.. sure.

                    This happened in WoW too a few years back (way before DXVK), but Blizzard reverted the bans, and today the WoW logs even say "Wine detected, skipping NvAPI/ADL loading" to help out non-functioning NVAPI calls. It's a "company issue", not a "Thats what you get for not using pure and perfect wine".

                    Originally posted by oiaohm View Post
                    The reality is like it or not if you will not write conformance tests wine are better off without you. Wine project can win agreements we can say to a vendor who as banned people that the behaviour can happen under windows this is what the conformance test shows so the user you banned was just unlucky. No conformance test that program a person spent like 60+ dollars for is now a total brick even if they go back to windows because the account was deleted.

                    Wine project rules are not the way the are for no reason.
                    As i said above. Strict rules. If i was a game company, i am perfectly in my rights to say "Required: Windows X", and have rules that say if i use non-original dll's, you get banned. Please do not claim that "Nah, the wine team will just show that company the awesomeness of their conformance tests, and they will have to budge". Nah. Not in the real world.

                    Originally posted by oiaohm View Post
                    Github is not a option as a primary operation location for wine. That is Microsoft and remember Wine at some point could be in legal dispute with Microsoft anything provided by Microsoft is off the table, Even before github was acquired by Microsoft its hosting was azure so Microsoft.

                    We have not had anyone offer to set up hosted gitlab on codeweavers servers. Gitlab has historically moved their hosting around sometime conflicting with wine project requirements that why self hosting by a company trust-able to the wine project is how it has to be yet project would need the labour to-do that.
                    Fair enough. Loads of ppl are not too happy with the whole M$ deal, so not having this hosted on github as a site, is not a problem. I am just point out that ME PERSONALLY feel like using a mailing list is "so 1990'ies", and that it would be better to switch.

                    Originally posted by oiaohm View Post
                    Not that the project wants it be hard but you need the people with the skill, time and labour to make it easy, Basically this here is all caused by lack of resources and the limitations on what resources the project can directly use.
                    Yeah. Great ideas only come from seasoned programmers. Why listen to anyone else? Best example of not allowing "outside influence", cos everyone else is just asshats if they cant program as good as me!
                    Honestly, it is THIS high horse the dev's should consider jumping off.

                    Originally posted by oiaohm View Post
                    One of the shocking realities is a lot of wine developers don't read the mailing list at all. This was shown the few times when a patch was being rejected for some reason and forgot to include the author in the CC about why and they came on irc asking about why their patch did not go in. If have not worked out the patches link above is a wine server side mailing list reader that pulls out submitted patches and give the status.

                    Wine mailing lists are a lot lighter used than people would think.
                    Why am i not surprised? But yeah, not reading the forums, and not reading the mailing list. Awesome way to keep in touch with ppl tho. I am sure they have better things to do than to read the super-duper easy to follow mailing list..... If only there would be a niftier way to keep track of stuff.. Oh wait. The mailing list IS great.

                    Originally posted by oiaohm View Post
                    https://wiki.winehq.org/Submitting_Patches

                    You never read this did you Cybmax or did not read it carefully. Notice nothing there says you have to read the mailing list. You submit stuff to mailing list and watch status by patches you not the maintainer of wine don't have to read the mailing list. If there is something wrong with your patch you will be emailed about it.
                    Why do you think there is no need to read the mailing list? I am starting to think YOU are the one not bothering. Ofc i know there is no NEED to, but if you do NOT you REALLY miss a lot. Cos even tho it sux balls to follow, there IS actually loads of comments on patches there that will help out, even if it is not YOU who submitted it. I am not saying i am not ABLE to submit patches, i am saying THERE IS BETTER WAYS in 2020. Christ.. are you one of those guys that still uses a "landline" and a "rolodex" cos it still works fine?

                    You are really kicking dirt in my eye with this shit tbh. The ONLY fucking way to have ANY! following to what the devs are thinking or saying is to read the mailing list. They NEVER talk ANYWHERE else... Well other than you tho, cos you might (for all i know) be an alias to Alexandre
                    Hanging out on IRC is a fruitless task for me tho, cos i think the timedifference is a bit much, so there is no live talk there... but i do from time to time.
                    One nice example would be the lib32 discussion going on. Why would i NOT read stuff like that? And do you think a mailing list is the BEST option for a discussion? Hell.. then i think you should suggest to Michael that he switch this forum to a mailing list. Yeah, having the test results from here on text-only mail would certainly be good enough...

                    Well... Have an amazing weekend.
                    Last edited by Cybmax; 01-17-2020, 02:12 PM.

                    Comment


                    • #60
                      Originally posted by Cybmax View Post
                      This happened in WoW too a few years back (way before DXVK), but Blizzard reverted the bans, and today the WoW logs even say "Wine detected, skipping NvAPI/ADL loading" to help out non-functioning NVAPI calls. It's a "company issue", not a "Thats what you get for not using pure and perfect wine".
                      That was reversed because the wine behaviour was not unique and could not be classed as a cheat and this was provable by the testsuite.

                      Originally posted by Cybmax View Post
                      This has happened several times with "plain" wine aswell, and this is all dependant on the anti-cheat software in use. If a anti-cheat software is checking against know HASH of the .dll's or other file checks which anti-cheat software sometimes do, this WILL fail nevertheless.
                      This stuff we cannot do anything about unless they happen to be in particular countries then its legal. This is not your only form of Anti-cheat.

                      Originally posted by Cybmax View Post
                      Why did it happen (and will do again) recently with DXVK?
                      Electronic Art's anti-cheat system detected program going down a non expected code path repeatably. DXVK caused a behaviour that did not happen with any windows instance so full blown ban hammer because this is cheating when your client is absolutely doing something the other clients are not. Yes this improved games performance under DXVK. The ban is not based on checksums. So Electronic Art's is not reversing this ban and they don't care if you use DXVK under windows or wine either will get you banned.

                      Originally posted by Cybmax View Post
                      Because the performance of DXVK is a lot better than WineD3D atm + it is included with Steam Proton, and thus is a LOT more widely used atm.
                      Wined3d does not trigger this code path monitoring anti-cheat in way a valid install of windows could not have.

                      Originally posted by Cybmax View Post
                      Strict rules. If i was a game company, i am perfectly in my rights to say "Required: Windows X", and have rules that say if i use non-original dll's, you get banned. Please do not claim that "Nah, the wine team will just show that company the awesomeness of their conformance tests, and they will have to budge". Nah. Not in the real world.
                      Sorry wine conformance tests can win at times on this. Depending on the country you are in that non-original Dlls arguement can land you on the wrong side of anti-discrimination. Sometimes applications reduce their anti-cheat protection due to true legal arm twisting wine users would not be able to-do that without conformance testing. So the Nah answers here is only right some of the time. Some of the time the conformance tests existence is a legal sledge hammer.


                      Originally posted by Cybmax View Post
                      Yeah. Great ideas only come from seasoned programmers. Why listen to anyone else? Best example of not allowing "outside influence", cos everyone else is just asshats if they cant program as good as me!
                      Please note I did not say Ideas. "skill, time and labour to make it easy" I wrote it that way particular in the wine bugzilla section over the site we have a lot of feature requests that would improve things. Problem is project don't have anyone with the time or skill or labour(pay) to implementing them. Bits of that have come out of summer of code people before.

                      Originally posted by Cybmax View Post
                      But yeah, not reading the forums, and not reading the mailing list. Awesome way to keep in touch with ppl tho. I am sure they have better things to do than to read the super-duper easy to follow mailing list.
                      https://www.winehq.org/forums
                      I did not say not reading forums. I said not reading mailing list. Note the users mailing list closed years ago.

                      Originally posted by Cybmax View Post
                      If only there would be a niftier way to keep track of stuff.. Oh wait. The mailing list IS great.
                      Mailing list is great for the bits that need time stamped legal and that how it being mostly used.

                      Originally posted by Cybmax View Post
                      Why do you think there is no need to read the mailing list?
                      Its how it currently used by majority of the wine developers.

                      Originally posted by Cybmax View Post
                      following to what the devs are thinking or saying is to read the mailing list. They NEVER talk ANYWHERE else... Well other than you tho, cos you might (for all i know) be an alias to Alexandre
                      Sorry the never talk anywhere else is wrong. Most developer talk happens at the yearly wine conference followed by irc then bugzilla, then https://forum.winehq.org/ and absolute tail of the hunt is the mailing lists.

                      Originally posted by Cybmax View Post
                      Hanging out on IRC is a fruitless task for me tho, cos i think the timedifference is a bit much, so there is no live talk there.
                      That is not possible that time difference is the problem codeweavers is setup with operations spaced around the world. So 24/7 there is always someone in the IRC channel from one of their offices. They do have the habit of being dead quite if there is nothing to talk about.

                      Originally posted by Cybmax View Post
                      One nice example would be the lib32 discussion going on.
                      I really would not say so as it not really a discussion.

                      https://github.com/AndreRH/hangover
                      Above is the long term solution to that lib32 problem. This was fairly much decided at the last wine conference. But the work to get it all working is kind of massive.
                      https://www.winehq.org/pipermail/win...ry/157701.html
                      You were kind of lucky to even get an answer not very details from one of the lead developers working on it.

                      Wine developers working on wine are not very chatty. One line answer if you are lucky at times. You learn more reading over the notes/watching the videos of the wine conference than watching the mailing list all year. In fact watching the mailing list will be highly miss leading.

                      I will give you wine project developer communication is not great or any major volume. Lot of this is not enough hours in day.

                      Wine project core developers don't chat much at all by any means it quite a rare to get more than a 1 line answer.

                      Comment

                      Working...
                      X