DP Tool Club 8/CDASC08.ISO/VRAC/MSDOSFAQ.ZIP/MSDOSFAQ.TXT

Text File | 1993-08-17 | 121.5 KB | 2,564 lines

Newsgroups: comp.os.msdos.programmer,comp.answers,news.answers
Path: senator-bedfellow.mit.edu]enterpoop.mit.edu]spool.mu.edu]darwin.sura.net]math.ohio-state.edu]magnus.acs.ohio-state.edu]usenet.ins.cwru.edu]ncoast]brown
From: [e-mail] (Stan Brown)
Subject: comp.os.msdos.programmer FAQ part 1 of 4
Expires: Fri, 23 Jul 1993 23:18:24 GMT
Organization: Oak Road Systems, Cleveland Ohio USA
Distribution: world
Date: Sat, 26 Jun 1993 23:18:24 GMT
Approved: [e-mail]
Message-ID: <[e-mail]>
Followup-To: comp.os.msdos.programmer
Keywords:
References: none
Supersedes: <[e-mail]>
Lines: 209
Xref: senator-bedfellow.mit.edu comp.os.msdos.programmer:24750 comp.answers:1132 news.answers:9756


Archive-name: msdos-programmer-faq/part1
Last modified: 26 June 1993


This is the FAQ list (Frequently Asked Questions list) for the newsgroup
comp.os.msdos.programmer.  Parts 2 through 4 of this article are posted
as followups in the same thread.  Starting 2 Feb 1993, I mark new and
revised answers with "new:" or "rev:" and the change date.

If the posting date shown above is more than four weeks in the past, see
instructions in part 4 of this list for how to get an updated copy.  (A
separate article, posted before this one, holds the changes from the
previous edition.  Look for the subject line "comp.os.msdos.programmer
FAQ diffs".)

FAQ lists are intended to reduce the noise level in their newsgroups
that results from the repetition of the same questions, correct answers,
wrong answers, corrections to the wrong answers, corrections to the
corrections, debate, etc.

This list should serve as a repository of the canonical "best" answers
to the questions in it.  The names of folks who have helped to improve
this FAQ list follow the table of contents.  If you know a better answer
or even a slight change that improves an answer, please tell me]  (Use
email, please.  Traffic in this group is high, and I may miss a relevant
posted article.)
                      Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                                        [e-mail]

Search tips
===========
    To search for specific topics:  See the list of questions in the
Contents section (immediately below) to find which article (part 2, 3,
or 4) you need.  Then, in that part, search for that question number.
For example, while you're reading part 2 of this list, the trn
newsreader command "gQ203" goes to Q203.
    To skip one topic and go to the next:  Search for "Q" starting in
column 1.  In trn and similar newsreaders, the command "g^Q" does that.
    If your newsreader doesn't support searches, you can extract these
articles to a file and use your favorite editor's search commands.


Contents--part 2 of 4
=====================
section 1. General questions
    101. Why won't my code work?
    102. What is this newsgroup about?
    103. What's the difference from comp.sys.ibm.pc.programmer?
    104. Is comp.os.msdos.programmer available as a mailing list?
    105. What other newsgroups should I know about?
section 2. Compile and link
    201. What the heck is "DGROUP > 64K"?
    202. How do I fix "automatic data segment exceeds 64K" or "stack
         plus data exceed 64K"?
    203. Will Borland C code and Microsoft C code link together?
    204. Why did my program bomb at run time with "floating point
         formats not linked"?
    205. Why did my program bomb with "floating point not loaded"?
    206. How can I change the stack size in Borland's C compilers?
    207. What's the format of an .OBJ file?
    208. What's the format of an .EXE header?
    209. What's the difference between .COM and .EXE formats?
section 3. Keyboard
    301. How can I read a character without echoing it to the screen,
         and without waiting for the user to press the Enter key?
    302. How can I find out whether a character has been typed, without
         waiting for one?
    303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del?
    304. How can I disable the print screen function?
    305. How can my program turn NumLock (CapsLock, ScrollLock) on/off?
    306. How can I speed up the keyboard's auto-repeat?
    307. What is the SysRq key for?
    308. How can my program tell what kind of keyboard is on the system?
    309. How can I tell if input, output, or stderr has been redirected?
    310. How can I increase the size of the keyboard buffer?


Contents--part 3 of 4
=====================
section 4. Disks and files
    401. What drive was the PC booted from?
    402. How can I boot from drive b:?
    403. Which real and virtual disk drives are valid?
    404. How can I make my single floppy drive both a: and b:?
    405. Why won't my C program open a file with a path?
    406. How can I redirect printer output to a file?
    407. How can I redirect the output of a batch file?
    408. How can my program open more files than DOS's limit of 20?
    409. How can I read, create, change, or delete the volume label?
    410. How can I get the disk serial number?
    411. What's the format of .OBJ, .EXE., .COM files?
    412. How can I flush the software disk cache?
section 5. Serial ports (COM ports)
    501. How do I set my machine up to use COM3 and COM4?
    502. How do I find the I/O address of a COM port?
    503. But aren't the COM ports always at I/O addresses 3F8, 2F8, 3E8,
         and 2E8?
    504. How do I configure a COM port and use it to transmit data?
section 6. Other hardware questions and problems
    601. Which 80x86 CPU is running my program?
    602. How can a C program send control codes to my printer?
    603. How can I redirect printer output to a file?
    604. Which video adapter is installed?
    605. How do I switch to 43- or 50-line mode?
    606. How can I find the Microsoft mouse position and button status?
    607. How can I access a specific address in the PC's memory?
    608. How can I read or write my PC's CMOS memory?
    609. How can I access memory beyond 640K?
    610. Where can I find a list of 80x86 opcodes?
section 7. Other software questions and problems
    701. How can a program reboot my PC?
    702. How can I time events with finer resolution than the system
         clock's 55 ms (about 18 ticks a second)?
    703. How can I find the error level of the previous program?
    704. How can a program set DOS environment variables?
    705. How can I change the switch character to - from /?
    706. Why does my interrupt function behave strangely?
    707. How can I write a TSR (terminate-stay-resident) utility?
    708. How can I write a device driver?
    709. What can I use to manage versions of software?
    710. What's this "null pointer assignment" after my C program
         executes?
    711. How can my program tell if it's running under Windows?
    712. How do I copyright software that I write?


Contents--part 4 of 4
=====================
section A. Downloading
    A01. What are Simtel, garbo, and wustl?
    A02. I have no ftp access.  How can I get files from the archives?
    A03. Can I get archives on CD-ROM?
    A04. Where do I find program <mumble>?
    A05. How can I check Simtel or garbo before I post a request for a
         program?
    A06. How do I download and decode a program I found?
    A07. Where is UUDECODE?
    A08. Why do I get errors when extracting from a ZIP file I
         downloaded?
section B. Vendors and products
    B01. How can I contact Borland?
    B02. How can I contact Microsoft?
    B03. What's the current version of UNZIP?
    B04. What's in Borland Pascal/Turbo Pascal 7.0?
    B05. What's in Microsoft Visual C++?
    B06. Where is Microsoft C 8.0?
section C. More information
    C01. Are there any good on-line references for PC hardware
         components?
    C02. Are there any good on-line references for PC interrupts?
    C03. What and where is "Ralf Brown's interrupt list"?
    C04. Where can I find lex, yacc, and language grammars?
    C05. What's the best book to learn programming?
    C06. Where are FAQ lists archived?
    C07. Where can I get the latest copy of this FAQ list?
    C08. How do I use ftp?


Acknowledgements
================
Many articles posted in comp.os.msdos.programmer sparked ideas or
provided information for the first version of this list.  Though I am
responsible for any errors, thanks are due to the following for posted
articles or private email that I used in subsequent editions:  Jamshid
Afshar, Mark Aitchison, Sanjay Aiyagari, George Almasi, Aaron Auseth,
Preston Bannister, Denis Beauregard, Mike Black, Jon Brinkmann, Glynn
Brooks, Paul Brooks, Ralf Brown, Shaun Burnett, Raymond Chen, Alan Drew,
Paul Ducklin, Gary Dueck, Roland Eriksson, Markus Fischer, George
Forsman, Vincent Giovannone, B.Haible, Janos Haide, Klaus Hartnegg, Kris
Heidenstrom, Tom Haapanen, Joel Hoffman, Ari Hovila, Joe Huffman,
Michael Holin, Mike Iarrobino, Byrial Jensen, Rune Jorgensen, Ajay
Kamdar, Everett Kaser, Jeff Kellam, Jen Kilmer, Reinhard Kirchner, Dave
Kirsch, Samuel Ko, Benjamin Lee, Sidney Markowitz, Jim Marks, Dimitri
Matzarakis, Fred McCall, Ken McKee, Tom Milner, Bill Moore, Duncan
Murdoch, Steve Murphy, Mert Nickerson, David Nugent, John Oldenburg,
David Pape, Keith Petersen, Karl Riedling, Arthur Rubin, Gerald
Ruderman, Timo Salmi, Tapio Sand, John Schmid, Russell Schulz, Ajay
Shah, Steve Summit, Tom Swingle, Anders Thulin, Curt Tilmes, Rick
Watkins, Ya-Gui Wei, Joe Wells, Gregory Youngblood, [e-mail]

New contributors this issue: Ari Hovila


Legalistic stuff
================
This article is not in the public domain, but it may be redistributed so
long as this notice, the acknowledgements, and the information on
obtaining the latest copy of this list are retained and no fee is
charged.  The code fragments may be used freely; credit would be polite.

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

THERE IS NO WARRANTY ON THE CODE.  I have tested all the code included
below, but your machine may not work the same as mine, and my testing
may not be perfect.  (Except where otherwise noted, I tested the code
with both BC++ 2.0 and MSC 5.0.)

