Wine 9.0-rc1 Released With Upgraded VKD3D, Wine Wayland Improvements

[kylew77]

Dude, you chose OpenBSD as your OS, aka the OS for people who think Desktop Linux is too mainstream and has too much software and hardware support. The 3 million or so people who bought a Steam Deck care about Wayland enablement.

True that OpenBSD makes Debian look like Windows in terms of popularity. Just getting Chrome sync setup with OpenBSD took some time! Why does steam deck require wayland? It runs KDE, KDE has a X11 mode still.

[varikonniemi]

Yeah it's totally distro's fault that Qt6 is backwards incompatible with Qt5.

Or that drivers won't compile anymore on a newer point release kernel.

Completely. Many distros allow the installation of multiple versions of a program. You can run Qt4 apps at the same time as qt5 and qt6 today if you want. This extends down to even C library. Allowing you to run linux 1.0 and 6.6 apps at the same time.

Driver support is no worse than with windows. Some drivers work across decades, others only in specific release depending on what they touch. Don't act like windows 2k/xp and vista transitions did not make many hardware permanently obsolete as the drivers simply did not work any longer and manufacturer did not release new driver. This does not happen with Linux, as if you need to use said hardware, you can always port the old driver over to the new kernel api. And don't even mention windows11 that made many modern computers obsolete as it puts absurd requirements to even start.

[Weasel]

Completely. Many distros allow the installation of multiple versions of a program. You can run Qt4 apps at the same time as qt5 and qt6 today if you want. This extends down to even C library. Allowing you to run linux 1.0 and 6.6 apps at the same time.

GTK2/3/4 are incompatible in the same address space. You ask how can that happen? It's called libraries and plugins.

Say you use some DAW that uses GTK4 on Linux. Now you load an old DSP plugin that uses GTK2. What happens now?

This is not a problem on Windows, I don't care what you say, this is a fact. You can mix and match gdi32, gdiplus, DirectWrite, DirectDraw, Direct3D 8, Direct3D 12, and so on. In the same address space.

Driver support is no worse than with windows.

LOL. You have to be joking, right? Or trolling?

Yes, Windows XP used a different driver subsystem. Guess what though? Your Windows XP drivers worked on all Windows XP versions, that's more than 10 years.

Windows 7+ drivers work on everything recently since it didn't get changed.

Drivers for Linux risk breaking even in a minor point release update and have to be recompiled due to different ABI.

On Windows you don't download Windows 10 build XYZ drivers, you download ONE binary generic covering a ton of versions. Period. And developers love this, that's why they write drivers for Windows.

[Weasel]

https://doc.qt.io/qt-6/portingguide.html Yes qt6 being backward incompatible to qt5 that an issue under Windows and Linux and Mac OS. Some of these problems are nicely platform neutral.

There is some distribution fault with toolkits like qt5 and qt6 is when distributions package stuff up in ways that you cannot install both.

Not a problem on Windows. Qt5 and Qt6 can be mixed in the same address space because the symbols won't conflict, they're local to the DLL file. On Linux they're usually built with global symbol resolution so it won't work. You can't just recompile the Qt5/Qt6 libs with versioned symbols btw, you have to recompile the apps using them too, and that's not feasible. That's the point here.

See my earlier comment. Imagine you use a DAW on Linux that uses GTK4 or Qt6 or whatever, and load an old plugin that uses GTK2/Qt4. What happens now? You cannot recompile the app and the plugin btw.

As for driver signing, that's a completely separate issue. You can disable it anyway with test signing mode if you are really desperate. It's not a compatibility problem.

[varikonniemi]

So your argument is that in a typically compiled Qt app on Linux it is not possible to run a Qt5 application that tries to use a Qt4 plugin? How is that an issue of Linux, instead of a shitty app? Especially as you seem to admit that a non-shittily compiled app could do it.

Isn't it enough that you can run the same program today as you could on the first official Linux release? As this was kind of what the discussion was supposedly all about, not what shit some shitty program written for linux intoduces. Linux has some 30 years of backwards compatibility. No other OS can match it.

