NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/alt/msdos/programm/2251

Internet Message Format | 1992-08-25 | 3.8 KB

Path: sparky!uunet!olivea!news.bbn.com!usc!sdd.hp.com!elroy.jpl.nasa.gov!news.larc.nasa.gov!lll-winken!taco!dspascha
From: [e-mail] (DAVID SCOTT PASCHAL)
Newsgroups: alt.msdos.programmer
Subject: Windows and PrintScreen
Message-ID: <[e-mail]>
Date: 25 Aug 92 15:00:06 GMT
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (DAVID SCOTT PASCHAL)
Organization: North Carolina State University, Project Eos
Lines: 58
Originator: [e-mail]


Hi.  There's a lot going on about intercepting the keyboard interrupt(s) and
whether or not this would work within Windows.  So I guess I'll put in my two
cents worth:

The Windows keyboard driver completely takes over INT 9 (the keyboard interrupt)
when Windows starts up.  However, in a DOS box, keystrokes WILL get passed to
that DOS box's keyboard handler (but only in a foreground DOS box, not when a
Windows application is in the foreground).  When a key is pressed when a DOS box
is in the foreground, the following handlers are called by the Windows keyboard
driver (with some help from the keyboard VDD in 386-enhanced mode):
1. Any handlers loaded by TSR's loaded into the DOS box (but only in the DOS
box(es) it was loaded into).
2. Any handlers loaded before Windows was started (these will be active in ALL
DOS boxes).
3. The default ROM-BIOS handler.
In Enhanced mode Windows always comes in first and passes the keystroke to the
DOS box.  In Real and Standard mode I'm not sure if Windows comes in first or
after (1) above.  (Based on the fact that the system is running in real mode and
not V86 protected mode in Real and Standard modes, I would guess that Windows
would come in after (1).  However, if Windows reprograms the IRQ0-7 addresses,
then maybe it would get the keytroke first.)

Denis Beauregard wrote something to the effect that once you've hooked INT 9 you
have to handle every keystroke that comes along (having the effect of being
"stuck" with English-language drivers or what not).  This is not quite so.
Unless this is specifically what you want to do, you should only consume the
keystrokes you want (i.e. if it's "your" hotkey) -- otherwise, you should pass
the keystroke to the previous INT 9 handler.

I have written a little TSR that allows me to enter German characters from my
American keyboard, and I have never had any problems using this feature (which
is loaded in AUTOEXEC.BAT) in DOS boxes.

There is another wrinkle to this: On PS/2 BIOSes and many recent clone BIOSes,
you can hook INT 15h function 4Fh instead of INT 9 -- The ROM-BIOS calls this
from its INT 9 handler after it's gotten a scan code from the keyboard, and
your 15/4F handler can either ignore the keystroke (passed in AL) and chain
to the previous INT 15 handler, modify the keystroke (pass a new one in AL) and
chain to the previous INT 15 handler, or consume the keystroke and do an IRET
instead of chaining to the previous INT 15 handler.  Whether or not to keep or
discard the keystroke depends on the state of the carry flag when the ROM-BIOS
regains control after the INT 15h instruction (But since I don't have any docs
on me right now, I can't tell you which setting of the carry flag means whether
to discard the keystroke or keep the keystroke and try to turn it into a
character.)

So anyway, regarding writing a PutBackPrintScreen program, I would say try to
write an INT 9 handler that captures PrintScreen and invokes the ROM-BIOS's
INT 5 handler.  See if the PIF settings will let you "reserve PrintScreen for
the DOS application".  On the other hand, you could define another keystroke
(like alt-scrolllock or something) that invokes PrintScreen.  That might be
your better bet.

I hope this helps.

Tschuess, (Sorry, Compose-Character doesn't seem to work on these DECstations!)
David :-)