The mention of particular books or programs must not be construed to
reflect unfavorably on any that are not mentioned.



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: 4 Jul 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 Jun 93" in news.lists shows
    68,000 readers of this newsgroup worldwide.  Traffic (exclusive of
    crossposts) was 783 articles aggregating 1519 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: 28 July 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.

    Why does the newsgroup seem to be so C-oriented sometimes?  I think
    there are two reasons.  First, comp.lang.c and comp.lang.pascal have
    evolved in different directions.  I am told that 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 I think that's best
    but because of the practical limit of my skills and (if I may use
    the word) integrity.  I am very reluctant to publish mere hearsay in
    the FAQ list, so I tend to stick to what I can verify personally.  I
    am a C programmer (with some assembler); therefore the solutions
    that I can verify personally are written in C or assembler.  I
    believe it's legitimate to publish short, clear programs in only one
    language, since programmers should be able to translate them easily
    into their languages of choice.  But the FAQ list also contains
    several long programs written only in C; I agree that this is a
    defect, but I'm not sure of the best way to remedy it.  When giving
    pointers to source code at archive sites, I do try to include both
    C- and Pascal-language source when available (and I would be
    grateful to know what I have missed).

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
    [e-mail].  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: 7 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.

    - 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
      [e-mail] 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: 13 Feb 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 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: 1 May 1993) Here's what I've been told.  I have verified the
    references marked "(verified)".

    - base .OBJ format:  Intel's document number #121748-001, {8086
      Relocatable Object Module Formats}.  (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:  a 45-page article in the {MS-DOS
      Encyclopedia}, ISBN 1-55615-049-0 (verified).  I am told there is
      also a "Microsoft Object Module Format (OMF)" Specification,
      printed 22 Nov 1991, from the Microsoft Languages Group.

    - Microsoft publishes an .OBJ spec in Windows help format (266K
      after unzipping).  I'm not sure why it's in Windows help format,
      since it's one long document without hypertex links.  Download it
      as /vendor/microsoft/developer-network/ctech/11-9.zip from
      ftp.uu.net (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.

    - A "tutorial on the .OBJ format" comes with the VAL experimental
      linker, downloadable as pd1:<msdos.pgmutl>val-link.arc at Simtel.

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, I am
    told that 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: 18 Apr 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, the
    characters ^C will appear on the screen when the user presses Ctrl-C
    or Ctrl-Break.  There are many ways to work around that, including:
    use INT 21 function 7, which allows redirection but doesn't display
    the ^C (or echo any other character, for that matter); or use INT 16
    function 0 or 10; or call _bios_keybrd( ) in MSC or bioskey( ) in
    BC++; 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 can't offer an easy way to
    disable the echo-screen-to-printer function.  Please send any tested
    solutions to [e-mail] and I'll add them to this list.

    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 I'm told that the QUICKEYS utility that
    {PC} published in 1986 does this sort of watching; 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: 7 Aug 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/tspa32*.zip at Garbo
        pd1:<msdos.turbopas>tspa32*.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/tsfaqp14.zip at Garbo
        pd1:<msdos.info>tsfaqp14.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)  I have tested only one of the many available
    device drivers that do this.  That one has performed flawlessly for
    me in almost two years of use with MS-DOS 5 and Windows 3.1.  It
    extends the keyboard buffer to 160 characters; it's downloadable as
        pd1:<msdos.keyboard>buf160_6.zip at Simtel
        /pc/keyboard/buf160_6.zip at Garbo.


section 4.  Disks and files
===========================

Subject:  401. What drive was the PC booted from?

    Under DOS 4.0 or later, load 3305 hex into AX; do an INT 21.  DL is
    returned with an integer indicating the boot drive (1=A:, etc.).

Subject:  402. How can I boot from drive b:?

    (rev: 18 Apr 1993)  Downloadable shareware:
        pd1:<msdos.dskutl>boot_b.zip from Simtel
        /pc/bootutil/boot_b.zip from Garbo.
    The included documentation says it works by writing a new boot
    sector on a disk in your a: drive that redirects the boot to your
    b: drive.

    If that doesn't work, you can always interchange your a: and b:
    drives by switching ribbon cables and changing the setup in your
    BIOS.  From an article posted 27 Jan 1993 on another newsgroup:

    Take the "ribbon" connector, as you call it, and switch them.  To
    double check, start at the end of the cable that connects to the
    motherboard or floppy controller.  Follow the cable until you get to
    the first connector.  Connect this to the drive you want to be b:.
    After this, there should be a few lines on the cable that get
    flipped left to right.  (On most cables, they just cut the lines and
    physically reverse them.  It should be quite obvious from looking at
    the cable.)  Anyway, the connector after the pins get flipped
    right to left is the connector for your a: drive.

Subject:  403. Which real and virtual disk drives are valid?

    Use INT 21 function 29 (parse filename).  Point DS:SI at a null-
    terminated ASCII string that contains the drive letter and a colon,
    point ES:DI at a 37-byte dummy FCB buffer, set AX to 2900h, and do
    an INT 21.  On return, AL is FF if the drive is invalid, something
    else if the drive is valid.  RAM disks and SUBSTed drives are
    considered valid.

    Unfortunately, the b: drive is considered valid even on a single-
    diskette system.  You can check that special case by interrogating
    the BIOS equipment byte at 0040:0010.  Bits 7-6 contain the one less
    than the number of diskette drives, so if those bits are zero you
    know that b: is an invalid drive even though function 29 says it's
    valid.

    Following is some code originally posted by Doug Dougherty, with my
    fix for the b: special case, tested only in Borland C++ 2.0 (in
    the small model):

        #include <dos.h>
        void drvlist(void)  {
            char *s = "A:", fcb_buff▌37¿;
            int valid;
            for (   ;  *s<='Z';  (*s)++) {
                _SI = (unsigned) s;
                _DI = (unsigned) fcb_buff;
                _ES = _DS;
                _AX = 0x2900;
                geninterrupt(0x21);
                valid = _AL ]= 0xFF;
                if (*s == 'B'  &&  valid) {
                    char far *equipbyte = (char far *)0x00400010UL;
                    valid = (*equipbyte & (3 << 6)) ]= 0;
                }
                printf("Drive '%s' is %sa valid drive.\n",
                        s, valid ? "" : "not ");
            }
        }

Subject:  404. How can I make my single floppy drive both a: and b:?

    Under any DOS since DOS 2.0, you can put the command

        assign b=a

    into your AUTOEXEC.BAT file.  Then, when you type "DIR B:" you'll no
    longer get the annoying prompt to insert diskette B (and the even
    more annoying prompt to insert A the next time you type "DIR A:").

    You may be wondering why anybody would want to do this.  Suppose you
    use two different machines, maybe one at home and one at work.  One
    of them has only a 3.5" diskette drive; the other machine has two
    drives, and b: is the 3.5" one.  You're bound to type "dir b:" on
    the first one, and get the nuisance message

        Insert diskette for drive B: and press any key when ready.

    But if you assign drive b: to point to a:, you avoid this problem.

    Caution:  there are a few commands, such as DISKCOPY, that will not
    work right on ASSIGNed or SUBSTed drives.  See the DOS manual for
    the full list.  Before typing one of those commands, be sure to turn
    off the mapping by typing "assign" without arguments.

    The DOS 5.0 manual says that ASSIGN is obsolete, and recommends the
    equivalent form of SUBST: "subst b: a:\".  Unfortunately, if this
    command is executed when a: doesn't hold a diskette, the command
    fails.  ASSIGN doesn't have this problem, so I must advise you to
    disregard that particular bit of advice in the DOS manual.

Subject:  405. How can I disable access to a drive?

    (new: 7 Aug 1993)  Reader Eric DeVolder writes that he has made
    available a program to do this.  It's downloadable from Simtel as
    pd1:<msdos.dskutl>rmdriv20.zip; I haven't tried it myself.

Subject:  406. How can a batch file test existence of a directory?

    (new: 7 Aug 1993)  The standard way, which in fact is documented in
    the DOS manual, is

        if exist d:\path\nul goto found

    Unfortunately, this is not entirely reliable.  I have found it to
    fail in Pathworks (DEC's network that connects PCs and VAXes, a/k/a
    PCSA), or on a MARS box that uses an OEM version of MS-DOS 5.0.
    Other readers have reported that it failed on Novell networks or on
    DR-DOS.

    There appears to be no foolproof way to use pure batch commands to
    test for existence of a directory.  The real solution is to write a
    program, which returns a value that your batch program can then test
    with an if errorlevel.  Reader Duncan Murdoch kindly posted the
    following Turbo Pascal version, which I haven't yet tried myself:

        program existdir;
        { Confirms the existence of a directory given on the command line.
          Returns errorlevel 2 on error, 1 if not found, 0 if found. }

        uses
          dos;

        var
          s : searchrec;

        begin
          if paramcount <> 1 then
          begin
            writeln('Syntax:  EXISTDIR directory');
            halt(2);
          end
          else
          begin
            findfirst(paramstr(1),Directory,S);
            while (Doserror = 0) and ((Directory and S.Attr) = 0) do
              findnext(S);
            if Doserror <> 0 then
            begin
              Writeln('Directory not found.');
              halt(1);
            end
            else
            begin
              Writeln('Directory found.');
              halt(0);
            end;
          end;
        end.

    Timo Salmi also has a Turbo Pascal version in his Turbo Pascal FAQ,
    which is downloadable as
        /pc/ts/tsfaqp14.zip at Garbo
        pd1:<msdos.info>tsfaqp14.zip at Simtel.

Subject:  407. Why won't my C program open a file with a path?

    You've probably got something like the following code:

        char *filename = "c:\foo\bar\mumble.dat";
        . . .  fopen(filename, "r");

    The problem is that \f is a form feed, \b is a backspace, and \m is
    m.  Whenever you want a backslash in a string constant in C, you
    must use two backslashes:

        char *filename = "c:\\foo\\bar\\mumble.dat";

    This is a feature of every C compiler, because Dennis Ritchie
    designed C this way.  It's a problem only on MS-DOS systems, because
    only DOS (and Atari ST/TT running TOS, I'm told) uses the backslash
    in directory paths.  But even in DOS this backslash convention
    applies _only_ to string constants in your source code.  For file
    and keyboard input at run time, \ is just a normal character, so
    users of your program would type in file specs at run time the same
    way as in DOS commands, with single backslashes.

    Another possibility is to code all paths in source programs with /
    rather than \ characters:

        char *filename = "c:/foo/bar/mumble.dat";

    Ralf Brown writes that "All versions of the DOS kernel accept either
    forward or backslashes as directory separators.  I tend to use this
    form more frequently than backslashes since it is easier to type and
    read."  This applies to DOS function calls (and therefore to calls
    to the file library of every programming language), but not to DOS
    commands.

