Folks,
We've once again made very good progress on the regressions during this code freeze period, thanks to everybody for your help!
It's now time for the final release. I've attached the tentative release notes, written with help from Jacek, Rémi and Zeb, and for the first time in Markdown format <g>. Please review these and let me know if anything is wrong, missing, or unclear.
It should probably be noted that this is not supported for 32-bit Windows applications despite Wine providing a 32-bit winscard.dll.
See https://bugs.winehq.org/show_bug.cgi?id=54661
The situation would be a lot better if at least Wine did not provide a broken 32-bit dll.
On Tue, 2024-01-16 at 18:24 +0100, Francois Gouget wrote:
It is supported for 32-bit applications but currently only in the new Wow64 setup.
On Tue, 16 Jan 2024, Hans Leidekker wrote:
And since no one will use that mode the release notes should note that this is not supported in pure 32-bit Wine and for 32-bit applications running in the default old WoW64 mode that every Linux distribution will ship.
On 17/01/2024 01:31, Francois Gouget wrote:
Not being use-able in pure 32-bit Wine sounds pretty bad, I hope it doesn't become a trend.
On Wed, 2024-01-17 at 16:17 +0200, Gabriel Ivăncescu wrote:
Arch is already offering new-style wow64 packages and macOS users have no choice.
Not being use-able in pure 32-bit Wine sounds pretty bad, I hope it doesn't become a trend.
I don't believee there are many users stuck on pure 32-bit Wine that also need winscard support. Note that it was never usable when pure 32-bit Wine was still the norm. Adding support isn't free unfortunately and I don't think that passing the tests is sufficient reason to pay that cost. I'd rather wait and see if there's real interest.
On 17/01/2024 16:57, Hans Leidekker wrote:
Yeah, I was thinking along the lines of it becoming a "trend" for other areas, which was more worrying. For winscard by itself it's not.
So Arch is shipping Wine packages with crippled 3D support?
I still see i386-unix directory in the wine package files (so I don't think Arch is doing that)
On Wed, 2024-01-17 at 13:05 -0600, Elizabeth Figura wrote:
I guess they do. They don't replace the old-style wow64 packages however. What are our options for fixing this?
I was curious about 16-bit support and found that Windows has dropped it recently. One option for Windows users to keep running these apps is a port of winevdm(!) to 64-bit Windows:
https://github.com/otya128/winevdm
I gave it a try on a new wow64 build and to my surprise it worked. I only had to add native overrides for the 16-bit system dlls.
It is.
On Wednesday, 17 January 2024 13:54:02 CST Hans Leidekker wrote:
I looked just now, and Arch's wine package [1] still uses old-style wow64 (look in "Source Files", navigate to PKGBUILD; there's no --enable-arch usage there.) There's no official package that uses new wow64. There is a wine-wow64 AUR package [2] that uses new wow64, but the AUR is basically for unvetted community packages, and Arch doesn't even provide binaries for those.
[1] https://archlinux.org/packages/multilib/x86_64/wine/ [2] https://aur.archlinux.org/packages/wine-wow64
Well, to be pedantic they *completely* dropped support for 16-bit recently (Windows 11, I think?), but it was never supported on 64-bit machines, which is the impetus for winevdm.
winevdm works by emulating segmented code. I don't know how that emulation is done or how accurate or performant it is. I would be wary of just depending on it until that's been tested. And in any case Wine doesn't need to drop 16-bit support yet.
Then anyone on old wow64 support is going to have to manually compile Wine just to get winscard support in a 32-bit application.
I do agree that we should wait for real interest before going back and fixing this case, but at the same time I too fear that this sets a dangerous precedent. I think it is a serious mistake to deprecate old wow64 until it offers at *least* the same support, and I also think we should have communicated its limitations clearly in the release notes, regardless of how obscure are the affected areas of Wine.
--Zeb
Elizabeth Figura zfigura@codeweavers.com writes:
There's nothing dangerous about it. Our philosophy has always been to only work on things that users actually need. If there are some limitations that users run into, we'll work on fixing them. If no one runs into them, it means they don't need to be fixed.
That's also why we don't wait for a new feature to be perfect before telling users to use it; because we don't need perfection, all we need is for it to address the users' needs. And the only way to know this is to have people use it and tell us what doesn't work for them.
passing
the `--enable-archs=i386,x86_64` option to configure. This is expected to
work
for most applications, but there are still some limitations, in
particular:
It's not just severely reduced performance; it also prevents us from exposing ARB_buffer_storage entirely, which in turn means we can't support 4.4 (and I know there are applications that depend on that).
Also missing are thunks for opencl, winscard, and odbc32, and capi2032. I suppose these were deemed not worth mentioning?
Specifically, the Video for Windows decoder. [IV50 support was already available through winegstreamer when using other APIs.]
many
"DirectInput"
The reduced performance also affects macOS, possibly affects all platforms.
On Tue, Jan 16, 2024 at 1:14 PM Elizabeth Figura zfigura@codeweavers.com wrote:
On Tue, 2024-01-16 at 11:51 -0600, Elizabeth Figura wrote:
Also missing are thunks for opencl, winscard, and odbc32, and capi2032. I suppose these were deemed not worth mentioning?
winscard does have wow64 thunks.
On Tuesday, 16 January 2024 14:07:46 CST Hans Leidekker wrote:
Right, sorry. I mixed it up with the opposite problem where it doesn't support old wow64.
Some Wine Mono highlights, if it's not too late:
Builtin assemblies in Wine Mono and those installed in the Windows Global Assembly Cache now take priority over assembly dll's located in the application's directory. Internal assemblies have been renamed to prevent namespace collisions with applications, for example the builtin FNA.dll is now WineMono.FNA.dll.
The PresentationFramework.Aero2 and System.Windows.Controls.Ribbon assemblies have been added.
-
Alexandre Julliard -
Dean Greer -
DodoGTA GT -
Elizabeth Figura -
Esme Povirk -
Francois Gouget -
Gabriel Ivăncescu -
Hans Leidekker