Curiously, the junk hardware probably prevented quite a bit of data loss. By being such a terrible experience within Windows, it was vanishingly unlikely that you’d be doing any heavy lifting within Windows. And even more unlikely that you might, say, have multiple programs writing to critical user files in flight when the suspend happened. Combine that with the terrible screen that makes any significant work painful, and it really becomes a weird saving grace.
A more capable system may well have fared much worse.
Honestly, this is exactly what I would expect from a BIOS company. I used to work at a hardware company and there the solution to everything was always “let’s just add a separate core for that”. It’s kind of “if you only have a hammer everything looks like a nail” but different because the nail is so complicated. If you are a carpenter and somebody wants a house you’re going to build a wooden house…
I don’t understand what’s cursed about how they switch OSs on sleep. What could go so very wrong with it?
The filesystem sharing does sound quite cursed and fragile. I imagine they used a journal rather than direct access in-part so that windows would be notified that the files were changing so it could update any internal filesystem state and potentially also pass notifications to any listening apps.
Testament to someone’s ego that any products launched with “fast booting” OSs that weren’t actually fast.
I don’t understand what’s cursed about how they switch OSs on sleep. What could go so very wrong with it?
At least fifteen years ago, the OS going to sleep assumed it’d be the next thing awake, and those assumptions are coded into things like open filehandles and such being saved and then restored. You’re basically right about the journal being used to let Windows keep up to date on any file state changes, but I think a lot of engineers wouldn’t want to get to the point where they need that.
I had a coworker that got in the habit of (some sequence of) hibernating Linux in a VM, hibernating Windows, un-hibernating Linux on the host, and then un-hibernating Windows in a VM. It all came crashing down when something got shut down out of sequence, and the un-hibernated thing still assumed stuff on disk was laid out in the expected way and it completely trashed the filesystem.
Yeah, mounting the filesystem read/write on two OSs is obviously a problem. I just don’t see why the other idea is bad. I guess even if you don’t edit any data outside your partitioned disk and memory space then you’re still going to be changing state in the hardware devices that might confuse drivers?
The journal file made me laugh! It felt like malicious compliance between engineers and higher ups, a brittle hack that technically did what was asked, here’s your curling monkey paw, sir
I’, surprised they needed the mini port thing for the hypervisor version. You could run Windows on Xen with GPU drivers in 2007, though it required some exciting hackers to ensure that the device was mapped at the location that the OS expected it. You couldn’t share the GPU between VMs, but you wouldn’t want the low-power OS to use it.
I’d written an explanation of how I’d implement the file sharing before I got that far in the article, but it turns out that irks the same thing that they did, so no point posting it. That said, if anyone wants to overturn the patent then I’d be happy to claim as an expert witness that it’s obvious to so someone versed in the art. If I understand correctly, it isn’t a problem that NTFS write support was bad in Linux because the Linux side just reads from the NTFS layer and writes to the log-structured filesystem, the Windows driver merges the changes at a higher layer in the driver stack and pushes the rights through the normal NTFS drivers.
That was wild. I remember the marketing for the thing with a parallel ARM processor running Linux. I think it’s kind of a shame it never went anywhere, it would be kinda cool to be able to run simultaneous OS in multiple processors/cores.
At least one variant of Dell’s “Latitude ON,” (briefly mentioned in the article) did use a dedicated Arm SoC. I worked at a company that once bought a Latitude notebook that came with it. Nobody used it — the head of IT who purchased it didn’t even know about it. But it was really fascinating.
The main motherboard in the laptop had a small auxiliary board that looked (and functioned, I suppose) very much like a Raspberry Pi Compute Module. It used the battery and the screen and keyboard and touchpad, but probably save for a few microcontrollers the entire x86 side of things didn’t even have power.
The little SoC board even had its own WiFi NIC. There was another little PCB that just had a handful of those tiny surface mount antenna connectors and some passive components. I’m not sure how it worked, or what it did — it probably was there for impedance matching or something, but I don’t know enough about radio to be sure.
It’s definitely of very limited use, but I can’t even imagine how much went into the engineering budget there.
I remember playing around with one of these a friend had picked up and going through several stages of denial, then finally concluding they must have pulled some hardware level stunt. I saw the memory allocation and my guess at the time was they had a SoC to run the instant-on OS and just used a hardware KVM switch to toggle them. I was right about the sleep + hardware hardware malarkey but didn’t realize how deep the rabbit hole actually went. Wow.
Interesting bit of PC history but the the writing style of this post was obnoxious and full of unfunny jokes. It also didn’t have to be like 5-6 pages long. The entire substance of the post could have been done in 100 words.
Save yourself some time, they used BIOS hooks on S3 sleep to transparently and quickly swap between two OSes. This mostly works except for sharing file systems.
I was skeptical when I saw:
but that was exactly correct. Wow, what a ride.
Curiously, the junk hardware probably prevented quite a bit of data loss. By being such a terrible experience within Windows, it was vanishingly unlikely that you’d be doing any heavy lifting within Windows. And even more unlikely that you might, say, have multiple programs writing to critical user files in flight when the suspend happened. Combine that with the terrible screen that makes any significant work painful, and it really becomes a weird saving grace.
A more capable system may well have fared much worse.
What a fun read.
Honestly, this is exactly what I would expect from a BIOS company. I used to work at a hardware company and there the solution to everything was always “let’s just add a separate core for that”. It’s kind of “if you only have a hammer everything looks like a nail” but different because the nail is so complicated. If you are a carpenter and somebody wants a house you’re going to build a wooden house…
I live in the US where I do live in wooden houses. Might not be quite the point you wanted to make!
Indeed. There are specialized framing hammers designed for the fast and efficient nailing of wooden frames.
Oh, I am not hating on wooden houses, they’re great but there are different ways to build houses. ;)
I don’t understand what’s cursed about how they switch OSs on sleep. What could go so very wrong with it?
The filesystem sharing does sound quite cursed and fragile. I imagine they used a journal rather than direct access in-part so that windows would be notified that the files were changing so it could update any internal filesystem state and potentially also pass notifications to any listening apps.
Testament to someone’s ego that any products launched with “fast booting” OSs that weren’t actually fast.
At least fifteen years ago, the OS going to sleep assumed it’d be the next thing awake, and those assumptions are coded into things like open filehandles and such being saved and then restored. You’re basically right about the journal being used to let Windows keep up to date on any file state changes, but I think a lot of engineers wouldn’t want to get to the point where they need that.
I had a coworker that got in the habit of (some sequence of) hibernating Linux in a VM, hibernating Windows, un-hibernating Linux on the host, and then un-hibernating Windows in a VM. It all came crashing down when something got shut down out of sequence, and the un-hibernated thing still assumed stuff on disk was laid out in the expected way and it completely trashed the filesystem.
Yeah, mounting the filesystem read/write on two OSs is obviously a problem. I just don’t see why the other idea is bad. I guess even if you don’t edit any data outside your partitioned disk and memory space then you’re still going to be changing state in the hardware devices that might confuse drivers?
The journal file made me laugh! It felt like malicious compliance between engineers and higher ups, a brittle hack that technically did what was asked, here’s your curling monkey paw, sir
this post was SO insane and worth the read. one of the best things i’ve read in recent memory, i’m stunned
what an insane hack. a perfect encapsulation of the total insanity of the late 2000s tech era
I’, surprised they needed the mini port thing for the hypervisor version. You could run Windows on Xen with GPU drivers in 2007, though it required some exciting hackers to ensure that the device was mapped at the location that the OS expected it. You couldn’t share the GPU between VMs, but you wouldn’t want the low-power OS to use it.
I’d written an explanation of how I’d implement the file sharing before I got that far in the article, but it turns out that irks the same thing that they did, so no point posting it. That said, if anyone wants to overturn the patent then I’d be happy to claim as an expert witness that it’s obvious to so someone versed in the art. If I understand correctly, it isn’t a problem that NTFS write support was bad in Linux because the Linux side just reads from the NTFS layer and writes to the log-structured filesystem, the Windows driver merges the changes at a higher layer in the driver stack and pushes the rights through the normal NTFS drivers.
That was wild. I remember the marketing for the thing with a parallel ARM processor running Linux. I think it’s kind of a shame it never went anywhere, it would be kinda cool to be able to run simultaneous OS in multiple processors/cores.
At least one variant of Dell’s “Latitude ON,” (briefly mentioned in the article) did use a dedicated Arm SoC. I worked at a company that once bought a Latitude notebook that came with it. Nobody used it — the head of IT who purchased it didn’t even know about it. But it was really fascinating.
The main motherboard in the laptop had a small auxiliary board that looked (and functioned, I suppose) very much like a Raspberry Pi Compute Module. It used the battery and the screen and keyboard and touchpad, but probably save for a few microcontrollers the entire x86 side of things didn’t even have power.
The little SoC board even had its own WiFi NIC. There was another little PCB that just had a handful of those tiny surface mount antenna connectors and some passive components. I’m not sure how it worked, or what it did — it probably was there for impedance matching or something, but I don’t know enough about radio to be sure.
It’s definitely of very limited use, but I can’t even imagine how much went into the engineering budget there.
I remember playing around with one of these a friend had picked up and going through several stages of denial, then finally concluding they must have pulled some hardware level stunt. I saw the memory allocation and my guess at the time was they had a SoC to run the instant-on OS and just used a hardware KVM switch to toggle them. I was right about the sleep + hardware hardware malarkey but didn’t realize how deep the rabbit hole actually went. Wow.
Interesting bit of PC history but the the writing style of this post was obnoxious and full of unfunny jokes. It also didn’t have to be like 5-6 pages long. The entire substance of the post could have been done in 100 words.
Save yourself some time, they used BIOS hooks on S3 sleep to transparently and quickly swap between two OSes. This mostly works except for sharing file systems.
The genre is “police procedural”, not “mystery”.