Originally posted by VikingGe
View Post
Announcement
Collapse
No announcement yet.
Wine-Staging Will No Longer Be Putting Out New Releases
Collapse
X
-
In my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.
In the same way that Magento Store and many other commercial products seperate their commercial products IMO there is space for 3 products.
1. CrossOver Commercial
2. Wine (For Mac, Linux, ReactOS, Android, etc...)
3. Wine Community Edition or Wine Experimental (basically what Wine-Staging was)
As I recall ,one of the big reasons staging existed at all was because wine developers refused to add in code that solely benefited the Linux platform. For example Gallium Nine doesn't benefit MacOS users of Wine or CrossOver Mac users. Another example in the same vein might be the GTK3 support.
I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."
- Likes 4
Comment
-
Originally posted by ElectricPrism View PostIn my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.
In the same way that Magento Store and many other commercial products seperate their commercial products IMO there is space for 3 products.
1. CrossOver Commercial
2. Wine (For Mac, Linux, ReactOS, Android, etc...)
3. Wine Community Edition or Wine Experimental (basically what Wine-Staging was)
As I recall ,one of the big reasons staging existed at all was because wine developers refused to add in code that solely benefited the Linux platform. For example Gallium Nine doesn't benefit MacOS users of Wine or CrossOver Mac users. Another example in the same vein might be the GTK3 support.
I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."
They use "system integration" to justify various things I always turn off (like letting my Windows applications muck with my filetype associations and games fill my documents folder with crud that belongs in AppData even on Windows). I'd love to have something which bridges in Qt or GTK+ widget drawing (preferrably Qt but I suspect GTK+ would be chosen) as a Windows theming engine.
- Likes 1
Comment
-
Sad and glad to finally hear some news on staging. Now they can hand over the project or people can fork it to further experimental work.
Originally posted by ElectricPrism View PostIn my opinion the fact that staging ever existed is validation that Wine Team is missing a BIG opportunity to provide value to the community.
....
I could be wrong, but I think that wine devs need to take a step back and ask themselves "Why did this fork exist and why was it so popular? And what we can do to provide for our users a similar value."
With the line drawn there, it makes it more secure for commercial or community projects to focus on those extra features which the best of can later be fed upstream.
Comment
-
Originally posted by leipero View PostWhile it is sad that maintainers do not have time to work on staging anymore, most people use wine-staging for CSMT support, and I've used it for nine support also. That being said, most distributions do patch wine anyway with some paches (Arch adds harmony-fix by default) and add optional support (Arch does silverlight and wine-binfmt by default for packages), so it's relatively easy to add patch for CSMT support (if it's needed in 3.x???) and make PPA for Ubuntu (since people would have to add wine PPA for staging anyway, at least last time I've tried Ubuntu).
As I'm writing, wine 3.2 and nine is building in background, will see if it works, if no one makes AUR for it, I might as well upload it (tho it is pain in the a** to maintain it, that's why I would avoid it).
- Likes 2
Comment
-
Originally posted by wpupkin View PostOk, take nvapi, nvcuda, vulkan patches and DLL Redirects support into main tree and I'm fine with this.
The current implementation of DLL redirects does not store any information about loaded dlls which were redirected. This causes trouble if an application tries to manually load the target of a redirection while the same library is already loaded under a different name. Wine does not notice that the library was already loaded and tries to load it a second time. The behaviour of builtin/native DLLs is slightly different, but in both cases an application might be confused.
So until someone fixes the known issue it will remain rejected. Using a WINEPREFIX per application with dll overrides works stable.
This is back in history please note the improved fake dlls. Wine has merged this mainline. DLL redirects patch depends on messing with the loader provide by the OS. But since windows has started mandating signing a lot of programs that take add dlls have added there own PE Loader so the add on do not have to be signed.
So this means dll redirects need to be complete rewritten to sit behind the fake dlls most likely required the redirected dll to be a dll.so or another form of dll outside the WINEPREFIX where the application is not normally going to find it. When someone rewrites the patch in a functional then you can have that feature..
nvapi, nvcuda I do not know why they have not been ever submitted to wine devel.
There is a wine-vulkan git out there. Please note its missing all the extra staging because the staging were breaking most of applications he was trying to test with.
- Likes 1
Comment
-
Originally posted by leipero View PostWhile it is sad that maintainers do not have time to work on staging anymore, most people use wine-staging for CSMT support, and I've used it for nine support also. That being said, most distributions do patch wine anyway with some paches (Arch adds harmony-fix by default) and add optional support (Arch does silverlight and wine-binfmt by default for packages), so it's relatively easy to add patch for CSMT support (if it's needed in 3.x???) and make PPA for Ubuntu (since people would have to add wine PPA for staging anyway, at least last time I've tried Ubuntu).
As I'm writing, wine 3.2 and nine is building in background, will see if it works, if no one makes AUR for it, I might as well upload it (tho it is pain in the a** to maintain it, that's why I would avoid it).
Originally posted by Dehir View PostWell its not bad having different experimental tree as staging. But if it dies away. Are the all "major" and important parts from it allready included in main tree like csmt etc?
And whats the future of Gallium fork? I think it runs best all dx9 games atleast with my rx480.
Thou in general i think this can be better for wine in general to ease things and try to focus everything on main branch
Unless the Gallium implementation adds more versions of direct x at some point it will just be more trouble than it worth. Yes a lot of people using Gallium nine try to run a more modern program complain that it don't work and we have test results in the appdb that it does and it all caused because Gallium nine does not support multi version direct X usage. Even some old dx7-dx8-dx9 hybrid applications also explode if you have gallium nine installed. The reality is Gallium nine is a broken patch set wine developers have attempted to tell them that only to get response we are only interested in dx 9.
Originally posted by pinguinpc View PostYeah wine devs stay more interesting in functions with tests (without tests many patches dont approved)
However step by step wine begin add more staging patches but no in same way than staging
The demand on test casing is 1 to prevent regressions 2 to locate functions where Microsoft/Nvidia/AMD developers have been inconstant in implementation so you know when you are heading into hell. Its not like wine runs test.winehq.org using VM machines running windows running the test cases for no good reason.
- Likes 4
Comment
-
Originally posted by geearf View Post
I have an aur package simply for nine, no need to bundle it with wine anymore
oiaohmCSMT patches are merged into wine 3.0. This is part of why there is less people to support staging as the developer who was working on CSMT is now back working on mainline and not needing staging any more.
Comment
Comment