Microsoft is beginning what will be a very long and drawn-out process of no longer supporting 32-bit versions of Windows 10. Beginning with Windows 10 version 2004, which is already available to OEMs and developers, the company is no longer offering a 32-bit version of the OS to OEMs for new PCs. The change is indicated on the Minimum Hardware Requirements documentation.
Hardly surprising. We’re well past the point where new machines need 32bit Windows.
i didn’t even know that windows 10 had a 32 bit version.
it makes a lot of sense that they’re going to end support.
i mean at this point 32 bit x86 cpu’s are so slow, that they’d have a hard time running windows anyway.
not to mention the fact, that there’s a lot software, where they don’t provide a 32 bit binary anmore.
I knew, because I’ve accidentally installed it on work systems on more than one occasion 😐
Every 64-bit x86 cpu is also a 32-bit x86 CPU. If OEMs are selling 32 bit windows at this point it’s to run on 64-bit hardware.
The article linked seems to make the same mistake
32-bit Windows mostly exists these days to run 16-bit code – win16 or DOS – or to run legacy device drivers.
I’m not entirely sure why they just don’t unlock the artificial memory limits on 32-bit desktop Windows (ie, PAE mode) as they did for Server but it’s not surprising they’re just getting rid of it.
The1stImmortal,
I had forgotten about that, but good point. I do remember being annoyed at the loss of 16bit app support with 64bit windows (technically this was AMD’s fault), I lost the ability to run my old dos software. DOSbox helped fill in the gap, but was harder to use than launching things directly. For some people it may have been a reason to keep a 32bit OS around.
It’s just more effort to support it, but from a practical standpoint 2-3GB per application isn’t so bad. Even to this day most 64bit applications don’t hit that limit under normal use. Still, it’s easier to write things like operating systems and memory mapping large files under a larger continuous address space, 48bit in the case of x86-64.
>>I’m not entirely sure why they just don’t unlock the artificial memory limits on 32-bit desktop Windows (ie, PAE mode) as they did for Server but it’s not surprising they’re just getting rid of it.
Most of the windows 32 bit PAE mode not allowed us running server know alot about. Windows drivers to work in 32 bit PAE mode had to be code compatible or it corrupted memory. Yes a 32 bit windows server running in PAE mode happens to load a non PAE 32 bit driver all hell would break lose. Bad part is drivers were flag as PAE compadible when they were not. So welcome to a game of driver loto.
Although it’s long, a full write up for this is at https://www.geoffchappell.com/notes/windows/license/memory.htm .
The important thing to know is that PAE is used as soon as NX/DEP is present, so most XP machines are already running a PAE kernel. The page table format is changed when PAE is present, including for NX/DEP. The only difference is that these systems are limited to never use a physical address above 4Gb. From a software point of view, this is somewhat curious, because physical pages are described as indexes, not pointers, so 4Gb of physical memory is described by page numbers 0-1048575. Obviously it’s possible to write a driver that steals bits and can’t address higher numbered pages, but it’s not a natural or easy thing to do – any operating system structure will have 32 bits for a PFN. Put another way, I never had any problem using a 2003 PAE kernel with memory above 4Gb on account of drivers.
Obviously this is all historic now since everyone is using 64 bit kernels, but there was a long time where systems with 4 or 8Gb of RAM would generally be more efficient with a 32 bit PAE kernel. But then, if people did this, most application software would need to remain 32 bit, which would prevent 64 bit systems from offering any value for even longer.
malxau,
I believe that all modern operating systems use PAE, 32bit operating systems needs it for features like NX as you indicate, but even 64bit systems use it too since I believe PAE needs to be enabled before 64-bit “Long Mode” can be utilized.
https://www.amd.com/system/files/TechDocs/24593.pdf
As you noted already, some operating systems won’t use the extra memory addressable via PAE. It’s interesting to note that even for 64bit modes, the virtual address space is limited to 48bits (for current generation CPUs) while 52bits are physically addressable. This means that you still need to use PAE on x86-64 to address the full physical address space. I don’t expect these to be a major problem anytime soon since 48bit / 281 TB represents a lot of data, but conceivably someone might want to use virtual addresses greater than 48bit for memory mapping huge datasets.
It’s not really about PAE; it’s about whether the driver supports 64-bit physical addresses for things like bus mastering/DMA operations.
For some cases the hardware simply doesn’t support 64-bit physical addresses at all; so when the driver is asked to transfer data to/from areas above the first 4 GiB of the physical address space it has to do a “bounce buffer” thing (use CPU to copy the data to/from a different physical address that the device can use). If all physical addresses are 32-bit then device drivers don’t need to support this “bounce buffer” (until someone flicks a switch and the bounce buffer support that never existed suddenly becomes a necessity).
For other cases (where device does support 64-bit physical addresses), other difference may exist. E.g. maybe the device has a pair of 32 bit registers (“high 32-bit, low 32-bit”) and the 32-bit driver never bothers to set the “high 32-bit” register.
(Replying to Brendan since I don’t get a reply button for him.)
That’s all technically true, just note the context. What I was saying before is 32 bit is sufficient when referring to PFNs, which is what Windows typically does – see how an MDL works, for instance. What Geoff Chappell was saying is a physical address that refers to page plus offset has been 64 bit since NT 4.0. He’s also pointing out that Windows 2000/XP pre-SP2 made no attempt to prevent PFNs above 4Gb from being exposed to drivers, because they limited the maximum memory but didn’t care where the memory physically is.
While I technically agree that a device can require memory to be below 4Gb, note the same device can be plugged into a 64 bit system and it would still have the same requirement. The assumption here is that the 64 bit driver is “new” and therefore handles the condition, but the 32 bit driver is “old” and might not. Even if this were the concern, there are many ways to solve it, such as having “new” drivers indicate >4Gb support and transparently double buffer when talking to “old” drivers. In a practical sense though, any peripheral designed for a 64 bit capable system is unlikely to require memory in the low 4Gb, so the set of devices we’re talking about are devices that are attached to a large memory system that never expected to be attached to a large memory system, regardless of the OS kernel.
(Replying to myself since I can’t edit)
I guess what I’m trying to say is in the context of a machine with 8Gb of RAM, when trying to determine whether to run a 32 bit kernel with PAE or a 64 bit kernel, both environments require drivers that handle the condition, and the concern is that 32 bit lacked an enforcement mechanism. But if you ran out and bought an 8Gb machine in 2010 or whenever, it won’t use 2001 era drivers, so this ceases to be a material point of difference.
I bought a quite low power hp consumer convertible a few years ago, and it came with a 32bit os, despite having a 64bit cpu, probably because it has 2gig of ram only. I guess this means end of updates for that device coming up with ths need of a clean reinstall of win10 64bit at some point in nearer future before the device is too low power to run windows at all.
That’s not what it means… even if they don’t support windows 10-32bit at all on the next release it still means that this current release will get updates until it goes EOL which is quite a long time.
In all likelihood they are just trying to stop OEMs from ripping off customers with those low ram devices that can’t even run 64bit applications… I think you’ll still get 32bit retail releases for a while at least, and when that stops you’ll still get updates on that for some years.
And when _that_ stops, there is always Debian 😉
Windows is undergoing changes that would normally have warranted a new major version bump. Combine this with the fact that microsoft has declared windows 10 to be the last major version of windows, it’s going to make the compatibility matrix for windows 10 increasingly complicated. How long will they keep it up? Will the next decade see no bump in windows identities?
I would think that marketing will eventually tire of the same old identity and announce something new.
Support calls will be: did you install the latest updates ? Yes ? OK, so we can then assume you have X, Y and Z and no more W or V.
“Hardly surprising. We’re well past the point where new machines need 32bit Windows.
>
>
Clueless Dolts. it’s not machines that need 32bit Windows, it’s *PEOPLE*
There are tons of old software and hardware that don’t work very well with or are compatible with newer windows versions are are still in wide use because they use file/data formats/hardware features that aren’t supported anymore in 64 bit Windows or the software that runs under it.
Sheesh.
Is it reasonable to expect infinite backwards compatibility? Honestly, trying to maintain that sort of backward compatibility is what’s holding MS back on Windows (I vaguely remember an article I can’t cite about that being the reason their compositing system is still so awful). The way Apple does it is better, frankly (even if they do it maybe a smidge too quickly – and Linux is of course the best).
But I think we’ll end up getting a 32-bit container at some point anyway – I mean, why not? In a strange way, it could up being (conceptually at least) like the way various wine projects run Windows apps on Linux. They create a customized Windows environments to run specific apps within. This is probably the way forward for backward compatibility on Windows. Maybe they can even get a reasonable security system in place that lets us finally run a “sudo-less” like environment, without Antivirus destroying our performance any more…
Many socially critical legacy systems still use 32-bit, MRIs, CAT Scanners, electron microscopes, industrial control systems, even older synchrotrons and linear accelerators. (Some even use 16-bit!)
It’s not an accident many of the systems run on mature and known 32-bit architecture. Do you want the latest and greatest of unproven reliability diagnosing that lump!
I wonder if the 32-bit naysayers would decline a life saving brain scan because it’s not 64-bit. I suppose they have never heard of false positives!
The title of this should also be changed, it tries to sound like Windows 10 is dropping support for running 32bjt software, which is what macOS did, Ubuntu tried, and MS would be stupid to do.
Windows dropping a 32bit version of the OS makes some sense, as I am not convinced that a 32bit only processor could run it! What was the last CPU that didn’t have x64 extensions?
Last IA-32 (so without x64 extensions) cpu in production that you would expect to find in anything that would be either
Vortex86 http://www.vortex86.com/compare this is i586 instruction level.
RDC R8620 R8621 RD6201 http://www.rdc.com.tw/?route=home/socs this is i486 instruction level
There is zfx86 https://www.zfmicro.com/zfx86.html you are not recommend to make new designs using it.
These are chips that you can get new from production today. There is the ao486 for fpga as well as the name says 486 level instructions.
Now when it comes to could these run windows10 . Vortex86 and RDC and the ao486 support up to 2G of ram. Windows 10 specifications sheet says 1G of ram for 32 bit version so zfx86 is out at this point with its 256 megs of ram limit. Windows bare min clock speed for Windows 10 is 1Ghz this puts RDC(400Mhz) and ao486(90mhz)out as well. 1Ghz clock speed of the Vortex86DX3 would not be exactly fun but it is really the min specification chip to run windows 10. Please note Vortex86DX3 is the only chip out of the Vortex 86 line that meets windows 10 min specifications.
Lot of people are not aware of the embedded used x86. Its been a long time since desktop has had a 32 bit only x86 chip. But in embedded 32 bit only x86 chips are still in production and one of them was able to run Windows 10 by min specifications.
Lot of people don’t expect that last x86 CPU that did not have x64 to be chips currently in production and you have number to pick from.
If it’s a 586 instruction set then no, it won’t run windows 10 at all… Supposedly it requires PAE, NX and SSE2.
https://www.lifehacker.co.uk/2015/08/06/can-you-run-windows-10-on-a-stupid-old-pc
https://www.forum-3dcenter.org/vbulletin/archive/index.php/t-594473.html
Vortex86DX3 is a i686 and typed that wrong early Vortex86 is i586 last generation Vortex is i686 but you are right its missing PAE, NX and SSE2. It is possible to get Windows 10 IOT headless up without PAE, NX and SSE2 these but you have no graphical welcome command line only and running in a mode that Microsoft does not officially support. Yes the no NX flag and no PAE flags is still in windows 10 for those so called incompatible embedded applications(ie using horrible CPU like this one) but turning them on instantly kills graphical that is not direct to screen built application(lot of ATM software).
Vortex86DX3 is scraping the very bottom of the barrel that will run anything Windows 10 that could possible display a Windows 10 blue/red screen of death. If you are wanting the Windows 10 desktop you are out of luck of course.