WIMBoot Explained: How Windows Can Now Fit on a Tiny 16 GB Drive

An interesting read.

http://www.howtogeek.com/196416/wimboot-explained-how-windows-can-now-fit-on-a-tiny-16-gb-drive/

John.

 

Interesting indeed, but no legacy BIOS support... pffff!

 

But 16GB... WHY!? They are already making 32GB machines and it's still too small, even WITH WIMBOOT. Seriously, at the cost of eMMC, offer 64GB minimum. It will cost the OEM's at worse a couple bucks, and users will gladly pay the $10 price bump for twice the storage.

 

When you consider the price of flash memory, say in the case of SSD the price per GB is very cheap, so why are so many tablets have 16gb or 32gb of fixed non-upgradable memory.

The should have 128gb minimum and not cost an arm and a leg, and it can be $50 to $100 to buy an 32gb version over the standard 16gb one.

John.

 

If anyone is interested in how to use it.

http://forums.mydigitallife.info/threads/52931-Windows-8-1-Update-1-WimBOOT-discussion

 

Of course Windows didn't always require this much space to start with... a decade ago you could put XP Tablet PC Edition on a 16 GB SSD (provided you could source one), and you'd have a reasonable amount of space for applications, probably a bit more than you would with 8.1 WIM. And that was bloated compared to 9x. Even with Windows 7 32-bit, a fresh install with hibernation disabled and a minimal page file was under 5 GB. Though the key is of course "fresh install". Still, I wonder how WIM would compare to 7 x86 with no hibernation and NTFS compression enabled.

It's good there's some attention being given to smaller install sizes, it just doesn't seem all that impressive either.

 

What did this guy smoke???

 

At first I was like huh as well? But after reading it a couple times, here's what I took from that paragraph, which you probably got as well. I think what he's saying is if you have the same file in two situations: 1) when larger and uncompressed and 2) when smaller and compressed, and you have the same fast-decompressing CPU in both situations paired with a slow reading drive...because the slow reading drive is reading larger data vs smaller data (regardless of the state of the data), that could potentially make WIMBoot faster with a fast CPU. What he might be over-neglecting is that 1) there's the decompression step when it comes to WIMBoot and 2) The decompression of the data by the CPU needs to be fast enough to at least offset the time it takes the slow drive to simply read the larger uncompressed data. He might also be neglecting that level of compression probably also factors in. With the speed of SSD/eMMC drives nowadays, I don't know how plausible his claim is. He says as much with his last sentence, completely negating his prior sentences. The extra step on its own would probably be enough to make WIMBoot slower in a vast majority, if not all SSD-situations today.

But I'm with HTWingNut, this might just make these OEM's more greedy with the size of already-cheap storage in devices.

 

Stupid idea. Just make eMMC and SSD's big enough and fix the root cause of the problem, the exponential ever growing WinSXS folder. I had a 7" tablet with Windows 8, Dual core Atom and a 32GB eMMC. That folder started off at 0KB and by the end of an upgrade to Win 8.1 and all the 100's of patches ended up at 3.7GB of cr@p, even after a few hours with dism. With the ever falling prcie of memory, I can see this being a very quickly passing fad (hopefully)!