Live data from Hacker News

Valve reveals it’s the architect behind a push to bring Windows games to Arm

theverge.com

71–80 of 876 posts

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#71

Earlier quoted context omitted.

These things do not prevent cheating at all. They are merely a remote control system that they can send instructions to look for known cheats. Cheating still exists and will always exist in online games. You can be clever and build a random memory allocator. You can get clever and watch for frozen struct members after a known set operation, what you can’t do is prevent all cheating. There’s device layer, driver layer…

Cheating still exists and will always exist in online games. Sure, but you still have to make a serious attempt or the experience will be terrible for any non-cheaters. Or you just make your game bad enough that no one cares. That's an option too.

Other options exist but it’s not an option for these real-time games like FPS’s. I get it.

If you don’t need real-time packets and can deal with the old school architecture of pulses, there’s things you can do on the network to ensure security.

You do this too on real-time UDP it’s just a bit trickier. Prediction and analysis pattern discovery is really the only options thus far.

But I could be blowing smoke and know nothing about the layers of kernel integration these malware have developed.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#72

Would love to see it on MacOS X -- Steam works great on my Mac Mini for the games it supports, would be great to see everything run on it.

Are you expecting to run Windows 11 ARM version on your Mac Mini directly, or within Parallels?

Apple Silicon has no UEFI support except as provided by Asahi, so that would be needed at a minimum to boot Windows 11 natively. Then there's the whole issue of having native Windows drivers for the Apple Silicon-specific hardware.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#73
post #19
post #11

> and modern multiplayer games with anti-cheat simply do not work through a translation layer, something Valve hopes will change in the future. Although this is true for most games it is worth noting that it isn't universally true. Usermode anti-cheat does sometimes work verbatim in Wine, and some anti-cheat software has Proton support, though not all developers elect to enable it.

It works in the sense it allows you to run the game; but it does not prevent cheating. Obviously, Window's kernel anti-cheet is also only partially effective anyway, but the point of open-source is to give you control which includes cheating if you want to. Linux's profiling is just too good; full well documented sources for all libraries and kernel, even the graphics are running through easier to understand translat…

Anti-cheat is a misnomer; it's much more about detecting cheats more than it is preventing them. For people who are familiar with how modern anti-cheat systems work, actually cheating is really the easy part; trying to remain undetected is the challenge.

Because of that, usermode anti-cheat is definitely far from useless in Wine; it can still function insofar as it tries to monitor the process space of the game itself. It can't really do a ton to ensure the integrity of Wine directly, but usermode anti-cheat running on Windows can't do much to ensure the integrity of Windows directly either, without going the route of requiring attestation. In fact, for the latest anti-cheat software I've ever attempted to mess with, which to be fair was circa 2016, it is still possible to work around anti-cheat mechanisms by detouring the Windows API calls themselves, to the extent that you can. (If you be somewhat clever it can be pretty useful, and has the bonus of being much harder to detect obviously.)

The limitation is obviously that inside Wine you can't see most Linux resources directly using the same APIs, so you can't go and try to find cheat software directly. But let's be honest, that approach isn't really terribly relevant anymore since it is a horribly fragile and limited way to detect cheats.

For more invasive anti-cheat software, well. We'll see. But just because Windows is closed source hasn't stopped people from patching Windows itself or writing their own kernel drivers. If that really was a significant barrier, Secure Boot and TPM-based attestation wouldn't be on the radar for anti-cheat vendors. Valve however doesn't seem keen to support this approach at all on its hardware, and if that forces anti-cheat vendors to go another way it is probably all the better. I think the secure boot approach has a limited shelf life anyways.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#74
post #65
post #45

Earlier quoted context omitted.

RISC-V the ISA is open; RISC-V implementations need not be. There's no reason to believe that any truly high-performance implementations will be usefully open.

There are also many high-performance Chinese implementations that are open-source (e.g., XuanTie C910, XiangShan, etc.). While achieving an open-core design comparable to Zen 5 is unlikely in the near term, a sustained open-source collaborative effort could, in the long run, significantly change the situation. For example, current versions of XiangShan are targeting ~20 SPECint 2006/GHz (early where at ~9).

Yeah, but then the US doesn't get to spy on you anymore ;)

Stuff tends to stay open until a new leader emerges. Then the closed source shell appears.

We've seen this with the hyperscalers and in a million other places.

Use open to pressure and weed out incumbents and market leaders. Then you're free to do whatever.

So we'd be replacing NSA spying with MSS spying.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#75
post #29
post #21

Earlier quoted context omitted.

It may have taken them a while, but it does now work fine.

Define 'fine'

You don't notice you're on ARM at all. Everything "Just Works."

And you're seeing 20+ hours battery under normal workloads (i.e. not spec sheet "20 hours" but day-to-day). I've been mainlining a Windows ARM laptop for six months, and am yet to run into anything I couldn't do.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#76

Would love to see it on MacOS X -- Steam works great on my Mac Mini for the games it supports, would be great to see everything run on it.

The last time I can remember a collaboration between Valve and Apple was for the SteamVR support on macOS back in 2016. Sadly it fell apart a year(-ish) after that. But… one can dream!

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#77

I thought for a moment from the title that Valve has finally started funding game developers to make content from SteamOS, but no, this is just another case where Valve pays some contractors for open source projects and force developers to foot the bill for verifying compatibility.

> force developers to foot the bill for verifying compatibility How are they forcing developers? If developers don't think it's worth it to make their game compatible with Steam Deck, can't they just avoid doing that?

They are forcing developers to be the one to pay for it if they do it because there is no other player in the space that would financially benefit from games having SteamOS support. Practically every other company with an game platform, Playstation, Xbox, Nintendo, iOS, Android, etc have programs to fund bringing content to their platform. Also developers can't avoid supporting SteamOS because there is no way for them to 100% opt out of being on that platform.

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#78
post #52

Does anyone know what the limfac is? The machine code produced is of course different on different CPU arches, but isn't this handled at the compiler level? I.e. lower level than game devs worry about. The exception I see is if SIMD intrinsics.

This system allows playing unmodified production x86 executables on arm64. It doesn’t have anything to do with the developers.

That's great, but begs the question: why not just compile the games for ARM?

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#79

Earlier quoted context omitted.

> force developers to foot the bill for verifying compatibility How are they forcing developers? If developers don't think it's worth it to make their game compatible with Steam Deck, can't they just avoid doing that?

They are forcing developers to be the one to pay for it if they do it because there is no other player in the space that would financially benefit from games having SteamOS support. Practically every other company with an game platform, Playstation, Xbox, Nintendo, iOS, Android, etc have programs to fund bringing content to their platform. Also developers can't avoid supporting SteamOS because there is no way for the…

> Practically every other company with an application platform, Playstation, Xbox, Nintendo, iOS, Android, etc have programs to fund bringing content to their platform.

the only platforms I've ever heard of this for were Windows Phone and the Epic Store

both of which were runaway commercial successes

Re: Valve reveals it’s the architect behind a push to bring Windows games to Arm

#80

Would love to see it on MacOS X -- Steam works great on my Mac Mini for the games it supports, would be great to see everything run on it.

I wonder if Apple's GPT (Game Porting Toolkit) could added to the macOS Steam client as a compatibility tool, like Proton is in the Linux client.
Post reply on HN