(i admit kernel driver compatibility is maybe not as good as on windows, but it's what made Linux better than windows, no need to stagnate. Why do you need long-term compatibility, when you have everything you need to make it compatible yourself in the event no-one has done it for you?)

[Weasel]

So your argument is that in a typically compiled Qt app on Linux it is not possible to run a Qt5 application that tries to use a Qt4 plugin? How is that an issue of Linux, instead of a shitty app?

How the fuck is that a shitty app? Have you ever used an app with plugins such as a DAW before? There's thousands of audio DSP plugins and only a handful of DAWs.

Of course, the situation on Linux is not as dramatic because you have far less plugins and DAWs available natively (without Wine). This is one of those reasons, lack of compatibility. Hence why it sucks.

Obviously you can use Wine to load Windows plugins and DAWs and they work just fine because Wine has (in theory) same compatibility. That's why Wine/Windows as a platform (not OS) > Linux userland. We were talking about native Linux compatibility though, without Wine.

Just for your info in case you don't know how the whole thing works: Plugins are not just "extensions" to an app (which is what Unix nerds think of in terms of "plugins", see for example GCC plugins which hijack the compiler). No, plugins have a stable API (for example, the VST 2.0 API) that plugins implement and then the host (DAW) simply loads them if they're compatible and export the necessary symbols. That's not the issue though, the issue lies in the dependencies of such plugins.

GCC plugin concept is completely different, it loads plugins and executes their entry point but then it's the plugin's job to hijack what it needs, and so GCC needs to export for example all its symbols for this to work properly. This is a retarded concept but it is what it is.

Clean plugin design simply define an API and how it interfaces with the host and then it's the host's job to call the plugin's capabilities (for example, to process a block of audio). There's nothing weird about this. It's clean.

Isn't it enough that you can run Qt4,5,6 apps at the same time?

No. If you go with such logic you might as well just use a virtual machine, too.

[s_j_newbury]

So your argument is that in a typically compiled Qt app on Linux it is not possible to run a Qt5 application that tries to use a Qt4 plugin? How is that an issue of Linux, instead of a shitty app? Especially as you seem to admit that a non-shittily compiled app could do it.

Isn't it enough that you can run the same program today as you could on the first official Linux release? As this was kind of what the discussion was supposedly all about, not what shit some shitty program written for linux intoduces. Linux has some 30 years of backwards compatibility. No other OS can match it.

(i admit kernel driver compatibility is maybe not as good as on windows, but it's what made Linux better than windows, no need to stagnate. Why do you need long-term compatibility, when you have everything you need to make it compatible yourself in the event no-one has done it for you?)

This isn't quite true. Linux adopted ELF in 1995 with kernel 1.2. Previously Linux only supported the "a.out" binary format. "a.out" support was removed in kernel 5.18. So currently Linux can only run binaries from kernel 1.2, if you want to run LInux 1.0 binaries, you'll need to use a kernel prior to 5.18.

[oiaohm]

Not a problem on Windows. Qt5 and Qt6 can be mixed in the same address space because the symbols won't conflict, they're local to the DLL file. On Linux they're usually built with global symbol resolution so it won't work. You can't just recompile the Qt5/Qt6 libs with versioned symbols btw, you have to recompile the apps using them too, and that's not feasible. That's the point here.

See my earlier comment. Imagine you use a DAW on Linux that uses GTK4 or Qt6 or whatever, and load an old plugin that uses GTK2/Qt4. What happens now? You cannot recompile the app and the plugin btw.

One problem there is a fix on Linux.

https://people.collabora.com/~vivek/dynamic-linking/segregated-dynamic-linking.pdf

https://sourceware.org/glibc/wiki/LinkerNamespaces

Everything you described here has been doable on Linux since 2018 in the same address space using dlmopen. You place a shim between the GTK2/GT4 plugin and the new program using dlmopen and everything now works again.

The reality is Valve paid to fix up the problem you are talking about to use new Opengl with old game that have conflicting lib libstdc++.

Yes the second part points out dlmopen was included on Sun OS where the ELF format comes from and if you look back existed before glibc even exists. This is a case glibc had not implemented a particular feature so causing a limitation. But since 2018 that feature has been implemented.

This is the fun fact Weasel the ELF format is design to have LinkerNameSpaces but then glibc decide only to implement 1 Namespace early on so had not implemented the dlmopen and other features. There are other Sun OS elf features that are still missing like the means to declare LinkerNameSpace splits at link time.

Windows does a linker namespace per library that does have a downside of requiring more ram and being slower Weasel.

Yes valve has huge stack of programs that cannot recompile because they don't have the source code so they funded to solve the problem. Person solving the problem with valve was basically shocked to find that everything that was required was already in the elf format just glibc implementation was lacking.

dlmopen is part of your standard glibc on all current Linux distributions.

Besides mixing Qt5 and Qt6 in the same executable on Windows is not recommend due to needing different versions of the C++ runtime in most cases leading to memory corruption issues .

This is the fun issue Linux instant failure if you don't use dlmopen does prevent creating hidden issues. Creating a shim between old and new allows you to think about if memory between transferred need to be reallocated and copied to prevent memory management issues.

There is a defect to the Windows automatic namespace per library Weasel its that you don't have to think about what you are doing and if any correction code is required. Yes there is a defect to the sun method with ELF dlmopen where you create a shim library between old and new that this is code you have to create.

Some programs like chrome for all .so plugins by default wraps them in dlmopen given them their own linkernamespace. So that DAW being GTK4/Qt6 not being able to load a GTK2/QT4 plugin on Linux is really deficiency in the DAW plugin loader code that can be overcome with a shim library.

As for driver signing, that's a completely separate issue. You can disable it anyway with test signing mode if you are really desperate. It's not a compatibility problem.

It is a linked problem you strike when Microsoft does a kernel change breaking the driver for the vendor. Like it or not Windows 10 in it life time every kernel update has broken drivers.

Linux kernel does more kernel releases per year than Windows that all the difference is in reality.

[Weasel]

One problem there is a fix on Linux.

https://people.collabora.com/~vivek/dynamic-linking/segregated-dynamic-linking.pdf

https://sourceware.org/glibc/wiki/LinkerNamespaces

Everything you described here has been doable on Linux since 2018 in the same address space using dlmopen. You place a shim between the GTK2/GT4 plugin and the new program using dlmopen and everything now works again.

I specifically said without recompilation. Using a different API (dlmopen instead of dlopen) requires recompilation. Duh.

Not sure if you can use LD_PRELOAD to hack it and replace normal dlopen. This could have nasty issues (legit uses of dlopen) and is a pure hack, so yeah. Better to just use something sane like Wine instead.

It is a linked problem you strike when Microsoft does a kernel change breaking the driver for the vendor. Like it or not Windows 10 in it life time every kernel update has broken drivers.

Linux kernel does more kernel releases per year than Windows that all the difference is in reality.

Oh really? Never heard of that. Link 1 such breakage because I'm sure you don't understand the article.

Again, signing has nothing to do with compatibility. It's a security measure, not a compatibility/interface issue.

[pinguinpc]

Add some updates

when build wine using: ./configure --enable-archs=i386,x86_64

appear new dependency:



this depency are related wayland 64bit development files but curiously in my xubuntu 24.04 have wayland dev dependencies installed but wine dont detect (maybe need new version ?)

other thing about this wine, in my case dont show dxvk in 32bit games

but i found new location in wine registry (HKEY_CURRENT_USER) where stay dll overrides for 32bit apps

this is default 64bit apps dll overrides registry location



and this is 32bit apps dll overrides registry location appear with wine 9.0-rc1 in my case



maybe can help for anyone use in same prefix 64bit and 32bit apps like in my case