Date: Fri, 10 Dec 93 20:41:17 +0100
From: javier AT auto DOT isa DOT cie DOT uva DOT es (Javier Achirica)
To: djgpp AT sun DOT soe DOT clarkson DOT edu

	Hello,

	I have download djgpp 1.11, which is a really good package, and while
I've been testing it, I found a couple of bugs in the libpc.a library:

	- clrscr doesn't work as calculates the width to erase incorrectly
resulting always 1 (winright - winright + 1). Also it erases one char to the
right from where it should.

	- putch has the position arguments of the call to ScreenPutChar swapped
giving strange results.

	This are the patches to correct these problems:
----------------------------------------------------------- cut here ---------
*** gppconio.c	Fri Dec 10 20:37:22 1993
--- gppconio.new	Fri Dec 10 20:38:41 1993
***************
*** 264,273 ****
  void clrscr(void)
  {
!   short filler[txinfo.winright - txinfo.winright + 1];
    int row, col;
!   for (col=0; col < txinfo.winright - txinfo.winright + 1; col++)
      filler[col] = ' ' | (ScreenAttrib << 8);
    for (row=txinfo.wintop-1; row < txinfo.winbottom; row++)
!     dosmemput(filler, (txinfo.winright - txinfo.winright + 1)*2, VIDADDR(row, txinfo.winleft));
    gotoxy(1, 1);
  }
--- 264,273 ----
  void clrscr(void)
  {
!   short filler[txinfo.winright - txinfo.winleft + 1];
    int row, col;
!   for (col=0; col < txinfo.winright - txinfo.winleft + 1; col++)
      filler[col] = ' ' | (ScreenAttrib << 8);
    for (row=txinfo.wintop-1; row < txinfo.winbottom; row++)
!     dosmemput(filler, (txinfo.winright - txinfo.winleft + 1)*2, VIDADDR(row, txinfo.winleft - 1));
    gotoxy(1, 1);
  }
***************
*** 306,310 ****
      short   val = c | (ScreenAttrib << 8);
      /* puttext(col + 1, row + 1, col + 1, row + 1, &val); */
!     ScreenPutChar(c, ScreenAttrib, row, col);
      col++;
    }
--- 306,310 ----
      short   val = c | (ScreenAttrib << 8);
      /* puttext(col + 1, row + 1, col + 1, row + 1, &val); */
!     ScreenPutChar(c, ScreenAttrib, col, row);
      col++;
    }
----------------------------------------------------------- cut here ---------

	Also, I noticed that when the extender is running under DPMI it is not
possible to map the 1Mb DOS area at 0xE0000000 in the current selector, and it
is mapped a 0 in a new selector. Wouldn't be better to also map that area in
the 0 position in a new selector when using a non-DPMI mode? This way accessing
that memory would only be a matter of changing selectors, so routines wouldn't
need to have a temporary area and call dosmemget and dosmemput to do the
transfer, saving all the overhead involved.

	This approach, if possible, could also be used for the 0xD0000000 video
window, so there still can be a planar video window in all cases.

Sincerely,
Javier Achirica