Wine 8.5 Released With VKD3D 1.7 Included, WinRT App Dark Theme

[avis]

Due to the newly emerging world order and the trade wars, it is the best time for Linux to be used and spread more and more, especially by countries like China and Russia, which are in conflict with the USA.
China wants to ban Microsoft with Windows from China as early as 2025 and also rely on its own hardware, which will then run Linux. Russia also wants to rely more on Linux in order to no longer be so digitally dependent on the USA.

And not to forget, the world's largest company in the games industry is Tencent, which is based in China.

(I exclude ruling organization and human rights).

China is doubling down on Linux in a bid to leave Windows behind

https://www.techradar.com/news/china-is-doubling-down-on-linux-with-new-project

China banning Windows has always been nothing but posturing. Their Linux endeavors so far have been a complete and utter failure. Just like North Korea's state Linux distro.

[Weasel]

I don't know about everyone else here but celebrating how great Win32 API works under Linux is kinda depressing to me.

It just sounds like a complete failure of Linux to become a viable software platform for developing proprietary applications which can work for decades without recompilation and struggling with dependencies. Something which Windows provides in spades.

And, nah, flatpak/snap are not the right solution. They are a lame attempt to hide the issue. It's like admitting the entire Linux user space is a big load of poo and you can only rely on the Linux kernel user interface (API).

That's like saying WSL is bad since it allows you to run apps that are not available for Windows or whatever. Yet, I'm pretty sure you wouldn't flame Windows at all for supporting it, nor think of it as a weakness, but rather a strength. The double standards are real with this one.

Not sure what you expect. Even if the userland library situation wasn't as awful, it would suck (note that it's not Linux's fault specifically, it's also the stupid ELF format, MacOS has similar issues here since dylibs are similar to ELF .so). There should be no fucking reason you can't just ship an old library version to maintain backwards compatibility. The real issue is that ELF will conflict with symbols since devs tend to use the same names on newer libraries that break the ABI. This isn't a problem with PE (Windows DLLs) since they specify from which library a symbol is supposed to be found on, so even if two symbols share the same name in two different libraries, no issue whatsoever.

The other issue is that companies don't want to offer official support for Linux since marketshare is too low and it's open source aka people can fuck up their systems too much and it's a pain for tech support to handle it. That's one of the main reasons actually, because most games tend to be statically linked anyway, so…

[dragon321]

Tbh, nothing in the desktop OS space as a whole really comes close to win32's backwards compatibility. I mean look at MacOS. Its backwards compatibility isn't any better than Linux's. In some ways its even worse. I've read comments that if you want to run a version of Photoshop from just a few years ago on modern MacOS versions, it will not work (and this isn't because of phasing out 32 bit support in Catalina).

Sure macOS backwards compatibly are not close to Windows backwards compatibility but it's better than Linux in that regard that core stuff is backwards compatible. For example I have application developed in Mac OS X Snow Leopard (released in 2009) written in Objective C and Cocoa and it still works fine on macOS Ventura (released in 2022) running on Apple Silicon Mac. While on Linux if you have some GTK+2/Qt4 application it's not going to run on system with GTK4/Qt6. While Linux kernel is backwards compatible for applications, userland is not and API breakage occurs in almost every essential library. So you need to port your application to the new library or use old that can be years without maintenance.

[Nozo]

Sure macOS backwards compatibly are not close to Windows backwards compatibility but it's better than Linux in that regard that core stuff is backwards compatible. For example I have application developed in Mac OS X Snow Leopard (released in 2009) written in Objective C and Cocoa and it still works fine on macOS Ventura (released in 2022) running on Apple Silicon Mac. While on Linux if you have some GTK+2/Qt4 application it's not going to run on system with GTK4/Qt6. While Linux kernel is backwards compatible for applications, userland is not and API breakage occurs in almost every essential library. So you need to port your application to the new library or use old that can be years without maintenance.

How is FreeBSD backwards compatibility compared to Linux? According to the FreeBSD team they care a lot about it, and that is demonstrated by NVIDIA's proprietary drivers, which derivatives like GhostBSD have shown that discontinued off-tree drivers can be installed and deployed straight and easily, while on Linux doing the same with legacy drivers is a nightmare.
Try installing the old NVIDIA proprietary drivers on Linux on any distribution other than Ubuntu via some random PPAs and you'll know what i'm talking about.

[dragon321]

How is FreeBSD backwards compatibility compared to Linux? According to the FreeBSD team they care a lot about it, and that is demonstrated by NVIDIA's proprietary drivers, which derivatives like GhostBSD have shown that discontinued off-tree drivers can be installed and deployed straight and easily, while on Linux doing the same with legacy drivers is a nightmare.
Try installing the old NVIDIA proprietary drivers on Linux on any distribution other than Ubuntu via some random PPAs and you'll know what i'm talking about.

In user land (for applications) it's pretty similar to Linux as far I know. Situation is little different here as FreeBSD is full operating system, not just kernel. So it's certainly easier to keep stable user space for applications as they control both kernel and user space. As for kernel it is stable within major release, so for example if you have driver written for FreeBSD 12.0 it should still work in FreeBSD 12.4.

[dacha]

How is FreeBSD backwards compatibility compared to Linux?

Within the base system, FreeBSD is more backward compatible than Linux, but very few applications rely only on libraries in the base system. So libc and pthreads and ncurses will break less often, but graphical applications using GTK / Qt will break just as often as on Linux. Also, libc incompatibilities on Linux are largely a thing of the past.

Applications also access kernel interfaces to hardware, where the fact FreeBSD maintains code and avoids unnecessary rewrites, unlike Linux, also helps. So if you wrote an old game using OSS for sound, it will continue to work on FreeBSD, whereas on Linux you'd have to rewrite it to use ALSA instead.

[DMJC]

Cisco uses Linux for all of their application platforms. e.g Cisco ISE, Call Manager, DNA, etc. Linux has a massive market in corporate applications. It's really only end-user desktops that have lagged. That's changing too, linux native Webex Teams is already working.