Stephen Kitt covers the bases well, but I think the majority of the reason relates to fact that Windows 3.0 finally brought 286 protected mode execution to the masses. Even though the 80286 was first released in 1984, Windows 3.0 was the first mainstream platform that actually ran it in protected mode. That made it the first mainstream platform that could present more than 1088K (not 1024K) of address space to a single user process. This may sound like a minor technical issue, but it represents Microsoft effectively addressing a demand from the marketplace that had been only poorly addressed for 6 years prior.)
To give a bit more detail, the 20-bit/1024K 'real mode' address space of the original PC was widely considered to be major limitation, even early on in the PC's life. The original design reserved the top 384K of address space for I/O devices, ROM, etc., leaving 640K of address space for RAM. One of the important software applications of the time was the spreadsheet Lotus 1-2-3, and large spreadsheets could easily hit this limit. This was particularly true when running what were known as TSR's. (There are subtleties, but In modern terms, you can think of TSR's as lightweight background processes.)
In parallel with this, 1984's Macintosh release and the 1985 release of Windows 1.0 started introducing GUI's to the mainstream PC market. These added memory pressure, both in terms of the graphics processing and in terms of the fact that they made it possible to run multiple applications at the same time. (In truth, this only came later to the Mac with Switcher and then MultiFinder.)
So, in the first half of the 1980's into the second half, there came to be a large demand for techniques for addressing more than 640K of RAM, and there were a few common ways to handle the problem. Some machines would let you allocate part of the top 384K over to RAM, allowing for 704K and 768K configurations, but by far the more popular approach was something called LIM EMS.
LIM EMS was essentially a standard bank switching standard developed by Lotus, Intel, and Microsoft (LIM). Lotus wanted to make it possible to work with big spreadsheets and Microsoft wanted to make it possible to run more applications in real mode 20-bit Windows. What LIM would do is take 64K within the top 384K and divide it into four 16K pages. It then presented a separate multi-megabyte address space that could be mapped into those four pages. While the CPU's native address space was still 20-bit and 1024K, this provided a way to use memory operations to access more than what would normally be allowed in a 20-bit address space, and do so in a semi-standard way. Initially, LIM EMS was always implemented in the form of a hardware plugin card that contained the mapping hardware and EMS memory.
The downside to LIM EMS was that 1) programs had to be specially written to use the memory and 2) it was a bit of a pain to use. Microsoft Windows (as far back as 1.0) addressed these issues at least in part through the use of a handle based memory manager. Unlike traditional malloc
/free
, which returned a pointer, the Windows memory manager returned block handles. Developers only got the pointer to the block when the indicated to the OS that they actually wanted to use it. This let Windows do things like automatically move blocks around, including to EMS, when they were not in use. (Keep this in mind, it becomes important later on.)
Of course, the real solution to the address space issue was to select a CPU that had a bigger address space. This happened in 1984 when IBM picked the 80286 for the PC AT. The 80286 introduced a 24-bit address space, which was more than even a real-mode EMS 3.2 machine could manage... and it was native to the chip.
The catch was that to get the 24-bit address space, you had to adopt 80286 protected mode, rather than real mode. Unfortunately, DOS didn't support protected mode, and protected mode changed the rules enough that it wasn't necessarily easy to make the switch. Existing applications couldn't run in protected mode, and once a 286 was in protected mode, it was difficult to get it back to real mode. Still, around this time, there were continual rumors of an Advanced DOS (aka 286-DOS or DOS 4.0) that would somehow enable protected mode operation. What this wound up being was the IBM/Microsoft joint effort - OS/2.
OS/2 brought protected mode to the PC, but due to limitations of the 286, it was itself limited. While it could multitask OS/2 applications, running a DOS application suspended all the OS/2 apps, and was subject to all the usual DOS limitations. It was also expensive, only partially complete when it shipped, and had high memory requirements. It wound up not doing very well, while the industry stayed with DOS, etc.
At this point, it's worth pointing out that there are also 80386 machines. The 80386 is expensive, but it has a couple things the 286 doesn't. The most notable (at least for the late 1980's) is what is known as V86 mode. The 80386 has hardware support for running multiple-real mode processes. This is used by Windows/386 and DesqView/386 to run multiple real mode processes at the same time. The 80386 is also powerful enough to emulate LIM EMS with its internal MMU. The 80386 is truly revolutionary. (Note, though, that even under Windows/386, the Windows environment itself runs in real mode with a 20-bit address space...)
There's also Windows/286 around this time. One of the implementation details of the 80286 is that it would actually generate physical addresses as high as 1088K-16bytes. Windows/286 allowed access to this, so-called, high memory area beyond 1MB.
This answer is turning into an epic, but this is the state of affairs when Windows 3.0 is about to be released. 80286 machines have been out for 6 years and 80386 machines for 4. While there are hacks and third party solutions to use the capabilities of these machines, there's nothing that works all that well, and nothing that easily ships out of the box. It's really rather a mess.
This is when a Microsoft Windows developer named David Weise figured out how to run normal, mostly unmodified Windows applications in protected mode:
https://docs.microsoft.com/en-us/archive/blogs/larryosterman/farewell-to-one-of-the-great-ones
This is a huge win for Windows, because there finally was a cheap path for people to take their existing hardware and software, and mostly cheaply get to use the capabilities of their system. (The reason this was possible at all is that handle based memory manager I mentioned several paragraphs ago. If using protected mode means following a different set of rules about memory usage, it turned out Windows applications were already mostly following those rules.)
You also have to keep in mind that this represented a huge turning point for Microsoft. They immediately knew it would undermine OS/2 (largely useful for protected mode access) and irreparably damage its relationship with IBM. They of course did it anyway, and made a huge success out of it.
As Stephen points out, there were a number of other significant and very positive changes to Windows, but I think the biggest is that it finally provided a decent answer to the memory question.