From brown@NCoast.ORG Thu Aug 6 22:25:09 1992
Newsgroups: comp.os.msdos.programmer,news.answers
From: brown@NCoast.ORG (Stan Brown)
Subject: comp.os.msdos.programmer FAQ part 1 of 4
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Sat, 25 Jul 1992 15:57:07 GMT
Followup-To: comp.os.msdos.programmer
Supersedes: <1992Jun26.024804.4121@NCoast.ORG>
Archive-name: msdos-programmer-faq/part1
Last-modified: 19 July 1992
Welcome!
This is the monthly FAQ list (Frequently Asked Questions list) for the
newsgroup comp.os.msdos.programmer. It's intended to reduce the noise
level in comp.os.msdos.programmer that results from the repetition of
FAQs, correct answers, wrong answers, corrections to the wrong answers,
corrections to the corrections, debate, etc.
Because it's quite long, I've broken this list into four parts, of which
you're now reading part 1. (If you have last month's version of this
FAQ list, you may want to look at the diffs rather than reread three
long articles. Look for "comp.os.msdos.programmer FAQ diff" in the
Subject lines.) I've posted the four parts of this article, and the
four parts of diffs, as single threads so that most newsreaders will
let you extract either of them in one operation.
This list should serve as a repository of the canonical "best" answers.
So 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.) If the posting date is
more than six weeks in the past, see instructions in the last part of
this list for how to get an updated copy.
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
brown@ncoast.org
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) list you need. In that part, then search for that question
number. For example, while you're reading part 2 of this list in trn,
the 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. 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. How can I change the stack size in Borland's C compilers?
206. 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 or output has been redirected?
Contents--part 3 of 4
=====================
section 4. Disks and files
401. What drive was the PC booted from?
402. Which real and virtual disk drives are valid?
403. How can I make my single floppy drive both a: and b:?
404. Why won't my C program open a file with a path?
405. How can I redirect printer output to a file?
406. What's the format of an .EXE header?
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?
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?
Contents--part 4 of 4
=====================
section A. Downloading
A01. What is garbo? What is wustl?
A02. What are Simtel and "mirror sites"? What good are they?
A03. Where do I find program <mumble>?
A04. How can I check Simtel or garbo before I post a request for a
program?
A05. How do I download and decode a program I found?
A06. Where is UUDECODE?
A07. 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 PKZIP?
B04. What's in Microsoft C/C++ 7.0?
B05. What's in Borland C++ 3.0, Turbo C++ 3.0, Application
Frameworks?
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?
Legalistic stuff
================
This article is not in the public domain, but it may be redistributed so
long as this notice, and the information on obtaining the latest copy of
this list, are retained. The code fragments may be used freely; credit
would be appreciated but is not required.
Copyright (C) 1992 Stan Brown, Oak Road Systems
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.
The mention of particular books or programs must not be construed to
reflect unfavorably on any that are not mentioned.
Acknowledgements
================
Many postings 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: Mark Aitchison,
Sanjay Aiyagari, George Almasi, Aaron Auseth, Denis Beauregard, Mike
Black, Glynn Brooks, Paul Brooks, Ralf Brown, Shaun Burnett, Raymond
Chen, Alan Drew, Roland Eriksson, Markus Fischer, George Forsman,
B.Haible, Klaus Hartnegg, Kris Heidenstrom, Joel Hoffman, Michael Holin,
Everett Kaser, Reinhard Kirchner, Dave Kirsch, Sidney Markowitz, Jim
Marks, Dimitri Matzarakis, Ken McKee, Tom Milner, Steve Murphy, Mert
Nickerson, David Nugent, Keith Petersen, Karl Riedling, Arthur Rubin,
Timo Salmi, Ajay Shah, Ya-Gui Wei, Joe Wells, jenk@microsoft.com,
khill@vax1.umkc.edu
(continued in part 2)
--
Stan Brown, Oak Road Systems brown@Ncoast.ORG
From brown@NCoast.ORG Thu Aug 6 22:25:16 1992
Newsgroups: comp.os.msdos.programmer,news.answers
From: brown@NCoast.ORG (Stan Brown)
Subject: comp.os.msdos.programmer FAQ part 2 of 4
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Sat, 25 Jul 1992 16:11:05 GMT
Followup-To: comp.os.msdos.programmer
Supersedes: <1992Jun26.031729.5300@NCoast.ORG>
Archive-name: msdos-programmer-faq/part2
Last-modified: 19 July 1992
(continued from part 1) (no warranty on the code or information)
If the posting date is more than six weeks in the past, see instructions
in the last part of this list for how to get an updated copy.
Copyright (C) 1992 Stan Brown, Oak Road Systems
section 1. General questions
============================
Q101. 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 list first, to make sure
your question isn't already answered.)
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.
When you do post a question, it's good manners to say "email please;
I'll post a summary." Then everybody else in the group doesn't have
to read ten virtually identical responses. Of course, then you have
to follow through. A summary is not simply pasting together all the
email you received. Instead, write your own (brief) description of
the solution: this is the best way to make sure you really
understand it. Definitely don't repost people's cute signatures.
Q102. What is this newsgroup about?
comp.os.msdos.programmer (comp.sys.ibm.pc.programmer until September
1990) concerns programming for MS-DOS systems. The article "USENET
Readership report for Feb 92" in news.lists shows 62,000 readers of
this newsgroup.
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.
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.
Q103. 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").
Q104. What other newsgroups should I know about?
Windows mavens are found in comp.os.ms-windows.programmer.tools and
comp.os.ms-windows.programmer.misc. According to the FAQ list in
the latter, comp.windows.ms.programmer has been replaced by those
two plus comp.os.ms-windows.programmer.win32.
Your best bet is to read the periodic information postings in the
comp.binaries.ibm.pc newsgroup. Specially helpful articles:
Using the comp.binaries.ibm.pc.d groups
Beginner's guide to binaries
Starter kit
About archives and archivers
Please wait for these articles to come around; don't post a request.
Also check out news.announce.newusers, even if you're not a new
user. You may be surprised how much useful information is in the
monthly postings there. Lots of old-timers also get useful stuff
from news.newusers.questions, especially the periodic postings.
Remember that it's good manners to subscribe to any newsgroup and
read it for a while before you post a question. When you post, it's
also good manners to ask for replies to be emailed and then to post
a summary, which you've edited down to the absolute minimum size.
You may also be interested in the following newsgroups. Caution:
Some of them have specialized charters; you'll probably get (and
deserve) some flames if you post to an inappropriate group.
- 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.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.binaries.ibm.pc.archives explains how to use the archive
sites, especially garbo and Simtel. Look for the excellent
periodic postings, such as "Recent msdos uploads to SIMTEL20".
- 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.
section 2. Compile and link
===========================
Q201. What the heck is "DGROUP > 64K"?
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.
Q202. 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 3.0. 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.
Q203. Will Borland C code and Microsoft C code link together?
Not in general. The usual context for this question is that you've
bought a package of application .OBJs or .LIBs that were meant for
use with a compiler that you don't have.
One problem is that each compiler uses calls to undocumented
functions to do things like long integer arithmetic, floating point
arithmetic, and stack checking. And the undocumented functions from
Microsoft are not the same as those from Borland. So a link will
generally fail with "not found" messages for oddball function names
that you can't find in the manuals. Although the link fails, it
usually creates an .EXE file. But if you try to run the program, it
crashes as soon as it tries to call one of those functions.
Another problem is that 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.
A third-party vendor of compiled object libraries can take some
steps to minimize such problems, but it's usually far more cost
effective for the vendor to issue different versions of the software
to be used with different compilers. I looked at this problem a
year or so ago for a client. The choice was between severely
restricting functions of the libraries the client would distribute,
or distributing them in companion disks for use with Microsoft and
Borland respectively. The client chose the latter solution, which
still seems to me the right one.
Q204. Why did my program bomb at run time with "floating point formats
not linked"?
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.
A new solution for Borland C++ 3.0 was posted, but I don't own the
product and have not been able to verify it. Insert these
statements in your program:
extern unsigned _floatconvert;
#pragma extref _floatconvert
Q205. 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.
Q206. 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.
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. Ralf Brown's interrupt list also documents the
.EXE header (including extensions by Borland's TLINK) at INT 21
function 4B, including New Executable and Linear Executable formats.
section 3. Keyboard
===================
Q301. 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.)
Q302. 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.
Q303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del?
You can download the file PD1:<MSDOS.KEYBOARD>CADEL.ZIP, 2534 bytes,
from Simtel. It contains a TSR to do disable those three keys, with
source code in ASM.
To disable only Ctrl-Alt-Del (actually, to change the boot keys to
leftShift-Alt-Del), use DEBOOT.COM. Along with KEYKILL.COM, which
lets you disable up to three keys of your choice, it is at Simtel in
the file PD1:<MSDOS.KEYBOARD>KEYKILL.ARC, 3395 bytes.
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.
Q304. 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 (tested under MSC 5.0 and BC++ 2.0):
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 brown@ncoast.org 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".
Q305. How can my program turn NumLock (CapsLock, ScrollLock) on or off?
You need to twiddle bit 5, 6, or 4 of location 0040:0017. Here's
some code (tested under MSC 5.0 and BC++ 2.0): 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;
}
Q306. 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; you can download
source and object code in PD1:<MSDOS.PCMAG>VOL5N05.ARC from Simtel.
Q307. 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.
Q308. How can my program tell what kind of keyboard is on the system?
Ralf Brown's Interrupt List has a detailed breakdown of the contents
of the BIOS system block that starts at 0040:0000. Bit 4 of byte
0040:0096 is "1=enhanced keyboard installed".
This code is tested under MSC 5.0 and BC++ 2.0:
char far *kbd_stat_byte3 = (char far *)0x00400096UL;
if (0x10 & *kbd_stat_byte3)
/* 101- or 102-key keyboard is installed */
{PC Magazine}'s 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 {PC Magazine} article suggests
a different approach to determining the type of keyboard.
Q309. How can I tell if input or output has been redirected?
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, download the /pc/ts/tspa*.zip
collection of Turbo Pascal units from garbo; or from Simtel,
PD1:<MSDOS.TURBOPAS>TSPA*.ZIP. Source code is not included. Also
see the information in garbo.uwasa.fi:/pc/ts/tsfaq*.zip Frequently
Asked Questions, the Turbo Pascal section.
If you program in C, use isatty( ) if your implementation has it.
Otherwise, you can download PD1:<MSDOS.SYSUTL>IS_CON10.ZIP, 4267
bytes (contains source code) from Simtel.
Good references for the principles are {PC Magazine} 16 Apr 1991
(vol 10 nr 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.
(continued in part 3)
--
Stan Brown, Oak Road Systems brown@Ncoast.ORG
From brown@NCoast.ORG Thu Aug 6 22:25:21 1992
Newsgroups: comp.os.msdos.programmer,news.answers
From: brown@NCoast.ORG (Stan Brown)
Subject: comp.os.msdos.programmer FAQ part 3 of 4
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Sat, 25 Jul 1992 16:11:11 GMT
Followup-To: comp.os.msdos.programmer
Supersedes: <1992Jun26.031736.5354@NCoast.ORG>
Archive-name: msdos-programmer-faq/part3
Last-modified: 19 July 1992
(continued from part 2) (no warranty on the code or information)
If the posting date is more than six weeks in the past, see instructions
in the last part of this list for how to get an updated copy.
Copyright (C) 1992 Stan Brown, Oak Road Systems
section 4. Disks and files
===========================
Q401. 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.).
Q402. 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 in Borland C++ 2.0 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 ");
}
}
Q403. 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.
Q404. 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.
Q405. How can I redirect printer output to a file?
My personal favorite utility for this purpose is PRN2FILE from {PC
Magazine}, available from Simtel as PD1:<MSDOS.PRINTER>PRN2FILE.ARC,
14451 bytes including .ASM source, or from garbo as prn2file.zip in
/pc/printer. ({PC Magazine} has given copies away as part of its
utilities disks, so you may already have a copy.)
The other listings that I found in Simtel's index as of mid-January
1992 are, from newest to oldest:
PD1:<MSDOS.PRINTER>
PRIND25.ZIP 17008 900420 Redirect printer to file/screen/printer
RPRN.ARC 2631 900120 Redirect printer output to disk file
PRINDIR.ARC 6836 891210 Redirects printer output to disk file
VPRNT301.ARC 15259 891030 Printer redirection to disk file, v3.01
PSTASH20.ARC 2830 890216 Redirects lpt output to file
PRNDSK.ARC 27172 871224 Redirect Printer Output To Disk
LPTX600.ARC 31596 870319 Redirect printer output to a file
At garbo, in the /pc/printer directory, you can find
lamneth.zip PrintScreen redirect to a disk file v09-Mar-88
lptx.zip Redirect printer output v6.0
lptx700.zip Redirect printer output v7.0 (not update, just
different)
prindir8.zip Printer and port Redirection from Allen Creations
Q406. What's the format of an .EXE header?
See pages 349-350 of {PC Magazine}'s June 30, 1992 issue (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.
section 5. Serial ports (COM ports)
===================================
Q501. 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
Q502. 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 (tested under MSC 5.0 and BC++ 2.0) 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;
}
Q503. 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.
Q504. How do I configure a COM port and use it to transmit data?
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.
section 6. Other hardware questions and problems
================================================
Q601. Which 80x86 CPU is running my program?
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 the
Intel's 486SX processor manual (order number 240950-001). You can
download David Kirschbaum's improved version of this from Simtel as
PD1:<MSDOS.SYSUTL>CPUID593.ZIP.
According to an article posted by its author, WCPU041.ZIP knows the
differences between DX and SX varieties of 386 and 486 chips, and
can also detect a math coprocessor. It's in PD1:<MSDOS.SYSUTL> at
Simtel.
Q602. 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.
Q603. How can I redirect printer output to a file?
Please see section 4, "Disks and files", for the answer.
Q604. Which video adapter is installed?
This technique should work if your BIOS is not too old. It uses
three functions from INT 10, the BIOS video interrupt.
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 brown@ncoast.org if your results vary.
Q605. How do I switch to 43- or 50-line mode?
Download PD1:<MSDOS.SCREEN>VIDMODE.ZIP, 4412 bytes, from Simtel or
one of the mirror sites. It contains .COM utilities and .ASM
source code.
Q606. 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, see the directory PD1:<MSDOS.MOUSE> at Simtel.
Q607. 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.
Q608. How can I read or write my PC's CMOS memory?
There are a great many public-domain utilities that do this. These
were available for download from Simtel as of 31 March 1992:
PD1:<MSDOS.AT>
CMOS13.ZIP 7258 920330 Backup and restore damaged CMOS memory
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.ARC 20497 900131 Save AT and 386 CMOS data to file and restore
SETUP21.ARC 24888 880613 Setup program which modifies CMOS RAM
VIEWCMOS.ARC 15374 900225 Display contents of AT CMOS RAM, w/C source
At garbo, /pc/ts/tsutle17.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.
section 7. Other software questions and problems
================================================
Q701. How can a program reboot my PC?
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
(tested under MSC 5.0 and BC++ 2.0):
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), 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 cluck
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".)
Here's C code that tries to signal the disk cache (if any) to
flush (compiles under MSC 5.0 and BC++ 2.0):
#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.x.ax = 0x4F53; /* 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)( );
}
Q702. How can I time events with finer resolution than the system
clock's 55 ms (about 18 ticks a second)?
The following files can be downloaded from Simtel:
PD1:<MSDOS.AT>
ATIM.ARC 5946 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)
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
ZTIMER11.ZIP 74477 920428 Time C/C++/Pascal/ASM-microsec accuracy
PD1:<MSDOS.TURBOPAS>
BONUS507.ARC 150435 900205 [Turbo Pascal source: high-res timing]
Pascal users can download source code in /pc/turbopas/bonus507.zip
at garbo.
Q703. How can I find the error level of the previous program?
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. If your language
doesn't, 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; you
can download it from Simtel as PD1:<MSDOS.BATUTL>ERRLVL12.ZIP. (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.)
Q704. How can a program set DOS environment variables?
Program functions that read or write "the environment" typically
access only the program's copy of the environment. 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 programming varies for different versions of DOS.
A fairly well-written article in {PC Magazine} volume 8 number 20
(1989 Nov 28), 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.
In searching Simtel for source code, I found many possibilities. I
liked PD1:<MSDOS.SYSUTL>RBSETNV1.ZIP of the ones I looked at (not
all of them). It includes some utilities to manipulate the environ-
ment, with source code in C.
Q705. How can I change the switch character to - from /?
Under DOS 5.0, you can't.
Earlier DOS versions let you change the "switch character" that
introduces command-line options by using SWITCHAR= in CONFIG.SYS or
by calling a DOS function. Then you would type "DIR -P" rather than
"DIR /P". Not only did this make DOS look more like Unix (oooo!),
but you could type / rather than \ in directory names.
Under DOS 5.0, all this has changed. The DOS 5.0 commands hard-code
/ as the switch character. I've seen several reports that programs
to change the switch character stopped working under DOS 5.0.
Programs like SLASH.ZIP claim to change the switch character from /
to something else. They do, but the change affects only the
third-party programs that query the switch character via INT 21
function 3700. DOS internal commands and most MS-DOS external
commands will still use /. (DOS replacements like 4DOS may honor
the switch character for internal commands.)
Q706. 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. 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. For a good writeup, download INTSHARE (from ni.funet.fi
in pub/msdos/simtel20/info or from Simtel in PD1:<MSDOS.INFO>).
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.)
Q707. How can I write a TSR (terminate-stay-resident) utility?
Several books can help you with this.
- 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.
You might want to download PD1:<MSDOS.ASMUTL>TEMPLATE.ZIP, 13161
bytes, from Simtel. It's Douglas Boling's MASM template for a TSR.
In the same directory, AMISL083.ZIP, 45230 bytes, contains Ralf
Brown's assembly-language implementation of the Alternate Multiplex
Interrupt Specification, with utilities in C.
Finally, there are commercial products, of which TesSeRact (for
C-language TSRs) is one of the best known.
Q708. 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.
(continued in part 4)
--
Stan Brown, Oak Road Systems brown@Ncoast.ORG
From brown@NCoast.ORG Thu Aug 6 22:25:29 1992
From: brown@NCoast.ORG (Stan Brown)
Newsgroups: comp.os.msdos.programmer,news.answers
Subject: comp.os.msdos.programmer FAQ part 4 of 4
Date: 25 Jul 92 16:11:20 GMT
Followup-To: comp.os.msdos.programmer
Organization: Oak Road Systems, Cleveland Ohio USA
Supersedes: <1992Jun26.031742.5432@NCoast.ORG>
Archive-name: msdos-programmer-faq/part4
Last-modified: 19 July 1992
(continued from part 3) (no warranty on the code or information)
If the posting date is more than six weeks in the past, see instructions
in the last part of this list for how to get an updated copy.
Copyright (C) 1992 Stan Brown, Oak Road Systems
section A. Downloads
====================
QA01. What is garbo? What is wustl?
These are alternative archive sites. Please try to use the site for
your continent; see next Q.
QA02. What are Simtel and "mirror sites"? What good are they?
The U.S. Government maintains a massive archive of useful software
and info files at the SIMTEL20 site. This includes scads of
utilities, plus source code from {PC Magazine}, {Dr Dobbs Journal},
and others. You can use Simtel by ftp (wsmr-simtel20.army.mil =
192.88.110.20) or (if necessary) email. To find out how, look for
these monthly articles in comp.binaries.ibm.pc.archives :
How to find files in the SIMTEL20 msdos collection
SIMTEL20 archive info for Internet FTP users
How to order SIMTEL20 files via e-mail
Another important archive site is garbo (at the University of Vaasa,
Finland). garbo is set up differently from Simtel but contains many
of the same useful files.
Please try first at the site nearest you:
- Europe and Asia: look first at garbo; for prerecorded instructions
(about 29K), email Timo Salmi (ts@uwasa.fi).
- Oceania: try archie.au first. (This is different from the Archie
mail server, archie-l@cs.mcgill.ca.) 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 (ccw@archie.au)
for instructions if needed.
- North America: try SIMTEL20 (a/k/a Simtel) first; see above for
instructions or email Keith Petersen (w8sdz@vela.acs.oakland.edu).
Also see the Simtel mirrors OAK.Oakland.Edu and ftp.uu.net, or the
SIMTEL20 & garbo mirror wuarchive.wustl.edu.
General cautions and guidelines:
- Some of the mirrors may lag occasionally, or might not have all
the files.
- If you send an email message and don't get a reply within a few
days, there are two likely causes. Most likely the Reply-to path
in your message is not valid; your sysadmin can check this and
correct it if necessary and then you can 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.
QA03. Where do I find program <mumble>?
There are several newsgroups to help; 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". See also the next Q.
QA04. How can I check Simtel or garbo before I post a request for a
program?
What a good idea! It will save your time and save net resources
too. Simtel and garbo have indexes of their contents, which you can
download and use in searching off line.
garbo has an index file, /pc/INDEX, an annotated list, frequently
updated, of the MS-DOS files there; to save download time, get the
packed form /pc/INDEX.ZIP. The news file, /pc/pd2/news-pd2 contains
selected news on all MS-DOS directories at garbo.
Simtel's index files are all in PD1:<MSDOS.FILEDOCS>. SIMLIST.ARC
is in text format (315K as of February 1992). But you may prefer
the file SIMIBM.ARC (355K as of February 1992) which is
comma-delimited for easy use with any of these search facilities:
- Two search programs are SIMTEL35.ARC (162K) and SIMDIR21.ZIP
(19K).
- dBASE III or IV users can load the index from SIMLIST.ARC using
instructions in SIMIBM.INF (180 bytes) and SIMIBM.DB3 (581 bytes).
- PC-FILE users should get SIMIBM.HDR (129 bytes), which tells how
to use SIMIBM.ARC.
QA05. How do I download and decode a program I found?
See the "starter kit" in comp.binaries.ibm.pc, usually posted on the
first and 15th of every month. Most binaries are posted and sent
through email in 'uuencode' format. The starter kit contains a
uudecode program to turn this file back into a binary.
If you can't wait (if?, bwaa-haa-haa), you can get the starter kit
via ftp or email. By ftp, access pit-manager.mit.edu (18.172.1.27)
and look for the following file or one with a similar name:
/pub/usenet/comp.binaries.ibm.pc/v17i7:_s.k,_C_S_s_K_(p_01_01)
By email, send mail-server@pit-manager.mit.edu a message with blank
subject and the following lines of text in the body:
send usenet/comp.binaries.ibm.pc/v17i7:_s.k,_C_S_s_K_(p_01_01)
send usenet/comp.binaries.ibm.pc/index
The first command sends the starter kit, unless the version number
has changed. If it has, the first command will fail, so look at
the index that you get in response to the second command and re-send
the first command with the correct version number.
If you're using Kermit, remember to set file type binary before
issuing the send command. By the way, the uuencoded file is bigger
than the binary, so you'll save connect time if you can uudecode it
and then download the binary file.
QA06. Where is UUDECODE?
You can find it in Simtel, 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.
QA07. Why do I get errors when extracting from a ZIP file I downloaded?
There are many possible causes, but two of them probably account for
95% of all problems. (1) Did you remember to set your file-transfer
protocol to binary mode, at both ends if necessary? (2) Are you
using the current version of PKUNZIP? (See section B, "Vendors and
products".) The vast majority of stuff in archive sites requires
PKZIP version 1.10 to extract correctly. It causes confusion that
older versions of PKZIP aren't smart enough to tell you that the
problem is with the extraction program and not with the file you're
trying to extract from.
section B. Vendors and products
===============================
QB01. How can I contact Borland?
Borland has set up three email addresses. However, none of them is
for technical support such as help with finding your own programming
errors and explaining compiler messages.
- customer-support@borland.com 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.
- bugs@borland.com 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 bugs@borland.com is to improve future
products sooner, not as a substitute for tech support channels."
- bc30-info@borland.com will reply to any message with canned info
on Borland C++ 3.0, Turbo C++ 3.0, and Application Frameworks.
Tech support is provided through Compuserve (GO BOR), by voice phone
at +1 408 438 5300, by FAX at (800) 822-4269 in U.S. (use Touch-Tone
voice phone), on a BBS at +1 408 439 9096, and by mail at
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.
Finally, in the 31 Mar 1992 issue of {PC Magazine}, an ad over the
signature of Philippe Kahn, Borland's chairman, says "I want to make
sure that I get your feedback about our dBASE products. Call my
voice mail directly at (800) 851-2122 with your critiques and
suggestions."
QB02. How can I contact Microsoft?
Individual employees of Microsoft (not MicroSoft, please!) post here
sometimes. Their addresses all take the form person@microsoft.com.
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).
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 (800) 426-9440
U.S. corporate/gov't/reseller/
educational sales (800) 227-4679
Canadian sales (800) 568-3503
International sales +1 206 936-8661
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++ (206) 635-7007
MASM (206) 646-5109
DOS Upgrade Users (206) 646-5104 (for 90 days after first call)
Windows Users (206) 637-6098
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 (206) 454-2030
U.S. languages support (206) 637-7096
You can also write to Microsoft Product Support, 16011 NE 36th Way,
Box 97017, Redmond WA 98073-9717, USA.
QB03. What's the current version of PKZIP?
The current version is 1.10 (PKZIP110.EXE), available from Simtel as
PD1:<MSDOS.ZIP>ZIP110EU.EXE. This is the same as the standard
version except it doesn't offer authenticity verification (the -AV
indicators) because of U.S. law. Remember that PKZIP is shareware
and you're expected to pay for it if you use it. Current price is
$25, or $47 for a free upgrade when the next version is released.
Since early 1992, PKWARE has been running ads in computer magazines
announcing 2.0; but it seems to be vaporware. The latest actual
version, 1.93, is a test version not in general release, and not
guaranteed compatible with the eventual official release. Several
versions that have been called 2.0 are actually hacked versions of
that beta-test version and are completely unauthorized.
QB04. What's in Microsoft C/C++ 7.0?
spoiler: Yes, it includes the Windows 3.1 SDK, with an option to
build applications that run on 3.0 and 3.1.
According to the {Getting Started} booklet, the compiler needs 4 MB
of RAM, an 80386 or better, and 8-27 MB on your hard disk. (An
email correspondent said Microsoft said it will run on an 80286, but
very slowly). C/C++ comes on nine 3.5" 1.44 MB diskettes, plus one
for the source profiler and 11 more for the Windows System Develop-
ment Kit (SDK); it's also available on 5.25 diskettes.
The Programmer's WorkBench (PWB) and CodeView (CV) run in Windows or
DOS. According to the README.TXT file, "Microsoft C/C++ version 7.0
requires DPMI services. If you wish to use Windows as your develop-
ment environment, Windows provides DPMI services for you. To use
MS-DOS as your development environment you must install 386-Max to
provide these services." A copy of Qualitas 386-Max is included.
The upgrade includes everything in the compiler except printed ref-
erence manuals for the Windows SDK (which is documented on disk).
The manuals in my copy of upgrade are:
Getting Started
Environment and Tools
Programming Techniques
Run-Time Library Reference
C Language Reference
C++ Tutorial
C++ Language Reference
Class Libraries User's Guide
Class Libraries Reference
Comprehensive Index and Errors Reference (indexes all the above)
Quick Reference Guide (card shows options for tools)
Source Profiler User's Guide
Class Libraries reference card
Windows SDK: Getting Started
Windows SDK: Programming Tools
Windows SDK: Setup Toolkit for Windows
The remaining printed manuals for the SDK for Windows 3.1 come with
the compiler but not with the upgrade. They are:
Guide to Programming
Programmers' Reference Volume 1: Overview
" " " " 2: Functions
" " " " 3: Messages, Structures and Macros
" " " " 4: Resources
Multimedia Programmer's Guide
Multimedia Programmer's Reference
MS Windows for Pen Computing: Programmer's Reference
The Windows Interface: An Application Design Guide
The Win32 Application Programming Interface: An Overview
Pricing:
- compiler: $499 list, about $300 from mail-order companies
- upgrade from any version of a C or C++ compiler from Microsoft,
Borland, Watcom, or Zortech/Symantec: $139 list -- to order, call
Microsoft sales and service listed earlier in this section
- printed docs for Windows 3.1 SDK: $150 list (order form included
with the upgrade)
QB05. What's in Borland C++ 3.0, Turbo C++ 3.0, Application Frameworks?
BC++ 3.1 is now the current version; this information on 3.0 will be
removed from the next FAQ list (replaced, I hope, with 3.1 info).
Send mail to bc30-info@borland.com. The mail server will ignore the
subject and text of your message and will email a text file about
Borland's family of C and C++ compilers to the reply-to address in
your message. The file includes features, list prices, and upgrade
prices.
section C. More information
===========================
QC01. Are there any good on-line references for PC hardware components?
I have heard good reports of HELPPC21.ZIP, downloadable from Simtel
in PD1:<MSDOS.INFO> (283578 bytes, dated 910510). There's an info
file in the same directory, HELPPC21.INF (6121 bytes). European
users will find it as garbo.uwasa.fi:/pc/programming/helppc21.zip.
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).
QC02. Are there any good on-line references for PC interrupts?
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
inter30a.zip, inter30b.zip, and inter30c.zip. At Simtel it's in
PD1:<MSDOS.INFO>INTER30A.ZIP, INTER30B.ZIP and INTER30B.ZIP. At
garbo it's in /pc/programming/inter30a.zip, inter30b.zip, and
inter30c.zip. These versions were uploaded in late April 1992;
updates are announced in comp.binaries.ibm.pc.archives every few
months.
If you'd rather not download the list, you can get it in book form,
split up by subject, as {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 than the book. (The on-line
list has also grown by about 30% since the book was published.)
QC03. What and where is "Ralf Brown's interrupt list"?
See the preceding Q.
QC04. 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.
QC05. What's the best book to learn programming?
Sorry, this FAQ list cannot settle religious arguments.
QC06. Where are FAQ lists archived?
Many are crossposted to news.answers. That newsgroup should have a
long expiry time at your site; if not, talk to your sysadmin.
FAQ lists are available by anonymous FTP from pit-manager.mit.edu
(18.172.1.27) in files with names like
/pub/usenet/news.answers/C-faq/faq
and by email from mail-server@pit-manager.mit.edu. For instructions
about the mail server, send a message with "help" and "index" on
different lines.
QC07. Where can I get the latest copy of this FAQ list?
It is posted every month to news.answers in such a way that it
should stick around until the following month's version has been
posted. Please check news.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/part1
through part4 via FTP at pit-manager.mit.edu [18.172.1.27]. This
list is also stored as garbo.uwasa.fi:/pc/doc-net/faqpYYMM.zip,
replacing YYMM by the year and month of the latest list, e.g. 9206.
If the article is unavailable from news.answers and you don't have
ftp, send a message with blank subject and contents
send usenet/news.answers/msdos-programmer-faq/part1
to mail-server@pit-manager.mit.edu.
(end of comp.os.msdos.programmer FAQ)
--
Stan Brown, Oak Road Systems brown@Ncoast.ORG