[comp.sys.ibm.pc] QuickBASIC 4.00b update list

brown@nicmad.UUCP (Mr. Video) (07/19/88)

Yesterday I received my updated copy of QB4.0, now called 4.00b.  Here is
Microsoft's UPDATE.DOC file.  If you have QB4.0, call Microsoft to get
your update shipment.  It will not be sent automatically.



				 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.
-- 
	       harvard-\	att!terminus--\
Mr. Video         ucbvax!uwvax.................!nicmad!brown
	       rutgers-/        att-/ decvax--/