CMD.EXE - a bug (and one of mine fixed!)

Lets get my embarrassment out of the way first. The last
release of CRiSP for Windows (11.0.29) contained a silly bug.
The installer defaulted to "C:\Program Files" instead of
"C:\Program Files\CRiSP". After people mentioned that the install
was going to the wrong choice of "Program Files" vs "Program Files (x86)",
I switched to using %ProgramFiles% so that the C runtime and Win API
would do the right thing - depending whether you installed win32 or win64
version of CRiSP.

I had been delaying resolving an issue with the uninstaller, which
had been failing to remove the final registry entry - due to the
fact that the setup.exe tool was distinguishing between a win32 vs
a win64 install. (CRiSP still comes as a Win32 or Win64 application,
despite all Windows systems supporting 64-bit as default; theres no real
need for the 32-bit version, except it may be 0.5% faster or smaller
in memory use; CRiSP will mostly fit into the L2 CPU cache).

As a reminder for history, CRiSP started life on an 80286 Unix system
and was ported to Windows 3.1! Much of the internal structure hasnt
changed in all these years, except to improve the bugs and the
GUI.

Since we are talking about Windows, someone posted an issue on CRiSP
and on investigation, its a bug in CMD.EXE. Very amazing. CMD.EXE
is so old - dating back to Windows NT 3.51, and before. Its a bizarre
application because it lets you have an MS-DOS style console window
and supports a console API for DOS like apps. "CR.EXE" uses that
to give the same BRIEF look'n'feel dating back to the early 1990s.

But a bug report - in 2014 ?!

CRiSP has a feature to display "[EOF]" as the last line in the file.
You can turn it on (e.g. "set eof" at the Command: prompt). It displays
in reverse video.

If CRiSP window borders are turned off (Alt-F1), then you will likely
notice strange lines on the screen as you scroll around.

This is being caused because when in reverse video, CMD.EXE is adding
one extra pixel to the left and right of the marked region. You
can see this effect by compiling and running the following test
program. The "[EOF]" is shown at line 10 and 12 of the console.
If you arrange to enter text at the C:\ prompt as you get near
to the "[EOF]" you will see the extra pixel disappear. Its easier to use
a tool like ZOOMIN.EXE or "xmag" on Unix, to examine closerly at the
delta.

Of course, CMD.EXE's bug is my bug, so I get to fix it, despite almost
no-one in the known universe caring about this, except people who
use CR.EXE (including myself).

Makes your heart bleed, doesnt it?!

#include <windows.h>

int main(int argc, char **argv)
{	int	i, j;
	HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
	int	num_written;
	COORD coord;
	WORD	attribs[80];

	for (j = 0; j < 2; j++) {
		coord.X = 30;
		coord.Y = 10 + 2 * j;

		WriteConsoleOutputCharacter(h,
			"[EOF]", 5, coord, &num_written);

		attribs[0] = FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE | BACKGROUND_GREEN;
		attribs[0] = BACKGROUND_GREEN | BACKGROUND_INTENSITY;
		if (j == 1)
			attribs[0] = BACKGROUND_GREEN ;
		for (i = 1; i < 5; i++)
			attribs[i] = attribs[0];
		WriteConsoleOutputAttribute(h, attribs, 5, coord, &num_written);
		}
}
c:\> cl test.c
c:\> cls
c:\> test

Post created by CRiSP v11.0.30a-b6722