Wine 8.21 (Dev) – Run Windows Applications on Linux, BSD, Solaris and macOS | Hacker News Reader

Wine 8.21 (Dev) – Run Windows Applications on Linux, BSD, Solaris and macOS

winehq.org

16 pointsneustradamus8 comments

>Beginnings of support for ARM64EC target.

I'm so ready for this.

Windows has a compatibility layer for x64 applications on ARM. If Wine can utilize this it'll be a game changer.

IMO I don't think x64 is a good mobile platform. I'm waiting for a ARM Steam Deck that has something like Rosetta built in.

What? AMD has the Z1 extreme that pulls something like 17 watts and can pull a GeForce 1650 level of graphics and decent CPU performance in a device the same size.

I was reading somewhere that zen4c may beat arm at power efficiency but time will tell when the laptops chips drop.

I do think it's cool having another CPU architecture out there everyone supports. I really want to see some decent open RISC V stuff gain more support but I fear that won't be for a few years.

> I'm waiting for a ARM Steam Deck that has something like Rosetta built in.

This would solve nothing, besides maybe a better chip design, but you're bringing back the same ISA, and you'd have to bend over backwards with your new fancy architecture to painstakingly truly support old software.

> Windows has a compatibility layer for x64 applications on ARM

It's the WoW layer, there's also Arm64X and I think a x86 mode (see Arm64EC documentation?).

I'm thinking battery life and heat.

The SteamDeck is also a giant device compared to a Switch.

A ton of progress has been made with Box64, I imagine a corporate effort would yield even better results.

> I'm thinking battery life and heat.

The problem is, I'm not sure how it'd help, when you have to do emulation. It often requires explicit hardware support (or some system level support) to break ABI to not manually do mappings and stuff, to make emulation as little overhead as possible. Make sure you caught that, "as little overhead as possible", I am not good at hardware whatsoever but to me there's no reason that an alternative chip would be any better than the original chip being emulated, when you have the same ISA being ran....... UNLESS there is some recompilation. This is why I'm a fan of JITs and their little VMs, you can do your own JIT compiler for VMs and implement your own optimizations, the same way you'd, say, implement fast-paths in a JS JIT compiler.

I might be out of my ballpark, but what about Rosetta ?

As far as I can tell you still get a battery life increase even when running x86 apps.

I heard that apparently the M-series chips have some dedicated hardware for emulation, I may be wrong however. Not sure though how it's powered, and how it does the emulation itself afterwards. It very well could improve battery life if it does more than blind emulation. For the opposite end, look at QEMU (kind of an unfair comparison since Rosetta seems to be more like an userspace emulator, whereas QEMU handles a ton of devices and more)

For those like me wonder WTF ARM64EC is:

"ARM64EC is a new application binary interface (ABI) for Windows 11 on ARM that runs with native speed and is interoperable with x64. An app, process, or even a module can freely mix and match ARM64EC and x64 as needed. The ARM64EC code in the app will run natively while any x64 code will run using Windows 11 on ARM’s built-in emulation.

The ARM64EC ABI differs slightly from the existing ARM64 ABI in ways that make it binary compatible with x64 code. Specifically, the ARM64EC ABI follows x64 software conventions including calling convention, stack usage, and data alignment, making ARM64EC and x64 interoperable. Apps built as ARM64EC may contain x64 code but do not have to, since ARM64EC is its own complete, first-class ABI for Windows."[0]

[0] https://blogs.windows.com/windowsdeveloper/2021/06/28/announ...

Reply on news.ycombinator.com