The 8086 and 80286 were so difficult to program, both in assembler and higher level languages. Everyone was relieved when the 386 and 486 came around - at last you could program sensibly and use operating systems that didn't crash all the time because of good memory protection.
When an OS making use of 386's features became mainstream we were well into the '90s. By that time the 386 itself was long obsolete. If by everyone you mean almost nobody, then I agree because that's how many people used the 386 as a 386 and not simply a fast 8086.
You are right about before 1990, but already in 1990 Windows 3.0 was released, which had a non-negligible amount of users, even if most Windows 3.0 users typically switched continuously between using Windows 3.0 and MS-DOS, because they continued to use various MS-DOS applications, e.g. Lotus 1-2-3, WordPerfect and so on.
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.
DESQview 386, a DOS multitasker, was released a little bit earlier. Probably more useful than Windows at the time given the popularity of DOS applications. I remember some local BBSes running multiple "nodes" in DESQview.
> Windows 3.0/3.1 offered a 386 Enhanced mode with significant benefits:
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
Previous Windows versions were for 8088 or 80286, which caused serious limitations for how memory was allocated and used (e.g. the programs had to be written in such a way as to allow the operating system to change the values of the pointers, whenever it needed to move the already allocated memory regions to other places).
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.
> Previous Windows versions were for 8088 or 80286, which caused serious limitations for how memory was allocated and used.
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
I assume that you are right, but for some reason the 386-mode of Windows 2.x has not been popular and it was little known.
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.
Texas Instruments was selling i386 Xenix systems to a major farm implement company in the early 90s. I actually traveled the country installing these in dealerships. They ran an accounting system written in RM+COBOL.
TI replaced this line with 68000-based UNIX, then sold their business computer systems line to HP.
I will say that the 486 Altos system I got a bit later was much better than the 386. Still, it was impressive how these boxes could support multiple users.
Those of us who were actually there at the time were running Xenix, System V, SunOS and Novell Netware requiring 386 features in the late 80s, much less the 90s.
Segmented memory isn't that weird. What was weird was that, instead of the obvious way of concatenating two sixteen-bit registers to produce a 32-bit address, they added them together to produce a 20-bit address. In addition to which there was some hardware nonsense with the top address bit ("gate A20"). This system seemed practically designed to generate pointer aliasing, and it also permanently limited the architecture to one megabyte of addressable memory. Whereas the concatenation system could have been extended by simply exposing more bits of the address bus on CPU pins.
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.
> This system seemed practically designed to generate pointer aliasing,
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.
Gate A20 and 640k memory limits are because of the design of the IBM PC and M$ DOS, not the 8086. Better hardware and software didn't have these limits (they had others).
I agree. I don't particularly remember any disdain at the time. It was just a thing that you worked with. Sure, it made things more complicated. Sure, it was easier with a flat address space. But there were way bigger problems in day-to-day development than segmented memory.
On 8086, the assembler managed the segmentation. All you had to do was load the DS (and possibly ES) register with an assembler defined symbol at the beginning of your function.
I never worked with the 80286, I pivoted to the i960 around 1992.
I was doing a lot of 6502 and 68000 assembly programming. Then (around 1988?) I got a PC with an 80286, and bought a book that described the 80286 instruction set. After reading it, I said "this is some bullshit" and returned the book for a refund. I had zero interest in writing a single line of code for that processor.
I first learned assembly on the x86 and wasn't until years later that I picked up m68k asm for a hobby computer and all that time I just assumed assembly was either gnarly and difficult like x86 or very bare bones for compilers (like the RISC isas). I didn't realize there was a such thing as nice, programmer oriented assembly.
Can you tell us what the vast difference was that made you give up programming for it? I've only assembled SPARC in college, so I have no basis of comparison.
It was a long time ago (37 years?) but the main difference is this:
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.
