tom9876543 wrote:This is another example of crap Microsoft design. This code is convoluted and inefficient and it was stupid of Microsoft to assume future 8086 cpus wouldn't have more than 1MB of memory.
The assumption was that there weren't going to be future 8086 models, something which Intel had basically assured both IBM and Microsoft would be the case. Intel saw the 8086 as a stopgap until the 432 was ready, which would allow them to get out of the muck of the microcomputer market and focus on the two business lines they expected to be viable: 8-bit and 16-bit microcontrollers, and 32-bit academic workstations.
You also need to realize that in the late 1970s and early 1980s, new home computer models were generally
sui generis - no one cared about either backwards compatibility or forward compatibility, because the next generation of hardware was going to be completely different anyway, possibly with new (and often unrelated) CPUs and all-new software.
(Furthermore, the design decision about CALL 5 was probably made by Tim Paterson when he was writing
86-DOS at Seattle Computer Products, before the IBM PC was even on the drawing board. But that's neither here nor there.)
Since IBM was just trying to 'deal with' (i.e., smother with any eye to destroying) the small-computer market, they didn't care; actually, Intel probably wouldn't have agreed in the first place if they didn't know this, as they thought micros were a dead end that needed to be sunk rather than acting as a drag on their 'real' business.
That also suited Microsoft fine as well, as they were was more than happy to write code for other processors - by then they were as sick of the 8080 line as Intel was (and from a programmer's perspective the 8086 - which started out as a super-8080 - was, if anything, even worse despite the larger memory), and would have preferred to focus on the 6502 (which was
the 8-bit chip at the time), the 6809, and 68000 (which was looking to steamroll everything ahead of it in the growing market for low-end workstations - Microsoft was expecting to be selling
Xenix as their main OS offering). They were in the deal for the opposite reason - they figured IBM would misread the market and embarrass themselves, leading them to abandon the project and leave the home and small business markets free to develop on their own.
Also, they didn't really expect PC-DOS to be much of a much - it was there mainly to give customers a less expensive alternative to CP/M-86 and UCSD, but it was expected that
Digital Research would get the lion's share of the customers. They knew that Kildall had the same view of the project they did, but unlike them, he resented it rather than seeing as a chance to stick it to the Evil Empire.
(OK, so it probably wasn't quite like that for Gates, who really did see it as a business opportunity; however, he also seems to have thought that IBM were going to fall on their face, and given how universally hated Big Blue was among the microcomputer community which were his main customer base, he probably found some amusement in the idea. Oh, and because he could get them to foot a large chunk of the development bill for software Microsoft was already going to be writing for other 8086/8088 systems anyway.)
In any case, it was only a quirk of the PC/AT's design that it became possible later, as when the AT was designed, the
A20 line was
meant to be
permanently latched down in hardware. Microsoft probably had no input on this, other than possibly to point out the CALL 5 issue (by then PC-DOS was a much bigger concern than expected, but it still was IBM's call, not Microsoft's). Since there were other reasons to wrap the high memory, this probably wasn't the main reason for the A20 latch.
It wasn't until after the AT had been on the market for a while that a Lotus developer noticed that he could hack the keyboard controller to re-enable it, and at first people didn't believe him. It was seen as a
bug at first, and the only reason it didn't get 'fixed' was because by then programs like Lotus needed more memory (which is why the developer was messing around with it in the first place - he was looking to see if there was a way to trim the size of the keyboard handling routines, and stumbled on it by accident). Up to that point, the assumption was that 640KiB was as much a hard limit for the AT as it was for the PC and XT, even for 286 protected mode, and finding out that this wouldn't be the case was a shocking revelation.
Not that it will matter in newer systems much longer; Intel has wanted to drop 16-bit mode outright for years. They haven't done so yet, because backward-compatibility is indeed a thing going forward from the early 1980s, but they do seem to planning that once there is a critical mass of UEFI-only motherboards to let them force the issue of abandoning the legacy BIOS entirely - and at this point, ~ to the contrary, firmware compatibility is the main sticking point, not compatibility with older application software.
