Subject: comp.os.msdos.programmer FAQ part 2 of 4
Newsgroups: comp.os.msdos.programmer,comp.answers,news.answers

Archive-name: msdos-programmer-faq/part2
Last-modified: 24 Sep 1993

(continued from part 1)         (no warranty on the code or information)

If the posting date is more than six weeks in the past, see instructions
at the end of this article for how to get an updated copy.

Copyright (C) 1993  Stan Brown, Oak Road Systems.  All rights reserved.

section 1. General questions
============================

Subject:  101. Why won't my code work?

    First you need to try to determine whether the problem is in your
    use of the programming language or in your use of MSDOS and your PC
    hardware.  (Your manual should tell you which features are standard
    and which are vendor- or MSDOS- or PC-specific.  You _have_ read
    your manual carefully, haven't you?)

    If the feature that seems to be working wrong is something related
    to your PC hardware or to the internals of MS-DOS, this group is the
    right place to ask.  (Please check this FAQ list first, to make sure
    your question isn't already answered here.)

    On the other hand, if your problem is with the programming language,
    the comp.lang hierarchy (including comp.lang.pascal and comp.lang c)
    is probably a better resource.  Please read the other group's FAQ
    list thoroughly before posting.  (These exist in comp.lang.c,
    comp.lang.c++, comp.lang.modula3, comp.lang.lisp, comp.lang.perl;
    they may exist in other groups as well.)  It's almost never a good
    idea to crosspost between this group and a language group.

    Before posting in either place, try to make your program as small as
    possible while still exhibiting the bad behavior.  Sometimes this
    alone is enough to show you where the trouble is.  Also edit your
    description of the problem to be as short as possible.  This makes
    it look more like you tried to solve the problem on your own, and
    makes people more inclined to try to help you.  See later in this
    section for some important netiquette tips.

Subject:  102. What is this newsgroup about?

    (rev: 11 Sep 1993) comp.os.msdos.programmer (comp.sys.ibm.pc.programmer
    until September 1990) concerns programming for MS-DOS systems.  The
    article "USENET Readership report for Aug 93" in news.lists shows
    78,000 readers of this newsgroup worldwide.  Traffic (exclusive of
    crossposts) was 813 articles aggregating 1604 Kbytes.

    Much of our traffic is about language products (chiefly from Borland
    and Microsoft).  More programming topics focus on C than on any one
    other language, but we are not just for C programmers (see next Q).

    Since most MS-DOS systems run on hardware that is roughly compatible
    with the IBM PC, on Intel 8088, 80188, or 80x86 chips, we tend to
    get a lot of questions and answers about programming other parts of
    the hardware.

Subject:  103. Is comp.os.msdos.programmer just for C programmers?

    (new: 12 Aug 1993)  No, it is for all programmers who to share
    information about programming in MS-DOS.  Programs and questions are
    also posted in Pascal, assembly, and other languages (including
    MS-DOS batch programming.)

    Why does the newsgroup seem to be so C-oriented sometimes?  There
    are two reasons.  First, comp.lang.c and comp.lang.pascal have
    evolved in different directions.  comp.lang.pascal welcomes
    vendor-specific discussion, such as Turbo Pascal.  Since so many of
    TP's features are tailored to programming on PCs and in MS-DOS,
    Turbo Pascal programmers tend to find DOS questions welcomed there,
    so that comp.os.msdos.programmer gets less of the "DOS in Turbo
    Pascal" traffic.  On the other hand, comp.lang.c has stayed closer
    to talking only about the C language, and vendor-specific or
    operating-system-specific questions are not welcome.  This tends to
    push questions about disks, DOS file structure, video, the keyboard,
    TSRs, etc. to c.o.m.p even when those programs are written in C.

    This FAQ is definitely C-oriented, not because that's necessarily
    best but because the original editor tried to stick to what he could
    verify personally.  As a C programmer (with some assembler), he
    could most carefully verify solutions in C or assembler.  He felt
    that short, clear programs could be published in just one language
    and programmers could translate them into their languages of choice.
    But the FAQ list also contains several long programs written only in
    C; this is a defect with no obvious remedy.  Most answers that point
    to source code at archive sites include both C- and Pascal-language
    source when available; please draw any omissions to the editor's
    attention.

Subject:  104. What's the difference from comp.sys.ibm.pc.programmer?

    c.s.i.p.programmer is the old name of comp.os.msdos.programmer, and
    has been obsolete since September 1990.  However, many systems have
    not removed the old group, or have removed it but aliased it to the
    new name.  This means that some people still think they're posting
    to c.s.i.p.programmer even though they're actually posting to
    c.o.m.programmer.

    You can easily verify the non-existence of c.s.i.p.programmer by
    reference to the "List of Active Newsgroups" posted to news.groups.
    It's available as /pub/usenet/news.answers/active-newsgroups/part1
    from the archives (see "Where are FAQ lists archived?" in section C,
    "More information").

Subject:  105. Is comp.os.msdos.programmer available as a mailing list?

    (new: 2 Feb 1993)  Sorry, no.

Subject:  106. What's this "netiquette"?

    (new: 7 Aug 1993)  Netiquette is good Usenet etiquette.  It includes
    basic rules like the following; see also the next Q.

    - Always read a newsgroup for a reasonable time before you post an
      article to it.

    - Pick the one right group for your article; don't crosspost unless
      absolutely necessary.  If you absolutely must post an article to
      more than one group, do crosspost it and don't post the same
      article separately to each group.

    - Before you post a question, make sure you're posting to the right
      newsgroup--the best way to do that is to observe the preceding
      rule.  Check the group's FAQ list (if it has one) to make sure
      that your question isn't already answered there.  See "Where are
      FAQ lists archived?" in section C, "More information".

    - When you post a question, if you ask for email responses then
      promise to post a summary.  Keep your promise.  And make it a
      real summary: don't just append all the email you got.  Instead,
      write your own (brief) description of the solution:  this is the
      best way to make sure you really understand it.

    - Before you post a follow-up, read the other follow-ups.  Very
      often you'll find that someone else has already made the point you
      had in mind.

    - When someone posts a question, if you want to know the answer
      don't post a "me, too".  Instead send email to the poster asking
      him or her to share responses with you.

    - When posting a follow-up to another posted article, remove all
      headers and signature lines from the old article; just keep the
      line "In <article>, so-and-so writes:".  Also cut the original
      article down as much as possible; just keep enough of it to remind
      readers of the context.

    - Keep lines in posted articles to 72-75 characters.  Many
      newsreaders chop off column 81 or arbitrarily insert a newline
      there, which makes longer lines difficult or impossible to read.
      But you need to keep well below 80 characters per line to allow
      for the > characters that get inserted when other people post
      follow-ups to your article.

    - Keep your signature to 4 lines or less (including any graphics),
      and for heaven's sake make sure it doesn't get posted twice in
      your article.

    - Don't post email without first obtaining the permission of the
      sender.

Subject:  107. How can I learn more about Usenet?

    (new: 7 Aug 1993)  There are two important newsgroups for learning
    about how Usenet and newsreader software works:

    - news.announce.newusers contains periodic postings that everybody
      is asked to read before posting anything to Usenet.  (In theory,
      all new users are subscribed to news.announce.newusers
      automatically.  But in practice not all newsreader software does
      that, so that many people violate the guidelines given there
      simply because they don't know about them.)

    - news.newusers.questions is described as "Q & A for users new to
      the Usenet".  But new and long-time users can ask or answer
      questions about Usenet and newsreader software there.  There's an
      important article, "Welcome to news.newusers.questions! (weekly
      posting)", that everyone is asked to read before posting to
      news.newusers.questions.  (See below for ways to get a copy of
      that article.)

    The following postings in news.announce.newusers might be considered
    the "mandatory course" for new users:

        Introduction to news.announce.newusers
        What is Usenet?
        Answers to Frequently Asked Questions
        Rules for posting to Usenet
        A Primer on How to Work With the Usenet Community
        Hints on writing style for Usenet
        Emily Postnews Answers Your Questions on Netiquette

    The articles mentioned above are downloadable via ftp from
    rtfm.mit.edu in the following files:

        /pub/usenet/news.answers/news-newusers-intro
                Welcome to news.newusers.questions! (weekly posting)
        /pub/usenet/news.answers/news-announce-intro/part1
                Introduction to news.announce.newusers
        /pub/usenet/news.answers/what-is-usenet/part1
                What is Usenet?
        /pub/usenet/news.answers/usenet-faq/part1
                Answers to Frequently Asked Questions
        /pub/usenet/news.answers/posting-rules/part1
                Rules for posting to Usenet
        /pub/usenet/news.answers/usenet-primer/part1
                A Primer on How to Work With the Usenet Community
        /pub/usenet/news.answers/usenet-writing-style/part1
                Hints on writing style for Usenet
        /pub/usenet/news.answers/emily-postnews/part1
                Emily Postnews Answers Your Questions on Netiquette

    They are also available from the mail server whose address is
    [email-masked].  Send a message containing one or more
    "send" command lines such as

        send usenet/news.answers/news-newusers-intro

    The "send" filenames are the same as the ftp filenames except the
    "/pub" at the beginning is omitted.  To get general information
    about the mail server, send it a message containing "help".

Subject:  108. What other technical newsgroups should I know about?

    (rev: 16 Aug 1993)  Caution:  Some of these newsgroups have
    specialized charters; you'll probably get (and deserve) some flames
    if you post to an inappropriate group.  Most groups have FAQ lists
    that will tell you what's appropriate.  Don't post a request for the
    FAQ list; instead, retrieve it yourself--see "Where are FAQ lists
    archived?", in section C, "More information".

    - misc.forsale.computers.d and misc.forsale.computers.pc-clone are
      where you post notices of equipment, software, or computer books
      that you want to sell.  Please don't post or crosspost those
      notices to comp.os.msdos.programmer.

    - comp.os.ms-windows.programmer.tools and ...misc (formerly part of
      comp.windows.ms.programmer):  Similar to this group, but focus
      on programming for the MS-Windows platform.

    - comp.sys.ibm.pc.hardware is for more hardware-oriented discussions
      of the machines that run DOS.

    - the various comp.lang.* groups for articles and questions on the
      programming languages.  Caution:  some groups welcome discussions
      that are operating-system dependent or vendor specific; others do
      not.  For example, comp.lang.c is definitely _not_ for questions
      about programming DOS or PC system features, even if the programs
      are written in C.  On the other hand, comp.lang.pascal contains
      much discussion that is specific to Turbo Pascal.

    - comp.binaries.ibm.pc.wanted: AFTER you have looked in the other
      groups, this is the place to post a request for a particular
      binary program.

    - comp.archives.msdos.announce (moderated) explains how to use the
      archive sites, especially Garbo and Simtel, and lists files
      uploaded to them.  Discussions belong in comp.archives.msdos.d,
      which replaced comp.binaries.ibm.pc.archives in December 1992.

    - MSDOS-Ann mailing list, for those who cannot subscribe to the
      comp.archives.msdos.announce newsgroup, lists Simtel and Garbo
      uploads in digest format.  Instructions are downloadable as
        /pc/MSDOSANN.ZIP from Garbo
        pd1:<msdos.info>msdosann.zip from Simtel.

    - comp.binaries.ibm.pc.d is for discussions about programs posted in
      comp.binaries.ibm.pc, and only those programs.  This is a good
      place to report bugs in the programs, but not to ask where to find
      them (see cbip.wanted, above).  cbip.d is NOT supposed to be a
      general PC discussion group.

    - comp.sources.misc: a moderated group for source code for many
      computer systems.  It tends to get lots of Unix stuff, but you may
      also pick up some DOS-compatible code here.

    - alt.sources: an unmoderated group for source code.  Guidelines are
      posted periodically.

    - Turbo Vision is a mailing list, not a newsgroup; send email to
      [email-masked] if you want to subscribe.

section 2. Compile and link
===========================

Subject:  201. What the heck is "DGROUP > 64K"?

    (rev: 18 Apr 1993) DGROUP is a link-time group of data segments, and
    the compiler typically generates code that expects DS to be pointing
    to DGROUP.  (Exception:  Borland's huge model has no DGROUP.)

    Here's what goes into DGROUP:

    - tiny model (all pointers near):  DGROUP holds the entire program.

    - small and medium models (data pointers near):  DGROUP holds all
      globals and static variables including string literals, plus the
      stack and the heap.

    - large, compact, and huge models in Microsoft (data pointers far):
      DGROUP holds only initialized globals and static variables
      including string literals, plus the stack and the near heap.

    - large and compact models in Borland (data pointers far): DGROUP
      holds initialized and uninitialized globals and static variables
      including string literals, but not the stack or heap.

    - huge model in Borland (data pointers far): there is no DGROUP, so
      the 64K limit doesn't apply.

    In all of the above, which is to say all six models in Microsoft C
    and all but huge in Borland C, DGROUP is limited to 64K including
    string literals (which are treated as static data).  This limitation
    is due to the Intel CPU's segmented architecture.

    See the next Q for possible remedies.

    For more information, see topics like "memory models" and "memory
    management" in the index of your compiler manual.  Also see
    ti738.asc, downloadable as part of
        pd1:<msdos.turbo-c>bchelp10.zip at Simtel
        /pc/turbopas/bchelp10.zip at Garbo,
    for an extended general discussion of memory usage in Borland C
    programs, of which much applies to any C compiler in DOS.

Subject:  202. How do I fix "automatic data segment exceeds 64K" or
               "stack plus data exceed 64K"?

    These messages are a variation of "DGROUP > 64K".  For causes,
    please see the preceding Q.

    If you get this error in tiny model, your program is simply too big
    and you must use a different memory model.  If you get this link
    error in models S, C, M, L, or Microsoft's H, there are some things
    you can do.  (This error can't occur in Borland's huge model.)

    If you have one or two big global arrays, simply declare them far.
    The compiler takes this to mean that any references to them will use
    32-bit pointers, so they'll be in separate segments and no longer
    part of DGROUP.

    Or you can use the /Gt[number] option with Microsoft or -Ff[=size]
    with Borland C++ 2.0 and up.  This will automatically put variables
    above a certain size into their own segments outside of DGROUP.

    Yet another option is to change global arrays to far pointers.  Then
    at the beginning of your program, allocate them from the far heap
    (_fmalloc in Microsoft, farmalloc in Borland).

    Finally, you can change to huge model (with Borland compilers, not
    Microsoft).  Borland's H model still uses far pointers by default,
    but "sets aside the [64K] limit" and has no DGROUP group, according
    to the BC++ 2.0 Programmer's Guide.  Microsoft's H model does use
    huge data pointers by default but retains DGROUP and its 64K limit,
    so switching to the H model doesn't buy you anything if you have
    DGROUP problems.

Subject:  203. Will Borland C code and Microsoft C code link together?

    (rev: 15 Aug 1993)  Typically this question is asked by someone who
    owns compiler A and is trying to write code to link with a
    third-party library that was compiled under compiler B.

    The answer to the question is, Not in general.  Here are some of the
    reasons:

    - "Helper" functions (undocumented functions for stack checking,
      floating-point arithmetic, and operations on longs) differ between
      the two compilers.

    - The compilers may embed instructions in the object code that tell
      the linker to look for their own run-time libraries.  You can use
      the linker option that says to ignore such instructions:  /n in
      TLINK, /NOD in the Microsoft linker (the one that comes with the C
      compiler, not the one that used to come with DOS).  But getting
      around this problem will very likely just reveal other problems,
      like different helper functions, that have no easy solution.

    Those problems will generate link-time errors.  Others may not show
    up until run time:

    - Borland's compact, large, and huge models don't assume DS=SS, but
      Microsoft's do.  The -Fs option on the Borland compiler, or one of
      the /A options on Microsoft, should take care of this problem --
      once you know that's what's going on.

    - Check conventions for ordering and packing structure members, and
      for alignment of various types on byte, word, paragraph, or other
      boundaries.  Again, you can generally adjust your code to match if
      you know what conventions were used in compiling the "foreign"
      libraries.

    - Check the obvious and make sure that your code was compiled under
      the same memory model as the code you're trying to link with.
      (That's necessary, but no guarantee.  Microsoft and Borland don't
      use exactly the same conventions for segments and groups,
      particularly in the larger memory models.)

    That said, there are some circumstances where you can link hybrids.
    Your best chance of success comes if you compile in large model with
    the compiler switch that says to reload DS on entry to each
    function, avoid longs and floating point, use only 16-bit pointers,
    suppress stack checking, and specify all libraries used in the link.

Subject:  204. Why did my program bomb at run time with "floating point
               formats not linked"?

    First, is that the actual message, or did it say "floating point not
    loaded"?  If it was the latter, see the next Q.

    You're probably using a Borland compiler for C or C++ (including
    Turbo C and Turbo C++).  Borland's compilers try to be smart and not
    link in the floating-point (f-p) library unless you need it.  Alas,
    they all get the decision wrong.  One common case is where you don't
    call any f-p functions, but you have %f or other f-p formats in
    scanf/printf calls.  The cure is to call an f-p function, or at
    least force one to be present in the link.

    To do that, define this function somewhere in a source file but
    don't call it:

        static void forcefloat(float *p)
            { float f = *p; forcefloat(&f); }

    It doesn't have to be in the module with the main program, as long
    as it's in a module that will be included in the link.

    If you have Borland C++ 3.0, the README file documents a slightly
    less ugly work-around.  Insert these statements in your program:

        extern unsigned _floatconvert;
        #pragma extref _floatconvert

Subject:  205. Why did my program bomb with "floating point not loaded"?

    That is Microsoft C's run-time message when the code requires a
    numeric coprocessor but your computer doesn't have one installed.

    If the program is yours, relink it using the xLIBCE or xLIBCA
    library (where x is the memory model).

Subject:  206. How can I change the stack size in Borland's C compilers?

    In Turbo C, Turbo C++, and Borland C++, you may not find "stack
    size" in the index but the global variable _stklen should be there.
    The manual will instruct you to put a statement like

        extern unsigned _stklen = 54321U;

    in your code, outside of any function.  You must assign the value
    right in the extern statement; it won't work to assign a value at
    run time.  (The "extern" in this context isn't ANSI C and ought not
    to be required, but the above statement is a direct quote from the
    Library Reference manual of Borland C++ 2.0.)  The linker may give
    you a duplicate symbol warning, which you can ignore.

Subject:  207. What's the format of an .OBJ file?

    (rev: 24 Sep 1993)

    - base .OBJ format:  Intel's document number #121748-001, {8086
      Relocatable Object Module Formats}.  (not verified)

    Both Microsoft and Borland have extended the .OBJ format, as has IBM
    for OS/2; and according to the MS-DOS encyclopedia, Microsoft
    doesn't actually use all the listed formats.

    - Microsoft-specific .OBJ formats:

      * The .OBJ format document dated 14 Dec 1992, a WinHelp file from
        the Microsoft developer's CD-ROM (266K after unzipping), is
        downloadable as /vendor/microsoft/developer-network/ctech/11-9.zip
        from ftp.uu.net. (verified by SB)

      * A 45-page article can be found in the {MS-DOS Encyclopedia},
        ISBN 1-55615-049-0 (verified by SB), now out of print.

      * "Microsoft Object Module Format (OMF)" Specification, 22 Nov 1991,
        was published by the Microsoft Languages Group.  (not verified)

    - Borland-specific .OBJ formats:  Open Architecture Handbook.  The
      Borland Developer's Technical Guide, 1991, no ISBN.  Chapter 2,
      "Object file contents", (pages 27-50) covers the comment records
      sent to the object file by Borland C++ version 3.0 and other
      Borland compilers.  The comment records mostly contain information
      for the Borland debugger. (not verified)

    - A "tutorial on the .OBJ format" comes with the VAL experimental
      linker, downloadable as
        pd1:<msdos.pgmutl>val-link.arc at Simtel
        /pc/assembler/linker.zoo at Garbo.
      Despite such different names, those files have the same contents,
      but their contents are dated 18 Feb 1989.  You'd be better off
      with one of the more recent references listed above.

Subject:  208. What's the format of an .EXE header?

    See pages 349-350 of {PC Magazine} 30 June 1992 (xi:12) for the old
    and new formats.  For a more detailed layout, look under INT 21
    function 4B in Ralf Brown's interrupt list.  Ralf Brown's list
    includes extensions for Borland's TLINK and Borland debugger info.

    Among the books that detail formats of executable files are {DOS
    Programmer's Reference: 2d Edition} by Terry Dettman and Jim Kyle,
    ISBN 0-88022-458-4; and {Microsoft MS-DOS Programmer's Reference},
    ISBN 1-55615-329-5.

Subject:  209. What's the difference between .COM and .EXE formats?

    To oversimplify:  a .COM file is a direct image of core, and an .EXE
    file will undergo some further relocation when it is run (and so it
    begins with a relocation header).  A .COM file is limited to 64K for
    all segments combined, but an .EXE file can have as many segments as
    your linker will handle and be as large as RAM can take.

    The actual file extension doesn't matter.  DOS knows that a file
    being loaded is in .EXE format if its first two bytes are MZ or ZM;
    otherwise it is assumed to be in .COM format.  For instance, DR-DOS
    6.0's COMMAND.COM is in .EXE format.

section 3. Keyboard
===================

Subject:  301. How can I read a character without echoing it to the
               screen, and without waiting for the user to press the
               Enter key?

    The C compilers from Microsoft and Borland offer getch (or getche to
    echo the character); Turbo Pascal has ReadKey.

    In other programming languages, load 8 in register AH and execute
    INT 21; AL is returned with the character from standard input
    (possibly redirected).  If you don't want to allow redirection, or
    you want to capture Ctrl-C and other special keys, use INT 16 with
    AH=10; this will return the scan code in AH and ASCII code (if
    possible) in AL, except that AL=E0 with AH nonzero indicates one of
    the grey "extended" keys was pressed.  (If your BIOS doesn't
    support the extended keyboard, use INT 16 function 0 not 10.)

Subject:  302. How can I find out whether a character has been typed,
               without waiting for one?

    In Turbo Pascal, use KeyPressed.  Both Microsoft C and Turbo C offer
    the kbhit( ) function.  All of these tell you whether a key has been
    pressed.  If no key has been pressed, they return that information
    to your program.  If a keystroke is waiting, they tell your program
    that but leave the key in the input buffer.

    You can use the BIOS call, INT 16 function 01 or 11, to check
    whether an actual keystroke is waiting; or the DOS call, INT 21
    function 0B, to check for a keystroke from stdin (subject to
    redirection).  See Ralf Brown's interrupt list.

Subject:  303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del?

    (rev: 11 Sep 1993)  Several utilities are downloadable from
    pd1:<msdos.keyboard> at Simtel.  In that directory, cadel.zip
    contains a TSR (with source code) to disable those keys.  Also,
    keykill.arc contains two utilities:  keykill.com lets you disable up
    to three keys of your choice, and deboot.com changes the boot key to
    leftShift-Alt-Del.

    C programmers who simply want to make sure that the user can't
    Ctrl-Break out of their program can use the ANSI-standard signal( )
    function; the Borland compilers also offer ctrlbrk( ) for handling
    Ctrl-Break.  However, if your program uses normal DOS input such as
    getch( ), ^C will appear on the screen when the user presses Ctrl-C
    or Ctrl-Break.  You can avoid the ^C echo for Ctrl-C by using
    _bios_keybrd( ) in MSC or bioskey( ) in BC++; however, Ctrl-Break
    will still terminate the program.

    An alternative approach involves programming input at a lower level.
    You can use INT 21 function 7, which allows redirection but doesn't
    echo the ^C (or any other character, for that matter); or use INT 16
    function 0 or 10; or hook INT 9 to discard Ctrl-C and Ctrl-Break
    before the regular BIOS keyboard handler sees them; etc., etc.

    You should be aware that Ctrl-C and Ctrl-Break are processed quite
    differently internally.  Ctrl-Break, like all keystrokes, is
    processed by the BIOS code at INT 9 as soon as the user presses the
    keys, even if earlier keys are still in the keyboard buffer:  by
    default the handler at INT 1B is called.  Ctrl-C is not special to
    the BIOS, nor is it special to DOS functions 6 and 7; it _is_
    special to DOS functions 1 and 8 when at the head of the keyboard
    buffer.  You will need to make sure BREAK is OFF to prevent DOS
    polling the keyboard for Ctrl-C during non-keyboard operations.

    Some good general references are {Advanced MS-DOS} by Ray Duncan,
    ISBN 1-55615-157-8; {8088 Assembler Language Programming:  The IBM
    PC}, ISBN 0-672-22024-5, by Willen & Krantz; and {COMPUTE!'s Mapping
    the IBM PC}, ISBN 0-942386-92-2.

Subject:  304. How can I disable the print screen function?

    There are really two print screen functions:  1) print current
    screen snapshot, triggered by PrintScreen or Shift-PrtSc or
    Shift-grey*, and 2) turn on continuous screen echo, started and
    stopped by Ctrl-P or Ctrl-PrtSc.

    1) Screen snapshot to printer

    The BIOS uses INT 5 for this.  Fortunately, you don't need to mess
    with that interrupt handler.  The standard handler, in BIOSes dated
    December 1982 or later, uses a byte at 0040:0100 (alias 0000:0500)
    to determine whether a print screen is currently in progress.  If it
    is, pressing PrintScreen again is ignored.  So to disable the screen
    snapshot, all you have to do is write a 1 to that byte.  When the
    user presses PrintScreen, the BIOS will think that a print screen is
    already in progress and will ignore the user's keypress.  You can
    re-enable PrintScreen by zeroing the same byte.

    Here's some simple code:

        void prtsc_allow(int allow) /* 0=disable, nonzero=enable */ {
            unsigned char far* flag = (unsigned char far*)0x00400100UL;
            *flag = (unsigned char)!allow;
        }

    2) Continuous echo of screen to printer

    If ANSI.SYS is loaded, you can easily disable the continuous echo of
    screen to printer (Ctrl-P or Ctrl-PrtSc).  Just redefine the keys by
    "printing" strings like these to the screen (BASIC print, C printf,
    Pascal Write statements, or ECHO command in batch files):

        <27>[0;114;"Ctrl-PrtSc disabled"p
        <27>[16;"^P"p

    Change <27> in the above to an Escape character, ASCII 27.

    If you haven't installed ANSI.SYS, I (SB) can't offer an easy way to
    disable the echo-screen-to-printer function.  Please send any tested
    solutions to the editor.

    Actually, you might not need to disable Ctrl-P and Ctrl-PrtSc.  If
    your only concern is not locking up your machine, when you see the
    "Abort, Retry, Ignore, Fail" prompt just press Ctrl-P again and then
    I.  As an alternative, install one of the many print spoolers that
    intercept printer-status queries and always return "Printer ready".

Subject:  305. How can my program turn NumLock (CapsLock, ScrollLock)
               on or off?

    First, if you just don't want NumLock turned on when you reboot,
    check your system's setups.  (Use Ctrl-Alt-Enter any time, or press
    a special key like Del at boot time, or run the setup program
    supplied with your system.)  Many systems now have an option in
    setup to turn NumLock off at boot time.

    You need to twiddle bit 5, 6, or 4 of location 0040:0017.  Here's
    some code:  lck( ) turns on a lock state, and unlck( ) turns it off.
    (The status lights on some keyboards may not reflect the change.  If
    yours is one, call INT 16 function 2, "get shift status", and that
    may update them.  It will certainly do no harm.)

        #define NUM_LOCK  (1 << 5)
        #define CAPS_LOCK (1 << 6)
        #define SCRL_LOCK (1 << 4)
        void lck(int shiftype) {
            char far* kbdstatus = (char far*)0x00400017UL;
            *kbdstatus |= (char)shiftype;
        }
        void unlck(int shiftype) {
            char far* kbdstatus = (char far*)0x00400017UL;
            *kbdstatus &= ~(char)shiftype;
        }

Subject:  306. How can I speed up the keyboard's auto-repeat?

    The keyboard speed has two components: delay (before a key that you
    hold down starts repeating) and typematic rate (the speed once the
    key starts repeating).  Most BIOSes since 1986 let software change
    the delay and typematic rate by calling INT 16 function 3, "set
    typematic rate and delay"; see Ralf Brown's interrupt list.  If you
    have DOS 4.0 or later, you can use the MODE CON command that you'll
    find in your DOS manual.

    On 83-key keyboards (mostly XTs), the delay and typematic rate can't
    easily be changed.  According to the {PC Magazine} of 15 Jan 1991,
    page 409, to adjust the typematic rate you need "a memory-resident
    program which simply '[watches]' the keyboard to see if you're
    holding down a key ... and after a certain time [starts] stuffing
    extra copies of the held-down key into the buffer."  No source code
    is given in that issue; but the QUICKEYS utility that {PC} published
    in 1986 does this sort of watching (not verified); source and object
    code are downloadable in pd1:<msdos.pcmag>vol5n05.arc from Simtel.

Subject:  307. What is the SysRq key for?

    There is no standard use for the key.  The BIOS keyboard routines in
    INT 16 simply ignore it; therefore so do the DOS input routines in
    INT 21 as well as the keyboard routines in libraries supplied with
    high-level languages.

    When you press or release a key, the keyboard triggers hardware line
    IRQ1, and the CPU calls INT 9.  INT 9 reads the scan code from the
    keyboard and the shift states from the BIOS data area.

    What happens next depends on whether your PC's BIOS supports an
    enhanced keyboard (101 or 102 keys).  If so, INT 9 calls INT 15
    function 4F to translate the scan code.  If the translated scan code
    is 54 hex (for the SysRq key) then INT 9 calls INT 15 function 85
    and doesn't put the keystroke into the keyboard buffer.  The default
    handler of that function does nothing and simply returns.  (If your
    PC has an older BIOS that doesn't support the extended keyboards,
    INT 15 function 4F is not called.  Early ATs have 84-key keyboards,
    so their BIOS calls INT 15 function 85 but nor 4F.)

    Thus your program is free to use SysRq for its own purposes, but at
    the cost of some programming.  You could hook INT 9, but it's
    probably easier to hook INT 15 function 85, which is called when
    SysRq is pressed or released.

Subject:  308. How can my program tell what kind of keyboard is on the
               system?

    Ralf Brown's Interrupt List includes MEMORY.LST, a detailed
    breakdown by Robin Walker of the contents of the BIOS system block
    that starts at 0040:0000.  Bit 4 of byte 0040:0096 is "1=enhanced
    keyboard installed".  C code to test the keyboard type:
        char far *kbd_stat_byte3 = (char far *)0x00400096UL;
        if (0x10 & *kbd_stat_byte3)
            /* 101- or 102-key keyboard is installed */

    {PC Magazine} 15 Jan 1991 issue suggests on page 412 that "for some
    clones [the above test] is not foolproof".  If you use this method
    in your program you should provide the user some way to override
    this test, or at least some way to tell your program to assume a
    non-enhanced keyboard.  The article suggests a different approach to
    determining the type of keyboard.

Subject:  309. How can I tell if input, output, or stderr has been
               redirected?

    (rev: 24 Sep 1993)  Normally, input and output are associated with
    the console (i.e., with the keyboard and the screen, respectively).
    If either is not, you know that it has been redirected.  Some source
    code to check this is available at the usual archive sites.

    If you program in Turbo Pascal, you'll want this downloadable
    collection of Turbo Pascal units:
        /pc/ts/tspa33*.zip at Garbo
        pd1:<msdos.turbopas>tspa33*.zip at Simtel.
    (where the * is 70, 60, 55, 50, or 40 for Turbo Pascal 7.0, 6.0,
    5.5, 5.0, or 4.0 respectively.)  Source code is not included.  Also
    see the downloadable Frequently Asked Questions files by Timo Salmi:
        /pc/ts/tsfaqp15.zip at Garbo
        pd1:<msdos.info>tsfaqp15.zip at Simtel.

    If you program in C, use isatty( ) if your implementation has it.
    Otherwise, pd1:<msdos.sysutl>is_con10.zip is downloadable from
    Simtel; it includes source code.

    Good references for the principles are {PC Magazine} 16 Apr 1991
    (x:7) pg 374; Ray Duncan's {Advanced MS-DOS}, ISBN 1-55615-157-8, or
    Ralf Brown's interrupt list for INT 21 function 4400; and Terry
    Dettman and Jim Kyle's {DOS Programmer's Reference:  2d edition},
    ISBN 0-88022-458-4, pp 602-603.

Subject:  310. How can I increase the size of the keyboard buffer?

    (new: 20 June 1993)  SB tested only one of the many available device
    drivers that do this, namely BUF160, which extends the keyboard
    buffer to 160 characters.  It performed flawlessly for two years
    with MS-DOS 5 and Windows 3.1.  It's downloadable as
        pd1:<msdos.keyboard>buf160_6.zip at Simtel
        /pc/keyboard/buf160_6.zip at Garbo.

Subject:  311. How can I stuff characters into the keyboard buffer?

    (new: 15 Aug 1993)  If your computer has an enhanced keyboard (see
    "How can my program tell what kind of keyboard is on the system?",
    above), then put the scan code in CH, the ASCII character in CL, 5
    in AH, and execute INT 16.  The return in AL is 0 for success or 1
    for buffer full.

(continued in part 3)