mattbee
Joined 16 years ago
Joined 16 years ago
but tl;dr is that ntvdm relied on the CPU running 16-bit code, so was naturally EOL on a 64-bit Windows, where that mode doesn't work.
winvdm adds it back via CPU emulation.
So this game still needed its bugs fixing to run in a modernised Windows, or it would have been stuck in a hardware emulator running Windows 95.
But after it was working on Windows, I tried it on Crossover and found that MacOS doesn't allow you to pin to one CPU. So it needed a racey scheduler rewriting.
There was also a difference in the way wine provides printer drivers that caused a buggy code path to run in the game, which caused a crash on the Steam Deck too.
So those bugs would have been critical even if the display implementation had worked.
The patch also adds an OpenGL window & scaling filter as the game's primary output, so it doesn't rely on GDI for pixel output any more.
The finished patch DLL ended up being a tour of the stuff that broke.
The game did launch on Windows 11 but the main issue was that the 8-bit pre-DirectDraw behaviour was broken - for 256 colour screens, Windows 11 resolvesld palette indices only once, but the game relies on being able to change the palette for fades etc. Most of the screeen ended up black, but you could see the animated parts just fine.
So most of fix ended up being to hook every draw call and implement a virtual GDI that acted like a graphics card of the day.
There was a 32-bit disc space check that overflowed, a couple of use-after-free crashes and some racey threading calls that can't have been tested on a machine with 2 CPUs.
Backwards compatibility from Microsoft was almost all there, and probably would have kept Orly running for a couple of subsequent Windows releases. But it relies on a developer meeting them half-way, it's not an emulation layer.
When a PoC drops before that timeline is up (like now!) the attackers get a head start because they have less work to do - just figure out how to use it to their payload, start spraying it out.
Meanwhile maintainers don't want release an incomplete or misunderstood fix. Otherwise they'd risk people updating and believing that they're safe when they're not. Even a fragment of misinformation from an official channel will spread like wildfire. So when you demand fixes NOW you're demanding something that may not be completely understood.
So (I'm sure we'll find out but) I believe this 2pm timeline was already as soon as is human possible for the PHP team to do a repsonsible job, and not risk us having to come back tomorrow for a fix to the fix.
LLMs gives attackers the advantage for a while, and it means we'll have to tighten the secrecy around even the rumour of a vulnerability.
After all Norton are the experts in preventing computer badness, and OpenAI can't stop blabbing about how much badness their products are causing. A match made in heaven!
Anything that randomly makes a Windows 8-style popup offer to keep my login credentials safe makes me want to run farrrrr away.
The vibe of the original criticism, even with its technical flaws was this: are passkeys - as a standard, and a user interface - vulnerable to corporate capture? I think passkey defenders are focusing far more on the theoretical technical superiority, and ignoring how instinctively alarming the average implementation is.
We face a lot a lot of attempts to capture our data, and passkey feels like a new frontier.
For me, I know exactly where I am with my password manager & TOTP. I think the current confusing interface of passkeys will make me less secure rather than more, so I've not invested the time to think about how to use them.
But do we all get that the consequences for this irresponsible behaviour are part of this test?
When there are none, they gradually normalize their naughty robot scamps running around the internet, breaking into other companies or servers run by foreign governments.
This is part of the value AI companies need to convince you of - not just that mistakes by AI products are normal, but criminal behaviour is normal, that their computer will always get a pass.
Sam Altman said yesterday "we believe that the world should accept some bad things happening for the benefits of this technology" - and this an AI company pushing the boundary, continually trying to make you accept those bad things as normal.
At any point we could choose to treat AI companies themselves as the actors behind this activity. We could enforce the laws that these hugely well-funded companies are choosing to break. Until we harm their financial viability, or threaten their executives with jail, this will keep happening.
So much is optional and easily removed. You don't even have to pay for it any more, never mind $49. For the power users that he's talking about, I don't see the issue.
(I agree the default state for Windows is completely rotten, and it shouldn't be!)
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/
https://matthewblo.ch https://bsky.app/profile/matthewblo.ch
email: matthew AT bloch DOT tv