Subject:  408. How can I redirect printer output to a file?

    (rev: 18 Apr 1993)  My personal favorite utility for this purpose is
    PRN2FILE from {PC Magazine}, downloadable as:
        pd1:<msdos.printer>prn2file.arc at Simtel
        /pc/printer/prn2file.zip at Garbo.
    {PC Magazine} has given copies away as part of its utilities disks,
    so you may already have a copy.

    The directories mentioned above have lots of other utilities to
    redirect printer output.

Subject:  409. How can I redirect the output of a batch file?

    (new: 12 June 1993) Assuming the batch file is called batch.bat, to
    send its output (stdout) to another file, just invoke COMMAND.COM as
    a secondary command processor:

        command /c batch parameters_if_any >outfile

    Timo Salmi's notes on this and other batch tricks are downloadable:
        pd1:<msdos.batutl>tsbat43.zip at Simtel
        /pc/ts/tsbat43.zip at Garbo.

Subject:  410. How can my program open more files than DOS's limit of 20?

    (rev: 1 May 1993.  This is a summary of an article Ralf Brown posted
    on 8 August 1992, with some additions from a Microsoft tech note.)

    There are separate limits on files and file handles.  For example,
    DOS opens three files but five file handles:  CON (stdin, stdout,
    and stderr), AUX (stdaux), and PRN (stdprn).

    The limit in FILES= in CONFIG.SYS is a system-wide limit on files
    opened by all programs (including the three that DOS opens and any
    opened by TSRs); each process has a limit of 20 handles (including
    the five that DOS opens).  Example:  CONFIG.SYS has FILES=40.  Then
    program #1 will be able to open 15 file handles.  Assuming that the
    program actually does open 15 handles pointing to 15 different
    files, other programs could still open a total of 22 files (40-3-15
    = 22), though no one program could open more than 15 file handles.

    If you're running DOS 3.3 or later, you can increase the per-process
    limit of 20 file handles by a call to INT 21 function 67, Set Handle
    Count.  Your program is still limited by the system-wide limit on
    open files, so you may also need to increase the FILES= value in
    your CONFIG.SYS file (and reboot).  The run-time library that you're
    using may have a fixed-size table of file handles, so you may also
    need to get source code for the module that contains the table,
    increase the table size, and recompile it.

    In Microsoft C the run-time library limits you to 20 file handles.
    To change this, you must be aware of two limits:

    - file handles used with _open( ), _read( ), etc.: Edit _NFILE_ in
      CRT0DAT.ASM.

    - stream files used with fopen( ), fread( ), etc.: Edit _NFILE_ in
      _FILE.C for DOS or FILE.ASM for Windows/QuickWin.  This must not
      exceed the value of _NFILE_ in CRT0DAT.ASM.

    (QuickWin uses the constant _WFILE_ in CRT0DAT.ASM and WFILE.ASM for
    the maximum number of child text windows.)

    After changing the limits, recompile using CSTARTUP.BAT.  Microsoft
    recommends that you first read README.TXT in the same directory.

Subject:  411. How can I read, create, change, or delete the volume
               label?

    In DOS 5.0 (and, I believe, in 4.0 as well), there are actually two
    volume labels: one, the traditional one, is an entry in the root
    directory of the disk; and the other is in the boot record along
    with the serial number (see next Q).  The DIR and VOL commands
    report the traditional label; the LABEL command reports the
    traditional one but changes both of them.

    In DOS 4.0 and later, use INT 21 function 69 to access the boot
    record's serial number and volume label together; see the next Q.

    Assume that by "volume label" you mean the traditional one, the one
    that DIR and VOL display.  Though it's a directory entry in the root
    directory, you can't change it using the newer DOS file-access
    functions (3C, 41, 43); instead, use the old FCB-oriented directory
    functions.  Specifically, you need to allocate a 64-byte buffer and
    a 41- byte extended FCB (file control block).  Call INT 21 AH=1A to
    find out whether there is a volume label.  If there is, AL returns 0
    and you can change the label using DOS function 17 or delete it
    using DOS function 13.  If there's no volume label, function 1A will
    return FF and you can create a label via function 16.  Important
    points to notice are that ? wildcards are allowed but * are not; the
    volume label must be space filled not null terminated.

    The following MSC 7.0 code worked for me in DOS 5.0; the functions
    it uses have been around since DOS 2.0.  The function parameter is 0
    for the current disk, 1 for a:, 2 for b:, etc.  It doesn't matter
    what your current directory is; these functions always search the
    root directory for volume labels.  (I didn't try to change the
    volume label of any networked drives.)

    // Requires DOS.H, STDIO.H, STRING.H
    void vollabel(unsigned char drivenum) {
        static unsigned char extfcb▌41¿, dta▌64¿, status, *newlabel;
        int chars_got = 0;
        #define DOS(buff,func) __asm { __asm mov dx,offset buff \
            __asm mov ax,seg buff  __asm push ds  __asm mov ds,ax \
            __asm mov ah,func  __asm int 21h  __asm pop ds \
            __asm mov status,al }
        #define getlabel(buff,prompt) newlabel = buff;  \
            memset(newlabel,' ',11);  printf(prompt);   \
            scanf("%11▌^\n¿%n", newlabel, &chars_got);  \
            if (chars_got < 11) newlabel▌chars_got¿ = ' ';

        // Set up the 64-byte transfer area used by function 1A.
        DOS(dta, 1Ah)
        // Set up an extended FCB and search for the volume label.
        memset(extfcb, 0, sizeof extfcb);
        extfcb▌0¿ = 0xFF;             // denotes extended FCB
        extfcb▌6¿ = 8;                // volume-label attribute bit
        extfcb▌7¿ = drivenum;         // 1=A, 2=B, etc.; 0=current drive
        memset(&extfcb▌8¿, '?', 11);  // wildcard *.*
        DOS(extfcb,11h)
        if (status == 0) {            // DTA contains volume label's FCB
            printf("volume label is %11.11s\n", &dta▌8¿);
            getlabel(&dta▌0x18¿, "new label (\"delete\" to delete): ");
            if (chars_got == 0)
                printf("label not changed\n");
            else if (strncmp(newlabel,"delete     ",11) == 0) {
                DOS(dta,13h)
                printf(status ? "label failed\n" : "label deleted\n");
            }
            else {                    // user wants to change label
                DOS(dta,17h)
                printf(status ? "label failed\n" : "label changed\n");
            }
        }
        else {                        // no volume label was found
            printf("disk has no volume label.\n");
            getlabel(&extfcb▌8¿, "new label (<Enter> for none): ");
            if (chars_got > 0) {
                DOS(extfcb,16h)
                printf(status ? "label failed\n" : "label created\n");
            }
        }
    }   // end function vollabel

Subject:  412. How can I get the disk serial number?

    Use INT 21.  AX=6900 gets the serial number; AX=6901 sets it.  See
    Ralf Brown's interrupt list, or page 496 of {PC Magazine} July 1992,
    for details.

    This function also gets and sets the volume label, but it's the
    volume label in the boot record, not the volume label that a DIR
    command displays.  See the preceding Q.

Subject:  413. What's the format of .OBJ, .EXE., .COM files?

    Please see section 2, "Compile and link".

Subject:  414. How can I flush the software disk cache?

    Please see "How can a program reboot my PC?" in section 7, "Other
    software questions and problems".

section 5. Serial ports (COM ports)
===================================

Subject:  501. How do I set my machine up to use COM3 and COM4?

    Unless your machine is fairly old, it's probably already set up.
    After installing the board that contains the extra COM port(s),
    check the I/O addresses in word 0040:0004 or 0040:0006.  (In DEBUG,
    type "D 40:4 L4" and remember that every word is displayed low
    byte first, so if you see "03 56" the word is 5603.)  If those
    addresses are nonzero, your PC is ready to use the ports and you
    don't need the rest of this answer.

    If the I/O address words in the 0040 segment are zero after you've
    installed the I/O board, you need some code to store these values
    into the BIOS data segment:

        0040:0004  word  I/O address of COM3
        0040:0006  word  I/O address of COM4
        0040:0011  byte (bits 3-1): number of serial ports installed

    The documentation with your I/O board should tell you the port
    addresses.  When you know the proper port addresses, you can add
    code to your program to store them and the number of serial ports
    into the BIOS data area before you open communications.  Or you can
    use DEBUG to create a little program to include in your AUTOEXEC.BAT
    file, using this script:

            n SET_ADDR.COM      <--- or a different name ending in .COM
            a 100
            mov  AX,0040
            mov  DS,AX
            mov  wo ▌0004¿,aaaa <--- replace aaaa with COM3 address or 0
            mov  wo ▌0006¿,ffff <--- replace ffff with COM4 address or 0
            and  by ▌0011¿,f1
            or   by ▌0011¿,8    <--- use number of serial ports times 2
            mov  AH,0
            int  21
                                <--- this line must be blank
            rCX
            1f
            rBX
            0
            w
            q

