Announcement

Collapse
No announcement yet.

Wine 6.20 Released With More Modules Switching To The PE Format

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

  • Wine 6.20 Released With More Modules Switching To The PE Format

    Phoronix: Wine 6.20 Released With More Modules Switching To The PE Format

    Wine 6.20 was released today as the latest bi-weekly development release of this open-source software for enjoying Windows games and applications on Linux and other platforms...

    https://www.phoronix.com/scan.php?pa...-6.20-Released

  • #2
    HID joystick is now the only supported joystick backend in DirectInput.
    Great. That's a lot more games which will be requiring the "Use xboxdrv to proxy non-XBox controllers" functionality to retrofit calibration tunables onto the HID API.

    Way to push planned obsolescence on early USB joysticks which expected Win9x's support for calibration in the control panel, guys.

    Comment


    • #3
      This better not break Microsoft Sidewinder Force Feedback 2 support, otherwise WINE is getting forked.

      Comment


      • #4
        Originally posted by ssokolow View Post

        Great. That's a lot more games which will be requiring the "Use xboxdrv to proxy non-XBox controllers" functionality to retrofit calibration tunables onto the HID API.

        Way to push planned obsolescence on early USB joysticks which expected Win9x's support for calibration in the control panel, guys.
        Im pretty sure the entire point of wine's HID joystick backend is to avoid stuff like this, isn't it?

        Comment


        • #5
          A few system libraries are bundled with the source to support PE builds.
          That part I don't understand.
          Aren't PE Builds already supported? The WINE team ports more and more libraries and programs to PE. So they can already create PE files.
          And what system libraries which are bundled with the source?
          Does it mean, that the system libraries are existing in already compiled form, which is bundled to the source code?
          And which system libraries? The core of WINE or do they adding Windows binary files?

          I don't understand the complete quote.

          Comment


          • #6
            Originally posted by theuserbl View Post

            That part I don't understand.
            Aren't PE Builds already supported? The WINE team ports more and more libraries and programs to PE. So they can already create PE files.
            And what system libraries which are bundled with the source?
            Does it mean, that the system libraries are existing in already compiled form, which is bundled to the source code?
            And which system libraries? The core of WINE or do they adding Windows binary files?

            I don't understand the complete quote.
            This has been explained a gazillion of times but let me do it again. PE libraries can be compiled by mingw and used natively by applications running in Windows. Makes Wine a little bit more universal and easier to compare with native Windows libraries in terms of behaviour/bugs/etc. Also aids running applications which actually verify libraries images on the disk, such as anticheats, DRM or copy protection solutions.

            More details here: https://www.winehq.org/announce/5.0

            *** PE modules

            - Most modules are built in PE format (Portable Executable, the
            Windows binary format) instead of ELF when the MinGW compiler is
            available. This helps various copy protection schemes that check
            that the on-disk and in-memory contents of system modules are
            identical.

            - The actual PE binaries are copied into the Wine prefix instead of
            the fake DLL files. This makes the prefix look more like a real
            Windows installation, at the cost of some extra disk space.

            - Modules that have been converted to PE can use standard wide-char C
            functions, as well as wide-char character constants like L"abc".
            This makes the code easier to read.

            - Not all modules have been converted to PE yet; this is an ongoing
            process that will continue during the Wine 5.x development series.

            - The Wine C runtime is updated to support linking to MinGW-compiled
            binaries; it is used by default instead of the MinGW runtime when
            building DLLs.
            By default, without mingw, nothing gets compiled as PE under Linux.

            Comment


            • #7
              Originally posted by Quackdoc View Post

              Im pretty sure the entire point of wine's HID joystick backend is to avoid stuff like this, isn't it?
              The old Linux /dev/input/jsX API has calibration support at the kernel API level, while everything I've searched up indicates that the /dev/input/eventX evdev/HID API assumes the device will be self-calibrating like modern gamepads or so specialized that each application which supports it will implement its own calibration in the tradition of MS-DOS sound card drivers.

              xboxdrv can be used to retrofit it by taking advantage of its x360ce equivalent to re-export new device nodes, modified by the --calibration, --deadzone, etc. options.
              Last edited by ssokolow; 22 October 2021, 09:58 PM.

              Comment


              • #8
                Originally posted by ssokolow View Post
                The old Linux /dev/input/jsX API has calibration support at the kernel API level, while everything I've searched up indicates that the /dev/input/eventX evdev/HID API assumes the device will be self-calibrating like modern gamepads or so specialized that each application which supports it will implement its own calibration in the tradition of MS-DOS sound card drivers.

                xboxdrv can be used to retrofit it by taking advantage of its x360ce equivalent to re-export new device nodes, modified by the --calibration, --deadzone, etc. options.
                https://wiki.archlinux.org/title/Gam..._API_deadzones

                This is nothing like being wrong ssokolow.
                https://www.mankier.com/1/evdev-joystick

                Turns out your generic Linux evdev for joysticks has some tuneable. In fact more tuneables than the old /dev/input/jsX use to provide. So yes a /dev/input/eventX has more adjustable options than a /dev/input/jsX . Yes this is why you can apply a old school Linux joystick configure to the jsX emulation of a evdev eventX and have the eventX also update because the jsX tuneables are stored in the generic evdev settings.

                The xboxdrv can do response curve adjustment that is something that the old linux kernel joystick interface cannot do and neither can evdev joysticks interface. Yes you use xboxdrv and other like to for when old school Linux joystick and modern evdev joystick adjustments are not up to the task. Yes some people use xboxdrv for adjustments that never required xboxdrv to be used so causing them to have extra input latency.

                ssokolow there is no particular to use /dev/input/jsX anymore. Yes you missed the set of generic calibrations on evdev/HID under Linux. Yes the fact there is a generic set of adjustments for evdev joysticks does need to get out there so people are not using the xboxdrv when they should not be.

                Of course there are some HID devices/joysticks that have internal device calibrations and those require specialist software.

                Comment


                • #9
                  Originally posted by oiaohm View Post
                  This is nothing like being wrong ssokolow.
                  From the phrasing, I get the impression you meant that as a "Ha! I win!", but all you have is my heartfelt thanks.

                  Last time I went looking, I searched and searched for something like that but both Google and DuckDuckGo were letting me down big-time. (I wonder how many years ago that was.)

                  That'll save me so much needless effort.
                  Last edited by ssokolow; 22 October 2021, 11:36 PM.

                  Comment


                  • #10
                    Originally posted by ssokolow View Post
                    From the phrasing, I get the impression you meant that as a "Ha! I win!", but all you have is my heartfelt thanks.

                    Last time I went looking, I searched and searched for something like that but both Google and DuckDuckGo were letting me down big-time. (I wonder how many years ago that was.)

                    That'll save me so much needless effort.
                    You have been wrong a few times now. Please note I have used https://wiki.archlinux.org many times on you so far when you have been wrong. Yes I normally use debian but for these odd things I use gentoo or arch wiki turns out those guys are good on documenting this stuff.

                    Please note it was not "Ha! I win!" it was darn I have to correct this person again. I was not blunt on the source I was using the last time. Hopefully this comes less common.

                    Comment

                    Working...
                    X