ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / MAGAZINE / MISC / CNEWS005.ZIP / CNEWS005.NWS next >

Wrap

Text File | 1988-03-07 | 46.0 KB | 997 lines

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