Wine 3.0 Released With Initial Direct3D 11 Support, D3D Command Stream

[oiaohm]

Quite retarded of them too. Its the -only- component of wine that actually is just a simple wrapper.

Lot of the opengl, valkan for windows opengl and Vulkan is also a very simple wrapper.

Its just you have never looks. galluim nine came out in 2010 and its only direct x 9. Direct x 11 comes out 2009 first direct x 11 only game 2012. Problem here is games even up to current are using a mix of direct x 9 and newer. So galluim nine statement about not doing 10,11,12 direct x as what is required doomed them.

https://github.com/disks86/VK9

Really an item like VK9 stands better chance of being merges as it stands a better chance of being made play ball with opengl and the other direct x versions. Yes that is another thing about galluim nine when you have games/programs using a mix of dx 9 and opengl under wine watch galluim nine cause failures.

The galluim nine method has been quite retarded. So windows compatibility is not as easy as what you would think with how different graphical toolkits have to cooperate with each other.

Really your point of view on galluim nine is insanely bias. The reason why galluim nine was refused is when you enabled galluim 9 using dx10 and 11 applications did work. Worst I had the galluim nine developer try to tell me that wine could not run any direct x application under a year ago and had to point out that was not the case as long as galluim nine was not loaded selected direct x 10 and 11 applications did in fact work but with galluim nine loaded it they broke. Why sections like game splash screens could be still coded in direct x 9 and changing to wine direct x 10 for the output buffer did not work with galluim nine loaded..

To make galluim nine work properly would be a major lot of code alterations including fixing up so galluim nine can share buffers with opengl.

https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx

duby229 basically read the above. See problem dx 9- dx11 has to use compatible buffer solution in background. That buffer solution also has to be compatible with dx 12 now. So its not a case that its a wise idea to attempt to implement direct x 9 as independent work to all the other direct x implementations that are going to be in use.

https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt

Remember I mentioned DX and opengl has to be able to get along. Remember those games you would see with Nvidia only on box. There is a nice opengl extension that is meant to work under windows to allow buffers to be shared between opengl and direct x 9. Of course this is not implemented by galluim nine as they got totally tunnelled vision on implementing direct x 9.

So basically galluim nine fails to connect in properly.

Welcome to reality. Direct x 9-12 has to use compatible buffer/texture/surface. Direct x 9 has to use opengl compatible buffer/texture/surface. If the direct x 9 you attempt to use does not provide these features applications will be broken. There are quite a number of mixed graphical engine games and program out there. MS office for example can be using 9, 10, 11 and 12 direct x at the same time and totally depending on the buffer/texture/surface sharing system.

So for wine implementing direct x since you had to be opengl compatible anyhow just go straight on top of opengl it was the lower developer resource path. Of course going on top of Vulkan is also a valid option this is not breaking the required compatibility with opengl..

[duby229]

Lot of the opengl, valkan for windows opengl and Vulkan is also a very simple wrapper.

Its just you have never looks. galluim nine came out in 2010 and its only direct x 9. Direct x 11 comes out 2009 first direct x 11 only game 2012. Problem here is games even up to current are using a mix of direct x 9 and newer. So galluim nine statement about not doing 10,11,12 direct x as what is required doomed them.

https://github.com/disks86/VK9

Really an item like VK9 stands better chance of being merges as it stands a better chance of being made play ball with opengl and the other direct x versions. Yes that is another thing about galluim nine when you have games/programs using a mix of dx 9 and opengl under wine watch galluim nine cause failures.

The galluim nine method has been quite retarded. So windows compatibility is not as easy as what you would think with how different graphical toolkits have to cooperate with each other.

Really your point of view on galluim nine is insanely bias. The reason why galluim nine was refused is when you enabled galluim 9 using dx10 and 11 applications did work. Worst I had the galluim nine developer try to tell me that wine could not run any direct x application under a year ago and had to point out that was not the case as long as galluim nine was not loaded selected direct x 10 and 11 applications did in fact work but with galluim nine loaded it they broke. Why sections like game splash screens could be still coded in direct x 9 and changing to wine direct x 10 for the output buffer did not work with galluim nine loaded..

