Grzyb wrote on 2024-05-27, 01:45:
But they are different stunts?
Yes, that's right.
Grzyb wrote on 2024-05-27, 01:45:
Windows/386 uses V86 mode, and there's nothing special about V86 virtual machines running *any* DOS program in a window.
Yes. Windows/386 is similar to Windows 3.0 here.
Grzyb wrote on 2024-05-27, 01:45:
On an 8088, however, it's only possible with software that displays stuff using BIOS/DOS calls only - which pretty much excludes anything graphical.
That's were Windows 2.x differs from Windows 3, I believe.
Not sure how to put into words, but Windows 2.x and the Windows 2.x drivers are able to grab/trap video data.
So an DOS application ends up drawing into a window rather than the graphics card.
There's an API function especially for making this possible, I believe. But it's all limited to CGA, I think.
This might also be because CGA is a graphics standard that's below the host's native video standard (such as VGA).
CGA with its tiny 16KB (32KB with duplicate) frame bufffer also fits within a an x86 segment (64KB), so no bank-switching is being needed.
EGA would be much more larger and complicated to support, I suppose. It would also consume more memory.
Another factor is that CGA is part of PC BIOS. So maybe that's why it's a bit special, also.
It's being highly standardized and nearly all applications in the 1980s had supported it, even if it merely was as a fallback.
In addition, many DOS programs did work on pseudo-CGA graphics (no Motorola 6845).
Even without support at the register level, programs usually ran.
That being said, I've seen screenshots of CGA games on Windows 2.x showing alternate CGA palettes..
So I'm not exactly sure how far Windows 2.x exactly goes into simulating CGA to applications.
Hm. That being said, I think on Windows 3.x, we'd talk about a grabber functionality maybe.
Windows 3.x has a grabber driver in system.ini being mentioned.
Sometimes, a 386 grabber is being mentioned, too, for the Enhanced-Mode kernal.
Edit: I would really have to check.. It's early in the morning right now and I'm still a bit sleepy. 😴
Edit: What also comes to mind, both CGA and VGA have an overlap in their frame buffer location (it's backwards compatible to CGA, after all).
A bit similar to how CGA and Hercules do have (under certain circumstances).
So if a Windows VGA driver is written appropriately, it might be possible to have the CGA frame buffer being left untouched.
So there's no actual trapping being needed, maybe. Because there's physical RAM available, I mean.
The CGA application would write into CGA frame buffer as normally, then the Windows driver reads the video data and then Windows 2.x would draw it on screen.
It's just a wild guess, of course. On the other hand, VGA is being very programmable. 🤷♂️
VGA also uses A segment mainly, whereas CGA uses upper end of B segment.
Edit: What's also interesting, Windows 2.x seems to use 8 colours in EGA/VGA, rather than 16 colours.
So maybe this makes it possible to get along with less video memory, not sure. Again, it's just an idea.
Edit: Screenshots attached.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//