The low-down on LOADALL (1990)
gist.github.com
gist.github.com
"The power of being able to re-program ANY and ALL of the registers of the CPU with one single instruction opens up a whole new world of possibilities. Including, but not limited to:... installing most of the guts of custom TSR's".
Wikipedia seems to confirm this:
"Intel did not expect personal computers to use the 286. The CPU was designed for multi-user systems with multitasking applications, including communications (such as automated PBXs) and real-time process control." [https://en.wikipedia.org/wiki/Intel_80286]
Viewed in the context of the 432, it's not hard to imagine Intel viewing an 8086 follow on chip as a niche market CPU while their would-be-anointed successor takes the more mainstream PC market.
What's maybe more interesting to consider is the role of the 80386, and how its design process might have gone. By the time of the 80386, Intel built in features to the chip explicitly useful for the purpose of bringing multitasking to the PC space. One of the 386's many noteworthy features, was 'V86' mode, which was designed to allow it to easily multitask multiple real mode 8086/8 apps at the same time. This was essentially a 'run several DOS programs at once' feature, and there were a couple major PC "OS"'s that used it - most notably Windows/386 and DesqView/386.
(You should also note that this is not close to the first time that Intel tried to get away from x86 - the iAPX 432, i860, and Itanium all represent varying attempts to achieve that goal.)
It's a strange irony that none of these homegrown attempts worked out, but x86 is now threatened by the one external architecture where Intel was a performance leader in 2000-2005 with their StrongARM / XScale chips.
Intel giving up on ARM in 2006 was IMO one of the greatest strategic blunders of all time.
Early versions of Windows all ran in real mode. Multiple Windows programs were loaded into the same real mode address space (no protection) and co-operatively multitasked based on the GUI's messaging infrastructure. (A program could just stop processing GUI messages and totally monopolize the CPU.) There was also some limited support for memory relocation via a block lock/unlock mechanism built into the memory manager. If you wanted to run a DOS program, this was all suspended, with the DOS program given control over the full machine in the interim.
What Windows/386 did is put a 386-specific V86 multitasker called VMM underneath all of this. This multitasker had isolation between the processes it ran, one of which would be the Windows GUI environment I described above and others could be other DOS Programs, for which there were also provisions to put the output into a window of the GUI. This is really the first moment Windows got protected mode support, although none of the user processes actually saw the larger address space.
It's Windows 3.0 that let the GUI itself run in protected mode, albeit still with 64K segmentation. Combined with some graphics and usability improvements in 3.0, this is really why 3.0 'got it right' in terms of feature set and price point.
Windows for Workgroups 3.11 then moved the file system to protected mode, a product called Win32s let Windows programs themselves use 32-bit segment addressing, and combination of all of that that was the foundation for the 'fully 32-bit' Windows 95, which just moved a bunch more functionality into 32-bit code and the VMM 32-bit multitasker originally introduced in Windows/386.
What about the 286 protected mode support. Did that come later?
Yeah... Protected mode came to Windows in fits and starts. Windows/386 introduced it via the V86 multitasker. The Windows VMM layer ran in protected mode, but all the client processes ran in real mode. The implication of this is that they were limited to a 20-bit address space, plus whatever auxiliary memory you could map in with a bank switching standard like EMS.
So at this point (up to 1990 and Windows 3.0), all Windows programs ran in real mode and shared a single 1MB heap. The official path forward from this advocated by the IBM/Microsoft partnership was OS/2. OS/2 put everything in 286 protected mode, but had enough API and EXE format differences that you had to have OS/2 specific software to use it.
However... in the late 80's, a Microsoft engineer named David Weise came up with a way to run Windows itself in protected mode that mostly retained compatibility with existing Windows software. (There was a flag that had to be set in EXE's that enabled protected mode operation, but the format and API's were all exactly the same. This is true to the extent that there were utilities that would toggle just the flag and often let you run an otherwise unmodified program.)
https://landley.net/history/mirror/ms/davidweise.html
It was Weise's work that enabled Windows 3.0, which came with a largely fulfilled process of getting you OS/2's larger address space, but at a much lower cost of entry. Part of the way they achieved that was to let it run in three modes:
* Real mode - This is essentially how Windows 2.x ran. Everything in real mode, and DOS apps preempted everything.
* Standard mode - This was the new addition. This gave you protected mode for compatible Windows apps, but they had to be marked compatible. DOS apps still preempted everything
* "386 Enhanced" mode - This was the Windows/386 equivalent for bigger Windows 3.0. (But it came in the same box as part of the same SKU.) It combined the new protected mode Windows features along with the ability to pre-emptively multitask DOS apps.
Note that everything I've mentioned (aside from the low level VMM multitasker) used 16-bit segment offsets. So even though your address space was 20 bits, you still had to worry about segment arithmetic for blocks of memory beyond 64K. 32-bit segments were fully native to the Windows NT kernel and came into the original windows codebase via Win32s, which was essentially the Windows equivalent of a DOS extender.
(Note that interestingly, this all implies that 386-specific protected mode came to Windows first, with 286-specific protected mode later.)
To be more confusing - Windows 2.0 have 2 versions. First is regular that runs on 8086 and other was Windows/386 2.0.
But confusion continue with Windows 2.1. There was also two versions - Windows/286 2.1 (that also can run on 8086) and Windows/386 2.1.
Windows 3.0 was like One-Size-Fits-All because minimum was 8086. Except when you run it on protected mode. Windows 3.0 with Multimedia minimum was 286. And Windows for Workgroups 3.11 minimum was 386 because dropped standard mode.
If it has been kept over for compatibility purposes, I would like to know whether it has been completely superseded by other instructions or if it still has a place in cogeneration.
once you toss aside the OS and look at the hardware with "what can i make it do?" there's still some joyous horrors possible. DOS was good in that it was so little OS to throw aside, where it got between you and the hardware at all.
> ** 0F 05 hex **
Nowadays this opcode is used for the "syscall" instruction.
According to this stackoverflow answer, "int 0x80" is a Linux-specific legacy way to do syscalls:
https://stackoverflow.com/questions/12806584/what-is-better-...
FreeBSD (and AFAIK other BSDs) also use(d) it; most likely any Unix system on x86 that doesn't require a processor with sysenter/syscall instructions would use int 0x80 to do syscalls.