286 protected modes, sure.
16-bit 8086, no way. difficulty of use did not hinder.
celebrating proper 32-bit protected modes, absolutely agree. but x86 was still well liked and used and was not the clunker that 286 was.
https://en.wikipedia.org/wiki/Windows_3.0
Windows 3.0 arrived in 1990.
Which was a follow-up to Windows/386 2.0 released in 1987.
I guess the big difference is few people ever used Windows 2.x, even in its 8086 variant, and use of its 386 variant was even rarer. Whereas Windows 3.0 was widely adopted. And by the time Windows 3.0 came out, 386 machines had become much more common too
While Windows 3.0 had compatibility modes with earlier Windows versions, its native mode was designed for 80386, which allowed a completely different programming model, removing the annoying limitations of the older Windows versions.
Saying that Windows 3.0 was a follow-up is not really appropriate because it was a very different operating system, even if many APIs had remained as compatible as possible with the earlier Windows versions.
No, this is not true. Windows/386 2.0 (and 2.1 and 2.11) were specifically for the 80386 only. The other edition of Windows 2.x, Windows/286, was for 80286 (and despite its name suggesting it required a 286, it was supported on 8086 as well, albeit with fewer features)
> Saying that Windows 3.0 was a follow-up is not really appropriate because it was a very different operating system, even if many APIs had remained as compatible as possible with the earlier Windows versions.
Again, I don't see how this is true. Windows 3.0's 386 Enhanced Mode was a direct evolution of Windows/386 2.x.
It sounds like you are under the false impression that the 386-only mode was a new thing in Windows 3.0, when it wasn't, it was first introduced with Windows/386 2.0
That must have been either because Windows 2.x in general was not popular, or because before 1990 the computers with 80386 were too expensive.
What I know for sure is that since 1990 Windows 3.0 has become popular enough and most of its users were using the 386 mode, which removed the problems caused by memory relocation.
Before Windows 95, most serious work would still be done using MS-DOS programs, frequently using EMM386.SYS for upper memory access, but many also had Windows 3.x on their computers and were toying with it from time to time.
TI replaced this line with 68000-based UNIX, then sold their business computer systems line to HP.
http://www.home.unix-ag.org/engel/ti/
I think this was the 1300 motherboard.
https://theretroweb.com/motherboards/s/texas-instrument-syst...
In 1990, far away from USA, and where computers where relatively much more expensive, I have started to use a 80386DX-based PC/AT clone on which (besides MS-DOS), I have used two 386-specific operating systems, i.e. Windows 3.0 and SCO UNIX (a couple of years later I have also used on it other 386-specific OSes, e.g. IBM OS/2 2.0).
I agree that during its lifetime more 80386 users must have used MS-DOS than other operating systems, but already since 1990 there was a non-negligible number of users of 80386 in 32-bit mode, with Windows 3.0 and its successors.
Moreover, even many of the strictly MS-DOS users were using EMM386.SYS in order to access the memory above 1 MB within MS-DOS programs.
While EMM386.SYS does not count as a complete operating system, it was a program using 80386 in its 32-bit mode that was an essential part of MS-DOS after 1990, because already by 1990 most 80386 PCs had more than 1 MB of memory, with 2 MB typical for the cheapest and 4 MB typical for the more expensive.
I never worked with the 80286, I pivoted to the i960 around 1992.
The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory.
We did not care about that then. Primarily because SMP and threads were simply not a thing. You might also note that any implementation of mmap(2) provides the exact same facility.
> permanently limited the architecture to one megabyte of addressable memory
It limited the generation. The architecture has obviously moved well past that. Now you can complain that though you have 64 bits only 48 are routed out to pins on your board.
> The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory.
hah. Program on a mainframe in 24bit mode sometime. That's a real treat.
The Motorola 68000 has 8 32-bit data registers and 8 32-bit address registers. They are named D0..D7 and A0..A7. You can use these in most instructions in the obvious/expected way. Maybe it's not completely orthogonal, but close enough. With those registers, you can keep 8 intermediate values and 8 pointers, and perform reasonable operations on them (add this and that, and store at that address)
The 80286 instruction has just 4 16-bit registers, 4 more registers with strange names (BP, SI, DI, SP) and 4 segment registers. None of these are general-purpose. I just looked it up and apparently, you can only use AX and DX for multiply/divide instructions. The segmented addressing is what is most repulsive about the whole thing: you can't just put an address into a register. You have to use a segment register and use an offset so the real address is (segment register value)*16 + offset. The reason for all this bad design is presumably compatibility with even more primitive earlier processors (8086, 8088, 8085, 8080).
All this backward compatibility is so painful and limiting. The 68k was launched in 1979 and it gets all of this right (32-bit addresses, general purpose registers), but the 8086 was launched in 1978 and it's so primitive and ugly.
It reminds me of Windows which even today has certain dumb features such as "\" being the path separator for compatibility with CP/M, some primitive relic of the 1970s. I understand the importance of backward compatibility for commercial success, but it's so ugly and I just don't want to have to deal with it decades later. Yes I know that the NT kernel can theoretically use a different path separator, but in practice, we're all still using \ for paths and / for command line options. Because CP/M was so incredibly great in 1975.