Announcement

Collapse
No announcement yet.

Wine 7.5 Released With HLSL Compiler Support For Bundled VKD3D

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

  • Wine 7.5 Released With HLSL Compiler Support For Bundled VKD3D

    Phoronix: Wine 7.5 Released With HLSL Compiler Support For Bundled VKD3D

    Wine 7.5 is out as the latest bi-weekly software update for enjoying Windows games and applications under Linux, macOS, and other platforms...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Nice!

    Finally compiler is hooked into Wine dlls:

    https://source.winehq.org/git/wine.g...ompiler.c#l940

    I'll test if it helps with Cyber Engine Tweaks for Cyberpunk 2077 to void installing d3dcompiler_47 native override.
    Last edited by shmerl; 25 March 2022, 06:35 PM.

    Comment


    • #3
      Originally posted by shmerl View Post
      Nice!

      Finally compiler is hooked into Wine dlls:

      https://source.winehq.org/git/wine.g...ompiler.c#l940

      I'll test if it helps with Cyber Engine Tweaks for Cyberpunk 2077 to void installing d3dcompiler_47 native override.
      If I had to make an educated guess:

      Most likely not, but please prove me wrong...

      Comment


      • #4
        I'm curious about this ALSA driver that converts to PE (portable executable). What does that do and how does that work? I'm not a developer, but more of an IT folk, so while I do not mind anything technical, I would like to have it explained in layman's terms.

        And Phoronix does certainly have a lot of "developer-focused" jargon even though I'm an experienced Linux user.

        Comment


        • #5
          Originally posted by GraysonPeddie View Post
          I'm curious about this ALSA driver that converts to PE (portable executable). What does that do and how does that work?
          For some time, Wine has had an ongoing project to convert all of its "Windows-side" code (the bits that are linked to and called by Windows programs, which implement the various Windows system calls) so that it is stored on disk as native Windows .dll files in the PE file-format instead of having dummy DLLs with the actual code being kept in Linux .so files in ELF format.

          As I understand it, the main benefit of this is that the various DRM and anti-cheat schemes are more likely to work because what is loaded into memory matches what they can see on disk when they read the DLLs to check whether they have been tampered with; with the "old" way, the DLL on disk would just be a list of exported functions while what was in memory would be a Linux shared object implementing those functions.

          There may well be other benefits for maintainability and/or portability too: PE is the one "constant" which is always present in Wine - it's a key part of what it is there to do, after all.

          Comment


          • #6
            Wine is so outdated on Debian and Ubuntu. Still version 6.0. 😥️

            Edit: jammy-proposed is now pushing version 6.7 for the wine-development package. The ordinary "wine" package is still 6.0 though.
            Last edited by uid313; 26 March 2022, 06:49 AM.

            Comment


            • #7
              Originally posted by molletts View Post
              For some time, Wine has had an ongoing project to convert all of its "Windows-side" code (the bits that are linked to and called by Windows programs, which implement the various Windows system calls) so that it is stored on disk as native Windows .dll files in the PE file-format instead of having dummy DLLs with the actual code being kept in Linux .so files in ELF format.

              As I understand it, the main benefit of this is that the various DRM and anti-cheat schemes are more likely to work because what is loaded into memory matches what they can see on disk when they read the DLLs to check whether they have been tampered with; with the "old" way, the DLL on disk would just be a list of exported functions while what was in memory would be a Linux shared object implementing those functions.

              There may well be other benefits for maintainability and/or portability too: PE is the one "constant" which is always present in Wine - it's a key part of what it is there to do, after all.
              So what does all this have to do with ALSA then? I didn't see a mention of ALSA in your post. Does the ALSA driver for Wine have something to do with the tampering for DRM and anti-cheat?
              Last edited by GraysonPeddie; 26 March 2022, 07:40 AM.

              Comment


              • #8
                Originally posted by GraysonPeddie View Post

                So what does all this have to do with ALSA then? I didn't see a mention of ALSA in your post. Does the ALSA driver for Wine have something to do with the tampering for DRM and anti-cheat?
                AFAIK, this is for eliminating dependency on 32-bit libraries for 64-bit systems.

                Comment


                • #9
                  Originally posted by uid313 View Post
                  Wine is so outdated on Debian and Ubuntu. Still version 6.0. 😥️

                  Edit: jammy-proposed is now pushing version 6.7 for the wine-development package. The ordinary "wine" package is still 6.0 though.
                  I've never used distro supplied Wine. I've always compiled it from sources - makes it faster too, considering Fedora's obsession with hardening.

                  Comment


                  • #10
                    Originally posted by GraysonPeddie View Post
                    So what does all this have to do with ALSA then? I didn't see a mention of ALSA in your post. Does the ALSA driver for Wine have something to do with the tampering for DRM and anti-cheat?
                    It's not specifically related to DRM/anti-cheat in itself; the aim is to convert all of the dummy DLLs to proper PE ones. The ALSA driver is a component of Wine, required for getting sound from Windows apps on systems using ALSA, so it's in-scope for the conversion project. It's essentially the "sound driver" as far as Windows apps are concerned, taking the place of the Realtek-ALC880-or-whatever driver that you might have on a native Windows system. (I guess there are also drivers for PulseAudio, JACK, etc. for those not using ALSA directly.)

                    There are probably other benefits too; I've not really looked into it in any great detail. If it helps the process of eliminating 32-bit dependencies as BratishkaErik mentioned, allowing 32-bit Windows apps to run on pure 64-bit systems, then that's got to be a good thing. I've got a ton of 32-bit packages installed on my system, mainly for Wine's benefit (I should probably check to see how many are actually still needed, though).

                    Comment

                    Working...
                    X