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

[oiaohm]

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

I said how.

https://people.collabora.com/~vivek/libcapsule.pdf

https://gitlab.collabora.com/vivek/libcapsule

Is a tool set.

The plugin a .so right weasel. So you make a shim library as valve does in their libcapsule work. The requirement from valve was no recompilation of the game or the platform libraries. Shim libraries in the middle was allowed.

Not sure if you can use LD_PRELOAD to hack it and replace normal dlopen

LD_PRELOAD hack is not dependable. The dependable is a shim .so file.

Yes shim/capsule
application->library.so comes application->shim/capsule library.so->library.so

This is a workaround dealing with application and a library that you cannot modify..

Now if you don't have the recompilation limitation you do what google chrome does and uses dlmopen on their plugins so removing the need for shim.so.

shim or capsule library name problem. Yes depending on the party some call it a shim others call the solution capsule result is the same thing. Yes depending on the collabora person writing the documentation at the time as well(not exactly fun if you don't remember they are the same thing). Use dlmopen in a library between the application and it so library that will not work due to some confliting dependancy fixing problem.

Shim setup is in fact mentioned

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

On page 9 of the above PDF.

https://gitlab.collabora.com/vivek/libcapsule/-/blob/master/doc/Capsules.txt?ref_type=heads

Libcapsule has all the fancy stuff for intercepting dlopen calls. So that the library wrapped by shim can still in fact use dlopen itself. Yes libcapsule is used by valve and is really well tested.

Weasel so recompile library or application not required to make incompatible library work with each other. Either application is design to use dlmopen to prevent issues like chrome or if it not design you use capsule/shim library like value does on their decades odd linux game executable so they work with modern libraries.

https://gitlab.collabora.com/vivek/libcapsule/-/blob/master/doc/Limitations.txt?ref_type=heads

The first limitation applies under Windows as well.

This is one of those annoying things. The global symbol thing of ELF prevents limitation 1 by only allowing 1 symbol. You are using a shim/capsules you do need to think about what you are doing.

This shim/capsule route does allow placing man in middle code for particular operations to copy data from one type of allocated memory to another so addressing part of the first limitation.

Yes the best way to avoid limitation 1 under Windows and Linux is do what gimp/pcsx2 does run plugins as their own programs. Of course this runs you into the Wayland problem of not having the neatest way to manage multi application windows attempting to act as one without using a proxy Wayland compositor.

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

https://support.microsoft.com/en-us/windows/devices-not-working-after-a-major-windows-update-a15667e6-baa1-4437-80aa-a77f08b3aaff

Major updates are kernel updates. Microsoft directly tells you that drivers may fail because they do.

Never heard of it is the works for me argument not the facts Weasel. The facts kernel updates on Windows and Linux drivers do stop working. Windows updates kernel less often than Linux does resulting in less driver breakage that is difference.

PS also note the dlopen not working inside standard glibc dlmopen is a glibc limitation that the solaris loader does not have. Lot of libcapsule code is required because glibc suxs.

[castlefox]

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

You seem to be deep into WINE release candidate testing. How easy/difficult is it to get started with reporting bugs and stuff in wine?

[kiffmet]

What's the current state of WINE's VKD3D?

[varikonniemi]

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.

Nice to know, but what i say still stands. As long as kernels prior to 5.18 are current and supported.

[varikonniemi]

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.

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

Shitty software, abandoned software, that has not updated their plugin to keep up with the shitty backwards-incompatible toolkit they decided to use.

[oiaohm]

Shitty software, abandoned software, that has not updated their plugin to keep up with the shitty backwards-incompatible toolkit they decided to use.

https://github.com/osxmidi/LinVst

Daw software is very common to be using really old plugins for different special effects. It also very common to have bridge software to deal with Weasel problem of miss matched toolkits.

Reality here you run into the problem under windows where VST plugin and the application have different MS C++ libraries and goes and decallocates the the wrong memory causing screw up. So bridge software is a must because library compadiblity issues turn up.

Bridge software is kind of more savage than using dlopen. Bridge software you run the plugin in a different process and use a socket file to connect to a proxy plugin. So plugin and daw end up running in different processors.

The reality here is the daw/DSP plugin example Weasel used is kind of a joke.

https://totomusic.github.io/TBridge/indexEn.html

Yes daw you run into 32 bit binaries need in 64 bit executable as well. So bridges. Yes bridge 64 bit to 64 bit fixes I am using incompatible graphical toolkit problem or I am using incompatible C++ runtime or I have a 32 bit plugin and 64 bit daw problem.

The reality is there is no such thing as a 100 percent clean plugin design that runs in the applications memory reason why bridges exist.

You have linux native daw that for plugins use dlmopen and they have bridges. Of course there is still the option of capsule library for the legacy ones that did not come with dlmopen support.

[cj.wijtmans]

I couldn't care less about the wayland enablement. What I want is a working port of wine to OpenBSD. It used to work in the stone age back in 3.x or 4.x releases. But hasn't for a long long long time. There are some emulators and games that keep me from going OpenBSD only and this would go a long way towards fixing that.

I was excited a couple years ago with Wine 7.x because they were doing something called PE to let 32bit binaries run on 64bit systems, which is critical because OpenBSD is like Slackware in that it is pure 64bit with no libraries to run 32bit software like in Debian or even FreeBSD.

A google summer of code project covered by Michael on here awhile back they got 32bit wine working in 64bit NetBSD so I just assumed that OpenBSD would fall into place soon, but that has not happened yet.

why not just install a steamOS VM and be done with it?

[SophTherapy]

Dear Linux fans. You need to establish a coherent narrative.

Once you write that Wine runs everything so wonderfully that widnows is unnecessary.

And once like you. And seeing by the pluses many agree with you.

And not so long ago I was convinced here that there is Wine, then why do I need Windows.

You change your mind like an emotionally unstable maiden - what you write can not be taken seriously.

Hello everybody,

I would like to apologize for my posts under nickname "sophisticles" and "hel88".

the thing is, I am very sick person. Schizophrenia with manic depression.
When I'm on my medication like now, I feel ashamed for the things that I do when not on medication.

For example, when I'm not using my therapy properly I get this crazy tendency to troll on linux forums. For that devious purpose I am using nicknames "sophisticles" and "hel88". under those nicknames I write crazy, insane things. when I am on regular therapy like now, I cannot believe the crap that I wrote under those 2 nicknames.

overall, I would like all of you to know that I don't really mean what I write under those 2 nicknames and also, I love linux, open source and gpl. and yes, microsoft sucks.