Mail Archives: djgpp/2000/10/08/01:49:09
> From: "Peter Remmers" <Peter DOT Remmers AT t-online DOT de>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 7 Oct 2000 00:07:23 +0200
>
> Okay here we go, at the end of this posting is a minimal source code
> which should reproduce the problem, ready to be compiled.
> If anyone wants to test it, we can see if it's only on my machine
> or not. Note that it's C++ (but that doesn't matter, I tried it).
I can only say that I cannot reproduce the problem on my machine. I
compiled your source as a C program, with only two changes: I needed
to move two declarations, "char *p = buf" and "int k = 0", to the
beginning of their respective functions, to get the program to compile
as a C program.
With those changes, the program worked as expected, any key I pressed,
including the Shift, Ctrl, Alt (both left and right varieties),
NumLock, ScrollLock, normal keys, function keys--everything worked. I
couldn't wedge my machine even once.
That was on a P166 with MS-DOS 5.0, QEMM 8 as the memory manager and
CWSDPMI r4 as the DPMI host. I compiled the program with two GCC
versions: 2.7.2.1 and 2.95.2, and both programs worked correctly (I
needed to remove the `*' from "*_oldirq1" for the older compiler).
You didn't say what command line you used to compile; my compilation
command was this:
gcc -Wall -g -o kbtest kbtest.c
> // this should make DJGPP's keyboard interrupt handler
> // chain to the next ISR without doing anything itself.
> // but it doesn't help
> // __djgpp_hwint_flags |= 1;
This is redundant. __djgpp_set_ctrl_c(0) (called internally by
setmode) does this already. What I meant was actually to avoid
hooking the keyboard interrupt by the startup code, not to affect what
that interrupt handler does once it is called.
- Raw text -