BASIC Wars 2
Volume Number: 3
Issue Number: 2
Column Tag: BASIC School
By Dave Kelly, MacTutor Editorial Board, General Dynamics Corp.
This episode of BASIC Wars finds us looking at the newly released Microsoft Basic
Compiler (version 1.0) and MS Basic Interpreter (version 3.0). In the first episode
several months back we were introduced to several of the newcomers to Basic
programming on the Macintosh. I refer you to the August 1986 MacTutor Basic
column entitled "And then came Basic Wars!" for an introduction to ZBasic, True
Basic, and PCMacBasic. Of these three, ZBasic now appears to be leading the race. If
you have been following the Basic Wars Saga, you know of the major improvements in
the reliability of ZBasic. It has come a long ways from the frequent bombs to the fairly
reliable product we see now. Finally after a long wait (and some pressure from
competition like ZBasic) Microsoft has recently released version 3.0 of the MS Basic
Interpreter and version 1.0 of the new Microsoft Basic Compiler.
BASIC 3.0 Improvements
Before the battle begins, we should discuss the MS Basic Interpreter, version
3.0. By now most of you have heard about the improvements that have been made and
registered owners have had a chance to upgrade for $25 (Well worth $25, I might
add). MS Basic Interpreter is still a very reliable product just as before with major
enhancements (i.e. value added). To begin, here is a brief overview of some of the new
features:
First and very importantly, Microsoft has now bundled the CLR ToolLib Library
with the interpreter. This alone is worth the $25 to upgrade from earlier versions,
e specially if you didn't already have CLR ToolLib. There are some new and improved
toolbox calls included which were not in the original CLR ToolLib. Among those that
were added to the original CLR ToolLib are:
BringToFront CmdKey DisposeDialog GetDialogBut GetDialogText
GetMouse GetNewDialog ModalDialog PtInRects RealFont
SetArray SetCreate SetDialogBut SetDialogText SetItemStyle
SetOrigin SetWindowPic SetWTitle SubPt
The list above is fairly complete unless I missed adding something to the list. One
great advantage is that now the library calls provided will be more widely used.
Previously only those who puchased the CLR Libraries could take advantage of them.
This limited the type of programs which could be widely distributed to those that could
be written without CLR Libraries. I expect that we will be seeing more widespread use
of the Libraries now that they are part of the interpreter package. (NOTE: ZBasic
claims to have more Toolbox calls available, but some if not most of them are still not
compatible with other ZBasic calls. Example: INSERTRESMENU is not compatible with
ZBasic MENU statement. However, INSERTRESMENU is not available with the MS Basic
Libraries. Maybe CLR will write some more for us!! The MS ToolLib routines are
compatible with all MS Basic commands).
Fig. 1 MS Compiler Options Dialog
The long awaited HFS incompatibility has been corrected with version 3.0. The
FILES$ statement now returns the full pathname for HFS files (MFS is not changed).
In version 2.x the FILES$ statement would only return the full pathname for a file in
the root directory. This problem has been corrected with version 3.0. A new Basic
statement has been added - CHDIR. CHDIR changes the current default directory to one
specified with the statement. Using CHDIR is similar to setting the PREFIX command in
ProDos on the Apple ][ series computers or using 'cd' on a UNIX™ operating system.
(NOTE: no equivalent in ZBasic). Also notice that since the Scrapbook DA uses the
default disk, the Scrapbook file that can be accessed will change when the CHDIR
statement is used. Problems with single voice sound and the new ROM's has been fixed
with version 3.0.
Now up to six windows can be opened at the same time. Older versions of the
interpreter only allowed 4 windows open. (Note: ZBasic also allows up to six windows
open). WINDOW(6) now returns the handle for the active edit field in the current
output window. WINDOW(6) returns zero if the window has no active edit field. This
function is useful with some toolbox functions.
The EDIT FIELD statement has been enhanced to include the type values 5,6,7 and
8. These types correspond to the types 1,2,3 and 4 except that the default text in the
EDIT FIELD is not highlighted. This will be useful in programming a text editor
application ( read on for more statements to make this possible).
Multi-line IF/THEN/ELSE statements are now allowed. Use of multi-line
IF/THEN/ELSE improves readability of your program and fewer program lines are
required in many cases. For better program structure, the multi-line IF/THEN/ELSE
statement makes it easier to avoid the use of GOTO (a no-no if you are following good
programming techniques). ZBasic provides multi-line IF/THEN/ELSE via use of the
LONG IF/XELSE statement. MS Basic 3.0 uses the following IF/THEN/ELSE structure:
IF condition THEN
statement [statement ] :
ELSEIF condition THEN
statement [statement ] :
ELSE
statement [statement ] :
END IF
While ZBasic multi-line IF/THEN/ELSE statements are functionally the same as
the MS Basic implementation, it should be noted that the MS Basic syntax follows a
more traditional implementation (as done in other languages). The MS Basic
implementation is compatible with the ANSI (American National Standards Institute)
Basic implementation.
The new function SADD returns the address of the first byte of data in a string
expression. This will typically be used to pass the address of a string to a
machine-language routine. [Since the first byte of a Macintosh Pascal string is the
length byte, getting to the first character is a bit of a pain. This function is a nice
addition. -Ed.]
Improvements have been made to Apple LaserWriter and LaserWriter Plus
support. Printer support was lacking in previous versions of MS Basic. I have not
verified exactly what improvements have been made. I will reserve that subject for a
future issue of MacTutor.
The Basic runtime interpreter package is now bundled with the full interpreter
for distributing your programs to others that don't have the interpreter without
paying any runtime fees or licenses. The interpreter routines are the same, but the
runtime package has no editor and no way to change your program.
Other than what I have just mentioned, there are no other documented changes. It
is apparent that there are some improvements that are not documented. One such
improvement is found in an example named 'DOUBLE CLICK ME' on the MS Basic disk 1
(there are two disks now, one for Basic and one for the ToolLib stuff). It is also found
in a program named 'QnD' on the compiler Toolbox disk. 'QnD' stands for 'Quick and
Dirty'. MS has provided us with a quick and dirty editor program written in Basic.
Until now a text editor could not be written with either MS Basic or ZBasic. Several
new statements show up in boldface in the program:
TECALTEXT WINDOW(6)
TEUPDATE VARPTR(rC(0)),WINDOW(6)
TESCROLL oFirstCh*-10,oFirstLn*-16,WINDOW(6)
TEACTIVATE WINDOW(6)
Also found on the MS Basic Interpreter disk in a demo file also named 'DOUBLE
CLICK ME':
TESETTEXT SADD(OldEdit$),LEN(OldEdit$),WINDOW(6)
TEUPDATE VARPTR(rC(0)),WINDOW(6)
Since these statements are in boldface it follows that they are a part of the
reserved words built into Basic. It is exciting to find out that they exist because they
fill a void. Text editing has been limited in Basic. At the present time I don't have any
information on the proper use of these statements, but Microsoft has promised to send
me information which I can pass on to you. I suggest that if you want to try to use them
before you have documentation that you do so with caution. I will bring you more
information on how to use these statements in a future issue as soon as I can get the
information from Microsoft on them. (NOTE: these are also supported by the MS
Compiler too!).
MS Basic Compiler Unveiled
Finally after months of rumors the MS Basic Compiler has been officially
released. Of the compiled basic products now available this one is number one for
compatibility with the MS Basic interpreter. There are a few small modifications that
may be needed in some programs, but most programs will not require any
modification. Compiled programs will likely run up to 10 times faster than the
interpreter. Note how similar the options dialog in fig. 1 is to MacFortran. This is
because Absoft wrote the compiler. We may find many more similarities between these
two compilers in time. The additions and enhancements to the interpreter version 3.0
are all supported by the compiler including the Toolbox libraries. The same CLR
ToolLib which is included with the interpreter is also included with the compiler. It
should be noted here that any other libraries from CLR or others you may have written
for the interpreter are supported equally well by the compiler. The compiler does not
support calls to routines written in other languages unless they follow the guidelines
setup in "Building Machine Language Libraries". There are a few differences in the
BASIC language provided by the interpreter and the compiler. One additional statement
(not supported by the interpreter) is the SELECTCASE construct. SELECTCASE is a
useful statement which is supported by the ANSI (American National Standards
Institute) standard for Basic (also supported by True Basic and many other languages).
With the compiler you may declare your arrays to be static or dynamic. Dynamic
arrays can be erased and redimensioned during runtime. Static arrays are set up at
compile time and cannot be redimensioned during runtime. All definitions of functions
and declaration of variables should appear at the beginning (or close to the beginning)
of your compiled program. For example if a function defined by using a GOSUB at the
beginning of your program and the subroutine with the function definition appears
sequentially later in the program than the first line where the function is called, the
compiled program will not work properly. The solution is to define the function and
dimension arrays early in the program and avoid setting up functions and dimensions
in subroutines.
Compiled subprograms may be called recursively. This allows subprograms to
call themselves. Programs written for the MS Basic interpreter will not work
recursively. An example is the mathematical factorial function where N! =
1*2*3...*N. A sample subprogram would be the following:
SUB fact (x, result)
IF x = 1 THEN
result = 1
ELSE
CALL fact(x-1,newresult)
result = x * newresult
END IF
END SUB
Most interpreter programs you will find will compile with no modifications. And
best of all they still work as expected. This is not true if you try to convert MS Basic
programs to ZBasic. The structure is very similar, but not all the commands work
exactly the same way that the MS Basic interpreter and compiler does.
Before we get too far ahead of ourselves in talking about the compiler, it should
be noted that the compiler should be thought of as a stand alone package. In other
words, although it is compatible with the interpreter, the interpreter is NOT required
to write and compile programs. The Apple EDIT program (version 2.0) is included
with the compiler. Actually any editor program will work. It just so happens that it
is convenient to use the interpreter's editor if you have both the interpreter and
compiler. This way you can run your program (provided you understand the few
differances between the interpreter and the compiler) with the interpreter until it is
debugged. Then when your program runs like you want it to, you may then save the
program as TEXT and run the compiler. Both the compler and the interpreter have
added a Transfer item in the File menu for transferring from one application to
another (in this case from the interpreter to the compiler). You could transfer to and
from the EDIT application to compiler equally as well. It should be noted that the last
line of a program saved by EDIT is lost when read in by the interpreter. So BEWARE. I
don't know which is at fault, interpreter editor or EDIT program (I think it is the
interpreter editor but I don't know for sure), but it is not hard to work around this
bug.
Two methods may be used in compiling your programs. A set of runtime files
(called runtime overlays) may be attached to your application at compile time to
create a full double-clickable standalone application. Or you can compile just the
program or set of programs (via a compiler list) and use the runtime files separately.