Why Does Microsoft Still Offer a 32-bit OS?
backblaze.com
backblaze.com
> The main gigantic upside of a 64-bit process is the ability to support more than 2 GBytes of RAM ... Since only 1.6% of Backblaze customers have 2 GBytes or less of RAM, the other 98.4% desperately need 64-bit support, period, end of story.
This would only be true if all those Backblaze customers were only running one process on their machines. With PAE, A 32-bit system can support more than 2 GB, just not a 32-bit process. And actually, there are workarounds available to enable even that.
> And remember, there is no downside.
There is a downside. 64-bit systems consume more RAM since every pointer and word is double the size. This could mean a performance penalty due to more swapping too.
> Because there is zero downside, the first time it could, Apple shipped with 64-bit OS support.
No, Apple did this because they are in control of the hardware their OS runs on, so they can ensure that everyone is supported. Microsoft don't have that luxury. Even then, Apple was still building for 32-bit just 5 years ago. They also weren't first to support it as the author seems to imply -- 64-bit Windows XP was available before OSX even ran on Intel CPUs.
> There are a variety of security features such as ASLR (Address Space Layout Randomization) that work best in 64-bits. The 32-bit version is inherently less secure.
Yeah, in the sense that it's easier to guess a 32-bit long number than a 64-bit long number. It's still unfathomable.
> Supporting both versions is complicated. The more data our customers have, the more momentarily RAM intensive some functions (like inheriting backup state) can be. The more data you have the bigger the problem. Backblaze customers who accidentally chose to disable 64-bit operations are then going to have problems.
Has Backblaze honestly ever had this problem, where 2GB of RAM was not enough to reliably find a customer's backup state? That seems ridiculous to me.
At least under the consumer versions of Windows PAE is only supported for up to 4 GB of RAM - partly because of company policy and partly because some drivers turned out to be unstable when physical addresses above 4 GB are used (source: https://en.wikipedia.org/w/index.php?title=Physical_Address_...).
... for the consumer versions of Windows. The server versions of 32 bit Windows support more.
I'm the author of the article and wrote the Backblaze Windows desktop client.
The problem isn't "finding" the customer's backup state, it IS the customer backup state. The "backup state" is a list of every filename that is backed up, with the size of the file, a SHA-1 of the file, and the location of that file in the Backblaze datacenter.
This is a bit over simplified, but while your computer is backing up, as a new file is transmitted from your laptop to the Backblaze datacenter we append one line to the "Backup State". That's EASY to do and takes a very small amount of RAM and Backblaze is efficient.
The first problem occurs when a customer purchases a new laptop and doesn't want to re-upload all their files from scratch, they want to "Inherit the Backup State". All of it at once. Backblaze was originally written 10 years ago, so for an average customers this all fit inside of a "reasonable" amount of RAM, let's say 50K of RAM. But the Inherit Backup feature itself caused an interesting problem. You are now carrying around all of the "baggage" of the previous file locations from all of your laptops going back 10 years. The logs only get longer, and we need all the logs to replay back everything that has occurred. So in the first year it is 50K. Then after 10 years of Inheriting it 5 laptops and 10 years later it is up to 500K of RAM. Still just fine.
The second problem is that the amount of data in the world has skyrocketed in the last 10 years, and some of our customers have 50 TBytes of data backed up with Backblaze (for $5/month). Again, all fine and all works, but when that customer goes to Inherit the Backup state we find it has passed 2 GBytes in size. Again, COMPLETELY FINE and the same original code still works -> but only on a 64 bit newer laptop which describes 98% of our customers.
I could rewrite the code, but I have to choose what to work on each day. Rewriting this code to work with 2% of our customers means that some OTHER feature does not get built.
A randomly interesting part is it isn't really the size of the backup, it is the NUMBER OF FILES in the backup. So a customer who has 1 billion 1 byte files is only storing 1 GByte of data, but the "Backup State" is more like 40 GBytes (for each of the 1 byte files we store a 40 byte SHA1).
I don't think Windows 10 supports any of the 32 bit only processors. AFAIK, all Intel and AMD processors in last 10 years has 64 bit support.
Update: Another user(geofft) mentioned debian analysis which confirms my point(albeit it says, none in last 13 years): https://news.ycombinator.com/item?id=14524215
Update 2: Looks like I am wrong. See comments below it.
Windows 10 32-bit runs well on it too. I mostly use it as a Netflix display or for calling out to Cortana, and control it via Synergy. Putting Windows 10 32-bit on there has kept alive a 10 year old laptop that still works fine, it was just lacking software / security patches. And there's a delicious irony to Microsoft continuing to support a discontinued Apple device.
I have Windows 10 32-bit edition running on a Fit-PC2 with an Intel Atom Z530. I believe this is a 32-bit-only processor.
I can't say it runs well with only 1GB on this old box - I'll probably put Linux on it instead - but Windows 10 definitely boots up and runs.
http://imgur.com/a/J9fGh (screenshot)
http://www.fit-pc.com/web/products/fit-pc2/fit-pc2-2i-specif...
http://ark.intel.com/products/35463
(edited to include information about this 32-bit system)
You misunderstood the question, which is: will the 32-bit version of Windows 10 even run on a CPU that predates x64? (The answer seems to be yes - according to Microsoft's list of requirements, it should run, say, on a Pentium 4).
https://www.microsoft.com/en-US/windows/windows-10-specifica...
I seem to distinctly remember it failing to boot on a 2.8Ghz Pentium 4.
http://ark.intel.com/Search/FeatureFilter?productType=proces...
64-bit systems can run 32-bit programs.
> Moving over to a 64-bit OS allows your laptop to run BOTH the old compatible 32-bit processes and also the new 64-bit processes. In other words, there is zero downside (and there are gigantic upsides)
is fairly clueless. I know of several enterprises that actually still depend on the 16bit NTVDM MS-DOS emulation for some legacy systems. Only 32bit windows 10 can keep running those; 64bit windows 10 removed that feature. So there is definitively not "zero downside".
Edit: This quote:
> I can't imagine having any problem hiring somebody to rewrite the original functionality but in a modern 64 bit Python program. Probably take somebody a weekend for most apps?
is so laughable I won't even comment further.
If you're using 16-bit Point of Sale software for example you might just decide to stick with 32-bit Windows as the VM wouldn't be worth it and would add more complexity for users.
This doesn't always have an answer.
Even if you do use DOSBOX, you still need to run a guest OS - will that be DOS, unpatched and unsupported Windows XP, or something relatively modern (if still 32-bit) that might let you stem the tide - instead of decaying further into your legacy hellhole?
and you can run dosbox on a modern 64-bit machine, so the idea of needing unsupported Windows XP (or similar) doesn't seem to be valid imo.
I'll try to clarify.
> I believe dosbox has support for hardware passthru.
There's a huge difference between hardware passthru and hardware passthru working. I've spent a lot of time fighting e.g. VirtualBox trying to get the simple task of USB passthrough working with relatively modern host and guest OSes, and failed. I don't even want to imagine the fun of COM and LPT passthrough, to say nothing of more proprietary options.
> and you can run dosbox on a modern 64-bit machine, so the idea of needing unsupported Windows XP (or similar) doesn't seem to be valid imo.
You're thinking of the host OS. Yes, I've run dosbox on modern 64-bit hosts.
You need a guest OS - the thing that runs within dosbox. I've often used DOS (what dosbox is named after, after all) or Windows 3.1 - both of which are unsupported and unpatched. These will run the 16-bit programs I'm interested in... and absolutely nothing else, including any less-legacy applications that have been upgraded to 32-bit. I could run those on the host instead of the guest, and that works for most of my needs, but now you get to manage trying to share data between the two OSes for all your existing workflows.
If you've got a mixture of 16-bit and 32-bit stuff going on, a better idea might be to run a 32-bit version of windows (it can still run 16-bit programs after all) instead of DOS or Windows 3.1 - this way I can run everything on the same OS, and get rid of all those sharing issues. Because Microsoft still offers 32-bit versions of it's OSes (to the chagrin of the author of this article), that could be a fully up to date, supported, and patched 32-bit version of Windows 10.
In the alternate history utopia for the author... where perhaps Windows XP was the last 32-bit version of Windows... well, XP is no longer supported, and basically no longer patched. I now have a significant tradeoff of convenience (single 32-bit OS context running all the programs) vs security (a supported and patched OS where possible), and that sucks.
Back to our current timeline, a similar story will play out when Microsoft finally stops cutting new 32-bit versions of windows. But for now, we've got our 32-bit Windows 10 guest OS running inside of DOSBox, VirtualBox, or whatever. And we've got our 64-bit Windows 10 host OS running DOSBox/VirtualBox/???. If we aren't actually doing anything with that 64-bit Windows 10 host OS besides DOSBox/VirtualBox... why not simplify and just run the 32-bit Windows 10 guest OS directly on the actual hardware?
For what it's worth, at that time, a lot of computers were still being sold with 32-bit only processors or an inadequate amount of RAM to handle 64-bit Windows. I can't count how many machines I saw sold with Vista and 1 GB of RAM. This actually became the subject of a class action lawsuit: https://www.slashgear.com/acer-offers-to-settle-vista-class-...
It also makes sense supporting those users upgrading their computer to the newer, more secure OSes. So I can see why Microsoft wants to continue to make 32-bit builds people can upgrade to for a number of years. I suppose the only real mystifying question is when doing a fresh install of Windows, it would allow you to ever select 32-bit. If the installer detects adequate system resources for 64-bit, that's what it should install.
Supporting the horrible legacy abominations combining 16-bit windows 3.1 targeting programs running side-by-side and interacting with 32-bit programs is a whole new can of worms. Maintaining an existing works-just-fine 32-bit build is way easier than writing, testing, QAing, and fielding support requests when the emulator layer breaks some poor bastard's existing workflow.
The author responded to a comment I left on the blog about 16-bit applications and he seemed confused about when development of 16-bit applications would have ended. He seemed to think around 1988; however, the Win32 API wasn't rolled out to the desktop until 1995 with Windows 95. Internet Explorer was available in a 16-bit version until IE5 which was released in 1999. Most of the 16-bit applications I see still in production had last releases in the early 2000s.
Emulation and virtualization aren't always an option. For instance if the application is used to support a piece of hardware that needs to be physically connected. Also some methods of copy protection or license validation used then will not work with emulation or virtualization.
Usually it's in the form of "I tried upgrading to Win 10 and my multifunction scanner/printer/fax machine stopped working, so I had to downgrade back to 32 bit Win 7."
So, how many of Microsoft's customers are also customers of Backblaze?
Like 0.1%?
As a side note, the even point for the need to go 64 bit (bigger OS, bigger executables, more memory used, etc.) is not in my experience at the 4 Gb of RAM level, but rather at the 6 Gb.
Looking at Backblaze logs, 100%.
But really, is nobody concerned that the author of TFA was the CTO of Backblaze and that somehow nobody stopped this awful article from being published?
There's no technical reason this cannot be offered, as the Windows installer already replaces all system directories, detects incompatible hardware, disables drivers that aren't supported, and everything else that would be technically required.
this actually isn't true. and I say this as the person who pushed for a 32->64bit upgrade path at microsoft in longhorn. at the most basic level - it is easy for the core OS. but any apps you've installed are going to be a crapshoot to see if they work, with their installers only expecting a 32bit OS, registry, etc.
upgrade is hard enough as it is so risking the experience to a customer of breaking many of their apps with no good path to resolution isn't worth it versus waiting ~3-5 years for a PC purchase cycle and their next preinstalled version of windows being 64bit and going from there.
It's possible MS can leverage part of its existing WoW code with x86 on ARM64. They would have more work to do with x64 on ARM64.
Plus the CPU might need special support to help things, for example I'm curious about how to efficiently emulate the stronger memory model of x86 on an ARM, and if the CPU provides help, it might be using low level tricks, reusing some bits here and there, to do the magic. Just some wild hypotheses though.
- Every pointer becomes twice as big (8 bytes vs 4 bytes).
- Potentially less data fits in the CPU cache lines, because the data is bigger.
One thing I wonder if the 32 bit edition mostly exists for small VM's?
I own a Dell Venue 8 (3845) and the reason it's running Windows 10 32-bit instead of 64-bit is because Intel inexplicably decided to ship 32-bit UEFI on Bay Trail instead of 64-bit UEFI. As far as I know, all Bay Trail devices are running a 32-bit copy of Windows because of this.
For Linux this isn't a problem, you can have grub x86 load an x86_64 kernel, but Windows doesn't have something similar. So 32-bit bootloader forces you to have a 32-bit OS.
So, thank Intel. I'm sure Microsoft and OEMs would have put x64 Windows on it if they could have.
Can you not just boot it in BIOS mode? Should be possible for the OS to escalate from there.
So it's 32-bit UEFI or a brick.
This being said, PAE doesn't seem to work great and out of a lab, when you start running multiple applications, you will usually want 4GB memory on the smallest system and typically 8GB, so, I think 64-bit is worth the sacrifice!
(No idea if still true, haven't done tests like this in many years)
If these applications were more mission-critical, we'd definitely want to stick with 32-bit Windows.
He's talking like there are people with 64-bit PCs running 32-bit Windows out of cluelessness or spite.
I wiped the computer and installed a 64-bit OS, but there are definitely people out there selling 64-bit PCs running 32-bit Windows out of cluelessness.
It was funny, because the only XP image they had was 32 bit. So we had really new PCs (Dells that are now 5-7 years old) running on these 32bit machines, with no choice by their IT staff: they couldn't make a new image (was a "global IT" thing).
So, they gave us a Windows 7 image that was only 32bit. Fun getting that one sorted before it was on everyone's PCs.
It is completely not obvious that there are Windows 10 users with 32-bit computers.
Here's an analysis from Debian trying to figure out whether to default to the 64-bit image: https://lists.debian.org/debian-devel/2017/06/msg00059.html
No one installs i386 new -- machines that are non-amd64-capable are:
* mainstream machines from 2004 and earlier
* a brief wave of mobile devices, now thankfully gone
* deeply embedded, usually incapable of running [the standard Debian installer]
> He's talking like there are people with 64-bit PCs running 32-bit Windows out of cluelessness or spite.
Cause this is what's going on, he's stating that explicitly.