C News Volume 1, Number 5
Volume 1, Number 5 06 March 1988
+---------------------------------------------------------------+
| |
| - C News - |
| |
| International |
| C Programming & Compiler Review |
| Newsletter |
| |
+---------------------------------------------------------------+
US Office:
Editor at large Barry Lynch
Assistant Editor Ami Dworkin
Technical Editor Marshall Presnell
Australian Office:
Editor David Nugent
C News is published bi-weekly by the C BBS as its official
newsletter. You are encouraged to submit articles for publication
in C News. Articles should be related to C programming and can be
Tutorials, reviews or articles of interest to the C programming
community. All Operating systems are fairly represented and this
newsletter shows no favoritism to any one in particular. Instruct-
ions on how to submit articles for publication is included on the
last page.
C News is the property of the C BBS and is Copyright 1988 by the
the C BBS. All rights are reserved and distribution is limited to
electronic distribution and personal printed copies. C News cannot
be resold at any profit, by any organization. All material enclosed
within the newsletter is the opinions of the writers and not the
C BBS or it's Sysop.
C News 1-05 06 Mar 1988
=================================================================
TABLE OF CONTENTS
=================================================================
1. EDITORIAL
The Heap: messages from the editor.................... 1
2. BOOK REVIEWS
TurboC Memory Resident Utilities ......................... 2
Reviewed by Magnus Cameron
3. FEATURE ARTICLE
The Integrated Environment ............................... 3
by David Nugent
4. /Usr/Bin
by Marshall Presnell ................................. 9
5. NOTES
Article Submission Standards ............................. 16
Address's ............................................... 17
USER Response Form ....................................... 18
6. INDEX ................................................... 19
7. DISTRIBUTION POINTS ..................................... 21
C News 1-05 Page 1 03 Mar 1988
=================================================================
EDITORIAL
=================================================================
The HEAP: Messages from the Editor.
One of the areas of Computer Science that currently fascinates
me is: Computer-Aided-Software-Engineering (CASE). Lately, I have
been reading a book on diagramming techniques for analysts and
programmers. The author stresses that effective automated diagramming
techinques can be used to design and dicument a system. He goes on
to state that a "code-generator" can be used to create code from the
the system flows(diagrams) that are created by the systems analyst.
Well, needless to say this was of great interest to me, being
a systems analyst by profession. The idea of using a computer to
create the diagrams and be able to change them at will and have the
documentation change also was fascinating. Here on the C BBS we have
a group project called PC-SCCS. Which is a public domain Source
Control System based on capabilities on the SCCS found on on UNIX
machines. After, reading this book I decided to change the scope
of PC-SCCS to encompass the CASE ideas. Therefore, the name of the
project is now PC-CASE. This project by any definition is complicated
and extremely technical. I make no guarantees that it will ever be
completed but if anyone is interested in exchanging ideas on this
subject, you are encouraged to send your thoughts here to the C BBS.
In the meantime I plan to write a simple tutorial on CASE for C News.
Hopefully, over time something concrete will come of this project.
On another topic, I have attempted to put togther a list of
regular distribution points of C News. If I have forgotten any
net/nodes that requested it previously, I apologize. If you are
interested in carrying C News for your readers < if you are a Sysop>
or you would like your favorite BBS to carry C News, let your sysop
know where he can get in touch with me. C News is for C programmers
worldwide and it is with your support that it continues.
B C'ng U
Barry Lynch
C News 1-05 Page 2 06 Mar 1988
================================================================
BOOK REVIEWS
================================================================
________________________________________________________________
Title: TurboC - Memory-Resident Utilities, Screen I/O and
programming techniques.
Author: Al Stevens.
Publisher: MIS Press, 1107 N.W. 14th Avenue, Portland, Oregon 97209.
ISBN 0-943518-35-0
This is a very good book if you want to develop a windows
user environment for your programs. The book starts off with a few
bland chapters which are not really worth reading. Then the chapters
on the windows and data entry screens are next.
I bought this book mainly for the window handling routines.
The chapters on windows are excellent. Unfortunately the
code is non-portable even across some MS-DOS compilers. A lot
of code is presented but is not completely documented. It is up to
the reader to decipher and work out what is going on. There is no
discussion for example on linked lists which you would expect in a book
that uses them extensively. Previous knowledge on a lot of subjects
is assumed. But if you are a medium to advanced C programmer then
you may, as I did, find this book very useful for developing your
own windows library.
This book is not for the beginner. I have modified much of the code
in an attempt to make it more portable, and you may be faced with the
same peril if you don't only run MSDOS.
An excellent chapter on TSR's (MSDOS specific) is then presented
which is followed by a chapter on how to make your C programs pop up
at the touch of a HOT key. (See CNEWS004 for an article
referring to this book). These chapters are really very informative,
but you are warned now about portability.
Generally a great book if you need some help in writing some
windows libraries and if you are too lazy like me to write Assembler
TSR's.
Magnus Cameron. (Melbourne, Australia)
C News 1-05 Page 3 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
The Integrated Environment
--------------------------
David Nugent,
Sysop: Alpha Centauri BBS 3:632/348
Melbourne, Australia
C is a language steeped in 'tradition' (or more tradition than
one would expect in its colorful but short life). It was
designed as a 'symbolic assembler' to provide the programmer with
a means of making code portable between operating systems and
types of processors. Until recently, it has not enjoyed the
public exposure or popularity as the more 'hobbyist' languages
such as BASIC or later Pascal. During its early evolution, C
became the tool of academics and systems programmers, only to be
looked at in awe by others.
Perhaps this history has made the veteran C programmer quick to
"poo-poo" the idea of the "integrated environment", first seen in
programming languages when Turbo Pascal was released. That fine
product put Pascal on the map, bringing it back from the
obscurity toward which it was surely headed after Digital
Research dropped its commitment to MT+. So now we see the latest
offerings in this technology in Bourland's Turbo C and
Microsoft's Quick C. Few veterans approved of the idea.
The "integrated environment" as such is not such a new idea.
Unix had one - a C interpreter (an environment not unlike the
BASIC interactive editor concept). Many of these are still used
for small and large program development; some being quite
sophisticated in their scope - including a full armament of
debugging tools. But no-one can deny that with the release of
Turbo and Quick C (and their relative low cost), the face of C
programming changed overnight. The language's power became quite
accessible to a much larger audience.
This brings me to my own personal experiences. I began learning
C under MS-DOS in the days of Lattice 1.00; a terribly slow and
inefficient compiler by today's standards, with a library that
included only basic I/O functions and not at all Unix compatible.
It was a real "bare bones" compiler, and I owe a lot to it and
MSC 2.0 (much the same, but with a better optimizer) for my early
experiences in dealing with low-level routines and MS-DOS. Spent
many hours in DEBUG trace discovering the rudiments of how the
chip/OS worked. I had no comfort in fancy symbolic debuggers,
nor any convenient workbench other than a few self 'inflicted'
batch files used to carry out the edit/compile/link process.
C News 1-05 Page 4 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
Eventually I discovered MAKE, and my program and library
development changed overnight.
Eventually, I upgraded to MSC 4.0, but in between discovered SCO
Xenix and its MSC 3.0 compatible compiler. Again, no integrated
environment and 'make' was the real life and time saver. My
introduction to integrated environments began when I acquired
Turbo C 1.0.
From that experience, I couldn't say that I would use it often.
Took too long to load, and the editor is not crash hot,
especially when others around offer MUCH better CMODE style. It
did have the familiar "wordstar" type commands, though, so using
it was no drama. But by that time, I had learned how to use (and
abuse) every editor under the sun anyway, and a change for the
better would indeed have been welcome.
I found it a good way to cut, develop and debug single or few
module applications. Particularly liked the ability to produce
quick and dirty .COM files. However, it was not really suitable
for my mainstream development, which was at that time mainly the
code of library modules. I needed to support making of MASM
files as well, make - being completely independent of any
language - provided a far more convenient means of constructing
full libraries. But then again, the integrated environment is
INTERACTIVE, and is really meant for just that, and that's where
I found its worth. Certainly the Turbo C command line compiler
was (is) impressive and was used far more often than the
environment.
Enter Quick C. I have only had this product a few days due to
shipping problems out here in Australia, so I can only convey
"first impressions". Frankly, I am impressed. Looks almost
entirely like the Quick Basic 4.0 environment with C extensions.
(should I admit to using QB4??). Although the debugger is useful
(used it tonight to track down one of those errors that the more
you looked at the code, the harder it is to find) and quite
powerful, it lacks many of the features of Turbo C's environment
that I found most useful, but makes up for it in other ways.
When are these two companies going to get together and make a
really DYNAMITE product! <grin> Each product has excellent
features that the other lacks!
Quick C is good for base level debugging. No good news with its
editor though, except that its autoindent is just a little (and I
MEAN "little") better than Turbo (e.g. Home returns to beginning
of text, not beginning of line). Certainly support for the mouse
helps, as I live and breath Windows/386 - being able to get
C News 1-05 Page 5 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
around a large file of code is very snappy using the guide bars.
It is also good for quickly compiling into memory, correcting
typos and also for "lint-picking" code, even providing warning
errors for ANSI compatibility at /W3. Turbo C may be a little
better in that regard, there having greater control over which
types of warnings are shown and which are not.
As you may gather from the above, QC and TC are very different
products. Both will produce reliable working code, and provide
convenient assistance to those learning the language, but each
approaches it in a different manner. Quick C may be slightly
better for the beginner because of its non-involvement in memory
models and the more esoteric parts of C programming. Turbo C is
an integrated environment for the more serious programmer. Both
compilers offer an excellent upgrade path to their command line
versions (and QC a further upgrade to those serious enough to
want to afford the full MSC 5.x).
I tend to feel that QC has been released as a development and
learning tool. It certainly looks that way, especially after
compiling a non-trivial program to 30K binary, then running
EXEPACK on it to crunch it to 20K! These results are startling,
when considering that the same file compiled under MSC 5.0
produced an 18.5K executable (TC interactive environment wound up
a little over 15K). I guess size isn't everything, but that
certainly indicated that there were lots of empty spaces
produced. Looks like EXEPACK is a handy utility for those who
use the stand-alone QC package! Very little was gained by
packing any of the other executables (few hundred bytes at best).
Turbo C, on the other hand, provides full compiler facilities in
the environment itself.
A blow-by-blow comparison of features of each of these compiler/
environments follows. This is not intended to be a "which
compiler is best ..." but a basis on which to make an informed
decision, whether MSC 5.0 compatibility is worth it, or whether
Turbo C is enough for your purposes.
As a coding tool, both compilers provide similar error list
approaches, with the ability to easily locate the line in
question which resulted in the error. Turbo provides a more
intuitive error window which can be stepped through using Up and
Down arrow keys, adjusting the current cursor position in the
source file to that line. Quick C has a more difficult method,
and I had to dive into the manual to find it: Shift-F3 and Shift-
F4 to next and previous errors.
C News 1-05 Page 6 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
This example underlines the use of the keyboard generally; Turbo
C having much more logical key assignments generally, with Quick
C relying far more upon the mouse interface - certainly a mouse
provides a far improved interface (MS-mouse or emulation
required). Some of QC's key combinations are difficult to
fathom, requiring usually two simultaneous keystrokes. The most
often used pop-up options are more easily accessed in Turbo C,
usually by single keystroke (Alt-R to compile and run a program
in memory), but less used options are placed in submenus and pop-
up windows well out of harm's way. Many of Quick C's most often
used functions require a number of keystrokes to access,
including compiling, although all information regarding the
function is on a single screen.
TC saves compile/setup these options in a configuration file in
the current subdirectory, so different settings (taken initially
from a "master" in the main TC directory) can be maintained for
each project. Quick C similarly saves a QC.INI file.
Each environment provides access to the operating system by
offering "shell to DOS" options. TC provides further options to
list and change directories (under QC, the default directory
remains the startup directory, even if the directory is changed
after shelling a second COMMAND.COM). Files may be "picked" and
edited using "point and shoot".
Both compilers offer a program list arrangement where a number of
files may be pulled in and edited easily. Certainly Quick C
offered a more logical and thorough approach to this, with the
ability to build a complete 'make' compatible makefile from the
list contents. Turbo's "pick list" is limited and used more for
convenience rather than to edit/compile a logical group of files.
Turbo's offering of project files is less intuitive and more
difficult to set up (at least to a seasoned MAKE user). Quick C
also offers the ability to view/edit an include file by placing
the cursor on an "#include" line and selecting View Include.
This not only searches the current directory, but also those
specified in the INCLUDE environment variable (as does the
compiler).
The convenience Quick C offers in multi-file compiles is
comparable to that of MAKE. Certainly it is convenient that it
builds a makefile (even though it uses an interesting 'kludge'
for longer than 128-byte LINK lines), but of course limited only
to C files. Mixed language and assembly module linking still
requires editing, but the QC editor can be conveniently used for
that. Once this is done, however, MAKE must be used externally
(after unloading QC). Still this approach can save much of the
C News 1-05 Page 7 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
work required to build and maintain a makefile even if it does
require edits. Making the file transportable to another
directory structure is easy by standard search and replace
functions.
Help available in either compiler is excellent. In addition to
the standard "usage" help, Quick C also offers syntax and calling
convention help for standard library functions, providing
excellent support to the beginner (and not so-beginner). This is
context sensitive using Shift-F1 instead of F1 only, calling up
the function on which the cursor is placed.
Code-level debugging is where Quick C takes all the points. It
includes watchpoints, breakpoints, dynamic display of memory
variables and conditional breakpoints. This falls far short of
the full-blown codeview (which, amongst other things, provides
assembly level debugging), but this is excellent for those non-
expert at ASM code anyway. Step by step trace is supported, with
full screen swapping (to and from the application begin run)
provided, which may be disabled if you wish to view only code and
variables. This is a real time-saver in debugging and available
right there in the environment, especially for variable tracing.
One important point to note, however. Turbo C gives the
programmer the (almost) full range of compile options available
in the command line version, TCC, including control over memory
models. Quick C (the environment) does not. When compiling to
memory, medium model MUST be used. However, QCL does provide
this option similar to MSC 5.0's CL (with the -A switch).
Therefore, where it is required that a different model be used,
one must first develop the application in medium model, generate
the appropriate makefile (which assumes QCL) then use the command
line version to compile the finished product. This is not so bad
and tends to encourage code which is portable across memory
models (at least that's my experience).
I hope this has given some insight into the workings and use of
these compilers. They certainly give an excellent introduction
to the language, and while more advanced C programmers may
"outgrow" the integrated environment, they are still viable as
tools for full time serious development. Various aspects of
these programs make them handy for doing things which no other
single tool can do, bringing to the C community yet another way
to develop code. Let's face it, a working environment is
important to the amount of work done, and any improvement is a
blessing and should improve productivity. For the hobbyist, it
makes C - the language - less difficult by providing on-line help
at the touch of a key (something I've recently grown accustomed
C News 1-05 Page 8 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
to), and certainly more pleasant to program in.
Like all tools, you can take it or leave it. If you find that a
good editor with macro capability and a command-line driven
compiler is best, then that will work better for you.
C News 1-05 Page 9 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
The /usr/bin
Marshall Presnell
Talking with a FOSSIL - Part 1
FOSSILs are NOT old bones. I've always wanted to say that! A
FOSSIL is really a standard communications interface for MS-
DOS and PC-DOS computers. Many so-called "compatibles" that
run MS-DOS and PC-DOS are not really compatible, especially
when it comes to communication. The communication facilities
are a part of the BIOS system, and that system is not a
stringent requirement for the proper operation of MS-DOS. As
will happen, the BIOS gets scrambled sometimes by different
manufacturers.
IBM placed its communication interrupt at vector 14 hex,
with a small number of functions available. This established
the "standard" communications BIOS entry point. Of course,
other issues kept the standard from being used on the wild
and varied machines that also ran MS-DOS and PC-DOS. The
concept of a FOSSIL (which stands for Fido/Opus/Seadog
Standard Interface Layer) comes from a few programmers who
wanted a real standard to work with in dealing with
communications. Naturally, the issue expanded to video
services, timer tick management, and application appendages
that would work across the wide variety of MS-DOS systems.
FOSSILs can be loaded three ways (that I have figured out,
at least). It can be a device driver, as is Ray Gwinn's
X00.SYS. It can load as a TSR, like Bob Hartman's OpusComm.
And it can be loaded to spawn a child process and field the
interrupts and requests itself. However it is loaded, the
interface to a FOSSIL is a rigid standard. All FOSSIL
entries are done through INT 14 hex. The AH register
contains a function code, and other registers contain
function specific data.
This column will present a C callable library which
interfaces with a FOSSIL. Using this library will help
ensure that any communications program that you write can be
easily ported to a foreign environment (so long as it runs a
FOSSIL!). Before you continue with this article, it might
help if you un-arced the file USR-BIN.ARC and read the file
called FOSSIL5.DOC. It's a long and complex document, but
contains the actual specification for a revision 5 (the
latest revision) FOSSIL driver.
C News 1-05 Page 10 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
Coding the FOSSIL library
For the coding of the FOSSIL interface itself, I chose to
use assembly language. Communications are usually a speed
bottleneck, so this decision was made to minimize the
overhead of coding it in pure C. Since the FOSSIL standard
requires an 80x86 interrupt system, this does not decrease
portability across our target systems (MS-DOS/PC-DOS).
The assembly language files F_*.ASM are provided in the USR-
BIN archive as well. Use the Microsoft Macro Assembler
version 5 to compile this if you make any changes. (Look at
the MAKEFILE to see how MASM is called) You will also need
the MIXED.MAC file that is provided with that assembler. The
file FOSSIL.LIBJ is also provided for those who do not have
the MASM 5 package. On furthur examination, you will find a
few C files that start with "F_". These contain some C
functions which make dealing with the FOSSIL interface
easier.
All of the low level FOSSIL functions are provided for in
the F_*.ASM files and the FOSSIL.LIB library. These
functions are as follows:
int f_setbaud(int port,int rate_code) - This function sets
the baud rate of the specified port to a value which is
encoded in the rate_code variable. (The rate_code value is
NOT 300, 1200, 2400, etc) The port variable is 0 for
COM1:, 1 for COM2:, etc. This convention is used
throughout the library wherever a port variable is used. A
status word is returned to the caller. (The status word is
defined in the function f_stat()). Instead of using this
function to set the baud rate, check the "helper" function
f_baud() in the F_BAUD.C file. It's very straightforward.
void f_tx(int port, int character) - This function sends a
character to the specified port. If the transmit buffer is
full, this function will wait until the character can be
queued for transmission. Only the lower byte of character
is signifigant. This function returns nothing.
unsigned int f_rx(int port) - This function will return a
character from the specified port. If the receive buffer
is empty, this function will wait until a character is
available before returning. The return value is mapped
into an unsigned int. The low byte is the returned ASCII
character.
C News 1-05 Page 11 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
unsigned int f_stat(int port) - This function returns status
information regarding the specified port. The return value
is bit-mapped as follows:
0x0100 - Received Data is available
0x0200 - Received data has overrun the buffer (ERROR)
0x2000 - Room is available in the transmit buffer
0x4000 - Transmit buffer is empty
0x8000 - Carrier Detected
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
int f_init(int port, int trigger, int * flag_address) - This
function initializes the FOSSIL for subsequent function
requests on a specified port. In other words, call this
function before you call other FOSSIL functions! The
trigger variable (if set to a non-zero value) causes the
initialization routine to provide a method for checking
for control-c activity. If the trigger byte is set, the
flag_address points to an integer in the application's
code which is to incremented when control-c is detected.
Note that this control-c business is an OPTIONAL service
for the FOSSIL and must only be supported on machines
which can't (or won't) issue an INT 1BH or INT 23H when a
control-c is entered. This function returns a "magic
number" of 0x1954 if the initialization was successful.
void f_deinit(int port) - This function de-initializes the
specified port. Nothing is returned.
void f_dtr(int port, int state) - This function controls the
state of the DTR (Data Terminal Ready) line for the
specified port. Dropping DTR (state == 0) is a widely used
way of terminating a communications session. DTR must be
ON (state == 1) if communications are to take place. This
function returns nothing.
int f_ttint() - This function returns the interrupt number
for the timer tick hardware interrupt.
int f_ttspeed() - This function returns the approximate
number of ticks per second on the timer tick interrupt.
int f_ttmilli() - This function returns the approximate
number of milliseconds per tick on the timer tick
interrupt.
C News 1-05 Page 12 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
void f_outflush(int port) - This function flushes (waits for
the all data to be sent) the transmit queue to the
communications line. This function can cause the FOSSIL to
go into a tight uninterruptable loop if used with flow
control active (see function f_flowctrl()).
void f_outpurge(int port) - This function cancels all
pending output for the specified port.
void f_inpurge(int port) - This function cancels all pending
input which is in the receive queue but has not been read.
int f_txnowait(int port, int character) - This function acts
identically to f_tx() except that if there is no room in
the transmit queue, the function returns a zero, otherwise
it returns a non-zero value.
unsigned int f_peek(int port) - This performs a non-
destructive "look-ahead" into the receive buffer. If a
character is ready to be read from the receive queue, this
function returns the character waiting, otherwise, it
returns 0xffff.
unsigned int f_keyrdnowait() - This function returns the IBM
style scan code is a character is available, otherwise it
returns 0xffff.
unsigned int f_keyrd() - This function waits for a character
from the keyboard if necessary, then it returns the IBM
style scan code of the key pressed.
void f_flowctrl(int port, int bitmask) - This function sets
the flow control parameters for the specified port. The
bitmask is encoded as follows:
0x0001 - Use XON/XOFF on transmitter
0x0002 - Use CTS/RTS (CTS on transmitter, RTS on receiver)
0x0008 - Use XON/XOFF on receiver
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
unsigned int f_ctrlcchk(int port, int bitmask) - This
function does two things of interest. The first is to
enable or disable control-c and control-k checking. The
second is to enable or disable the transmitter. The
following is the bitmask values:
C News 1-05 Page 13 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
0x0001 - Enable / Disable Control-C/K checking
0x0002 - Enable / Disable the transmitter
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
If Control-C/K checking is enabled, the return value from
this function indicates if a control-c or control-k has
been received since the last call to this function. The
transmitter enable/disable allows the application to
control the transmitter in the same way that XON/XOFF flow
control does.
void f_setcurs(int row, int col) - This function provides a
standard method for setting the row and column position of
the cursor. The upper left hand corner of the screen (the
home position) is row 0, column 0.
unsigned int f_getcurs() - This returns the row and column
position of the current cursor position. The row is in the
upper byte of the return value, the column is in the lower
byte.
void f_wransi(int character) - This function provides the
fastest possible display of characters that permit ANSI
processing to occur.
void f_watchdog(int port, int state) - This function
enables/disables the "watchdog" monitor for the specified
port. If the watchdog is enabled and the carrier for the
specified port goes away, the system is booted.
void f_wrbios(int character) - This function sends the
specified character to the screen using BIOS calls. Note
that this function does not use DOS calls at all because
it may also be used by the FOSSIL driver to display
messages.
unsigned int f_insertfunc(void (*fptr)()) - This function
inserts the function pointed to by fptr into the timer
tick interrupt chain. Note that the function inserted into
the chain must be compiled with no stack traces enabled
(use the #pragma check_stack(off) in MSC 5). This function
returns a zero value if the function was inserted, and a
non-zero value if the insert failed for any reason.
unsigned int f_removefunc(void (*fptr)()) - This function
removes the function pointed to by fptr from the timer
C News 1-05 Page 14 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
tick interrupt chain. This function returns a zero value
if the function was removed, and a non-zero value if the
remove failed for any reason.
void f_reboot(int temparature) - This function reboots your
system. If temprature == 0, a cold boot is performed,
otherwise a warm boot is done. If you get a return code
from THIS function, something is very wrong withyour
FOSSIL!
int f_readblk(int port, int count, void * buffer) - This
function allows you to read a block of characters from the
receive buffer to a memory buffer in your application.
(Great for file-transfer protocols!). The return value is
the number of characters actually transferred from the
FOSSIL buffer to your buffer.
int f_writeblk(int port, int count, void * buffer) - This
function allows you to write a block of characters from a
memory buffer in your application directly to the FOSSIL.
(Great for file-transfer protocols!). The return value is
the number of characters actually transferred from your
buffer to the FOSSIL buffer.
void f_break(int port, int state) - This function starts and
stops a break signal. When state != 0, the break signal is
started, when state == 0, the break stops.
void f_data(int port, int count, void * buffer) - This
function loads a structure (defined in the FOSSIL5.DOC
specification) which contains information of interest to
the specific implementation of FOSSIL that you have
installed. See the FOSSIL5 document for more information.
The f_installapi and f_removeapi functions are generally not
used by high-level languages and will not be covered in
this issue.
"But wait!", you say... "Some of those functions have
NOTHING AT ALL to do with communications!". True. There
are functions for keyboard input and video output and timer
tick management as well. The main thing to remember is that
a FOSSIL lays over the top of the operating system, allowing
compatibility where it counts... at the application level.
Next issue, we'll see how a FOSSIL is used in an actual
application (a dumb terminal program). The capabilities in
using a FOSSIL will astound and amaze you. Go ahead and try
C News 1-05 Page 15 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
some simple stuff (or, if you are REALLY daring, some
complicated stuff!) with your compiler. FOSSIL.LIB is set up
as SMALL model for now. If you have any questions on the
assembly source or FOSSILs in general, you can find me in
the C conference on FidoNet, or you can leave a message on
the RENEX BBS. Fido 109/639, telephone (703) 494-8331. C you
next issue!
C News 1-05 Page 16 06 Mar 1988
================================================================
ARTICLE SUBMISSION STANDARDS AND ADDRESSES
================================================================
As I have repeatedly stated in this newsletter and previous
issues, I would like to see user-submitted articles, reviews or
questions. Listed below are the standards that should be
followed to make my job easier as an editor.
- Articles should be submitted in a ASCII non-formatted
file.
- If the article include code fragments as examples. Then
you can include the entire source file if you like for
inclusion with the newsletter.
- Book or magazine reviews should follow the same format,
that is outlined in this issue. The publisher, author,
title, and ISBN number are a must.
- Compiler/and or product reviews, should include the
version number and manufacture. If possible, reviews
should include a sample program with benchmarks.
If you have any questions you can contact me at the
address's included on the next page.
C News 1-05 Page 17 03 Mar 1988
================================================================
ADDRESSES
================================================================
The C BBS is located at:
C BBS
% BCL Limited
P.O. Box 9162
McLean VA, 22102
or you can send netmail to:
1:109/713 < The phone number in the current nodelist is
inaccurate. At this time it is not known
when it will be corrected. >
C News 1-05 Page 18 06 Mar 1988
================================================================
USER RESPONSE FORM:
================================================================
This form will be included as a regular feature in all future
issues of C NEWS.
What did you think of the content of this Issue? _____________
_______________________________________________________________
What improvements can you think of that would make C News a
better tool for the C Community?
_______________________________________________________________
_______________________________________________________________
What is your favorite section or sections? ___________________
_______________________________________________________________
What don't you like about C News? ____________________________
_______________________________________________________________
Additional Comments: _________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
C News 1-05 Page 19 06 Mar 1988
================================================================
INDEX
================================================================
Subject: Issue:
Articles:
Filename Wildcard Expansion in MSC 4
Integrated Environment: TC & QC 5
Talking with a Fossil 5
TurboC and Interrupts: A few Questions 2
Book Reviews:
C Database Development 1
C Programming Guide 1
C Programming Language 1
C Programmer's Guide to Serial Communications 3
C Programmer's Library 1
C Primer Plus 1
C the Complete Reference 2
Crafting C Tools for the IBM PC 2
Learning to Program in C 1
Microsoft C Programming on the IBM PC 1
MS-DOS Developer's Guide 4
Programming in Windows 3
Reliable Data Structures in C 1
TurboC: Memory Resident Utilities 5
TurboC Programmer's Reference Book 2
Compilers:
QuickC 1
Software Reviews:
Bplus11.arc 3
C_Dates.arc 4
Cdate.arc 4
Casm.arc 3
C-subr.arc 4
Docu.arc 3
Jcl-src.arc 4
Mscpopup.arc 3
Ndmake41.arc 4
Nuc-subr.arc 3
Shift_c.arc 4
C News 1-05 Page 20 06 Mar 1988
================================================================
INDEX
================================================================
Subject: Issue:
Software Reviews Cont:
Sysact11.arc 4
Tp_to_qc.arc 3
Xenixarc.arc 4
C News 1-05 Page 21 06 Mar 1988
================================================================
DISTRIBUTION POINTS
================================================================
Board Name Number Net/Node Sysop
United States
C BBS (703) 998-8377 1:109/713 Barry Lynch
Alexandria, VA
Jaz C-Scape (904) 724-1377 1:112/1027 Tom Evans
Jacksonville, FL
Links.BBS (916) 343-4422 1:119/13 Tom Baughman
Chico, CA
Eastern C Board Unknown 1:107/335 Todd Lehr
Rutgers1 (201) 932-4066 1:107/320 Michael Keyles
Rutgers, NJ
PTC Net (206) 757-4248 1:138/4 Arlen Fletcher
Washington, State
Canada
Another BBS System (416) 465-7752 1:148/208 Mark Bowman
Toronto, Canada
Europe
Eurpean Fido Gateway Unknown 2:2/1 Henk Wevers
The Netherlands
Australia
Alpha-Centuri BBS 011-61-3-874-3559 3:632/348 David Nugent
Another BBS System
+---------------------------------------------------------------+
| |
| - C News - |
| |
| International |
| C Programming & Compiler Review |
| Newsletter |
| |
+---------------------------------------------------------------+
US Office:
Editor at large Barry Lynch
Assistant Editor Ami Dworkin
Technical Editor Marshall Presnell
Australian Office:
Editor David Nugent
C News is published bi-weekly by the C BBS as its official
newsletter. You are encouraged to submit articles for publication
in C News. Articles should be related to C programming and can be
Tutorials, reviews or articles of interest to the C programming
community. All Operating systems are fairly represented and this
newsletter shows no favoritism to any one in particular. Instruct-
ions on how to submit articles for publication is included on the
last page.
C News is the property of the C BBS and is Copyright 1988 by the
the C BBS. All rights are reserved and distribution is limited to
electronic distribution and personal printed copies. C News cannot
be resold at any profit, by any organization. All material enclosed
within the newsletter is the opinions of the writers and not the
C BBS or it's Sysop.
C News 1-05 06 Mar 1988
=================================================================
TABLE OF CONTENTS
=================================================================
1. EDITORIAL
The Heap: messages from the editor.................... 1
2. BOOK REVIEWS
TurboC Memory Resident Utilities ......................... 2
Reviewed by Magnus Cameron
3. FEATURE ARTICLE
The Integrated Environment ............................... 3
by David Nugent
4. /Usr/Bin
by Marshall Presnell ................................. 9
5. NOTES
Article Submission Standards ............................. 16
Address's ............................................... 17
USER Response Form ....................................... 18
6. INDEX ................................................... 19
7. DISTRIBUTION POINTS ..................................... 21
C News 1-05 Page 1 03 Mar 1988
=================================================================
EDITORIAL
=================================================================
The HEAP: Messages from the Editor.
One of the areas of Computer Science that currently fascinates
me is: Computer-Aided-Software-Engineering (CASE). Lately, I have
been reading a book on diagramming techniques for analysts and
programmers. The author stresses that effective automated diagramming
techinques can be used to design and dicument a system. He goes on
to state that a "code-generator" can be used to create code from the
the system flows(diagrams) that are created by the systems analyst.
Well, needless to say this was of great interest to me, being
a systems analyst by profession. The idea of using a computer to
create the diagrams and be able to change them at will and have the
documentation change also was fascinating. Here on the C BBS we have
a group project called PC-SCCS. Which is a public domain Source
Control System based on capabilities on the SCCS found on on UNIX
machines. After, reading this book I decided to change the scope
of PC-SCCS to encompass the CASE ideas. Therefore, the name of the
project is now PC-CASE. This project by any definition is complicated
and extremely technical. I make no guarantees that it will ever be
completed but if anyone is interested in exchanging ideas on this
subject, you are encouraged to send your thoughts here to the C BBS.
In the meantime I plan to write a simple tutorial on CASE for C News.
Hopefully, over time something concrete will come of this project.
On another topic, I have attempted to put togther a list of
regular distribution points of C News. If I have forgotten any
net/nodes that requested it previously, I apologize. If you are
interested in carrying C News for your readers < if you are a Sysop>
or you would like your favorite BBS to carry C News, let your sysop
know where he can get in touch with me. C News is for C programmers
worldwide and it is with your support that it continues.
B C'ng U
Barry Lynch
C News 1-05 Page 2 06 Mar 1988
================================================================
BOOK REVIEWS
================================================================
________________________________________________________________
Title: TurboC - Memory-Resident Utilities, Screen I/O and
programming techniques.
Author: Al Stevens.
Publisher: MIS Press, 1107 N.W. 14th Avenue, Portland, Oregon 97209.
ISBN 0-943518-35-0
This is a very good book if you want to develop a windows
user environment for your programs. The book starts off with a few
bland chapters which are not really worth reading. Then the chapters
on the windows and data entry screens are next.
I bought this book mainly for the window handling routines.
The chapters on windows are excellent. Unfortunately the
code is non-portable even across some MS-DOS compilers. A lot
of code is presented but is not completely documented. It is up to
the reader to decipher and work out what is going on. There is no
discussion for example on linked lists which you would expect in a book
that uses them extensively. Previous knowledge on a lot of subjects
is assumed. But if you are a medium to advanced C programmer then
you may, as I did, find this book very useful for developing your
own windows library.
This book is not for the beginner. I have modified much of the code
in an attempt to make it more portable, and you may be faced with the
same peril if you don't only run MSDOS.
An excellent chapter on TSR's (MSDOS specific) is then presented
which is followed by a chapter on how to make your C programs pop up
at the touch of a HOT key. (See CNEWS004 for an article
referring to this book). These chapters are really very informative,
but you are warned now about portability.
Generally a great book if you need some help in writing some
windows libraries and if you are too lazy like me to write Assembler
TSR's.
Magnus Cameron. (Melbourne, Australia)
C News 1-05 Page 3 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
The Integrated Environment
--------------------------
David Nugent,
Sysop: Alpha Centauri BBS 3:632/348
Melbourne, Australia
C is a language steeped in 'tradition' (or more tradition than
one would expect in its colorful but short life). It was
designed as a 'symbolic assembler' to provide the programmer with
a means of making code portable between operating systems and
types of processors. Until recently, it has not enjoyed the
public exposure or popularity as the more 'hobbyist' languages
such as BASIC or later Pascal. During its early evolution, C
became the tool of academics and systems programmers, only to be
looked at in awe by others.
Perhaps this history has made the veteran C programmer quick to
"poo-poo" the idea of the "integrated environment", first seen in
programming languages when Turbo Pascal was released. That fine
product put Pascal on the map, bringing it back from the
obscurity toward which it was surely headed after Digital
Research dropped its commitment to MT+. So now we see the latest
offerings in this technology in Bourland's Turbo C and
Microsoft's Quick C. Few veterans approved of the idea.
The "integrated environment" as such is not such a new idea.
Unix had one - a C interpreter (an environment not unlike the
BASIC interactive editor concept). Many of these are still used
for small and large program development; some being quite
sophisticated in their scope - including a full armament of
debugging tools. But no-one can deny that with the release of
Turbo and Quick C (and their relative low cost), the face of C
programming changed overnight. The language's power became quite
accessible to a much larger audience.
This brings me to my own personal experiences. I began learning
C under MS-DOS in the days of Lattice 1.00; a terribly slow and
inefficient compiler by today's standards, with a library that
included only basic I/O functions and not at all Unix compatible.
It was a real "bare bones" compiler, and I owe a lot to it and
MSC 2.0 (much the same, but with a better optimizer) for my early
experiences in dealing with low-level routines and MS-DOS. Spent
many hours in DEBUG trace discovering the rudiments of how the
chip/OS worked. I had no comfort in fancy symbolic debuggers,
nor any convenient workbench other than a few self 'inflicted'
batch files used to carry out the edit/compile/link process.
C News 1-05 Page 4 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
Eventually I discovered MAKE, and my program and library
development changed overnight.
Eventually, I upgraded to MSC 4.0, but in between discovered SCO
Xenix and its MSC 3.0 compatible compiler. Again, no integrated
environment and 'make' was the real life and time saver. My
introduction to integrated environments began when I acquired
Turbo C 1.0.
From that experience, I couldn't say that I would use it often.
Took too long to load, and the editor is not crash hot,
especially when others around offer MUCH better CMODE style. It
did have the familiar "wordstar" type commands, though, so using
it was no drama. But by that time, I had learned how to use (and
abuse) every editor under the sun anyway, and a change for the
better would indeed have been welcome.
I found it a good way to cut, develop and debug single or few
module applications. Particularly liked the ability to produce
quick and dirty .COM files. However, it was not really suitable
for my mainstream development, which was at that time mainly the
code of library modules. I needed to support making of MASM
files as well, make - being completely independent of any
language - provided a far more convenient means of constructing
full libraries. But then again, the integrated environment is
INTERACTIVE, and is really meant for just that, and that's where
I found its worth. Certainly the Turbo C command line compiler
was (is) impressive and was used far more often than the
environment.
Enter Quick C. I have only had this product a few days due to
shipping problems out here in Australia, so I can only convey
"first impressions". Frankly, I am impressed. Looks almost
entirely like the Quick Basic 4.0 environment with C extensions.
(should I admit to using QB4??). Although the debugger is useful
(used it tonight to track down one of those errors that the more
you looked at the code, the harder it is to find) and quite
powerful, it lacks many of the features of Turbo C's environment
that I found most useful, but makes up for it in other ways.
When are these two companies going to get together and make a
really DYNAMITE product! <grin> Each product has excellent
features that the other lacks!
Quick C is good for base level debugging. No good news with its
editor though, except that its autoindent is just a little (and I
MEAN "little") better than Turbo (e.g. Home returns to beginning
of text, not beginning of line). Certainly support for the mouse
helps, as I live and breath Windows/386 - being able to get
C News 1-05 Page 5 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
around a large file of code is very snappy using the guide bars.
It is also good for quickly compiling into memory, correcting
typos and also for "lint-picking" code, even providing warning
errors for ANSI compatibility at /W3. Turbo C may be a little
better in that regard, there having greater control over which
types of warnings are shown and which are not.
As you may gather from the above, QC and TC are very different
products. Both will produce reliable working code, and provide
convenient assistance to those learning the language, but each
approaches it in a different manner. Quick C may be slightly
better for the beginner because of its non-involvement in memory
models and the more esoteric parts of C programming. Turbo C is
an integrated environment for the more serious programmer. Both
compilers offer an excellent upgrade path to their command line
versions (and QC a further upgrade to those serious enough to
want to afford the full MSC 5.x).
I tend to feel that QC has been released as a development and
learning tool. It certainly looks that way, especially after
compiling a non-trivial program to 30K binary, then running
EXEPACK on it to crunch it to 20K! These results are startling,
when considering that the same file compiled under MSC 5.0
produced an 18.5K executable (TC interactive environment wound up
a little over 15K). I guess size isn't everything, but that
certainly indicated that there were lots of empty spaces
produced. Looks like EXEPACK is a handy utility for those who
use the stand-alone QC package! Very little was gained by
packing any of the other executables (few hundred bytes at best).
Turbo C, on the other hand, provides full compiler facilities in
the environment itself.
A blow-by-blow comparison of features of each of these compiler/
environments follows. This is not intended to be a "which
compiler is best ..." but a basis on which to make an informed
decision, whether MSC 5.0 compatibility is worth it, or whether
Turbo C is enough for your purposes.
As a coding tool, both compilers provide similar error list
approaches, with the ability to easily locate the line in
question which resulted in the error. Turbo provides a more
intuitive error window which can be stepped through using Up and
Down arrow keys, adjusting the current cursor position in the
source file to that line. Quick C has a more difficult method,
and I had to dive into the manual to find it: Shift-F3 and Shift-
F4 to next and previous errors.
C News 1-05 Page 6 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
This example underlines the use of the keyboard generally; Turbo
C having much more logical key assignments generally, with Quick
C relying far more upon the mouse interface - certainly a mouse
provides a far improved interface (MS-mouse or emulation
required). Some of QC's key combinations are difficult to
fathom, requiring usually two simultaneous keystrokes. The most
often used pop-up options are more easily accessed in Turbo C,
usually by single keystroke (Alt-R to compile and run a program
in memory), but less used options are placed in submenus and pop-
up windows well out of harm's way. Many of Quick C's most often
used functions require a number of keystrokes to access,
including compiling, although all information regarding the
function is on a single screen.
TC saves compile/setup these options in a configuration file in
the current subdirectory, so different settings (taken initially
from a "master" in the main TC directory) can be maintained for
each project. Quick C similarly saves a QC.INI file.
Each environment provides access to the operating system by
offering "shell to DOS" options. TC provides further options to
list and change directories (under QC, the default directory
remains the startup directory, even if the directory is changed
after shelling a second COMMAND.COM). Files may be "picked" and
edited using "point and shoot".
Both compilers offer a program list arrangement where a number of
files may be pulled in and edited easily. Certainly Quick C
offered a more logical and thorough approach to this, with the
ability to build a complete 'make' compatible makefile from the
list contents. Turbo's "pick list" is limited and used more for
convenience rather than to edit/compile a logical group of files.
Turbo's offering of project files is less intuitive and more
difficult to set up (at least to a seasoned MAKE user). Quick C
also offers the ability to view/edit an include file by placing
the cursor on an "#include" line and selecting View Include.
This not only searches the current directory, but also those
specified in the INCLUDE environment variable (as does the
compiler).
The convenience Quick C offers in multi-file compiles is
comparable to that of MAKE. Certainly it is convenient that it
builds a makefile (even though it uses an interesting 'kludge'
for longer than 128-byte LINK lines), but of course limited only
to C files. Mixed language and assembly module linking still
requires editing, but the QC editor can be conveniently used for
that. Once this is done, however, MAKE must be used externally
(after unloading QC). Still this approach can save much of the
C News 1-05 Page 7 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
work required to build and maintain a makefile even if it does
require edits. Making the file transportable to another
directory structure is easy by standard search and replace
functions.
Help available in either compiler is excellent. In addition to
the standard "usage" help, Quick C also offers syntax and calling
convention help for standard library functions, providing
excellent support to the beginner (and not so-beginner). This is
context sensitive using Shift-F1 instead of F1 only, calling up
the function on which the cursor is placed.
Code-level debugging is where Quick C takes all the points. It
includes watchpoints, breakpoints, dynamic display of memory
variables and conditional breakpoints. This falls far short of
the full-blown codeview (which, amongst other things, provides
assembly level debugging), but this is excellent for those non-
expert at ASM code anyway. Step by step trace is supported, with
full screen swapping (to and from the application begin run)
provided, which may be disabled if you wish to view only code and
variables. This is a real time-saver in debugging and available
right there in the environment, especially for variable tracing.
One important point to note, however. Turbo C gives the
programmer the (almost) full range of compile options available
in the command line version, TCC, including control over memory
models. Quick C (the environment) does not. When compiling to
memory, medium model MUST be used. However, QCL does provide
this option similar to MSC 5.0's CL (with the -A switch).
Therefore, where it is required that a different model be used,
one must first develop the application in medium model, generate
the appropriate makefile (which assumes QCL) then use the command
line version to compile the finished product. This is not so bad
and tends to encourage code which is portable across memory
models (at least that's my experience).
I hope this has given some insight into the workings and use of
these compilers. They certainly give an excellent introduction
to the language, and while more advanced C programmers may
"outgrow" the integrated environment, they are still viable as
tools for full time serious development. Various aspects of
these programs make them handy for doing things which no other
single tool can do, bringing to the C community yet another way
to develop code. Let's face it, a working environment is
important to the amount of work done, and any improvement is a
blessing and should improve productivity. For the hobbyist, it
makes C - the language - less difficult by providing on-line help
at the touch of a key (something I've recently grown accustomed
C News 1-05 Page 8 06 Mar 1988
================================================================
Title: Integrated Environments.
================================================================
to), and certainly more pleasant to program in.
Like all tools, you can take it or leave it. If you find that a
good editor with macro capability and a command-line driven
compiler is best, then that will work better for you.
C News 1-05 Page 9 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
The /usr/bin
Marshall Presnell
Talking with a FOSSIL - Part 1
FOSSILs are NOT old bones. I've always wanted to say that! A
FOSSIL is really a standard communications interface for MS-
DOS and PC-DOS computers. Many so-called "compatibles" that
run MS-DOS and PC-DOS are not really compatible, especially
when it comes to communication. The communication facilities
are a part of the BIOS system, and that system is not a
stringent requirement for the proper operation of MS-DOS. As
will happen, the BIOS gets scrambled sometimes by different
manufacturers.
IBM placed its communication interrupt at vector 14 hex,
with a small number of functions available. This established
the "standard" communications BIOS entry point. Of course,
other issues kept the standard from being used on the wild
and varied machines that also ran MS-DOS and PC-DOS. The
concept of a FOSSIL (which stands for Fido/Opus/Seadog
Standard Interface Layer) comes from a few programmers who
wanted a real standard to work with in dealing with
communications. Naturally, the issue expanded to video
services, timer tick management, and application appendages
that would work across the wide variety of MS-DOS systems.
FOSSILs can be loaded three ways (that I have figured out,
at least). It can be a device driver, as is Ray Gwinn's
X00.SYS. It can load as a TSR, like Bob Hartman's OpusComm.
And it can be loaded to spawn a child process and field the
interrupts and requests itself. However it is loaded, the
interface to a FOSSIL is a rigid standard. All FOSSIL
entries are done through INT 14 hex. The AH register
contains a function code, and other registers contain
function specific data.
This column will present a C callable library which
interfaces with a FOSSIL. Using this library will help
ensure that any communications program that you write can be
easily ported to a foreign environment (so long as it runs a
FOSSIL!). Before you continue with this article, it might
help if you un-arced the file USR-BIN.ARC and read the file
called FOSSIL5.DOC. It's a long and complex document, but
contains the actual specification for a revision 5 (the
latest revision) FOSSIL driver.
C News 1-05 Page 10 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
Coding the FOSSIL library
For the coding of the FOSSIL interface itself, I chose to
use assembly language. Communications are usually a speed
bottleneck, so this decision was made to minimize the
overhead of coding it in pure C. Since the FOSSIL standard
requires an 80x86 interrupt system, this does not decrease
portability across our target systems (MS-DOS/PC-DOS).
The assembly language files F_*.ASM are provided in the USR-
BIN archive as well. Use the Microsoft Macro Assembler
version 5 to compile this if you make any changes. (Look at
the MAKEFILE to see how MASM is called) You will also need
the MIXED.MAC file that is provided with that assembler. The
file FOSSIL.LIBJ is also provided for those who do not have
the MASM 5 package. On furthur examination, you will find a
few C files that start with "F_". These contain some C
functions which make dealing with the FOSSIL interface
easier.
All of the low level FOSSIL functions are provided for in
the F_*.ASM files and the FOSSIL.LIB library. These
functions are as follows:
int f_setbaud(int port,int rate_code) - This function sets
the baud rate of the specified port to a value which is
encoded in the rate_code variable. (The rate_code value is
NOT 300, 1200, 2400, etc) The port variable is 0 for
COM1:, 1 for COM2:, etc. This convention is used
throughout the library wherever a port variable is used. A
status word is returned to the caller. (The status word is
defined in the function f_stat()). Instead of using this
function to set the baud rate, check the "helper" function
f_baud() in the F_BAUD.C file. It's very straightforward.
void f_tx(int port, int character) - This function sends a
character to the specified port. If the transmit buffer is
full, this function will wait until the character can be
queued for transmission. Only the lower byte of character
is signifigant. This function returns nothing.
unsigned int f_rx(int port) - This function will return a
character from the specified port. If the receive buffer
is empty, this function will wait until a character is
available before returning. The return value is mapped
into an unsigned int. The low byte is the returned ASCII
character.
C News 1-05 Page 11 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
unsigned int f_stat(int port) - This function returns status
information regarding the specified port. The return value
is bit-mapped as follows:
0x0100 - Received Data is available
0x0200 - Received data has overrun the buffer (ERROR)
0x2000 - Room is available in the transmit buffer
0x4000 - Transmit buffer is empty
0x8000 - Carrier Detected
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
int f_init(int port, int trigger, int * flag_address) - This
function initializes the FOSSIL for subsequent function
requests on a specified port. In other words, call this
function before you call other FOSSIL functions! The
trigger variable (if set to a non-zero value) causes the
initialization routine to provide a method for checking
for control-c activity. If the trigger byte is set, the
flag_address points to an integer in the application's
code which is to incremented when control-c is detected.
Note that this control-c business is an OPTIONAL service
for the FOSSIL and must only be supported on machines
which can't (or won't) issue an INT 1BH or INT 23H when a
control-c is entered. This function returns a "magic
number" of 0x1954 if the initialization was successful.
void f_deinit(int port) - This function de-initializes the
specified port. Nothing is returned.
void f_dtr(int port, int state) - This function controls the
state of the DTR (Data Terminal Ready) line for the
specified port. Dropping DTR (state == 0) is a widely used
way of terminating a communications session. DTR must be
ON (state == 1) if communications are to take place. This
function returns nothing.
int f_ttint() - This function returns the interrupt number
for the timer tick hardware interrupt.
int f_ttspeed() - This function returns the approximate
number of ticks per second on the timer tick interrupt.
int f_ttmilli() - This function returns the approximate
number of milliseconds per tick on the timer tick
interrupt.
C News 1-05 Page 12 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
void f_outflush(int port) - This function flushes (waits for
the all data to be sent) the transmit queue to the
communications line. This function can cause the FOSSIL to
go into a tight uninterruptable loop if used with flow
control active (see function f_flowctrl()).
void f_outpurge(int port) - This function cancels all
pending output for the specified port.
void f_inpurge(int port) - This function cancels all pending
input which is in the receive queue but has not been read.
int f_txnowait(int port, int character) - This function acts
identically to f_tx() except that if there is no room in
the transmit queue, the function returns a zero, otherwise
it returns a non-zero value.
unsigned int f_peek(int port) - This performs a non-
destructive "look-ahead" into the receive buffer. If a
character is ready to be read from the receive queue, this
function returns the character waiting, otherwise, it
returns 0xffff.
unsigned int f_keyrdnowait() - This function returns the IBM
style scan code is a character is available, otherwise it
returns 0xffff.
unsigned int f_keyrd() - This function waits for a character
from the keyboard if necessary, then it returns the IBM
style scan code of the key pressed.
void f_flowctrl(int port, int bitmask) - This function sets
the flow control parameters for the specified port. The
bitmask is encoded as follows:
0x0001 - Use XON/XOFF on transmitter
0x0002 - Use CTS/RTS (CTS on transmitter, RTS on receiver)
0x0008 - Use XON/XOFF on receiver
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
unsigned int f_ctrlcchk(int port, int bitmask) - This
function does two things of interest. The first is to
enable or disable control-c and control-k checking. The
second is to enable or disable the transmitter. The
following is the bitmask values:
C News 1-05 Page 13 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
0x0001 - Enable / Disable Control-C/K checking
0x0002 - Enable / Disable the transmitter
Manifest constants have been defined in FOSSIL.H which
correspond to these bit maps.
If Control-C/K checking is enabled, the return value from
this function indicates if a control-c or control-k has
been received since the last call to this function. The
transmitter enable/disable allows the application to
control the transmitter in the same way that XON/XOFF flow
control does.
void f_setcurs(int row, int col) - This function provides a
standard method for setting the row and column position of
the cursor. The upper left hand corner of the screen (the
home position) is row 0, column 0.
unsigned int f_getcurs() - This returns the row and column
position of the current cursor position. The row is in the
upper byte of the return value, the column is in the lower
byte.
void f_wransi(int character) - This function provides the
fastest possible display of characters that permit ANSI
processing to occur.
void f_watchdog(int port, int state) - This function
enables/disables the "watchdog" monitor for the specified
port. If the watchdog is enabled and the carrier for the
specified port goes away, the system is booted.
void f_wrbios(int character) - This function sends the
specified character to the screen using BIOS calls. Note
that this function does not use DOS calls at all because
it may also be used by the FOSSIL driver to display
messages.
unsigned int f_insertfunc(void (*fptr)()) - This function
inserts the function pointed to by fptr into the timer
tick interrupt chain. Note that the function inserted into
the chain must be compiled with no stack traces enabled
(use the #pragma check_stack(off) in MSC 5). This function
returns a zero value if the function was inserted, and a
non-zero value if the insert failed for any reason.
unsigned int f_removefunc(void (*fptr)()) - This function
removes the function pointed to by fptr from the timer
C News 1-05 Page 14 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
tick interrupt chain. This function returns a zero value
if the function was removed, and a non-zero value if the
remove failed for any reason.
void f_reboot(int temparature) - This function reboots your
system. If temprature == 0, a cold boot is performed,
otherwise a warm boot is done. If you get a return code
from THIS function, something is very wrong withyour
FOSSIL!
int f_readblk(int port, int count, void * buffer) - This
function allows you to read a block of characters from the
receive buffer to a memory buffer in your application.
(Great for file-transfer protocols!). The return value is
the number of characters actually transferred from the
FOSSIL buffer to your buffer.
int f_writeblk(int port, int count, void * buffer) - This
function allows you to write a block of characters from a
memory buffer in your application directly to the FOSSIL.
(Great for file-transfer protocols!). The return value is
the number of characters actually transferred from your
buffer to the FOSSIL buffer.
void f_break(int port, int state) - This function starts and
stops a break signal. When state != 0, the break signal is
started, when state == 0, the break stops.
void f_data(int port, int count, void * buffer) - This
function loads a structure (defined in the FOSSIL5.DOC
specification) which contains information of interest to
the specific implementation of FOSSIL that you have
installed. See the FOSSIL5 document for more information.
The f_installapi and f_removeapi functions are generally not
used by high-level languages and will not be covered in
this issue.
"But wait!", you say... "Some of those functions have
NOTHING AT ALL to do with communications!". True. There
are functions for keyboard input and video output and timer
tick management as well. The main thing to remember is that
a FOSSIL lays over the top of the operating system, allowing
compatibility where it counts... at the application level.
Next issue, we'll see how a FOSSIL is used in an actual
application (a dumb terminal program). The capabilities in
using a FOSSIL will astound and amaze you. Go ahead and try
C News 1-05 Page 15 06 Mar 1988
================================================================
/Usr/Bin by Marshall Presnell
================================================================
some simple stuff (or, if you are REALLY daring, some
complicated stuff!) with your compiler. FOSSIL.LIB is set up
as SMALL model for now. If you have any questions on the
assembly source or FOSSILs in general, you can find me in
the C conference on FidoNet, or you can leave a message on
the RENEX BBS. Fido 109/639, telephone (703) 494-8331. C you
next issue!
C News 1-05 Page 16 06 Mar 1988
================================================================
ARTICLE SUBMISSION STANDARDS AND ADDRESSES
================================================================
As I have repeatedly stated in this newsletter and previous
issues, I would like to see user-submitted articles, reviews or
questions. Listed below are the standards that should be
followed to make my job easier as an editor.
- Articles should be submitted in a ASCII non-formatted
file.
- If the article include code fragments as examples. Then
you can include the entire source file if you like for
inclusion with the newsletter.
- Book or magazine reviews should follow the same format,
that is outlined in this issue. The publisher, author,
title, and ISBN number are a must.
- Compiler/and or product reviews, should include the
version number and manufacture. If possible, reviews
should include a sample program with benchmarks.
If you have any questions you can contact me at the
address's included on the next page.
C News 1-05 Page 17 03 Mar 1988
================================================================
ADDRESSES
================================================================
The C BBS is located at:
C BBS
% BCL Limited
P.O. Box 9162
McLean VA, 22102
or you can send netmail to:
1:109/713 < The phone number in the current nodelist is
inaccurate. At this time it is not known
when it will be corrected. >
C News 1-05 Page 18 06 Mar 1988
================================================================
USER RESPONSE FORM:
================================================================
This form will be included as a regular feature in all future
issues of C NEWS.
What did you think of the content of this Issue? _____________
_______________________________________________________________
What improvements can you think of that would make C News a
better tool for the C Community?
_______________________________________________________________
_______________________________________________________________
What is your favorite section or sections? ___________________
_______________________________________________________________
What don't you like about C News? ____________________________
_______________________________________________________________
Additional Comments: _________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
C News 1-05 Page 19 06 Mar 1988
================================================================
INDEX
================================================================
Subject: Issue:
Articles:
Filename Wildcard Expansion in MSC 4
Integrated Environment: TC & QC 5
Talking with a Fossil 5
TurboC and Interrupts: A few Questions 2
Book Reviews:
C Database Development 1
C Programming Guide 1
C Programming Language 1
C Programmer's Guide to Serial Communications 3
C Programmer's Library 1
C Primer Plus 1
C the Complete Reference 2
Crafting C Tools for the IBM PC 2
Learning to Program in C 1
Microsoft C Programming on the IBM PC 1
MS-DOS Developer's Guide 4
Programming in Windows 3
Reliable Data Structures in C 1
TurboC: Memory Resident Utilities 5
TurboC Programmer's Reference Book 2
Compilers:
QuickC 1
Software Reviews:
Bplus11.arc 3
C_Dates.arc 4
Cdate.arc 4
Casm.arc 3
C-subr.arc 4
Docu.arc 3
Jcl-src.arc 4
Mscpopup.arc 3
Ndmake41.arc 4
Nuc-subr.arc 3
Shift_c.arc 4
C News 1-05 Page 20 06 Mar 1988
================================================================
INDEX
================================================================
Subject: Issue:
Software Reviews Cont:
Sysact11.arc 4
Tp_to_qc.arc 3
Xenixarc.arc 4
C News 1-05 Page 21 06 Mar 1988
================================================================
DISTRIBUTION POINTS
================================================================
Board Name Number Net/Node Sysop
United States
C BBS (703) 998-8377 1:109/713 Barry Lynch
Alexandria, VA
Jaz C-Scape (904) 724-1377 1:112/1027 Tom Evans
Jacksonville, FL
Links.BBS (916) 343-4422 1:119/13 Tom Baughman
Chico, CA
Eastern C Board Unknown 1:107/335 Todd Lehr
Rutgers1 (201) 932-4066 1:107/320 Michael Keyles
Rutgers, NJ
PTC Net (206) 757-4248 1:138/4 Arlen Fletcher
Washington, State
Canada
Another BBS System (416) 465-7752 1:148/208 Mark Bowman
Toronto, Canada
Europe
Eurpean Fido Gateway Unknown 2:2/1 Henk Wevers
The Netherlands
Australia
Alpha-Centuri BBS 011-61-3-874-3559 3:632/348 David Nugent
Another BBS System
Comments
Post a Comment