Subject:  502. How do I find the I/O address of a COM port?

    Look in the four words beginning at 0040:0000 for COM1 through COM4.
    (The DEBUG command "D 40:0 L8" will do this.  Remember that words
    are stored and displayed low byte first, so a word value of 03F8
    will be displayed as F8 03.)  If the value is zero, that COM port is
    not installed (or you've got an old BIOS; see the preceding Q).  If
    the value is nonzero, it is the I/O address of the transmit/receive
    register for the COM port.  Each COM port occupies eight consecutive
    I/O addresses (though only seven are used by many chips).

    Here's some C code to find the I/O address:

        unsigned ptSel(unsigned comport) {
            unsigned io_addr;
            if (comport >= 1  &&  comport <= 4) {
                unsigned far *com_addr = (unsigned far *)0x00400000UL;
                io_addr = com_addr▌comport-1¿;
            }
            else
                io_addr = 0;
            return io_addr;
        }

Subject:  503. But aren't the COM ports always at I/O addresses 3F8,
               2F8, 3E8, and 2E8?

    The first two are usually right (though not always); the last two
    are different on many machines.

Subject:  504. How do I configure a COM port and use it to transmit data?

    (rev: 19 Jul 1993) Do you want actual code, or do you want books
    that explain what's going on?

    1) Source code

    First, check your compiler's run-time library.  Many compilers offer
    functions similar to Microsoft C's _bios_serialcom() or Borland's
    bioscom(), which may meet your needs.

    Second, check for downloadable resources at Simtel and Garbo.  At
    Simtel, pd1:<msdos.c>pcl4c34.zip (March 1993) is described as
    "Asynchronous communications library for C"; Garbo has a whole
    /pc/comm directory.  Also, an extended example is in Borland's
    TechFax TI445, downloadable as part of
        pd1:<msdos.turbo-c>bchelp10.zip at Simtel
        /pc/turbopas/bchelp10.zip at Garbo.
    Though written by Borland, much of it is applicable to other forms
    of C, and it should give you ideas for other programming languages.

    2) Reference books

    After hearing several recommendations, I looked at Joe Campbell's {C
    Programmer's Guide to Serial Communications}, ISBN 0-672-22584-0,
    and agree that it is excellent.  He gives complete details on how
    serial ports work, along with complete programs for doing polled or
    interrupt-driver I/O.  The book is quite thick, and none of it looks
    like filler.

    If Campbell's book is overkill for you, you'll find a good short
    description of serial I/O in {DOS 5: A Developer's Guide}, ISBN
    1-55851-177-6, by Al Williams.

    Finally, a reader has recommended {Serial Communications Programming
    in C/C++} by Mark Goodwin (ISBN 1558281983), with source code in the
    book and on disk.  Topics include the basics, various methods of
    serial communications on the PC (with consideration of high-speed
    modems), ANSI screen interface, file transfer protocols (Xmodem and
    Ymodem), etc.  There is code in C, and that code is extended into a
    C++ class for those who use C++.  There are also subroutines in
    Assembly.

section 6. Other hardware questions and problems
================================================

Subject:  601. Which 80x86 CPU is running my program?

    (rev: 20 June 1993)  According to an article posted by Michael
    Davidson, Intel's approved code for distinguishing among 8086,
    80286, 80386, and 80486 and for detecting the presence of an 80287
    or 80387 is published in Intel's 486SX processor manual (order
    number 240950-001).  David Kirschbaum's improved version of this is
    downloadable as
        pd1:<msdos.sysutl>cpuid593.zip from Simtel
        /pc/sysinfo/cpuid593.zip from Garbo.

    According to an article posted by its author, WCPU knows the
    differences between DX and SX varieties of 386 and 486 chips, and
    can detect a math coprocessor and a Pentium.  It's downloadable as
        pd1:<msdos.sysutl>wcpu050.zip at Simtel
        /pc/sysinfo/wcpu050.zip at Garbo.

Subject:  602. How can a C program send control codes to my printer?

    If you just fprintf(stdprn, ...), C will translate some of your
    control codes.  The way around this is to reopen the printer in
    binary mode:

        prn = fopen("PRN", "wb");

    You must use a different file handle because stdprn isn't an lvalue.
    By the way, PRN or LPT1 must not be followed by a colon in DOS 5.0.

    There's one special case, Ctrl-Z (ASCII 26), the DOS end-of-file
    character.  If you try to send an ASCII 26 to your printer, DOS
    simply ignores it.  To get around this, you need to reset the
    printer from "cooked" to "raw" mode.  Microsoft C users must use int
    21 function 44, "get/set device information".  Turbo C and Borland
    C++ users can use ioctl to accomplish the same thing:

        ioctl(fileno(prn), 1, ioctl(fileno(prn),0) & 0xFF ! 0x20, 0);

    An alternative approach is simply to write the printer output into a
    disk file, then copy the file to the printer with the /B switch.

    A third approach is to bypass DOS functions entirely and use the
    BIOS printer functions at INT 17.  If you also fprintf(stdprn,...)
    in the same program, you'll need to use fflush( ) to synchronize
    fprintf( )'s buffered output with the BIOS's unbuffered.

    By the way, if you've opened the printer in binary mode from a C
    program, remember that outgoing \n won't be translated to carriage
    return/line feed.  Depending on your printer, you may need to send
    explicit \n\r sequences.

Subject:  603. How can I redirect printer output to a file?

    Please see section 4, "Disks and files", for the answer.

Subject:  604. Which video adapter is installed?

    The technique below should work if your BIOS is not too old.  It
    uses three functions from INT 10, the BIOS video interrupt.  (If
    you're using a Borland language, you may not have to do this the
    hard way.  Look for a function called DetectGraph or something
    similar.)

    Set AH=12h, AL=0, BL=32h; INT 10h.  If AL is 12h, you have a VGA.
    If not, set AH=12h, BL=10h; INT 10h.  If BL is 0,1,2,3, you have an
    EGA with 64,128,192,256K memory.  If not, set AH=0Fh; INT 10h.  If
    AL is 7, you have an MDA (original monochrome adapter) or Hercules;
    if not, you have a CGA.

    I've tested this for my VGA and got the right answer; but I can't
    test it for the other equipment types.  Please let me know by email
    at [e-mail] if your results vary.

Subject:  605. How do I switch to 43- or 50-line mode?

    pd1:<msdos.screen>vidmode.zip, downloadable from Simtel, contains
    .COM utilities and .ASM source code.

Subject:  606. How can I find the Microsoft mouse position and button
               status?

    Use INT 33 function 3, described in Ralf Brown's interrupt list.

    The Windows manual says that the Logitech mouse is compatible with
    the Microsoft one, so I assume the interrupt will work the same.

    Also, many files are downloadable from pd1:<msdos.mouse> at Simtel.

Subject:  607. How can I access a specific address in the PC's memory?

    First check the library that came with your compiler.  Many vendors
    have some variant of peek and poke functions; in Turbo Pascal use
    the pseudo-arrays Mem, MemW, and MemL.  As an alternative, you can
    construct a far pointer:  use Ptr in Turbo Pascal, MK_FP in the
    Turbo C family, and FP_OFF and FP_SEG in Microsoft C.

    Caution:  Turbo C and Turbo C++ also have FP_OFF and FP_SEG macros,
    but they can't be used to construct a pointer.  In Borland C++ those
    macros work the same as in Microsoft C, but MK_FP is easier to use.

    By the way, it's not useful to talk about "portable" ways to do
    this.  Any operation that is tied to a specific memory address is
    not likely to work on another kind of machine.

Subject:  608. How can I read or write my PC's CMOS memory?

    (rev: 13 Jun 1993) There are a great many public-domain utilities
    that do this.  These are downloadable from Simtel:

    pd1:<msdos.at>
    cmos14.zip     5965  920817  Saves/restores CMOS to/from file
    cmoser11.zip  28323  910721  386/286 enhanced CMOS setup program
    cmosram.zip   76096  920214  Save AT/386/486 CMOS data to file and restore
    rom2.zip      15692  900131  Save AT and 386 CMOS data to file and restore
    setup21.zip   18172  880613  Setup program which modifies CMOS RAM
    viewcmos.zip  11068  900225  Display contents of AT CMOS RAM, w/C source

    Downloadable from Garbo, /pc/ts/tsutle22.zip contains a CMOS program
    to check and display CMOS memory, but not to write to it.

    I have heard good reports of CMOS299.ZIP, available in the pc.dir
    directory of cantva.canterbury.ac.nz ▌132.181.30.3¿.

    Of the above, my only experience is with CMOSRAM, which seems to
    work fine.  It contains an excellent (and witty) .DOC file that
    explains the hardware involved and gives specific recommendations
    for preventing disaster or recovering from it.  It's $5 shareware.

    Robert Jourdain's {Programmer's Problem Solver for the IBM PC, XT,
    and AT} has code for accessing the CMOS RAM, according to an article
    posted in this newsgroup.

Subject:  609. How can I access memory beyond 640K?

    (rev: 2 May 1993) This is a legitimate FAQ, in that it is frequently
    asked.  But there is no single agreed-upon answer.  Please see the
    separate article called "How to access memory above 640K" in
    comp.os.msdos.programmer and in faqp*.zip at Simtel and Garbo.

