"This is how bad it is -> When Microsoft released Windows Vista in 2007 it was 64-bit and also ran all 32-bit programs flawlessly. So at that time I was baffled why Microsoft ALSO released Windows Vista in 32-bit only mode – a version that refused to run any 64-bit binaries."
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.
Yeah. Its called having options and you don't get much of that with Apple.
I remember when Apple stopped supporting the Core 2 DUO machines because the EFI was 32bit(not even the processor). I was not pleased
Wasn't that only the first generation of hardware they made with Intel's processors? IIRC, my friend and I both got laptops about 3 months apart and mine had support longer than his, I don't know if this was the issue or not.
The first Intel Macbook Pro in Early 2006 was Core Duo (32-bit), then in October they reved them with Core 2 Duo (64-bit w/ 32-bit EFI). I remember specifically because I had to wait out the first couple months of my freshman year of college without a laptop, waiting for that 64-bit support that was supposed to drop at any time...
You lose at least one thing with 64 bit Windows versus 32 bit, support for legacy 16 bit applications or components. When Windows Vista, 7 and 8 were released there were still many in use which alone justified Microsoft releasing 32 bit OS versions. I still see them in use today but at a much much lower rate than 5 years ago when Windows 8 was released.
I don't think it would have been so hard for them to develop an emulation layer to run 16-bit programs on 64-bit if they were really concerned about having that functionality. It's not like performance issues are going to be a concern in a 16-bit application. So that might be a reason people still use 32-bit Windows, but it surely isn't the reason that Microsoft keeps building for 32-bit.
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.
Maybe but then you need to maintain a whole separate windows installation with separate printer and scanner drivers and network logins and so on. Plus your files are hidden away inside a vm disk image. If all you need is some light internet/mail access and your legacy applications, while still being able to use your peripherals, 32bit windows fits the bill perfectly as long as 64bit windows refuses to implement 16bit compatibility.
Exactly. That small number of 32-bit Windows-running Backblaze customers might very well have legacy 16-bit applications that they need to continue to support. It's remarkable that the author of this post completely missed that point, and in fact goes on and on about how you lose nothing by running 64-bit Windows.
Those customers can use emulation to cover their needs. The point of the article is that whatever benefits exist of the 32 bit skew, they are outweighed by its costs.
From his perspective but not from the perspective of those who still need to maintain the systems using 16-bit apps. The costs of emulation and virtualization outweigh the cost of deploying a 32-bit version of Windows for them.
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.
To be fair I think the number of 16-bit applications still in use would surprise a lot of people.
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.
You also lose out on some drivers for older hardware. Most of that hardware is trash, but occasionally people still want to use it even if it means being stuck on 32 bit Windows.
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."
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]
From the followup comments, there were apparently a few netbooks using the mobile chipsets as late as 2012, but I doubt a netbook from 2012 using a mobile chipset is going to be well-supported by Windows 10, regardless of CPU architecture.
When my sister started grad school at Harvard she bought a brand new 64-bit Dell laptop from the school store that came preinstalled with 32-bit Windows. I was amazed.
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.
Haha. I helped out IT for a major corporation. This was only a few-ish years ago, but we were just moving to Windows 7 from XP.
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.
I may read it the wrong way, but basically it says "since all (98.4%) our customers have more than 2 Gb of RAM, then Microsoft should only make 64 bit OS".
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.
I think you actually did. They are not saying - "Hey, we are having only a few 32bit customers, Microsoft should dump them". The problem is much more complex.
No, they are saying, more or less "Hey, having to support a tiny fraction of our users that are on 32 bit causes us a whole lot of problems, so, since we don't have the guts to tell these customers to switch to 64 bit, we are telling Microsoft what they should do in order to totally remove the inferior OS architecture."
I imagine an upgrade path from 32-bit to 64-bit installations would take care of a huge chunk of the population MS keeps the 32-bit editions around for (enterprise 32-bit installations on 64-bit-capable hardware).
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.
> There's no technical reason this cannot be offered
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.
> 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.
> 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.
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.
Given that the article above is talking about the 32-bit version of Windows 10, I think 'likelynew is aware of that.
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).
I have failed multiple times to reliably use a Linux desktop with 1Gb of ram. Even the most stripped down Ubuntu version seems untested for this setup; for instance, the background process that repacks the DEB database easily peaks over 1Gb, and you get the computer swapping at a random point. On top of that, also browsers have a really hard time working with that constraint.
Windows 10 requires at least a 1 GHz processor. Every Pentium 4 released (most all of which were 32-bit only) had a clock speed of at least 1.3 GHz, so ALL of those meet the requirements. The pleasantness of using such a system is a different story.
That's incorrect. I'm running Windows 10 32-bit on a MacBook 1,1, one of the machines Apple left stuck on Snow Leopard. It has a 32-bit 2.0Ghz Core Duo (not Core 2 Duo) CPU and maxes out at 2GB RAM.
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.
> 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.
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_...).
> Has Backblaze honestly ever had this problem, where 2GB of RAM was not enough to reliably find a customer's backup state?
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.
It's 500K or less for "most customers", but then for a few of our largest data customers it 2 GByte. Think of a bell curve where the average is 500K but the top 10% are above 2Gbytes.
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).
> 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.
Lots of new computers are sold with 32-bit Windows on them. I think this is primarily devices with lower memory, because 32-bit Windows uses less RAM and less disk space. I own a Windows 10 tablet with 1GiB RAM, for example.
> I own a Windows 10 tablet with 1GiB RAM, for example.
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.
I am so much shocked by the comments here giving reasons that they provide 32 bit operating systems, ranging from ability to run 16 bit softwares, to the speed. I mean, it's not a bad thing to debate, but I seriously did not expected it here.
The upcoming battery friendly ARM based windows PC will support x86 emulation 32-bit apps in near native speed. Not sure if it will support x64 now or in the future and perhaps someone can comment if this is a technical limitation or an economical or both.
I think they don't support x64, and probably they never will, or at least not before a very long time.
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.
Most of the comments addressed the issues with the article. It mostly boils down to, Microsoft will support legacy for as long as possible (such as 16 bit apps), some performance advantages of 32 bit OSes. And that one reader who correctly stated that some are still on 32 bit CPU architectures.
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?
> 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?
But why do they offer 32 bit windows to consumers? I get why you'd keep some embedded skew for just this dos emulation legacy case, but why are 4% of backblaze customers running a 32 bit windows? Microsoft shouldn't be offering that as a choice.
What if those customers want to run legacy 16 bit apps in NTVDM? I have a few games I like that I occasionally fire up a 32 bit VM for just for this reason.
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.
The question is why add a VM layer (and suffer the loss of direct hardware access for drivers / dongles / having all your programs in the same context / user confusion / other drawbacks) just so you can run a 64-bit host?
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?
> 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?
I remember back in Windows Vista days (and early Windows 7 builds) doing extensive 32-bit Vs 64-bit testing and the 32 bit system outperformed the 64-bit in everything from startup time to application launch time.
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)
But, but when you upgrade to 64-bit you DO lose access to 16-bit programs! (I seriously did go into slight withdrawal when I couldn't play BOWEP Tetris anymore. No other Tetris will ever be the same...)
The way Microsoft implemented 32-bit support in Windows 64 broke a lot of the legacy applications I help maintain (from an admin/support standpoint, not development standpoint) at work. Years after switching to 64-bit Windows, we still uncover subtle bugs that need to be patched in our configuration or by the vendor (if they still exist).
If these applications were more mission-critical, we'd definitely want to stick with 32-bit Windows.
74 comments
[ 4.3 ms ] story [ 144 ms ] threadFor 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.
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.
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.
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."
He's talking like there are people with 64-bit PCs running 32-bit Windows out of cluelessness or spite.
> 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.
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
From the followup comments, there were apparently a few netbooks using the mobile chipsets as late as 2012, but I doubt a netbook from 2012 using a mobile chipset is going to be well-supported by Windows 10, regardless of CPU architecture.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.
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%.
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.
> 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.
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.
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.
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.
http://ark.intel.com/Search/FeatureFilter?productType=proces...
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).
64-bit systems can run 32-bit programs.
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.
- 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?
https://news.ycombinator.com/item?id=14518290
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.
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?
> 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?
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.