Announcement

Collapse
No announcement yet.

Wine 5.18 Released With VKD3D 1.2's vkd3d-shader Usage

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

  • Wine 5.18 Released With VKD3D 1.2's vkd3d-shader Usage

    Phoronix: Wine 5.18 Released With VKD3D 1.2's vkd3d-shader Usage

    Wine 5.18 is out as the newest bi-weekly feature development release...

    http://www.phoronix.com/scan.php?pag...-5.18-Released

  • #2
    Wine 5.18 also converts the USER32 library to being of the portable executable (PE) format,
    What was the reason, that the WINE developers thought for a long time, that it is better, to compile the WINE libraries and programs to Linux native ELF format?
    And what is the reason, that the WINE developers in the last times, thinking, that it is better to compile it to Windows native PE format?

    Now some WINE programs and libaries can in binary form direct tested on Windows.
    But still exists the possibility to compile all in ELF format?
    For example if anybody wants only the WINElib, to "port" its program from Windows to Linux.

    Greetings
    theuserbl

    Comment


    • #3
      Probably worth mentioning that this VKD3D is NOT the one being developed by Valve for Proton.

      https://www.phoronix.com/scan.php?pa...x=VKD3D-Proton

      Comment


      • #4
        ".NET 4.0 and higher fail to install via winetricks" - finally, they fixed this extremely important thing after many weeks.

        Comment


        • #5
          Originally posted by theuserbl View Post
          What was the reason, that the WINE developers thought for a long time, that it is better, to compile the WINE libraries and programs to Linux native ELF format?
          https://wiki.winehq.org/Wine_Develop...cture_Overview
          The DLL descriptor, when the DLL is instantiated, is used to create an in-memory PE header, which will provide access to various information about the DLL, including but not limited to its entry point, its resources, its sections, its debug information...

          Except winebuild produced ELF files are not pure ELF files they have in memory generated PE headers and other things. I refer to this beast as a ELF/PE as it a hybrid of ELF and PE stuff.

          Originally posted by theuserbl View Post
          And what is the reason, that the WINE developers in the last times, thinking, that it is better to compile it to Windows native PE format?
          It useful for work in the direction of hangover https://github.com/AndreRH/hangover
          1) PE libraries cannot be link out to host native libraries directly. That helps with the hangover process to rule out the PE libraries from needing major work.
          2) Simpler cross complier using a PE complier compared to a than multi host compilers.

          Originally posted by theuserbl View Post
          Now some WINE programs and libaries can in binary form direct tested on Windows.
          This was already the case with like "wined3d on windows" and other examples.

          Originally posted by theuserbl View Post
          But still exists the possibility to compile all in ELF format?
          That is not what you think it is. Yes ELF/PE hybrid build still remains at this stage.

          Originally posted by theuserbl View Post
          For example if anybody wants only the WINElib, to "port" its program from Windows to Linux.
          WINELib port still need the wine PE loader to process the PE parts in the produced ELF files and for windows style memory structures. Winelib port is like having your feet on both sides of windows and host at the same time. Yes there can be advantages but there are a high number of disadvantages as well and a stack of creative ways to make 100 percent unique bugs.

          Winelib has it usage for making binding from windows applications to host but for porting programs turns in most cases not to be that much of advantage. Yes there are many reason why winelib ports are so rare.

          Also wine is horrible for those porting for example support graphics cards for directx are hard coded in wine so using old version of wine with new graphics cards equals trouble. So using winelib to port you application are you going to be releasing regular updates or will it be just better to be wine compatible.



          Comment


          • #6
            I understand nothing in this whole PE conversion but:

            Code:
            $ file user32*
            user32.dll.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
            user32.so:     ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
            
            $ file * | grep -v LSB
            fakedlls:                                                directory
            
            $ wine --version
            wine-5.18
            Last edited by birdie; 26 September 2020, 08:11 AM.

            Comment


            • #7
              Originally posted by theuserbl View Post
              What was the reason, that the WINE developers thought for a long time, that it is better, to compile the WINE libraries and programs to Linux native ELF format?
              Simplicity in interfacing with unix libraries.
              Originally posted by theuserbl View Post
              And what is the reason, that the WINE developers in the last times, thinking, that it is better to compile it to Windows native PE format?
              Apps with intrusive shit like anti-cheat or DRM that check if the on-disk file has same memory layout as the one mapped in memory, to name one example.
              Originally posted by theuserbl View Post
              Now some WINE programs and libaries can in binary form direct tested on Windows.
              That's not the case here. user32 relies on a unix library, but it's not part of user32.dll itself, it's a "dependency", so it satisfies those apps, who only check user32.dll itself.

              Comment


              • #8
                Originally posted by birdie View Post
                I understand nothing in this whole PE conversion but:

                Code:
                $ file user32*
                user32.dll.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
                user32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
                
                $ file * | grep -v LSB
                fakedlls: directory
                
                $ wine --version
                wine-5.18
                Sounds like you don't have mingw installed, or Wine's configure didn't pick it up.

                Comment


                • #9
                  Originally posted by Weasel View Post
                  Simplicity in interfacing with unix libraries.Apps with intrusive shit like anti-cheat or DRM that check if the on-disk file has same memory layout as the one mapped in memory, to name one example.That's not the case here. user32 relies on a unix library, but it's not part of user32.dll itself, it's a "dependency", so it satisfies those apps, who only check user32.dll itself.
                  This case no wrong idea. Current highly intrusive anti-cheat or drm applications in fact avoid using user32 mostly because of unthemed feature still in Windows 10 user32 as well as Applnit_DLLs and a few other user32 features allowing third parties to silently add extra executable code any application using user32.dll. Yes this is also why a lot of DRM and anti-cheat protected programs ship with their own kind of version user32.dll missing a few features, User32 is one of those fun Libraries that wine has to run random modified native versions of from different anti-cheat/DRM solutions.

                  The man reason for user32.dll as PE with wine is hangover requirements not anti-cheat or DRM stuff because its a rare anti-cheat that does not avoid user32.dll or replace user32.dll with own. Application functionally difference between having user32.dll.so (the hybrid) vs user32.dll the PE on a x86 system is basically nothing due to anti-cheat due to developer avoiding user32.dll to make inserting cheats and hacks into program harder, This is also why there are no bug fixes with 5.18 fixing any anti-cheat linked user32.dll coming PE fixed because does nothing in that department.

                  Weasel there are other libraries where wine changing them to PE will make anti-cheat/DRM difference user32.dll is just not one of them. I know it simple to miss that particular libraries those making anti-cheat and DRM solutions avoid or replace with own due to Microsoft design choices with those libraries that produces a list of libraries where ELF/PE hybrid or PE formated file makes no difference for items using anti-cheat and DRM.

                  For effects on applications people use with user32 the bigger change in 5.18 is "user32: Build with msvcrt" that sorts out some of the applications that hook in their own memory tracking and other things.

                  Comment


                  • #10
                    Originally posted by oiaohm View Post
                    This case no wrong idea. Current highly intrusive anti-cheat or drm applications in fact avoid using user32 mostly because of unthemed feature still in Windows 10 user32 as well as Applnit_DLLs and a few other user32 features allowing third parties to silently add extra executable code any application using user32.dll. Yes this is also why a lot of DRM and anti-cheat protected programs ship with their own kind of version user32.dll missing a few features, User32 is one of those fun Libraries that wine has to run random modified native versions of from different anti-cheat/DRM solutions.
                    I don't know of a single non-malware app that supplies its own user32, because it's not a redistributable, so it's illegal to begin with. Not to mention too low level and can break between Windows versions. Please just stop.

                    Also, you realize Wine's own drivers interact with user32 in its own way, right? In fact Wine's user32 has extra exports just for drivers (like the X11 driver) to interact with. There's no way in hell a native user32 would ever work on Wine.

                    Also "user32: Build with msvcrt" just means it was built as PE, but you wouldn't even know that (it adds the -mno-cygwin option, which is what it does, see wine's tools source).

                    So you're clueless like always.

                    Comment

                    Working...
                    X