Subject:  610. Where can I find a list of 80x86 opcodes?

    (new: 2 May 1993)  It's part of a rather long file, the 8 Dec 1992
    edition of the Info-IBMPC Digest (V92 #185), downloadable as
    pd2:<archives.ibmpc>9212.1-txt at Simtel.  (Note: pd2, not
    pd1.)  Opcodes for the 8086 through 80386 are listed.

section 7. Other software questions and problems
================================================

Subject:  701. How can a program reboot my PC?

    (rev: 28 July 1993) You can generate a "cold" boot or a "warm" boot.
    A cold boot is the same as turning the power off and on; a warm boot
    is the same as Ctrl-Alt-Del and skips the power-on self test.

    For a warm boot, store the hex value 1234 in the word at 0040:0072.
    For a cold boot, store 0 in that word.  Then, if you want to live
    dangerously, jump to address FFFF:0000.  Here's C code to do it:

        /* WARNING:  data loss possible */
        void bootme(int want_warm)  /* arg 0 = cold boot, 1 = warm */ {
            void (far* boot)(void) = (void (far*)(void))0xFFFF0000UL;
            unsigned far* type = (unsigned far*)0x00400072UL;
            *type = (want_warm ? 0x1234 : 0);
            (*boot)( );
        }

    What's wrong with that method?  It will boot right away, without
    closing files, flushing disk caches, etc.  If you boot without
    flushing a write-behind disk cache (if one is running), you could
    lose data or even trash your hard drive.

    There are two methods of signaling the cache to flush its buffers:
    (1) simulate a keyboard Ctrl-Alt-Del in the keystroke translation
    function of the BIOS (INT 15 function 4F; but see notes below), and
    (2) issue a disk reset (DOS function 0D).  Most disk-cache programs
    hook one or both of those interrupts, so if you use both methods
    you'll probably be safe.

    When user code simulates a Ctrl-Alt-Del, one or more of the programs
    that have hooked INT 15 function 4F can ask that the key be ignored by
    clearing the carry flag.  For example, HyperDisk does this when it
    has started but not finished a cache flush.  So if the carry flag
    comes back cleared, the boot code has to wait a couple of clock
    ticks and then try again.  (None of this matters on older machines
    whose BIOS can't support 101- or 102-key keyboards; see "What is the
    SysRq key for?" in section 3, "Keyboard".)

    C code that tries to signal the disk cache (if any) to flush is
    given below.  Equivalent Pascal code by Timo Salmi may be found at
    question 49 (as of this writing) in the Turbo Pascal FAQ in
    comp.lang.pascal, and is downloadable in FAQPAS2.TXT in
        /pc/ts/tsfaqp14.zip at Garbo
        pd1:<msdos.info>tsfaqp14.zip at Simtel.

    Here's C code that reboots after trying to signal the disk cache:
        #include <dos.h>
        void bootme(int want_warm)  /* arg 0 = cold boot, 1 = warm */ {
            union REGS reg;
            void    (far* boot)(void) = (void (far*)(void))0xFFFF0000UL;
            unsigned far* boottype    =     (unsigned far*)0x00400072UL;
            char     far* shiftstate  =         (char far*)0x00400017UL;
            unsigned      ticks;
            int           time_to_waste;
            /* Simulate reception of Ctrl-Alt-Del: */
            for (;;) {
                *shiftstate != 0x0C;    /* turn on Ctrl & Alt */
                reg.h.ah = 0x4F;        /* see notes below */
                reg.h.al = 0x53;        /* 0x53 = Del's scan code */
                reg.x.cflag = 1;        /* sentinel for ignoring key */
                int86(0x15, ®, ®);
                /* If carry flag is still set, we've finished. */
                if (reg.x.cflag)
                    break;
                /* Else waste some time before trying again: */
                reg.h.ah = 0;
                int86(0x1A, ®, ®);/* system time into CX:DX */
                ticks = reg.x.dx;
                for (time_to_waste = 3;  time_to_waste > 0;  ) {
                    reg.h.ah = 0;
                    int86(0x1A, ®, ®);
                    if (ticks ]= reg.x.dx)
                        ticks = reg.x.dx , --time_to_waste;
                }
            }
            /* Issue a DOS disk reset request: */
            reg.h.ah = 0x0D;
            int86(0x21, ®, ®);
            /* Set boot type and boot: */
            *boottype = (want_warm ? 0x1234 : 0);
            (*boot)( );
        }

    Reader Timo Salmi reported (26 July 1993) that the INT 15 AH=4F call
    may not work on older PCs (below AT, XT2, XT286), according to Ralf
    Brown's interrupt list.

    Reader Roger Fulton reported (1 July 1993) that INT 15 AH=4F call
    above hangs even a modern PC "ONLY when ANSI.SYS ▌is¿ loaded high
    using EMM386.EXE.  (Other things loaded high with EMM386.EXE were
    OK; ANSI.SYS loaded high with QEMM386.SYS was OK; ANSI.SYS loaded
    low with EMM386.EXE installed was OK.)"  His solution was to use
    only the disk reset, INT 21 function 0D, which does flush SMARTDRV,
    then wait five seconds in hopes that any other disk-caching
    software would have time to flush its queue.

    I'll publish a more bulletproof solution when one is known.

Subject:  702. How can I time events with finer resolution than the
               system clock's 55 ms (about 18 ticks a second)?

    (rev: 7 Aug 1993) The following files, among others, are
    downloadable from Simtel:

    pd1:<msdos.at>
    atim.zip       4783  881126  Precision program timing for AT

    pd1:<msdos.c>
    millisec.zip  37734  911205  MSC/asm src for millisecond res timing
    mschrt3.zip   53708  910605  High-res timer toolbox for MSC 5.1
    msec_12.zip    8484  920320  High-def millisec timer v1.2 (C,ASM)
    ztimer11.zip  77625  920428  Microsecond timer for C, C++, ASM
        (also at Garbo as /pc/c/ztimer11.zip)

    pd1:<msdos.turbo-c>
    tchrt3.zip    53436  910606  High-res timer toolbox for Turbo C 2.0
    tctimer.arc   20087  891030  High-res timing of events for Turbo C
        (same as /pc/c/tctimer.zoo at Garbo; both are version 1.0)

    For Turbo Pascal users, source and object code are downloadable in
        pd1:<msdos.turbopas>bonus507.zip at Simtel
        /pc/turbopas/bonus507.zip at Garbo.
    Also see "Q: How is millisecond timing done?" in FAQPAS.TXT,
    downloadable as /pc/ts/tsfaqp14.zip from Garbo.

Subject:  703. How can I find the error level of the previous program?

    (rev: 20 June 1993)  First, which previous program are you talking
    about?  If your current program ran another one, when the child
    program ends its error level is available to the program that
    spawned it.  Most high-level languages provide a way to do this; for
    instance, in Turbo Pascal it's Lo(DosExitCode) and the high byte
    gives the way in which the child terminated.  In Microsoft C, the
    exit code of a synchronous child process is the return value of the
    spawn-type function that creates the process.

    If your language doesn't have a function to return the error code
    of a child process, you can use INT 21 function 4D (get return
    code).  By the way, this will tell you the child's exit code and the
    manner of its ending (normal, Ctrl-C, critical error, or TSR).

    It's much trickier if the current program wants to get the error
    level of the program that ran and finished before this one started.
    G.A.Theall has published source and compiled code to do this; the
    code is downloadable as
        pd1:<msdos.batutl>errlvl13.zip at Simtel
        /pc/batchutil/errlvl13.zip at Garbo.
    (The code uses undocumented features in DOS 3.3 through 5.0.  Theall
    says in the .DOC file that the values returned under 4DOS or other
    replacements won't be right.)

Subject:  704. How can a program set DOS environment variables?

    (rev: 13 June 1993)  Program functions that read or write "the
    environment" typically access only the program's copy of it.  What
    this Q really wants to do is to modify the active environment, the
    one that is affected by SET commands in batch files or at the DOS
    prompt.  You need to do some programming to find the active
    environment, and that depends on the version of DOS.

    A fairly well-written article in {PC Magazine} 28 Nov 1989
    (viii:20), pages 309-314, explains how to find the active
    environment, and includes Pascal source code.  The article hints at
    how to change the environment, and suggests creating paths longer
    than 128 characters as one application.

    Now as for downloadable source code, there are many possibilities.
    Of the ones I looked at (not all of them), I liked
        pd1:<msdos.envutil>rbsetnv1.zip at Simtel
        /pc/envutil/rbsetnv1.zip at Garbo
    the best.  It includes some utilities to manipulate the environment,
    with source code in C.  A newer program is
        pd1:<msdos.batutl>strings2.zip at Simtel
        part of /pc/pcmag/vol11n22.zip at Garbo,
    which is the code from {PC Magazine} 22 Dec 1992 (xi:22).

    You can also use a call to INT 2E, Pass Command to Interpreter for
    Execution; see Ralf Brown's interrupt list for details and cautions.

Subject:  705. How can I change the switch character to - from /?

    Under DOS 5.0, you can't -- not completely, anyway.  INT 21 function
    3700, get switch character, always returns a '/' (hex 2F) -- and the
    DOS commands don't even call that function, but hard code '/' as the
    switch character.

    Some history:  DOS used to let you change the switch character by
    using SWITCHAR= in CONFIG.SYS or by calling DOS function 3701.  DOS
    commands and other programs called DOS function 3700 to find out the
    switch character.  If you changed the switch character to '-' (the
    usual choice), you could then type "dir c:/c700 -p" rather than "dir
    c:\c700 /p".  Under DOS 4.0, the DOS commands ignored the switch
    character but functions 3700 and 3701 still worked and could be used
    by other programs.  Under DOS 5.0, even those functions no longer
    work, though all DOS functions still accept '/' or '\' in file
    specs.

    You can reactivate the functions to get and set switchar by using
    programs like SLASH.ZIP or the sample TSR called SWITCHAR in
    amisl091.zip (see "How can I write a TSR?", below.)  DOS commands
    will still use the slash, but non-DOS programs that call DOS func-
    tion 3700 will use your desired switch character.  (DOS replacements
    like 4DOS may honor the switch character for internal commands.)

    Some readers may wonder why this is even an issue.  Making '-' the
    switch character frees up the front slash to separate names in the
    path part of a file spec.  This is easier for the ten-fingered to
    type, and it's one less difference to remember for commuters between
    DOS and Unix.  The switch character is the only issue, since all the
    INT 21 functions accept '/' or '\' to separate directory names.

Subject:  706. Why does my interrupt function behave strangely?

    Interrupt service routines can be tricky, because you have to do
    some things differently from "normal" programs.  If you make a
    mistake, debugging is a pain because the symptoms may not point at
    what's wrong.  Your machine may lock up or behave erratically, or
    just about anything else can happen.  Here are some things to look
    for.  (See the next Q for general help before you have a problem.)

    First, did you fail to set up the registers at the start of your
    routine?  When your routine begins executing, you can count on
    having CS point to your code segment and SS:SP point to some valid
    stack (of unknown length), and that's it.  In particular, an
    interrupt service routine must set DS to DGROUP before accessing any
    data in its data segments.  (If you're writing in a high-level
    language, the compiler may generate this code for you automatically;
    check your compiler manual.  For instance, in Borland and Microsoft
    C, give your function the "interrupt" attribute.)

    Did you remember to turn off stack checking when compiling your
    interrupt server and any functions it calls?  The stack during the
    interrupt is not where the stack-checking code expects it to be.
    (Caution:  Some third-party libraries have stack checking compiled
    in, so you can't call them from your interrupt service routine.)

    Next, are you calling any DOS functions (INT 21, 25, or 26) in your
    routine?  DOS is not re-entrant.  This means that if your interrupt
    happens to be triggered while the CPU is executing a DOS function,
    calling another DOS function will wreak havoc.  (Some DOS functions
    are fully re-entrant, as noted in Ralf Brown's interrupt list.
    Also, your program can test, in a way too complicated to present
    here, when it's safe to call non-re-entrant DOS functions.  See INT
    28 and functions 34, 5D06, 5D0B of INT 21; and consult {Undocumented
    DOS} by Andrew Schulman.  Your program must read both the "InDOS
    flag" and the "critical error flag".)

    Is a function in your language library causing trouble?  Does it
    depend on some initializations done at program startup that is no
    longer available when the interrupt executes?  Does it call DOS (see
    preceding paragraph)?  For example, in both Borland and Microsoft C
    the memory-allocation functions (malloc, etc..) and standard I/O
    functions (scanf, printf) call DOS functions and also depend on
    setups that they can't get at from inside an interrupt.  Many other
    library functions have the same problem, so you can't use them
    inside an interrupt function without special precautions.

    Is your routine simply taking too long?  This can be a problem if
    you're hooking on to the timer interrupt, INT 1C or INT 8.  Since
    that interrupt expects to be called 18.2 times a second, your
    routine -- plus any others hooked to the same interrupts -- must
    execute in less than 55 ms.  If they use even a substantial fraction
    of that time, you'll see significant slowdowns of your foreground
    program.  A good discussion is downloadable as
        pub/msdos/simtel20/info/INTSHARE at ni.funet.fi
        pd1:<msdos.info>intshare at Simtel.

    Did you forget to restore all registers at the end of your routine?

    Did you chain improperly to the original interrupt?  You need to
    restore the stack to the way it was upon entry to your routine, then
    do a far jump (not call) to the original interrupt service routine.
    (The process is a little different in high-level languages.)

Subject:  707. How can I write a TSR (terminate-stay-resident utility)?

    (rev: 20 June 1993)  There are books, and there's code to download.

    First, the books:

    - Ray Duncan's {Advanced MS-DOS}, ISBN 1-55615-157-8, gives a brief
      checklist intended for experienced programmers.  The ISBN is for
      the second edition, through DOS 4; but check to see whether the
      DOS 5 version is available yet.

    - {DOS 5:  A Developer's Guide} by Al Williams, ISBN 1-55851-177-6,
      goes into a little more detail, 90 pages worth]

    - Pascal programmers might look at {The Ultimate DOS Programmer's
      Manual} by John Mueller and Wallace Wang, ISBN 0-8306-3534-3, for
      an extended example in mixed Pascal and assembler.

    - For a pure assembler treatment, check Steven Holzner's {Advanced
      Assembly Language}, ISBN 0-13-663014-6.  He has a book with the
      same title out from Brady Press, but it's about half as long as
      this one.

    - For C programmers, there's a chapter in Herbert Schildt's {The Art
      of C:  Elegant Programming Solutions}.  I haven't seen the book,
      but a posted article recommended it.

    Next, the code.  Some of it is companion code to published articles,
    which are also listed below:

    - The Alternate Multiplex Interrupt Specification, downloadable as
        pd1:<msdos.info>altmpx35.zip at Simtel
        /pc/programming/altmpx35.zip at Garbo
        /afs/cs/user/ralf/pub/altmpx35.zip at cs.cmu.edu

    - Ralf Brown's assembly-language implementation of the spec, with
      utilities in C, downloadable as
        pd1:<msdos.asmutl>amisl091.zip at Simtel
        /pc/c/amisl091.zip at Garbo
        /afs/cs/user/ralf/pub/amisl091.zip at cs.cmu.edu

    - Douglas Boling's MASM template for a TSR is downloadable as
        pd1:<msdos.asmutl>template.zip at Simtel.

    - A posted article mentions Boling's "Strategies and Techniques for
      Writing State-of-the-Art TSRs that Exploit MS-DOS 5", Microsoft
      Systems Journal, Jan-Feb 1992, Volume 7, Number 1, pages 41-59,
      with examples downloadable in
          pd1:<msdos.msjournal>msjv7-1.zip at Simtel

    - code for Al Stevens's "Writing Terminate-and-Stay-Resident
      Programs", Computer Language, February 1988, pages 37-48 and March
      1988, pages 67-76 is downloadable as
        pd1:<msdos.c>tsrc.zip at Simtel

    - software examples to accompany Kaare Christian's "Using Microsoft
      C Version 5.1 to Write Terminate-and-Stay-Resident Programs",
      Microsoft Systems Journal, September 1988, Volume 3, Number 5,
      pages 47-57 are downloadable as
          pd1:<msdos.msjournal>msjv3-5.arc at Simtel

    Finally, there are commercial products, of which TesSeRact (for
    C-language TSRs) is one of the best known.

Subject:  708. How can I write a device driver?

    Many books answer this in detail.  Among them are {Advanced MS-DOS}
    and {DOS 5: A Developer's Guide}, cited in the preceding Q.
    Michael Tischer's {PC System Programming}, ISBN 1-55755-036-0, has
    an extensive treatment, as does Dettman and Kyle's {DOS Programmer's
    Reference: 2d Edition}, ISBN 0-88022-458-4.  For a really in-depth
    treatment, look for a specialized book like Robert Lai's {Writing
    MS-DOS Device Drivers}, ISBN 0-201-13185-4.

Subject:  709. What can I use to manage versions of software?

    (rev: 7 Aug 1993)  A port of the Unix RCS utility is downloadable
    from Simtel as pd1:<msdos.gnuish>rcs55ax.zip (EXE and docs) and
    rcs55as.zip (source).  I haven't used it myself, but I understand
    this is no longer limited to one-character extensions on filenames
    (so .CPP and .BAS are fine).

    As for commercial software, I posted a question asking for readers'
    experiences in July 1993.  Seven readers responded.  PVCS from
    Intersolv (formerly Polymake) got five positive reviews, though
    several readers commented that it's expensive; RCS from MKS got one
    positive and one negative review; Burton TLIB got one negative
    review; DRTS from ILSI got one positive review.

Subject:  710. What's this "null pointer assignment" after my C program
               executes?

    (rev: 18 Apr 1993)  Somewhere in your program, you assigned a value
    _through_ a pointer without first assigning a value _to_ the
    pointer.  (This might have been something like a strcpy or memcpy
    with a pointer as its first argument, not necessarily an actual
    assignment statement.) Your program may look like it ran correctly,
    but if you get this message you can be certain that there's a bug
    somewhere.

    Microsoft and Borland C, as part of their exit code (after a return
    from your main function), check whether the location 0000 in your
    data segment contains a different value from what you started with;
    if so, they infer that you must have used an uninitialized pointer.

    To track down the problem, you can put exit( ) statements at various
    spots in the program and narrow down where the uninitialized pointer
    is being used by seeing which added exit( ) makes the null-pointer
    message disappear.  Or, in the debugger, set a watch at location
    0000 in your data segment, assuming you're in small or medium model.
    (If data pointers are 32 bits, as in the compact and large models, a
    null pointer will overwrite the interrupt vectors at 0000:0000 and
    probably lock up your machine.)

    Under MSC/C++ 7.0, you can declare the undocumented library function

        extern _cdecl _nullcheck(void);

    and then sprinkle calls to _nullcheck( ) through your program at
    regular intervals.

    Borland's TechFax document #TI726 discusses the null pointer
    assignment from a Borland point of view.  It's one of many documents
    downloadable as part of
        pd1:<msdos.turbo-c>bchelp10.zip at Simtel
        /pc/turbopas/bchelp10.zip at Garbo.

Subject:  711. How can my program tell if it's running under Windows?

    (rev: 18 Apr 1993)  Set AX=4680 and execute INT 2F.  If AX contains
    0, you're in Windows real mode or standard mode (or under the DOS
    5.0 shell).  Otherwise, set AX=1600 and INT 2F.  If AL does not
    contain 0 or 80, you're in Windows 386 enhanced mode.  See {PC
    Magazine} 24 Nov 1992 (xi:20), pages 492-493.

    When Windows 3.0 or 3.1 is running, the DOS environment will contain
    a definition of the string windir, in lower case.

    For more information, see {PC Magazine} 26 May 1992 (xi:10) pages
    345-346.  A program, WINMODE, is available as part of
        pd1:<msdos.pcmag>vol11n10.zip at Simtel
        /pc/pcmag/vol11n10.zip at Garbo.

