How to invert screen colors on Windows 1.01?

[DVINTHEHOUSEMAN]

I have recently bought an IBM 5140 PC Convertible, and installed Windows 1.01 on it. Since the screen colors are inverted, the OS looks horrible. I have inverted the color scheme, but it’s not contiguous through the whole OS, such as icons and some graphical apps such as Paint, Calculator, or Calendar show inverted of how they should look. Is there a driver or way to invert the whole screen, including icons and apps, in Windows when it is running so it looks normal? If there is, please let me know.

[Overdoze]

It may be possible the swap the foreground and background colors at the driver level (CGA.DRV) to achieve this.

[DVINTHEHOUSEMAN]

How would I do that?

[Overdoze]

I guess disassemble the driver with IDA Pro, see how it configures the card and if it's possible to change the background.

[John Elliott]

I had a quick go the last time this question was asked, but it's not simple. I hoped it would just be a matter of rewriting RealizeObject to map dark colours to white and light colours to black, but it isn't. It also needs a rewrite of the logic operations in BitBlt and StrBlt - painting done with OR instead of AND or vice versa, and it might be necessary to insert extra XOR instructions to invert mask bytes.

If we had the source code it might just be a matter of flipping an equate somewhere and letting the build process generate the appropriate code (in GEM it was just a matter of setting rev_vid to false and recompiling). But starting with a disassembly is a lot harder - not only do you have to do a lot of work to go from the disassembly to something that builds to the original driver, you then have to gain a thorough understanding of what the code is doing so you know which areas to change. And with Windows 1.01 still under copyright, the legal environment is less friendly, too.

From my point of view Windows drivers are tougher to understand than GEM drivers, because they have to support drawing on bitmaps as well as on the screen, so there are extra code paths all over the place. And they're more like hand-compiled C than assembly, with variables all on the stack rather than in the data segment, which my ancient freeware version of IDA can't cope with.

[DVINTHEHOUSEMAN]

Oh. I’m not very experienced with code disassembly, or with Windows 1.x drivers, so it might just be a lost cause.

[Tootles]

A thought I had after I gave up trying with my Amstrad (upgraded to a 286) to get it working was maybe a TSR in DOS to intercept the driver's draw commands and invert them. But I don't have the programming chops for that.

[John Elliott]

On a dumb framebuffer device like a CGA, there are no 'draw commands' you can hook - the driver just reads and writes bytes in video RAM or an offscreen bitmap. The closest you could come is doing something with the single-step interrupt to check every single instruction to see if it's a read/write to video RAM. But that would really slow things down.