Announcement

Collapse
No announcement yet.

Wine 6.11 Released With Theming Support For All Built-In Programs

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

  • #11
    Originally posted by ix900 View Post

    What you're saying is basically that wine is so broken that it can't do its one thing correctly so it has to be splintered into multiple. That cannot be correct.

    Point in fact I've seen code not added to wine in tkg's or ge's projects and it is stuff that should be added to Wine since its stubbed or unfinished. No one adds it.

    I do not see it your way ;-)
    Well, i do not disagree with you completely, because i aswell would like to and do not always understand why it does not work that way. What i do know is that it is somewhat of a rigid system to get stuff accepted upstream wine. Just look at all the code in staging that DO WORK, but does not seem to ever be accepted mainline.

    Some of it is understandable, as wine (i guess) strive for stability even tho it is not always the case, vs staging strive to "get things working" albeit code not deemed stable/correct enough. I do not know why staging <-> wine could never be "1 project" other than that staging is "experimental". A lot of code goes from staging -> upstream tho, so it is working even tho it is a very slow process.

    When it comes to proton, this is a "STEAM gaming branch", so it is a different project altogether (Different goals). TKG/GE is "enthusiast projects" and although contributing with code it is usually picking useful patches from proton/staging/other and putting it together. I also do that for my own wine version - picking proton patches, and other "performance patches" i find from various sources. Some of this is definitely not "production ready" code, as it is "hacks" to fix problems. (Eg. vulkan fullscreen hack patches, that really work great imo)
    WineHQ team i think try to avoid those "hacks" even tho it works. I have at some occasions spoken out on this... cos as you point out they SOMETIMES add stub's that are "unsafe", yet at other times is very rigid at adding (to me seemingly) working code.

    Think of it like this then: Why do not all distro kernels have the futex wait multiple (fsync), or futex2 pathes? Why do you have to use a 3rd party kernel for your distro? The distro kernels are CLEARLY not working optimally then? Or even winesync/fastsync kernel module + wine patches? It works fine, and could even be built as a standalone 3rd party kernel module with dkms. Don't see that in the Ubuntu repo....
    Oh.. cos it is still "experimental code" that is not yet upstream.

    It is what it is....

    Comment


    • #12
      Originally posted by ix900 View Post
      What you're saying is basically that wine is so broken that it can't do its one thing correctly so it has to be splintered into multiple. That cannot be correct.
      Windows itself uses compatibility shims for older apps on newer Windows versions, so even Windows arguably had to be "splintered into multiple" for everything to work as well as it does.

      The LGPL licence also prevents Wine from being closed off, so these forks aren't necessarily that harmful.

      Comment

      Working...
      X