To make galluim nine work properly would be a major lot of code alterations including fixing up so galluim nine can share buffers with opengl.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

duby229 basically read the above. See problem dx 9- dx11 has to use compatible buffer solution in background. That buffer solution also has to be compatible with dx 12 now. So its not a case that its a wise idea to attempt to implement direct x 9 as independent work to all the other direct x implementations that are going to be in use.

https://www.khronos.org/registry/Ope...DX_interop.txt

Remember I mentioned DX and opengl has to be able to get along. Remember those games you would see with Nvidia only on box. There is a nice opengl extension that is meant to work under windows to allow buffers to be shared between opengl and direct x 9. Of course this is not implemented by galluim nine as they got totally tunnelled vision on implementing direct x 9.

So basically galluim nine fails to connect in properly.

Welcome to reality. Direct x 9-12 has to use compatible buffer/texture/surface. Direct x 9 has to use opengl compatible buffer/texture/surface. If the direct x 9 you attempt to use does not provide these features applications will be broken. There are quite a number of mixed graphical engine games and program out there. MS office for example can be using 9, 10, 11 and 12 direct x at the same time and totally depending on the buffer/texture/surface sharing system.

So for wine implementing direct x since you had to be opengl compatible anyhow just go straight on top of opengl it was the lower developer resource path. Of course going on top of Vulkan is also a valid option this is not breaking the required compatibility with opengl..

And that whole wall of text boils down to you aren't gonna do it ever, so what was the point writing that wall? I will read through your links of course., but I definitely don't agree with you at all. As long as you guys are translating DX to GL that wall of text you wrote will always be true, but it's -only- because you chose that path.

And yet the bottom line truth is that gallium nine has better compatibility and performance almost across the entire list of games. Despite real world limitations of gallium itself wine's translation from DX to OGL doesn't come close and has no chance to.

[oiaohm]

And that whole wall of text boils down to you aren't gonna do it ever, so what was the point writing that wall? I will read through your links of course., but I definitely don't agree with you at all. As long as you guys are translating DX to GL that wall of text you wrote will always be true, but it's -only- because you chose that path.

And yet the bottom line truth is that gallium nine has better compatibility and performance almost across the entire list of games. Despite real world limitations of gallium itself wine's translation from DX to OGL doesn't come close and has no chance to.

LOL read again. Across the complete list of support applications of wine only 30 percent work with galluim nine. Please note I say work as in run with galluim nine they would crash out. This was many platuim status wine programs that no longer would work with people using gallium nine. Due to all the issues with cross direct x version support and gdi and opengl that gallium nine is missing.

Lets not forget all the people using wine on OS X who gallium nine is not even an option. The wall of text was not about wine problem is about a major design problem in the way galluim nine was implemented. To fix galluim nine problems most likely would be rewrite the core of it completely from scratch. The developer of galluim nine started with a fatal presume that opengl and direct x were independent and that direct x versions were independent .

The focus has moved to Vulkan as VK9 is showing most of the performance gains of galluim nine and it at least using something that could be integrated.

Wine project is not stuck to always do a DX to OGL. DX to EGL and DX to Vulkan will be looked at for android usage and future wayland usage.

Basically your point of view about gallium nine is what is called user bias not based on the numbers. Just because some programs perform better does not mean the number of programs that still work are the same. This is the problem with gallium nine make some programs run better and a lot of other programs not run at all.

Of course wine people were highly offend when it was just said hey you will have to disable gallium nine every time it breaks something because we developers of gallium nine are not going to implement dx 10,11,12 and opengl compatibility as required and wine developers know making these work will require core alterations to gallium nine.

duby229 about time you pull you head in and wake up gallium nine was reject on technical grounds and flat out refuse from maintainer of gallium nine to implement what was required. Of course wine project lead developer has changed mind on items in past if the technical problems get addressed.

