home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / basic / library / pb / library5 / pbnews.003 < prev    next >
Text File  |  1990-08-17  |  21KB  |  427 lines
  1. ************************************************************************
  2.                  PowerBASIC News
  3.  
  4.             Issue #3    <<====>>   August, 1990
  5.  
  6.     The latest information from the authors of PowerBASIC
  7.         =====================================================
  8.  
  9.   This file will be updated on a regular basis to provide PowerBASIC 
  10.   users with important news, programming tips, and other valuable
  11.   information.  Watch the library posting date to learn of each newly
  12.   published issue.  While some very important items will be carried 
  13.   over from issue to issue, you can count on new information whenever
  14.   the date changes.  Watch for it!
  15.  
  16. ************************************************************************
  17.  
  18.  
  19. * PowerBASIC Availability
  20. =========================
  21. The current version of PowerBASIC is Rev. #2.00b.  It is available world-
  22. wide from selected dealers, and now at all Egghead Discount Software 
  23. stores throughout the country.  If you can't find PowerBASIC locally, you
  24. can order directly from Spectra Publishing, 1030D East Duane Ave., 
  25. Sunnyvale, CA, 94086 -- 1-800-245-6717.  The suggested retail price is 
  26. $129.00.  Registered owners of Turbo Basic may upgrade to PowerBASIC for 
  27. $59.00, by providing their Turbo Basic serial number.
  28.  
  29.  
  30. * PowerBASIC "Patches"
  31. ======================
  32. We have released the third in a series of patches to be applied to
  33. PowerBASIC version #2.00b.  It may be downloaded from our library as the
  34. file PATCH3.ZIP.  It requires PBPATCH.EXE, which may be downloaded in 
  35. PATCH1.ZIP.  This patch corrects erroneous floating point results when
  36. numeric error checking is disabled, incorrect executable code generation
  37. when the INP() function is referenced in certain complex numeric 
  38. expressions, and unexpected results and side effects from execution of
  39. the CHAIN statement.  We urge all users of PowerBASIC #2.00b to implement
  40. all three patches as soon as possible.  
  41.  
  42. The first file, PATCH1, fixes premature "out of memory" errors when 
  43. compiling to a disk file, incorrect execution of CVF/CBCD/REMOVE$/REPLACE 
  44. in certain circumstances, single precision functions and FN's in procedural 
  45. mode, references to public  procedures (GET$LOC, etc.) from a chained file, 
  46. and incorrect error codes from ARRAY INSERT/DELETE.  The second file,
  47. PATCH2, corrects an incompatibility linking certain .OBJ files, a problem 
  48. with error addresses (ERADR/RESUME/NEXT) in emulated float mode, and 
  49. incorrect generation of string/array memory corrupt errors (error #242).  
  50.  
  51. If downloading from our library is inconvenient, the files are also available
  52. on disk from Spectra Tech Support.
  53.  
  54.  
  55. * Ambiguous DIM statements
  56. ==========================
  57. We've confirmed a rather obscure, but potentially serious bug in PowerBASIC
  58. #2.00b.  Under the folowing circumstances, a DIM statement can cause side
  59. effects, unrelated errors (overflow, function call, etc.), or even a system
  60. "hang".
  61.         1- An ambiguous (no static/dynamic option) DIM with literal indexes.
  62.     2- A later statement in the program which forces that array to be
  63.            considered dynamic (a second DIM, a COMMON, etc.).
  64.  
  65. This condition can be avoided by always including a STATIC or DYNAMIC option
  66. in each DIM statement, or by declaring a default to dynamic arrays (using the
  67. $DYNAMIC meta-statement) at the beginning of your program.
  68.  
  69.  
  70. * GET statement (graphics) 
  71. ==========================
  72. We have confirmed an error in the PowerBASIC Reference Guide concerning
  73. the formula used to determine the size of an array required for a GET
  74. graphics statement.  Internally, the current version of PowerBASIC uses
  75. the same incorrect formula.  This frequently results in too small of a
  76. data area to hold the graphics image, which may cause serious side effects.
  77. Please change page 133 in your manual as follows:
  78.  
  79. The correct formula is:
  80.  
  81. # of bytes required = 4 + INT((X * BitsPerPixelPerPlane + 7) / 8) *
  82.               Planes * Y
  83.  
  84. where X is the horizontal image length, Y is the vertical image length,
  85. and BitsPerPixelPerPlane and Planes depend on the screen mode selected:
  86.  
  87. Screen mode    BitsPerPixelPerPlane    Planes
  88. -----------    --------------------    ------
  89.     1                  2                 1
  90.     2                  1                 1
  91.     3                  1                 1
  92.     7                  1                 4
  93.     8                  1                 4
  94.     9                  1                 4
  95.     10                 1                 2
  96.     11                 1                 1
  97.     12                 1                 4
  98.  
  99.  
  100. * Calling PowerBASIC SUBS/FUNCTIONS from assembler modules
  101. ==========================================================
  102. As described on pages 290-291 of the Users Manual, PowerBASIC SUBs and
  103. FUNCTIONs may be called from assembler routines which are $LINKed into your
  104. programs.  The manual fails to point out, however, that when a SUB or
  105. FUNCTION is called, it may alter the contents of the AX, BX, CX, DX, SI, DI,
  106. and ES registers.  If your assembler routine expects the contents of any of
  107. these registers to remain constant, both before and after a PowerBASIC
  108. routine is called, you must save the appropriate registers before performing
  109. the call and restore them afterwards.  Also, prior to calling a PowerBASIC
  110. routine, the DS register must contain the same value that it had when your
  111. assembler routine was invoked (PowerBASIC's main data segment).
  112.  
  113.  
  114. * Standard output
  115. =================
  116. In the current version of PowerBASIC, as well as its predecessor Turbo
  117. Basic, we chose to PRINT via direct screen writes rather than using
  118. DOS or BIOS calls, due to the tremendous speed increase this provides.
  119. While speed is important, there are certain times when DOS output is
  120. preferable:  1-use of ANSI.SYS   2-redirection of standard output.  We
  121. recognize this, and have committed to a change in the next version of
  122. PowerBASIC.  At that time, we will be adding a "CONS:" device, which
  123. will optionally write to DOS standard output.  Redirection of both
  124. input and output will then be supported via "KYBD:" and "CONS:".  In
  125. the current version of PowerBASIC, standard output can be accessed
  126. with the following SUB:
  127.  
  128.   SUB StdOutput(text$)
  129.     for i% = 1 to len(text$)
  130.       reg 1, &h0200
  131.       reg 4, asc(mid$(text$,i%))
  132.       call interrupt &h21
  133.     next i%
  134.   END SUB
  135.  
  136.  
  137. * Assembler FUNCTIONS
  138. =====================
  139. For those of you who may be writing assembler functions for floating point
  140. math, we have a major change coming in the future!  In PowerBASIC #2.00b,
  141. a single-precision FUNCTION returns it's value to the caller in the 8087
  142. numeric co-processor (or emulator) at the "top-of-stack".  This would
  143. normally be implemented by:  FLD return_value.  In the next version of
  144. PowerBASIC, I'm afraid we found it necessary to alter this convention.
  145. Single precision floats will now be returned in the DX:AX register pair
  146. instead.  This change has no effect on any data type other than single's.
  147.  
  148.  
  149. * Printer DEVICE TIMEOUT errors
  150. ===============================
  151. Some PowerBASIC users have reported a problem with error 24 (Device Timeout)
  152. when writing to their printer.  If you experience this problem, there may be
  153. a solution.  PowerBASIC utilizes the BIOS for all printer output, and only
  154. "passes along" an error report generated by the BIOS.  The BIOS does allow
  155. the timeout value to be changed from it's normal default of 20 seconds.  In
  156. fact, it can be increased to as much as 255 seconds.  All you need do is:
  157.  
  158.     DEF SEG = 0
  159.     POKE &H478, 255  ' for 255 seconds
  160.  
  161. If this fix is successful, you might compile the above code to an .EXE file
  162. and include it as part of AUTOEXEC.EXE to automatically configure whenever
  163. your system is started.
  164.  
  165.  
  166. * Huge FIELD Statements
  167. =======================
  168. Certain statements in Basic (such as FIELD) have the potential to cause
  169. huge amounts of code to be generated. This is a consequence of complexity,
  170. as well as the fact that parts of them may be repeated an unlimited number 
  171. of times, by using line continuation characters.  In fact, we've found that
  172. some Turbo Basic users have constructed FIELDS of more than 400 sub-strings.
  173. In PowerBASIC, we limited the size of some internal buffers in an effort to
  174. conserve precious memory, and have found that some very large FIELD
  175. statements may not compile properly.  If buffer space is exceeded, PB will
  176. normally generate an error 402: Statement too complex.  Also, in extreme
  177. cases, it is possible for PB to "hang" or have other undesirable side
  178. effects.  While this will be corrected in the next version of PowerBASIC,
  179. there is a simple way to break down large field statements:
  180.  
  181.   FIELD #1, 5 as a$, 5 as b$, 5 as c$, 5 as d$, 5 as e$, 5 as f$
  182.  
  183.     could also be implemented as:
  184.  
  185.   FIELD #1, 5 as a$, 5 as b$
  186.   FIELD #1, 10 as dummy$, 5 as c$, 5 as d$
  187.   FIELD #1, 20 as dummy$, 5 as e$, 5 as f$
  188.  
  189.  
  190. * Internal Representation of Strings
  191. ====================================
  192. Internally to PowerBASIC, strings are referenced by an integer "handle" or
  193. id number.  This handle may range from 1 to 32767.  On page 274 of the
  194. User's guide, it incorrectly states that "The upper bit . . . must be
  195. logically ANDed off of the value to arrive at the true handle number of the
  196. string."  In actuality, the upper bit is never set, and so need never be
  197. removed.
  198.  
  199.  
  200. * Sidekick Plus Compatibilty
  201. ============================
  202. We have noticed some serious side effects when executing compiled PowerBASIC
  203. programs while Borland's Sidekick Plus is resident.  It seems that if any
  204. Terminate/Stay-Resident program (even something simple such as the PRINT
  205. program supplied with DOS) is loaded subsequent to Sidekick Plus, segment
  206. registers are occasionally altered during a timer tick interrupt.  This can
  207. pose a serious threat to correct execution of your programs.  We have found
  208. an apparent work-around:  make certain that Sidekick Plus is always the very
  209. last TSR loaded in your system.  In that configuration, we have not yet seen
  210. any errors.  We would appreciate hearing any reports of problems you've
  211. encountered, as well as other symptoms or successful work-arounds.  We'll
  212. try to gather as much detail as possible, to assist Borland in correcting
  213. this problem.
  214.  
  215.  
  216. * Novell's BTRIEVE
  217. ==================
  218. Novell's BTRIEVE is an efficient and easy-to use ISAM file manager, or
  219. indexed file system.  It may be directly interfaced to PowerBASIC programs
  220. to allow fast, database-style access to files via alpha-numeric keywords,
  221. rather than just record numbers.  We have created a single procedure, which 
  222. will allow easy access to all BTRIEVE functions from any PowerBASIC program.
  223. It may de downloaded, in source code format, as the file BTRIEV.ZIP in our 
  224. library section.  The current version is dated May 3, 1990, and replaces an
  225. erroneous prior version, dated April 26, 1990.  Please be sure to use only
  226. the latest, correct version.
  227.  
  228.  
  229. * Conversion from Turbo Basic
  230. =============================
  231. PowerBASIC is built around the original syntax of Turbo Basic.  While
  232. most programs will compile just "as-is", some will require a bit of
  233. change.  The two key areas to watch are:
  234.  
  235. 1. New reserved words conflicting with program variable names
  236.  
  237. In order to extend the capabilities of this BASIC language, we have
  238. found it necessary to add many reserved words to the compiler.  You
  239. may have used some of these words in your Turbo Basic programs as
  240. variable names, SUB/DEF FN routine names, or labels.  When such a 
  241. program is compiled with PowerBASIC, the most likely error to occur
  242. is Variable Expected (error 426).  This means the compiler was 
  243. looking for a variable and it found a reserved word instead (even 
  244. though it looks like a variable to you, and was treated as such by
  245. Turbo Basic).  In this case, you need to change the variable name
  246. to something which is not a reserved word.  See pages 96-99 in the 
  247. User's Guide for a complete list of reserved words.  We regret the
  248. inconvenience but think you will appreciate the new features which
  249. this has allowed.
  250.  
  251. 2. Name sharing between program variables and labels
  252.  
  253. In PowerBASIC, variables, labels, DEF FN functions, FUNCTIONs, SUBs,
  254. modules ($LINK files), and external public labels (in .OBJ files 
  255. $LINKed into your program) cannot share names with each other.  In
  256. other words, you cannot have both a variable called COUNT% and a
  257. SUB called COUNT in the same program.  You can, however, share names
  258. between variables: A$, A$$, A%, A&, A&&, A!, A#, A##, A@, and A@@ are
  259. 10 distinct variables.  The most likely error to occur when names are
  260. incorrectly shared is Duplicate Name (error 466).  Syntax errors
  261. (error 477) and Undefined Label/Line Reference errors (error 463)
  262. also occur under certain circumstances.
  263.  
  264. There were several things which necessitated this change, but
  265. certainly the most significant was performance.  If the compiler had
  266. to maintain multiple classes of identifiers with identical names, it
  267. would have significantly degraded compilation performance.  Of course
  268. an added benefit is the fact that your programs will be easier to 
  269. read and understand (for example, in "PRINT ABC", is "ABC" a variable
  270. or a call to the FUNCTION "ABC"?  Worse yet, within the FUNCTION ABC,
  271. does "ABC = 1" refer to the return value of the function, or an 
  272. external or shared variable by the same name?).
  273.  
  274.  
  275. * Units and Segments
  276. ====================
  277. A unit may never, under any circumstances, span multiple segments.  It
  278. follows, therefore, that a $SEGMENT meta-statement may never appear in
  279. a unit's source program.  While the reference manual makes this point,
  280. the current version of PowerBASIC does not check for that error.  It
  281. incorrectly allows a $SEGMENT meta-statement to be used, although the
  282. resulting programs will fail.  This oversight will be corrected in
  283. future compiler updates.  For now, be certain never to use $SEGMENT in 
  284. a unit.  Serious side effects can result.
  285.  
  286.  
  287. * Turbo Basic Toolboxes
  288. =======================
  289. There are six changes which need to be applied to the toolbox source
  290. code in order to make it function properly under PowerBASIC.  The
  291. toolbox code accesses certain string data directly via Turbo Basic's
  292. internal string descriptors.  PowerBASIC uses a considerably different
  293. internal format for string data, in order to remove the old 64k string
  294. space limit.  Because of these differences, the string handling routines
  295. in the Database Toolbox must be changed in order to work properly with
  296. PowerBASIC.  The file TOOLFX.ZIP contains step-by-step instructions on
  297. how and where to make the necessary changes.  It can be downloaded from
  298. the library section of this forum.  If downloading is inconvenient, the 
  299. file is also available on disk from Spectra Tech Support.
  300.  
  301.  
  302. * PRINT USING "^^^"
  303. ===================
  304. The current PowerBASIC documentation states: "Numbers can be output in
  305. scientific notation by including three to six carets (^) in the formatting
  306. string.  In actuality, the current version of PowerBASIC will accept only
  307. four or more carets, just as other dialects of BASIC (BASICA, Turbo Basic,
  308. Quick Basic, GW-BASIC, etc.).  The extension to three carets was planned,
  309. but not implemented.  It will be included in the next major upgrade of
  310. PowerBASIC.
  311.  
  312.  
  313. * PRINT USING "-##.##"
  314. ======================
  315. In Turbo Basic, putting a minus sign at the beginning of a numeric
  316. format string (PRINT USING "-##.##";-99) causes a negative number to
  317. be printed with a minus sign in front of it (-99.00).  This was,
  318. unfortunately, a bug in Turbo Basic as it was inconsistent with the
  319. operation of BASICA.  While the bug has been fixed in PowerBASIC, the
  320. description of PRINT USING in the PowerBASIC manual has not, which is
  321. no doubt very confusing.  Our apologies.  Corrections to the manual
  322. and examples appear in the library file USING.FIX.  If you have Turbo
  323. Basic code which uses PRINT USING "-##.##", simply change the format
  324. string to "###.##" and it will work the same way in PowerBASIC 
  325. (negative numbers will be displayed with a leading minus sign, 
  326. positive numbers with a leading space).
  327.  
  328.  
  329. * LINE INPUT in Units
  330. =====================
  331. When LINE INPUT is used in a PowerBASIC Unit without a "prompt" string,
  332. unwanted "garbage" is sometimes printed at the time of execution.  There
  333. is a simple work-around:  insert a prompt of a null string, which will then
  334. print nothing.  Replace  LINE INPUT A$   with   LINE INPUT "" A$
  335.  
  336.  
  337. * Debugging with $LINK'd .OBJ's
  338. ===============================
  339. Under some circumstances, you may encounter a problem debugging a PowerBASIC
  340. program which includes $LINK'd .OBJ files.  Since the current version of
  341. PowerBASIC does not utilize any debugging information in .OBJ files, it is
  342. not possible to STEP INTO assembler procedures and functions.  Due to some
  343. additional incompatibilities, there may also be a problem should you try to
  344. STEP OVER a $LINK meta-statement.  For that reason, we suggest you place all
  345. $LINK (.obj) meta-statements at the very end of your program, preceded by an
  346. END statement.  This will guarantee you never step over a $LINK, thereby
  347. guaranteeing you never experience the problem.  This inconsistency will be
  348. corrected in the next major upgrade to PowerBASIC (along with some very
  349. interesting assembler enhancements).
  350.  
  351.  
  352. * Memory Management Tips
  353. ========================
  354. Programming Proverb Number One:
  355.  
  356.      "Programs and data expand to consume all available memory"
  357.                          "( . . . and then some)"
  358.  
  359. PowerBASIC is no exception.  We've added many new features.  The code has
  360. to go somewhere.  Sometimes the result is the dreaded error 406: Compiler 
  361. Out of Memory.  We have lots planned for the future.  In fact, the next
  362. major release of PowerBASIC will create program files of virtually unlimited
  363. size, even if you don't have EMS available.  But what can you do right now?
  364.  
  365. 1- Eliminate TSR's and Device Drivers which aren't absolutely necessary.
  366.  
  367. 2- Reduce the arguments to commands in your CONFIG.SYS file (FILES, FCBS,
  368. STACKS, etc.).  They all take memory.
  369.  
  370. 3- Utilize the command line compiler (PBC.EXE) when necessary.
  371.  
  372. 4- Turn all unneeded Error-checking OFF.  Turbo Basic defaulted to all error
  373. checks off, while PowerBASIC defaults to ON, for safety sake.
  374.  
  375. 5- Turn Integrated Debugging OFF, both in the main compilation, as well as
  376. any units which are to be linked.
  377.  
  378. 6- Consider adding Expanded Memory (EMS) to your system, but only if the
  379. "Page Frame" (the 64k where EMS is accessed) is located above the standard
  380. 640k of main memory (that is, above paragraph A000h).  Most hardware EMS
  381. meets that criteria; some software EMS drivers do not.  If you are not sure,
  382. we have an EMS analysis program available in our library, to help you decide 
  383. the value of a particular EMS implementation.  In the current version of 
  384. PowerBASIC (#2.00b), we utilize up to 64k of EMS for source file storage 
  385. during compilation.  Depending upon programming style, that 64k may increase
  386. your capacity by 25-100%.
  387.  
  388. 7- Avoid procedural math mode, if possible.  While this is far faster with 
  389. no 8087, it does generate larger code, as noted in the manual.  You may wish
  390. to limit procedural math to only those sections of your program which are
  391. extremely speed sensitive (use the $FLOAT meta-statement).
  392.  
  393. 8- If you have EMS, make your main source file as large as possible. Use the
  394. entire 64k, if possible, before resorting to units or includes.  If you do
  395. not have EMS, make your main source file as small as possible.  Ideally, it
  396. would contain nothing except $INCLUDE and/or $LINK meta-statements.
  397.  
  398. 9- Break up your code into many small modules, taking every possible
  399. advantage of units and/or includes.  Keep all of the modules very close
  400. to the same size, as PB requires a buffer be reserved for linking, equal to
  401. the size of the largest module.  If one module must be 40k, you may as well
  402. make them all 40k.  But ideally, try to keep individual files down to around
  403. 8-12k for the maximum compaction.
  404.  
  405. 10- Remove any unnecessary line numbers or labels, and shorten identifier
  406. names as much as possible.
  407.  
  408. 11- Lastly, use PBPLUS96!  If you have an EGA or VGA video card, it will 
  409. allow PowerBASIC to "steal" 96k of memory from the card, to be used during 
  410. compilation, or even running/debugging in the integrated environment.  This 
  411. extra 96k may increase your capacity by 35-120%, depending upon your 
  412. programming style.  Of course there are some limitations.  It steals video 
  413. memory from A000 to B7FF, so you can't execute graphics programs while 
  414. using it.  But for .EXE compilation, or debugging of text mode programs, it 
  415. offers unmatched capacity.  Best of all, it's FREE to all licensed users of
  416. PowerBASIC.  Just download it from the PowerBASIC library, or contact
  417. Spectra Tech Support for a copy.
  418.  
  419.  
  420. * Wish Lists
  421. ============
  422. Keep those cards and letters coming!  Let us know what features YOU want
  423. in the next version of PowerBASIC!  Your ideas and wishes are VERY
  424. important.  Share them with us!  Today!
  425.  
  426. ************************************************************************
  427.