"In 1989, computers only supported a single small display"
Macs supported more than one display at that point, I think.
Macs supported more than one display at that point, I think.
[1] https://en.wikipedia.org/wiki/Hercules_Graphics_Card#Hercule...
In contrast, the Mac II supported multiple displays in the sense that QuickDraw would happily draw graphics across monitors, switching color depths along the way, without applications needing to even be aware of the presence of multiple graphics cards.
The Mac also supported having multiple identical graphics cards plugged in. In contrast, a Hercules card could coexist with a VGA card, but not with a second Hercules card, for example.
I don't know anything about Macs but I have no trouble believing it was superior.
The PC was incredibly primitive in this area. But that's also why there was essentially nothing to configure when you inserted a VGA and Hercules card into a machine. Their physical configuration is defined by their respective standards, and the standard didn't consider multi-monitor support. It's just fortuitous that Hercules/MDA and VGA standards didn't collide.
My solution was to write little C programs which addressed the Hercules screen directly. Fun times! :)
It was dog slow, even slower than in DOS.
For graphics yes. But around that time all Borland (C, Pascal) products supported debugging with to monitors (VGA+Hercules). And I used a little TSR for years that transferred the contents of the main VGA Screen to Hercules via 'PtrScr' key, which was handy too. All text mode of course.
That said, I literally was born after Windows 3.0. So... I never personally dealt with such a setup. Maybe some day, as a matter of exploring older computers, I will get a chance to actually run such a setup and see what it was like.
It's probably worth mentioning that the idea of developing Windows software in Windows was something that only came around until 1990-91 or so. Prior to that, all the tooling (except for things like the message Spy and the resource editor) ran in the command line in text mode, including the debugger.
Visual Basic gets a huge amount of grief, but when it was first released, this was a huge part of the reason why it was so amazing. It took Windows development from a relatively complex and obscure process involving a multi-step build/edit/compile and turned it into 'drag the button where you want it, click, and add an event handler... all in Windows itself.'
A lot of graphical software had commandline switches to override the videocard autodetection, "in case it failed", but this could also be used to force the software onto one monitor or another.
I ran dual-head under DesQview for quite a while. The CGA monitor whined like mad so I kept it off most of the time, but when I needed more display real estate, I'd turn it on and put my text sessions over there, leaving the graphical stuff on the VGA.
But OP is amazing to do this btw.
This was 1987. so at the time PC's were way behind in terms of the architecture needed to do this. Apple had a 24/32-bit [1] address space and an OS abstraction layer sitting in front of the graphics hardware. The closest in the PC space at the time was Windows 2.x, which ran in a 20-bit segmented real mode address space or OS/2, which nobody had. PC Video cards of the time were also hardwired to certain physical addresses, so installing two in one machine would run the risk of physically damaging hardware when the two boards both attempted to respond to a memory operation in that shared space. (The MDA was a unique case since it had its own memory window, separate from the rest.)
1] The original Mac II marked the first use of the fully 32-bit 68020 in the Macintosh. The earlier 68000 did operate internally on 32-bit addresses, but only exposed 24-bits on the package. (The 68000 was introduced in 1979, so >16MB was a fantasy.)
The net result of this is that programmers would often pack flags into the top 8 bits of a 32-bit address, with the knowledge that the hardware would just mask them off and ignore them. Since the Mac II had a fully 32-bit bus, that wouldn't work and Apple added external hardware to the CPU that would mask down to 24-bit addresses. Even the early Mac II ROM wasn't '32-bit clean' enough to run without this masking.
(PC's had a similar problem on a smaller scale. The (seg<<4)+ofs addressing scheme used in real-mode allowed 64K-16 addresses to be generated past the 1MB bound. On a chip with a 20-bit address bus (8088, etc.), these would wrap around. On a 286, they would address new memory locations. So AT class machines had masking of the A20 bit to allow them to wrap around addresses too. This masking also made its way into CPU packages, since there are implications for caching if you mask A20 and wrap the address space at 1MB.)