Basically no matter how much you attempt to lie will not change the fact that gallium nine at core is defective. Since that is the case no point merging it and have people look else where like VK9 and hope these projects end up done in way that can be used. Or pray that gallium nine maintainer alter course or gets replaced.

[Hi-Angel]

To be correct the answer you got about why is C89 is part right.

https://developercommunity.visualstudio.com/content/problem/168219/incomplete-ansi-c99-stdio-support-in-windows-sdk.html

MSVC even the most current version does not properly support C99. When wine developers want to attempt a substitution test. This is where a dll from wine is built with MSVC then used to replace that dll under windows to check that behaviours are right not being MSVC compatible at that point causes problems. So some sections are pure C89 others are using gnu89 features.

Oh, this is an interesting point. But I'm still not convinced — isn't it possible to target more modern compiler under Windows (e.g. if not mingw then why not clang?), and pass to the linker options to set some fields/signatures to look like it was built with MSVC?

MSVC does not support gnu89. Wine usage of gnu extensions is required for mapping between platform native code and windows applications.

Ah, I see, so probably parts of the code with gnu89 are hidden under #ifdefs, and does not show up upon built under MSVC.

It is a problem wine project rules forbid any change that results in build and test server failure.

https://wiki.winehq.org/Code_Hygiene Its part of wine project Code_Hygiene. No added patches are meant to add more warning messages in the build process.

So just straight up pushing up the requirement is against project rules. The project rules also prevents submitting hacks to make 1 application work and like 200 others fail.

Wine would need patches fixing wine to use as much C standard as MSVC support with the C99 missing bits from MSVC and higher stuff possibly #ifdef before the requirements could be pushed up so you have not broken rules on the build server and if you break rules on the build server the patch can be tagged to be rejected..

Its one of the thing when dealing with open source projects there are rules that the community has formed at times those forbid going about things particular ways. Sometimes it makes things a pain.

This case rules created to enforce quality do get in way and its not like making exceptions to quality rules is a good thing as this normally comes a slippery slope of you bypassed the rules then why cannot this case bypass the rules and very quickly you are rule less.

I feel there's some misunderstanding. I didn't mean making a code that gonna cause tests to start failing. I was referring to fails of compiler to build the code. I can't be certain without looking the code, but I'm 90% sure that problems after adding C99 code to C89/gnu89 would lead to problems of type "compile/won't compile", not to "compile with incorrect behavior".

[edwaleni]

I would like some wealthy eccentric rube to donates his millions to Wine and ReactOS and get them off the eternal starved feature request wagon.

Where are the JP Morgan's of today who used to fund the Edison's and Tesla's of yesteryear?

[oiaohm]

Oh, this is an interesting point. But I'm still not convinced — isn't it possible to target more modern compiler under Windows (e.g. if not mingw then why not clang?), and pass to the linker options to set some fields/signatures to look like it was built with MSVC?

Lot of windows programs are built with MSVC and when you want to debug end to end MSVC built open source test/application having the DLL built with MSVC is useful so that the debugging information all aligned up.

The annoying part is that generating MSVC debugging information from mingw or clang built code for windows is a uphill battle.. You do have https://github.com/rainers/cv2pdb but it does always get the conversion right and you could waste many hours before you work out that the pdb file was generated wrong and its leading you to hell. Even having gdb attempt to use pdb files for MSVC built part is a path to hell.

If everything worked and was not in the state of maybe I will today and next update I will not.

Basically its the debugging information formats that send everything to hell. Yes in theory you should be able to build a dll with mingw or clang and debug with Microsoft debugger for MSVC built stuff by using the right tools but having it work in real world it unstable and unpredictable.

Ah, I see, so probably parts of the code with gnu89 are hidden under #ifdefs, and does not show up upon built under MSVC.

Yes they are but look at those #ifdefs is what tells you that wine is gnu89 or greater. As when you are using feature greater than gnu89 it wrapped up behind #ifdefs.

I feel there's some misunderstanding. I didn't mean making a code that gonna cause tests to start failing. I was referring to fails of compiler to build the code. I can't be certain without looking the code, but I'm 90% sure that problems after adding C99 code to C89/gnu89 would lead to problems of type "compile/won't compile", not to "compile with incorrect behavior".

