Power-Programmierung

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

/ Power-Programmierung / CD1.mdf / basic / library / pb / library5 / pbnews.003 < prev next >

Wrap

Text File | 1990-08-17 | 20.9 KB | 427 lines

************************************************************************ PowerBASIC News Issue #3 <<====>> August, 1990 The latest information from the authors of PowerBASIC ===================================================== This file will be updated on a regular basis to provide PowerBASIC users with important news, programming tips, and other valuable information. Watch the library posting date to learn of each newly published issue. While some very important items will be carried over from issue to issue, you can count on new information whenever the date changes. Watch for it! ************************************************************************ * PowerBASIC Availability ========================= The current version of PowerBASIC is Rev. #2.00b. It is available world- wide from selected dealers, and now at all Egghead Discount Software stores throughout the country. If you can't find PowerBASIC locally, you can order directly from Spectra Publishing, 1030D East Duane Ave., Sunnyvale, CA, 94086 -- 1-800-245-6717. The suggested retail price is $129.00. Registered owners of Turbo Basic may upgrade to PowerBASIC for $59.00, by providing their Turbo Basic serial number. * PowerBASIC "Patches" ====================== We have released the third in a series of patches to be applied to PowerBASIC version #2.00b. It may be downloaded from our library as the file PATCH3.ZIP. It requires PBPATCH.EXE, which may be downloaded in PATCH1.ZIP. This patch corrects erroneous floating point results when numeric error checking is disabled, incorrect executable code generation when the INP() function is referenced in certain complex numeric expressions, and unexpected results and side effects from execution of the CHAIN statement. We urge all users of PowerBASIC #2.00b to implement all three patches as soon as possible. The first file, PATCH1, fixes premature "out of memory" errors when compiling to a disk file, incorrect execution of CVF/CBCD/REMOVE$/REPLACE in certain circumstances, single precision functions and FN's in procedural mode, references to public procedures (GET$LOC, etc.) from a chained file, and incorrect error codes from ARRAY INSERT/DELETE. The second file, PATCH2, corrects an incompatibility linking certain .OBJ files, a problem with error addresses (ERADR/RESUME/NEXT) in emulated float mode, and incorrect generation of string/array memory corrupt errors (error #242). If downloading from our library is inconvenient, the files are also available on disk from Spectra Tech Support. * Ambiguous DIM statements ========================== We've confirmed a rather obscure, but potentially serious bug in PowerBASIC #2.00b. Under the folowing circumstances, a DIM statement can cause side effects, unrelated errors (overflow, function call, etc.), or even a system "hang". 1- An ambiguous (no static/dynamic option) DIM with literal indexes. 2- A later statement in the program which forces that array to be considered dynamic (a second DIM, a COMMON, etc.). This condition can be avoided by always including a STATIC or DYNAMIC option in each DIM statement, or by declaring a default to dynamic arrays (using the $DYNAMIC meta-statement) at the beginning of your program. * GET statement (graphics) ========================== We have confirmed an error in the PowerBASIC Reference Guide concerning the formula used to determine the size of an array required for a GET graphics statement. Internally, the current version of PowerBASIC uses the same incorrect formula. This frequently results in too small of a data area to hold the graphics image, which may cause serious side effects. Please change page 133 in your manual as follows: The correct formula is: # of bytes required = 4 + INT((X * BitsPerPixelPerPlane + 7) / 8) * Planes * Y where X is the horizontal image length, Y is the vertical image length, and BitsPerPixelPerPlane and Planes depend on the screen mode selected: Screen mode BitsPerPixelPerPlane Planes ----------- -------------------- ------ 1 2 1 2 1 1 3 1 1 7 1 4 8 1 4 9 1 4 10 1 2 11 1 1 12 1 4 * Calling PowerBASIC SUBS/FUNCTIONS from assembler modules ========================================================== As described on pages 290-291 of the Users Manual, PowerBASIC SUBs and FUNCTIONs may be called from assembler routines which are $LINKed into your programs. The manual fails to point out, however, that when a SUB or FUNCTION is called, it may alter the contents of the AX, BX, CX, DX, SI, DI, and ES registers. If your assembler routine expects the contents of any of these registers to remain constant, both before and after a PowerBASIC routine is called, you must save the appropriate registers before performing the call and restore them afterwards. Also, prior to calling a PowerBASIC routine, the DS register must contain the same value that it had when your assembler routine was invoked (PowerBASIC's main data segment). * Standard output ================= In the current version of PowerBASIC, as well as its predecessor Turbo Basic, we chose to PRINT via direct screen writes rather than using DOS or BIOS calls, due to the tremendous speed increase this provides. While speed is important, there are certain times when DOS output is preferable: 1-use of ANSI.SYS 2-redirection of standard output. We recognize this, and have committed to a change in the next version of PowerBASIC. At that time, we will be adding a "CONS:" device, which will optionally write to DOS standard output. Redirection of both input and output will then be supported via "KYBD:" and "CONS:". In the current version of PowerBASIC, standard output can be accessed with the following SUB: SUB StdOutput(text$) for i% = 1 to len(text$) reg 1, &h0200 reg 4, asc(mid$(text$,i%)) call interrupt &h21 next i% END SUB * Assembler FUNCTIONS ===================== For those of you who may be writing assembler functions for floating point math, we have a major change coming in the future! In PowerBASIC #2.00b, a single-precision FUNCTION returns it's value to the caller in the 8087 numeric co-processor (or emulator) at the "top-of-stack". This would normally be implemented by: FLD return_value. In the next version of PowerBASIC, I'm afraid we found it necessary to alter this convention. Single precision floats will now be returned in the DX:AX register pair instead. This change has no effect on any data type other than single's. * Printer DEVICE TIMEOUT errors =============================== Some PowerBASIC users have reported a problem with error 24 (Device Timeout) when writing to their printer. If you experience this problem, there may be a solution. PowerBASIC utilizes the BIOS for all printer output, and only "passes along" an error report generated by the BIOS. The BIOS does allow the timeout value to be changed from it's normal default of 20 seconds. In fact, it can be increased to as much as 255 seconds. All you need do is: DEF SEG = 0 POKE &H478, 255 ' for 255 seconds If this fix is successful, you might compile the above code to an .EXE file and include it as part of AUTOEXEC.EXE to automatically configure whenever your system is started. * Huge FIELD Statements ======================= Certain statements in Basic (such as FIELD) have the potential to cause huge amounts of code to be generated. This is a consequence of complexity, as well as the fact that parts of them may be repeated an unlimited number of times, by using line continuation characters. In fact, we've found that some Turbo Basic users have constructed FIELDS of more than 400 sub-strings. In PowerBASIC, we limited the size of some internal buffers in an effort to conserve precious memory, and have found that some very large FIELD statements may not compile properly. If buffer space is exceeded, PB will normally generate an error 402: Statement too complex. Also, in extreme cases, it is possible for PB to "hang" or have other undesirable side effects. While this will be corrected in the next version of PowerBASIC, there is a simple way to break down large field statements: FIELD #1, 5 as a$, 5 as b$, 5 as c$, 5 as d$, 5 as e$, 5 as f$ could also be implemented as: FIELD #1, 5 as a$, 5 as b$ FIELD #1, 10 as dummy$, 5 as c$, 5 as d$ FIELD #1, 20 as dummy$, 5 as e$, 5 as f$ * Internal Representation of Strings ==================================== Internally to PowerBASIC, strings are referenced by an integer "handle" or id number. This handle may range from 1 to 32767. On page 274 of the User's guide, it incorrectly states that "The upper bit . . . must be logically ANDed off of the value to arrive at the true handle number of the string." In actuality, the upper bit is never set, and so need never be removed. * Sidekick Plus Compatibilty ============================ We have noticed some serious side effects when executing compiled PowerBASIC programs while Borland's Sidekick Plus is resident. It seems that if any Terminate/Stay-Resident program (even something simple such as the PRINT program supplied with DOS) is loaded subsequent to Sidekick Plus, segment registers are occasionally altered during a timer tick interrupt. This can pose a serious threat to correct execution of your programs. We have found an apparent work-around: make certain that Sidekick Plus is always the very last TSR loaded in your system. In that configuration, we have not yet seen any errors. We would appreciate hearing any reports of problems you've encountered, as well as other symptoms or successful work-arounds. We'll try to gather as much detail as possible, to assist Borland in correcting this problem. * Novell's BTRIEVE ================== Novell's BTRIEVE is an efficient and easy-to use ISAM file manager, or indexed file system. It may be directly interfaced to PowerBASIC programs to allow fast, database-style access to files via alpha-numeric keywords, rather than just record numbers. We have created a single procedure, which will allow easy access to all BTRIEVE functions from any PowerBASIC program. It may de downloaded, in source code format, as the file BTRIEV.ZIP in our library section. The current version is dated May 3, 1990, and replaces an erroneous prior version, dated April 26, 1990. Please be sure to use only the latest, correct version. * Conversion from Turbo Basic ============================= PowerBASIC is built around the original syntax of Turbo Basic. While most programs will compile just "as-is", some will require a bit of change. The two key areas to watch are: 1. New reserved words conflicting with program variable names In order to extend the capabilities of this BASIC language, we have found it necessary to add many reserved words to the compiler. You may have used some of these words in your Turbo Basic programs as variable names, SUB/DEF FN routine names, or labels. When such a program is compiled with PowerBASIC, the most likely error to occur is Variable Expected (error 426). This means the compiler was looking for a variable and it found a reserved word instead (even though it looks like a variable to you, and was treated as such by Turbo Basic). In this case, you need to change the variable name to something which is not a reserved word. See pages 96-99 in the User's Guide for a complete list of reserved words. We regret the inconvenience but think you will appreciate the new features which this has allowed. 2. Name sharing between program variables and labels In PowerBASIC, variables, labels, DEF FN functions, FUNCTIONs, SUBs, modules ($LINK files), and external public labels (in .OBJ files $LINKed into your program) cannot share names with each other. In other words, you cannot have both a variable called COUNT% and a SUB called COUNT in the same program. You can, however, share names between variables: A$, A$$, A%, A&, A&&, A!, A#, A##, A@, and A@@ are 10 distinct variables. The most likely error to occur when names are incorrectly shared is Duplicate Name (error 466). Syntax errors (error 477) and Undefined Label/Line Reference errors (error 463) also occur under certain circumstances. There were several things which necessitated this change, but certainly the most significant was performance. If the compiler had to maintain multiple classes of identifiers with identical names, it would have significantly degraded compilation performance. Of course an added benefit is the fact that your programs will be easier to read and understand (for example, in "PRINT ABC", is "ABC" a variable or a call to the FUNCTION "ABC"? Worse yet, within the FUNCTION ABC, does "ABC = 1" refer to the return value of the function, or an external or shared variable by the same name?). * Units and Segments ==================== A unit may never, under any circumstances, span multiple segments. It follows, therefore, that a $SEGMENT meta-statement may never appear in a unit's source program. While the reference manual makes this point, the current version of PowerBASIC does not check for that error. It incorrectly allows a $SEGMENT meta-statement to be used, although the resulting programs will fail. This oversight will be corrected in future compiler updates. For now, be certain never to use $SEGMENT in a unit. Serious side effects can result. * Turbo Basic Toolboxes ======================= There are six changes which need to be applied to the toolbox source code in order to make it function properly under PowerBASIC. The toolbox code accesses certain string data directly via Turbo Basic's internal string descriptors. PowerBASIC uses a considerably different internal format for string data, in order to remove the old 64k string space limit. Because of these differences, the string handling routines in the Database Toolbox must be changed in order to work properly with PowerBASIC. The file TOOLFX.ZIP contains step-by-step instructions on how and where to make the necessary changes. It can be downloaded from the library section of this forum. If downloading is inconvenient, the file is also available on disk from Spectra Tech Support. * PRINT USING "^^^" =================== The current PowerBASIC documentation states: "Numbers can be output in scientific notation by including three to six carets (^) in the formatting string. In actuality, the current version of PowerBASIC will accept only four or more carets, just as other dialects of BASIC (BASICA, Turbo Basic, Quick Basic, GW-BASIC, etc.). The extension to three carets was planned, but not implemented. It will be included in the next major upgrade of PowerBASIC. * PRINT USING "-##.##" ====================== In Turbo Basic, putting a minus sign at the beginning of a numeric format string (PRINT USING "-##.##";-99) causes a negative number to be printed with a minus sign in front of it (-99.00). This was, unfortunately, a bug in Turbo Basic as it was inconsistent with the operation of BASICA. While the bug has been fixed in PowerBASIC, the description of PRINT USING in the PowerBASIC manual has not, which is no doubt very confusing. Our apologies. Corrections to the manual and examples appear in the library file USING.FIX. If you have Turbo Basic code which uses PRINT USING "-##.##", simply change the format string to "###.##" and it will work the same way in PowerBASIC (negative numbers will be displayed with a leading minus sign, positive numbers with a leading space). * LINE INPUT in Units ===================== When LINE INPUT is used in a PowerBASIC Unit without a "prompt" string, unwanted "garbage" is sometimes printed at the time of execution. There is a simple work-around: insert a prompt of a null string, which will then print nothing. Replace LINE INPUT A$ with LINE INPUT "" A$ * Debugging with $LINK'd .OBJ's =============================== Under some circumstances, you may encounter a problem debugging a PowerBASIC program which includes $LINK'd .OBJ files. Since the current version of PowerBASIC does not utilize any debugging information in .OBJ files, it is not possible to STEP INTO assembler procedures and functions. Due to some additional incompatibilities, there may also be a problem should you try to STEP OVER a $LINK meta-statement. For that reason, we suggest you place all $LINK (.obj) meta-statements at the very end of your program, preceded by an END statement. This will guarantee you never step over a $LINK, thereby guaranteeing you never experience the problem. This inconsistency will be corrected in the next major upgrade to PowerBASIC (along with some very interesting assembler enhancements). * Memory Management Tips ======================== Programming Proverb Number One: "Programs and data expand to consume all available memory" "( . . . and then some)" PowerBASIC is no exception. We've added many new features. The code has to go somewhere. Sometimes the result is the dreaded error 406: Compiler Out of Memory. We have lots planned for the future. In fact, the next major release of PowerBASIC will create program files of virtually unlimited size, even if you don't have EMS available. But what can you do right now? 1- Eliminate TSR's and Device Drivers which aren't absolutely necessary. 2- Reduce the arguments to commands in your CONFIG.SYS file (FILES, FCBS, STACKS, etc.). They all take memory. 3- Utilize the command line compiler (PBC.EXE) when necessary. 4- Turn all unneeded Error-checking OFF. Turbo Basic defaulted to all error checks off, while PowerBASIC defaults to ON, for safety sake. 5- Turn Integrated Debugging OFF, both in the main compilation, as well as any units which are to be linked. 6- Consider adding Expanded Memory (EMS) to your system, but only if the "Page Frame" (the 64k where EMS is accessed) is located above the standard 640k of main memory (that is, above paragraph A000h). Most hardware EMS meets that criteria; some software EMS drivers do not. If you are not sure, we have an EMS analysis program available in our library, to help you decide the value of a particular EMS implementation. In the current version of PowerBASIC (#2.00b), we utilize up to 64k of EMS for source file storage during compilation. Depending upon programming style, that 64k may increase your capacity by 25-100%. 7- Avoid procedural math mode, if possible. While this is far faster with no 8087, it does generate larger code, as noted in the manual. You may wish to limit procedural math to only those sections of your program which are extremely speed sensitive (use the $FLOAT meta-statement). 8- If you have EMS, make your main source file as large as possible. Use the entire 64k, if possible, before resorting to units or includes. If you do not have EMS, make your main source file as small as possible. Ideally, it would contain nothing except $INCLUDE and/or $LINK meta-statements. 9- Break up your code into many small modules, taking every possible advantage of units and/or includes. Keep all of the modules very close to the same size, as PB requires a buffer be reserved for linking, equal to the size of the largest module. If one module must be 40k, you may as well make them all 40k. But ideally, try to keep individual files down to around 8-12k for the maximum compaction. 10- Remove any unnecessary line numbers or labels, and shorten identifier names as much as possible. 11- Lastly, use PBPLUS96! If you have an EGA or VGA video card, it will allow PowerBASIC to "steal" 96k of memory from the card, to be used during compilation, or even running/debugging in the integrated environment. This extra 96k may increase your capacity by 35-120%, depending upon your programming style. Of course there are some limitations. It steals video memory from A000 to B7FF, so you can't execute graphics programs while using it. But for .EXE compilation, or debugging of text mode programs, it offers unmatched capacity. Best of all, it's FREE to all licensed users of PowerBASIC. Just download it from the PowerBASIC library, or contact Spectra Tech Support for a copy. * Wish Lists ============ Keep those cards and letters coming! Let us know what features YOU want in the next version of PowerBASIC! Your ideas and wishes are VERY important. Share them with us! Today! ************************************************************************