madd@bu-cs.BU.EDU (Jim Frost) (01/13/88)
For those of you who are interested in Turbo Pascal version 4.0 but haven't had the chance to try it, here is a hands-on review of the program. We had it on backorder since it was first introduced, and it showed up in early December. I have spent 3 weeks working with it. NOTES The manual is much larger than the old. The basic style of the manual is the same. The most noteworthy thing about the manual is that it states several things about version 3.0 which are not documented (so far as I could tell, and I *looked*) in the 3.0 manual. Particularly, there is a boolean variable "cbreak" which, in 3.0, supposedly controlled whether or not ^C could interrupt a program. The documentation noted that this variable had been renamed. I searched the 3.0 manual for considerable time but could only find references to user break control in the $u and $c compiler directives. A similar note applied to the procedure ExitProc, which the 4.0 manual claimed allowed you to redefine the exit procedure of a program. There was no reference to such a beast anywhere in the 3.0 manual. INTEGRATED ENVIRONMENT The editor is much like that in Turbo C but with some prettification. It has the same look and feel as the Turbo C editor. There are many enhancements that make it easier to use (such as the ability to shell out of the editor). It takes more effort to negotiate the integrated environment than before, but this is the result of a cleaner and more versatile interface. It took me only a few minutes to get the feel of the new environment. I did not make use of the standalone compiler, nor of the provided "make" utility, so I cannot comment on them. HELP The help function within the editor is FANTASTIC. Unlike that of of Turbo C (1.0), it provides quick-reference to just about everything discussed in the manual. Even better, the help uses a hypertext concept to link help pages. Finding your way around is a dream. The only real lack that I found was that it did not explain the compiler directives (eg $m, $ifdef, etc). It was possible to utilize many of the new functions without ever touching the manual. IMPROVEMENTS The one that almost everyone has been waiting for: programs with more than 64K of code. Yes, it's here. There is still a 64K code limit, but it's local to what TPascal 4.0 calls "units", basically a code module. As many units as you like may go into a program, but no one unit may be larger than 64K. While this seems to be a solution to everyone's problems, it is interesting to note that the 64K data limitation is still in effect. In addition, the 64K data limitation applies to ALL global variables in ALL units. The manual recommends redefining large data structures as pointers and doing heap allocations if you run out of data space, a common method used in TPascal 3.0. In reference to "units", Modula-2 users should feel right at home. The definition of units is very similar to that used in Modula-2, which is not terribly surprising. There are many new compiler directives. The most important new ones (to me) are $m, which allows inline declaration of heap and stack sizes (a boon to anyone writing TSR's), and $ifdef/$elseif/$endif for conditional compilation. A caveat: Many of the old compiler directives are no longer supported. In most cases, this just causes a compilation halt, but in the case of $u, which used to indicate whether user interrupts, is now used for something else (exactly what has slipped my mind). An error is not generated when $u+ or $u- is encountered. This had no effect on my programs, though. You may declare interrupt procedures. Where older versions of TPascal needed inline statements for the preservation/restoration of registers, the new one does this automatically. It also provides the registers as arguments to the function, quite a good idea. An example program that uses this new function is provided on disk; this example shows an interrupt routine to handle communications ports, something that I found tricky using TPascal 3.0. Several units are included with TPascal. These include units for handling graphics (the graphics support is literally amazing; wait until you see how many new graphics programs are about to come out), many MS-DOS commands, enhanced crt/keyboard control, and even one to help port TPascal 3.0 programs. Another useful thing about units is the ability to define initialization and exit procedures for each unit. The first time something in a unit is called, an initialization routine is called (if provided). This makes variable initialization a snap, although it can make debugging hairy because the call is implicit. You may similarly declare an exit procedure to do cleanups. By default, TPascal 4.0 uses the MS-DOS file handles for I/O instead of its own "fast" routines as in earlier versions. What this means to the programmer is that you no longer have to add $g and $p directives in order to allow your programs' output to be redirected. One of the greatest new things is the ability to change the I/O drivers. You can now set pointers to functions to handle any kind of I/O, making it possible to tremendously enhance your programs by including custom drivers with virtually no program modification. Support for math coprocessors is considerably enhanced, too, with new data types that give greater flexibility and precision. An extremely useful thing added to 4.0 is a shorthand version of the addr() function used in previous versions. If you swap pointers around, you'll like the ability to use the "@" symbol as a unary operator to give the address of an object. COMPATIBILITY The only real incompatibility I could find related to the crt and keyboard handling, which has changed somewhat. The "kbd" file is missing now, but this can be fixed using the compatibility unit mentioned earlier. Some of my programs exibited strange behavior when compiled under 4.0 using the 3.0 compatibility unit, but I was unable to determine a cause easily. I suspect that this is related to the change from using "fast" I/O drivers to using the normal MS-DOS file handles. Incompatibilities with the compiler directives have already been mentioned. Programs that used intr() or msdos() must be changed to use the predefined type "register". All of my programs that utilized these features compiled and ran flawlessly. SPEED While Borland claims an improvement in speed over TPascal 3.0, most programs did not run much faster. The I/O routines, however, appeared to be substantially faster, resulting in performance boosts for anything that made frequent use of the disk or crt. Some programs may benefit from optimization that is done in 4.0 but was not done in 3.0. While this optimization is not extensive, it can have a real effect on your programs in some cases. See the manual for more details. Compilation speed is fantastic, somewhat faster than 3.0 even including the link step. GENERAL OPINIONS This product will probably dominate the Pascal market for some time to come. Its significant enhancements, fantastic integrated environment, and versatile libraries will make it a boon to Pascal programmers. I was impressed with Borland's attention to detail. They met almost every complaint that users had with the older versions of TPascal and added enhancements to meet the needs of programmers that try to squeeze every bit of performance from their programs. The only failing that I could note was the 64K data space limitation on global variables. If you've never used Pascal on a PC before, you may want to try out TPascal 4.0. If you have earlier versions of TPascal, you really want to upgrade. If you are using graphics for anything, you REALLY want to look at this. The graphics support is spectacular. This product is quite impressive. If you have any questions or comments on anything I have mentioned in this article, feel free to discuss them with me. I may be reached at the addresses below via email. Disclaimer: I am not, never have been, and don't ever expect to be related to Borland in any other way than as a pretty satisfied customer. jim frost ARPA: madd@bu-it.bu.edu UUCP: ..!harvard!bu-cs!madd BITNET: madd%bu-it.bu.edu@bostonu
Ralf.Brown@B.GP.CS.CMU.EDU (01/13/88)
Some comments on Jim Frost's excellent review: }states several things about version 3.0 which are not documented (so }far as I could tell, and I *looked*) in the 3.0 manual. Particularly, }there is a boolean variable "cbreak" which, in 3.0, supposedly }controlled whether or not ^C could interrupt a program. The Cbreak only took effect when $u and $c were active, i.e. the program could temporarily shut off Ctrl-Break checking. }documentation noted that this variable had been renamed. I searched }the 3.0 manual for considerable time but could only find references to }user break control in the $u and $c compiler directives. A similar }note applied to the procedure ExitProc, which the 4.0 manual claimed }allowed you to redefine the exit procedure of a program. There was no ExitProc subsumes the function of ErrorPtr, which allowed you to create a custom fatal-error handler. }The help function within the editor is FANTASTIC. Unlike that of }of Turbo C (1.0), it provides quick-reference to just about everything }discussed in the manual. Even better, the help uses a hypertext TC 1.5 now includes help for library functions, just like TP4--put the cursor on the function name, and hit Ctrl-F1. Then use the hypertext links to get to related functions. }everyone's problems, it is interesting to note that the 64K data }limitation is still in effect. In addition, the 64K data limitation }applies to ALL global variables in ALL units. The manual recommends Because typed variables now share the data segment with globals, rather than the code segment, some programs that worked under 3.0 may run out of data space under 4.0. }Several units are included with TPascal. These include units for }handling graphics (the graphics support is literally amazing; wait }until you see how many new graphics programs are about to come out), Also for TC1.5, because that includes the same functions, with the same arguments. If the author of the TPC TPas-to-C converter updates it to handle TP4, graphics programs written in Turbo Pascal will need almost no touch-ups after conversion. }Another useful thing about units is the ability to define }initialization and exit procedures for each unit. The first time }something in a unit is called, an initialization routine is called (if The initialization code is called *before* the main program begins (see pg 89). } }jim frost }ARPA: madd@bu-it.bu.edu }UUCP: ..!harvard!bu-cs!madd }BITNET: madd%bu-it.bu.edu@bostonu } -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make. FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?