Wish it was that simple. Wine has been tested with gnu99 and it build and runs.

https://bugs.winehq.org/show_bug.cgi?id=20474

The tests with pure C99 currently wine breaks into a million pieces of fail and even if you were to fix all the apparent failure points you would most like have some incorrect behaviours..

What is interesting is that wine configuration process checks for C89 and __GNU__ flag but it does not set a flag limiting the compiler to a particular standard so it basically goes with the highest version of gnuxx the compiler supports.

https://github.com/wine-mirror/wine/blob/5a7ce7ccb1f9e5c958ba1b7e6dfdaa0cd697f9b1/include/msvcrt/crtdefs.h

And if you look around the wine source you will see different #ifdef based on gcc version. As in gnuxx support this feature as of X version of gcc if not X version of gcc or greater use this other code.

Yes there are examples of fragments of C99 features inside wine source if you dig deep enough protected by #ifdef.

Supporting broad range of compilers the way wine does is a source of some nightmares.

Coding on wine is coding from gnu89 to gnu11+ with other gcc targeted addons thrown in for good measure + support for MSVC + support for where mingw is odd and support for where clang is odd. So it kind of a nightmare that need payment in a lot of cases to deal with it.

[Hi-Angel]

Lot of windows programs are built with MSVC and when you want to debug end to end MSVC built open source test/application having the DLL built with MSVC is useful so that the debugging information all aligned up.

The annoying part is that generating MSVC debugging information from mingw or clang built code for windows is a uphill battle.. You do have https://github.com/rainers/cv2pdb but it does always get the conversion right and you could waste many hours before you work out that the pdb file was generated wrong and its leading you to hell. Even having gdb attempt to use pdb files for MSVC built part is a path to hell.

If everything worked and was not in the state of maybe I will today and next update I will not.

Basically its the debugging information formats that send everything to hell. Yes in theory you should be able to build a dll with mingw or clang and debug with Microsoft debugger for MSVC built stuff by using the right tools but having it work in real world it unstable and unpredictable.

