home *** CD-ROM | disk | FTP | other *** search
- UPDATE.DOC
- Release Notes for Microsoft(R) QuickBASIC Version 4.00b
- for IBM(R) Personal Computers and Compatibles
-
- (C) Copyright Microsoft Corporation, 1987, 1988
-
- This document is divided into three parts. Part 1 describes features that have
- been added since Microsoft(R) QuickBASIC 4.0 was released. Part 2 lists
- corrections made to the software. Part 3 describes how to install a patch for
- MS-DOS(R) 3.20 for systems that meet certain requirements.
-
- ===< Part 1: New Features >===
-
- ---< Enhanced Error Handling >---
-
- Microsoft QuickBASIC Version 4.00b includes an important new error-handling
- feature for multiple-module programs. See Chapter 6 of Programming in BASIC:
- Selected Topics for a thorough discussion of error handling and event handling.
-
- In previous versions of QuickBASIC, an error in a module that did not contain
- an error handler caused the program to terminate immediately, even if an error
- handler was present in a different module. QuickBASIC 4.00b first looks for an
- active error handler in the module where the error occurred, then in the module
- that invoked that module, and so on. QuickBASIC follows the chain of procedure
- invocations back until it finds an active error handler or reaches the
- program's main module. If QuickBASIC cannot find an error handler by this
- process, the program terminates with an error message.
-
- Note that if the error occurs in an event-handling routine, however, QuickBASIC
- does not search for an error handler beyond the module that invoked the event
- handler.
-
- This feature affects the behavior of the RESUME statement. In previous versions
- of QuickBASIC, RESUME caused the program to resume execution at the "current
- statement," meaning the statement that caused the error. In a QuickBASIC 4.00b
- multiple-module program, however, the "current statement" is the last executed
- statement in the module containing the active error handler.
-
- The new error-handling feature has a similar effect on the ERL function.
- In QuickBASIC 4.00b, the program line that the ERL function identifies as the
- source of an error is the line that contains the last executed statement in the
- module where the active error handler is located.
-
- ---< New Screen Mode >---
-
- The new screen mode, mode 4, is supported on the following machines:
-
- Olivetti(R) Personal Computers, models M24, M28, M240, M280, M380
- AT&T(R) 6300 Personal Computer series
-
- Mode 4 is a 640x400 graphics mode that allows you to specify 1 of 16 colors
- (0-15) as the foreground color. Use the SCREEN statement to select the mode,
- and use the COLOR statement to select the foreground color. The example below
- shows how to specify this mode with a blue foreground color.
-
- SCREEN 4
- COLOR 1
-
- See the Basic Language Reference for more information on these statements.
-
- ---< New Statement: ON UEVENT >---
-
- Action:
- Defines an event trap for a user-defined event
-
- Syntax:
- ON UEVENT GOSUB {<linenumber>|<linelabel>}
-
- Remarks:
- In this syntax <linenumber> or <linelabel> specifies the number or label of
- the first line in the event-trapping subroutine.
-
- The ON UEVENT statement allows your program to branch to an event-trapping
- subroutine when a user-defined event occurs. ON UEVENT is unlike other event-
- trapping statements in that it allows your program, not an external agent, to
- trigger the event that you expect to trap.
-
- For example, assume that your system contains a data acquisition device that
- generates an interrupt when data arrives. Most of your application is written
- in QuickBASIC. The main module contains an event-trapping subroutine that
- responds to a user-defined event (in this case, the arrival of data from the
- acquisition device). The following three assembly-language procedures are
- also linked into the program:
-
- 1. An interrupt handler that responds to the interrupt generated by the
- acquisition device
-
- 2. A routine that installs the interrupt handler in the chain of interrupts
-
- 3. A routine that removes the interrupt handler from the chain of interrupts
-
- When the program begins, it calls the assembly-language routine that installs
- the interrupt handler. Then it executes an ON UEVENT statement to identify
- the QuickBASIC subroutine that will be executed when a user-defined event
- occurs. The final step in setting up the user-defined event trap is to
- execute a UEVENT ON statement. Once this is done, the BASIC program enters
- its main execution loop.
-
- When data arrives, the acquisition device generates an interrupt. The
- assembly-language interrupt handler, in turn, calls the routine SetUEvent.
- SetUEvent is a BASIC run-time-library routine that causes a user-defined
- event to occur in BASIC. This special routine can be called from any
- Microsoft language. References to SetUEvent are resolved when your program
- is linked with the run-time library.
-
- The user-defined event causes the program to branch to the QuickBASIC
- subroutine identified by the previous ON UEVENT statement. At this point,
- the event-trapping subroutine performs whatever processing is desired.
-
- Just before the application terminates, it calls the assembly-language
- routine that removes the interrupt handler from the chain of interrupts.
-
- ---< New Statements: UEVENT ON, OFF, STOP >---
-
- Action:
- Enable, disable, or suspend event trapping for a user-defined event
-
- Syntax:
- UEVENT ON
- UEVENT OFF
- UEVENT STOP
-
- Remarks:
- The effect of UEVENT parallels that of other event-trapping statements. For
- example, UEVENT ON enables a user-defined event trap that you previously set
- up with an ON UEVENT GOSUB statement.
-
- ---< New Statement: SLEEP >---
-
- Action:
- Suspends the execution of a BASIC program
-
- Syntax:
- SLEEP <seconds>
-
- Remarks:
- In this syntax the optional parameter <seconds> determines how many seconds
- to suspend the program.
-
- SLEEP suspends a QuickBASIC program until one of the following three events
- occurs:
-
- 1. The time period specified in the SLEEP statement has elapsed.
-
- 2. A key is pressed.
-
- 3. An enabled QuickBASIC event occurs.
-
- A QuickBASIC event is one that you can trap with an ON <event> statement such
- as ON COM or ON KEY. Note that a QuickBASIC event does not interrupt the
- suspension caused by SLEEP unless its trap is active when the event occurs.
- That is, the trap must have been set up with an ON <event> statement, turned
- on with an <event> ON statement, and not disabled with <event> OFF or <event>
- STOP. Note, too, that SLEEP responds only to actual keystrokes that occur
- after the SLEEP statement executes; SLEEP ignores characters that were stored
- in the keyboard buffer before the SLEEP statement executes.
-
- If you execute SLEEP with a time period of zero, or without specifying any
- time period, the program is suspended for an indefinite period. In this case
- only a keystroke or QuickBASIC event can interrupt the suspension.
-
- Example:
- The following program suspends its execution for twenty seconds. Because the
- example program has no ON EVENT statement, the only way to interrupt its
- suspension prior to the end of the twenty-second delay is by pressing a key.
-
- PRINT "Taking a twenty-second timeout..."
- SLEEP 20
- PRINT "Play ball!"
-
- ===< Part 2: Software Corrections >===
-
- The following is a list of the corrections or changes made to the software:
-
- The run-time library files have been updated. All references in the
- documentation to BRUN40.EXE, BCOM40.LIB, BRUN40.LIB, and BQLB40.LIB should
- now refer to BRUN41.EXE, BCOM41.LIB, BRUN41.LIB, and BQLB41.LIB respectively.
- If you are upgrading from version 4.0, you must re-install all executable and
- library files; the new run-time library files will not work with the previous
- version and vice versa. However, do not delete BRUN40.EXE or previously
- compiled programs will not be able to execute unless recompiled with version
- 4.00b.
-
- Chaining to a larger program from within the QuickBASIC environment works
- correctly, even when memory is tight.
-
- Odd-length fixed-length strings used in COMMON statements do not produce
- "string space corrupt" error messages.
-
- SADD(Function$) is allowed inside the function.
-
- The interpreter allows the use of fixed-length strings with the LINE INPUT
- statement.
-
- Variables containing periods are allowed in SELECT CASE statement.
-
- The graphics palette is not reset when changing active pages.
-
- Extended ASCII characters are now allowed in file names.
-
- The CIRCLE statement's arguments for starting and ending angles plot in the
- same manner as they did in previous versions of QuickBASIC.
-
- The default aspect ratio for some graphics modes has been corrected.
-
- The QLBDUMP program now works correctly with files of any size.
-
- The same key can be trapped more than once inside QuickBASIC.
-
- Frame-variable offset is now correct in INTRPT.ASM (-1Eh instead of -0Eh).
-
- The DOS screen is correctly reset after using PALETTE statements in QuickBASIC.
-
- FOR/NEXT loops correctly decrement the loop counter with long integers.
-
- Errors occurring after an ON ERROR GOTO 0 statement now result in expected
- run-time errors.
-
- A "string space corrupt" error message is no longer given when using a
- Quick library containing a COMMON statement when the main program has no
- COMMON statement.
-
- The PLAY statement correctly handles strings longer than 256 characters.
-
- Run-time programs chain in DOS 2.1
-
- The BLOAD and BSAVE statements do not give error 67 with DOS 2.1
-
- An executable file can be created within the QuickBASIC environment with
- DOS 2.1.
-
- QuickBASIC works with Mouse Systems' PC Mouse.
-
- Graphics programs work on AT&T PC 6300 with current ROM chips.
-
- The /MBF option is passed when creating an executable file in QuickBASIC.
-
- Undimensioned arrays can be compiled from within the environment.
-
- The error message "Device timeout" is no longer given when using the COM
- port and using the Make EXE File or DOS Shell commands in QuickBASIC.
-
- COM support is improved in several ways. When using an OPEN COM statement, the
- DTR line remains active, whereas the RTS line is reset briefly before being
- made active. Both the RTS and DTR lines are reset when a COM file is closed, or
- when an error or CTRL-BREAK causes the OPEN COM statement to abort. A SHELL or
- CHAIN operation leaves DTR active and resets RTS during the operation. RTS is
- restored to its original status once the SHELL or CHAIN operation is complete.
- Pressing CTRL-BREAK while executing an OPEN COM statement now resets the COM
- port hardware correctly.
-
- The RUN statement does not generate a line feed in compiled programs.
-
- The screen-swapping problem in Hercules graphics mode (SCREEN 3) that existed
- on some machines has been corrected.
-
- The Hercules(R) driver, QBHERC.COM, now has a /H (/HALF) option that should be
- used if you have both a color video card and a Hercules monochrome card. The
- /H option causes the driver to use only one graphics page instead of two. This
- prevents the two video cards from trying to use the same memory address space.
-
- MOUSE.COM, LINK.EXE, and LIB.EXE have been updated.
-
- ASCII listings from BC.EXE print extended ASCII characters.
-
- Event trapping works correctly in Quick-library routines called by main
- modules that do not use events.
-
- The CLEAR statement no longer affects function-key values in executable files.
-
- Procedure calls can compile if the calls have scalar variables with periods
- and records.
-
- Using the CONST statement with string expressions gives the correct length
- when compiled.
-
- Scalars can contain periods in COMMON statements.
-
- Creating an executable file from within QuickBASIC works with
- DPATH (a public domain utility).
-
- Setting breakpoints on CASE or CASE ELSE statements may cause unpredictable
- results.
-
- Note: The GET and PUT statements used for file I/O work differently than in
- previous versions when the following two conditions are true:
-
- 1) A disk file or COM device is opened for random access.
-
- 2) The GET and PUT statement's optional third parameter (variable) is
- a variable-length string.
-
- The PUT statement encodes the length of the string and stores it as
- the first two bytes of the string. The GET statement uses this encoded
- value to determine how many characters to read.
-
- ===< Part 3: MS-DOS(R) 3.20 Patch >===
-
- This information is relevant only if your system has ALL of the following
- characteristics:
-
- 1. Uses MS-DOS Version 3.20
-
- 2. Boots from a hard disk drive
-
- 3. Has a math coprocessor (for instance, an 8087 chip)
-
- 4. Runs programs that use floating-point math
-
- For systems that satisfy all of the preceding conditions, you may be able to
- eliminate floating-point math problems by installing a small patch in DOS. If
- you are not sure whether you need the patch, perform the following steps:
-
- 1. Copy the program PATCH87.EXE (included on disk 3 of this release) to
- the root directory of your hard drive.
-
- 2. Reboot your system from the hard disk, and DO NOT PERFORM ANY FLOPPY-
- DISK OPERATIONS after rebooting. It is very important that you avoid
- floppy-disk I/O after rebooting, since this will affect the reliability
- of the diagnostic test that you are about to perform.
-
- 3. Use the CD command to move to the root directory of your
- hard-disk drive, if necessary.
-
- 4. Run the PATCH87.EXE program by entering this command at the DOS prompt:
-
- PATCH87
-
- The program performs a diagnostic test on your system to determine
- whether it needs the DOS patch, and if the patch is needed, whether the
- patch can be installed successfully. Follow the procedure described in
- the next section if the program tells you that you need to install the
- DOS patch, and that it can be done.
-
- NOTE: The floating-point problem has been eliminated in versions of
- MS-DOS higher than 3.20. This includes MS-DOS versions 3.21 and 3.30.
-
- If you performed the preceding test and determined that you should install the
- DOS patch on your system, perform the following steps:
-
- 1. Format a blank floppy disk. (Do NOT use the /s formatting option to
- transfer system files to the disk.)
-
- 2. Use the SYS command to copy IO.SYS and MSDOS.SYS from the root
- directory of your hard disk to the new floppy disk. For instance, if
- you boot from drive C:, you would enter the following commands:
-
- C:
- SYS A:
-
- 3. Use the COPY command to copy COMMAND.COM and SYS.COM to the same floppy
- disk.
-
- 4. Use the COPY command to copy the program PATCH87.EXE (included in this
- release) to the same floppy disk.
-
- 5. Change the current drive and directory to the floppy disk, by entering
- the following command:
-
- A:
-
- 6. Patch the version of MS-DOS on the floppy disk by entering the
- following command:
-
- PATCH87 /F
-
- WARNING: If you experience any disk errors during steps 2 through 6, do
- NOT proceed with step 7. Reboot from your hard disk and repeat the entire
- process.
-
- 7. If you have not experienced any errors, use the SYS command to transfer
- the files IO.SYS and MSDOS.SYS from the floppy disk back to your hard
- disk. For instance, if the boot directory of your system is the root
- directory of drive C:, you would enter the following commands at the
- DOS prompt:
-
- A:
- SYS C:
-
- The DOS patch is now installed on your hard disk.
-
- 8. Reboot the system.
-