Subject:  712. How do I copyright software that I write?

    (new: 5 Apr 1993) The following is adapted (and greatly condensed)
    from chapter 4 of the Chicago Manual of Style (13th edition, ISBN
    0-226-10390-0).  Disclaimer:  I am not a lawyer, and this is not
    legal advice.  Also, there are very likely to be differences in
    copyright law among nations.  No matter where you live, if
    significant money may be involved, get legal advice.

    That said, in the U.S. (at least), when you write something, you own
    the copyright.  (The most significant exception to programmers is
    "works made for hire", i.e., something you write because your
    employer or client pays you to.  A contract, agreed in advance, can
    vest the copyright in the programmer even if an employee.)  You
    don't have to register the work with the Copyright Office unless
    (until) the copyright is infringed and you intend to bring suit;
    however, it is easier to recover damages in court if you did
    register the work within three months of publication.

    From paragraph 4.16 of the Chicago Manual:  "... the ▌copyright¿
    notice consists of three parts: (1) the symbol ▌C-in-a-circle¿
    (preferred because it also suits the requirements of the Universal
    Copyright Convention), the word 'Copyright', or the abbreviation
    'Copr.', (2) a date--the year of first publication, and (3) the name
    of the copyright owner.  Most publishers also add the phrase 'All
    rights reserved' because it affords some protection in Central and
    South American countries ...."  Surprise:  "(C)" is legally not the
    same as the C-in-a-circle, so those of us who are ASCII-bound must
    use the word or the abbreviation.


section A. Downloads
====================

