Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

theverge.com

Post reply on HN
Print view View original

181–190 of 876 posts

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

#181

Post by fulafel »

the__alchemist wrote: post #78
jitl wrote: post #52

Earlier quoted context omitted.

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?

Think back to the x86 32->64 bit transition, but much worse, since ARM is more niche and there are more arch differences.

You need all your 85 3rd party middlewares and dependencies (and transitive dependencies) to support the new architecture. The last 10% of which is going to be especially painful. And your platform native APIs. And your compilers. And you want to keep the codebase still working for the mainstream architecture so you add lots of new configuration combos / alternative code paths everywhere, and multiply your testing burden. And you will get mystery bugs which are hard to attribute to any single change since getting the game to run at all already required a zillion different changes around the codebase. And probably other stuff I didn't think of.

So that's for one game. Now convince everyone who has published a game on Steam to take on such a project, nearly all of whom have ages ago moved on and probably don't have the original programmers on staff anymore. Of course it should also be profitable for the developer and publisher in each case (and more profitable & interesting than whatever else they could be doing with their time).

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

#182

Post by [deleted] »

Xss3 wrote: post #126
jchw wrote: post #73

Earlier quoted context omitted.

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 itsel…

Anticheat devs could REALLY benefit by having some data scientists involved. Any player responding to ingame events (enemy appeared) with sub 80ms reaction times consistently should be an automatic ban. Is it ever? No. Given good enough data a good team of data scientists would be able to make a great set of rules using statistical analysis that effectively ban anyone playing at a level beyond human. In the chess of…

[deleted]

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

#183

Post by concinds »

galleywest200 wrote: post #161
concinds wrote: post #155

Earlier quoted context omitted.

Apple leadership cares more about "games on the Mac App Store built for Metal on a Mac" than it cares about "games on the Mac". This won't change until leadership changes.

It does not matter what Apple wants if Steam ships their own compatibility layer.

Valve is all-in on Linux and their own hardware. They have no reason to invest tons into a platform with an uncooperative vendor who culturally DGAF about gaming. Why run from Windows only to jump into a more hostile ecosystem? You can still run 32-bit x86 games on Windows ARM, you know.

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

#184

Post by coldpie »

hamdingers wrote: post #178
jamie_ca wrote: post #50

Earlier quoted context omitted.

Are you looking for Crossover? It's a bit annoying to not run Steam natively (no cmd+H to hide, etc) but it's got a lot of support. Performance is decent on my M2 mini, and even cross-platform stuff like Baldurs Gate 3 is comparable performance to native. Especially anything that Mac Steam natively calls out lack of 32bit support has good support.

CodeWeavers, the developers of Crossover, also do most of the development on proton under contract for Valve. This is speculation but I suspect there's something in that contract that prevents Valve from competing with Crossover on MacOS.

Nah, nothing like that. We explored shipping Proton for macOS early on, but decided it wasn't where we wanted to spend our time, so we removed it[1] to focus on Linux. There's only so many hours in the day, and supporting two platforms is a lot more work than one.

[1] https://github.com/ValveSoftware/Proton/commit/a84120449d817...

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

#185

Post by willis936 »

PaulHoule wrote: post #2

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.

Valve employed Alyssa Rosenzweig while she developed the graphics stack for asahi linux. That's a very simple statement that masks the size of the achievement and its impact on the world. No, we haven't entered a golden era of gaming on macs, but the world has been shown the way. And no, the software challenges are not insurmountable.

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

#186

Post by jmkni »

Marsymars wrote: post #69
jmkni wrote: post #29

Earlier quoted context omitted.

Define 'fine'

I run WoA on my daily work laptop and everything I run other than some of the junky IT-pushed apps (outlook extension to report phishing, etc.) are ARM64-native and run as expected.

That's good to hear, I remember that "holy shit" moment when I first moved to an Apple Silicon mac, I guess Microsoft are getting there but in a more hap-hazard "we'll make eventually" sort of way

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

#187

Post by [deleted] »

Xss3 wrote: post #126
jchw wrote: post #73

Earlier quoted context omitted.

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 itsel…

Anticheat devs could REALLY benefit by having some data scientists involved. Any player responding to ingame events (enemy appeared) with sub 80ms reaction times consistently should be an automatic ban. Is it ever? No. Given good enough data a good team of data scientists would be able to make a great set of rules using statistical analysis that effectively ban anyone playing at a level beyond human. In the chess of…

[deleted]

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

#190

Post by kbolino »

kouteiheika wrote: post #115
buildbot wrote: post #102

Earlier quoted context omitted.

Speaking of Anti-Cheat and secure boot, you need SB for Battlefield 6. The game won't start without it. So it's happening! I don't hate the lack of cheating compared to older Battlefield games if I am going to be honest.

> Speaking of Anti-Cheat and secure boot, you need SB for Battlefield 6. The game won't start without it. So it's happening! I'm curious, does anyone know how exactly they check for this? How was it actually made unspoofable?

Disclaimer: This is only an educated guess based upon public info. Also, it's impossible to make something truly unspoofable, but it isn't that hard to raise the bar for spoofing pretty high.

There are two additional concepts built upon the TPM and Secure Boot that matter here, known as Trusted Boot [1,2] and Remote Attestation [2].

Importantly, every TPM has an Endorsement Key (EK) built into it, which is really an asymmetric keypair, and the private key cannot be extracted through any normal means. The EK is accompanied by a certificate, which is signed by the hardware manufacturer and identifies the TPM model. The major manufacturers publish their certificate authorities [3].

So you can get the TPM to digitally sign a difficult-to-forge, time-stamped statement using its EK. Providing this statement along with the TPM's EK certificate on demand attests to a remote party that the system currently has a valid TPM and that the boot process wasn't tampered with.

Common spoofing techniques get defeated in various ways:

- Stale attestations will fail a simple timestamp check

- Forged attestations will have invalid signatures

- A fake TPM will not have a valid EK certificate, or its EK certificate will be self-signed, or its EK certificate will not have a widely recognized issuer

- Trusted Boot will generally expose the presence of obvious defeat mechanisms like virtualization and unsigned drivers

- DMA attacks can be thwarted by an IOMMU, the existence/lack of which can be exposed through Trusted Boot data as well

- If someone manages to extract an EK but shares it online, it will be obvious when it gets reused by multiple users

- If someone finds a vulnerability in a TPM model and shares it online, the model can be blacklisted

Even so, I can still think of an avenue of attack, which is to proxy RA requests to a different, uncompromised system's TPM. The tricky parts are figuring out how to intercept these requests on the compromised system, how to obtain them from the uncompromised system without running any suspicious software, and knowing what other details to spoof that might be obtained through other means but which would contradict the TPM's statement.

[1]: https://learn.microsoft.com/en-us/windows/security/operating...

[2]: https://docs.system-transparency.org/st-1.3.0/docs/selected-...

[3]: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Endors...

Post reply on HN