Another workaround is to start using C++ (and IMO if we target at least C++14 it's a much better one). As an example of a great project that successfully mixes both C and C++ I can point out Mesa. MSVC supports C++ just fine, so building with it should cause no problems.

Wish it was that simple. Wine has been tested with gnu99 and it build and runs.

https://bugs.winehq.org/show_bug.cgi?id=20474

The tests with pure C99 currently wine breaks into a million pieces of fail and even if you were to fix all the apparent failure points you would most like have some incorrect behaviours..

But the bug you linked tells that it doesn't compile with c89, c99, c11 — not that it ends up in incorrect behavior.

---

Thanks, it was a pleasure to read your comments, both on C89 and Gallium Nine, it's the first time I actually feel there are real technical reasons behind instead of something vague maybe-politic-maybe-just-because.

[ssokolow]

Isn't integration with your linux desktop environment a good thing? The more seemless the better right?

I don't want clueless Windows applications innocently scribbling all over the walls of my nice clean Linux profile and it doesn't help that Windows game developers don't comprehend that save files are not documents.

Am I likely to double-click a game's save file to launch the game? ...or organize it beyond what the game provides internally? ...or e-mail it to someone? ...or copy it to a thumbdrive to take along with me? No! Therefore, it belongs in AppData, not My Documents!

Much better to turn off all integration, use something like PlayOnLinux as a launcher and let deleting the game from PlayOnLinux guarantee a clean uninstall from the system. (Retaining save files can be solved by symlinking the WINEPREFIX's C:\users to something like ~/.local/share/PlayOnLinux/userdata/<GameName>.

(Why, yes, I do install my GOG Linux games using a wrapper script around unzip gog_name_of_game.sh 'data/noarch/*'.)

...not that Linux ports are immune to this. One of the biggest reasons I'm looking forward to when I have time to upgrade to a Kubuntu version with Flatpak is that I'll finally be able to prevent games like The Escapists and applications like MakeHuman from creating folders in $HOME that can't be hidden because that would involve renaming them. (The Escapists is a particularly nasty example because, rather than listening to a forged $HOME from a wrapper script, it goes direct for the system calls to query /etc/passwd.)

[artivision]

Lot of the opengl, valkan for windows opengl and Vulkan is also a very simple wrapper.

Its just you have never looks. galluim nine came out in 2010 and its only direct x 9. Direct x 11 comes out 2009 first direct x 11 only game 2012. Problem here is games even up to current are using a mix of direct x 9 and newer. So galluim nine statement about not doing 10,11,12 direct x as what is required doomed them.

https://github.com/disks86/VK9

Really an item like VK9 stands better chance of being merges as it stands a better chance of being made play ball with opengl and the other direct x versions. Yes that is another thing about galluim nine when you have games/programs using a mix of dx 9 and opengl under wine watch galluim nine cause failures.

The galluim nine method has been quite retarded. So windows compatibility is not as easy as what you would think with how different graphical toolkits have to cooperate with each other.

Really your point of view on galluim nine is insanely bias. The reason why galluim nine was refused is when you enabled galluim 9 using dx10 and 11 applications did work. Worst I had the galluim nine developer try to tell me that wine could not run any direct x application under a year ago and had to point out that was not the case as long as galluim nine was not loaded selected direct x 10 and 11 applications did in fact work but with galluim nine loaded it they broke. Why sections like game splash screens could be still coded in direct x 9 and changing to wine direct x 10 for the output buffer did not work with galluim nine loaded..

To make galluim nine work properly would be a major lot of code alterations including fixing up so galluim nine can share buffers with opengl.

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

duby229 basically read the above. See problem dx 9- dx11 has to use compatible buffer solution in background. That buffer solution also has to be compatible with dx 12 now. So its not a case that its a wise idea to attempt to implement direct x 9 as independent work to all the other direct x implementations that are going to be in use.

https://www.khronos.org/registry/Ope...DX_interop.txt

Remember I mentioned DX and opengl has to be able to get along. Remember those games you would see with Nvidia only on box. There is a nice opengl extension that is meant to work under windows to allow buffers to be shared between opengl and direct x 9. Of course this is not implemented by galluim nine as they got totally tunnelled vision on implementing direct x 9.

So basically galluim nine fails to connect in properly.

Welcome to reality. Direct x 9-12 has to use compatible buffer/texture/surface. Direct x 9 has to use opengl compatible buffer/texture/surface. If the direct x 9 you attempt to use does not provide these features applications will be broken. There are quite a number of mixed graphical engine games and program out there. MS office for example can be using 9, 10, 11 and 12 direct x at the same time and totally depending on the buffer/texture/surface sharing system.

So for wine implementing direct x since you had to be opengl compatible anyhow just go straight on top of opengl it was the lower developer resource path. Of course going on top of Vulkan is also a valid option this is not breaking the required compatibility with opengl..

Gallium Nine never failed me, WineD3D did many times. That after 40+ games. What a crap is this WineD3D?

[oiaohm]

Gallium Nine never failed me, WineD3D did many times. That after 40+ games. What a crap is this WineD3D?

Problem here since I do support on wine. I am not looking at the information from 40 games. I am looking 5000+ games and applications. Gallium Nine looks very bad when you are looking big picture. Look great when you are using applications that work with it. Of course the wine developers like me are looking big picture and wants something that fits properly and works for the big picture.

Failure to understand that there is a big picture means people start demand items like galluim nine get included when they don't have the technical merit to be included then yell at the developer for being foolish. Wine project rules does not support per application or applications hacks. Part of the prime objective of wine is to be able to run everything without user having to change settings. Galluim nine since it does not support the integration between direct x versions and opengl does not meet part of the prime objective either.

Unless there is changes in gallium nine developer it would be better to support VK9 at least there is a fair chance for that to merge. Its possible to share from vulkan buffers back to normal opengl and direct x under windows and it already possible from the vulkan support in wine to do that with existing parts. So linking VK9 in properly is in fact possible.