Subject:  A01. What are Simtel, Garbo, and wustl?

    (rev: 26 July 1993) These are three of the most popular archive
    sites, with a few bazillion files available for downloading by ftp.
    (For email access, see next Q.)  Everything is free for downloading,
    though many of the files are shareware and you're expected to send a
    payment directly to the authors if you use them regularly.

    In comp.archives.msdos.d, Samuel Ko posts a two-part "Useful
    MSDOS Programs at SIMTEL20 and Garbo"; it's downloadable as
        pd1:<msdos.info>useful27.zip at Simtel
        /pc/filelist/useful27.zip at Garbo
        /pub/usenet/news.answers/msdos-archives/part* at rtfm.mit.edu.
    For rtfm.mit.edu instructions, see "Where are FAQ lists archived?"
    in section C, "More information".

    A few words about file names and versions:  Many files at the
    archive sites are updated from time to time.  I have verified the
    filenames in this FAQ list as follows:

        Garbo: from /pc/INDEX.ZIP as of 10 Jun 1993
        Simtel: from pd1:<msdos.filedocs>simibm.zip as of 1 Jun 1993
        rtfm.mit.edu: via ftp access on 10 Apr 1993

    If you can't find a file given in these articles as mumble12.zip,
    perhaps there's a newer version; try mumble13.zip or mumble14.zip,
    or mumble*.zip if your ftp program supports wildcards (most do so).
    Please let me know of any out-of-date file names in these FAQs and
    I'll gladly update them.

    I have tried to list both Garbo and Simtel directory and file names
    for every file mentioned for downloading.  If you see a listing for
    only one of them, it means that I couldn't find the file at the
    other site, or that the other site's catalog shows an old version.

    Also remember that caps and lower case filenames are not inter-
    changeable at most archive sites, though they are at Simtel.

    1) Simtel = wsmr-simtel20.army.mil ▌192.88.110.20¿

    is located in New Mexico, USA.  For instructions, see these monthly
    articles in comp.archives.msdos.announce:

        SIMTEL20 archives info for Internet FTP users
        How to find files in the SIMTEL20 msdos collection
        How to order SIMTEL20 files via e-mail
        How to upload files to SIMTEL20

    These are downloadable from Simtel as pd1:<msdos.starter>simtel20.inf
    and pd1:<msdos.filedocs>aaaread.me, mailserv.inf, and upload.inf.
    If you have no ftp access, you can get these files (and anything
    else) by email; see the next Q.

    If Simtel is busy, you might try the mirror site oak.oakland.edu,
    which is operated by the University of Rochester (Michigan).  Both
    are maintained by Keith Petersen ([e-mail] or
    [e-mail]), so oak will probably be updated faster
    than any other mirror.  At Oak, the directories /pub/msdos/*
    correspond to Simtel's pd1:<msdos.*>, so the starter files mentioned
    above are downloadable as /pub/msdos/starter/simtel20.inf and
    /pub/msdos/filedocs/aaaread.me, mailserv.inf, and upload.inf.

    2) Garbo = garbo.uwasa.fi ▌128.214.87.1¿

    is located at the University of Vaasa in Finland and maintained by
    Timo Salmi ([e-mail]) and others.  Garbo and Simtel contain many
    of the same files, but there are many differences too.  Among them:
    the directory structures differ greatly, and case is significant in
    directory and file names at Garbo.

    3) wustl = wuarchive.wustl.edu ▌128.252.135.4¿

    mirrors both Garbo (in /mirrors4/garbo.uwasa.fi) and Simtel (in
    /mirrors/msdos).  As with any mirror site, it may lag by a day or
    two, so you may not want to try it on the same day you see an upload
    notice posted.

    4) others

    A comprehensive list of MS-DOS archive sites is downloadable as
    /pc/pd2/moder26.zip at Garbo.

    For archie.au via Telnet (different from the Archie file-finding
    mail servers):  Oceanian users should try archie.au first.  Paul
    Brooks has written to say that it "mirrors Garbo and Simtel-20 (in
    /micros/pc/simtel-20, /micros/pc/garbo) as well as many other
    archives.  Telnetting to 'archie.au' and logging on as 'archie' (no
    password) will access the Oceanic ARCHIE server." Email Craig Warren
    ([e-mail]) for instructions if needed.

Subject:  A02. I have no ftp access.  How can I get files from the
               archives?

    (rev: 14 June 1993) First, be _sure_ that you have no ftp access
    before trying email methods.  (Ask your sysadmin, or a knowledgeable
    user at your site.)  ftp is better for you because it's faster, and
    it uses less net resources too.

    When using an email server, make sure the Reply-to path in your
    message is valid.  If it's not, you'll get no reply from the server.
    Do wait a few days before assuming you're not going to get a
    response; some servers have long pending queues.  After a suitable
    wait, get your sysadmin's help to correct your reply-to, and send
    your message again.

    Occasionally a machine goes down for an extended period, which may
    prevent a timely reply to your message.  If you're sure your message
    bears a good reply path and you haven't got a reply in a week or so,
    you might send your message again, once.  Don't post it as an
    article in a newsgroup.

    For files from Simtel, see "How to order SIMTEL20 files via e-mail",
    posted monthly in comp.archives.msdos.announce; or send email
    containing only the word "help" to [e-mail].  For
    instructions on using Garbo's email server, send a request to
    Timo Salmi at [e-mail].

    The DEC Western Research Labs server will get files from any ftp
    site by ftp and then email them to you.  Send email containing
    "help" to [e-mail].

Subject:  A03. Can I get archives on CD-ROM?

    (rev: 24 May 1993) Copies of the SIMTEL20 MS-DOS, Macintosh and
    Unix-C collections (also of wuarchive, cica, and others) are
    available from Walnut Creek CDROM, 1547 Palos Verdes, Suite 260,
    Walnut Creek, CA 94596-2228, telephone [phone] or +1 510
    674-0783, or FAX [phone], or email [e-mail].

    For a catalog of disks available, send email to [e-mail], or
    ftp the catalog as /cdrom/catalog from cdrom.com.

Subject:  A04. Where do I find program <mumble>?

    (rev: 7 Aug 1993)  You _are_ asking about shareware, freeware, or
    public-domain programs, right?  Commercial software is not legally
    distributed through the net, in general.  (Occasionally vendors will
    make patches available, but these are useful only if you already
    have the software.)

    That said, there are several newsgroups to help you find a program.
    comp.binaries.ibm.pc.wanted is generally the best place to ask your
    question.  Please review the guidelines in "What other newsgroups
    should I know about?" in section 1, "General questions".

    Download and check the indexes from Simtel and Garbo (see next Q).
    Unless what you're looking for is commercial software, there's a
    good chance it will be at one or both of those sites.

    The Archie servers maintain directories of many (not all) ftp sites
    worldwide.  You can Telnet to a server or client to search for
    files, or perform a search by email.

Subject:  A05. How can I check Simtel or Garbo before I post a request
               for a program?

    (rev: 26 July 1993) Simtel and Garbo have indexes of their contents,
    which you can download and then search off line.

    Garbo's index file, /pc/INDEX.ZIP, contains an annotated list, often
    updated, of the MS-DOS files there.  The news file /pc/pd2/news-pd2
    contains selected news on all MS-DOS directories at Garbo.

    Simtel's index files, in pd1:<msdos.filedocs>, are updated several
    times a month.  SIMLIST.ZIP contains a list in text format.  But you
    may prefer the file SIMIBM.ZIP, which is comma-delimited for easy
    use with any of these search facilities:

    - Two downloadable search programs are SIMTEL35.ARC and
      SIMDIR22.ZIP.  Of the two, I find I use SIMDIR much more often.

    - dBASE III or IV users can load the index from SIMLIST.ZIP using
      instructions in SIMIBM.INF and SIMIBM.DB3.

    - PC-FILE users should get SIMIBM.HDR, which tells how to use
      SIMIBM.IBM.

Subject:  A06. How do I download and decode a program I found?

    (rev: 7 Aug 1993)  See the "Starter kit" and "Beginner's guide to
    binaries" in comp.binaries.ibm.pc, usually posted on the first and
    15th of every month.  Please wait for these articles to come around;
    don't post a request.  If you can't wait (if?, bwaa-haa-haa), they
    are downloadable from
        Garbo as /pc/doc-net/starter.kit and bin.man
        rtfm.mit.edu, in /pub/usenet/comp.binaries.ibm.pc .  The file
            names are quite long; try look for names of the form
            *starter.kit* and *bin.man*
    For general instructions on rtfm.mit.edu, see "Where are FAQ lists
    archived?" in section C, "More information".

    Most binaries are posted and sent through email in 'uuencode'
    format.  The starter kit contains a uudecode program to turn this
    file back into binary.  Since the uuencoded file is bigger than the
    binary, you'll save connect time if you can uudecode it and then
    download the binary file.  Remember to set file type to binary.

Subject:  A07. Where is UUDECODE?

    You can find it at Simtel and Garbo, but it's easier to take it from
    the "starter kit" mentioned in the preceding Q.

    If you're logged in at a Unix site, there's almost certainly a
    uudecode there:  just type "uudecode" followed by a space and the
    file name.  The binary file is 25% smaller than the uuencoded file,
    so you'll save connect time if you can uudecode it on the Unix host
    and then download the binary file.  Remember: set file type binary.

Subject:  A08. Why do I get errors when extracting from a ZIP file I
               downloaded?

    (rev: 5 Apr 1993) There are many possible causes, but two of them
    probably account for 95% of all problems.

    1) File transmission:  You must tell the archive site to transfer
    .ZIP files in binary mode.  Depending on your software, you may also
    need to set your local software to receive files in binary mode.

    2) Unzipping program:  Make sure you aren't using an obsolete
    version.  In <[e-mail]> on 29 Mar
    1993, Keith Petersen, Simtel administrator, wrote:  "SIMTEL20 has
    standardized on the Info-ZIP group's ZIP and UNZIP because they are
    freely distributable and they have no restrictions on exporting.
    The latest version of Info-ZIP's ZIP and UNZIP can always be found
    in directory PD1:<MSDOS.ZIP> and will always have the name
    'Info-ZIP' in the description to make them easy to locate."  PKUNZIP
    version 1.10 may not unzip newer stuff from archive sites because
    site administrators have now embraced version 2.04.  Also see
    "What's the current version of UNZIP?" in section B, "Vendors and
    products".

section B. Vendors and products
===============================

Subject:  B01. How can I contact Borland?

    (rev: 18 Apr 1993)  Borland has set up these email addresses.
    However, none of them is for technical support such as help with
    finding your own programming errors and explaining compiler
    messages.

    - [e-mail] will reply to any message with 17K of info on
      Borland Pascal with Objects 7.0 and Turbo Pascal 7.0.

    - [e-mail] is for questions about prices and
      features of products, replacing bad or missing disks, info on
      upgrades, etc.  They do not accept emailed credit-card numbers.

    - [e-mail] will take "a well-documented bug report" and send
      an automated response, but will not give you a workaround or a
      scheduled fix date or even confirm that it is or is not considered
      a bug.  "The purpose of [e-mail] is to improve future
      products sooner, not as a substitute for tech support channels."

    Email tech support is available only through Compuserve (GO BOR).

    Telephone support is provided through separate phone numbers for
    most products.  If you're calling from the U.S., dial [phone]
    for a recorded list of toll numbers to call.  Borland's BBS is at +1
    408 439 9096.  The surface-mail address is

        Technical Support Department
        Borland International
        P.O. Box 660001
        Scotts Valley CA 95067-0001, USA.

    You'll need to give your product's name, version, and serial number.

    Borland's TechFax documents are also available for download:
        pd1:<msdos.turbo-c>bchelp10.zip from Simtel
        /pc/turbopas/bchelp10.zip from Garbo.
    These documents are detailed answers to common questions about Turbo
    C and Borland C products, and aggregate several hundred Kbytes.

Subject:  B02. How can I contact Microsoft?

    (rev: 18 Apr 1993) Individual employees of Microsoft (not MicroSoft,
    please]) post here sometimes.  Their addresses all take the form
    [e-mail].  However, Microsoft as a company does not
    provide product support through the Internet, as far as I'm aware.
    Technical support through your modem is available on Compuserve (GO
    MICROSOFT) or via Microsoft's BBS at [phone] in the U.S., or
    [phone] in Canada.

    If you want to place an order or get general pre-sales information,
    call the appropriate sales and service number:

        U.S. end-user sales                   [phone]
        U.S. corporate/gov't/reseller/
                 educational sales            [phone]
        Canadian sales                        [phone]
        International sales                  [phone]

    For tech support you must make an ordinary long-distance phone call.
    Microsoft has separate incoming phone numbers for many products.
    Since it's your nickel, first check your documentation to see if a
    phone number is listed.  Here are phone numbers (as of 1 June 1992)
    for a few products of most interest to the readers of this group:

        C/C++               [phone]
        MASM                [phone]
        DOS Upgrade Users   [phone] (for 90 days after first call)
        Windows Users       [phone]

    If you can't find the direct number any other way, call the "master"
    numbers below or the sales numbers a few paragraphs above.  You'll
    get the "voice mail phone tree from h-ll" but you'll eventually get
    to the right department.  They don't provide technical assistance,
    but a voice menu will help you find the current phone number for the
    department you need.

        U.S. end-user product support         [phone]
        U.S. languages support                [phone]

    You can also write to Microsoft Product Support, 16011 NE 36th Way,
    Box 97017, Redmond WA 98073-9717, USA.

Subject:  B03. What's the current version of UNZIP?

    (rev: 14 June 1993)  As of April 1993, the administrators of Garbo
    and Simtel are accepting uploads in the ZIP 2.0 format.  You can use
    the free Info-ZIP versions, or PKZIP 2.04g (not 2.04c or 2.04e).
    Simtel has standardized on the Info-ZIP versions for several
    reasons, as explained in an article posted 29 Mar 1993 in
    comp.archives.msdos.announce.

    The official site for the latest versions of Info-ZIP's Zip and
    unZip programs is quest.jpl.nasa.gov ▌128.129.75.43¿ in directory
    /pub.  Also downloadable are these files, in pd1:<msdos.zip> at
    Simtel and /pc/arcers at Garbo (source code at Garbo in /unix/arcers):

        unz50p1.exe   UnZip 5.0p1 program and documentation
        unz50p1.zip   UnZip 5.0p1 source code
        zip19p1x.zip  Zip 1.9p1 .EXEs and docs (PKZIP 2.04 compatible)
        zip19p1.zip   Zip 1.9p1 source code (PKZIP 2.04 compatible)

    An advantage of the Info-ZIP versions is that are not restricted to
    MS-DOS.  Look at quest.jpl.nasa.gov for versions for all supported
    operating systems.  At Simtel, look in pd8:<misc.unix> and
    pd8:<misc.vaxvms> for unix and VAX/VMS versions; the source code in
    pd8:<misc.unix> also compiles under MS-DOS and VAX/VMS.

    PKZIP and PKUNZIP are shareware products of PKWARE Inc.  The current
    version is 2.04g, which is the third official version after 1.10.
    You can download them from PKWARE's bulletin board, [phone],
    or from Garbo as /pc/arcers/pkz204g.exe.  U.S. law forbids U.S.
    archive sites from making them available.

    By the way, if you want to develop your own utilities, you will find
    the ZIP 2.0 data structures described in the downloadable file
    pd1:<msdos.zip>appnote.zip at Simtel.

Subject:  B04. What's in Borland Pascal/Turbo Pascal 7.0?

    You can send email to [e-mail] and get an automatic
    reply of the 17K information file from Borland, or the file is
    downloadable (6k, ZIPped) as /pc/turbopas/bp7-info.zip from
    garbo.uwasa.fi.

Subject:  B05. What's in Microsoft Visual C++?

    (new: 24 May 1993)  This is the replacement for Microsoft C/C++
    7.0.  It comes in Standard and Professional versions, as well as an
    upgrade from MSC 7.0.  The Professional upgrade is $139 in U.S. and
    includes all software but less than half the full set of manuals.

    According to Microsoft Sales, [phone] in the U.S., the
    Professional edition can develop applications for Windows or good
    ol' DOS and includes the optimizing compiler; the Standard edition's
    compiler lacks the optimization and can't develop Windows
    applications.

Subject:  B06. Where is Microsoft C 8.0?

    There won't be an 8.0.  Visual C++ is the upgrade to C/C++ 7.0 (see
    previous Q).

section C. More information
===========================

Subject:  C01. Are there any good on-line references for PC hardware
               components?

    (rev: 28 July 1993) I have heard good reports of HELPPC21, which is
    downloadable as
        pd1:<msdos.info>helppc21.zip at Simtel
        /pc/programming/helppc21.zip at Garbo.

    This hypertext system contains much information on ports and other
    hardware, as well as some overlap with Ralf Brown's interrupt list
    (see next Q).  It is shareware ($25).

Subject:  C02. Are there any good on-line references for PC interrupts?

    (rev: 6 June 1993)  The definitive work is Ralf Brown's interrupt
    list, which is packed with information on documented and
    (officially) undocumented BIOS and DOS interrupts, DOS tables, and
    interrupts hooked by many software packages.

    The interrupt list comes from CS.CMU.EDU ▌128.2.222.173¿ in
    /afs/cs/user/ralf/pub (switch there with a *single* command) as
    inter35a.zip, inter35b.zip, and inter35c.zip.  It's downloadable as
        pd1:<msdos.info>inter35*.zip from Simtel
        /pc/programming/inter35*.zip from Garbo.
    These versions were uploaded in early June 1993; updates are
    announced every few months in comp.archives.msdos.announce.

    There is a book, {PC Interrupts:  A Programmer's Reference to BIOS,
    DOS, and Third-Party Calls} by Ralf Brown and Jim Kyle
    (Addison-Wesley; ISBN 0-201-57797-6).  This corresponds to INTER26
    with the most important new material from INTER27, so the on-line
    list contains more current information (and more information) than
    the book.

Subject:  C03. What and where is "Ralf Brown's interrupt list"?

    See the preceding Q.

Subject:  C04. Where can I find lex, yacc, and language grammars?

    The FAQ list of the comp.compilers newsgroup answers this for Basic,
    C, Pascal, and other languages.  See later in this section.

Subject:  C05. What's the best book to learn programming?

    Sorry, this FAQ list cannot settle religious arguments.

    Much of the heat over this topic arises because each person believes
    that the book that he or she learned from is the best book.  But my
    observation is that different people have very different experiences
    of the same book.  The only person who can tell you which is the
    best book for learning a given topic is you.

    Your best bet is to go to a fairly well-stocked bookstore when you
    have a couple of hours to spare.  Start at one end of the shelf and
    work your way methodically through every book that looks like it
    might cover what you want to learn.  Look at the tables of contents;
    read a page or two from each book.  Then make your decision.  If
    money is a problem, or if you're not sure of your choice, check out
    your top two or three from your library.

Subject:  C06. Where are FAQ lists archived?

    (rev: 27 Apr 1993) Very possibly the FAQ list you want is already at
    your site.  Check the newsgroup news.answers; if your site doesn't
    carry news.answers, check comp.answers, rec.answers, etc., according
    to the top-level name in the FAQ list's "home" newsgroup.  Articles
    are posted to the *.answers groups in a way that should make them
    last until the next versions are posted.  If they expire sooner at
    your site, you might want to lobby your sysadmin to treat the
    moderated *.answers groups as a special case and grant them longer
    expiry times than other groups.

    To ftp the FAQ lists, connect to rtfm.mit.edu, which is operated by
    Jonathan Kamens ([e-mail]) at MIT.  Change to directory
    /pub/usenet/news.answers.  The name of the file that you want is the
    Archive-name from the top of the article.  For instance, to retrieve
    this article you would get msdos-programmer-faq/part4.

    By email (only if you have no ftp access, please), the server is
    [e-mail]; file names omit the leading "/pub/".  For
    instructions about the mail server, send a message with "help" and
    "index" on different lines.

    Not just FAQ lists, but every article listed in the "List of
    Periodic Informational Postings" (LoPIP) can be obtained by ftp or
    email from rtfm.mit.edu.  If you have an old copy of an
    informational article, look for an "Archive-name" at the beginning;
    rtfm.mit.edu stores it under that name in /pub/usenet/news.answers.
    If the article has no Archive-name, check the first name on the
    Newsgroups line and change to that directory under /pub/usenet.

Subject:  C07. Where can I get the latest copy of this FAQ list?

    (rev: 22 Apr 1993)  It is posted to news.answers in such a way that
    it should stick around until the next version has been posted.
    Please check news.answers or comp.answers first, looking for the
    Subject line "comp.os.msdos.programmer FAQ".

    If the article has expired from your site's news.answers, or your
    site doesn't get news.answers, you can retrieve the latest version
    of this list as
        /pub/usenet/news.answers/msdos-programmer-faq/part* via ftp or
            email from rtfm.mit.edu; see previous Q
        pd1:<msdos.info>faqp*.zip from Simtel
        /pc/doc-net/faqp*.zip from Garbo.

Subject:  C08. How do I use ftp?

    (new: 16 Mar 1993) I have been much impressed with {The Whole
    Internet User's Guide and Catalog} by Ed Krol (O'Reilly &
    Associates, ISBN 1-56592-025-2).  It gives lots of information on
    using ftp, email, Telnet, Archie, etc.  As a new user of ftp
    (January 1993), I found the information made me productive quickly.

    Disclosure:  Though I don't believe it has biased my judgment, you
    should know that O'Reilly sent me a free evaluation copy.

    You may also want to look for the "Beginner's Guide to FTP", posted
    periodically in comp.binaries.ibm.pc.  You can retrieve it from
    rtfm.mit.edu (see "Where are FAQ lists archived?", above), in
    /pub/usenet/comp.binaries.ibm.pc, as (hang on])
    v21inf05:_b.m,_B_s_G_t_F_V1.7_(p_01_01) .

(end of comp.os.msdos.programmer FAQ)
--
Stan Brown, Oak Road Systems                    [e-mail]

Can't find FAQ lists?  ftp to 'rtfm.mit.edu' and look in /pub/usenet
(or email me >>> with valid reply-to address <<< for instruct