Microsoft Programmer's Library 1.3/Microsoft_Programmers_Library.7z/MPL/basic/basknow.txt

Text File | 2013-11-08 | 3.9 MB | 110,021 lines

 Microsoft BASIC Professional Development System
 =============================================================================


 1. How Microsoft BASIC ON ERROR Handles DOS General Drive Failure

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q19842

 Error trapping in Microsoft BASIC programs (invoked with the ON ERROR
 statement) will trap a DOS general drive failure.

 A DOS general drive failure occurs if an error occurs while trying to
 read the specified drive (for example, the drive door is not closed or
 the disk is improperly formatted). The general drive failure message
 is usually of the following form:

    General failure reading drive A:
    (Abort, Retry, Ignore)?

 BASIC error trapping invoked with the BASIC ON ERROR statement traps
 the DOS general drive failure and returns a BASIC error number 57,
 "Device I/O error."


 2. LIB Errors During SETUP.EXE If Directory Has "-" in Its Name

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  7-FEB-1990    ArticleIdent: Q37304

 If you specify a library directory name that contains a minus sign
 (such as LIB-BAS) during the SETUP.EXE program for Microsoft BASIC
 Compiler Version 6.00 or 6.00b, or Microsoft BASIC Professional
 Development System (PDS) Version 7.00, the LIB.EXE manager may have
 problems creating the BASIC stand-alone and run-time libraries.

 This problem occurs because when the Library Manager (LIB) is run from
 the SETUP program, it uses the pathname to your library directory in
 its "Operations:+" step and is confused by an operator (such as "-")
 in the directory name.

 For example, if you specified the directory name C:\LIB-BAS for your
 BASIC libraries, a library build would look like the following:

    Microsoft (R) Library Manager  Version 3.11
    Copyright (C) Microsoft Corp 1983-1988.  All rights reserved.

    Library name:BRUN60ER.LIB
    Library does not exist.  Create? (y/n) Y
    Operations:+ C:\LIB-BAS\BRUN60R.LIB
    LIB : error V2155: BAS\BRUN60ER.LIB : module not in library; ignored
    &
    Operations:+ .\B4 ;
    LIB : error V2157: C:\LIB.obj : cannot access file

 The LIB thinks the "-" character in the LIB-BAS directory is an extra
 operation trying to subtract BAS\BRUN60ER.LIB. It then tries to add a
 file called C:\LIB.obj, which does not exist.

 Then, when trying to compile a BASIC program and link it with the
 BRUN60ER.LIB library, the compile will seem to work correctly, but the
 link can return errors, such as the following:

    LINK : warning L4021: no stack segment
    LINK : error L2029: Unresolved externals:
      < here would be a list of the unresolved library references >

 If you avoid the following operators in the directory name for BASIC
 libraries, the LIB shouldn't have any problems initially creating the
 libraries:

    +  -  -+  *  -*


 3. How DEFINT, DEFSNG, DEFDBL Affect Type of DEF FN Function

 Product Version(s): 5.35 5.36 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS                         | OS/2
 Flags: ENDUSER | B_QuickBas B_BasicInt
 Last Modified: 17-JAN-1991    ArticleIdent: Q21311

 This article discusses the default type declaration of DEF FN
 user-defined functions in Microsoft BASIC.

 The DEFINT, DEFLNG, DEFDBL, and DEFSNG statements affect the first
 letter of the variable part of a DEF FN function name, and not the FN
 part of the function name. This information applies to all Microsoft
 BASIC compilers and interpreters for MS-DOS, MS OS/2, Macintosh, and
 CP/M-80.

 Microsoft BASIC Compiler versions 6.00 and later, and QuickBASIC
 versions 4.00 and later for the IBM PC, introduced the DEFLNG
 statement for long integer declaration, which also behaves this way.

 Example
 -------

 The following program prints 1.2 (a noninteger):

    10 DEFINT F   ' DEFINT F doesn't affect the DEF FN below.
    20 DEF FNAB=1.2
    30 PRINT FNAB

 The following program prints 1 (truncated to an integer):

    10 DEFINT A   ' DEFINT A does affect the DEF FN below.
    20 DEF FNAB=1.2
    30 PRINT FNAB


 4. BRUNxx.EXE Run-Time Module Must Reload from Disk After SHELL

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# G881101-5556 B_QuickBas
 Last Modified:  1-FEB-1990    ArticleIdent: Q37767

 When the SHELL statement is executed, some portions of the BASIC
 run-time module (BRUNxx.EXE) are unloaded. This is done to free up as
 much memory as possible for COMMAND.COM. When the SHELL is complete,
 the run-time module must be reloaded.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2, Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2, and to Microsoft
 QuickBASIC Compiler Versions 4.00, 4.00b, 4.50 and earlier for MS-DOS.

 If the run-time module is located on a floppy disk removed during the
 SHELL statement, it must be re-inserted before the BASIC program can
 continue. If the program cannot find the run-time module, it will
 prompt you for its location.

 To avoid the need to reload the run-time module after SHELL, you can
 compile with the /O (stand alone) option, which includes the run-time
 routines into the BASIC .EXE program at LINK time.


 5. "Device I/O" Error Using LPRINT or "LPT1:" After a CHAIN

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00
 Last Modified: 17-JAN-1990    ArticleIdent: Q32214

 The following problem occurs in OS/2 protected mode programs compiled
 with Microsoft BASIC Compiler Versions 6.00 and 6.00b or Microsoft
 BASIC Professional Development System (PDS) Version 7.00 for MS OS/2.
 Using LPRINT, or sending output to the "LPT1:" device name, then
 chaining to a second routine that uses the printer produces the
 following error:

    Device I/O error in line 0 of module PROG2

 This problem can be worked around in OS/2 protected mode by sending
 output to the DOS "LPT1" (without a colon) device name instead of
 using LPRINT or "LPT1:". This problem does not occur in OS/2 real
 mode.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b and in Microsoft BASIC PDS Version
 7.00. We are researching this problem and will post new information
 here as it becomes available.

 The following chained programs demonstrate the "Device I/O" error.
 These programs must be compiled with the BRUN library option for
 protected mode.

    ' prog1
    OPEN "O",15,"LPT1:"
    PRINT #15,"program 1"
    CHAIN "prog2"

    ' prog2
    PRINT #15,"program 2"
    CLOSE #15

 The problem occurs only when sending output to the BASIC "LPT1:"
 printer device. If the DOS device, "LPT1" (without a colon) is used,
 the problem does not occur. For example, the following programs CHAIN
 correctly:

    ' prog1
    OPEN "O",15,"LPT1"
    PRINT #15,"program 1"
    CHAIN "prog2"

    ' prog2
    PRINT #15,"program 2"
    CLOSE #15
    SYSTEM


 6. MS-DOS BASIC Compiler Does Not Provide ISAM File Support

 Product Version(s): 5.35 5.36 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q21331

 Microsoft BASIC Compiler Versions 5.35, 5.36, 6.00, and 6.00b for
 MS-DOS does not support Index Sequential Files (ISAM). You must write
 your own routine or use a third-party vendor's routine that is
 compatible with the BASIC compiler.

 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS does support ISAM files. BASIC PDS 7.00 currently supports
 single-user ISAM, however.


 7. A Single-Precision Number as a File Number Causes "Overflow"

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q37339

 A program compiled with Microsoft BASIC Compiler Version 6.00 or
 6.00b, or QuickBASIC Version 4.00 or 4.00b, generates an "Overflow"
 error message if you are using a single-precision variable as the
 number of a file to be opened.

 This behavior does not occur in Microsoft QuickBASIC Version 4.50 for
 MS-DOS or Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS and MS OS/2.

 The following sample code demonstrates the problem. If the file number
 "F" is redefined as an integer, the program works correctly. The
 program also can be forced to work correctly using any of the
 following alternatives:

 1. By compiling with the /o, /d, /v, or /x compiler-option switches

 2. By putting line numbers on affected lines

 3. By deleting a few lines of code in the subroutine

 Earlier versions of Microsoft QuickBASIC do not have this problem.

 The following is an example:

    DIM SHARED f9$(22, 9), id$(9), size%(9), fdr$(9)
    CLS
    f = 1
    fi$ = "FILENAME.DAT"
    CALL OPEN.ISAM(f, fi$)
    END

    SUB OPEN.ISAM (f, fid$) STATIC
         OPEN "r", f, fid$, 256
            FIELD #f, 256 AS f9$
         fdr$(f) = SPACE$(256)
            size%(f) = LOF(f) / 256
            id$(f) = fid$
    END SUB


 8. "Feature Unavailable" Using FRE(-3) in .EXE Compiled in 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900125-132
 Last Modified: 26-FEB-1990    ArticleIdent: Q58123

 The FRE(-3) function, which returns available expanded memory in the
 QuickBASIC Extended (QBX.EXE) environment, normally gives a "Feature
 Unavailable" (run-time error 73) in .EXE files created with BC.EXE. An
 exception is if an executable .EXE file is linked with overlays that
 are each no larger than 64K, and if a LIM 4.0 EMS expanded memory
 driver (defined below) is installed, then the FRE(-3) function returns
 a value for the amount of free expanded memory. This information
 applies to Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS.

 The FRE(-3) function returns the amount of free LIM 4.0 EMS expanded
 memory available for arrays, SUBs, and functions in the QBX.EXE
 environment.

 Note that the only way that compiled BASIC .EXE applications can take
 advantage of expanded memory is with linked overlays, but then only if
 each overlay is smaller than 64K. (If expanded memory is not
 accessible, overlays just swap to disk.) The FRE(-3) function returns
 a value for an .EXE program only when a LIM 4.0 EMS driver is
 installed and the .EXE program is able to successfully store its
 overlays in expanded memory.

 To check the amount of available expanded memory from an EXE program,
 see Pages 204-206 in Ray Duncan's "Advanced MS-DOS Programming, 2nd
 Edition" (Microsoft Press, 1988). The method described there uses
 assembly language and interrupts.

 Note: LIM 4.0 EMS is defined as follows:

    LIM  = Lotus, Intel, Microsoft
    4.0  = Version number 4.0 (of the standard LIM EMS)
    EMS  = Expanded Memory Specification, a standard for addressing
           expanded memory

 For more information about linker overlays in BASIC PDS 7.00, search
 for a separate article with the following keywords:

    BASIC and 7.00 and linker and overlays and modules

 Also see Pages 612-614 of the "Microsoft BASIC 7.0: Programmer's
 Guide," in the section "Linking with Overlays".


 9. LINK Overlays Not Supported in BASIC 6.00/6.00b, or QuickBASIC

 Product Version(s): 6.00 6.00b
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr B_QuickBas
 Last Modified: 30-MAY-1990    ArticleIdent: Q31153

 Microsoft QuickBASIC versions 1.00, 1.02, 2.00, 2.01, 3.00, 4.00,
 4.00b, and 4.50 for MS-DOS and Microsoft BASIC Compiler versions 6.00
 and 6.00b for MS-DOS do NOT support code overlays. These versions of
 BASIC compiler and QuickBASIC are not designed to output the special
 object format necessary to support overlays under MS-DOS.

 The description of LINK.EXE provided in the "Microsoft CodeView and
 Utilities: Software Development Tools for MS-DOS" manual, supplied
 with Microsoft BASIC Compiler versions 6.00 and 6.00b, is a general
 description for the linker. However, this description is misleading.
 Although Pages 285-286 discuss linker overlays, overlays are not
 supported by these versions of BASIC.

 Microsoft has introduced support for linker overlays in Microsoft
 BASIC Professional Development System (PDS) version 7.00 under MS-DOS.
 For more information, search for a separate article with the following
 words:

    how and use and LINK and overlays and BASIC and PDS and 7.00

 Other Microsoft languages, such as Microsoft C and Microsoft FORTRAN,
 also support linker overlays.

 The error message "L2048 cannot find overlay manager" will be
 generated if you try to link with overlays using BASIC compiler
 version 6.00.

 Overlays are useful in a memory-restricted environment because overlay
 capability allows programs to load portions of code from disk into
 memory when needed, and overlays in memory not currently being used
 are automatically swapped out when loading the needed overlays.

 The CHAIN, RUN, and SHELL statements in BASIC offer capabilities that
 are similar to code overlays, but more limited.


 10. "Formal Parameter Specification Illegal" from BC But Not QB

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q27856

 For the following statement, the BC.EXE compiler correctly generates
 the compile-time error message "Formal parameter specification
 illegal," while the QuickBASIC QB.EXE editor does not produce any
 error messages:

    DECLARE SUB prompt (prompt$)

 This error message results from the requirement in QuickBASIC Versions
 4.00, 4.00b, and 4.50, in Microsoft BASIC Compiler Versions 6.00 and
 6.00b, and in Microsoft BASIC Professional Development System (PDS)
 Version 7.00 that procedure and variable names must be different.
 Therefore, programs may not contain functions or subprograms whose
 names are the same as those of variables.

 Note that the QB.EXE environment of QuickBASIC Versions 4.00, 4.00b,
 and 4.50 and the QBX.EXE environment of BASIC PDS 7.00 correctly gives
 you a "Duplicate Definition" error on the following CALL or SUB
 statement:

    CALL PROMPT(PROMPT$)

 Therefore, the lack of warning of "Duplicate Definition" for the
 DECLARE statement is a minor issue.

 An error message occurs even in the case in which the variable and
 procedure names differ by a data-typing character (for example, %, &,
 !, #, $). The error message displays because the compiler makes no
 distinction between the variable "prompt$" and the subprogram name
 "prompt".

 The requirement that procedure and variable names be different was
 introduced in QuickBASIC Version 4.00 and BASIC compiler Version 6.00.
 This was not a requirement in earlier versions.


 11. "Error During Run-Time Initialization": Mixing /FPa and /FPi

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  4-SEP-1990    ArticleIdent: Q31505

 When you link separate modules together to make an .EXE program, all
 the modules must have been compiled with the same math package. The
 two math packages available in Microsoft BASIC Compiler versions 6.00
 and 6.00b and in Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 are as follows:

 1. BC /FPi (IEEE coprocessor-emulation math, the default)
 2. BC /FPa (alternate math)

 If you LINK modules or libraries together that were compiled with both
 the BC /FPa and /FPi options, the .EXE program gives the following
 error message at run time and usually hangs:

    Error during run-time initialization

 Combining math packages can cause unpredictable results in the .EXE
 program at run time. After the error message appears, a warm boot
 (CTRL+ALT+DEL) does not work. To reboot, you must turn the computer
 off, then back on.

 To avoid this problem, make sure when you LINK routines that they were
 compiled with the same math package. Also, remember that the QB.EXE
 environment of the BASIC compiler and the QBX.EXE environment of BASIC
 PDS 7.00 and 7.10 do not support the alternate math package. In other
 words, object modules compiled with the /FPa switch cannot be placed
 into a Quick library (.QLB file) for use in QB.EXE or QBX.EXE.


 12. PCOPY & Multiple Pages Not Supported in MS OS/2 Protected Mode

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# G880910-3123 docerr
 Last Modified:  2-FEB-1990    ArticleIdent: Q35519

 Multiple video pages are not supported in the protected mode of MS
 OS/2. As stated on Page 40 of the "Microsoft BASIC Compiler 6.0:
 User's Guide" and on Page 522 of the "Microsoft BASIC 7.0:
 Programmer's Guide," the SCREEN function ignores the active and visual
 page parameters.

 Since multiple pages are not supported, the PCOPY function is not
 allowed in MS OS/2 protected mode. This fact needs to be added to the
 section on BASIC language changes for MS OS/2 protected mode.

 Through BASIC, there is no way to manipulate the video buffer directly
 in MS OS/2 protected mode. However, it can be done through the use of
 OS/2 API calls. The following API calls can be used to modify the
 video buffer:

    VioGetBuf
    VioShowBuf
    VioGetPhysBuf
    VioScrLock
    VioScrUnLock

 The VioGetBuf function retrieves the address and length of the logical
 video buffer (LVB). The address of the buffer is returned in a long.
 The high 2 bytes are the segment and the low 2 bytes are the offset,
 as in the following example:

    x = VioGetBuf(pointer, length, 0)
    segment& = pointer / &H10000
    offset& = pointer MOD &H10000

 To modify the buffer, change the segment to the segment value returned
 and use PEEK and POKE to read and modify the information. Once the
 information is changed, VioShowBuf is used to display the changes.

 The VioGetPhysBuf function retrieves the selector of the physical
 video buffer. The physical video buffer contains the current screen
 image. To modify the screen, change the segment to the selector
 returned and use PEEK and POKE to read and modify the screen. This
 method is faster than using VioGetBuf/VioShowBuf because you are
 directly modifying the screen.

 For more information about these VIO API calls, please refer to your
 OS/2 documentation. Listed below are two sample programs that use the
 methods discussed above.

 Code Examples
 -------------

 'The following program uses VioGetPhysBuf:
 DEFINT A-Z
 TYPE PhysBufData
      bufstart AS LONG
      buflength AS LONG
      selector1 AS INTEGER
      selector2 AS INTEGER
 END TYPE

 DECLARE FUNCTION VioGetBuf (_
    SEG p1 AS LONG,_
    SEG p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioShowBuf (_
    BYVAL p1 AS INTEGER,_
    BYVAL p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioGetPhysBuf (_
    SEG p1 AS PhysBufData,_
    BYVAL p2 AS INTEGER)

 DECLARE FUNCTION VioScrLock (_
    BYVAL p1 AS INTEGER,_
    SEG p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioScrUnLock (_
    BYVAL p1 AS INTEGER)

 CLS
 FOR i = 1 TO 10
     PRINT "This is a test"
 NEXT i
 DIM stuff AS PhysBufData
 x = VioScrLock(1, status, 0)
 PRINT
 PRINT "Lock Status: "; status
 stuff.bufstart = &HB8000
 stuff.buflength = 43 * 80 * 2
 x = VioGetPhysBuf(stuff, 0)
 IF (x) THEN
     PRINT "Error: "; x; " occurred."
     END
 ELSE
     PRINT
     PRINT "Start: "; HEX$(stuff.bufstart)
     PRINT "Length: "; stuff.buflength
     PRINT "Selector1: "; stuff.selector1
     PRINT "Selector2: "; stuff.selector2
     PRINT
     PRINT
     PRINT "Enter a key to begin changing..."
     WHILE INKEY$ = "": WEND
     offset = 0
     DEF SEG = stuff.selector1
     FOR i = offset TO offset& + stuff.buflength - 1 STEP 2
        POKE i, 65     'Character
        POKE i + 1, &H17'Attribute
     NEXT i
     DEF SEG
     x = VioScrUnLock(0)
 END IF
 PRINT "Enter a key to quit..."
 WHILE INKEY$ = "": WEND
 END

 'The following program uses VioGetBuf/VioShowBuf:
 DEFINT A-Z
 TYPE PhysBufData
      bufstart AS LONG
      buflength AS LONG
      selector1 AS INTEGER
      selector2 AS INTEGER
 END TYPE

 DECLARE FUNCTION VioGetBuf (_
    SEG p1 AS LONG,_
    SEG p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioShowBuf (_
    BYVAL p1 AS INTEGER,_
    BYVAL p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioGetPhysBuf (_
    SEG p1 AS PhysBufData,_
    BYVAL p2 AS INTEGER)

 DECLARE FUNCTION VioScrLock (_
    BYVAL p1 AS INTEGER,_
    SEG p2 AS INTEGER,_
    BYVAL p3 AS INTEGER)

 DECLARE FUNCTION VioScrUnLock (_
    BYVAL p1 AS INTEGER)

 CLS
 FOR i = 1 TO 10
     PRINT "This is a test"
 NEXT i
 DIM pointer AS LONG
 DIM length AS INTEGER
 DIM handle AS INTEGER
 x = VioGetBuf(pointer, length, 0)
 segment& = pointer / &H10000
 offset& = pointer MOD &H10000
 IF (x) THEN
     PRINT "Error: "; x; " occurred."
     END
 ELSE
     PRINT "POINTER = "; HEX$(pointer)
     PRINT "LENGTH = "; length
     PRINT
     PRINT "SEGMENT = "; HEX$(segment&)
     PRINT "OFFSET = "; HEX$(offset&)
     PRINT
     PRINT "Enter a key to begin changing the buffer..."
     WHILE INKEY$ = "": WEND
     CLS
     DEF SEG = segment&
     FOR i = offset TO offset& + length - 1 STEP 2
       POKE i, 65     'Character
       POKE i + 1, &H17'Attribute
     NEXT i
     DEF SEG
     PRINT "Enter a key to see the changes..."
     WHILE INKEY$ = "": WEND
     x = VioShowBuf(0, length, 0)
 END IF
 PRINT "Enter a key to quit..."
 WHILE INKEY$ = "": WEND
 END


 13. ERDEV & ERDEV$ "Advanced Feature" Error in OS/2 Protected Mode

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q35653

 The statements ERDEV and ERDEV$ give the run-time error message
 "Advanced Feature Unavailable" when compiled and run in OS/2 protected
 mode because these functions are set by DOS interrupt 24H, which is
 not available in OS/2 protected mode.

 ERDEV and ERDEV$ are not supported in OS/2 protected mode. This
 restriction should be added to Page 40 of the "Microsoft BASIC
 Compiler 6.0: User's Guide" for Versions 6.00 and 6.00b and to Page
 520 of the "Microsoft BASIC 7.0: Programmer's Guide" for Microsoft
 BASIC Professional Development System (PDS) Versions 7.00 and 7.10.

 Code Example
 ------------

 I% = ERDEV
 A$ = ERDEV$


 14. /FPa; "Symbol Defined More Than Once" Linking BASIC and Pascal

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# G880915-3308 buglist6.00 buglist6.00b buglist7.00
 Last Modified:  2-MAR-1990    ArticleIdent: Q35902

 If you compile Microsoft BASIC and Microsoft Pascal modules with the
 alternate-math library (/FPa) option, a "Symbol Defined More than
 Once" error occurs when you LINK the BASIC and Pascal modules. This
 problem occurs in Microsoft BASIC Compiler Versions 6.00 and 6.00b for
 MS-DOS and MS OS/2, and in Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b and in Microsoft BASIC PDS Version
 7.00. We are researching this problem and will post new information
 here as it becomes available.

 The programs correctly link together if you compile the BASIC program
 with the stand-alone (BC /O) option.

 To duplicate the problem, follow the steps below:

 1. Compile the BASIC program -- BC prog /Fpa;

 2. Compile the Pascal routine -- PL /FPa /C  progr.pas

 3. Link the BASIC and Pascal modules -- LINK prog + progr /noe;

 4. The linker displays the following error:

       LIBPASA.LIB(fcall.ASM) : error L2025: __fpmath : symbol defined
       more than once
       pos: 1339E Record type: 7F04



 15. How to Call OS/2 Function DosAllocHugeSeg and DosGetHugeShift

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35904

 Below is a sample program that makes a call to the MS OS/2 functions
 DosAlocHugeSeg, DosGetHugeShift, DosReallocHuge, and DosMemAvail. This
 program can be compiled in Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for MS OS/2.

 The following is code example:

 DECLARE FUNCTION DosAllocHuge%(_
                  BYVAL P1 AS INTEGER,_
                  BYVAL P2 AS INTEGER,_
                  SEG P3 AS INTEGER,_
                  BYVAL P4 AS INTEGER,_
                  BYVAL P5 AS INTEGER)

 DECLARE FUNCTION DosGetHugeShift%(SEG P1 AS INTEGER)

 DECLARE FUNCTION DosReallocHuge%(_
                  BYVAL P1 AS INTEGER,_
                  BYVAL P2 AS INTEGER,_
                  BYVAL P3 AS INTEGER)

 DECLARE FUNCTION DosMemAvail%(SEG P1 AS LONG)

 DEFINT A-Z
 DIM mem AS LONG

 CLS
 MEM=0
 x=DosMemAvail%(mem)

 IF (x) THEN
    PRINT "An error occurred.  The number is : ";x
 ELSE
    PRINT "The amount of available memory is : ";mem
 END IF

 INPUT "Enter the number of Segments : ";NUMSEG

 SIZE=0
 SELECTOR=0
 SHAREID=0
 input "Enter the Number of MAXSEG for REALLOCATION: ";MAXNUMSEG
 print
 x=DosAllocHuge%(numseg,size,selector,shareid,maxnumseg)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "The selector is : ";selector
 END IF
 SHIFTCOUNT=0

 x=DosGetHugeShift%(shiftcount)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "The Huge Shift Count is : ";shiftcount
 END IF

 print
 INPUT "Enter the number of segments in reallocation : ";NUMSEG
 SIZE=0
 print
 x=DosReAllocHuge%(numseg,size,selector)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "Memory was been reallocated"
 END IF

 end


 16. Example of BASIC Calling MS OS/2 Function DosStartSession

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35905

 Below is a sample program that makes a call to the MS OS/2 function
 DosStartSession. This program can be compiled in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00.

 The full pathname must be specified for the program to be executed. If
 this is not done when you are using OS/2 Version 1.00, an error 203 is
 generated. OS/2 Version 1.10 and 1.20 produce an error 2.

 The following is a code example:

 'This information can be found in BSEDOSPC.BI
 TYPE ADDRESS
   Offset    as INTEGER
   Segment   as INTEGER
 END TYPE

 TYPE STARTDATA
   cb    as INTEGER
   Related   as INTEGER
   FgBg      as INTEGER
   TraceOpt  as INTEGER
   PgmTitle  as ADDRESS
   PgmName   as ADDRESS
   PgmInputs as ADDRESS
   TermQ     as ADDRESS
 END TYPE

 DECLARE FUNCTION DosStartSession%(_
                  SEG P1 AS StartData,_
                  SEG P2 AS INTEGER,_
                  SEG P3 AS INTEGER)

 DIM info AS STARTDATA
 DIM apinputs AS ADDRESS, apname AS ADDRESS, aptitle AS ADDRESS
 DIM title AS STRING*32
 DIM flname AS STRING*32
 DIM pinput AS STRING*32

 title="BASIC TEST"+chr$(0)
 INPUT "Enter filename with extension", flname
 flname=flname+chr$(0)
 pinput=chr$(0)

 apname.segment=varseg(flname)
 apname.offset=varptr(flname)

 apinputs.segment=varseg(pinputs)
 apinputs.offset=varptr(pinputs)

 aptitle.segment=varseg(title)
 aptitle.offset=varptr(title)

 info.cb=24
 info.Related=0
 info.FgBg=1
 info.TraceOpt=0
 info.PgmTitle=aptitle
 info.PgmName=apname
 info.PgmInputs=apinputs

 y=DosStartSession%(info,a%,b%)

 if (y) then
    print "An error occurred.  The number is : ";y
 else
    Print "Successful"
    while inkey$="" :wend
 end if
 END


 17. LINE Statement with BF Option Outside Window Will Hang

 Product Version(s): 6.00   | 6.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist6.00 fixlist6.00b SR# S881221-109 viewport
 Last Modified: 17-JAN-1990    ArticleIdent: Q40546

 If a LINE statement with the BF (box filled) option is executed
 outside the boundaries of the physical view port set up by the VIEW
 statement, the computer will hang. The program runs properly inside
 the QuickBASIC QB.EXE environment, but fails when compiled with BC.EXE
 from Microsoft BASIC Compiler Version 6.00.

 Microsoft has confirmed this to be a problem with BC.EXE in Microsoft
 BASIC Compiler Version 6.00. This problem was corrected in Microsoft
 BASIC Compiler Version 6.00b.

 This problem does not occur in Microsoft QuickBASIC Versions 4.00,
 4.00b, and 4.50, or in Microsoft BASIC Professional Development System
 (PDS) Version 7.00.

 The following program sets up a physical view port with the VIEW
 statement and then draws a line using the BF option, starting inside
 the box and moving outside the window's boundaries. If the program is
 compiled with Version 6.00 of Microsoft BASIC Compiler, the program
 will hang upon attempting to draw the first box that lies outside the
 window view port.

 The following is a code example:

 SCREEN 2
 xmin = 0: ymin = 0
 xmax = 1000: ymax = 1000
 dx = (xmax - xmin) / 10
 dy = (ymax - ymin) / 10
 VIEW (200, 50)-(400, 150)
 WINDOW SCREEN (xmin, ymin)-(xmax, ymax)
 LINE (xmin, ymin)-(xmax, ymax), 1, B
 x0 = xmin
 loop1:  x0 = x0 + dx
         LOCATE 5, 35: PRINT USING "x0=####"; x0
         LINE (x0, ymin + dy)-(x0 + 5, ymax - dy), 1, BF
 stall:  x$ = INKEY$: IF x$ = "" THEN GOTO stall
         IF x$ = CHR$(27) THEN END
         GOTO loop1


 18. BUILDRTM Puts C Routines in BC 6.00 Extended Run-Time Library

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q37092

 You can include Microsoft C routines in a Microsoft BASIC Compiler
 Version 6.00 or 6.00b or a Microsoft BASIC Professional Development
 System (PDS) Version 7.00 extended run-time library by using the
 BUILDRTM utility, provided that the C routine does not have C graphics
 support (such as GRAPH.H). The following is an example of this for a
 void function called "test" located in a source file named PROG1.C:

 1. Compile the C program with the medium or large model as follows:

       CL prog1 /Al

 2. Create an export list and include the new routine(s) to be added to
    the BASIC compiler extended run-time library, as follows (call this
    file "EXP.LST"):

       #Here is the export list example.
       #OBJECTS
       prog1
       #EXPORTS
       _test
       #LIBRARIES
       llibcer.lib

 3. Invoke BUILDRTM using the EXP.LST to create the new run-time
    library with the following:

       BUILDRTM /LR /FPI NEWRUN EXP.LST

 The above steps are covered more completely on Pages 13-19 of the
 "Microsoft BASIC Compiler 6.0: User's Guide" or Pages 661-668 of the
 "Microsoft BASIC 7.0: Programmer's Guide."

 The above steps produce a new run-time library called "NEWRUN.EXE" and
 a matching "NEWRUN.LIB" file. Now your Microsoft BASIC programs can be
 linked with NEWRUN to allow a program to call the C void function
 "_test" at any time. For example, if you want your new BASIC program,
 named PROG2.BAS, to call "_test," compile normally as follows:

    BC PROG2.BAS;

 This produces the PROG2.OBJ file. Then link with your new extended
 run-time library using IMPORT.OBJ as the first object file. This helps
 LINK understand that there are more support routines than the standard
 run-time library. The following is an example:

    LINK IMPORT.OBJ+PROG2.OBJ,PROG2.EXE,,NEWRUN.LIB/NOD;

 This produces the .EXE file PROG2.EXE, which requires the NEWRUN.EXE
 extended run-time library to run.


 19. Asynchronous SHELL Leaves Cursor Turned Off in New Process

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28157

 The following program starts CMD.EXE as an asynchronous process.
 However, CMD.EXE starts without a cursor visible.

    x=SHELL("CMD.EXE")

 This is because there can be only one cursor on the screen at a time.
 When you do an asynchronous shell, the shelled program is subordinate
 to the main program that controls the screen/keyboard. Thus the cursor
 displayed is that of the main program. The cursor is turned off
 immediately after the shell (in the main program), so it disappears
 from the screen. If the cursor is explicitly turned on in the main
 program, there will be a cursor in the (asynchronously) shelled
 program.


 20. Bound EXE Must Run on DOS 2.10 Default Drive

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-FEB-1990    ArticleIdent: Q27904

 The following is a change/addition to Page 3 of the "Microsoft BASIC
 Compiler 6.0: User's Guide" for Versions 6.00 and 6.00b:

    If you use DOS Version 2.10, note that all bound executable files
    must be run from the default disk drive. (A "bound executable" is a
    Family API application, which can run under OS/2 protected mode,
    OS/2 real mode, or MS-DOS.)

 Note: This correction does not apply to the documentation for
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 because BASIC PDS 7.00 requires DOS Version 3.00 or later.

 For instance, if the default drive is A, the following command does
 not work:

    B:SETUP

 Before running a bound executable file under DOS Version 2.10, you
 should move to the directory and drive that contain that file.

 The above is not a limitation with bound executable files under DOS
 Versions 3.x.

 This information is taken from the README.DOC disk file.


 21. Sample Program That Makes OS/2 CALL DosSetDateTime

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q27905

 Below is an example of how to make the DosSetDateTime OS/2 call.

 ' The user-defined TYPE and function DECLARE are found in BSEDOSPE.BI
 TYPE DateTime
      Hour        AS STRING*1
      Minutes     AS STRING*1
      Seconds     AS STRING*1
      Hundredths  AS STRING*1
      Day         AS STRING*1
      Month       AS STRING*1
      Year        AS INTEGER
      Timezone    AS INTEGER
      DayOfWeek   AS STRING*1
 END TYPE

 DECLARE FUNCTION DosSetDateTime%(SEG P1 AS DateTime)

 DIM dayt AS DateTime
 CLS
 input "Enter the HOUR : ";h%
 dayt.hour=chr$(h%)
 input "Enter the Minutes : ";m%
 dayt.minutes=chr$(m%)
 input "Enter the Seconds : ";s%
 dayt.seconds=chr$(s%)
 input "Enter the Hundredths : ";hd%
 dayt.hundredths=chr$(hd%)
 input "Enter the Month : ";mn%
 dayt.month=chr$(mn%)
 input "Enter the Date  : ";dt%
 dayt.day=chr$(dt%)
 input "Enter the Year  : ";yr%
 dayt.year=yr%
 input "Enter the TimeZone (number of hours from Greenwich Mean Time) : ";tz%
 dayt.timezone=tz%*60%

 x=DosSetDateTime%(dayt)

 IF (x) THEN
   Print "An error occurred.  The error number is : ";x
 ELSE
   print "The system time and date have been reset."
 END IF
 END


 22. CALLing Pascal and FORTRAN Modules in QuickBASIC Programs

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q27906

 The following information is from the README.DOC disk file for
 Microsoft BASIC Compiler Version 6.00 for MS-DOS and OS/2. This
 information also applies to BASIC compiler 6.00b, to Microsoft BASIC
 Professional Development System (PDS) Version 7.00, and to QuickBASIC
 Versions 4.00, 4.00b, and 4.50 for MS-DOS (and is also found in the
 README.DOC disk file for all these products except BASIC PDS 7.00).

 Modules compiled with Microsoft Pascal or FORTRAN can be linked with
 compiled BASIC programs, as described in the "Microsoft Mixed-Language
 Programming Guide" (which comes with Microsoft Macro Assembler
 Versions 5.00 and 5.10 or Microsoft C Versions 5.00 and 5.10). These
 modules can also be incorporated in Quick libraries for use in the
 QuickBASIC QB.EXE or BASIC PDS 7.00 QBX.EXE environments. However,
 BASIC programs containing code compiled with Microsoft Pascal must
 allocate at least 2K of near-heap space for Pascal. This can be done
 using the DIM statement to allocate a static array of 2K or greater in
 the NMALLOC named common block, as shown in the following example:

    DIM name%(2048)
    COMMON SHARED /NMALLOC/ name%()

 The Pascal run time assumes it always has at least 2K of near-heap
 space available. If the Pascal code cannot allocate the required
 space, BASIC may hang. This applies to Pascal code in Quick libraries
 as well as to Pascal code linked into executable files. The situation
 is similar for FORTRAN I/O, which also requires near buffer space, and
 which can be provided by the same means as the Pascal near malloc
 space.


 23. MS-DOS 3.20 Patch for Coprocessor Math Exceptions in BC and QB

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified: 22-JAN-1990    ArticleIdent: Q27911

 The information below is taken from the following files, and only
 applies to the product versions shown:

 1. The README.DOC file from the Program Disk of Microsoft BASIC
    Compiler Versions 6.00 and 6.00b for MS-DOS

 2. The UPDATE.DOC file from the Program Disk for QuickBASIC Version
    4.00b

 Note: This information was not included with Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS (except
 for a brief mention in the PACKING.LST file) but it still applies
 since PATCH87.EXE is shipped with BASIC PDS 7.00.

 This article 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 or 80287 chip)

 4. Runs programs that use floating-point math

 The following DOS patch is not necessary if you have PC-DOS; the patch
 only applies to MS-DOS. (Attempting to patch PC-DOS may give you an
 error such as the following: "File Not Found: IO.SYS".)

 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. The problem that usually arises is hanging when a math
 exception occurs. Math exceptions are items such as "divide by zero"
 or "overflow" errors. If you are not sure whether you need the patch,
 perform the following steps:

 1. Copy the program PATCH87.EXE (included in this release) to the
    root directory of your hard-disk 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 because that will
    affect the reliability of the diagnostic test that you are about
    to perform.

 3. If necessary, use the CD command to move to the root directory
    of your hard-disk drive.

 4. Run the PATCH87.EXE program by entering the following command at
    the DOS prompt:

       PATCH87

 5. 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. If the program tells you
    that you need to install the DOS patch, and that it can be done,
    follow the procedure described in the next section.

 Please note that the floating-point problem has been eliminated in
 versions of MS-DOS later than Version 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 MS-DOS.SYS from the root
    directory of your hard disk to the new floppy disk. For instance,
    if you boot from Drive C, 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. Install the DOS patch by entering the following command:

       PATCH87 /F

 Please note that 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 MS-DOS.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, enter the following
    command at the DOS prompt:

       A: SYS C:

 8. The DOS patch has been installed. Reboot the system.


 24. BASIC 6.00 & 7.00 Can't Make Family API (Bound) Applications

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified: 22-JAN-1990    ArticleIdent: Q27921

 Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2 cannot
 create "bound" applications (Family API applications). (A given bound
 EXE application can run under OS/2 protected mode, OS/2 real mode,
 and/or MS-DOS.) The compiler can only create EXE files that run under
 either OS/2 protected mode or real mode but not both. ("Real mode"
 includes both the DOS 3.x-compatibility box in OS/2, and straight
 MS-DOS.)

 To have the functionality of BASIC, the BASIC run-time module contains
 routines that are outside OS/2's Family API (Applications Programming
 Interface).


 25. EGA and VGA Graphics Are Not Supported in OS/2 Protected Mode

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27925

 EGA and VGA graphics are not supported in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b and Microsoft BASIC Professional Development
 System (PDS) Version 7.00 programs in the protected mode of OS/2.
 (Note also that COLOR is ignored in SCREEN 1.)

 The BASIC compiler talks directly to the hardware to perform EGA or
 VGA graphics. Applications that sit in OS/2 "ring 4" are not allowed
 to perform EGA or VGA graphics in the protected mode of OS/2.

 If the application needs to talk to the hardware, it must go through a
 device driver. There is currently not a device driver for EGA or VGA
 graphics in OS/2 protected mode.


 26. QBX /NOF (NOFrills) Option Saves 19K, Not 22K in BASIC 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 31-JAN-1990    ArticleIdent: Q58218

 The "Microsoft BASIC 7.0: Getting Started" manual incorrectly states
 on Page 15 that the /NOFrills command-line option for QBX.EXE reduces
 memory usage by 22K.

 However, the manual correctly states on Page 16 that QBX actually uses
 about 19K less memory with the /NOF command-line option.

 This information applies to QBX.EXE in Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS.

 Please note that the /NOF option for QBX.EXE is unrelated to the /NOF
 (/NOFarcalls) option for the linker (LINK.EXE) in BASIC PDS 7.00.


 27. Routines Compiled /FPa (Alt. Math) Can't Be in Quick Library

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified:  4-SEP-1990    ArticleIdent: Q27928

 The linker error message "L2025: Symbol defined more than once" occurs
 when you attempt to create a Quick library (LINK /Q) from .OBJ modules
 that were compiled with the alternate math package (BC /FPa) option.

 Routines compiled with BC /FPa (the alternate math package switch)
 cannot be placed into a Quick library because the QB.EXE or QBX.EXE
 environment does not support the use of the alternate math package.
 The QuickBASIC and QuickBASIC extended environments support only the
 IEEE coprocessor-emulation math package (/FPi). The alternate math
 package (/FPa) is only supported in compiled EXE programs.

 This information applies to the QB.EXE environment supplied with
 Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS, and to
 the QBX.EXE environment supplied with Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10.

 The purpose of the alternate floating-point math package is to provide
 faster floating-point calculations on computers that do not have a
 coprocessor. The alternate math package is significantly faster than
 the IEEE coprocessor-emulation math package when run on a computer
 without a coprocessor installed.

 Note that the alternate math package is about 50 percent slower than
 the Microsoft Binary Format (MBF) floating-point math found in the
 noncoprocessor version of QuickBASIC versions 3.00 and earlier.
 (QuickBASIC versions 4.00, 4.00b, and 4.50, Microsoft BASIC Compiler
 versions 6.00 and 6.00b, and Microsoft PDS versions 7.00 and 7.10 only
 offer support for the older MBF math with a /MBF compiler option and
 some MBF numeric conversion functions. These BASIC versions have
 adopted IEEE and alternate math to be compatible with the other
 Microsoft language products [FORTRAN, Pascal, and C] and to support
 the math coprocessor.)

 For the greatest speed, applications should be compiled with the BC
 /FPi switch and run on a computer with a coprocessor installed.


 28. Cannot Create Dynamic Link Libraries from BC 6.00 Modules

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27929

 Under MS OS/2 protected mode, you cannot create dynamic link libraries
 (DLLs) out of BASIC modules created with Microsoft BASIC Compiler
 Version 6.00 or 6.00b or Microsoft BASIC Professional Development
 System (PDS) Version 7.00.

 The following are a number of fundamental reasons why you cannot
 create dynamic link libraries out of compiled BASIC programs:

 1. Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft
    BASIC PDS Version 7.00 code is not reentrant.

 2. These compilers assume that the data (DS) and stack (SS) segments
    are the same, which is not allowed in a .DLL.

 3. Compiled BASIC routines cannot be called directly from an EXE
    written in another language, since a BASIC EXE must be the
    initiating program. This is not compatible with a dynamic link
    library.

 However, you can add your own BASIC routines to the BASIC run-time
 module with the BUILDRTM utility provided with BASIC compiler Versions
 6.00 and 6.00b and Microsoft BASIC PDS 7.00. The BASIC run-time module
 is a dynamic link library.

 BASIC compiler routines can also call routines contained in dynamic
 link libraries other than the BASIC run-time library.


 29. Sample Program That Makes OS/2 Call DosGetDateTime

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27931

 Below is a sample program that CALLs the OS/2 routine DosGetDateTime.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00.

 ' The user-defined TYPE and function DECLARE are found in
 ' BSEDOSPE.BI

 TYPE DateTime
      Hour        AS STRING*1
      Minutes     AS STRING*1
      Seconds     AS STRING*1
      Hundredths  AS STRING*1
      Day         AS STRING*1
      Month       AS STRING*1
      Year        AS INTEGER
      Timezone    AS INTEGER
      DayOfWeek   AS STRING*1
 END TYPE

 DECLARE FUNCTION DosGetDateTime%(SEG P1 AS DateTime)
 DECLARE FUNCTION FDAY$ (x%)

 DIM dayt AS DateTime
 CLS
 x=DosGetDateTime%(dayt)

 IF (x) THEN
   Print "An error occurred.  The error number is : ";x
 ELSE
   t$=str$(asc(dayt.hour))+":"+str$(asc(dayt.minutes))+":"_
      +str$(asc(dayt.seconds))  +":"+str$(asc(dayt.hundredths))

   d$=str$(asc(dayt.month))+"/"+right$(str$(asc(dayt.day)),2)_
       +"/"+right$(str$(dayt.year),4)

   Print "TIME : ";t$
   Print "DATE : ";d$
   print "Number of hours from Greenwich Mean Time : ";(dayt.timezone)/60%
   print "The day of the week : "; fday$(asc(dayt.dayofweek))
 END IF
 end

 FUNCTION FDAY$(x%) STATIC

 SELECT CASE x%
    case 0
        fday$="Sunday"
    case 1
        fday$="Monday"
    case 2
        fday$="Tuesday"
    case 3
        fday$="Wednesday"
    case 4
        fday$="Thursday"
    case 5
        fday$="Friday"
    case 6
        fday$="Saturday"
    case else
        fday$="XXXXXXXXX"
   END SELECT
 END FUNCTION


 30. Sample Program That Makes OS/2 Call to DosChdir

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q27936

 The following sample program makes an OS/2 call to DosChdir.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for MS OS/2.

 ' The function declaration is found in BSEDOSFL.BI

 DECLARE FUNCTION DosChdir%(_
                  BYVAL P1s AS INTEGER,_
                  BYVAL P1o AS INTEGER,_
                  BYVAL P2 AS LONG)
 DIM a AS LONG

 Input "Enter Directory: ";dr$
 dr$=dr$+chr$(0)
 x%=DosChdir%(varseg(dr$),sadd(dr$),a)
 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   Print "Directory changed for the process."
 END IF
 END


 31. Sample Program That Makes OS/2 Call to DosQCurDir

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27937

 Below is a sample program that makes an OS/2 call to DosQCurDir.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00.

 ' The function declaration is found in BSEDOSFL.BI

 DECLARE FUNCTION DOSQCURDIR%(_
         BYVAL P1 AS INTEGER,_
         BYVAL P2s AS INTEGER,_
         BYVAL P2o AS INTEGER,_
         SEG P3 AS INTEGER)

 DIM dirp AS STRING*80

 DEFINT a-z

 dpl=80
 number=0

 x=DosQCurDir%(number,varseg(dirp),varptr(dirp),dpl)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   dr$=left$(dirp,instr(1,dirp,chr$(0)))
   Print "The DIR path : ";dr$
 END IF
 END


 32. Sample Program That Makes OS/2 Call to DosSetFileMode

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27938

 Below is a sample program that makes an OS/2 call to DosSetFileMode.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 ' The function declaration is found in BSEDOSFL.BI

 DECLARE FUNCTION DosSetFileMode%(_
                  BYVAL P1s AS INTEGER,_
                  BYVAL P1o AS INTEGER,_
                  BYVAL P2 AS INTEGER,_
                  BYVAL P3 AS LONG)
 DIM c AS LONG

 INPUT "Enter the Filename : ";flname$
 flname$=flname$+chr$(0)
 PRINT "Attributes can be: Normal = 0"
 PRINT "                   Read only = 1"
 PRINT "                   Hidden = 2"
 PRINT "                   System = 4"
 PRINT "                   Directory = 16"
 PRINT "                   Archived = 32"
 INPUT "Enter desired file attribute : ";attr%

 x=DosSetFileMode%(varseg(flname$),sadd(flname$),attr%,c)

 IF (x) THEN
    print "An error has occurred.  The error number is ";x
 ELSE
   print "Attribute has been changed."
 END IF
 END


 33. Sample Program That Makes OS/2 Call to DosMkdir

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q27939

 Below is a sample program that makes a call to the OS/2 DosMkdir
 routine.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 ' The function declaration is found in BSEDOSFL.BI.

 DECLARE FUNCTION DosMkdir%(_
                  BYVAL P1s AS INTEGER,_
                  BYVAL P1o AS INTEGER,_
                  BYVAL P2 AS LONG)

 DIM a AS LONG

 Input "Enter the directory : ";dr$
 dr$=dr$+chr$(0)

 x=DosMkdir(varseg(dr$),sadd(dr$),a)

 IF (x) THEN
    print "An error has occurred.  The error number is ";x
 ELSE
   print "Directory was made"
 END IF
 END


 34. How to Modify the BASIC 6.00 Run-Time Module with BUILDTRM

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  7-FEB-1990    ArticleIdent: Q28020

 Using BUILDRTM, you can modify the default BASIC run-time modules. The
 runtime can be customized to a particular application. You can add
 routines to or delete routines from the BASIC runtime.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2 and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2. The
 following are the default run-time module names for the applicable
 products:

    BC 6.00          BC 6.00b        PDS 7.00
    -------          --------        --------

    BRUN60ER.EXE     BRUN61ER.EXE    BRT70ENR.EXE
    BRUN60AR.EXE     BRUN61AR.EXE    BRT70EFR.EXE
                                     BRT70ANR.EXE
                                     BRT70AFR.EXE

 For more information, please refer to Section 3.3 of the "Microsoft
 BASIC Compiler 6.0: User's Guide" for Microsoft BASIC Compiler Version
 6.00 or 6.00b, or Chapter 21 of the "Microsoft BASIC 7.0: Programmer's
 Guide" for Microsoft BASIC PDS Version 7.00.

 The following is an example:

    ===== EXPORT.LST =====

    #OBJECTS
    NOLPT.OBJ
    NOGRAPH.OBJ
    MYROUTINE.OBJ

    #EXPORTS
    myroutine1
    myroutine2
    myroutine3

    ===== COMMAND LINE to CREATE the RUNTIME =====

    BUILDRTM newruntime export.lst

    ===== COMMAND LINE to USE the RUNTIME =====

    LINK IMPORT.OBJ your objects,executable,,NEWRUNTIME.LIB /NOD


 35. MS Floating Point Is Faster Than BC /FPa Alternate Math

 Product Version(s): 6.00 6.00b 7.00  | 6.00 6.00b 7.00
 Operating System:   MS-DOS           | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28023

 An EXE compiled with the Alternate Math package (BC /FPa) performs
 floating-point calculations more slowly than an EXE compiled with
 QuickBASIC Versions 3.00 and 2.x Microsoft Floating Point.

 However, an EXE compiled with the alternate math package is between 40
 and 50 percent faster than an EXE compiled with IEEE Floating Point
 (with no /FPa switch) when run on a computer that does not have a
 coprocessor.

 Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 do not support
 Microsoft Floating Point. If you want the greatest floating-point
 speed on a computer that does not have a coprocessor, compile with the
 BC /FPa switch. ("FPa" stands for "Floating Point Alternate-Math
 Library"). If you want the greatest floating-point speed on a computer
 that has a coprocessor, compile with the BC /FPi switch. ("FPi" stands
 for "Floating Point In-line Instructions"). In-line Instructions is
 the default when you compile with BC and without /FPa or /FPi switch.

 Microsoft Floating Point is an older format found in the
 noncoprocessor version of QuickBASIC Version 3.00. It also is found in
 all prior versions of QuickBASIC (Versions 2.10, 2.00, 1.02, 1.01,
 1.00).

 Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft BASIC
 PDS Version 7.00 do not support Microsoft Floating Point. These
 products have adopted IEEE and Alternate Math in order to be linkable
 with FORTRAN, PASCAL, and C.

 Compiling with BC /FPa gives you the Alternate Math floating-point
 format. (The QuickBASIC interpreter uses only IEEE and cannot use
 Alternate Math.)

 Compiling without /FPa gives you IEEE floating-point format. IEEE
 floating-point format is fastest when run on a computer that has a
 coprocessor installed.


 36. EXE May Be Slower in OS/2 Protected Mode than in DOS

 Product Version(s): 6.00 6.00b 7.00  | 6.00 6.00b 7.00
 Operating System:   MS-DOS           | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28024

 Because of the event scheduling in OS/2, programs run under protected
 mode may run more slowly than they did under DOS. This is expected
 behavior.

 Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 are all capable of
 compiling programs to run under OS/2 protected mode.


 37. SETUP Program Can Create Subdirectory Only If Parent Exists

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  7-FEB-1990    ArticleIdent: Q28027

 The SETUP.EXE program can create a subdirectory only if the parent
 directory already exists. For example, if you want to place the
 library files in a subdirectory named \BC6\LIB, the directory \BC6
 must exist before SETUP is run.

 This information applies to the SETUP.EXE program in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS-DOS and OS/2, Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2, and Microsoft QuickBASIC Versions 4.00, 4.00b, and 4.50 for the
 MS-DOS.

 This is also a limitation of DOS. You cannot use the MKDIR command to
 create a subdirectory in a directory that does not exist.


 38. QB Fast Load Format Source Code Cannot Be Used in MS CodeView

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER |
 Last Modified: 17-JAN-1991    ArticleIdent: Q28030

 Microsoft CodeView is not able to read the QuickBASIC source file if
 it is saved in Fast Load format. If you plan to use the Microsoft
 CodeView debugger, be sure that the source file is saved in ASCII
 format.

 To save a file in ASCII format, use the Save As command on the File
 menu in the QB.EXE environment of Microsoft BASIC Compiler version
 6.00 or 6.00b, or in the QBX.EXE environment of Microsoft BASIC
 Professional Development System (PDS) version 7.00 or 7.10.

 To compile a BASIC program for use with CodeView, follow these steps:

 1. BC filename /Zi [other switches]

 2. LINK filename /Co [other switches]


 39. No "Incompatible Runtime" CHAIN Error with Mismatched COMMON

 Product Version(s): 6.00   | 6.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 runtime
 Last Modified: 30-MAY-1990    ArticleIdent: Q28038

 The problem under Microsoft BASIC Compiler version 6.00 and 6.00b is
 as follows:

 1. A routine that has a blank COMMON block is built into a custom
    run-time module with BUILDRTM.EXE.

 2. Main1 contains the same blank COMMON (matched exactly in length).

 3. Main2 contains the same blank COMMON plus some more blank COMMON.

 4. Main3 contains the same blank COMMON as Main2.

 5. Main1 chains to Main2, which puts something in the EXTENDED portion
    of COMMON, then chains to Main3. Main3 expects something to be
    there, but it is gone.

 There should be an error on the chain to Main2 since we cannot enlarge
 blank COMMON when there is a set size of blank COMMON in the custom
 run-time module. An error should have been generated during the chain.
 When Main2 is run as a stand alone, the "incompatible runtime module"
 error message appears.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Compiler versions 6.00 and 6.00b, and in Microsoft BASIC Professional
 Development System (PDS) version 7.00. We are researching this problem
 and will post new information here as it becomes available.

 When using Microsoft BASIC PDS version 7.00 for MS-DOS and MS OS/2,
 any inclusion of a COMMON block into a custom run-time module will
 result in an "incompatible runtime module" error, even if the COMMON
 statement(s) in the run-time match the COMMON in the program(s).
 If you link IMPORT.OBJ as the first .OBJ file on the link line,
 this is not a problem.

 The following is code example for Microsoft BASIC Compiler versions
 6.00 and 6.00b:

 MAIN1:

   common a,b,c     'This COMMON matches the COMMON in the custom run time
   a=1
   b=2
   c=3
   chain "main2"
   end

 MAIN2:

   common a,b,c,d,e  'It is not legal to add more elements to the blank
                     'COMMON if you are using a custom run time.
   d=4
   e=5
   chain "main3"
   end

 MAIN3:

   common a,b,c,d,e
   print a,b,c,d,e
   end


 40. LOCATE Has 8 lines Resolution DOS & Real Mode, 16 in Protected

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28042

 The BASIC statement LOCATE X,Y,1,0,7 executed under DOS and real mode
 generates a cursor block eight lines tall. Executing the same
 statement under protected mode generates a small block of a cursor.
 For a full-height cursor under protected mode, the statement must be
 LOCATE X,Y,1,0,15. This is expected behavior and is documented in the
 "Microsoft BASIC 7.0: Language Reference" on Page 196.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2, and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.


 41. Misleading QB.EXE Message Using Reserved Word in SUB

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q28158

 Illegally using the reserved word "SEG" in a SUB statement can give
 you a misleading error message.

 To generate the misleading message, start up the QB.EXE environment of
 Microsoft BASIC Compiler Version 6.00 or 6.00b or Microsoft QuickBASIC
 Version 4.00, 4.00b, or 4.50, and type the following:

    SUB foo(SEG x AS INTEGER)

 The environment highlights the SEG keyword and returns the following:

    Expected: variable or BYVAL or SEG or )

 This is because the parser correctly detects that SEG is illegal in a
 SUB statement, but shares the error message with DECLARE, so SEG is
 misleadingly listed as "expected."

 This error message has been clarified in the QBX.EXE environment of
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2. This situation now produces the following error,
 indicating that the SEG keyword is not allowed in that context:

    Expected: parameter or )


 42. QB /L A: Does Not Find QB.QLB If SET LIB=A: Is Not Set

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28160

 Problem:

 If the default Quick library file QB.QLB is on Drive A and no LIB
 environment variable is set, then the following command line fails to
 find QB.QLB:

    QB /L A:

 Response:

 This is how the Quick library search is supposed to work. If no
 argument is given to the /L switch, QB.EXE looks for a filename of
 QB.QLB. Otherwise, if you specify a drive such as Drive A, QB.EXE
 assumes that you are specifying a Quick library name other than
 QB.QLB.

 The following are easy workarounds:

 1. Specify QB /L A:QB, which is only two characters longer.

 2. An alternate workaround is to perform the following command from
    the DOS command line before running QB /L:

       SET LIB=A:


 43. Missing END IF in FOR NEXT Gives Different Errors in QB and BC

 Product Version(s): 6.00 6.00b 7.00   | 6.00 6.00b 7.00
 Operating System:   MS-DOS            | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28162

 The following program gives a "NEXT without FOR" error in QB.EXE and
 the QBX.EXE environment shipped with Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS, and a "BLOCK IF
 WITHOUT END IF" error from an EXE compiled in BC.EXE (the following is
 a code example):

    for i=1 to 10
       if x=10 then
         a=c
       else
          d=c
     next i

 Both error messages are correct, depending on how you view the program.
 This feature will not be changed.


 44. Unexpected PRINT USING ".##" Rounding for .xx5

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28163

 Problem:

 For the following statement

    PRINT USING " ###.##"; .245, .255, .265, .275, .285

 the output is as follows

    0.25  0.25  0.26  0.28  0.28

 whereas you would expect the following

    0.25  0.26  0.27  0.28  0.29

 or with IEEE rounding, you would expect the following:

       0.24  0.26  0.26  0.28  0.28

 Response:

 The internal representation of the numbers used by BASIC differs
 slightly from the decimal numbers typed into the source code.

 IEEE floating-point format cannot accurately represent numbers that
 are not of the form 1.x to the power of y (where x and y are base 2
 numbers). The internal representation will be slightly more or
 slightly less than the decimal numbers typed into the source code.

 The internal representations are correctly rounded and displayed. This
 is not a software problem.


 45. "String Formula Too Complex" with Recursive String Function

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q28165

 The program below, which recursively invokes a string function, causes
 a "String Formula Too Complex" run-time error. This program shows a
 design limitation in Microsoft BASIC Compiler Version 6.00 and 6.00b,
 Microsoft BASIC Professional Development System (PDS) Version 7.00,
 and in QuickBASIC that is not usually encountered.

 In the following program, QuickBASIC is computing RIGHT$(TEXT$,1),
 assigning the value to a temporary string descriptor, and then
 recursing on REVERSE$(LEFT$(TEXT$,LEN(TEXT$)-1)):

    DECLARE FUNCTION Reverse$ (Text$)
    CLS
    PRINT Reverse$ ("123456789 1234567890")

    FUNCTION Reverse$ (Text$)
    IF LEN(Text$) = 0 THEN
      EXIT FUNCTION
    ELSE
      Reverse$ = RIGHT$(Text$, 1) + Reverse$ (LEFT$(Text$, LEN(Text$) -1))
    END IF
    END FUNCTION

 The temporary string descriptor is not released until the recursion is
 completed. Each recursive REVERSE$ function call locks one string
 descriptor. Because QuickBASIC allows only 20 temporary descriptors
 (more than enough for most applications), after around 20 function
 calls the program gives the error "String Formula Too Complex."

 The workaround is to use a real string descriptor as follows (which
 will be allocated from stack space):

    Temp$ = Reverse$(LEFT$(Text$,LEN(Text$)-1))
    Reverse$ = RIGHT$(Text$,1) + Temp$


 46. QB Uses Up Default String Space When Concatenating Far String

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q28166

 Problem:

 When running the program below inside the QB.EXE environment, after
 about 72 iterations of concatenating a variable-length string onto a
 fixed-length string, an "Out of String Space" error is generated.
 However, the FRE("") and FRE(-1) functions both return the same value
 all the way through the loop. Note that the array of fixed-length
 strings is dynamically allocated, putting it into the far heap.

 The program runs properly when compiled and run as an EXE file.

 Response:

 The problem is that QuickBASIC assumes that a far fixed-length string
 will always stay far.

 However, the BASIC run-time routines must have the string in DGROUP in
 order to manipulate it with string functions like LTRIM$ and RTRIM$.
 LTRIM$ and RTRIM$ require two copies of the string at one point, and
 the program eventually runs out of string space in the default data
 segment in DGROUP. This will also happen in a version of the program
 compiled with BC /O if the strings are made longer. This limitation of
 BASIC is inherent in its construction, and Microsoft currently has no
 plans to change this construction.

 The following is a code example:

    REM $DYNAMIC
    DIM srv(0) AS STRING * 28000

    abc$ = STRING$(330,"0")

    srv(0) = abc$
    FOR t = 1 to 79
       srv(0) = RTRIM$(srv(0)) + abc$
       PRINT t, LEN(RTRIM$(srv(0))), FRE(""), FRE(-1)
    NEXT t


 47. A RETURN Without a GOSUB in a Subprogram Hangs in EXE

 Product Version(s): 6.00    | 6.00
 Operating System:   MS-DOS  | OS/2
 Flags: ENDUSER |
 Last Modified: 11-JUL-1990    ArticleIdent: Q28154

 Executing a RETURN statement without a corresponding GOSUB in a
 subprogram hangs an EXE program when compiled without the BC /D
 option. You must compile with the BC /D option (or compile in the
 QuickBASIC environment) to trap a "RETURN without GOSUB" programming
 error (just as you must use BC /D to trap array bounds violations).

 This information applies to BC.EXE in Microsoft BASIC Compiler
 versions 6.00 and 6.00b for MS-DOS and MS OS/2, to BC.EXE in Microsoft
 BASIC Professional Development System (PDS) version 7.00 for MS-DOS
 and MS OS/2, and to BC.EXE in QuickBASIC versions 4.00, 4.00b, and
 4.50 for MS-DOS.

 Compile the test program below with BC.EXE and then link it. If you
 compile with the BC /D option, the program gives run-time error,
 "RETURN without GOSUB." If you don't compile with /D, the program
 hangs the computer at run time without telling you about your
 programming mistake.

 To avoid hanging due to a programming error like this, use the QB.EXE
 or QBX.EXE environment as a debugger, since the interpreter
 environment correctly traps the "Return without GOSUB" error. The
 program should be modified to remove the "Return without GOSUB"
 programming error.

 Code Example
 ------------

 ' test.bas
    defint a-z
    declare sub atest ( x )

      i = 1
      print i
      call atest (i)
      print i
    end

    sub atest ( j )
       print j
       j = 2
       print j
       return
    end sub


 48. BC 6.00 Example Calling OS/2 API Function DosSetMaxFH

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35906

 Below is a sample program that makes a call to the MS OS/2 function
 DosSetMaxFH. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS OS/2.

 By default, 20 file handles are allocated to a file. To increase the
 number of file handles available, the DosSetMaxFH function must be
 called. The maximum number of file handles is 255. When determining
 the required number of handles, add several for dynamic-link modules
 (these modules use several handles), and three more for the default
 system I/O handles.

 The following is a code example:

 'This information is found in BSEDOSFL.BI
 DECLARE FUNCTION DOSSETMAXFH%(BYVAL P1 AS INTEGER)

 INPUT "Enter the maximum number of file handles : ",fh%
 x=DosSetMaxFH%(fh%)

 IF (x) THEN
    Print "An error occurred.  The error number is ";x
 ELSE
    Print "Maximum number of file handles has been changed."
 END IF

 ON ERROR GOTO DONE

 for i = 1 to 255
   fl$="xxxxx"+mid$(str$(i),2,len(str$(i)))
   open fl$ for output as i
 next i
 stop

 done:
   Print i

 end


 49. It Is Illegal to Pass a CONST Type Constant in COMMON

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28283

 A user-defined CONST constant cannot be passed in COMMON.

 CONST constants never need to be passed in COMMON since you can put
 the CONST definitions in a $include file to include for use in any
 desired module.

 A given user-defined CONST constant is local to each separately
 compiled module, and can be used throughout a given source file.

 The following is an example of illegally passing a CONST type symbol
 in COMMON. In the QB.EXE environment that comes with Microsoft BASIC
 Compiler Versions 6.00 and 6.00b or in the QBX.EXE environment
 supplied with Microsoft BASIC Professional Development System (PDS)
 Version 7.00, the following program correctly gives a "duplicate
 definition" error on x in the COMMON SHARED:

    CONST x = 5
    COMMON SHARED x, y, z   ' "duplicate definition" error for x
    TYPE person
      test AS STRING * x
    END TYPE
    DIM joe AS person

 Please note that when you use STRING * x, x must be a CONST type or a
 numeric constant, according to the "Microsoft QuickBASIC 4.0: BASIC
 Language Reference" manual on Page 430.

 The following shows how the above program can be modified to work
 correctly:

    CONST x = 5
    COMMON SHARED y, z
    TYPE person
      test AS STRING * x
    END TYPE
    DIM joe AS person


 50. OS/2 Protected Mode Restrictions for BASIC Compiler 6.00/6.00b

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28442

 The following is a list of restrictions under MS OS/2 protected mode
 for Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft
 BASIC Professional Development System (PDS) Version 7.00:

  1. Programs using statements that refer directly to addresses in the
     machine's physical memory may need modification when run in
     protected mode, for example, CALL ABSOLUTE, DEF SEG, PEEK, POKE,
     BLOAD, BSAVE, VARPTR, and VARSEG.

  2. Graphics are limited to screens 1 and 2. EGA and VGA graphics are
     not supported in protected mode.

  3. Except for BEEP, no sound is supported. SOUND or PLAY statements
     are not allowed in protected mode. As a workaround, you can make
     an OS/2 CALL to create a sound with a specified frequency and
     duration.

  4. Light pens and joysticks are not allowed in protected mode.

  5. CALL INT86, INT86OLD, INT86X, INTERRUPT, and INTERRUPTX are not
     available in protected mode.

  6. COLOR is ignored in Screen 1 in protected mode.

  7. INP and OUT are not available in protected mode.

  8. IOCTL and IOCTL$ are not available in protected mode.

  9. PALETTE [USING] is not available in protected mode.

 10. WAIT is not available in protected mode.

 11. If a program in real mode is using the serial communications port
     (COM1 or COM2), then you cannot use that port in protected mode at
     the same time. This is an OS/2 restriction. The reverse is also
     true: if a program in protected mode is using the communications
     port (COM1 or COM2), then you cannot use that port in real mode at
     the same time.


 51. Example of Calling OS/2 Function DosRmDir

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28443

 The following is a sample program that makes OS/2 call to DosRmDir:

 ' The DosRmDir FUNCTION declaration is found in the file BSEDOSFL.BI

    DECLARE FUNCTION DosRmDir%(_
            BYVAL P1s AS INTEGER,_
            BYVAL P1o AS INTEGER,_
            BYVAL P2 AS LONG)

    DIM a AS LONG

    Input "Enter Directory to be removed : ";dr$
    dr$=dr$+chr$(0)

    x=DosRmdir(varseg(dr$),sadd(dr$),a)
    IF (x) THEN
       print "An error has occurred.  The error number is ";x
    ELSE
       print "Directory ";dr$;" was REMOVED"
    END IF
    END


 52. Example of Calling OS/2 DosGetVersion and DosGetMachineMode

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28444

 Below is a sample program that makes calls to the OS/2 functions
 DosGetVersion and DosGetMachineMode.

 ' The function declarations are found in BSEDOSPC.BI

 DECLARE FUNCTION DosGetVersion%(_
         SEG P1 AS INTEGER)

 DECLARE FUNCTION DosGetMachineMode(_
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER)

 DEFINT A-Z
 CLS
 DIM mode AS STRING*1

 x=DosGetMachineMode%(varseg(mode),varptr(mode))
 IF (x) THEN
    Print "An error occurred. The number is : ";x
 ELSE
    IF mode=chr$(0) THEN
       print "Real Mode"
    ELSE
       print "Protect Mode"
    END if
 END IF

 x=DosGetVersion(version)
 IF (x) THEN
    Print "An error occurred. The number is : ";x
 ELSE
    Print "The version number is : ";
    Print  peek(varptr(version)+1);".";peek(varptr(version))
 END IF


 53. Example of Calling OS/2 DosSetFSInfo and DosQFSInfo

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28445

 Below is a sample program that makes OS/2 calls to DOSSetFSInfo and
 DOSQFSInfo.

 ' The function declarations are found in file BSEDOSFL.BI

 TYPE FSAllocate1
      Filesysid    AS LONG
      SecPerUnit   AS LONG
      NumUnits     AS LONG
      AvailUnits   AS LONG
      ByteSec     AS INTEGER
 END TYPE

 TYPE FSAllocate2
      VolumeDate  AS INTEGER
      VolumeTime  AS INTEGER
      VLen        AS STRING*1
      VLabel      AS STRING*11
 END TYPE

 TYPE SetInfo2
      Vlen        AS STRING*1
      VLabel      AS STRING*11
 END TYPE

 DECLARE FUNCTION DOSSetFSInfo%(_
         BYVAL P1 AS INTEGER,_
         BYVAL P2 AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P3o AS INTEGER,_
         BYVAL P4 AS INTEGER)

 DECLARE FUNCTION DOSQFSInfo%(_
         BYVAL P1 AS INTEGER,_
         BYVAL P2 AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P3o AS INTEGER,_
         BYVAL P4 AS  INTEGER)

 'Routine to Shift and Print Information

 DECLARE FUNCTION wdate$(p1 as integer)
 DECLARE FUNCTION wtime$(p1 as integer)
 DECLARE FUNCTION RightShift%(P1 as LONG,P2 as Integer)
 DECLARE FUNCTION LeftShift%(P1 as LONG, P2 as Integer)
 DECLARE FUNCTION unsigned&(P1 as integer)

 DEFINT a-z
 DIM info1 AS FSAllocate1
 DIM info2 AS FSAllocate2
 DIM info3 AS SetInfo2
 cls

 Input "Enter Drive Number (0=default, 1=A, etc) : ",drivenumber
 level = 1
 bufsize=18

 x = DosQFSInfo%(drivenumber,level,varseg(info1),varptr(info1),bufsize)

 print
 Print "Level One Information"
 print
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "File System ID : ";info1.Filesysid
    print "Number of sectors per allocation unit : ";info1.secperunit
    print "Number of allocation units : ";info1.numunits
    print "Available allocation units : ";info1.availunits
    print "Bytes per sector : ";info1.bytesec
 END IF

 level=2
 bufsize=16
 print
 Print "Level Two Information"
 print

 x = DosQFSInfo%(drivenumber,level,varseg(info2),varptr(info2),bufsize)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "Volume Creation Date : ";wdate$(info2.VolumeDate)
    PRINT "Volume Creation Time : ";wtime$(info2.VolumeTime)
    PRINT "Length of Label : ";asc(info2.Vlen)
    PRINT "Volume Label : ";info2.Vlabel
 END IF

 print
 input "Enter the new VOLUME name : ";info3.Vlabel
 info3.vlen=chr$(len(info3.vlabel))
 info3.vlabel=info3.vlabel+chr$(0)
 level=2
 bufsize=12

 x = DosSetFSInfo%(drivenumber,level,varseg(info3),varptr(info3),bufsize)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    Print "The volume label is changed."
    level=2
    bufsize=16
    print
    Print "Level Two Information"
    print
    x = DosQFSInfo%(drivenumber,level,varseg(info2),varptr(info2),bufsize)
    IF (x) THEN
      Print "An error occurred.  The number is : ";x
   ELSE
      PRINT "Volume Creation Date : ";wdate$(info2.VolumeDate)
      PRINT "Volume Creation Time : ";wtime$(info2.VolumeTime)
      PRINT "Length of Label : ";asc(info2.Vlen)
      PRINT "Volume Label : ";info2.Vlabel
   END IF
 END IF

 END

 FUNCTION wdate$(d%) static
 DIM dl AS LONG
     dl=unsigned&(d%)
     mn=(RightShift%(dl,5)) AND (&h0f)
     IF mn < 10 THEN
        mn$="0"+ltrim$(str$(mn))
     ELSE
        mn$=ltrim$(str$(mn))
     END IF
     dy= dl AND (&h1f)
     IF dy < 10 THEN
        dy$="0"+ltrim$(str$(dy))
     ELSE
        dy$=ltrim$(str$(dy))
     END IF
     yr$=str$(RightShift(dl,9)+1980)
     wdate$=mn$+"/"+dy$+"/"+ltrim$(yr$)
 END FUNCTION

 FUNCTION wtime$(d%)
 DIM dl AS LONG
    dl=unsigned&(d%)
    hr=RightShift%(dl,11) AND (&h1f)
    IF hr < 10 THEN
       hr$="0"+ltrim$(str$(hr))
    ELSE
       hr$=ltrim$(str$(hr))
    END IF
    mt=(RightShift%(dl,5) AND (&h3f))
    IF mt < 10 THEN
       mt$="0"+ltrim$(str$(mt))
    ELSE
       mt$=ltrim$(str$(mt))
    END IF
    wtime$=ltrim$(hr$)+":"+mt$+string$(5,32)
 END FUNCTION

 FUNCTION RightShift%(number&,amount)
    Rightshift=number&\2^amount
 END FUNCTION

 FUNCTION LeftShift%(number&,amount)
   LeftShift=number&*(2^amount)
 END FUNCTION

 FUNCTION unsigned&(num)
    IF num >=0 THEN
       unsigned&=num
    ELSE
       unsigned&=65536+num
    END IF
 END FUNCTION


 54. Example of Calling OS/2 Function DosGetEnv

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28446

 Below is a sample program that invokes the OS/2 function DosGetEnv.

 ' The function declarations are found in file BSEDOSPC.BI

 DECLARE FUNCTION DosGetEnv%(_
         SEG P1 AS INTEGER,_
         SEG P2 AS INTEGER)
 cls
 x=DosGetEnv(y%,z%)

 IF (x) then
   Print "An error occurred.  The error number is ";x
 ELSE
   Print "Address to Place Segment Handle : ";y%
   Print "Address to Place Command Line Start : ",z%
 END IF

 def seg = y%

 PRINT "THE INFORMATION IN THE ENVIRONMENT TABLE :" : PRINT

 For i = 0 to z%-20
   t%=peek(i)
   IF t%=42 THEN
      hold%=i
   END IF

   IF t% = 0 THEN
     print " "
   ELSE
     print chr$(t%);
   END IF
 next i
 print
 i = 0
 PRINT "The Command Line Argument is : ";

 DO
  t%=peek(z%+i)
  print chr$(t%);
  i = i + 1
 LOOP WHILE t% <> 0
 PRINT " "

 print
 PRINT "POKING SOME INFORMATION INTO THE ENVIRONMENT TABLE... " : print
 PRINT

 IF hold%<>0 THEN
    for i = 0 to 9
      poke hold%-i, 74-i
    next i
    def seg
    PRINT "The information was poked into the environment variable FOO;"
    PRINT "which was previously set to **********"

    print "The NEW contents of FOO  : ";environ$("FOO") : print
    Print "When the program is exited, notice the environment table";
    Print "isn't changed."
    PRINT "BASCOM uses only a copy of the actual DOS environment table"
    print
 ELSE
    print "The FOO environment variable is not set. "
    print "To have the complete demo, set the FOO=**********"
 END IF
 END


 55. Calling OS/2 DOSInsMessage, DOSGetMessage, DOSPutMessage

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28447

 Below is an example of calling OS/2 DOSInsMessage, DOSGetMessage, and
 DOSPutMessage.

 ' The function declarations are found in file BSEDOSPC.BI

 TYPE ADDRESS
      OFFSET  AS INTEGER
      SEGMENT AS INTEGER
 END TYPE

 DECLARE FUNCTION DOSINSMESSAGE%(_
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER,_
         BYVAL P2  AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P3o AS INTEGER,_
         BYVAL P4  AS INTEGER,_
         BYVAL P5s AS INTEGER,_
         BYVAL P5o AS INTEGER,_
         BYVAL P6  AS INTEGER,_
         SEG   P7  AS INTEGER)

 DECLARE FUNCTION DOSGETMESSAGE%(_
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER,_
         BYVAL P2  AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P3o AS INTEGER,_
         BYVAL P4  AS INTEGER,_
         BYVAL P5  AS INTEGER,_
         BYVAL P6s AS INTEGER,_
         BYVAL P6o AS INTEGER,_
         SEG   P7  AS INTEGER)

 DECLARE FUNCTION DOSPUTMESSAGE%(_
         BYVAL P1  AS INTEGER,_
         BYVAL P2  AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P3o AS INTEGER)

 DEFINT a-z

 DIM VarTable(9) AS ADDRESS   'Array of address of Strings
 VarCount=2
 CLS
 MsgIn$="This is a test.  My Name is %1 %2"+chr$(0)
 MsgInLen=len(MsgIn$)

 DIM MsgOut AS STRING*80

 MsgOutLen=len(MsgOut)
 MsgOut=string$(MsgOutLen-1,32)

 one$="Joe"+chr$(0)
 two$="Smith"+chr$(0)

 VarTable(0).offset=sadd(one$)
 VarTable(0).segment=varseg(one$)
 VarTable(1).offset=sadd(two$)
 VarTable(1).segment=varseg(two$)

 x=DosInsMessage%(varseg(VarTable(0)),varptr(VarTable(0)),VarCount,_
                  varseg(MsgIn$),sadd(MsgIn$),MsgInLen,_
                  varseg(MsgOut),varptr(MsgOut),MsgOutLen,number)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
   print MsgOut
 END IF

 DIM buffer as STRING*80
 BufferLen=80

 'This is a file by the OS/2 Message Utilities.
 'See Microsoft OS/2 Programmer's Guide, Section 20.5, Pages 205-212)

 Filename$="JoeSmith.msg"+chr$(0)

 FOR i = 100 to 104
 x=DosGetMessage%(varseg(VarTable(0)),varptr(VarTable(0)),VarCount,_
                  varseg(buffer),varptr(buffer),BufferLen,_
                  i,varseg(filename$),sadd(filename$),number)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
   x=DosPutMessage(1,number,varseg(buffer),varptr(buffer))
   IF (x) THEN
      Print "An error occurred.  The number is : ";x
   END IF
 END IF
 NEXT i
 locate 10,1

 END


 56. Example Calling OS/2 DosFindFirst, DosFindNext, DosFindClose

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q28448

 Below is an example of calling OS/2 DosFindFirst, DosFindNext, and
 DosFindClose.

 'Declarations found in file BSEDOSFL.BI
 'Compiler options: /D/W (/V requires modifications to the code)
 CONST TRUE=-1
 CONST FALSE=0

 TYPE FILEFINDBUF
         fdateCreation  AS INTEGER
         ftimeCreation  AS INTEGER
         fdateLastAccess AS INTEGER
         ftimeLastAccess AS INTEGER
         fdateLastWrite AS INTEGER
         ftimeLastWrite AS INTEGER
         cbFile         AS LONG
         cbFileAlloc    AS LONG
         attrFile       AS INTEGER
         cchName        AS STRING * 1
         achName        AS STRING * 13
 END TYPE

 DECLARE FUNCTION DosFindFirst%( _
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER,_
         SEG   P2 AS INTEGER,_
         BYVAL P3 AS INTEGER,_
         SEG   P4 AS FILEFINDBUF,_
         BYVAL P5 AS INTEGER,_
         SEG   P6 AS INTEGER,_
         BYVAL P7 AS LONG)

 DECLARE FUNCTION DosFindNext%( _
         BYVAL P1 AS INTEGER,_
         SEG   P2 AS FILEFINDBUF,_
         BYVAL P3 AS INTEGER,_
         SEG   P4 AS INTEGER)

 DECLARE FUNCTION DosFindClose%( _
         BYVAL P1 AS INTEGER)

 'Routines to print Date/Time and File Type

 DECLARE FUNCTION wdate$(p1 as integer)
 DECLARE FUNCTION wtime$(p1 as integer)
 DECLARE FUNCTION RightShift%(P1 as LONG,P2 as Integer)
 DECLARE FUNCTION LeftShift%(P1 as LONG, P2 as Integer)
 DECLARE FUNCTION FileType$(P1 as Integer)

 DEFINT a-z

 COLOR 15,1
 DIM buffer AS FileFindBuf
 DIM filelist(255) as FileFindBuf
 DIM reserved  AS LONG

 CLS
 print "Test of DOSFINDFIRST..."

 INPUT "Enter the Filename(s) : ";flname$
 flname$=flname$+chr$(0)

 atr= 0+2+4+16    'normal + hidden + system + subdirectory
 dirh=1
 searchcount=1
 bufflen=36

 x=DosFindFirst%(varseg(flname$),sadd(flname$),_
                 dirh,atr,buffer,bufflen,searchcount,reserved)
 IF (X=0) THEN
    DO
      counter=counter+1
      filelist(counter)=buffer
      buffer.achname=string$(13,32)  'assign blanks
      buffer.fdatelastwrite=0
      buffer.ftimelastwrite=0
    LOOP WHILE (DosFindNext%(dirh,buffer,bufflen,searchcount) = 0 )
 ELSE
     PRINT "No MATCH was found"
     END
 END IF
 CLS

 print  "FILENAME : "; : LOCATE 1,30 : PRINT "FILE SIZE : ";
 locate 2,1 : PRINT "LAST WRITE DATE : ";
 locate 3,1 : PRINT "LAST WRITE TIME : ";
 locate 4,1 : PRINT "FILE TYPE : ";
 COLOR 5

 i = 1

 done=FALSE

 key 15, chr$(&h00)+chr$(&h01) 'ESC KEY to EXIT
 on key (15) gosub FINISH
 on key (11) gosub UP
 on key (14) gosub DOWN
 key (15) on
 key (11) on
 key (14) on

 locate 20,1 : Print "Enter ESC to quit, UP/DOWN ARROWS to scroll list";

 while (not DONE)
 lp:
  LOCATE 1,14 : PRINT filelist(i).achname;
  LOCATE 1,45 : PRINT filelist(i).cbfile;"/";filelist(i).cbfilealloc;"       "
  LOCATE 2,20 : PRINT wdate$(filelist(i).fdatelastwrite);"        ";
  LOCATE 3,20 : PRINT wtime$(filelist(i).ftimelastwrite);"        ";
  LOCATE 4,15 : PRINT filetype$(filelist(i).attrfile);"       ";
  a$=inkey$
  if a$="" then goto lp
 wend

 color 15
 x=DosFindClose%(dirh)
 IF (x) THEN
   color 7 : PRINT "An error occurred. The number is : ";x : color 15
 ELSE
   color ,0
   cls
 END IF
 END
 STOP

 FINISH:
    DONE = TRUE
    RETURN
    STOP
 UP:
    IF i = 1 THEN
       locate 24,1
       color 7
       print "At the top of the list                       ";
       color 5
    ELSE
       locate 24,1 : print string$(78,32);
       i = i - 1
    END IF
    RETURN
    STOP
 DOWN:
    IF i = counter THEN
       locate 24,1
       color 7
       Print "At the bottom of the list                  ";
       color 5
    ELSE
       i = i + 1
       locate 24,1 : print string$(78,32);
    END IF
    RETURN
    STOP

 FUNCTION wdate$(d%) static
 DIM dl AS LONG
     dl=unsigned&(d%)
     mn=(RightShift%(dl,5)) AND (&h0f)
     IF mn < 10 THEN
        mn$="0"+ltrim$(str$(mn))
     ELSE
        mn$=ltrim$(str$(mn))
     END IF
     dy= dl AND (&h1f)
     IF dy < 10 THEN
        dy$="0"+ltrim$(str$(dy))
     ELSE
        dy$=ltrim$(str$(dy))
     END IF
     yr$=str$(RightShift(dl,9)+1980)
     wdate$=mn$+"/"+dy$+"/"+ltrim$(yr$)
 END FUNCTION

 FUNCTION wtime$(d%)
 DIM dl AS LONG
    dl=unsigned&(d%)
    hr=RightShift%(dl,11) AND (&h1f)
    IF hr < 10 THEN
       hr$="0"+ltrim$(str$(hr))
    ELSE
       hr$=ltrim$(str$(hr))
    END IF
    mt=(RightShift%(dl,5) AND (&h3f))
    IF mt < 10 THEN
       mt$="0"+ltrim$(str$(mt))
    ELSE
       mt$=ltrim$(str$(mt))
    END IF
    wtime$=ltrim$(hr$)+":"+mt$+string$(5,32)
 END FUNCTION

 FUNCTION FileType$(attr)
   SELECT CASE attr
      CASE 0
         FileType$="Normal File"
      CASE 1
         FileType$="Read-Only File"
      CASE 2
         FileType$="Hidden File"
      CASE 4
         FileType$="System File"
      CASE &h10
         FileType$="Subdirectory"
      CASE &h20
         FileType$="File Archive"
      CASE ELSE
         FileType$="Unknown Type"
   END SELECT
 END FUNCTION

 FUNCTION RightShift%(number&,amount)
    Rightshift=number&\2^amount
 END FUNCTION

 FUNCTION LeftShift%(number&,amount)
   LeftShift=number&*(2^amount)
 END FUNCTION

 FUNCTION unsigned&(num)
    IF num >=0 THEN
       unsigned&=num
    ELSE
       unsigned&=65536+num
    END IF
 END FUNCTION


 57. "Device Unavailable" Using Communications Port in Real Mode

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00B 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified: 26-FEB-1990    ArticleIdent: Q30855

 If a "Device Unavailable" message occurs when trying to do
 communications under real mode (the DOS 3.x compatibility box in
 OS/2), then setcom40 must be run. This process allows the program to
 access the COM port in real mode. Setcom40 sets the serial-port
 address before starting the real mode program.

 Real mode applications use the BIOS COM-port base addresses, which
 begin at 400H to determine the presence of serial ports. However, the
 OS/2 COM.SYS device driver fills these addresses with zeros to keep
 real mode programs from interfering with protected mode applications
 that might try to access the COM ports.

 Setcom40 sets the port base addresses to values that real mode
 applications will recognize.

 The following syntax writes the port address for COMx in the BIOS area
 of the disk, where x is the number of the serial port:

    setcom40 comx=on

 The following syntax removes the address from the BIOS area of the
 disk when the real mode application no longer requires it:

    setcom40 comx=off (where x is the number of the serial port)

 For more information, please refer to Page 190 in the "Microsoft
 Operating System/2 Beginning User's Guide" of the Microsoft OS/2 SDK
 (Software Development Kit) Version 1.00.


 58. Sample BASIC Program That Makes OS/2 Call to DosSearchPath

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35271

 Below is a sample program that makes a call to the MS OS/2 function
 DosSearchPath. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS OS/2.

 'This information is in the include File: BSEDOSPC.BI

 DECLARE FUNCTION DOSSEARCHPATH%(_
         BYVAL P1 AS INTEGER,_
         BYVAL P2o AS INTEGER,_
         BYVAL P2s AS INTEGER,_
         BYVAL P3o AS INTEGER,_
         BYVAL P3s AS INTEGER,_
         BYVAL P4o AS INTEGER,_
         BYVAL P4s AS INTEGER,_
         BYVAL P5 AS INTEGER)

 DEFINT a-z

 DIM Buffer   AS STRING*60
 CLS
 bufferlen=len(buffer)
 buffer=string$(bufferlen,32)

 PRINT " 0 - SEARCH DIRECTORY GIVEN AS PATH"
 PRINT " 1 - SEARCH DEFAULT THEN PATH"
 PRINT " 2 - SEARCH STRING OF DIRECTORIES"
 PRINT " 3 - SEARCH DEFAULT THEN DIRECTORIES IN ENVIRONMENT VARIABLE GIVEN"
 INPUT "Enter OPTION : ";opt
 INPUT "Enter the PATH : ";pathref$
 pathref$=pathref$+chr$(0)
 INPUT "Enter the FILENAME : ";flname$
 flname$=flname$+chr$(0)

 x=DosSearchPath%(opt,varseg(PathRef$),sadd(PathRef$),_
                  varseg(FlName$),sadd(FlName$),_
                  varseg(buffer),varptr(buffer),bufferlen)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    Print Buffer
 END IF
 end


 59. Missing Text: DECLARE Statement

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  2-FEB-1990    ArticleIdent: Q28962

 There is a documentation error on Page 43 of the "Microsoft BASIC
 Compiler 6.0: Programming in BASIC: Selected Topics" manual for
 Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS and MS
 OS/2. The last sentence of the first paragraph in the Note that
 appears in the center of the page is missing some text.

 The sentence should read as follows:

    A DECLARE statement ensures that only the correct number and type
    of arguments are passed to a procedure, and allows your program to
    call procedures defined in separate modules. See the "BASIC
    Language Reference" manual for more information on DECLARE.

 This documentation error was corrected in the documentation for
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2.


 60. LINK /PAC and /F Options Are Not Supported by BASIC Compiler

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q31881

 The /F (far call translation) and /PAC (packcode) options of LINK.EXE
 Version 5.01.20 should not be used with BASIC programs.

 The LINK section on Pages 276-278 of the "Microsoft CodeView and
 Utilities: Software Development Tools for MS-DOS" manual states that
 if the /F and /PAC options are used together, slightly faster code and
 smaller executable file size are generated.

 This process is performed by directing the linker to group together
 neighboring code segments and by optimizing far CALLs.

 However, this information does not apply to BASIC. When you link
 compiled BASIC routines with LINK /F/PAC, the executable .EXE file
 size remains the same as the .EXE file size when linked without these
 options, and speed is not increased.

 This information applies to the BC.EXE that comes with QuickBASIC
 Versions 4.00, 4.00b, and 4.50, to Microsoft BASIC Compiler Versions
 6.00 and 6.00b for MS-DOS and MS OS/2, and to Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2.


 61. Example of Using SetUEvent, ON UEVENT to Detect Mouse Presence

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified: 17-JAN-1991    ArticleIdent: Q31936

 The following example uses the SetUEvent routine and the ON UEVENT
 statement to trap a user-defined event. An event occurs in the sample
 program below if the Microsoft Mouse is not installed. The program
 traps the event if and when it occurs, and then prints a message.

 The user-defined event-trapping feature is found in QuickBASIC version
 4.00b, Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS,
 and Microsoft BASIC Professional Development System (PDS) versions
 7.00 and 7.10 for MS-DOS. The SetUEvent routine and the ON UEVENT
 statement are not found in QuickBASIC version 4.00 or earlier.

 For more information on the CALL INTERRUPT statement used in the code
 example below to call the Microsoft Mouse, query on the following
 words in this database:

    mouse and CALL and INTERRUPT

 INTERRUPT is an external routine located in QB.LIB on the QuickBASIC
 release disk.

 Code Example
 ------------

 DECLARE SUB mouse (m0, m1, m2, m3)
 ' change following line to include QBX.BI if in BASIC PDS 7.00/7.10
 REM $INCLUDE: 'QB.BI'

 ON UEVENT GOSUB handler
 UEVENT ON

 m0 = 0: CALL mouse(m0, m1, m2, m3)                 'Initialize the MOUSE
    IF NOT m0 THEN CALL SetUEvent    'If no Mouse installed print message
 '-------------- Other program code can be written here -----------------
 END
 handler:
    PRINT "No Mouse installed"
 END

 SUB mouse (m0, m1, m2, m3) STATIC         'Talks to the MOUSE.COM driver
 DIM inregs AS RegType: DIM outregs AS RegType
    inregs.ax = m0                                    'Load the registers
    inregs.bx = m1
    inregs.cx = m2
    inregs.dx = m3
    CALL INTERRUPT(51, inregs, outregs)   'Call the mouse driver interrupt
    m0 = outregs.ax
    m1 = outregs.bx                             'Return values from driver
    m2 = outregs.cx
    m3 = outregs.dx
 END SUB


 62. Two Ways to Pass Arrays in Compiled BASIC to Assembler Routine

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  8-AUG-1990    ArticleIdent: Q32216

 An array in a compiled BASIC program can be passed to an assembly
 language program in the two ways shown below. The array can be passed
 either through the CALL statement's parameter list or, for static
 arrays only, through a COMMON block.

 Microsoft does not support passing dynamic arrays through COMMON to
 assembler (since this depends upon a Microsoft proprietary dynamic
 array descriptor format that changes from version to version). Dynamic
 arrays can be passed to assembler only as parameters in the CALL
 statement.

 This information applies to the following products:

 1. Microsoft QuickBASIC Compiler versions 4.00, 4.00b, and 4.50

 2. Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS and
    MS OS/2

 3. Microsoft BASIC Professional Development System (PDS) versions 7.00
    and 7.10 for MS-DOS and MS OS/2

 For more information about passing other types of parameters between
 BASIC and MASM, search in the Software/Data Library for the following
 word:

    BAS2MASM

 The following information pertains to passing an array to an assembly
 routine through the CALL parameter list:

 If the array is passed through the parameter list, all the information
 about the array must be passed. This includes the length of each item,
 the number of items, and the segment and offset of the base element of
 the array. The first two items may be hardcoded into the assembler
 program, but the latter two must be passed because there is no way of
 knowing where the array will be located before the program starts. The
 following is an example:

    DECLARE SUB PutInfo (BYVAL Segment%, BYVAL Offset%)
    DIM a%(100)
    CALL PutInfo(VARSEG(a%(0)),VARPTR(a%(0)))

 The assembly-language program pulls the information off the stack,
 then continues with its purpose. Please note that this method works
 with both static and dynamic arrays.

 The following information pertains to passing an array to an assembly
 language routine through a COMMON block:

 Passing information through a COMMON block to an assembly language
 program is fairly simple. In the assembly language program, a segment
 is set up with the same name as the COMMON block and then grouped with
 DGROUP, as follows:

    BNAME segment 'BC_VARS'
      x  dw 1 dup (?)
      y  dw 1 dup (?)
      z  dw 1 dup (?)
    BNAME ends

   dgroup group BNAME

 The above assembler code matches the following BASIC code named COMMON
 block:

    DEFINT A-Z
    COMMON /BNAME/ x,y,z

 Passing arrays through the COMMON block is done in a similar fashion.
 However, only static arrays may be passed to assembler through COMMON.

 Note: This information does not apply to passing far
 variable-length-strings in BASIC PDS version 7.00 or 7.10. For
 information on accessing far variable-length-strings in BASIC PDS
 version 7.00 or 7.10, see Chapter 13, "Mixed-Language Programming with
 Far Strings," in the "Microsoft BASIC 7.0: Programmer's Guide" for
 versions 7.00 and 7.10.

 When static arrays are used, the entire array is stored in the COMMON
 block. Consider the following example:

 BASIC Program
 -------------

       DECLARE SUB PutInfo ()
       DIM b%(100)
       COMMON /BNAME/ a%, b%(), c%
       CALL PutInfo
       CLS
       PRINT a%, c%
       FOR i = 0 TO 100
        PRINT b%(i);
       NEXT i
       END

 Assembly Program
 -----------------

       ;Note, this program uses MASM version 5.x directives.

       .model Medium

        BNAME segment COMMON 'BC_VARS'
          a  dw 1 dup (?)
          b  db 202 dup (?)      ;Note that all the space for the
                                 ;array is set up
          c  dw 1 dup (?)
        BNAME ends

        dgroup group BNAME

        .code

             public PutInfo
        PutInfo      proc   far
             push   bp
             mov    bp,sp
             push   di

             inc    word ptr dgroup:a
             inc    word ptr dgroup:c

             mov    cx,101
             mov    di,offset dgroup:b

        repeat:
             mov    [di],cx
             add    di,2
             loop   repeat

             pop    di
             pop    bp
             ret
        PutInfo      endp
             end

 As noted in the assembly source, the space for the array must be set up
 in the COMMON segment.

 When dynamic arrays are used, the array is not placed in the COMMON
 block. Instead, a multibyte array descriptor is placed on the COMMON
 block. The dynamic array descriptor changes from version to version,
 and is not released by Microsoft -- it is considered Microsoft
 proprietary information.


 63. Using B_OnExit Across a CHAIN Hangs System; Compiled BASIC

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 B_QuickBas
 Last Modified: 17-JAN-1990    ArticleIdent: Q32217

 Chaining to and from programs that use B_OnExit causes the system to
 hang.

 Microsoft has confirmed this to be a problem in Microsoft QuickBASIC
 Versions 4.00 and 4.00b (buglist4.00, buglist4.00b), in Microsoft
 BASIC Compiler Version 6.00 and 6.00b for MS-DOS and MS OS/2, and in
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 Please note that the B_OnExit routine is documented on Pages 319-321
 of the "Microsoft QuickBASIC 4.0: Learning and Using" manual for
 Microsoft QuickBASIC Versions 4.00 and 4.00b (this is the same manual
 for Microsoft BASIC Compiler Versions 6.00 and 6.00b), and in the
 "Microsoft BASIC 7.0: Programmer's Guide" on Pages 474-475.

 The following steps reproduce the problem using source code provided
 farther below:

 1. Use the following software to reproduce the problem:

    a. Microsoft QuickBASIC Versions 4.00, 4.00b, Microsoft BASIC
       Compiler Version 6.00 or 6.00b, or Microsoft BASIC PDS Version
       7.00.

    b. Microsoft C Compiler Version 5.10

 2. Type the following command lines:

       BC BUGTEST.BAS;
       BC BUGNEXT.BAS;
       CL /c /AM BUGC.C
       LINK /NOE BUGTEST+BUGC;
       LINK /NOE BUGNEXT+BUGC;

 3. Run BUGTEST.EXE from the DOS prompt.

 4. At the "CHAIN Y/N?" prompt, type Y.

 The system locks up when BUGNEXT exits.

 Please note the following:

 1. You must link BUGC.OBJ with BUGNEXT.OBJ even though it is not
    called.

 2. Both programs apparently run correctly until you exit BUGNEXT.

 Code Example
 ------------

 'BUGTEST.BAS

         DECLARE SUB IntProc CDECL
         DEFINT A-Z
         PRINT "[***** ENTRY TO MAIN  *****]"
         CALL InProc
         INPUT "CHAIN Y/N";T$
         IF T$="Y" OR T$="y" THEN
            CHAIN "BUGNEXT.EXE"
         END IF
         SYSTEM
         END

 'BUGNEXT.BAS

         DEFINT A-Z
         PRINT "[***** CHAIN *****]"
         SYSTEM
         END

 /* BUGC.C */

 #include <malloc.h>
 extern pascal far B_OnExit();  /* Declare the routine */

 void IntProc()
 {
   void TermProc();             /* Declare TermProc routine */
   printf ("\nIn the C IntProc routine\n");
   B_OnExit(TermProc);          /* Log termination routine with BASIC */
 }

 void TermProc()                         /* The TermProc function is */
 {                                       /* called before any restarting */
   printf ("\nIn C TermProc routine\n"); /* or termination of the program. */
 }


 64. DosGetPid and DosGetInfoSeg Get Process Identification (PID)

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q32219

 Two MS OS/2 API calls return the process identification (PID) of the
 current process. The two calls are DosGetPid and DosGetInfoSeg, which
 are illustrated in a code example below.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2, and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 DosGetPid is the simplest and most direct way of retrieving the
 current PID. This function is passed the address of a structure
 containing three integers or words. The function declarations are as
 follows:

       TYPE PidInfo
            Pid as integer        'Process Pid
            Tid as integer        'Thread Pid
            pidParent as integer 'Parent Pid
       END TYPE

       DECLARE FUNCTION DosGetPid%(_
                    SEG P1 AS PidInfo)

 The PID information is returned in the structure.

 The information returned by DosGetInfoSeg also helps find the PID, but
 the procedure is more difficult. This function returns the address of
 both the GDT and LDT. The LDT contains the process information. To
 locate the PID, you must set the segment to the LDT (DEF SEG=address
 of LDT), then look at the bytes that contain the desired information.
 The program below demonstrates this method. (This program also
 contains an example of DosGetPid.)

        'Declarations used below can be found in BSDOSPC.BI
        TYPE PidInfo
             Pid as integer
             Tid as integer
             pidParent as integer
        END TYPE
        DECLARE FUNCTION DosGetInfoSeg%(_
                     SEG P1 AS INTEGER,_
                     SEG P2 AS INTEGER)
        DECLARE FUNCTION DosGetPid%(_
                     SEG P1 AS PidInfo)

        DEFINT A-Z
        CLS
        DIM info AS PidInfo

        x=DosGetInfoSeg%(global,localo)

        IF (x) THEN
          Print "Error, the number is : ";x
        ELSE
          Print "The Global Segment : ";Global
          Print "The Local Segment : ";localo
          def seg=localo            'Change Segment
          pid1=peek(0)+(256*(peek(1))) 'First Word in segment
          pid2=peek(2)+(256*(peek(3))) 'Second Word
          pid3=peek(6)+(256*(peek(7))) 'Fourth Word
          def seg
          print "         Current Process ID : ";pid1
          print "       Process ID of Parent : ";pid2
          print "Thread ID of Current Thread : ";pid3
        END IF

        x=DosGetPid%(info)

        IF (x) THEN
          Print "Error, the number is : ";x
        ELSE
          print "         Current Process ID : ";info.pid
          print "       Process ID of Parent : ";info.pidParent
          print "Thread ID of Current Thread : ";info.tid
        END IF


 65. Cannot Use Alternate Math Library Without Compiling BC /FPa

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q32415

 The alternate math libraries should not be used without compiling with
 the BC /FPa switch; otherwise, unpredictable results may occur.

 The following alternate math libraries can be used in MS OS/2
 protected mode:

    BC 6.00           BC 6.00b         PDS 7.00
    -------           --------         --------

    BRUN60AP.DLL      BRUN61AP.DLL     BRT70ANP.DLL
    BCOM60AP.LIB      BCOM61AP.LIB     BRT70ANP.LIB
                                       BRT70AFP.DLL
                                       BRT70AFP.LIB

 The following alternate math libraries can be used in MS-DOS or MS
 OS/2 real mode:

    BC 6.00           BC 6.00b         PDS 7.00
    -------           --------         --------

    BRUN60AR.EXE      BRUN61AP.EXE     BRT70ANR.EXE
    BCOM60AR.LIB      BRUN61AP.LIB     BRT70ANR.LIB
                                       BRT70AFR.EXE
                                       BRT70AFR.LIB

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2 and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.


 66. Linker Module-Definition Files for MS OS/2 or Windows

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q33137

 A module-definition file, used by LINK.EXE, describes the name,
 attributes, exports, imports, and other characteristics of an
 application or library for MS OS/2 (or Microsoft Windows). This file
 is required for dynamic link libraries (DLLs) that run under MS OS/2
 (and for Microsoft Windows applications and libraries).

 Note that Microsoft BASIC Compiler Versions 6.00 and 6.00b and
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 cannot make Microsoft Windows applications or libraries. These
 products can only make OS/2 applications.

 For more information about the module-definition file used by LINK,
 see Page Update 39 in the "Microsoft CodeView and Utilities: Software
 Development Tools for MS OS/2 and MS-DOS: Update" manual.

 For more information about BASIC compatibility with Microsoft Windows,
 search for a separate article with the following words:

    Windows and SDK and BASIC and compiler


 67. 7.00 Problem Passing Near Fixed String to Recursive FUNCTION

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q58409

 The problem described below is so rare that it will not be encountered
 by most readers.

 When passing a fixed-length string variable as a variable-length
 string parameter to a recursive FUNCTION procedure in the program
 below, the fixed-length string variable is nulled (reduced to "") when
 the FUNCTION procedure returns if you compiled with BC.EXE using near
 strings. Renaming the FUNCTION procedure eliminates this problem.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) version 7.00 for MS-DOS and MS
 OS/2. This problem was corrected in BASIC PDS version 7.10.

 Note that this problem occurs only if the original variable is a
 fixed-length string and you are executing from a program compiled to
 use near strings. If the original variable is a variable-length string
 or the program uses far strings (either in the QBX.EXE environment or
 in a compiled program), this error does not occur.

 The program below demonstrates the error. To reproduce the problem,
 compile and link the program using Microsoft BASIC PDS 7.00 as
 follows:

    BC /o Recfun.bas;
    LINK Recfun.bas;

 Executing the program below shows that the string variable "parm1" is
 nulled after the return from the recursive function call to "CTRL".

 To work around the problem, do one of the following:

 1. Add the /Fs (far strings) option to the compile line.

 2. Rename the CTRL FUNCTION procedure to FUN2 (or some other name).

 3. Change the DIM statement for "original" to read as follows:

       DIM original AS STRING

 Code Example
 ------------

 The following program, RECFUN.BAS, shows the problem:

    DECLARE FUNCTION Fun1% (parm1 AS STRING)
    DECLARE FUNCTION ctrl% (parm1 AS STRING, parm2 AS STRING)
    CONST CASEONE = "1"
    CONST CASETWO = "2"
    DIM original AS STRING * 3   'Remove "* 3" to work around problem.
    CLS
    original = "ooo"
    retval% = Fun1%(original)
    END

    FUNCTION ctrl% (parm1 AS STRING, parm2 AS STRING)
      DIM retval       AS INTEGER
      IF parm2 = CASEONE THEN
        PRINT "Caseone: parm1=["; parm1; "]": SLEEP 1
      ELSE
        PRINT "Case two:"
        PRINT "before recursion:  parm1=["; parm1; "]": SLEEP 1
        retval = ctrl%(parm1, CASEONE)
        PRINT "after recursion :  parm1=["; parm1; "]": SLEEP 1
      END IF
    END FUNCTION

    FUNCTION Fun1% (parm1 AS STRING)
      DIM retval         AS INTEGER
      retval = ctrl%(parm1, CASETWO)
    END FUNCTION

 Workaround
 ----------

 To work around the problem, rename CTRL to FUN2 as follows:

    DECLARE FUNCTION Fun1% (parm1 AS STRING)
    DECLARE FUNCTION fun2% (parm1 AS STRING, parm2 AS STRING)
    CONST CASEONE = "1"
    CONST CASETWO = "2"
    DIM original AS STRING * 3   'Remove "* 3" to make it work
    CLS
    original = "ooo"
    retval% = Fun1%(original)
    END

    FUNCTION Fun1% (parm1 AS STRING)
      DIM retval         AS INTEGER
      retval = fun2%(parm1, CASETWO)
    END FUNCTION

    FUNCTION fun2% (parm1 AS STRING, parm2 AS STRING)
      DIM retval       AS INTEGER
      IF parm2 = CASEONE THEN
        PRINT "Caseone: parm1=["; parm1; "]": SLEEP 1
      ELSE
        PRINT "Case two:"
        PRINT "before recursion:  parm1=["; parm1; "]": SLEEP 1
        retval = fun2%(parm1, CASEONE)
        PRINT "after recursion :  parm1=["; parm1; "]": SLEEP 1
      END IF
    END FUNCTION


 68. Example to Load OS/2 Disk Directory into String Array

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q33178

 This article discusses two methods to put a disk directory listing
 into a string array under OS/2 protected mode. (Note: This article was
 written because the FILES statement in BASIC only outputs to the
 screen, not to a file or to string variables.)

 Example 1 shows a simple method to SHELL to the DIR command, redirect
 the output to a file, and input from the file into string variables.
 (Example 1 also works correctly in MS-DOS.)

 Example 2 shows how to invoke OS/2 API functions (DosFindFirst and
 DosFindNext) to retrieve a disk directory into string variables.

 This article applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2 and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 Note: In Microsoft BASIC PDS 7.00, the DIR$ function can be used to
 accomplish the same thing as these two routines show. The use of DIR$
 is documented on Page 107 of the "Microsoft BASIC 7.0: Language
 Reference" manual.

 For an article about how to invoke MS-DOS (or OS/2 real mode)
 functions to accomplish the same thing, query in this Knowledge Base
 on the following keywords:

    INTERRUPT and FINDFIRST and FINDNEXT

 In MS OS/2 protected mode, you can use the API CALLs DosFindFirst and
 DosFindNext to retrieve a disk directory listing and load it into a
 string array, as shown in Example 2 below. Example 2 does NOT apply to
 QuickBASIC Versions 4.50 and earlier because they cannot compile
 programs for OS/2 protected mode.

 Example 1 (the simplest technique) is as follows:

 ' Works in QuickBASIC 2.00, 2.01, 3.00, 4.00, 4.00b, 4.50, and
 ' BASIC compiler 6.00 and 6.00b.
 nf = 200   ' Handles directory listing up to 200 lines.
 DIM buffer$(nf)
 INPUT "Enter Search Path: ", path$   ' Enter path such as c:
 SHELLSTRING$ = "dir " + path$ + " >dirfile.dat"
 SHELL SHELLSTRING$   ' SHELL to the MS-DOS DIRectory command.
 OPEN "dirfile.dat" FOR INPUT AS #1
 pntr% = 0
 WHILE NOT EOF(1) AND pntr% < nf
   pntr% = pntr% + 1
   INPUT #1, buffer$(pntr%)  ' Inputs one directory line at a time.
   PRINT buffer$(pntr%)
 WEND
 CLOSE #1
 KILL "dirfile.dat"
 END

 Example 2 is as follows:

 The following sample program is for MS OS/2 protected mode (to be
 compiled only in BASIC compiler Version 6.00 or 6.00b in MS OS/2
 protected mode or BASIC PDS Version 7.00 in MS OS/2 protected mode):

 'The TYPE below is taken from the following include file: BSEDOSFL.BI
 TYPE FILEFINDBUF
         fdateCreation   AS INTEGER
         ftimeCreation   AS INTEGER
         fdateLastAccess AS INTEGER
         ftimeLastAccess AS INTEGER
         fdateLastWrite  AS INTEGER
         ftimeLastWrite  AS INTEGER
         cbFile          AS LONG
         cbFileAlloc     AS LONG
         attrFile        AS INTEGER
         cchName         AS STRING * 1
         achName         AS STRING * 13
 END TYPE

 DECLARE FUNCTION DosFindFirst%( _
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER,_
         SEG   P2  AS INTEGER,_
         BYVAL P3  AS INTEGER,_
         SEG   P4  AS FILEFINDBUF,_
         BYVAL P5  AS INTEGER,_
         SEG   P6  AS INTEGER,_
         BYVAL P7  AS LONG)

 DECLARE FUNCTION DosFindNext%( _
         BYVAL P1 AS INTEGER,_
         SEG   P2 AS FILEFINDBUF,_
         BYVAL P3 AS INTEGER,_
         SEG   P4 AS INTEGER)

 DEFINT a-z

 DIM buffer AS FileFindBuf
 DIM filelist(255) as string*13
 DIM reserved  AS LONG

 CLS

 INPUT "Enter the Filename(s) : ";flname$
 flname$=flname$+chr$(0)

 atr= 0+2+4+16    'normal + hidden + system + subdirectory
 dirh=1
 searchcount=1
 bufflen=36
 x=DosFindFirst%(varseg(flname$),sadd(flname$),_
                 dirh,atr,buffer,bufflen,searchcount,reserved)
 IF (X=0) THEN
    DO
      counter=counter+1
      filelist(counter)=buffer.achName
      buffer.achName=string$(13,32)  'assign blanks
    LOOP WHILE (DosFindNext%(dirh,buffer,bufflen,searchcount) = 0 )
 ELSE
     PRINT "No MATCH was found"
     END
 END IF

 for i = 1 to counter
     print filelist(i)
 next i

 END


 69. Sample Program That Makes OS/2 Call to DosQCurDisk Function

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q35273

 Below is a sample program that makes a call to the MS OS/2 function
 DosQCurDisk. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and in Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 'The declarations are in BSEDOSFL.BI

 DECLARE FUNCTION DosQCurDisk%(_
                  SEG P1 AS INTEGER,_
                  SEG P2 AS LONG)

 DIM number AS INTEGER
 DIM LogicalDriveMap AS LONG

 x=DosQCurDisk%(number,LogicalDriveMap)
 if (x) then
     print "An error occurred.  The number is : ";number
 else
     print "Logical Drive Map; ";LogicalDriveMap
 end if
 end


 70. Sample Program That Makes MS OS/2 Call to DosSleep Function

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q35274

 Below is a sample program that makes a call to the MS OS/2 function
 DosSleep. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and in Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 'The declaration is in BSEDOSPC.BI
 DECLARE FUNCTION DOSSLEEP%(BYVAL P1 AS LONG)

 DIM a AS LONG

 INPUT "Enter the amount of time to SLEEP (in seconds) :";longer

 longer=longer*1000

 x=timer
 y=DosSleep%(longer)
 z=timer

 IF (y) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   Print "The amount of time you slept is : ";z-x
 END IF
 end


 71. Sample Program That Makes MS OS/2 Call to DosScanEnv Function

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q35275

 Below is a sample program that makes a call to the MS OS/2 function
 DosScanEnv. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS OS/2.

 'The declarations are in BSEDOSPC.BI
 TYPE address
      offset AS INTEGER
      segment AS INTEGER
 END TYPE

 DECLARE FUNCTION DOSSCANENV%(_
         BYVAL P1s AS INTEGER,_
         BYVAL P1o AS INTEGER,_
         SEG P2 AS Address)

 DEFINT a-z
 DIM info AS address

 INPUT "Enter the item to be searched for in the Environment Table : ";item$
 item$=ucase$(item$)+chr$(0)

 x=DosScanEnv%(varseg(item$),sadd(item$),info)

 IF (x) THEN
    print "An error occurred.  The error number is ";x
 ELSE
    counter=0
    def seg = info.segment
    do
      c$=chr$(peek(info.offset+counter))
      result$=result$+c$
      counter=counter+1
    loop while c$<>chr$(0)
    print item$;" = ";result$
 END IF
 END


 72. Sample Program That Makes MS OS/2 Call to DosPhysicalDisk

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35276

 Below is a sample program that makes a call to the MS OS/2 function
 DosPhysicalDisk. This program can be compiled in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 'The declaration is in BSEDOSFL.BI

 DECLARE FUNCTION DOSPHYSICALDISK%(_
         BYVAL P1 AS INTEGER,_
         BYVAL P2s AS integer,_
         BYVAL P2o AS integer,_
         BYVAL P3 AS INTEGER,_
         BYVAL P4s AS INTEGER,_
         BYVAL P4o AS INTEGER,_
         BYVAL P5 AS INTEGER)

 DEFINT a-z
 DIM DataPtr AS LONG
 DIM ParmLength AS INTEGER
 DIM DataBuff AS STRING*2
 DIM ParmBuff AS STRING*3

 databuff="**"

 func = 1
 DataLength = 2
 ParmLength = 0

 x=DosPhysicalDisk%(func,varseg(DataBuff),varptr(DataBuff),datalength,_
                    0,0,parmlength)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "Number partitionable drives: ";
    PRINT asc(mid$(databuff,1,1));asc(mid$(databuff,2,2))
 END IF

 func = 2
 DataLength = 2
 ParmLength = 3
 ParmBuff="1:"+chr$(0)
 x=DosPhysicalDisk%(func,varseg(DataBuff),varptr(DataBuff),datalength,_
                    varseg(Parmbuff),varptr(ParmBuff),parmlength)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    PRINT "Handle: ";
    PRINT asc(mid$(databuff,1,1));asc(mid$(databuff,2,2))
 END IF
 END


 73. Sample Program That Makes MS OS/2 Call to DosDelete Function

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35277

 Below is a sample program that makes a call to the MS OS/2 function
 DosDelete. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS OS/2.

 'The declaration is in BSEDOSFL.BI
 DECLARE FUNCTION DOSDELETE%(_
                  BYVAL P1o AS INTEGER,_
                  BYVAL P1s AS INTEGER,_
                  BYVAL P2 AS LONG)

 DEFINT A-Z
 DIM reserved AS LONG

 INPUT "Enter the file to be deleted : ";fl$
 fl$=fl$+chr$(0)

 x=DosDelete%(varseg(fl$),sadd(fl$),reserved)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   Print fl$; "was DELETED"
 END IF
 end


 74. Sample Program That Makes MS OS/2 Call to DosBeep Function

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35278

 Below is a sample program that makes a call to the MS OS/2 function
 DosBeep. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00.

 REM $INCLUDE: 'bsedospc.bi'
 DEFINT a-z
 PRINT "Test of DOSBEEP..."
 i = &H25
 WHILE ((INKEY$ = "") and (i < &H7EFF))
    i = i + &H100
    x = DOSBEEP(i, 400)
 WEND


 75. Sample Program That Makes MS OS/2 Call to DosQFileMode

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q35279

 Below is a sample program that makes a call to the MS OS/2 function
 DosQfileMode. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00.

 'The declaration is in BSEDOSFL.BI
 DECLARE FUNCTION DOSQFILEMODE%(_
                  BYVAL P1s AS INTEGER,_
                  BYVAL P1o AS INTEGER,_
                  SEG P2 AS INTEGER,_
                  BYVAL P3 AS LONG)
 DIM c AS LONG
 INPUT "Enter the Filename : ";flname$
 flname$=flname$+chr$(0)
 x=dosqfilemode%(varseg(flname$),sadd(flname$),attr%,c)
 IF (x) then
    print "An error has occurred.  The error number is ";x
 else
   print "Attribute Number is ";hex$(attr%)
 end if


 76. LINK "Symbol Defined More Than Once" Mixing Math Packages

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q37342

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2 and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 You can pass variables between BASIC and other languages that have the
 alternate math package if each of the modules is compiled using that
 option. The error message L2025, "symbol defined more than once",
 results from any attempt to link modules that were compiled using
 different math package options.

 The code example below, which shows a BASIC program calling a C
 function, should be compiled and linked using the following syntax:

    bc cf.bas /FPa [other optional switches are OK];
    cl /AM /Gs /FPa /c cfunc.c
    link cf+cfunc /noe;

 The alternate math package is not available in QuickBASIC, or in
 versions of the BASIC compiler earlier than Version 6.00.

 The following is sample code:

 ' BASIC PROGRAM CF.BAS:
 DECLARE function cfunc# CDECL (byval x AS double)
 input "enter a floating point number ";x#
 print x#;" * 2 = ";cfunc(x#)

 /*   C FUNCTION CFUNC.C:   */
    double  cfunc(double value)
    {
       return  (value * 2);
    }


 77. Sample BASIC 6.00/7.00 Program to CALL OS/2 Mouse Functions

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | O_OS2API O_OS2SDK
 Last Modified: 26-MAR-1990    ArticleIdent: Q37410

 Below is a sample program that calls the following MS OS/2 API
 function calls for accessing the mouse in MS OS/2 protected mode:

    MouReadEventQue
    MouSetEventMask
    MouOpen
    MouRemovePtr
    MouDrawPtr

 This program can be compiled in MS OS/2 protected mode in Microsoft
 BASIC Compiler Version 6.00 or 6.00b for MS OS/2 and in Microsoft
 BASIC Professional Development System (PDS) Version 7.00 for MS OS/2.

 Code Example
 ------------

 ' Summary of Program:
 '
 ' The following program loops until any key is pressed.
 ' As the mouse is moved, a "smiley" face is displayed.
 ' Pressing the left mouse button causes the face to
 ' change colors. The colors are random.
 ' Pressing the right mouse button causes the screen to
 ' clear and be the same color as the last face.
 '
 ' The following is taken from BSESUBMO.BI
 ' OS/2 Subroutine Include File - Mouse Support
 ' Copyright (c) 1987,1988 Microsoft Corporation

 TYPE MOUEVENTINFO
       fs        AS INTEGER
       Time      AS LONG
       row       AS INTEGER
       col       AS INTEGER
 END TYPE

 TYPE NOPTRRECT
       row       AS INTEGER
       col       AS INTEGER
       cRow      AS INTEGER
       cCol      AS INTEGER
 END TYPE

 TYPE PTRSHAPE
       cb        AS INTEGER
       col       AS INTEGER
       row       AS INTEGER
       colHot    AS INTEGER
       rowHot    AS INTEGER
 END TYPE

 DECLARE FUNCTION MouReadEventQue%( _
       SEG   P1 AS MOUEVENTINFO,_
       SEG   P2 AS INTEGER,_
       BYVAL P3 AS INTEGER)

 DECLARE FUNCTION MouSetEventMask%( _
       SEG   P1 AS INTEGER,_
       BYVAL P2 AS INTEGER)

 DECLARE FUNCTION MouOpen%( _
       BYVAL P1s AS INTEGER,_
       BYVAL P1o AS INTEGER,_
       SEG   P2 AS INTEGER)

 DECLARE FUNCTION MouClose%( _
       BYVAL P1 AS INTEGER)

 DECLARE FUNCTION MouRemovePtr%( _
       SEG   P1 AS NOPTRRECT,_
       BYVAL P2 AS INTEGER)

 DECLARE FUNCTION MouDrawPtr%( _
       BYVAL P1 AS INTEGER)

 DEFINT a-z
 DIM MouEvent as MOUEVENTINFO
 DIM Pointer as PTRSHAPE
 CLS
  x=MouOpen(0,0,hMouse) 'OPEN MOUSE DRIVER
  IF x THEN
     PRINT "*** Unable to load Mouse Driver ***"
     END
  ELSE
     x=MouDrawPtr(hMouse)  'Draw the mouse
     mask=&h001F '(2 buttons 1F)
     x=MouSetEventMask(mask,hMouse)
     ReadType=0
     while inkey$=""
        x=MouReadEventQue(MouEvent,ReadType,hMouse)
        'Structure is all zeros if no event
        IF (MouEvent.time<>0) THEN
           IF (MouEvent.fs AND &h0004) THEN  'left button
              y=INT(16 * RND)
              color ,y
           END IF

           IF (MouEvent.fs AND &h0010) THEN  'right button
              CLS
           END IF
              CALL HideMouse(MouEvent.Row,MouEvent.Row,MouEvent.Col,_
                             MouEvent.col,hMouse)
              locate MouEvent.row+1,MouEvent.col+1 : print chr$(1);
        END IF
     WEND
  END IF

 SUB HideMouse(a,b,c,d,driver) STATIC
 DIM NoMouse  as NoPtrRect
    NoMouse.row=a
    NoMouse.cRow=b
    NoMouse.col=c
    NoMouse.cCol=d
    x=MouRemovePtr(NoMouse,driver)
 END SUB


 78. BSEDOSPC.BI Is Missing DosSetSigHandler Definition; for OS/2

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q37420

 The include file BSEDOSPC.BI fails to include the definition for
 DosSetSigHandler. It should be defined as follows:

    DECLARE FUNCTION DosSetSigHandler%( _
            BYVAL P1seg AS INTEGER,_
            BYVAL P1offset AS INTEGER,_
            SEG   P2 AS LONG,_
            SEG   P3 AS INTEGER,_
            BYVAL P4 AS INTEGER,_
            BYVAL P5 AS INTEGER)

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development System
 (PDS) Versions 7.00 and 7.10 for MS OS/2.


 79. Sample Program That Makes OS/2 Function Call DosMove

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q37426

 Below is a sample program that makes a call to the MS OS/2 function
 DosMove. This program can be compiled in Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS OS/2.

 The sample program is as follows:

 ' This definition is from the include file BSEDOSFL.BI
 DECLARE FUNCTION DosMove%(_
                  BYVAL P1S AS INTEGER,_
                  BYVAL P1O AS INTEGER,_
                  BYVAL P2S AS INTEGER,_
                  BYVAL P2O AS INTEGER,_
                  BYVAL P3 AS LONG)

 DIM reserved AS LONG

 INPUT "Enter the ORIGINAL filename : ";f1$
 INPUT "Enter the NEW filename : ";f2$

 f1$=f1$+chr$(0)
 f2$=f2$+chr$(0)

 x=DosMove%(varseg(f1$),sadd(f1$),varseg(f2$),sadd(f2$),reserved)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   Print UCASE$(f1$)" ===> " UCASE$(f2$)
 END IF
 END


 80. Sample Program That Makes OS/2 Function Call DosSelectDisk

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q37427

 Below is a sample program that makes a call to the MS OS/2 function
 DosSelectDisk. This program can be compiled in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 The sample program is as follows:

 ' This definition is from the include file BSEDOSFL.BI
 DECLARE FUNCTION DosSelectDisk%(BYVAL P1 AS INTEGER)

 DIM number AS INTEGER
 INPUT "Enter disk number (A - &H0001, B - &H0002, etc.): ";number
 x=DosSelectDisk%(number)
 IF (x) THEN
     Print "DosSelectDisk returned an error ";x
 ELSE
     shell "dir"
     print "Hit any key to continue..."
     while inkey$="" : wend
 END IF
 END


 81. READ/DATA Statement Slower in QB 4.00 & BC 6.00 Than QB 3.00

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# G881102-5637 B_QuickBas
 Last Modified:  1-FEB-1990    ArticleIdent: Q37768

 The following are two reasons why READ/DATA statements are slower in
 Microsoft BASIC Compiler Versions 6.00 and 6.00b, Microsoft BASIC
 Professional Development System (PDS) Version 7.00, and QuickBASIC
 Versions 4.00, 4.00b, and 4.50 than in the noncoprocessor version of
 QuickBASIC Version 3.00:

 1. Math Package

    The noncoprocessor version of QuickBASIC Version 3.00 (QB.EXE) uses
    Microsoft Binary Format (MBF) for floating-point numbers, while
    QuickBASIC Versions 4.x, Microsoft BASIC PDS, and the BASIC
    compiler Versions 6.00 and 6.00b use IEEE. If a math coprocessor is
    not present, the later compilers emulate one and, thus, are slower
    than the noncoprocessor version of QuickBASIC 3.00.

    To increase its speed without a coprocessor, the BASIC compiler
    Versions 6.00 and 6.00b and Microsoft BASIC PDS Version 7.00
    provide support for the alternate math library. Alternate math is a
    subset of IEEE and is 40 to 50 percent faster than emulating a math
    coprocessor (but is still slower than MBF). To use alternate math,
    compile with the BC /FPa switch. Note that the alternate math
    library is not supported in Microsoft QuickBASIC Compiler Versions
    1.00, 1.01, 1.02, 2.00, 2.01, 3.00, 4.00, 4.00b, or 4.50.

 2. Microsoft rewrote the code for READ and DATA statements to support
    both the QB.EXE 4.00, 4.00b, and 4.50 environment and separate
    compilation in the BC.EXE BASIC compiler. QuickBASIC 3.00 is highly
    dependent upon a particular format and location for DATA
    statements. In QuickBASIC 4.00 and later, and in the QuickBASIC
    extended environment included with Microsoft BASIC PDS Version
    7.00, the support is generalized to allow for DATA statements in
    Quick libraries.


 82. Using Run-Time Module, RUN Makes Program Lose 70K Memory

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10 B_QuickBas
 Last Modified: 20-SEP-1990    ArticleIdent: Q37769

 When a program compiled without the /O option executes the RUN
 statement to run a second program, the run-time module (BRUNxx.EXE or
 BRTMxx.EXE) is unloaded from memory. However, the 70K of space for the
 run-time module fragments memory, and approximately 70K of RAM is
 unavailable to the program run with the RUN statement. When the second
 program quits or transfers control, the 70K of memory is available
 again.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Compiler versions 6.00 and 6.00b for MS-DOS, Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS, and Microsoft QuickBASIC Compiler versions 4.00, 4.00b, and
 4.50 (buglist4.00, buglist4.00b, buglist4.50) for MS-DOS. We are
 researching this problem and will post new information here as it
 becomes available. This problem doesn't occur in QuickBASIC version
 3.00.

 This temporary fragmentation of memory can contribute towards causing
 any one of the following errors when attempting to RUN another .EXE
 program: "Out of Memory," "Error R6005," or the MS-DOS message "Not
 enough memory to Exec."

 To work around this problem, you can make the program that uses the
 run-time module RUN another BASIC program compiled with the BC /O
 (stand-alone) option, which in turn can RUN the desired .EXE program.

 If the first BASIC program is compiled with the BC /O (stand-alone)
 option, all but 200 bytes are available after the RUN statement. In
 this case, the 200 missing bytes are the expected overhead associated
 with the RUN statement.

 The following are two different examples (1 and 2) that duplicate the
 problem:

 1. To duplicate the problem, do the following:

    a. Compile the following program WITHOUT the BC /O (stand-alone)
       option:

          ' TEST1.BAS
          PRINT FRE(-1)
          RUN "TEST2"

    b. Compile the following program WITH the BC /O (stand-alone)
       option:

          ' TEST2.BAS
          PRINT FRE(-1)

    c. Run TEST1.EXE. The following is sample output:

          439432  (from TEST1)
          429432  (from TEST2)

    d. Run TEST2.EXE alone. The following is sample output:

          500232  (from TEST2)

       There is about 70K more far heap available for TEST2 when it is
       run alone compared to when it is run from a BASIC program using
       the BRUNxx.EXE module.

 2. The problem was originally reported using the RUN statement to
    execute a Microsoft C .EXE program.

    To duplicate this problem, compile (without /O) and run the BASIC
    program below, which RUNs a Microsoft C program. The C routine
    prints the approximate amount of memory free. When the BASIC
    routine is compiled with the run-time module, about 70K is lost.

    If you RUN the C program from the BASIC routine compiled with /O
    and then compare with running the C program from MS-DOS, the memory
    numbers are within 200 bytes of one another.

    The following BASIC routine RUNS the C routine:

       RUN "memtest.exe"

    The following Microsoft C routine prints available memory:

 /*   memtest.c   */
 #include <dos.h>
 #include <malloc.h>
 #include <stdio.h>
 long l;
 unsigned int j,pp;
 main()
 {
 union REGS inregs, outregs;
 inregs.h.ah=0x48;
 inregs.x.bx=0xffff;
 intdos(&inregs,&outregs);
 l=(long)(outregs.x.bx * 16L); /*amount available from far heap*/
 j=_memavl();/*calculate approximate amount available from near heap*/
 printf("approximate # of bytes available for allocation %ld\n",l+j);
 }


 83. "Program Memory Overflow": Break into SUBprograms

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# G881028-5376 B_QuickBas
 Last Modified: 10-AUG-1990    ArticleIdent: Q37770

 The code generated by BC.EXE in Microsoft BASIC Compiler versions 6.00
 and 6.00b, Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10, and QuickBASIC versions 4.00, 4.00b, and 4.50
 may be larger (on disk or in run-time memory) than that compiled with
 previous versions. With the increase in product features, the program
 size has grown. Therefore, it is possible that your program will no
 longer compile and will give a "Program Memory Overflow" error. This
 error can be avoided by breaking the program into smaller, separately
 compiled subprograms or FUNCTION procedures.

 At compile time, the BC.EXE compiler options can make a big difference
 in object file size. The /D (debug), /E (error handling with RESUME
 label), and /V (event handling between statements) compiler options
 generate the largest amount of code. The /X (error handling with
 RESUME NEXT, RESUME, and RESUME 0) and /W (event handling between
 lines) options generate less code than /E and /V; however, /X and /W
 still generate a fair amount of code.

 If you find that even with a careful choice of compiler options the
 program is still too big to compile, the program should be broken up
 into smaller modules that can be linked together.

 Each module can contain up to 64K in code and share a 64K data segment
 with the other modules. For code to be placed into its own module, it
 must be a subprogram or FUNCTION procedure. A subprogram procedure is
 surrounded by the SUB and END SUB statements. A FUNCTION procedure is
 surrounded by the FUNCTION and END FUNCTION statements. For more
 information about the memory the compiler uses and how to determine
 segment sizes for code and data, query in this Knowledge Base for the
 following words:

    determining and segment and sizes and LINK and /Map

 Also, if a program works in the QuickBASIC environment, BC.EXE usually
 compiles it to an executable program. However, there are two
 exceptions. If the program contains a large $INCLUDE file with RESUME
 and RESUME NEXT in it, the BC.EXE compiler may fail. The BC.EXE
 compiler builds a table of line numbers for RESUME/RESUME NEXT
 statements at 4 bytes each so it can tell where to resume back to.
 This adds additional code to the program and causes memory depletion.
 The QB.EXE interpreter does not have to keep the table, so less code
 is generated.

 To work around this situation, you can do the following two things:

 1. Use RESUME <label> instead of RESUME NEXT. Note that RESUME <label>
    should only be used to return to the same procedure level as where
    the error occurred, or else stack space will be consumed without
    being released, which can result in an "Out of stack space" error.
    For example, if an error occurs in a SUB procedure that is handled
    by an error handler in the main level code that performs RESUME
    <label> to a label in the main level code, then return addresses
    for the SUB remain unused on the stack and unavailable to the
    program.

 2. Break the program into smaller separate modules.

 If you have a large number of static numeric arrays, the BC.EXE
 compiler can run out of memory. In the QuickBASIC QB.EXE or QBX.EXE
 environment, static numeric arrays are not stored in the DGROUP data
 segment; they are stored in an additional segment. When the program is
 compiled with BC.EXE, these arrays are placed into the DGROUP data
 segment. This segment is limited to 64K. One way to work around this
 segment limitation is to make the static arrays dynamic to put them in
 the far heap.

 Dynamic non-variable-length-string arrays are stored on the far heap
 and not in the DGROUP data segment. There are three different ways to
 make an array dynamic, as follows:

 1. Use the REM $DYNAMIC metacommand to make all arrays dynamic.

 2. Use a variable as the number of elements in the DIM statement, as
    in the following example:

       x=20
       DIM array(x)

 3. Place the array in COMMON and dimension the array after the COMMON
    statement:

       COMMON SHARED array()
       DIM array(100)

 Once the program compiles, there are a few things that can be done to
 reduce the size of the linked executable file. The following is a list
 of ways to help reduce the size of .EXE files:

 1. Use the /E (/EXEPACK) linker option. This linker option removes
    sequences of repeated bytes and optimizes the load-time relocation
    table. The result is that executable files linked with this option
    may be smaller and may load faster than files linked without this
    option. Note: The /EXEPACK option cannot be used with the /Q
    option.

 2. For stand-alone .EXE files (that is, those compiled with the BC /O
    option) that use a string variable for the filename in the OPEN
    statement, linking in the file NOCOM.OBJ reduces the size of the
    programs by about 4K. (NOCOM.OBJ should be used only if your
    program contains no OPEN "COM" statements.) For example, the
    following is a program that NOCOM.OBJ will help make smaller:

       X$="test.dat"
       OPEN X$ FOR OUTPUT AS #1

 In addition to NOCOM.OBJ, BASIC compiler version 6.00 provides other
 NOxxx.OBJ files, including NOCGA.OBJ, NOEGA.OBJ, NOGRAPH.OBJ,
 NOHERC.OBJ, NOLPT.OBJ, NOVGA.OBJ, and SMALLERR.OBJ. These files are
 discussed in both the "Microsoft BASIC Compiler 6.0: User's Guide" and
 the README.DOC found on Disk 1. These NOxxx.OBJ files can also be used
 when a custom run-time module is built with the BUILDRTM.EXE utility.

 For more information about stub files and optimizing code for size and
 speed, see Chapter 15, "Optimizing Program Size and Speed," in the
 "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10.


 84. BASIC Example to Call OS/2 Function DosSetVerify, DosQVerify

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q37772

 The sample program below makes a call to the MS OS/2 functions
 DosSetVerify and DosQVerify. This program can be compiled in Microsoft
 BASIC Compiler Versions 6.00 and 6.00b for MS OS/2 and in Microsoft
 BASIC Professional Development System (PDS) Version 7.00 for MS OS/2.

 The program is as follows:

 DEFINT A-Z

 'The declarations can be found in BSEDOSFL.BI

 DECLARE FUNCTION DosSetVerify%(_
                  BYVAL P1 AS INTEGER)

 DECLARE FUNCTION DosQVerify%(_
                  SEG P1 AS INTEGER)

 x=DosQVerify(opt%)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   SELECT CASE opt%
      CASE 0
         Print "Verify is off"
      CASE 1
         PRINT "Verify is on"
      CASE ELSE
         PRINT "An unexpected error occurred."
   END SELECT
 END IF

 Print  "(0) to deactivate verify "
 input  "(1) to activate for this Application : ";opt%

 x=DosSetVerify(opt%)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   SELECT CASE opt%
      CASE 0
         Print "Verify is set off"
      CASE 1
         PRINT "Verify is set on"
      CASE ELSE
         PRINT "An unexpected error occurred."
   END SELECT
 END IF
 INPUT "Enter Any Key to Verify the Status of VERIFY";a$

 x=DosQVerify(opt%)

 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   SELECT CASE opt%
      CASE 0
         Print "Verify is off"
      CASE 1
         PRINT "Verify is on"
      CASE ELSE
         PRINT "An unexpected error occurred."
   END SELECT
 END IF
 END


 85. Compiled BASIC Example to Call OS/2 Function DosKillProcess

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q37773

 The sample program below makes a call to the MS OS/2 function
 DosKillProcess. This program can be compiled in Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 The program is as follows:

 DEFINT A-Z

 'This declaration can be found in BSEDOSPC.BI
 DECLARE FUNCTION DosKillProcess%(_
                  BYVAL p1 AS INTEGER,_
                  BYVAL p2 AS INTEGER)

 Input "Enter PID to KILL : ";pid%
 Input "Enter ACTION code : ";action%

 x% = DosKillProcess%(action%,pid%)

 if (x%) then
     Print "Error: ";x%
 else
     Print "PID : ";pid%;" - stopped"
 end if
 end


 86. "Duplicate Definition" LINKing C Graphics Library to BASIC, /O

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | S_C S_QuickC B_QuickBas SR# G881109-6007
 Last Modified: 27-JUL-1990    ArticleIdent: Q37901

 The C graphics library, GRAPHICS.LIB, is incompatible with programs
 compiled with BC /O in QuickBASIC versions 4.00, 4.00b, and 4.50,
 Microsoft BASIC Compiler versions 6.00 or 6.00b, or Microsoft BASIC
 Professional Development System (PDS) version 7.00. The FONT and CHART
 graphics in QuickC version 2.00 are also incompatible with programs
 compiled with BC /O in these versions of QuickBASIC and BASIC
 compiler. Many of the C graphics routines conflict with the BASIC
 graphic routines in the BASIC stand-alone library. If you need to do
 graphics when you link BASIC stand-alone programs with C, the graphics
 should be done in BASIC. An alternative is to compile without the BC
 /O option in BASIC.

 Linking BASIC programs compiled BC /O with Microsoft C graphics
 routines gives many "Duplicate Definition" errors, even if you LINK
 with the /NOE option. Compile without /O to eliminate the errors.


 87. BASIC Sample Program for OS/2 Function Calls for DLL Modules

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q37905

 Below is a sample program that makes a call to the following MS OS/2
 functions:

    DosLoadModule
    DosFreeModule
    DosGetProcAddr
    DosGetModHandle
    DosGetModName

 The program below can be compiled in Microsoft BASIC Compiler Versions
 6.00 and 6.00b for MS-DOS and MS OS/2 and Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 The program below should be compiled with BASIC compiler Version 6.00
 or 6.00b, or BASIC PDS 7.00 and should use the default run-time module
 (BRUN60EP.DLL for BASIC compiler 6.00, BRUN61EP.DLL for BASIC compiler
 6.00b, and BRT70ENP.DLL for BASIC PDS 7.00). The run-time module is
 required because the call to DosGetModHandle is searching for the
 handle of the run-time module. The program can be modified to search
 for any given DLL (dynamic link library).

 The following is a code example:

 'The function declarations can be found in BSEDOSPE.BI

 DECLARE FUNCTION DosLoadModule%(_
       BYVAL P1s AS INTEGER,_
       BYVAL P1o AS INTEGER,_
       BYVAL P2  AS INTEGER,_
       BYVAL P3s AS INTEGER,_
       BYVAL P3o AS INTEGER,_
       SEG   P4  AS INTEGER)

 DECLARE FUNCTION DosFreeModule%(_
       BYVAL P1  AS INTEGER)

 DECLARE FUNCTION DosGetProcAddr%(_
       BYVAL P1  AS INTEGER,_
       BYVAL P2s AS INTEGER,_
       BYVAL P2o AS INTEGER,_
       SEG   P3  AS LONG)

 DECLARE FUNCTION DosGetModHandle%(_
       BYVAL P1s AS INTEGER,_
       BYVAL P1o AS INTEGER,_
       SEG   P2  AS INTEGER)

 DECLARE FUNCTION DosGetModName%(_
       BYVAL P1  AS INTEGER,_
       BYVAL P2  AS INTEGER,_
       BYVAL P3s AS INTEGER,_
       BYVAL P3o AS INTEGER)

 DEFINT a-z

 dllname$="BRUN60EP"+chr$(0)  'Change this "BRUN61EP" for 6.00B

 x=DosGetModHandle%(varseg(dllname$),sadd(dllname$),handle)

 IF (x) THEN
    Print "An error occurred in DosGetModHandle.  The number is : ";x
 ELSE
    Print "The handle for ";dllname$;" is : ";handle

    'Using the handle returned, find the name
    DIM buffer AS STRING*40
    length=40
    x=DosGetModName%(handle,length,varseg(buffer),varptr(buffer))
    IF (x) THEN
       Print "An error occurred in DosGetModName.  The number is : ";x
    ELSE
       Print "The module name for handle ";handle;" is ";buffer
    END IF

    'Load another DLL
    DIM bad AS STRING*128
    dllname$="DOSCALLS1"+chr$(0)
    x=DosLoadModule%(varseg(bad),varptr(bad),128,varseg(dllname$),_
              sadd(dllname$),handle)
    IF (x) THEN
       Print "An error occurred in DosLoadModule.  The number is : ";x
    ELSE
       Print "The handle for ";dllname$;" is : ";handle

       '#150 is an routine that can be found in DOSCALLS1
       routine$="#150"+chr$(0)
       DIM address AS LONG
       x=DosGetProcAddr%(handle,varseg(routine$),sadd(routine$),address)
       IF (x) THEN
        Print "An error occurred in DosGetProcAddr.  The number is : ";x
       ELSE
        Print "The address of ";routine$;" is ";address
       END IF

       'Unload module
       x=DosFreeModule%(handle)
       IF (x) THEN
        print "An error occurred in DosFreeModule.  The number is : ";x
       ELSE
        Print "DLL was freed."
       END IF
    END IF
 END IF
 END


 88. BC /A or CodeView Finds Run-Time Error Segment:Offset Address

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified: 26-FEB-1990    ArticleIdent: Q39190

 The following information applies to Microsoft BASIC Compiler Versions
 6.00 and 6.00b for MS-DOS and MS OS/2, to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2, and to
 QuickBASIC Versions 4.00, 4.00b, and 4.50 for MS-DOS.

 When a run-time error message is displayed with a segment and offset
 address, the address is in hexadecimal notation. For example, "error
 in module [name] at 5517:0059" means a code segment address of 5517
 hexadecimal and a code offset address of 0059 hexadecimal.

 To find out where this address corresponds to a statement in your
 program, you can compile your program with the BC /A option and
 generate a .LST file. The .LST file lists the code offsets along with
 the BASIC statements and their translation into assembly-language
 code. You can use the module name and code offset from the run-time
 error message to find the error line in that module's .LST file. (The
 segment address from the error message is not needed to find the error
 line in the .LST file).

 You can also use the run-time error's segment:offset address in the
 Microsoft CodeView debugger to see which BASIC code caused the
 run-time error.

 The BC /A option requires the file to be saved in Text format. (If you
 save the source file in Fast Load and Save format, BC /A gives the
 compiler error "Cannot generate listing for BASIC binary source
 files.")

 Page 196 of the "Microsoft CodeView and Utilities: Software
 Development Tools for MS-DOS" manual states that you can use "V" to
 view an address in the segment:offset format. To view the source code
 executed at an address, type the following in CodeView:

    V &H5517:&H0059

 Note: QuickBASIC Versions 4.00, 4.00b, and 4.50 are not sold with the
 CodeView debugger. The CodeView debugger comes with Microsoft BASIC
 Compiler Version 6.00 or 6.00b, Microsoft BASIC PDS Version 7.00, or
 with Microsoft Macro Assembler Versions 5.00 and 5.10, but is not sold
 separately.

 The following is an example of finding the statement in error in a
 BASIC program based upon the code offset given in the run-time error
 message. The BASIC .EXE program below generates a "File Not Found"
 error at a specific address. Note that the error occurred at an offset
 (0057) right after a call to B$OPEN. This is a clue that the error
 occurred with the open routine.

 The following is a code example to be compiled with the BC /A option:

    CLS
    PRINT "This is a test of the /a option"
    OPEN "NONEXIST.DAT" FOR INPUT AS #1

 This program generates the following output:

    This is a test of the /a option

    File not found in module TEST     at address 5CCD:0057

 The .LST file generated with BC /A is as follows:
                                                            PAGE   1
                                                           28 Dec 88
                                                            09:35:26
 Offset  Data    Source Line      Microsoft (R) QuickBASIC

  0030   0006    CLS
  0030   0006    PRINT "This is a test of the /a option"
  0030   0006    OPEN "NONEXIST.DAT" FOR INPUT AS #1
  0030   0006
  0030   0006
  0030    **            I00002: mov   ax,0FFFFh
  0033    **                    push  ax
  0034    **                    call  B$SCLS
  0039    **                    mov   ax,offset <const>
  003C    **                    push  ax
  003D    **                    call  B$PESD
  0042    **                    mov   ax,offset <const>
  0045    **                    push  ax
  0046    **                    mov   ax,0001h
  0049    **                    push  ax
  004A    **                    mov   ax,0FFFFh
  004D    **                    push  ax
  004E    **                    mov   ax,0001h
  0051    **                    push  ax
  0052    **                    call  B$OPEN      <<-- offending line
  0057    **                    call  B$CENP
  005C   0006

 43613 Bytes Available
 43308 Bytes Free

     0 Warning Error(s)
     0 Severe  Error(s)


 89. Sample Program; BASIC Invoking C Function That Returns String

 Product Version(s): 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom SR# S881207-17
 Last Modified:  1-FEB-1990    ArticleIdent: Q39361

 The sample program below demonstrates a BASIC program calling a C
 routine that returns a BASIC string descriptor. This programming
 example is a variation of the sample program located on Page 310 of
 the "Microsoft QuickBASIC 4.0: Learning and Using" manual.

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50, to Microsoft BASIC Compiler Versions 6.00 and 6.00b for
 MS-DOS and MS OS/2, and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 Note: The Microsoft C medium-memory model should be used to ensure
 that the C string is in DGROUP.

 Note: This information does not apply if using far string support in
 BASIC PDS Version 7.00 or when running inside the QuickBASIC extended
 (QBX.EXE) environment with BASIC PDS Version 7.00. For information on
 programming with mixed-languages using far strings refer to Chapter
 13, "Mixed-Language Programming with Far Strings," in the "Microsoft
 BASIC 7.0: Programmer's Guide."

 The COMPILE and LINK instructions are as follows:

    BC test.bas;
    CL /AM /c tc.c
    LINK test tc /noe;

 The BASIC routine is as follows:

    DECLARE FUNCTION t1$()
    a$ = t1$
    PRINT a$

 The C function is as follows:

    struct bas_str{
            int sd_len;
            char *sd_addr;
            };
    char cstr[]="ABC";
    struct bas_str pascal t1()
    {
       struct bas_str str_des;
       str_des.sd_addr = cstr;
       str_des.sd_len = strlen(cstr);
       return (str_des);
    }


 90. Can't Define SUB/FUNCTION in INCLUDE File

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas SR# S881209-27
 Last Modified:  1-FEB-1990    ArticleIdent: Q39581

 The command line compiler BC.EXE fails to flag the error if you put a
 procedure definition (SUB...END SUB or FUNCTION...END FUNCTION) into
 an INCLUDE file. The program compiles, LINKs, and runs without error.

 QB.EXE, and QBX.EXE included with Microsoft BASIC Professional
 Development System (PDS) Version 7.00, correctly gives the error
 "Statement cannot occur within include file." Procedure definitions
 are not allowed in $INCLUDE files.

 This information applies to QuickBASIC Versions 4.00b and 4.50, to
 Microsoft BASIC Compiler Versions 6.00 and 6.00b, and Microsoft BASIC
 PDS Version 7.00 for MS-DOS and MS OS/2.

 The BC.EXE from QuickBASIC Version 4.00 correctly flags the error.

 The following is a example:

    DIM arr(50)
    REM $INCLUDE: 'getsub.inc'
    FOR i = 1 TO 50
       arr(i) = i
    NEXT i
    CALL prntarray(arr())
    END

    'This is GETSUB.INC, the separate include file:
    SUB prntarray (a())
       FOR j = 1 TO 50
          PRINT a(j)
       NEXT j
    END SUB


 91. BC 6.00 Example to Manipulate File with OS/2 API Calls

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-57
 Last Modified:  1-FEB-1990    ArticleIdent: Q40865

 Below is a sample program that calls the following MS OS/2 API
 functions:

    DosBufReset
    DosChgFilePtr
    DosClose
    DosOpen
    DosQFHandState
    DosQHandType
    DosRead
    DosSetFHandState
    DosWrite

 This program can be compiled in Microsoft BASIC Compiler Version 6.00
 or 6.00b for MS OS/2 and Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 The following is the sample program:

 CONST TRUE=-1
 CONST FALSE=0

 REM $INCLUDE: 'BSEDOSFL.BI'
 DEFINT A-Z
 DIM sizel AS LONG
 DIM reserved AS LONG
 DIM buf AS STRING*512
 DIM distance AS LONG
 DIM NewPointer AS LONG

 CLS
 input "Enter the Filename : ";fl$
 fl$=fl$+chr$(0)
 openflag = 17
 openmode = &h6092
 PRINT
 PRINT "Enter a Key to OPEN the file"
 WHILE INKEY$="" : WEND
 PRINT
 x=DosOpen(varseg(fl$),sadd(fl$),handle,action,sizel,_
           filea,openflag,openmode,reserved)

 IF (x) THEN
    print "An error occurred.  The number is : ";x
    end
 ELSE
   print "The handle is : ";handle
   print "The action is : ";action
   print "The size is   : ";sizel
   print "The filea is  : ";filea
   print "The openflag  : ";openflag
   print "The openmode  : ";openmode
   size=512
   buffer$=string$(size/4,65)+string$(size/4,66)
   buffer$=buffer$+string$(size/4,67)+string$(size/4,68)+chr$(0)
   PRINT
   PRINT "Enter a Key to WRITE to the file"
   WHILE INKEY$="" : WEND
   PRINT
   x=DosWrite%(handle,varseg(buffer$),sadd(buffer$),size,nw)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     print "The information was placed into the file."
     print "The number of bytes written was : ";nw
   END IF
 END IF
 PRINT
 PRINT "Enter a Key to CLOSE the file"
 WHILE INKEY$="" : WEND
 PRINT

 x=DosClose%(handle)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The file is closed." : print
 END IF
 PRINT
 PRINT "Enter a Key to RE-OPEN the file"
 WHILE INKEY$="" : WEND
 PRINT
 x=DosOpen(varseg(fl$),sadd(fl$),handle,action,sizel,_
           filea,openflag,openmode,reserved)

 IF x THEN
    print "error: ";x
    stop
 END IF
 DONE=FALSE
 WHILE NOT(done)
   size=256
   buf=string$(size,42)
   PRINT
   PRINT "Enter a Key to READ the file"
   WHILE INKEY$="" : WEND
   PRINT

   x=DosRead%(handle,varseg(buf),varptr(buf),size,nr)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     IF nr=0 THEN
        PRINT "EOF Detected"
        DONE=TRUE
     ELSE
        PRINT "The number of bytes read is : ";nr
        PRINT "The bytes were : ";buf
     END IF
   END IF
 WEND
   PRINT
   PRINT "Enter a Key to RESET the file BUFFER"
   WHILE INKEY$="" : WEND
   PRINT
   x=DosBufReset%(handle)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     PRINT "The BUFFER was flushed"
   END IF
 PRINT
 PRINT "Enter a Key to CHANGE the file POINTER"
 WHILE INKEY$="" : WEND
 PRINT
 distance=192
 MoveType=0

 x=DosChgFilePtr%(handle,distance,MoveType,NewPointer)
 IF (x) THEN
   Print "An error occurred.  The number is : ";x
 ELSE
   Print "The file pointer is moved.  The information will be read."
   size=256
   buf=string$(size,42)
   PRINT
   PRINT "Enter a Key to READ the file"
   WHILE INKEY$="" : WEND
   PRINT

   x=DosRead%(handle,varseg(buf),varptr(buf),size,nr)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     IF nr=0 THEN
        PRINT "EOF Detected"
        DONE=TRUE
     ELSE
        PRINT "The number of bytes read is : ";nr
        PRINT "The bytes were : ";buf
     END IF
   END IF
 END IF
 PRINT
 PRINT "Enter a Key to get the GET/Modify File Handle State"
 WHILE INKEY$="" : WEND
 PRINT

 x=DosQFHandState%(handle,FileHandleState)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The filehandle state is : ";FileHandleState
 END IF

 NewHandState=&h0010
 x=DosSetFHandState%(handle,NewHandleState)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The filehandle state was changed."
 END IF

 x=DosQFHandState%(handle,FileHandleState)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The filehandle state is : ";FileHandleState
 END IF

 x=DosQHandType%(handle,HandType,FlagWord)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    IF (HandleType) THEN
        print "The handle type is a Device handle"
        print "The Flag Word is : ";Flag Word
    ELSE
        print "The handle type is a File-System handle"
    END IF
 END IF
 PRINT
 PRINT "Enter a Key to CLOSE the file"
 WHILE INKEY$="" : WEND
 PRINT
 x=DosClose%(handle)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The file is closed."
 END IF
 END


 92. BC 6.00 Example of OS/2 API Calls DosGetPrty, DosSetPrty

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-56
 Last Modified:  1-FEB-1990    ArticleIdent: Q40866

 Below is a sample program that calls the MS OS/2 API functions
 DosGetPrty and DosSetPrty. This program can be compiled in Microsoft
 BASIC Compiler Versions 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 The following is the sample program:

 REM $INCLUDE: 'BSEDOSPC.BI'
 DEFINT a-z
 DIM pids AS PidInfo

 x%=DosGetPid(pids)
 IF (x%) THEN
    PRINT "An error occurred in DosGetPid: ";x%
    END
 ELSE
    pid=pids.pid
    scope = 0
    x% = DosGetPrty(scope,priority,pid)
    IF (x%) THEN
        PRINT "An error occurred in DosGetPrty: ";x%
        END
    ELSE
       PRINT
       PRINT "Priority: "; Priority
       PRINT
       CALL SetPrty(pid)
       PRINT
       PRINT "Enter a Key to Verify Change..."
       WHILE INKEY$="": WEND
       scope=0
       x%=DosGetPrty(scope,priority,pid)
       IF (x%) THEN
          PRINT "An error Occurred in DosGetPrty: ";x%
          END
       ELSE
          PRINT
          PRINT "Priority: "; Priority
       END IF
    END IF
 END IF
 END

 SUB SetPrty(pid) STATIC
     Print "Enter the SCOPE (0 - Process and all threads)"
     PRINT "                (1 - Process and all the descendants)"
     PRINT "                (2 - Thread calling the function)"
     INPUT "                                         OPTION: ";scope
     PRINT
     PRINT "Enter the CLASS (0 - No Change)"
     PRINT "                (1 - Idle-time)"
     PRINT "                (2 - Regular)"
     PRINT "                (3 - Time-Critical)"
     INPUT "                             OPTION: ";class
     PRINT
     INPUT "Enter CHANGE (-31 to + 31) : "; change
     x% = DosSetPrty%(scope,class,change,pid)
     if (x%) then
         PRINT "Error setting Priority - ";x%
     else
         PRINT "Priority Changed."
     end if
 END SUB


 93. BC 6.00 Example of OS/2 API Calls DosError, DosErrClass

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-55
 Last Modified:  1-FEB-1990    ArticleIdent: Q40867

 Below is an example of using the MS OS/2 API function DosError and
 DosErrClass. This program must be compiled with Microsoft BASIC
 Compiler Version 6.00 and 6.00b for MS OS/2 and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS OS/2.

 The following is the sample program:

 DEFINT a-z
 REM $include: 'bsedosfl.bi'
 REM $include: 'bsedospc.bi'
 PRINT "Note: This only affects OS/2 API calls you call"
 PRINT "      BASIC handles its own errors"
 PRINT
 PRINT "Enter (0) to SUSPEND system hard-error processing"
 INPUT "or (1) to RESUME system hard-error processing : ";y%
 PRINT
 x=DOSERROR%(y%)

 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    Print "Hard-Error Processing Suspended"
    Print "Open Drive Door A and Enter any Key..."
    PRINT
    WHILE INKEY$="" : WEND
 END IF
 fl$="A:\ABC.EXE"+chr$(0)

 code%=DosQFileMode(varseg(fl$),sadd(fl$),attribute%,0&)
 if (code%) then
    Print "Error Returned from DosQFileMode: " code%
    x% = DosErrClass(code%,class%,action%,locus%)
    IF (x%) THEN
       PRINT "An error was received determining class"
    ELSE
       CALL DetermineError(class%,action%,locus%)
    END IF
 END IF
 END

 SUB DetermineError(class%,action%,locus%) STATIC
 PRINT "Error Class: ";
 SELECT CASE class%
        CASE 1
          PRINT "ERRCLASS_OUTRES ==> Out of Resource"
        CASE 2
          PRINT "ERRCLASS_TEMPSIT ==> This is a Temporary Situation"
        CASE 3
          PRINT "ERRCLASS_AUTH ==> Authorization has failed"
        CASE 4
          PRINT "ERRCLASS_INTRN ==> An Internal Error has Occurred"
        CASE 5
          PRINT "ERRCLASS_HRDFAIL ==> A Device Hardware Failure"
        CASE 6
          PRINT "ERRCLASS_SYSFAIL ==> A System Failure has Occurred"
        CASE 7
 PRINT "ERRCLASS_APPERR ==> A Probable Application Error has Occurred"
        CASE 8
          PRINT "ERRCLASS_NOTFND ==> The Item was not Located"
        CASE 9
          PRINT "ERRCLASS_BADFMT ==> Bad Format"
        CASE 10
          PRINT "ERRCLASS_LOCKED ==> Locked"
        CASE 11
 PRINT "ERRCLASS_MEDIA ==> Incorrect Media; a CRC Error has Occurred"
        CASE 12
          PRINT "ERRCLASS_ALREADY ==> Everything is Ready"
        CASE 13
          PRINT "ERRCLASS_UNK ==> Error is Unclassified"
        CASE 14
          PRINT "ERRCLASS_CANT ==> Cannot perform Requested Action"
        CASE 15
          PRINT "ERRCLASS_TIME ==> Time-out has Occurred"
        CASE ELSE
          PRINT "UnKnown Class"
 END SELECT
 Print "Recommended Action: ";
 SELECT CASE action%
        CASE 1
          PRINT "ERRACT_RETRY ==> Retry Immediately"
        CASE 2
          PRINT "ERRACT_DLYRET ==> Delay and Retry"
        CASE 3
          PRINT "ERRACT_USER ==> Bad User Input; Get New values"
        CASE 4
          PRINT "ERRACT_ABORT ==> Terminate in an Orderly Manner"
        CASE 5
          PRINT "ERRACT_PANIC ==> Terminate Immediately"
        CASE 6
          PRINT "ERRACT_IGNORE ==> Ignore the Error"
        CASE 7
          PRINT "ERRACT_INTRET ==> Retry After User Intervention"
        CASE ELSE
          PRINT "UnKnown Class"
 END SELECT
 PRINT "Location: ";
 SELECT CASE locus%
        CASE 1
          PRINT "ERRLOC_UNK ==> The Origin of the Error is Unknown"
        CASE 2
          PRINT "ERRLOC_DISK ==> The Error Occurred in a Random-Access"
          PRINT "                Device, such as a Disk Drive"
        CASE 3
          PRINT "ERRLOC_NET ==> This is a Network Error"
        CASE 4
          PRINT "ERRLOC_SERDEV ==> This is a Serial-Device Error"
        CASE 5
          PRINT "ERRLOC_MEM ==> This is a Memory Parameter Error"
        CASE ELSE
          PRINT "Unknown Location Error"
 END SELECT
 END SUB


 94. BC 6.00 Example of OS/2 API Function Call DosExecPgm

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-54
 Last Modified:  1-FEB-1990    ArticleIdent: Q40868

 Below is an example of using the MS OS/2 API function DosExecPgm. This
 program must be compiled with Microsoft BASIC Compiler Versions 6.00
 or 6.00b for MS OS/2 or Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 The following is the example code:

 'The definitions are taken from BSEDOSPC.BI
 TYPE ResultCodes
      codeterminate as integer
      coderesult as integer
 END TYPE
 DECLARE FUNCTION DosExecPgm%(_
         BYVAL p1S AS INTEGER,_
         BYVAL p1o AS INTEGER,_
         BYVAL p2  AS INTEGER,_
         BYVAL p3  AS INTEGER,_
         BYVAL p4s AS INTEGER,_
         BYVAL p4o AS INTEGER,_
         BYVAL p5s AS INTEGER,_
         BYVAL p5o AS INTEGER,_
         SEG   p6  AS ResultCodes,_
         BYVAL p7s AS INTEGER,_
         BYVAL p7o AS INTEGER)
 DEFINT A-Z
 DIM results as ResultCodes

 INPUT "Enter NAME of EXE file (with .EXE) to execute: "; fln$
 fln$ = fln$ + chr$(0)
 buffer$=space$(255)+chr$(0)
 bufferlen = len(buffer$)
 AsyncTraceFlags = 1  'Execute Asynchronously to the parent
 ArgPointer$=chr$(0)
 EnvPointer$=chr$(0)
 x% = DosExecPgm(varseg(buffer$),sadd(buffer$),_
                 bufferlen,AsyncTraceFlags,_
                 varseg(ArgPointer$),sadd(ArgPointer$),_
                 varseg(EnvPointer$),sadd(EnvPointer$),_
                 results, varseg(fln$),sadd(fln$))
 PRINT "ExecPgm Error CODE : ";x%
 SLEEP(5)
 PRINT "This Parent is Complete"
 END


 95. BC 6.00 Example of OS/2 API Function Call DosNewSize

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-34
 Last Modified:  1-FEB-1990    ArticleIdent: Q40870

 Below is a sample program that makes a call to the MS OS/2 API
 function DosNewSize. This function can be used to truncate or expand a
 file. If the file is expanded, the new bytes are undefined. The
 program also makes calls to DosOpen and DosClose.

 The program can be compiled in Microsoft BASIC Compiler Versions 6.00
 and 6.00b for MS OS/2 and Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 The following is the sample program:

 REM $INCLUDE: 'bsedosfl.bi'
 DEFINT a-z
 CLS
 DIM filelist AS FileStatus
 DIM sizel AS LONG
 DIM reserved AS LONG
 DIM buf AS STRING*512
 DIM distance AS LONG
 DIM NewPointer AS LONG

 input "Enter the Filename : ";fl$
 fl$=fl$+chr$(0)
 openflag=17
 openmode=&h6092

 x=DosOpen(varseg(fl$),sadd(fl$),handle,action,sizel,_
           filea,openflag,openmode,reserved)

 IF (x) THEN
    print "An error occurred.  The number is : ";x
    end
 ELSE
   input "Enter the new size ",newsize&
   x=DosNewSize(handle,newsize&)
   IF (x) THEN
      Print "An error occurred.  The number is : ";x
   ELSE
      Print "File size was changed"
   END IF
   x=DosClose%(handle)
   IF (x) THEN
      color 7 :PRINT "An error occurred. The number is : ";x :color 15
   ELSE
      print "File Closed."
      print "Enter any key to exit..."
      while inkey$="" :wend
   END IF
 END IF
 END


 96. Some Coprocessor Assembler Instructions Are Not Emulated

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas S_C H_Fortran H_MASM SR# S890111-171
 Last Modified:  1-FEB-1990    ArticleIdent: Q40872

 Microsoft Macro Assembler Version 5.10 does not come with routines to
 emulate a math coprocessor.

 Page 382 of the "Microsoft Macro Assembler 5.1: Programmer's Guide"
 states that to emulate math-coprocessor instructions, you must link
 with a Microsoft high-level language that supports floating-point
 emulation of the coprocessor. You would write the assembler procedure
 using coprocessor instructions, then assemble with the /E option, and
 finally link it with the high-level language modules.

 However, only a subset of coprocessor instructions are emulated by the
 Microsoft high-level languages.

 If you link your Microsoft higher-level language to an assembler
 routine that invokes an instruction that is NOT emulated by the
 higher-level language, then the program gives a run-time error (or
 possibly hangs, or gives incorrect results) when run on a machine that
 has no coprocessor.

 This information applies to the following products:

 1.  Microsoft BASIC Compiler Versions 6.00 and 6.00b

 2.  Microsoft BASIC Professional Development System (PDS) Version 7.00

 3.  Microsoft QuickBASIC Version 4.50

 4.  Microsoft C Compiler Version 5.10

 5.  Microsoft FORTRAN Compiler Version 4.10

 Below is a list of the coprocessor (8087 or 80287) instructions that
 are not emulated by Microsoft high-level languages:

    FBLD    - packed decimal load
    FBSTP   - packed decimal store and pop
    FCOS    - cosine function
    FDECSTP - decrement stack pointer
    FINCSTP - increment stack pointer
    FINIT   - initialize processor
    FLDENV  - load environment
    FNOP    - No operation
    FPREM1  - partial remainder
    FRSTOR  - restore saved state
    FSAVE   - save state
    FSETPM  - set protected mode
    FSIN    - only sine function
    FSINCOS - sine and cosine function
    FSTENV  - store environment
    FUCOM   - unordered comparison
    FUCOMP  - unordered comparison and pop
    FUCOMPP - unordered comparison and double pop
    FXTRACT - extract exponent and significant

 Also, some of the No-Wait forms of instructions are not emulated, such
 as FNSTENV and FNINIT.


 97. BC 6.00 Example of OS/2 API Function Call DosDupHandle

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890125-58
 Last Modified:  1-FEB-1990    ArticleIdent: Q40873

 Below is a sample program that makes a call to the MS OS/2 API
 function DosDupHandle. It also uses the following MS OS/2 API
 functions:

    DosOpen
    DosRead
    DosWrite
    DosClose

 This program can be compiled in Microsoft BASIC Compiler Versions 6.00
 and 6.00b for MS OS/2 and Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 The following is the sample program:

 CONST TRUE=-1
 CONST FALSE=0
 REM $include: 'BSEDOSFL.BI'

 DEFINT A-Z
 DIM sizel AS LONG
 DIM reserved AS LONG
 DIM buf AS STRING*512
 DIM distance AS LONG
 DIM NewPointer AS LONG
 CLS

 input "Enter the Filename : ";fl$
 fl$=fl$+chr$(0)
 openflag=17
 openmode=&h6092

 x=DosOpen(varseg(fl$),sadd(fl$),handle,action,sizel,_
           filea,openflag,openmode,reserved)

 IF (x) THEN
    print "An error occurred.  The number is : ";x
    end
 ELSE
   print "The handle is : ";handle
   print "The action is : ";action
   print "The size is   : ";sizel
   print "The filea is  : ";filea
   print "The openflag  : ";openflag
   print "The openmode  : ";openmode
   size=512
   buffer$=string$(size/4,65)+string$(size/4,66)+string$(size/4,67)
   buffer$=buffer$+string$(size/4,68)+chr$(0)

   x=DosWrite%(handle,varseg(buffer$),sadd(buffer$),size,nw)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     print "The information was placed into the file."
     print "The number of bytes written was : ";nw
   END IF
 END IF

 x=DosClose%(handle)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The file is closed." : print
 END IF
 print "Enter Any Key OPEN file and DUPLICATE Handle..."
 while inkey$="" :wend

 x=DosOpen(varseg(fl$),sadd(fl$),handle,action,sizel,_
           filea,openflag,openmode,reserved)
 x=DosDupHandle%(handle,newhandle)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     Print "Handle was Duplicated."
   END IF
 PRINT
 PRINT "Enter any Key to READ with Both handles"
 PRINT
 WHILE INKEY$="" : WEND
 size=256
 buf=string$(size,42)
 x=DosRead%(handle,varseg(buf),varptr(buf),size,nr)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     IF nr=0 THEN
        PRINT "EOF Detected"
     ELSE
        PRINT "ORIGINAL HANDLE"
        PRINT "The number of bytes read is : ";nr
        PRINT "The bytes were : ";buf
     END IF
   END IF
 size=256
 buf=string$(size,42)
 x=DosRead%(newhandle,varseg(buf),varptr(buf),size,nr)
   IF (x) THEN
     Print "An error occurred.  The number is : ";x
   ELSE
     IF nr=0 THEN
        PRINT "EOF Detected"
     ELSE
        PRINT "NEW HANDLE"
        PRINT "The number of bytes read is : ";nr
        PRINT "The bytes were : ";buf
     END IF
   END IF

 x=DosClose%(handle)
 IF (x) THEN
    Print "An error occurred.  The number is : ";x
 ELSE
    print "The file is closed."
 END IF
 END


 98. Mouse Not Supported on VGA in OS/2 Real Mode; OK in MS-DOS

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# S890222-67 B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q42589

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50 for MS-DOS, to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2, and to Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 In MS OS/2 real mode under MS OS/2 Versions 1.00 and 1.10, due to
 limitations of the MS OS/2 mouse controller, the mouse driver does not
 support operating with VGA graphics. The mouse works correctly in EGA,
 CGA, and text modes. This problem was corrected in MS OS/2 Version
 1.20.

 In MS OS/2 protected mode, the MS OS/2 mouse driver does not support
 the drawing of the mouse pointer in graphics modes. It is up to the
 application to draw its own pointer. The mouse driver provides
 notification of mouse movement to an MS OS/2 application, provided
 that the VioSetMode CALL (set graphics mode) is used AFTER the MouOpen
 (open the mouse) and the MouSetDevStatus (to disable pointer drawing)
 CALLs are performed.

 More information on the VioSetMode and MouSetDevStatus MS OS/2 API
 CALLs can be found in the "Microsoft Operating System/2: Programmer's
 Toolkit Programming Tools."


 99. "SYS2090" Error Using SETUP, LINK, or LIB with BASIC Compiler

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified:  1-FEB-1990    ArticleIdent: Q42591

 You can receive the error, "SYS2090: Unable to load User Program" when
 trying to run the SETUP.EXE, LINK.EXE, or LIB.EXE program (from
 Microsoft BASIC Compiler Versions 6.00 or 6.00b and Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2) in either the protected or real modes of Microsoft OS/2.

 This Microsoft OS/2 error typically occurs when trying to run a bound
 application that is not configured correctly in the real (MS-DOS)
 environment. Because bound applications can run under both real or
 protected mode, these applications are very sensitive to their
 environment.

 The following are some possible reasons for this error in real mode:

 1. A corrupted or zero-length .EXE file.

 2. When running under the standard MS-DOS environment, you may be
    using MS-DOS Versions 2.x. Running a bound application under MS-DOS
    2.x requires that the bound programs be placed in the current
    subdirectory. Using MS-DOS Versions 3.x will also correct the
    problem.

 3. Problems with the specific BIOS, possibly corrected by upgrading
    the ROM version.

 4. Interference by terminate-and-stay-resident (TSR) programs and some
    unpatched versions of Novell netware has been observed to cause
    SYS2090 errors. Novell users should contact their dealers to obtain
    patched versions of the netware that emulate MS-DOS 3.x correctly by
    preserving the SS and SP registers when spawning processes. Novell
    netware Version 2.0A++, and Versions 2.10 and later are patched
    properly, according to Novell.)


 100. BASIC User-Entry Points Cannot Be Called from Other Languages

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | docerr B_QuickBas H_MASM S_C S_PasCal H_Fortran
 Last Modified:  8-JAN-1991    ArticleIdent: Q42700

 The "Microsoft Mixed-Language Programming Guide" is packaged with
 Microsoft C Versions 5.00 and later, Microsoft Pascal Versions 4.00
 and later, Microsoft FORTRAN Versions 4.10 and later, and Microsoft
 Macro Assembler (MASM) Versions 5.00 and later.

 On the bottom of Page 39, there is a note that incorrectly states that
 QuickBASIC Version 4.00 provides a number of "user-entry points,"
 which are BASIC system-level functions that may be called directly
 from C, and that the README file provides more information. However,
 there is no information on these "user-entry points" in the README.DOC
 file provided with QuickBASIC Versions 4.00, 4.00b, or 4.50, Microsoft
 BASIC Compiler Versions 6.00 and 6.00b, or Microsoft BASIC
 Professional Development System (PDS) Version 7.00 or 7.10 for MS-DOS
 and MS OS/2. This note should be removed, since there are no such
 user-entry points available.


 101. M.EXE Editor's CALLTREE Does Not Support BASIC Source Files

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | B_QuickBas SR# S890212-9
 Last Modified:  1-FEB-1990    ArticleIdent: Q43788

 The CALLTREE program used by the Microsoft M.EXE editor does not
 produce meaningful results for BASIC source files. The CALLTREE
 utility is provided with the Microsoft Editor for use with Microsoft C
 and Microsoft Macro Assembler (MASM). It returns a listing of a C or
 MASM program's function-calling structure in a tree format. CALLTREE
 processes BASIC files with no error messages; however, the results are
 not correct.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2, to Microsoft BASIC Professional
 Development System (PDS) Version 7.00, and to Microsoft QuickBASIC
 Versions 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50. (Note: The Microsoft
 M.EXE editor comes with the BASIC compiler 6.00 and 6.00b and
 Microsoft BASIC PDS Version 7.00 but not with any version of the
 QuickBASIC package.)

 Code Example
 ------------

 The following is the BASIC SOURCE FILE for testing CALLTREE:

 DECLARE SUB anysub1 ()
 DECLARE SUB anysub3 ()
 DECLARE SUB anysub2 ()

 CLS
 CALL anysub3
 END

 SUB anysub1
   PRINT "inside of subroutine 1"
 END SUB

 SUB anysub2
 PRINT "Inside of subroutine 2"
 CALL anysub1
 END SUB

 SUB anysub3
   PRINT "Inside of subroutine 3"
   CALL anysub2
 END SUB

 The following is the CALLTREE OUTPUT for the above BASIC file:

 anysub1
 anysub3
 anysub2

 The following is the C SOURCE FILE for testing CALLTREE:

 void func1(void)
 {
   printf("Inside of function 1\n");
 }

 void func2(void)
 {
   printf("inside of function 2\n");
   func1();
 }

 void func3(void)
 {
   printf("Inside of function 3\n");
   func2();
 }

 void main(void)
 {
   func3();
 }

 The following is the CALLTREE OUTPUT for the above C program:

 func1
 |   printf?
 func2
 |   printf?
 |   func1
 |   |   printf?
 func3
 |   printf?
 |   func2
 |   |   printf?
 |   |   func1
 |   |   |   printf?
 main
 |   func3
 |   |   printf?
 |   |   func2
 |   |   |   printf?
 |   |   |   func1
 |   |   |   |   printf?


 102. BC 6.00's BUILDRTM Has Not Been Tested with QB 4.50's Compiler

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified:  4-JAN-1990    ArticleIdent: Q43931

 QuickBASIC Version 4.50 has not been tested with the BUILDRTM.EXE
 found in Microsoft BASIC Compiler Versions 6.00 and 6.00b and
 Microsoft BASIC PDS Version 7.00. Microsoft does not claim that
 BUILDRTM.EXE will work correctly with object modules compiled using
 the BC.EXE compiler from QuickBASIC 4.50.

 "Unresolved Externals" during linkage is one of the reported errors
 that occurs when using the BUILDRTM.EXE on an object module compiled
 with the BC.EXE from QuickBASIC 4.50.

 BUILDRTM is designed for use only with Microsoft BASIC Compiler
 Versions 6.00 and 6.00b for MS-DOS and OS/2 and Microsoft BASIC PDS
 Version 7.00 for MS-DOS and OS/2. BUILDRTM adds routines to extend the
 BRUN6xx.EXE run-time libraries for Versions 6.00 and 6.00b and the
 BRT70xxx.EXE run-time libraries for BASIC PDS 7.00.


 103. MARKEXE.EXE in OS/2 May Cause .EXE Hang at Run Time

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890424-101
 Last Modified:  4-JAN-1990    ArticleIdent: Q44230

 Microsoft BASIC Compiler programs running in OS/2 protected mode take
 over the full screen by default and will not run from an OS/2
 Presentation Manager (PM) windowed environment unless you first alter
 the .EXE program's header with the MARKEXE utility or with PM's Start
 Programs window (as shown further below).

 It has been reported that system crashes may intermittently occur
 while running graphics-mode programs from the PM windowed environment.
 Only nongraphics programs using SCREEN 0 in a PM windowed environment
 seem to work without problems, and this is not always the case either.
 It has also been reported that system crashes have occurred while
 running character-mode (SCREEN 0) programs from within a PM windowed
 environment.

 Microsoft has not tested programs running within a PM window that were
 compiled with Microsoft BASIC Compiler Versions 6.00, 6.00b, or
 Microsoft BASIC PDS Version 7.00. This feature is under review and
 will be considered for inclusion in a future release.

 While there are problems running BASIC programs from within a PM
 window, you can write OS/2 Presentation Manager (PM) applications
 using BASIC compiler Versions 6.00 and 6.00b and BASIC PDS Version
 7.00. This information is detailed in a separate article that can be
 found by querying on the following words:

   OS/2 and Presentation and Manager and BASIC

 The MARKEXE.EXE utility program is shipped on the Toolkit 1 disk
 with the Microsoft OS/2 Software Development Kit and is used for
 altering the header of a bound or protected-mode executable program
 (.EXE) to run from a PM windowed environment. The following is an
 example of running MARKEXE:

    MARKEXE progname windowcompat

 Another method to modify your compiled BASIC .EXE to run under a PM
 window (in protected mode) is to do the following:

 1. Choose the Add option from the Program menu of the Start Programs
    window in PM.

 2. Choose Change from the Program menu. The Change Program Information
    window now appears.

 3. Choose Other for the Program Type. Press the ENTER key. The How To
    Run The Program window now appears.

 4. Choose Run The Program In A Text Window to run your program in a
    PM window. Press the ENTER key.

 You can now run your program in a PM window from OS/2's Start Program
 window or from the OS/2 full-screen command prompt.

 If the program is deleted from the Start Program menu, the .EXE header
 is changed back to what it was prior to being entered into the Start
 Program menu.


 104. LPOS(0) and LPOS(1) Both Return Print Head Position for LPT1

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | docerr B_QuickBas
 Last Modified:  2-FEB-1990    ArticleIdent: Q45420

 The LPOS(0) and LPOS(1) functions both return the current position of
 the print head within the printer buffer for LPT1. LPOS(2) returns
 the current print position for LPT2.

 On Page 263 of the "Microsoft BASIC Compiler 6.0: BASIC Language
 Reference" manual for Versions 6.00 and 6.00b for MS OS/2 and MS-DOS,
 the program example uses LPOS(0) to return the current position of the
 line printer's print head within the print buffer, but no mention is
 made of LPOS(0) in the function description. LPOS(0) operates the same
 as LPOS(1), and there is no difference between the two functions.

 This information applies also to Page 263 of the "Microsoft QuickBASIC
 4.0: BASIC Language Reference" manual for QuickBASIC Versions 4.00 and
 4.00b, to Page 224 of the "Microsoft QuickBASIC 4.5: BASIC Language
 Reference" for Version 4.50, and to the QuickBASIC Version 4.50 QB
 Advisor online Help system.

 This documentation error was corrected on Page 204 of the "Microsoft
 BASIC 7.0: Language Reference" manual for Microsoft BASIC Professional
 Development System (PDS) Version 7.00.


 105. CodeView Can't Watch Array Passed to BASIC SUBprogram

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas buglist6.00 buglist6.00b buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q47060

 When debugging a BASIC program (compiled with BC.EXE versions 7.00 and
 earlier) with Microsoft CodeView (version 2.20, 2.30, 2.35, 3.00, or
 3.10), an attempt to watch an array passed to a SUBprogram produces
 the error "Not an array."

 Microsoft has confirmed this to be a problem in QuickBASIC versions
 4.00, 4.00b, and 4.50 (even though they do not provide CodeView on the
 release disks) (buglist4.00, buglist4.00b, buglist4.50); in Microsoft
 BASIC Compiler versions 6.00 and 6.00b (which provide CodeView version
 2.20 on the release disks); and in Microsoft BASIC Professional
 Development System (PDS) version 7.00 (which provides CodeView version
 2.35 on the release disks). This problem is corrected by compiling the
 program with BASIC PDS version 7.10 and using Microsoft CodeView
 version 3.10, which comes with BASIC PDS 7.10.

 As a workaround in earlier versions, you can make the array global by
 putting it in a COMMON statement and not passing it through a CALL
 statement's parameter list.

 Note that CodeView version 2.20 is shipped with Microsoft BASIC
 Compiler versions 6.00 and 6.00b; CodeView 2.30 is shipped with
 Microsoft FORTRAN version 5.00; CodeView version 2.35 is shipped with
 Microsoft BASIC Professional Development System (PDS) version 7.00;
 CodeView version 3.00 is shipped with Microsoft C Compiler version
 6.00; and CodeView 3.10 is shipped with Microsoft BASIC PDS version
 7.10.

 The following program is CVTEST.BAS, which demonstrates the above
 problem when compiled in BC.EXE 7.00 or earlier, and run under
 Microsoft CodeView:

    DECLARE SUB test (a() AS INTEGER)
    DIM a(5) AS INTEGER
    a(3) = 3
    PRINT a(3)
    CALL test(a())
    END

    SUB test (a() AS INTEGER)
      PRINT a(3)
    END SUB

 To demonstrate the problem, compile and link as follows:

    BC /Zi TEST.BAS;
    LINK /CO TEST;

 Load the program into CodeView (CV.EXE) and set a Watch (CTRL+W) on
 the variable a(3), then single-step the program (by pressing function
 key F8) until you execute the PRINT a(3) statement inside the
 SUB...END SUB procedure. At this point, the "Not an array" error
 message appears.

 Additional article reference words: S_CodeView


 106. Using BASIC to Perform Serial Communications in MS OS/2

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S890801-2
 Last Modified: 17-JAN-1991    ArticleIdent: Q48400

 This article contains a sample BASIC module that calls API routines in
 MS OS/2 protected mode to perform serial communications through
 communications port COM1, COM2, COM3, or COM4.

 You must link NOCOM.OBJ (which requires BC /O) with this module before
 attempting to use this module's routines.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 (in protected mode only) and to Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for MS
 OS/2 (in protected mode only).

 The following steps must be taken to use the COMPORT.BAS module
 (farther below):

 1. Create a program called COM.BAS that makes calls to the routines
    found in COMPORT.BAS and compile the program.

 2. Compile COMPORT.BAS. Ensure that COMPORT.BI (shown below) and
    BSEDOSFL.BI (included with BASIC compiler 6.00/6.00b and BASIC
    PDS 7.00/7.10) are in a directory that is in the $INCLUDE
    statement's explicit path.

 3. Link your program to COMPORT.OBJ in addition to NOCOM.OBJ.

 The following is a sample file that, when used as input for the MAKE
 utility, compiles and links a program called COM.BAS that uses the
 COMPORT module:

 #----------------------
 # MAKE file for COM.BAS
 #----------------------
 comport.obj : comport.bas comport.bi
      BC /LP /Z /O /D COMPORT.BAS;
 com.obj : com.bas comport.bi
      BC /LP /Z /O /D COM.BAS;
 com.exe : com.obj comport.obj
      link /EX com comport nocom;

 COMPORT.BI
 ----------

 ' parameter buffer for DosDevIOCtrl Function 41H
 TYPE F41Info
     BaudRate AS INTEGER
 END TYPE

 ' parameter buffer for DosDevIOCtrl Function 42H
 TYPE F42Info
     DataBits AS STRING * 1
     Parity AS STRING * 1
     StopBits AS STRING * 1
 END TYPE

 ' data buffer for DosDevIOCtrl Function 68H
 TYPE F68Info
     NumChars AS INTEGER   ' Number of characters waiting in
                           '   device queue
     QueueSize AS INTEGER  ' Size of queue
 END TYPE

 DECLARE FUNCTION InitComPort% (ComPort$, Baud%, Parity%,_
                                DataBit%,StopBit%)
 DECLARE SUB WriteCom (Handle%, ToCom$, BytesWritten%)
 DECLARE SUB PrintCom (Handle%, ToCom$, BytesWritten%)
 DECLARE SUB ReadCom (Handle%, FromCom$, BytesToRead%,_
                      BytesRead%)
 DECLARE SUB ComSize (Handle%, Size%)
 DECLARE SUB CloseCom (Handle%)

 COMPORT.BAS
 -----------

 ' $INCLUDE: 'COMPORT.BI'
 ' $INCLUDE: 'BSEDOSFL.BI'
 ' Note:
 '       These routines call OS/2 system functions
 ' that always return a value indicating whether or not an
 ' error has occurred. In this module, ReturnErr% always
 ' contains this value. A return value of 0 means no error
 ' occurred. This module does no error checking. This would
 ' have to be added using the values in ReturnErr%.
 '       For added flexibility in configuring the port, use
 ' DosDevIOCtrl Function 53H.
 '       All of the routines in this module (except
 ' InitComPort%) need a Handle% as one of the parameters.
 ' This Handle% is obtained from InitComPort%

 '***********************************************************
 ' InitComPort% returns a handle to the comport specified in
 ' the parameter ComPort$ (must be in the form: "COMn" where
 ' n is a number between 1 and 4.) Before the handle to the
 ' port is returned, the port is configured to the correct
 ' baud rate (110 to 19200), parity, data bit, and stop bit.
 '***********************************************************
 FUNCTION InitComPort% (ComPort$, Baud%, Parity%, DataBit%,_
                        StopBit%)
     DIM F42 AS F42Info
     DIM F41 AS F41Info
     DIM Temp AS STRING * 5 'Temp holds string of form "COMn"+null byte
     Temp = ComPort$
     F41.BaudRate = Baud%
     F42.DataBits = CHR$(DataBit%)
     F42.Parity = CHR$(Parity%)
     F42.StopBits = CHR$(StopBit%)

     ReturnErr% = DosOpen% (VARSEG(Temp), VARPTR(Temp),_
                            Handle%,_
                            Action%,_
                            0,_
                            0,_
                            1,_
                            &H12,_
                            0)
     IF (ReturnErr% = 0) THEN
         ReturnErr% = DosDevIOCtl%(0, 0,_
                                   VARSEG(F41), VARPTR(F41),_
                                   &H41,_
                                    1,_
                                    Handle%)
         ReturnErr% =  DosDevIOCtl%(0, 0,_
                                    VARSEG(F42),VARPTR(F42),_
                                    &H42,_
                                    1,_
                                    Handle%)
     END IF
     InitComPort% = Handle%
 END FUNCTION

 '***********************************************************
 ' WriteCom writes a string (ToCom$) to the port associated
 ' with Handle%. BytesWritten% will contain the actual
 ' number of bytes written after the call to WriteCom.
 '***********************************************************
 SUB WriteCom (Handle%, ToCom$, BytesWritten%)
     DIM Temp AS STRING * 512
     Temp = ToCom$
     Length = LEN(ToCom$)
     ReturnErr% = DosWrite%(Handle%,_
                            VARSEG(Temp), VARPTR(Temp),_
                            Length,_
                            BytesWritten%)
 END SUB

 '***********************************************************
 ' PrintCom Prints a string (ToCom$) to the port associated
 ' with Handle%. The string is written and an additional CR
 ' and LF. BytesWritten% will contain the actual number of
 ' bytes written after the call to PrintCom.
 '***********************************************************
 SUB PrintCom (Handle%, ToCom$, BytesWritten%)
     ToCom$ = ToCom$ + CHR$(13) + CHR$(10)
     DIM Temp AS STRING * 512
     Temp = ToCom$
     Length = LEN(ToCom$)
     ReturnErr% = DosWrite%(Handle%,_
                            VARSEG(Temp), VARPTR(Temp),_
                            Length,_
                            BytesWritten%)
 END SUB

 '***********************************************************
 ' ReadCom reads BytesToRead% number of bytes from the port
 ' associated with Handle%. The bytes read are placed in
 ' FromCom$, and the number of bytes read will be placed in
 ' BytesRead%.
 '***********************************************************
 SUB ReadCom (Handle%, FromCom$, BytesToRead%, BytesRead%)
     DIM Temp AS STRING * 512
     ReturnErr% = DosRead%(Handle%,_
                           VARSEG(Temp), VARPTR(Temp),_
                           BytesToRead%,_
                           BytesRead%)
     FromCom$ = MID$(Temp,1,BytesRead%)
 END SUB

 '***********************************************************
 ' ComSize returns the number of bytes waiting to be read at
 ' the port associated with Handle%. The number of bytes
 ' waiting is placed in Size%.
 ************************************************************
 SUB ComSize (Handle%, Size%)
     DIM F68 AS F68Info
     DIM FileInfo AS FILESTATUS
     ReturnErr% = DosDevIOCtl%(VARSEG(F68), VARPTR(F68),_
                               0, 0,_
                               &H68,_
                               1,_
                               Handle%)
     Size% = F68.NumChars
 END SUB

 '***********************************************************
 ' CloseCom closes the port associated with Handle%. This
 ' should be called before the end of the program.
 '***********************************************************
 SUB CloseCom (Handle%)
     ReturnErr% = DosClose% (Handle%)
 END SUB


 107. OS/2 Program Selector Fails to Show DOS Box If Using SCREEN 3

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | SR# S891010-116 B_QuickBas
 Last Modified: 15-DEC-1989    ArticleIdent: Q50625

 The Program Selector of OS/2 Version 1.00 or 1.10 can't correctly
 switch to the screen of a running BASIC application that is currently
 using SCREEN 3 (Hercules graphics) in the DOS 3.x box (real mode). To
 work around this OS/2 limitation, you must stop the BASIC program with
 CTRL+BREAK or switch back to SCREEN 0 (or text mode) within the
 program.

 This behavior occurs in Microsoft QuickBASIC Versions 4.00, 4.00b, and
 4.50 for MS-DOS, in Microsoft BASIC Compiler Versions 6.00 and 6.00b
 for MS-DOS and MS OS/2, and in Microsoft BASIC PDS 7.00 for MS-DOS
 and MS OS/2.

 The Program Selector of OS/2 Version 1.00 or 1.10 is a simple
 interface that runs in character mode. When you invoke the OS/2 DOS
 box when it is running a program in Hercules graphics mode, OS/2
 maintains character mode and can't refresh the Hercules screen.
 QuickBASIC thinks it is still running under SCREEN 3 and the output is
 incorrect. Text mode must be reinvoked to restore visibility in the
 DOS box.

 Note that this problem does not occur for non-Hercules graphics screen
 modes (CGA, EGA, VGA) or for the Task Manager of OS/2 Presentation
 Manager (which can't run on Hercules graphics cards anyway).

 When you choose MS-DOS Command Prompt from the Switch To A Running
 Program menu in the OS/2 1.10 Program Selector screen and press ENTER,
 the highlighting on the menu selection disappears, the mouse pointer
 (if any) disappears, and the Program Selector appears to be hung
 (frozen) on the screen. If the BASIC program in the DOS box scrolls
 the screen during this time, the Program Selector will scroll upward
 showing some BASIC output, but the display will be incorrect
 (garbage).

 To stop the apparent hang or garbage on the screen, press CTRL+BREAK
 to abort the BASIC program and switch the screen over to text mode,
 thus making the DOS box visible. You can also press CTRL+ESC or
 ALT+ESC to go back to OS/2 at any time.

 Example
 -------

 To duplicate the problem, invoke the OS/2 Program Selector (CTRL+ESC),
 and then select MS-DOS Command Prompt from the Switch To A Running
 Program menu. Run the following code in the QuickBASIC QB.EXE editor
 or in a compiled .EXE program:

    SCREEN 3
    PRINT "This is a test"
    idle: GOTO idle

 [You must compile the .EXE program with /D (debug) so that CTRL+BREAK
 can stop the continuous loop in the program.] Invoke the OS/2 Program
 Selector (CTRL+ESC), and then select MS-DOS Command Prompt again. The
 menu highlight will disappear and the Program Selector screen will
 remain intact. The system will appear to be hung, but you are actually
 in the BASIC program. Pressing CTRL+BREAK will stop execution of the
 BASIC program and switch the DOS box back to text mode. When this is
 done, the Program Selector screen will be replaced with the DOS box
 screen.

 Note that if the BASIC application is not provided with a means to
 terminate or switch to the text mode screen, then the DOS box (for all
 practical purposes) will be hung. Technically, it can still be
 accessed by the keyboard, but the screen is never displayed correctly
 unless the program itself reinvokes SCREEN 0. The only way out of this
 condition is to reboot the computer.


 108. BASIC Program to Tell If Expanded Memory Driver Is Resident

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified: 26-FEB-1990    ArticleIdent: Q51293

 The following program shows how to determine if an expanded memory
 driver [or Expanded Memory Manager (EMM)] is loaded under MS-DOS. This
 program can be used either in the QuickBASIC editor or in an .EXE
 program created with the BC.EXE BASIC compiler under MS-DOS. This
 program also determines the amount of available expanded memory and
 the Lotus/Intel/Microsoft (LIM) specification version number of the
 EMS (Expanded Memory Specification) driver. For more information,
 refer to Pages 204-206 in "Advanced MS-DOS Programming, 2nd Edition"
 by Ray Duncan (Microsoft Press, 1988).

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50 for MS-DOS, to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS, and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 Note that Microsoft BASIC PDS 7.00 introduces support for LIM 4.0 EMS
 (Expanded Memory Specification) for the following features: ISAM file
 buffers, the QBX.EXE editor environment, and LINK overlays at run
 time. Microsoft BASIC Compiler Versions 6.00b and earlier and
 QuickBASIC Versions 4.50 and earlier don't support expanded memory,
 ISAM, or LINK overlays.

 If an EMM driver is loaded, it is hooked to Interrupt 67 hex. This
 means that the address stored in the interrupt vector table for
 interrupt 67 hex points to the beginning of the driver. The device
 name for an Expanded Memory Manager driver must be "EMMXXXX0". This
 device name is located 0A hex bytes into the device header. This name
 can be checked to determine if a legitimate driver has been loaded. If
 this name is not found, you can assume that no expanded memory support
 is available.

 The strategy used in the program below is to use the DOS service
 (Interrupt 21 hex, function 35 hex) to get the address of the driver
 and then check the driver header found at that address for the correct
 name. Once the program determines that an expanded memory driver is
 available, it can access the driver through interrupt 67 hex, with
 functions 42 hex and 46 hex, to obtain the amount of expanded memory
 and LIM version numbers, respectively. The code example below
 illustrates one method for accomplishing this in Microsoft BASIC.

 For more information about how to use INTERRUPT or INTERRUPTX to
 access a DOS interrupt, ROM BIOS interrupt, or any other interrupt
 service, query for a separate article with the following word: QB4INT

 For more information about the interrupts necessary to access LIM EMS,
 see Pages 25-68 of "MS-DOS Extensions: Programmer's Quick Reference,"
 by Ray Duncan (Microsoft Press, 1989).

 Sample Program
 --------------

 '----------------------------- EXPCHK.BAS --------------------------
 '
 '   This program determines if an Expanded Memory Driver is loaded,
 '   displays the amount of available expanded memory, raw page
 '   size, EMM driver status, and the version number of the
 '   Lotus/Intel/Microsoft Expanded Memory Specification.

 '$INCLUDE: ''QBX.BI'              'Data Declarations for CALL INTERRUPT(X)
 DIM InRegsx AS RegTypeX, OutRegsx AS RegTypeX
 DIM InRegs AS RegType, OutRegs AS RegType
 DIM buffer(0 TO 4) AS INTEGER
 CLS
 LOCATE 10
 '-------------------------------------------------------------------
 'The Expanded Memory Manager is accessed through Interrupt &H67 if
 'present. Use the DOS Get Interrupt Vector (interrupt 21 hex, with
 'function 35 hex) service to retrieve the address of the device
 'driver and then get the device name from there. If the name is found
 'to be "EMMXXXX0", then the driver is loaded and calls can be made to
 'it.
 '-------------------------------------------------------------------

 InRegsx.ax = &H3500 + &H67         'DOS Get Interrupt Address Service
 InRegsx.ds = -1                    'Retain current DS and ES values
 InRegsx.es = -1
 CALL INTERRUPTX(&H21, InRegsx, OutRegsx)
 EMMDriverSEG = OutRegsx.es         'Segment of INT 67 EMM driver
 EMMDriverOFF = OutRegsx.bx         'Offset  of INT 67 EMM driver

 DEF SEG = EMMDriverSEG
 index = &HA   'Driver name located at offset &H0A into device header
 DO UNTIL LEN(EMMName$) > 7         'Retrieve Device Name (8 chars)
         EMMName$ = EMMName$ + CHR$(PEEK(index))
         index = index + 1
 LOOP

 IF EMMName$ = "EMMXXXX0" THEN
         PRINT TAB(10); "Expanded Memory Available"
 ELSE
         PRINT TAB(10); "No Expanded Memory Driver Loaded"
         END
 END IF

 InRegs.ax = &H4000                'EMM get status function
 CALL INTERRUPT(&H67, InRegs, OutRegs)

 IF OutRegs.ax < 0 THEN            'Isolate high byte of AX
         highbyte = (OutRegs.ax + 2 ^ 16) \ 256&   'High bit set case
 ELSE
         highbyte = OutRegs.ax \ 256&
 END IF

 IF highbyte = 0 THEN          'Check for error codes in AH
         PRINT TAB(10); "Extended Memory Driver Status: FUNCTIONAL"
 ELSE
         PRINT TAB(10); "Extended Memory Driver Status: NON-FUNCTIONAL"
         PRINT TAB(10); "Error Code: "; OutRegs.ax
 END IF

 InRegs.ax = &H4600                        'EMM get version function
 CALL INTERRUPT(&H67, InRegs, OutRegs)
 LimVersion$=LEFT$(HEX$(OutRegs.ax),1) + "." + RIGHT$(HEX$(OutRegs.ax),1)
 PRINT TAB(10); "LIM Version "; LimVersion$; " Driver Installed"

 InRegs.ax = &H4200                  'EMM get number of pages function
 CALL INTERRUPT(&H67, InRegs, OutRegs)

 IF OutRegs.ax < 0 THEN                      'Isolate high byte of AX
         highbyte = (OutRegs.ax + 2 ^ 16) \ 256&
 ELSE
         highbyte = OutRegs.ax \ 256&
 END IF

 IF highbyte = 0 THEN
         PRINT TAB(10); "Total Number of 16K Pages Available: "; OutRegs.dx
         total& = OutRegs.dx * 16 * 1024& \ 1048576  'Convert to Megabytes
         PRINT TAB(10); "Total Expanded Memory: "; total&; " Megabytes"
 ELSE
         PRINT TAB(10); "Error Determining Number of Expanded Memory Pages"
         PRINT TAB(10); "Error Code: "; OutRegs.ax
 END IF

 DEF SEG                                'Restore original state
 IF VAL(LimVersion$) >= 4! THEN  'This only supported LIM 4.0 and later
    InRegsx.ax = &H5900  'EMM Get hardware config (Page Size) function
    InRegsx.es = VARSEG(buffer(0))
    InRegsx.di = VARPTR(buffer(0))
    CALL INTERRUPTX(&H67, InRegsx, OutRegsx)
    IF OutRegsx.ax < 0 THEN
       highbyte = (OutRegsx.ax + 2 ^ 16) \ 256&
    ELSE
       highbyte = OutRegsx.ax \ 256&
    END IF

    IF highbyte = 0 THEN
       size = buffer(0) * 16& \ 1024  'Convert paragraphs to Kilobytes
       PRINT TAB(10); "Raw Expanded Memory Page Size: "; size; " Kilobytes"
    ELSE
       PRINT TAB(10); "Error in determining Raw Page Size."
       PRINT TAB(10); "Error Code: "; OutRegsx.ax
    END IF
 ELSE
    PRINT TAB(10); "Raw Expanded Memory Page Size: 16 Kilobytes"
 END IF

 END


 109. STACK STACK Correctly Gives "Out of Memory" in QBX.EXE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891019-160
 Last Modified: 12-DEC-1989    ArticleIdent: Q51413

 If you run a program containing the statement STACK STACK in the
 QBX.EXE environment and then attempt to edit the program, the error
 message "Out of memory" will result. The error message can be
 prevented by going to the Immediate window in QBX and executing the
 STACK statement to reset the stack size to the default. The error
 occurs because the STACK STACK statement allocates all available
 memory in the data segment for the stack. However, QBX needs to use
 part of this segment for its own purposes.

 This information applies to Microsoft BASIC PDS Version 7.00 for
 MS-DOS.


 110. Internal Format of CURRENCY Data Type in BASIC PDS 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 21-FEB-1991    ArticleIdent: Q51414

 The CURRENCY data type available in Microsoft BASIC Compiler versions
 7.00 and 7.10 for MS-DOS and OS/2 is an 8-byte signed integer scaled
 by 10,000. This allows a variable of the CURRENCY type to have a range
 of

    (2 ^ 63 -1) / 10,000  =  +922337203685477.5807

 to

    (2 ^ 63) / 10,000   =  -922337203685477.5808

 Up to 19 digits are allowed, with no more than 4 digits to the right
 of the decimal point.

 Because the CURRENCY type is scaled by 10,000, its internal
 representation is the actual value multiplied by 10,000. For instance,
 a CURRENCY variable holding the value 0.0001 will be stored as
 follows:

    HIGH BYTE                                                     LOW BYTE
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

 As with ordinary INTEGERs, the higher byte is stored at the higher
 memory address so that once you find the address of the variable, you
 will find the low byte there, the second byte stored above, the third
 byte above that, etc. The example program below displays the
 hexadecimal machine representation for a CURRENCY data type variable
 whose value is INPUT from the keyboard.

 Sample Code:

 '******************************************************************
 '     Sample program to display machine representation of the     *
 '     CURRENCY data type (8-byte scaled INTEGER)                  *
 '******************************************************************
 CLS
 DO UNTIL INKEY$ = CHR$(27)
   PRINT "Enter a CURRENCY value.  The machine representation will be "
   PRINT "displayed in Hex"
   INPUT a@                   ' "@" is the CURRENCY data type suffix.
   address% = VARPTR(a@)      ' Get the address of the variable a@

   FOR i% = 7 TO 0 STEP -1
      PRINT HEX$(PEEK(address% + i%)); "  ";  ' Display representation
   NEXT i%                                    ' in normal Low-Byte to
                                              ' the right form.
   PRINT
   PRINT "press a key to continue, Esc to EXIT"
   SLEEP
 LOOP


 111. PDS 7.00 Alert FUNCTION Return Value Description Incorrect

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891101-66 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q51415

 The Alert FUNCTION in the WINDOW.BAS file of the User Interface (UI)
 Toolbox is incorrectly described in the documentation. On Page 553 of
 the "Microsoft BASIC 7.0: Language Reference" manual (for 7.00 and
 7.10), the "Syntax" section incorrectly shows that the Alert FUNCTION
 will return a string. The "Remarks" section and the source code in
 WINDOW.BAS correctly show that the Alert FUNCTION actually returns an
 INTEGER from 1 to 3.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The "Syntax" section of the Alert FUNCTION description reads as
 follows:

    Syntax   variablename$ = Alert(style%,text$,row1%,...etc.

 It should read as follows:

    Syntax   variablename% = Alert(style%,text$,row1%,...etc.

 The dollar sign ($) appended to "variablename" should be a percent
 sign (%) because the Alert FUNCTION returns an integer.


 112. How to Use Link Overlays in BASIC PDS 7.00 and 7.10

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891017-94 S_LINK
 Last Modified:  5-SEP-1990    ArticleIdent: Q51416

 When using the linker (LINK.EXE) to generate code overlays for
 Microsoft BASIC Professional Development System (PDS) version 7.00 or
 7.10 under MS-DOS, you must put the modules you want to overlay in
 parentheses on the LINK command line. The modules that make up one
 overlay must be compiled with the same switches. Code is the only part
 of the program that is overlaid. Data is not overlaid. Examples and
 further restrictions for using linker overlays are given below.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS (but does NOT apply to earlier BASIC compiler versions).

 Note that link overlays are not needed and not supported under OS/2
 protected mode, since OS/2 itself automatically provides a similar
 feature to support swapping of very large .EXE programs in OS/2's
 extended and virtual memory.

 The following is an example of how to produce code overlays

    LINK test1+(test2+test3)+test4+(test5)+(test6),TEST1.EXE,TEST1.MAP;

 where the following apply:

 1. test1 (TEST1.OBJ) is the main module.

 2. test2 and test3 (TEST2.OBJ and TEST3.OBJ) are separately compiled
    modules that make up one overlay.

 3. test4 (TEST4.OBJ) stays resident in memory along with the main
    module (test1) at run time and is not swapped out of memory to disk.

 4. test5 and test6 (TEST5.OBJ and TEST6.OBJ) are two separate overlays.

 5. TEST1.EXE is the executable overlaid program created by this LINK.

 6. TEST1.MAP is a text file (created by the above LINK) that tells
    you the code sizes of all overlays and procedures.

 To invoke an overlay, you call a SUB or FUNCTION in a module contained
 in that overlay, and the Overlay Manager automatically moves the
 overlay (if it is not already loaded) into DOS memory, overlaying any
 previous overlay in memory.

 You can call any module or overlay from any other module or overlay.

 Overlays provide an alternative to CHAINing when a program is too
 large to fit into memory all at once. An overlaid program is made up
 of a single .EXE file (which can be an advantage in some cases),
 unlike CHAINed programs, which are composed of several .EXE files.

 Restrictions on Using Overlays
 ------------------------------

 The restrictions on using overlays in Microsoft BASIC PDS versions
 7.00 and 7.10 for MS-DOS are as follows:

 1. Each Microsoft BASIC overlay cannot exceed 256K in code (see LINK
    .MAP for size of each overlay). You can have up to 64 overlays
    per .EXE program. This means you may be able to make .EXE programs
    up to 16 MB in code size under MS-DOS.

 2. The main module must be the first module in the LINK command line,
    and it must NOT be specified as an overlay. If you incorrectly make
    the first module in the LINK command line an overlay, the machine
    will hang when the program first loads.

 3. When you create an overlaid version of a program, make sure that
    each module contained in the program is compiled with the same
    options.

 4. You cannot use the LINK /PACKCODE or /EXEPACK option when linking a
    program that uses overlays.

 5. You cannot have a stub file as an overlay. Do not specify stub
    files (NOxxx.OBJ) in the parentheses for link overlays, or the
    program will hang. Stub files may only be specified outside
    parentheses in the LINK command line.

 Using Expanded Memory with Overlays
 -----------------------------------

 386Max (386MAX.SYS) from Qualitas, Inc. is an example of an expanded
 memory driver that can be used with BASIC PDS 7.00 and 7.10. BASIC PDS
 7.00 and 7.10 require an expanded memory driver that uses the
 Lotus-Intel-Microsoft (LIM) version 4.0 Expanded Memory Specification
 (EMS).

 If you have loaded an expanded memory driver, and if all the overlays
 can fit together at one time in expanded memory, and if each overlay
 has less than 64K of code, then overlays are loaded from expanded
 memory. Otherwise, overlays are swapped from disk, which is slower
 than loading from expanded memory.

 Assume that the overlaid program satisfies the above conditions for
 using expanded memory. Note that the overlaid modules are not loaded
 when the EXE file is first invoked. They remain on disk until the
 first overlay is called. When this occurs, all the overlaid modules
 are loaded at once from disk into expanded memory. From then on, the
 overlays are swapped from expanded memory into DOS memory, and the
 disk is no longer used for loading overlays.

 The overlay manager in BASIC 7.00 and 7.10 requests expanded memory in
 16K pages (blocks). The overlay manager only knows the size of the
 largest overlay, and must make a "best guess" at the size of the
 smaller overlays. When the overlay manager estimates how many 16K
 pages are necessary to hold all overlays at once in expanded memory,
 the estimate could be over or under the actual number of pages needed.
 If your overlays are all between 16K and 64K in size (according to the
 LINK .MAP file), and if the estimated or actual size of all overlays
 together exceeds the available expanded memory, the following
 initialization error occurs when the first overlay is called at
 run-time:

    Insufficient EMS to load overlays

 Note: This error is documented on Page 656 of the "Microsoft BASIC
 7.0: Language Reference" manual for versions 7.00 and 7.10. You will
 never see this error if all your overlays are smaller than 16K each.

 If you want to force loading overlays from disk, thus avoiding the
 possibility of this overlay initialization error in expanded memory,
 you must link with the stub file NOEMS.OBJ (with no parentheses around
 NOEMS.OBJ on the LINK command line). Alternatively, you can try
 reconfiguring expanded memory so more of it is available for BASIC
 overlays. Another alternative is to make overlays similar in size.

 DOS Memory Map When Using Overlaid .EXE Program
 ------------------------------------------------

 [Low Memory]

 * MS-DOS.
 * Main program and non-overlaid modules.
 * Contiguous overlay memory area, equal to the size of biggest overlay.
 * DGROUP (default data segment, which is shared by all routines).
 * Far heap (dynamic non-variable-length-string arrays).
 * BASIC's run-time support module if .EXE not compiled stand-alone (BC /O)

 [High Memory]

 For more information on using overlays, see the section "Linking with
 Overlays" on Pages 612-614 in the "Microsoft BASIC 7.0: Programmer's
 Guide."


 113. CURRENCY Data Type Not Available in Alternate Math (BC /FPa)

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  6-AUG-1990    ArticleIdent: Q51417

 The CURRENCY data type available in Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 can be used only with
 the coprocessor/emulation math package (BC /FPi, the default). The
 CURRENCY type is not supported in the alternate math package (BC /FPa
 option). Trying to compile a program that uses CURRENCY variables with
 the alternate math package results in "Currency type illegal in
 alternate math pack" errors.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The implementation of a CURRENCY data type for alternate math would
 have delayed the release of BASIC PDS 7.00 and 7.10, keeping the
 product from developers who need the other new features. This feature
 is under review and will be considered for inclusion in a future
 release.

 The CURRENCY data type is not found in Microsoft BASIC Compiler
 versions earlier than Microsoft BASIC PDS version 7.00.

 You can declare a variable with the CURRENCY data type by appending
 the variable name with the suffix @ (the "at" sign), or you can use
 the DIM statement with the AS CURRENCY clause (DIM x AS CURRENCY).


 114. EXT.H, EXTHDR.H Files Don't Come with BASIC 6.00 or COBOL 3.00

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | B_COBOL S_QuickC S_C
 Last Modified: 15-DEC-1989    ArticleIdent: Q51603

 EXT.H and EXTHDR.H, the files necessary to write C extensions for the
 Microsoft Editor (M.EXE and MEP.EXE), are not included with the
 Microsoft Editor software for the following products:

    Microsoft BASIC Compiler Version 6.00 or 6.00b for MS-DOS and OS/2
    Microsoft BASIC PDS Version 7.00 for MS-DOS and OS/2
    Microsoft COBOL Compiler Version 3.00 or 3.00a for MS-DOS and OS/2

 As EXT.H and EXTHDR.H are included with the Microsoft C Compiler 5.10,
 the lack of EXT.H and EXTHDR.H will only affect those who are writing
 C extensions for the M.EXE or MEP.EXE editor and using Microsoft
 QuickC.


 115. Example of Gaussian Elimination; Matrix Math in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 13-DEC-1989    ArticleIdent: Q51605

 This article explains the purpose of Gaussian elimination and gives
 a code example.

 In Microsoft BASIC PDS (Professional Development System) Version 7.00
 for MS-DOS and MS OS/2, the following FUNCTION procedures perform
 Gaussian elimination:

    MatSEqnS% (for single-precision)
    MatSEqnD% (for double-precision)
    MatSEqnC% (for currency data type)

 The source code of all of these functions is provided in the MATB.BAS
 source file on one of the release disks. To use these functions in the
 QuickBASIC Extended editor, load the MATBEFR.QLB Quick library as
 follows:

    QBX /L MATBEFR.QLB

 MATFEFR.QLB and the related .LIB files are mentioned in the $INCLUDE
 file MATB.BI. MATB.BI contains DECLARE FUNCTION statements necessary
 for the matrix math routines.

 Definitions
 -----------

 1. A matrix is a two-dimensional array in BASIC.

 2. A vector is a one-dimensional array in BASIC.

 3. An identity matrix is a square array composed of 1's along the
    diagonal from upper left to lower right, with all else 0's (zeros).

 Gaussian Elimination
 --------------------

 A linear equation of n variables (unknowns) has the following form:

    a1*x1 + a2*x2 + an*xn = b

 where:

    a1 through an and b are known constants, and x1 through xn are
    variables with unknown values.

 Linear equations do not involve any products or roots of variables.
 All variables are to the first power, and don't appear as arguments
 of trigonometric, logarithmic, or exponential functions.

 A solution of a linear equation is a sequence of n numbers (s1 through
 sn) such that the equation is satisfied when we substitute x1=s1,
 x2=s2, ..., xn=sn.

 A set of multiple linear equations in the variables x1 through xn is
 called a system of linear equations. The set (vector) of constants s1
 through sn is called a solution of the system if it provides a
 solution for every equation in the system. Every system of linear
 equations has either no solutions, exactly one solution, or infinitely
 many solutions.

 A system of m linear equations in n unknowns can be written as follows
 in BASIC:

    a(1,1)*x1 + a(1,2)*x2 + ... + a(1,n)*xn = b(1)

    a(2,1)*x1 + a(2,2)*x2 + ... + a(2,n)*xn = b(2)

       ...                  ...

    a(m,1)*x1 + a(m,2)*x2 + ... + a(m,n)*xn = b(m)

 If you mentally keep track of the location of the +'s, the x's, and
 the ='s, the arrays a(m,n) and b(m) provide a shorthand notation for
 the system of linear equations. In elementary linear algebra texts,
 a(m,n) and b(m) together make what is called the "augmented matrix."

 Again, our goal is to discover the unknown values s1 through sn that,
 when assigned to variables x1 through xn, solve every equation.

 Gaussian elimination reduces the augmented matrix [the combination of
 a(m,n) and b(m)] to a matrix of reduced row-echelon form, which looks
 like a square identity matrix attached to a 1 by m vector [ b() ]. The
 vector b() contains the solution set (s1 through sn) of the system of
 linear equations.

 The Gaussian elimination functions MatSEqnS%, MatSEqnD%, and MatSEqnC%
 accept a square matrix a() and a vector b() as input arguments
 (together composing the input-augmented matrix), and give the solution
 in the one-dimensional array b(). After you invoke the function, a()
 is replaced with the identity matrix, and the solution values
 overwrite the input arguments that you had placed in b(). The n
 solution values in b(), when assigned to variables x1 through xn,
 satisfy every equation in the system.

 For more information about linear algebra, the following is an
 excellent text:

    "Elementary Linear Algebra, Second Edition", by Howard Anton,
     published by John Wiley & Sons, 1977

 Code Example
 ------------

 ' This program demonstrates Gaussian elimination to solve a set of
 ' linear equations using double-precision variables.
 ' The MATSEQND, MATSEQNS, and MATSEQNC matrix math routines are
 ' provided in the Matrix Math Toolbox in Microsoft BASIC 7.00 for
 ' MS-DOS and MS OS/2.
 '
 ' To run this program in the QuickBASIC Extended editor, load the
 ' MATBEFR.QLB Quick library as follows:
 '
 '     QBX /L MATBEFR.QLB
 '
 ' MATFEFR.QLB and the related .LIB files are documented in the INCLUDE
 ' file 'MATB.BI' but NOT in "Microsoft BASIC 7.0: Language Reference."

 DECLARE FUNCTION MatSEqnD% (A() AS DOUBLE, b() AS DOUBLE)

 ' The above DECLARE statement is all that is needed from the following
 ' include file:   REM $INCLUDE: 'matb.bi'
 DEFDBL A-Z
 OPTION BASE 1    ' Use OPTION BASE 1 for easier reference.
 DIM A(3, 3), b(3)

 ' The following system of linear equations:
 PRINT "       x +   y + 2*z = 9"
 PRINT "     2*x + 4*y - 3*z = 1"
 PRINT "     3*x + 6*y - 5*z = 0"
 ' ...can be represented in the following matrix:
 '     1  1  2  9
 '     2  4 -3  1
 '     3  6 -5  0
 ' ...which can be placed in arrays a() and b() respectively as follows:
 '     a(1,1)  a(1,2)  a(1,3)  b(1)
 '     a(2,1)  a(2,2)  a(2,3)  b(2)
 '     a(3,1)  a(3,2)  a(3,3)  b(3)
 A(1, 1) = 1
 A(1, 2) = 1
 A(1, 3) = 2
 A(2, 1) = 2
 A(2, 2) = 4
 A(2, 3) = -3
 A(3, 1) = 3
 A(3, 2) = 6
 A(3, 3) = -5
 b(1) = 9
 b(2) = 1
 b(3) = 0
 errcode% = MatSEqnD%(A(), b())
 PRINT "The following values for x, y, and z solve all three equations:"
 PRINT "x="; b(1)
 PRINT "y="; b(2)
 PRINT "z="; b(3)

 ' Here is the output, accurate to within double-precision limits:
 '    x= 1.00000000000001
 '    y= 2
 '    z= 3


 116. EXD Should Be EXP, BASIC 7.00 Page 541 "Programmer's Guide"

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr SR# S891109-123
 Last Modified:  8-JAN-1991    ArticleIdent: Q51861

 EXD should be changed to EXP in the list of transcendental operations
 affected by the NOTRNEMM.LIB stub file on Page 541 of "Microsoft BASIC
 7.0: Programmer's Guide" for 7.00 and 7.10.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 117. Example of Using NPV and IRR Financial Functions in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-JAN-1990    ArticleIdent: Q52068

 This article explains how to use the NPV and IRR financial functions
 in Microsoft BASIC PDS (Professional Development System) Version 7.00
 for MS-DOS and MS OS/2.

 Note that the NPV#, IRR#, and MIRR# functions are used for investments
 that are a series of nonconstant cash payments made at equal
 intervals. You pass the series of nonconstant payments in an array.
 [This contrasts with the financial functions for annuity investments
 (FV#, IPmt#, Rate#, NPer#, PV#, Pmt#, and PPmt#). In an annuity, each
 cash payment is the same constant amount, made at equal intervals.]

 The present value (PV) of a future cash receipt is the amount of money
 that, if received today, would be considered equivalent to the future
 receipt, at a given interest rate. The present value is less than the
 future receipt because you can earn interest on money received today.
 NPV (Net Present Value) compares (subtracts) the current value of a
 series of future cash flows with an amount invested today.

 NPV is useful to compare investment opportunities at a given discount
 (interest) rate. The discount rate (rate#) can be viewed as the rate
 of return you want out of your investment. If NPV is greater than or
 equal to 0, the investment equals or exceeds your interest (discount)
 rate requirement; if NPV is less than 0, the investment does not meet
 your interest rate requirement.

 The NPV#(rate#,valuearray#(),valuecount%,status%) function returns
 Net Present Value. You input the values rate#, valuearray#(), and
 valuecount% (which is the number of array elements), and get back
 status% equals 0 for success, 1 for failure.

 The IRR#(valuearray#(),valuecount%,guess#,status%) function returns
 Internal Rate of Return. IRR returns the discount rate at which NPV
 would return 0 (zero). For a given array of cash flow values, IRR can
 be thought of as an average interest rate (which compounds at each
 period). If IRR is lower than the interest rate you desire for this
 investment, then it is not a good investment.

 The first element of the input cash-flow array should usually be
 negative, indicating your initial investment. A high (positive) income
 early in the value array will make IRR higher than if the same high
 income instead occurred later in the array. This is an example of the
 time value of money.

 Please refer to an elementary accounting textbook for more information
 about these standard Accounting functions.

 Code Example
 ------------

 You can run this program in the QuickBASIC Extended environment with
 QBX /L FINANCER.QLB. To run outside this environment, you must link
 with the appropriate library (FINANCER.LIB, FINANCAR.LIB,
 FINANCEP.LIB, or FINANCAP.LIB).

 REM $INCLUDE: 'FINANC.BI
 DEFDBL A-Z
 OPTION BASE 1
 CLS
 valuecount% = 5   ' = number of cash-flow values in valuearray()
 ' Array holds cash flow values, one value per period (such as per
 ' year):
 DIM valuearray(valuecount%)
 guess = .1        ' Guess the IRR (use .1 if in doubt)

 valuearray(1) = -1000 ' 0. First value negative as initial investment.
 valuearray(2) = 100   ' 1. Return on investment after 1 period.
 valuearray(3) = 200   ' 2. (Positive value is return on investment.)
 valuearray(4) = -300  ' 3. (Negative value is additional investment.)
 valuearray(5) = 1200  ' 4. Return on investment after 4 periods.
 ' For the above values, IRR returns .0514. (5.14% return per period)
 status% = 0

 irreturn = IRR(valuearray(), valuecount%, guess, status%)
 IF status% THEN PRINT "IRR error occurred; try different guess";

 discountrate = irreturn
 netpresval = NPV#(discountrate, valuearray(), valuecount%, status%)

 'Notes for NPV#() function:
 ' If discountrate = value returned by IRR(), then NPV returns zero, as
 '    in the IRR example in the "Microsoft BASIC 7.0: Language
 '    Reference" manual, and also as in this code example.
 ' If discountrate = zero, NPV returns sum of values in valuearray().
 ' If discountrate > zero, NPV returns an amount smaller than sum of
 '    values in valuearray() due to the discount effect at each period.
 ' If discountrate < zero, NPV returns an amount larger than the sum of
 '    the values in valuearray().

 IF status% THEN PRINT "NPV error occurred"
 PRINT "IRR (fractional return on investment per period) = ";
 PRINT USING "##.####"; irreturn
 PRINT "NPV = ";
 PRINT USING "#######.##"; netpresval

 Output
 ------

 For the above values, IRR returns .0514 (5.14 percent return per
 period). NPV returns 0 (zero), since IRR returns the discount rate at
 which NPV returns 0.


 118. MatSEqn FUNCTION Correction Page 506, 7.00 Language Reference

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr SR# S891218-99
 Last Modified:  8-JAN-1991    ArticleIdent: Q52069

 The following two corrections apply to the MatSEqn FUNCTION
 (MatSEqnS%, MatSEqnD%, and MatSEqnC%) on Page 506 of the "Microsoft
 BASIC 7.0: Language Reference" manual (for 7.00 and 7.10):

 1. Insert the text marked in brackets ([]) into the first sentence in
    the Remarks on Page 506, as follows:

    The MatSEqntype% procedure solves a system of linear equations
    contained in [a one-dimensional vector and in] a square matrix...

 2. Insert the sentence marked in brackets ([]) after the fourth
    sentence in the Remarks on Page 506, as follows:

    The first matrix is the square input matrix that contains the
    coefficients for a system of simultaneous equations. [The second
    matrix is used to input the vector of constants for that system
    of simultaneous equations.]

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 For an example of using MatSEqnx (Gaussian elimination), query on
 the following words:

    Gaussian and elimination


 119. Example of PPMT and PMT Financial Functions in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-JAN-1990    ArticleIdent: Q52070

 This program demonstrates the PPMT and PMT financial functions in
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2.

 PMT returns the periodic payment for an investment. In the case of a
 loan, PMT returns the amount of the constant monthly payment (the sum
 of principal plus interest) for the loan, based upon a constant
 interest rate, the total number of payments, and the amount (present
 value) of the loan.

 PPMT is the payment on the principal for an investment at a specified
 period. (PMT minus PPMT is the payment on the interest at a specified
 period.) The sum of all PPMT values returned over the life of the loan
 equals the loan amount.

 Below is an analysis of the finances for buying and selling a house.
 The program returns average equity gain per month after the house has
 been bought and sold. You can change the initial parameters (such as
 houseval, down, rate1, sellper, apprec, etc.) to explore different
 scenarios, including a simplified inflation effect. Negative net
 equity gain per month is outgoing money; positive net equity gain per
 month is income.

 You can choose the period of time at which you sell the house and
 compare the net income or outgo per month to that of your current
 housing situation.

 Run this program with QBX /L FINANCER.QLB in Microsoft BASIC PDS
 Version 7.00 for MS-DOS. To run outside the QBX.EXE environment, you
 must link with the appropriate library (FINANCER.LIB, FINANCAR.LIB,
 FINANCEP.LIB, or FINANCAP.LIB).

 Code Example
 ------------

 REM $INCLUDE: 'financ.bi'
 DEFDBL A-Z

 ' Initialize variables:
 CLS
 houseval = 110000#     ' Purchase price of house (median for Seattle).
 apprec = 1.07#         ' Assumed yearly appreciation rate of house.
 sellper = 10# * 12#    ' Period (month) at which you choose to sell.
 down = .1#             ' Fraction of houseval paid as down payment.
 equity = down * houseval  ' Initial equity in house (10% down payment)
 pv1 = (1 - down) * houseval 'Present value of loan = 90% of houseval
 rate1 = .1025# / 12 ' Loan interest rate (10.25%) divided by 12 months
 pool = 0 ' Pool of money, if any, to earn interest & subtract payments
 poolint = 1.0057# ' Monthly interest earned on pool to get 7% yearly.
 pointsbuy = .02#  ' Assumed fees to buy loan, as fraction of houseval.
 pointsell = .07#  ' Selling fees (points) as fraction of selling price
 per = 0#           ' Month (period) counter.
 nper1 = 360#       ' # periods in loan. 30-year loan has 360 months.
 ptype% = 0#        ' 0 means payment due at end of each period.
 fv1 = 0#           ' Future value (the goal) of a loan is always zero.
 ptot1 = 0#         ' Current total of principal paid towards loan.
 in = .95#          ' 1 minus the inflation rate
 proptax = -130#    ' property taxes per month (tax deductible)
 fire = -25#        ' fire/house insurance per month
 roommate = 400#   ' Rent income from roommate (0 if none) after taxes.
 roominflate = 1.02 ' Yearly rate you increase your roommate's rent.
 tax = .8#       ' 1 minus your average yearly Tax rate (as a fraction)
 initial = pool + equity
 PRINT "Purchase price ="; houseval;
 PRINT " // Initial pool + equity = "; initial
 upfront = equity + (pointsbuy * houseval)
 PRINT "Up front cost (down payment + loan fees) ="; upfront

 ' Calculate monthly (principal+interest) payment:
 payment1 = Pmt(rate1, nper1, pv1, fv1, ptype%, status%)
 IF down < .2# THEN
    minsure = .03 * payment1 ' Monthly mortgage insurance rate (3% of
 ELSE               ' principal+interest payment). You usually must pay
    minsure = 0#    ' mortgage insurance if you paid < 20% down.
 END IF
 PRINT "monthly payment= "
 PRINT payment1; "+"; fire; "+"; proptax; "+"; minsure; "= ";
 PRINT payment1 + fire + proptax + minsure
 PRINT "not counting tax savings ("; 1 - tax; "factor ) ";
 PRINT "or roommate income ("; roommate; ")";
 PRINT "**************************************************"

 ' Add up numbers until the period (month) where you sell (sellper):
 FOR j = 1 TO sellper
    per = j
    ' Yearly rent increase:
    IF j MOD 12 = 0 THEN roommate = roominflate * roommate

    ' Calculate principal and interest amounts paid:
    principal1 = PPmt(rate1, per, nper1, pv1, fv1, ptype%, status%)

    ptot1 = ptot1 + principal1   ' total accumulated principal to date
    interest1 = payment1 - principal1
    itot1 = itot1 + interest1  'total accumulated interest paid to date
    ' Outaftertax1 and outgo values are negative:
    outaftertax1 = ((interest1+proptax)*tax) +principal1 +fire +minsure
    pool = pool + outaftertax1 + roommate  ' (outaftertax is negative)
    ' pool earns interest if positive (no interest charged if negative,
    ' assuming you make monthly house payments without borrowing):
    IF pool > 0 THEN pool = pool * poolint
    equity = equity + ABS(principal1) ' Monthly principal builds equity
 NEXT

 ' Calculate final appreciation and closing costs; and print out:
 years = sellper / 12#   ' Number of years after which you sold.
 aphouseval = houseval * (apprec ^ years) ' Appreciated house value.
 closecost = -(pointsbuy * houseval) - (pointsell * aphouseval)
 naphouseval = aphouseval - houseval  ' net appreciation on house value
 final = pool + equity + naphouseval + closecost
 in1989 = final * (in ^ years)  ' In 1989 dollars (inflation adjusted).
 PRINT
 PRINT "After"; years; " years, buy+sell closecost ="; closecost
 PRINT "total principal paid="; ptot1 + ptot2
 PRINT "total interest paid="; itot1 + itot2
 PRINT "Appreciated value of house = "; aphouseval
 PRINT "final pool+equity+apprec-close="; final
 PRINT "or"; in1989; " in 1989 dollars with"; 1 - in;"yearly inflation"
 PRINT "(which is a"; CSNG(in ^ years); " overall inflation factor)"
 PRINT
 PRINT "Net ave. equity increase per month="; (final-initial)/sellper
 PRINT"(or with inflation=";(in1989-initial)/sellper;"in 1989 dollars)"


 120. Library Naming Conventions for BASIC PDS 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891206-120
 Last Modified: 14-JAN-1990    ArticleIdent: Q52091

 The following article explains the library naming conventions used by
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2.

 In Microsoft BASIC PDS Version 7.00, library names are acronyms that
 follow a standard format:

    NAMEmso.LIB
        m = Alternate (A) or Emulation (E) math package.
        s = Far (F) or Near (N) variable-length string storage.
        o = Protected (P) or Real (R) mode operating system.

 The format starts with a base NAME of several characters used to
 identify the function of the library (such as BRT70, BCL70, FINANC,
 FONTB, MATB, etc.). Next is a two- or three-character extension
 specifying support for which math package (emulation or alternate
 math), variable-length string storage (near or far), or operating
 system (real or protected mode).

 Real mode refers to the DOS Version 3.x box in MS OS/2, or to straight
 MS-DOS. Protected mode refers to MS OS/2 only.

 BASIC Run-Time Libraries
 ------------------------

    BRT70EFR.LIB, BRT70ENR.LIB, BRT70EFP.LIB, BRT70ENP.LIB
    BRT70ANR.LIB, BRT70AFR.LIB, BRT70ANP.LIB, BRT70AFP.LIB

    Format: BRT70mso.LIB
                 m = Alternate (A) or Emulation (E) math package.
                 s = Far (F) or Near (N) strings.
                 o = Protected (P) or Real (R) mode operating system.

 BASIC Stand-Alone Libraries
 ---------------------------

    BCL70EFR.LIB, BCL70ENR.LIB, BCL70EFP.LIB, BCL70ENP.LIB
    BCL70ANR.LIB, BCL70AFR.LIB, BCL70ANP.LIB, BCL70AFP.LIB

    Format: BCL70mso.LIB    (where the mso letters are defined above)

 Financial Libraries
 -------------------

    FINANCER.LIB, FINANCAR.LIB, FINANCEP.LIB, FINANCAP.LIB

    Format: FINANCmo.LIB    (where the mo letters are defined above)
    (Name is not dependent upon Far or Near string storage.)

    FINANCER.QLB is the Quick library for use in the QBX.EXE
    environment.

 Date/Time Format Libraries
 --------------------------

    DTFMTER.LIB, DTFMTAR.LIB, DTFMTEP.LIB, DTFMTAP.LIB

    Format: DTFMTmo.LIB    (where the mo letters are defined above)
    (Name is not dependent upon Far or Near string storage.)

    DTFMTER.QLB is the Quick library for use in the QBX.EXE
    environment.

 Font Libraries
 --------------

    FONTBEFR.LIB, FONTBENR.LIB, FONTBANR.LIB, FONTBAFR.LIB

    Format: FONTBmsR.LIB    (where the ms letters are defined above)
    (There is no protected mode version.)

    FONTBEFR.QLB is the Quick library for use in the QBX.EXE
    environment.

 Matrix Operations Toolbox Libraries
 -----------------------------------

    MATBEFR.LIB, MATBENR.LIB, MATBEFP.LIB, MATBENP.LIB
    MATBANR.LIB, MATBAFR.LIB, MATBANP.LIB, MATBAFP.LIB

    Format: MATBmso.LIB    (where the mso letters are defined above)

    MATBEFR.QLB is the Quick library for use in the QBX.EXE
    environment.

 User Interface Toolbox Libraries
 --------------------------------

    UITBEFR.LIB, UITBENR.LIB, UITBEFP.LIB, UITBENP.LIB
    UITBANR.LIB, UITBAFR.LIB, UITBANP.LIB, UITBAFP.LIB

    Format: UITBmso.LIB    (where the mso letters are defined above)

    UITBEFR.QLB is the Quick library for use in the QBX.EXE
    environment.

 Presentation Graphics Toolbox Libraries
 ---------------------------------------

    CHRTBEFR.LIB, CHRTBENR.LIB, CHRTBEFP.LIB, CHRTBENP.LIB
    CHRTBANR.LIB, CHRTBAFR.LIB, CHRTBANP.LIB, CHRTBAFP.LIB

    Format: CHRTBmso.LIB    (where the mso letters are defined above)

    CHRTBEFR.QLB is the Quick library for use in the QBX.EXE
    environment.

 Stub Library
 ------------

    NOTRNEMR.LIB, NOTRNEMP.LIB

    Format: NOTRNEMo.LIB
                   o = Protected (P) or Real (R) mode operating system.

    Description: A stub library file that removes all intrinsic math
                 functions including LOG, SQR, SIN, COS, TAN, ATN, EXP,
                 ^, CIRCLE statements with a start and/or stop angle,
                 and DRAW statements with A or T commands.

    (NOTRNEMR.LIB and NOTRNEMP.LIB are the only .LIB stub files in
    BASIC 7.00. For a list of .OBJ stub files, refer to Pages 540 and
    541 of "Microsoft BASIC Version 7.0: Programmer's Guide.")

 OTHER LIBRARY NAMING CONVENTIONS
 --------------------------------

 ISAM Libraries
 --------------

    PROISAMD.LIB, PROISAM.LIB

    PROISAMD.LIB gives you full ISAM support, including the data
    dictionary routines for creating and deleting indexes, tables, and
    databases. PROISAM.LIB (with no D) supports ISAM programs without
    the ability to create or delete indexes, tables, or databases.

    PROISAM.EXE and PROISAMD.EXE are the TSR (Terminate-and-Stay-
    Resident) programs that provide ISAM support in the QBX.EXE
    environment, or in .EXE programs where you don't wish to link the
    ISAM support directly to your .EXE file.

 OS/2 Function Library
 ---------------------

    Name: OS2.LIB
    Description: Used for operating system calls into MS OS/2.


 121. "Subscript out of Range in Quick Library Module: MENU" in 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891207-103
 Last Modified:  2-MAY-1990    ArticleIdent: Q52092

 A program that uses procedures in the User Interface Toolbox's
 WINDOW.BAS source-code file may generate the message "Subscript out
 of range in module: MENU," if either the global-array declarations
 used with MENU.BAS are not included in the program or if they are
 included in the wrong order.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS.

 When using procedures in WINDOW.BAS, you must include the global-array
 declarations used with MENU.BAS in addition to the global-array
 declarations that are specific to WINDOW.BAS.

 The MENU.BAS COMMON SHARED statements must be listed before the
 WINDOW.BAS COMMON SHARED statements or a "Subscript out of range in
 module: MENU" error occurs.

 When using procedures in WINDOW.BAS, you make the following
 global-array declarations in your program. The COMMON SHARED
 statements must be listed in the exact order shown. The order of the
 DIM statements does NOT matter.

 'COMMON SHARED statements to be used with MENU.BAS:

         COMMON SHARED /uitools/ GloMenu       AS MenuMiscType
         COMMON SHARED /uitools/ GloTitle()    AS MenuTitleType
         COMMON SHARED /uitools/ GloItem()     AS MenuItemType

 'COMMON SHARED statements WINDOW.BAS:

         COMMON SHARED /uitools/ GloWindow()   AS WindowType
         COMMON SHARED /uitools/ GloButton()   AS ButtonType
         COMMON SHARED /uitools/ GloEdit()     AS EditFieldType
         COMMON SHARED /uitools/ GloStorage    AS WindowStorageType
         COMMON SHARED /uitools/ GloWindowStack() AS INTEGER
         COMMON SHARED /uitools/ GloBuffer$()

 'DIM statements to be used with MENU.BAS:

         DIM GloTitle(MAXMENU)                 AS MenuTitleType
         DIM GloItem(MAXMENU, MAXITEM)         AS MenuItemType

 'DIM statements to be used with WINDOW.BAS:

         DIM GloWindow(MAXWINDOW)              AS WindowType
         DIM GloButton(MAXBUTTON)              AS ButtonType
         DIM GloEdit(MAXEDITFIELD)             AS EditFieldType
         DIM GloWindowStack(MAXWINDOW)         AS INTEGER
         DIM GloBuffer$(MAXWINDOW + 1, 2)


 122. BASIC 7.00 Example to Find All Available Disk Drives

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891214-80
 Last Modified: 14-JAN-1990    ArticleIdent: Q52093

 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2 can change the current drive from within a BASIC
 program with the command

    CHDRIVE <drive letter>

 where <drive letter> is a string expression that is a valid drive.
 This statement, coupled with error trapping, can be used to find all
 available disk drives.

 The example program below collects a list of all the available disk
 drives and puts it into the fixed-length STRING array "Drives". This
 is done by using the CHDRIVE statement to log onto each possible drive
 (A through Z) and adding to the list only those drives that were
 successfully logged onto.

 The INTEGER variable "IsDrive%" is used to flag whether or not the
 CHDRIVE statement was successful in trying to log onto the next drive.

 If CHDRIVE is unsuccessful, BASIC will generate a "Device unavailable"
 error. This error will be trapped by the local error-handling routine,
 "DriveError", which will set "IsDrive%" to FALSE.

 If CHDRIVE is successful, "IsDrive%" will remain TRUE and the drive
 will be added to the list. The total number of available drives is
 stored in the INTEGER variable "TotalDrives%".

 Note that on a PC a legal drive name can only be a single letter
 between  "A" and "Z". Also, DOS does not distinguish between uppercase
 and lowercase letters. Therefore, in the following program we can use
 the numbers 65 through 90 whose corresponding ASCII characters are "A"
 through "Z" to circulate through all the possible drives. The counter
 variable of a FOR...NEXT loop is just right for performing this task.
 Our counter is "DriveLetter%".

 Code Example
 ------------

 CONST TRUE = -1
 CONST FALSE = 0

 DIM Drives(26) AS STRING * 1       'The list of drives.

 ON LOCAL ERROR GOTO DriveError   'If CHDRIVE unsuccessful trap error.
 TotalDrives% = 0

 FOR DriveLetter% = 65 TO 90      'ASCII "A" through "Z"
    IsDrive% = TRUE
    CHDRIVE CHR$(DriveLetter%)   'Try to log onto drive.
    IF IsDrive% THEN
       TotalDrives% = TotalDrives% + 1   'CHDRIVE was successful.
       Drives(TotalDrives%) = CHR$(DriveLetter%)   'Add drive letter.
    END IF
 NEXT DriveLetter%

 END

 DriveError: IsDrive% = FALSE   'CHDRIVE was unsuccessful.
             RESUME NEXT        'Resume at the IF statement.


 123. You Can CHAIN Only to an .EXE or .COM in BASIC PDS 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891220-87
 Last Modified: 14-JAN-1990    ArticleIdent: Q57341

 In Microsoft Basic Compiler Versions 6.00 and 6.00b and in QuickBASIC
 Versions 4.00, 4.00b, and 4.50 for MS-DOS, you can CHAIN to an
 executable file that does not have the extension .EXE, and it will not
 generate an error. In BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS and MS OS/2, the same executable file must
 have the extension .EXE or .COM to run without an error. If the
 CHAINed-to file does not have one of these two extensions, the error
 "Bad File Mode" is generated when the program is executed.

 This new extension checking is to help you CHAIN to files that are
 most likely meant to be CHAINed to.


 124. QBX May Incorrectly Parse Array Element in User-Defined TYPE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57501

 The QuickBASIC Extended editor (QBX.EXE), which is shipped with
 Microsoft BASIC Professional Development System (PDS) version 7.00 for
 MS-DOS, incorrectly parses a line of code that uses incorrect syntax
 for an array element in a user-defined TYPE. The following is an
 example:

    TYPE abc
       a(1 to 10) AS STRING * 8
    END TYPE
    DIM y AS abc
    PRINT y.a$(3)

 When you enter the last line into QBX.EXE and press the ENTER key,
 the line is interpreted (parsed) incorrectly and is displayed
 incorrectly as follows:

    3yGOTO

 If the correct line of code "PRINT y.a(3)" is entered, the code is
 interpreted correctly.

 Microsoft has confirmed this to be problem in the QBX.EXE editor in
 Microsoft BASIC PDS version 7.00. This problem was corrected in
 QBX.EXE in BASIC PDS 7.10.

 This problem relates only to QBX.EXE and does not relate to the BC.EXE
 compiler in BASIC 7.00.


 125. SCREEN Statement Correction for SCREEN 3 and 4 in PDS 7.00

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891214-90 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57343

 The "Microsoft BASIC 7.0: Language Reference" manual for Microsoft
 BASIC PDS Versions 7.00 and 7.10 incorrectly documents SCREEN modes 3
 and 4. Page 311 incorrectly states that SCREEN mode 3 supports
 Olivetti or AT&T Adapter Boards and that SCREEN mode 4 supports
 Hercules graphics capabilities.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The correct entries under the SCREEN statement for SCREEN modes 3 and
 4 are included in the QBX.EXE Microsoft Advisor online Help system and
 appear as follows:

 SCREEN 3: Hercules adapter required, monochrome monitor only
    - 720 x 348 graphics
    - 80 x 25 text format, 9 x 14 character box
    - 2 screen pages (1 only if a second display adapter is installed)
    - PALETTE statement not supported

 SCREEN 4:
    - Supports Olivetti (R) Personal Computers models M24, M240, M28,
      M280, M380, M380/C, M380/T and AT&T (R) Personal Computers 6300
      series
    - 640 x 400 graphics
    - 80 x 25 text format, 8 x 16 character box
    - 1 of 16 colors assigned as the foreground color (selected by
      the COLOR statement); background is fixed at black


 126. "Subscript out of Range in Quick Library Module: WINDOW" Error

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S891207-24 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57344

 The following COMMON SHARED statement should be added to the global
 array declarations found on Page 550 of the "Microsoft BASIC 7.0:
 Language Reference" manual (for 7.00 and 7.10) to successfully use the
 User Interface (UI) Toolbox's WINDOW.BAS source code file:

    COMMON SHARED /uitools/GloWindowStack() AS INTEGER

 The order of COMMON SHARED statements is important. The above
 statement should be inserted as follows:

    COMMON SHARED /uitools/GloWindow()      AS WindowType
    COMMON SHARED /uitools/GloButton ()     AS ButtonType
    COMMON SHARED /uitools/GloEdit()        AS EditFieldType
    COMMON SHARED /uitools/GloStorage()     AS WindowStorageType
    COMMON SHARED /uitools/GloWindowStack() AS INTEGER
    COMMON SHARED /uitools/GloBuffer$()

 If this COMMON SHARED statement is missing from a program that uses
 the WINDOW.BAS source code file, the program generates the error
 message "Subscript out of range in Quick library module: WINDOW" on
 the first call to a WINDOW.BAS procedure. This error will probably
 occur on the call to WindowInit because it must be the first
 WINDOW.BAS procedure called.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.


 127. Colored Buttons/Scroll Bars in BASIC 7.00 UI Toolbox

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891207-109
 Last Modified: 14-JAN-1990    ArticleIdent: Q57355

 The User Interface (UI) Toolbox supplied with Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2 allows you to display scroll bars in windows. However, it has no
 facility for specifying foreground and background colors for them and
 always uses white and black, respectively. This limitation can be
 removed by modifying two COLOR statements in the ButtonShow procedure
 of the WINDOW.BAS toolbox file and adding a COMMON SHARED statement to
 the module-level code of that same file.

 The ButtonShow procedure of the WINDOW.BAS toolbox file is called when
 a button (which includes scroll bars) is to be displayed in a window.
 As written, the ButtonShow procedure does not allow regular buttons to
 have a different color than the window text and scroll bars are
 limited to a white foreground and black background.

 The colors of regular buttons can be specified through the use of the
 WindowColor procedure, which changes the colors used for window text.
 The colors used for window text are the same as those used for
 buttons.

 The COLOR statement used to color scroll bars is as follows:

    COLOR 0,7

 There are two of these COLOR statements in the ButtonShow procedure,
 one for horizontal scroll bars and one for vertical scroll bars. Both
 of them need to be changed to the following statement:

    COLOR ScrollBarForeground%, ScrollBarBackground%

 Here ScrollBarForeground and ScrollBarBackground are sample names for
 integer variables and may be differently named. However, they must be
 unique throughout the entire program because they will be COMMON
 SHARED between the module opening a button and the WINDOW.BAS module.
 Therefore, at the module-level code of both of those modules, insert
 the following statements:

    COMMON SHARED /ScrollBarColors/ ScrollBarForeground%
    COMMON SHARED /ScrollBarColors/ ScrollBarBackground%

 Here ScrollBarColors is an sample name for a named COMMON block and
 may be different. However, the name of the COMMON block must be the
 same in both modules and the data types of the variables must be
 integer. To prevent confusion, the same names used in the COLOR
 statements should be used in the COMMON SHARED statements.

 After the above changes have been made, you can specify what the
 foreground and background colors of each scroll bar will be by
 assigning color numbers to the variables in the named COMMON block.
 The variables do not need to be passed to the ButtonShow procedure
 because they are COMMON SHARED with the WINDOW.BAS module. The COLOR
 statement will always have access to them.

 Code Example
 ------------

 The following code fragment is an example of specifying colors for a
 scroll bar:

 'The following COMMON SHARED statements would also appear in the
 'module-level code of the WINDOW.BAS module.

 COMMON SHARED /ScrollBarColors/ ScrollBarForeground%
 COMMON SHARED /ScrollBarColors/ ScrollBarBackground%

 ScrollBarForeground% = 14   'yellow foreground.
 ScrollBarBackground% = 1    'blue background.

 'The ButtonOpen procedure will call the ButtonShow procedure,
 'which will use the values in ScrollBarForeground% and
 'ScrollBarBackground% to COLOR the scroll bar.

 CALL ButtonOpen (1, 1, "", 10, 30, 20, 30, 6)


 128. "Overflow" Accessing > 32K Array Inside User-Defined TYPE

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891113-17 buglist7.00
 Last Modified: 14-JAN-1990    ArticleIdent: Q57356

 When a program is compiled with the /D switch, the length of arrays
 inside user-defined TYPEs is limited to 32,768 bytes. The compiler
 will not generate an error if a larger array is declared inside a
 user-defined type, but accessing any element that is offset more than
 32,768 bytes into the array will cause an "Overflow" error.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2. We are researching this problem and will report new information
 here as it becomes available.

 This limitation applies only to arrays inside user-defined TYPEs, a
 new feature that was introduced in BASIC PDS 7.00 for MS-DOS and MS
 OS/2.

 The following two examples illustrate when the "Overflow" error occurs
 and when it doesn't.

 Example 1
 ---------

 When compiled with the BC /D switch, this program generates an
 "Overflow" error. This is because element 16,385 of the INTEGER array
 inside of the user-defined TYPE is being accessed. 16,385 * 2 (2 bytes
 per INTEGER) is greater than 32,768, so that element is out of bounds.

 TYPE aType
    anArray (1 TO 16385) AS INTEGER  'The compiler will not
                                     'flag this as an error -
 END TYPE                            '(16385*2) > 32768
 DIM aVariable as aType

 FOR i = 1 TO 16385
    aVariable.anArray(i) = 1   'When i = 16385 the "Overflow"
 NEXT i                        'error will be generated.

 Example 2
 ---------

 The following program does not generate an "Overflow" error. This is
 because the highest element of the INTEGER array inside the
 user-defined type being accessed is 16,384. 16,384 * 2 (2 bytes per
 INTEGER) is not greater than 32,768, so the element is not out of
 bounds.

 TYPE aType
    anArray (1 TO 16385) AS INTEGER  'The compiler will not
                                     'flag this as an error -
 END TYPE                            '(16385 * 2) > 32768
 DIM aVariable as aType

 FOR i = 1 TO 16384
    aVariable.anArray(i) = 1   'No "Overflow" error -
 NEXT i                        '16384 * 2 <= 32768.


 129. Missing Dollar Sign on a Call to Assembly Routine

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S891226-5 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57357

 On Page 372 of the "Microsoft BASIC 7.0: Language Reference" manual
 (for 7.00 and 7.10) the CALL to Makestring needs to have a dollar sign
 appended to the end of it as shown below.

 The following is incorrect:

    PRINT Makestring

 It should be the following:

    PRINT Makestring$

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 130. Incorrect Declaration of Far Procedure in Assembly; BASIC 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S891226-6 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57358

 On Page 495 of the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00
 and 7.10), the "proc far" declaring the assembly procedures as far
 should actually be just "far", not "proc far" as shown below.

 The following is incorrect:

    extrn stringassign:proc far

 It should be the following:

    extrn stringassign:far

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 131. Use "proc uses", Not "procuses" in MASM Example; BASIC 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S891226-4 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57359

 On Page 495 of the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00
 and 7.10), a space should appear between the assembly code "proc" and
 "uses", but the manual shows no space between them.

 The following is incorrect:

    addstring  procuses si di ds,s1:far ptr,s1len,s2:far ptr,s2len

 The following is correct:

    addstring  proc uses si di sd,s1:far ptr,s1len,s2:far ptr,s2len

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 132. Variable Length String Passed from BASIC PDS 7.00 to C

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891017-100
 Last Modified: 17-JAN-1990    ArticleIdent: Q57362

 The example below demonstrates how to pass a variable-length string
 from a compiled BASIC program to a C program. This information applies
 to Microsoft BASIC Professional Development System (PDS) 7.00 for
 MS-DOS and MS OS/2.

 BASIC to C Example
 ------------------

 Compile and link as follows:

 Compile:  BC /Fs/d Bastest.bas;
           QCL /AM Ctest.c /c

 Link:     LINK /noe/nod Bastest+Ctest,,,BRT70EFR+MLIBCE;

 REM ===== BASIC PROGRAM =====
 DECLARE SUB StringFar CDECL (BYVAL p1o AS INTEGER, BYVAL p1s AS
 INTEGER, SEG p3 AS INTEGER)
 CLS
 a$ = "This is a test" + CHR$(0)
 CALL StringFar(SADD(a$), SSEG(a$), LEN(a$))
 PRINT "Back from C"
 END
 /* C sub-program */
 #include <e:\qc2\include\stdio.h>
 void StringFar(a,len)
    char far *a;
     int *len;
  {
     int i;
     printf("The string is : %s \n\n",a);
     printf(" Index       Value       Character\n");
     for (i=0;i < *len; i++)
        {
          printf("  %2d          %3d
 %c\n",i,a[i],a[i]);
        };
  }


 133. How to Pass a Variable Length String from BASIC to MASM

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891017-100
 Last Modified: 17-JAN-1990    ArticleIdent: Q57363

 The example below demonstrates how to pass a variable-length string
 from a compiled BASIC program to a MASM procedure. This information
 applies to Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS and MS OS/2.

 BASIC to MASM Example
 ---------------------

 Compile and link as follows:

 Compile: BC /Fs/d basmasm.bas;
          MASM masmtest;
 Link:    LINK basmasm+masmtest,,,BRT70EFR;

 REM ==BASIC to MASM code===
 DEFINT A-Z
 DECLARE SUB printmessage (BYVAL segm, BYVAL offs)
 CLS
 a$ = "Assembly test successful" + "$"
 CALL printmessage(SSEG(a$), SADD(a$))
 LOCATE 10, 10
 PRINT "Back from assembly"
 END

 ;MASM code here
                     .Model    Medium,basic
                     .stack
                     .code
                     public    printmessage
 printmessage        proc      uses ds,segm,offs
                     mov       ax,segm
                     mov       ds,ax
                     mov       dx,offs
                     mov       ah,9
                     int       21h
                     ret
 printmessage        endp
                     end


 134. Missing FUNCTION Name in BASIC PDS 7.00 Example

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S891219-95 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57364

 There is an error on Page 494 of the "Microsoft BASIC 7.0:
 Programmer's Guide" (for 7.00 and 7.10), as shown below.

 The following is incorrect:

    C$ = (A$, LEN(A$), B$, LEN(B$))

 The following is correct:

    C$ = AddString$(A$, LEN(A$), B$, LEN(B$))

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 135. "Subprogram Not Defined" GetCopyBox, AttrBox Using GENERAL.BAS

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891219-77 docerr
 Last Modified:  1-AUG-1990    ArticleIdent: Q57365

 GetCopyBox, PutCopyBox, and AttrBox (which are all invoked in
 GENERAL.BAS) are assembly language procedures located in the UIASM.ASM
 assembler source file, in the UIASM.OBJ object file, and in the
 UITBEFR.QLB Quick library. This fact needs to be added on Pages 499,
 585-586, 589, and 591 of the "Microsoft BASIC 7.0: Language Reference"
 manual for Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10. You will need to know this when using
 GENERAL.BAS from the User Interface (UI) Toolbox as described below.

 If you are using GENERAL.BAS in QBX.EXE and get a "Subprogram not
 defined" error on a call to GetCopyBox, PutCopyBox, or AttrBox, then
 you must invoke QBX with a Quick library containing these routines,
 for example:

    QBX /L UITBEFR.QLB.

 [Also, if you are using GENERAL.BAS in QBX.EXE and get a "Subprogram
 not defined" error on a call to MouseHide (in the Box subprogram),
 then you must Load (choose Load from the File menu) the MOUSE.BAS
 source file, which contains MouseHide and the other mouse UI Toolbox
 routines.]

 This information applies to the UI Toolbox in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS.

 If you chose to have Quick libraries created when you ran SETUP.EXE
 for BASIC 7.00 or 7.10, you already have the UITBEFR.QLB Quick library
 that contains all the UI Toolbox routines. SETUP.EXE places
 UITBEFR.QLB by default in the directory where you chose to place
 .LIB files.

 Pages 534 and 535 "Microsoft BASIC 7.0: Language Reference" for
 versions 7.00 and 7.10 describe how to build UITBEFR.QLB (or subsets)
 yourself. (You can use LINK /Q to build UIASM.OBJ into a Quick library
 and use LIB.EXE to build the parallel .LIB library.)

 The three routines in UIASM.OBJ (PutCopyBox, GetCopyBox, and AttrBox)
 must always be present when using the UI Toolbox.

 Page 586 correctly describes how to make calls to AttrBox SUB. Since
 the code for AttrBox is not in the GENERAL.BAS source-code file, if
 you want to alter the code for AttrBox, you must edit the UIASM.ASM
 source file and reassemble it with Microsoft Macro Assembler (MASM).

 Documentation Correction
 ------------------------

 Pages 499 and 585-586 of the "Microsoft BASIC 7.0: Language Reference"
 manual incorrectly imply that AttrBox SUB is a procedure found in the
 GENERAL.BAS source-code file for the User Interface (UI) Toolbox.

 The AttrBox is actually an assembly language procedure located in the
 UI Toolbox object file, UIASM.OBJ (and in the UIASM.ASM source file).
 The UI Toolbox procedures require that UIASM.OBJ be included either in
 a Quick library when running inside the QBX.EXE editor or in a library
 (.LIB) that is linked to your program when running outside the
 environment (in a compiled executable .EXE form).


 136. DateSerial# Accepts Values Outside Range for Arguments

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr SR# S891227-47
 Last Modified:  8-JAN-1991    ArticleIdent: Q57366

 Page 425 of the "Microsoft BASIC 7.0: Language Reference" manual (for
 7.00 and 7.10) states that the DateSerial# function will generate an
 "Illegal function call" if values are specified outside the given
 ranges of the following:

    year%  - A year from 1753 to 2078
    month% - A month from 1 to 12
    day%   - A day from 1 to 31

 An "Illegal function call" is only generated if the year, month, and
 day arguments generate a serial number outside the valid range of
 -53,688 to 65,380. The corresponding dates for this range are January
 1, 1753, to December 31, 2078.

 The README.DOC file provided with Microsoft BASIC Professional
 Development System (PDS) Versions 7.00 and 7.10 notes this
 documentation error.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The DateSerial# function can return serial numbers for dates in the
 following range, inclusive:

    DATE:     January 1, 1753, to December 31, 2078
    SERIAL#:           -53688 to 65380

 The DateSerial# function generates an "Illegal function call" only if
 the arguments passed to it generate a serial number outside the range
 of -53,688 to 65,380. The following example uses a value outside the
 given range for the "month%" argument, but does not generate an
 "Illegal function call":

    theDate# = DateSerial#(89, 13, 1)

 The serial number returned in the above call actually corresponds to
 the date January 1, 1990. A value of 13 logically corresponds to the
 month following December. Since December is the last month of a year,
 the year value is incremented by 1, and the month value is reset to 1,
 which corresponds to January; therefore, the following two calls to
 DateSerial# return the same serial number:

    theDate# = DateSerial#(89, 13, 1)
    theDate# = DateSerial#(90,  1, 1)

 Negative numbers work in the same way. A value of "-1" for the month
 argument refers to the month of November in the previous year. The
 following to calls to DateSerial# return the same serial number:

    theDate# = DateSerial#(90, -1, 1)
    theDate# = DateSerial#(89, 11, 1)

 The following are example calls to DateSerial# that generate the
 "Illegal function call" error message since the resulting serial
 number falls outside the valid range:

    theDate# = DateSerial#(2078, 12, 32)  ->  January   1, 2079
    theDate# = DateSerial#(2078, 13,  1)  ->  January   1, 2079
    theDate# = DateSerial#(1753,  0, 31)  ->  December 31, 1752


 137. COMMON SHARED Must Be in Order in User Interface Toolbox

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891211-54
 Last Modified: 23-FEB-1990    ArticleIdent: Q57367

 When using procedures from the User Interface (UI) Toolbox's MENU.BAS
 or WINDOW.BAS, you must provide global-array declarations in your
 program. If these declarations are in the wrong order, various errors
 may occur. The proper order for COMMON SHARED declarations can be
 found at the beginning of each User Interface Toolbox .BAS file.
 Possible errors include "Subscript out of range in module...," "Far
 Heap Corrupt," or the system may hang.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 In most cases, switching the order of the COMMON SHARED statements for
 the global-array declarations generates the error "Subscript out of
 range in module..." on the first call to a procedure in MENU.BAS or
 WINDOW.BAS.

 Changing the order of certain COMMON SHARED statements results in a
 "Far Heap Corrupt" message when the program is run from the QBX.EXE
 editor. This can put the computer in an unstable memory state, which
 may cause it to hang. When the same program is run from the DOS
 command line, the program fails and gives a "Subscript out of range in
 module..." error message.

 Here is some good advice from Page 65 of the "Microsoft BASIC 7.0:
 Language Reference" manual:

    Errors caused by mismatched COMMON statements are subtle and
    difficult to find. An easy way to avoid mismatched COMMON
    statements is to place COMMON declarations in a single include
    file and use the $INCLUDE metacommand in each module.

 Code Example
 ------------

 The following code exhibits the behavior of a program that has a
 statement (COMMON SHARED /uitools/GloWindowStack() AS INTEGER) in the
 wrong order. This program generates a "Far Heap Corrupt" message and
 can hang when run from the QBX.EXE editor in either MS-DOS or in OS/2
 real mode. If this program is compiled, linked, and then run from the
 DOS command line, it generates a "Subscript out of range in module..."
 error.

    REM $INCLUDE: 'MENU.BI'
    REM $INCLUDE: 'WINDOW.BI'
    REM $INCLUDE: 'MOUSE.BI'
    REM $INCLUDE: 'GENERAL.BI'

    COMMON SHARED /uitools/GloMenu     AS MenuMiscType
    COMMON SHARED /uitools/GloTitle()  AS MenuTitleType
    COMMON SHARED /uitools/GloItem()   AS MenuItemType

    'The next statement is out of order

    COMMON SHARED /uitools/GloWindowStack() AS INTEGER
    COMMON SHARED /uitools/GloWindow() AS WindowType
    COMMON SHARED /uitools/GloButton() AS ButtonType
    COMMON SHARED /uitools/GloEdit()   AS EditFieldType
    COMMON SHARED /uitools/Storage     AS WindowStorageType
    'This is where the statement should be
    COMMON SHARED /uitools/GloBuffer$()

    DIM GloTitle(MAXMENU)              AS MenuTitleType
    DIM GloItem(MAXMENU, MAXITEM)      AS MenuItemType
    DIM GloWindow(MAXWINDOW)           AS WindowType
    DIM GloButton(MAXBUTTON)           AS ButtonType
    DIM GloEdit(MAXEDITFIELD)          AS EditFieldType
    DIM GloWindowStack(MAXWINDOW)      AS INTEGER
    DIM GloBuffer$(MAXWINDOW +1, 2)

    MenuInit
    WindowInit


 138. QBX Make Library Uses OS/2 Mode Last Used by Make EXE File

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891211-105
 Last Modified:  8-JAN-1990    ArticleIdent: Q57382

 The Make Library menu command of the QuickBASIC Extended (QBX.EXE)
 environment that comes with Microsoft BASIC PDS Version 7.00 for
 MS-DOS and MS OS/2 will compile currently loaded source modules for
 whichever OS/2 mode (real or protected) that the last Make EXE File
 menu command compiled for.

 (Note that the QBX.EXE environment runs only under OS/2 real mode or
 MS-DOS and does not itself run under OS/2 protected mode, although
 QBX.EXE can make .EXE programs that run under OS/2 protected mode.)

 The Make Library command on the Run menu of the QBX.EXE environment
 can be used to make stand-alone libraries for either real or protected
 mode operation. However, there is no option in the Make Library dialog
 box that allows you to choose which mode the modules of the library
 will be compiled for.

 The Make Library command will compile the source-code modules for
 whichever mode the last Make EXE File command compiled for. That is,
 if the OS/2 Protected Mode option in the Make EXE File dialog box was
 selected the last time you made an EXE file, then the Make Library
 command will compile the library modules for protected mode. If a real
 mode (using the DOS or OS/2 Real Mode option) EXE file was made last,
 a real mode library will be made the next time Make Library is
 invoked.

 Note that selecting a mode (protected or real) in the Make EXE File
 dialog box and then choosing the Cancel button will not cause the Make
 Library command to compile for that mode. BC.EXE must be invoked for
 the change to take effect.

 Do the following to demonstrate the problem:

 1. Invoke QBX and type the following line:

    PRINT "This will be a protected-mode program"

    Now save the program.

 2. Make the program into an executable file using the Make EXE File
    menu command. For the target environment (operation mode), select
    the OS/2 Protected Mode option. Choose the Make EXE button to make
    the executable file.

    The "/Lp" option should be one of the parameters on the BC.EXE
    command line that is displayed. This switch is used to compile for
    protected mode.

 3. When the executable has been made, the QBX environment should
    reappear on the screen. Choose the Make Library command and select
    the Make Library button to make the library.

    The "/Lp" switch should be one of the parameters on the BC.EXE
    command line that is displayed. This switch is used to compile for
    protected mode.

 4. When the QBX environment comes back on the screen, repeat Steps 2
    and 3. However, in Step 2, select the DOS Or OS/2 Real Mode option
    for the target environment. Instead of the "/Lp" switch, the "/Lr"
    switch should be one of the parameters on the BC.EXE command line
    generated by the Make EXE File and the Make Library commands.


 139. LoadFont Function Example Documentation Error in BASIC 7.00

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891211-4 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57502

 Page 524 of the "Microsoft BASIC 7.0: Language Reference" for
 Microsoft BASIC Professional Development System (PDS) Versions 7.00
 and 7.10 shows an incorrect example of how to load a font by its order
 in the font file. This documentation incorrectly states the following:

    Note that to load fonts according to their order in the font
    file, l% would take the form:

       l% = LoadFont%("n1,n3,n6")

 The code above should read as follows (where l% means L%, not to be
 confused with 1%):

    l% = LoadFont%("n1/n3/n6")

 When loading multiple fonts, each font given in the fontspec$ argument
 of LoadFont%(fontspec$) should be separated by forward slashes (the
 "/" character), not by commas.

 If the code in this documentation error is used, only the first font
 is loaded (l% contains the number "1", indicating that only one font
 is loaded).

 Code Example
 ------------

 The following code example demonstrates the documentation problem. To
 use this code example, you must start QBX.EXE with /L FONTBEFR.QLB to
 access the font routines.

 REM $INCLUDE: 'fontb.bi'
 '* Load a the Times Roman font.
 SCREEN 9
 PRINT "Registering Times Roman font."
 FontNum% = RegisterFonts("D:\BC7\FONTS\TMSRB.FON")
 PRINT "Number of fonts in the file: "; FontNum%
 PRINT "Loading fonts 4,5,6 from the Times Roman file."
 var1% = LoadFont%("N4,N5,N6")
 PRINT "Number of fonts successfully loaded"; var1%
 PRINT "value of FontErr", FontErr
 a$ = "Hello world"
 var1% = OutGText%(100, 100, a$)
 END


 140. Documentation Errors in BASIC 7.00 Presentation Graphics

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891211-2 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q57504

 This article documents several documentation errors in Chapter 6,
 "Presentation Graphics," of the "Microsoft BASIC 7.0: Programmer's
 Guide" for Microsoft BASIC Professional Development System (PDS)
 Versions 7.00 and 7.10. The errors are as follows:

 1. Page 250 details the fields in the AxisType user-defined TYPE. The
    field "Labelled" is misspelled. It should be spelled "Labeled".
    This field is spelled correctly in the definition of the AxisType
    in the CHRTB.BI $INCLUDE file.

 2. Page 251 incorrectly says to assign TicFormat to the CONSTant
    cDecFormat for decimal. There is no CONSTant named cDecFormat.
    This constant is defined as cNormFormat in the CHRTB.BI $INCLUDE
    file.

 3. Page 266 describes how to load fonts for use in Presentation
    Graphics. The following line in the example at the bottom of the
    page is incorrect:

       Env.MainTitle.Font = 3

    This line should be changed to the following:

       Env.MainTitle.TitleFont = 3


 141. "No Symbolic Information" Using Older CodeView with BASIC PDS

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891228-44
 Last Modified: 14-JAN-1990    ArticleIdent: Q57515

 If a version of Microsoft CodeView earlier than Version 2.35 is used
 on a program compiled with Microsoft BASIC Professional Development
 System (PDS) Version 7.00, the message "No symbolic information" is
 displayed within CodeView and no BASIC source code is displayed.

 BASIC PDS 7.00 is designed to use CodeView Version 2.35, which is
 included with the product.

 This information applies to the Microsoft BASIC PDS Version 7.00 for
 MS-DOS and MS OS/2.


 142. Why BASIC 7.00 and 7.10 Don't Support Multiuser ISAM

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 27-JUL-1990    ArticleIdent: Q57579

 Question:

 Why is ISAM support in Microsoft BASIC Professional Development System
 (PDS) versions 7.00 and 7.10 only single-user and not multiuser? Also,
 why was ISAM support for OS/2 protected mode not available in 7.00 but
 was released in version 7.10?

 (Multiuser ISAM support refers to the ability for multiple processes,
 or users on a network, to access different records within one ISAM
 file at the same time, with locking of individual records. BASIC 7.00
 and 7.10 don't support multiuser ISAM; they only support single-user
 ISAM, where the whole ISAM file is locked during use by one program.)

 Response:

 The Microsoft BASIC Professional Development System (PDS) is a
 feature-packed product designed to satisfy the majority of needs
 expressed to us by our professional BASIC programmers. It includes the
 following:

  - Significant enhancements in performance (smaller and faster EXEs)

  - Significant enhancements in capacity (a 10- to 50-times increase in
    code and/or data space)

  - Significant enhancements in language (CURRENCY data type, static
    arrays in user-defined-TYPE records, local error handling, stack
    control, DOS file control)

  - Extras (three Excel-based libraries, three BASIC toolboxes for user
    interfaces, presentation graphics, and matrix math)

  - A new dimension added to file handling in the form of the
    high-performance ISAM database engine with a powerful, integrated
    BASIC programming interface

 As much as Microsoft wanted to include multiuser ISAM in BASIC PDS
 version 7.00 or 7.10, doing so meant holding back other features (such
 as those above) from the programmers who have expressed such a great
 need for them. Clearly, PC connectivity is growing and so will the
 need for a multiuser ISAM in BASIC. Just as Microsoft listened to
 customers in creating BASIC PDS 7.00 and 7.10, we will continue to
 listen and will make every attempt to have our future products address
 the most serious needs made known to us.

 The longer we allow the feature list for a given product release to
 grow, the longer everyone has to wait to get the feature(s) that may
 solve their immediate problem(s). If we had held BASIC 7.00 or 7.10
 off the market until multiuser ISAM was ready, no one would have had
 any of the above capacity, performance, or language features in a
 satisfactory time frame.

 Only after thorough testing did we introduce protected-mode (but still
 single-user) ISAM support in BASIC 7.10.

 Our perpetual challenge in the product release planning process is to
 find the combination of features and schedule that will best satisfy
 the needs of most of our customers.


 143. What Features Would You Want for a 1-Byte Data Type in BASIC?

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified: 17-JAN-1990    ArticleIdent: Q57580

 Some developers using Microsoft BASIC or QuickBASIC may suggest that a
 single-byte, unsigned data type should be added to BASIC. As of
 Microsoft BASIC PDS Version 7.00 or QuickBASIC Version 4.50 or
 earlier, a single-byte data type hasn't yet been implemented. If you
 support this suggestion, please send Microsoft your (customer)
 comments about what you would use this data type for and what kinds
 of operations you would like to see it support.

 For example, would you like the single-byte data type to be a fully
 implemented short integer complete with overflow checking and coercion
 to floating point or longer integers for the appropriate operations,
 or would you like to see it implemented as a simple, small, and fast
 data type with a subset of these operations? What are the ranges of
 uses that you can see for such a data type in your programs?

 We'd like to know what kinds of uses people envision for a single-byte
 data type before we consider adding the overhead to the product.

 Please send in your comments to Microsoft Product Support
 (206-454-2030) so we may forward them to the Microsoft BASIC Program
 Manager. Your input will be greatly appreciated.


 144. Microsoft Doesn't Offer Educational Edition of BASIC PDS 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-JAN-1990    ArticleIdent: Q57581

 Question:

 Why doesn't Microsoft offer an educational edition of BASIC PDS
 (Professional Development System) Version 7.00?

 Response:

 Microsoft instead recommends one of the following products for
 educational institutions and people who want to teach modern BASIC on
 IBM Personal Computers or compatibles:

 1. "Learn BASIC Now" by Halvorson and Rygmyr, published by Microsoft
    Press, 1989.

    This is the fastest, easiest way to learn modern QuickBASIC
    programming. The book includes a disk with the Microsoft QuickBASIC
    Interpreter (QBI.EXE), the QBI Advisor complete electronic
    reference, the QuickBASIC Express online tutorial and introduction
    to the interpreter, and dozens of sample programs. The book teaches
    BASIC programming step by step.

 2. Microsoft QuickBASIC Interpreter, Academic Edition Version 1.00,
    for IBM Personal Computers and Compatibles

    This product is entirely disk based, without a printed manual. The
    disk contains the Microsoft QuickBASIC Interpreter (QBI.EXE), the
    QBI Advisor complete electronic reference, the QuickBASIC Express
    online tutorial and introduction to the interpreter, and dozens of
    sample programs.

 The above two QuickBASIC Interpreter (QBI.EXE) products have the same
 language features found in Microsoft QuickBASIC Version 4.50 for IBM
 PCs and compatibles. (Note that the QBI.EXE interpreter environment
 has some limitations compared to QB.EXE 4.50).

 We found no compelling reason to make a special academic edition for
 BASIC PDS 7.00 since the only features in 7.00 not found in the
 existing QuickBASIC academic editions are all targeted for people
 making professional, commercial applications and are not crucial for
 teaching BASIC.


 145. BC 6.00/6.00b ERROUT.EXE Utility, "Command Failed" Error

 Product Version(s): 6.00 6.00b
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891019-106 docerr
 Last Modified: 14-JAN-1990    ArticleIdent: Q57644

 Contrary to Pages 328 and 329 of the "Microsoft CodeView and
 Utilities: Software Development Tools for MS-DOS" manual, the
 ERROUT.EXE utility supplied with Microsoft BASIC Compiler Versions
 6.00 and 6.00b works only with .EXE or .COM files.

 When running any DOS command line other than an .EXE or .COM file,
 ERROUT fails to execute the supplied command and either hangs the
 machine or returns the following error:

    execution error U2253 : command failed

 When executing batch files or DOS commands such as TYPE and DIR, the
 above error message displays. In the case of batch files, if the .BAT
 extension is included at the end of the batch-file name, ERROUT.EXE
 may hang the machine. If the .BAT extension is not included, the above
 error message displays. (When an error output filename is supplied
 with the /f option, this same error is written to the file.)

 The first example on Page 329 of the "Microsoft CodeView and
 Utilities: Software Development Tools for MS-DOS" manual (for
 Microsoft BASIC Compiler 6.00 and 6.00b) fails since it uses the DOS
 TYPE statement. This first example should be removed. The examples
 using CL and MASM work properly since CL.EXE and MASM.EXE are .EXE
 programs.

 (The ERROUT.EXE utility is not shipped in Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.)

 Syntax for ERROUT
 -----------------

 The ERROUT.EXE utility redirects standard error output generated from
 an .EXE or .COM program, using the following syntax:

    ERROUT [/f standarderrorfile] doscommandline

 Here, "standarderrorfile" is a filename to which all errors generated
 by "doscommandline" will be written when you use the /f option
 (lowercase "f"). Without the /f option, all error messages are sent to
 the console.

 No form of ERROUT works except when doscommandline is the name of an
 .EXE or .COM file.


 146. Setting COMSPEC & SHELL in OS/2; SHELL "Illegal Function Call"

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# S891218-2  B_QuickBas
 Last Modified: 14-JAN-1990    ArticleIdent: Q57645

 The following two situations might cause an "Illegal function call"
 error when attempting to SHELL under OS/2:

 1. In the OS/2 DOS 3.x compatibility box, a program can generate an
    "Illegal function call" if the COMSPEC environment variable is
    placed in the AUTOEXEC.BAT. Under OS/2, COMSPEC should be defined
    only in the CONFIG.SYS file.

 2. In an OS/2 protected mode session, "Illegal function call" on a
    SHELL can be generated if the parameter /E:xxxx is used to attempt
    to set the environment size on the CMD.EXE command interpreter. The
    CMD.EXE command interpreter will accept this parameter, but it will
    then prevent you from SHELLing another copy of CMD.EXE. To correct
    this problem, remove the COMSPEC from the AUTOEXEC.BAT file and make
    sure it is in the CONFIG.SYS. Also delete the parameter /E:xxxx
    after CMD.EXE in the CONFIG.SYS.

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50 under MS OS/2 real mode, to Microsoft BASIC Compiler Versions
 6.00 and 6.00b under MS OS/2 real and protected modes, and to
 Microsoft BASIC Professional Development System (PDS) 7.00 under MS
 OS/2 real and protected modes.

 To reproduce the problem, do the following:

 1. Place the following lines in the CONFIG.SYS file for OS/2:

       SET COMSPEC=C:\OS2\CMD.EXE /P /E:1024
       SET SHELL=C:\OS2\COMMAND.COM /P /E:1024

 2. Place the following statement in the OS/2 AUTOEXEC.BAT file:

       SET COMSPEC=C:\OS2\COMMAND.COM /P /E:1024

    Note: The path names to CMD.EXE and COMMAND.COM may be different on
    your system, depending on how you installed OS/2.

 3. Reboot your computer with the new settings.

 4. Do one of the following, depending on whether you are in real
    (MS-DOS) or protected mode:

    a. Load QB.EXE or QBX.EXE in real mode (DOS 3.x box) and either
       choose DOS Shell from the File menu, execute the word "SHELL"
       in the immediate window, or execute a program that contains only
       the word "SHELL." Each of these will produce the "illegal
       function  call" error in QB and QBX.EXE.

    b. Under OS/2 protected mode, execute a BASIC 6.00, 6.00b,or 7.00
       compiled program whose only statement is SHELL to show the
       problem.

 To eliminate the problem, remove the COMSPEC statement from the
 AUTOEXEC.BAT file, delete the /P /E:1024 after CMD.EXE, and reboot.

 The Command Interpreter (COMMAND.COM) Under DOS
 -----------------------------------------------

 Under DOS 3.x, 4.00, and 4.01, the COMSPEC environment variable is
 defined in the AUTOEXEC.BAT file. The SET COMSPEC= statement gives DOS
 a path for where the DOS command interpreter COMMAND.COM is located on
 the disk.

 Under DOS, a SHELL= command defined in the CONFIG.SYS file tells DOS
 the name of your command interpreter. This at first may not seem
 useful, but this feature was provided so that you can write your own
 command interpreter. You can place the name of your command
 interpreter in the SHELL= statement for DOS to load that command
 interpreter at boot time. However, most people use COMMAND.COM as
 their command interpreter in both the SET COMSPEC= and SHELL= commands
 under DOS.

 If you want to set the environment size, you can use the /E:xxx
 parameter on COMMAND.COM to increase or decrease the size available
 for environment variables and the PATH.

 The Command Interpreters (CMD.EXE and COMMAND.COM) Under OS/2
 -------------------------------------------------------------

 Under OS/2, there are two command interpreters (CMD.EXE and
 COMMAND.COM) and two parameters to SET in the CONFIG.SYS file:

 1. First, the SET COMSPEC= statement tells OS/2 where to find the OS/2
    protected mode command interpreter, which is called CMD.EXE. Unlike
    COMMAND.COM, CMD.EXE does not take the parameter /E:xxxx to set the
    environment size. OS/2 does not limit the environment size as DOS
    does with COMMAND.COM. If you use /E: on CMD.EXE, it will not cause
    an error message at boot time, but it will prevent you from
    SHELLing when in an OS/2 session.

 2. Second, the SHELL= statement tells OS/2 where to find the DOS
    compatibility box command interpreter, which is called COMMAND.COM.
    Just as in DOS, COMMAND.COM will take the parameter /E:xxxx, which
    allows you to set the environment size for the DOS box command
    interpreter. Note, however, that when you go into the DOS box, OS/2
    takes the value of the SHELL in the CONFIG.SYS and SETs the DOS box
    COMSPEC equal to that value so that normal DOS programs that need
    that information will function normally. This can be shown by
    typing the word SET at the DOS box command line. This will show
    that the COMSPEC is actually set, even though it is not in the
    AUTOEXEC.BAT file.

 Note again that both COMSPEC and SHELL are set in the CONFIG.SYS file
 under OS/2. Nothing is done in the AUTOEXEC.BAT file to specify
 information about command interpreters under OS/2.


 147. Use STACK, Not FRE("), with QBX.EXE or /Fs in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 14-JAN-1990    ArticleIdent: Q57646

 With the advent of far string support in Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and OS/2, the FRE()
 function has some different properties. The following statement

    PRINT  FRE("")

 does not return the remaining default data segment (DGROUP) space when
 run in the QBX.EXE environment or when run as a program compiled with
 the /Fs (Far String) option. To obtain the remaining DGROUP space in
 these cases, you must now use the STACK function (introduced in BASIC
 7.00). For example, the following statement

    PRINT STACK

 returns the current space available in DGROUP for the STACK to be
 resized. The stack is always in DGROUP, so the new STACK function
 conveniently informs you of the total remaining space that can be used
 in DGROUP.

 This information applies to Microsoft BASIC PDS 7.00 for MS-DOS and
 MS OS/2.

 For more information on the many changes in the FRE() function in
 regard to far strings, refer to Pages 140-142 of the "Microsoft BASIC
 7.0: Language Reference" manual.


 148. Using DIR$ to Load Directory Listing into Array in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 15-JAN-1990    ArticleIdent: Q57671

 This article illustrates how to use the DIR$ function and load an
 MS-DOS or MS OS/2 directory listing into a BASIC string array. This
 information applies only to the Microsoft BASIC Professional
 Development System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 The following sample program demonstrates use of the DIR$ function
 available in BASIC PDS 7.00 to return all the files matching a given
 filespec and store them in a BASIC string array. For more information
 on the DIR$ function, see Page 107 of the "Microsoft BASIC 7.0:
 Language Reference" manual.

 Code Example
 ------------

 DEFINT A-Z
 CONST TRUE = -1
 CONST FALSE = NOT TRUE

 NumFiles = 255             'Maximum number of filenames to hold
 Counter = 0
 Finished = FALSE
 DIM FileName$(NumFiles)

 CLS     'Enter DIR type filespec, for example "C:\*.BAS":
 INPUT "Enter filespec:"; Path$

 TempName$ = DIR$(Path$)             'Get the first filename.
 IF TempName$ = "" THEN
   PRINT "No file(s) found"
 ELSE
   FileName$(Counter) = TempName$ ' Keep getting filenames until we
   Counter = Counter + 1      ' have NumFiles worth or we get them all.
   DO
     TempName$ = DIR$
     IF TempName$ <> "" THEN FileName$(Counter) = TempName$
     Counter = Counter + 1
   LOOP WHILE TempName$ <> "" AND Counter <= NumFiles
 END IF

 IF FileName$(0) <> "" THEN    'Display filenames if we received any.
   Counter = 0
   DO
     PRINT FileName$(Counter)
     IF FileName$(Counter) = "" THEN Finished = TRUE
     Counter = Counter + 1
   LOOP WHILE Counter <= NumFiles AND NOT Finished
 END IF


 149. Menus Cannot Have Zero Items in BASIC PDS 7.00 UI Toolbox

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900108-113
 Last Modified: 14-JAN-1990    ArticleIdent: Q57672

 The User Interface (UI) Toolbox routines provided with Microsoft BASIC
 Professional Development System (PDS) Version 7.00 do not allow menus
 without menu items.

 Because of this design, it is necessary to always have menu items to
 choose from. It may be possible to alter the source for the menu
 routines (MENU.BAS) and change the functionality to add the ability
 for menus without items.

 This feature is under review and will be considered for inclusion in a
 future release.


 150. "Typed Variable Not Allowed in Expression" Using Nested Arrays

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S891220-141 buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57709

 Microsoft BASIC Professional Development System (PDS) version 7.00
 allows static arrays as fields of user-defined TYPEs. This feature
 allows programs to have complex data structures such as nested arrays
 (a nested array is an array of user-defined-TYPE records that contain
 an array).

 However, compile-time errors occur using the ERASE statement and the
 LBOUND and UBOUND functions on an array of arrays (nested in a
 user-defined TYPE) when subscripted by means of a user-defined TYPE.
 The BC.EXE compiler gives the messages "Syntax error" and "Typed
 variable not allowed in expression." This problem occurs only when the
 code is compiled with BC.EXE, not when it is compiled with QBX.EXE.

 The array reference needed to produce the problem looks like the
 following:

    PRINT UBOUND(array2(typedvariable.field).nestedarray1)

 Microsoft has confirmed this to be a problem in BC.EXE in Microsoft
 BASIC Professional Development System (PDS) version 7.00 for MS-DOS
 and MS OS/2. This problem was corrected in BASIC PDS version 7.10.

 You can work around this problem by using a non-TYPEd variable as the
 subscript for the nested array (see the workaround example below).

 Code Example
 ------------

 The following code example illustrates the problem:

    TYPE Type1
       Array1(1 TO 1) AS INTEGER
    END TYPE
    TYPE Type2
       Number AS INTEGER
    END TYPE
    DIM Array2(1 TO 1) AS Type1
    DIM Var AS Type2
    Var.Number = 1
    PRINT LBOUND(Array2(Var.Number).Array1)
    '                   ^^^^^^^^^^ This TYPEd variable causes the error.

 The following code example shows a workaround for the problem:

    TYPE Type1
       Array1(1 TO 1) AS INTEGER
    END TYPE
    TYPE Type2
       Number AS INTEGER
    END TYPE
    DIM Array2(1 TO 1) AS Type1
    DIM Var AS Type2
    Var.Number = 1
    Var2% = Var.Number
    PRINT LBOUND(Array2(Var2%).Array1)
    '                   ^^^^^ Non-TYPEd variable will work.


 151. QB/QBX "Out of Stack Space" Using Large TYPE as SUB Parameter

 Product Version(s): 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.00b buglist4.50 B_BasicCom
 Last Modified: 20-SEP-1990    ArticleIdent: Q57711

 The program below demonstrates a problem with the QuickBASIC (QB.EXE)
 and QuickBASIC Extended (QBX.EXE) editors in which the environment
 runs out of stack space when passing a large user-defined TYPE
 variable to a SUBprogram.

 Microsoft has confirmed this to be a problem in QB.EXE in Microsoft
 QuickBASIC versions 4.00, 4.00b, and 4.50 for MS-DOS; in QB.EXE
 shipped with Microsoft BASIC Compiler 6.00 and 6.00b (buglist6.00,
 buglist6.00b) for MS-DOS; and in the QBX.EXE editor that comes with
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS (buglist7.00, buglist7.10). We are researching
 this problem and will post new information here as it becomes
 available.

 This problem does not occur in .EXE programs compiled with BC.EXE.

 The minimum code to duplicate this "Out of stack space" error is as
 follows:

 1. Create a TYPE that is near the size of, or larger than, the
    available stack space. (A TYPE with 2400 bytes is adequate to show
    the problem in both QB.EXE and QBX.EXE. QB.EXE has a default
    program stack size of 2K, and QBX.EXE has a default program stack
    size of 3K).

 2. DIMension an array of that TYPE. An array of one element is all
    that is necessary to reproduce the problem. The array can be
    either $DYNAMIC or $STATIC.

 3. Create a SUBprogram that takes a single element of this TYPE as a
    parameter. The SUB does not have to contain any code at all.

 4. CALL the SUB and pass one element of this array.

 5. Run the program by pressing SHIFT+F5 in the environment.

 Attempting to run this program in the editor produces an "Out of stack
 space" error followed by an "Out of memory" error before the program
 even begins to execute. The errors do NOT occur at the time of the
 CALL because the program is pushing information onto the stack. This
 can be shown by putting a breakpoint on the CALL and then attempting
 to execute the program. The CALL is never reached; the problem occurs
 during the binding and final memory allocation steps.

 This problem does not occur when the program is compiled with the
 BC.EXE compiler.

 To work around this problem, dimension the TYPEd array with DIM SHARED
 or put it in a COMMON SHARED statement.

 The following is the minimum amount of code needed to reproduce the
 problem:

    DECLARE SUB sub1 (boot AS ANY)
    TYPE rec1
      jump1 AS STRING * 2400
    END TYPE
    DIM var1(1) AS rec1
    CALL sub1(var1(1))
    END
    SUB sub1 (boot AS rec1)
    END SUB

 The following code example shows one workaround:

    DECLARE SUB sub1 ()
    TYPE rec1
      jump1 AS STRING * 2400
    END TYPE
    DIM SHARED var1(1) AS rec1
    CALL sub1
    END
    SUB sub1
    END SUB


 152. Repeated Word on Page 611 BASIC 7.0 Programmer's Guide

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr SR# S900112-170
 Last Modified: 20-JAN-1990    ArticleIdent: Q57777

 On Page 611 of the "Microsoft BASIC Version 7.0: Programmer's Guide,"
 there is a repeated word in the explanation of the stub file
 NOFLTIN.OBJ. The error is shown below.

 Page 611 states the following:

    If you link with NOFLTIN.OBJ, all numbers numbers used by INPUT,
    READ, and VAL must be legal long integers.

 It should be corrected to read as follows:

    If you link with NOFLTIN.OBJ, all numbers used by INPUT, READ,
    and VAL must be legal long integers.


 153. FORTRAN READ Statement Hangs in OS/2 If Called from BASIC

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 SR# S900103-146
 Last Modified: 17-JAN-1990    ArticleIdent: Q57795

 When running under MS OS/2, a Microsoft BASIC program LINKed with a
 FORTRAN routine that contains a READ statement will hang during
 execution. The same program compiled and linked under MS-DOS will run
 correctly.

 This problem occurs in Microsoft BASIC Compiler Versions 6.00 and
 6.00b for OS/2 and in Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for OS/2. Microsoft is researching this problem and
 will post new information here as it becomes available.

 The following two programs will hang when run. To demonstrate these
 programs from an .EXE program, compile and link as follows with the
 BASIC compiler and Microsoft FORTRAN Optimizing Compiler Version 5.00:

    BC /O /Lp BAS;
    FL /c /FPi /Lp FOR.FOR ;
    LINK /NOE /NOD BAS FOR,,,BCOM60.LIB LLIBFE.LIB;

 Please note that the above FORTRAN library LLIBFE.LIB may be called
 LLIBFEP.LIB, depending on how you installed FORTRAN.

 Code Example
 ------------

 The following BASIC program is BAS.BAS, which calls a FORTRAN
 procedure:

    DECLARE SUB FPROG()
    DIM A%(500)
    COMMON SHARED /NMALLOC/ A%()
    PRINT "Calling FORTRAN"
    CALL FPROG
    END

 The following program is FOR.FOR, which prompts you for input and then
 should display the entered value:

       SUBROUTINE FPROG()
          INTEGER i
          WRITE (*,*) 'Please enter i'
          READ (*, *) i
          WRITE (*, *) 'This is i:', i
       END

 BAS.EXE produces the following output, and then hangs:

    Calling FORTRAN
    Please enter i


 154. QBX.EXE 7.00 Editor Black & White Only on PS/2 Model 60 & 80

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900111-148
 Last Modified: 20-JUN-1990    ArticleIdent: Q57796

 The QuickBASIC Extended (QBX.EXE) environment may have problems
 displaying colors on certain IBM PS/2 models with an out-of-date 8514
 adaptor card. QBX.EXE loads and correctly runs programs that execute
 graphics in VGA SCREEN modes 12 and 13. However, the editor itself
 comes up in gray, black, and white. The only colors available under
 Display on the Options menu are gray, black, and white.

 This problem may be corrected by contacting IBM and updating the 8514
 adaptor card (or the BIOS chip on the card).

 This information applies to the QuickBASIC Extended editor (QBX.EXE)
 in Microsoft BASIC Professional Development System (PDS) version 7.00
 for MS-DOS.

 Microsoft Product Support Services has verified this problem on a PS/2
 model 60 that has a built-in VGA with an 8514 VGA color monitor. This
 problem was reproduced under MS-DOS version 3.30, under PC-DOS version
 3.30, and under the DOS 3.x box in IBM OS/2 version 1.20.

 One customer also reported this problem on a PS/2 model 80 with an
 8514A monitor. Microsoft has not confirmed this problem on a PS/2
 model 80.

 Another customer reported that on an IBM PS/2 Model 80 (under IBM DOS
 4.00) with an 8514 video card and an 80387 coprocessor installed, the
 QBX.EXE editor displays in monochrome. However, if the coprocessor is
 disabled (SET NO87="Coprocessor Disabled"), the QBX.EXE editor
 displays the proper colors. (No TSR or device drivers were in the
 system during this test.) Microsoft has not confirmed this report.

 A customer has also reported this problem on an IBM PS/2 Model 70
 using an 8515 monitor. Microsoft has not confirmed this report.

 To demonstrate that these color problems are due to the card, do the
 following:

 1. Start QBX.EXE.

 2. Unplug the monitor from the 8514 card.

 3. Plug the monitor into the VGA on the motherboard.

 4. Unplug the monitor and plug it back into the 8514 card, and correct
    color now returns.


 155. Problems Using BASIC 7.00 with Novell Advanced NetWare 2.15

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900112-81
 Last Modified:  1-AUG-1990    ArticleIdent: Q57797

 Microsoft BASIC Professional Development System (PDS) version 7.00 has
 not been fully tested under nor is it guaranteed to run under any
 version of Novell NetWare. Below are some confirmed and unconfirmed
 cases of problems using BASIC PDS 7.00 programs with Novell NetWare.

 Confirmed QBX.EXE Hanging Report
 --------------------------------

 1. Microsoft Product Support Services performed one test that showed
    that QBX.EXE may hang under Novell Advanced NetWare version 2.15
    revision C. This test was performed on an IBM AT with a 16-bit
    Ungermann Bass network card. The test was run on a nondedicated
    Novell server. The QBX.EXE editor screen comes up, but at this
    point, the machine hangs and requires a cold reboot.

    This information applies to the QBX.EXE editor that comes with
    Microsoft BASIC Professional Development System (PDS) version 7.00
    for MS-DOS.

 Unconfirmed QBX.EXE Hanging Reports
 -----------------------------------

 1. A customer reported that QBX.EXE can hang under the following
    configuration:

       COMPAQ 386/20 or ALR 386/33 computer
       Version 2.15 Novell Advanced NetWare
       Micom Interland board NI52100TP-8
       Microsoft Mouse 7.00

    When the customer booted without the Novell drivers, or with the
    Novell drivers and without the Microsoft Mouse 7.00 driver, QBX.EXE
    worked correctly without hanging. Microsoft has not confirmed this
    information.

 2. A customer reported that QBX.EXE can hang under the following
    configuration:

       IBM PS/2 Model 50z computer
       Version 2.15 revision C Novell SFT network

 3. A customer reported that a BASIC PDS 7.00 program using the
    OPEN COM statement may hang on a workstation connected to Novell
    Advanced NetWare version 2.15 revision A. When a Quarterdeck QEMM
    version 5.00 expanded memory driver was installed, the machine
    would not hang, but instead, QEMM would return an "Exception 12"
    error. When the software for the Novell Network was removed, the
    computer would not hang, nor would it generate an Exception 12
    error with the QEMM driver loaded. Microsoft has not confirmed this
    problem. The customer reported the problem on the following
    configuration:

       Dell System 310
       Novell Advanced NetWare version 2.15 revision A
       DOS version 3.30
       80387 math coprocessor
       4 MB extended memory
       Video Seven VGA video card
       Phoenix 80386 ROM BIOS Plus version 1.10 A05
       Western Digital EtherCard Plus 16, or 3Com EtherLink card

 4. A customer reported that QBX.EXE hangs on the following
    configuration (customer did not test same program run from .EXE):

       Novell NetWare 2.15 SFT revision C
       Everex Step 386
       Version 3 AMI BIOS
       MS-DOS version 4.01

 5. A customer reported that QBX.EXE hangs on the following
    configuration (customer did not test same program run from .EXE):

     Novell SFT NetWare 286 version 2.15 revision B
     Uknown name AT 286
     1 MB RAM
     MDI Graphics Card (Hercules-compatible)
     MF-II keyboard
     MS-DOS 3.30


 156. LINK /PAC Switch in 6.00/6.00b Is Now /PACKC in BASIC PDS 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr SR# S900116-46
 Last Modified:  8-JAN-1991    ArticleIdent: Q57852

 The LINK.EXE /PACKCODE switch of the Microsoft Segmented-Executable
 Linker version 5.01.20, shipped with Microsoft BASIC Compiler versions
 6.00 and 6.00b for MS-DOS and MS OS/2, can be abbreviated with /PAC on
 the LINK command line. The same is true for the Microsoft Overlay
 Linker shipped with Microsoft QuickBASIC versions 4.00, 4.00b, and
 4.50.

 This abbreviation has changed to /PACKC in the Segmented-Executable
 Linker version 5.05 shipped with Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for MS-DOS and MS
 OS/2.

 On Page 589 of the "Microsoft BASIC 7.0: Programmer's Guide" (for
 versions 7.00 and 7.10) the abbreviation for /PACKCODE is incorrectly
 documented as being /PAC. It should be changed to /PACKC.

 In addition, eleven occurences of /PAC should be changed to /PACKC on
 Pages 596-597 of the "Microsoft BASIC 7.0: Programmer's Guide" (for
 versions 7.00 and 7.10).

 The /PACKCODE switch abbreviation was changed from /PAC to /PACKC
 because a new switch was added to the linker to take advantage of
 Microsoft BASIC PDS's ability to manage multiple data segments (far
 strings). The name of the new switch is /PACKDATA and is used to pack
 small data segments together. Its abbreviation is /PACKD.

 Although it is not ambiguous to have one switch abbreviated /PAC and
 another /PACKD, because the switches have similar functions, it is
 more logical for their abbreviations to have the same first 4 letters
 ("PACK") followed by a distinguishing letter ("C" or "D").


 157. BASIC 7.00 WindowDo Doesn't Trap Click in Current Window

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891113-16
 Last Modified: 20-JAN-1990    ArticleIdent: Q57853

 The WindowDo procedure of the WINDOW.BAS toolbox file that is included
 with Microsoft BASIC Professional Development System (PDS) Version
 7.00 for MS-DOS will not trap a click in the current window unless
 that click is in a button or edit field.

 To work around this limitation, open an "area" button (button type 4)
 in the current window that is exactly the same size as the current
 window. This does not make the WindowDo procedure trap clicks in the
 current window (it is only trapping a click in a button), but it
 appears so because an area button is invisible.

 The WindowDo procedure allows you to trap window events such as
 selecting buttons and edit fields, resizing, moving, or closing a
 window, and selecting a window other than the current window. However,
 WindowDo cannot trap a click in the current window itself unless the
 click occurs on a button or edit field in that window.

 For example, suppose a program opens up two windows. For simplicity,
 we will assume that there are no buttons or edit fields opened in
 either window. By default, the last window opened (window2) is the
 current window. The WindowDo procedure will trap a click in the other
 window (window1) but not in window2. This is a design limitation of
 the WindowDo procedure and is not considered a problem.

 To easily work around this situation, in the current window, open an
 area button (button type 4) that is exactly the same size as the
 current window. The WindowDo procedure is still trapping a click in a
 button, but it appears as if a click is being trapped anywhere in the
 window because the button is hidden. Type 4 buttons are invisible.

 For a detailed explanation of the WindowDo procedure, see Page 572 of
 the "Microsoft BASIC Version 7.0: Language Reference" manual. For more
 information on area buttons (button type 4), see the ButtonOpen
 procedure on Page 557 of the same manual.

 The following example program illustrates the limitation and its
 workaround:

 '$INCLUDE: 'general.bi'   'These INCLUDE, COMMON SHARED, and DIM
 '$INCLUDE: 'mouse.bi'     'statements are generally those needed
 '$INCLUDE: 'menu.bi'      'for using the User Interface Toolbox.
 '$INCLUDE: 'window.bi'

 COMMON SHARED /uitools/ GloMenu           AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()        AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()         AS MenuItemType
 COMMON SHARED /uitools/ GloWindow()       AS WindowType
 COMMON SHARED /uitools/ GloButton()       AS ButtonType
 COMMON SHARED /uitools/ GloEdit()         AS EditFieldType
 COMMON SHARED /uitools/ GloStorage        AS WindowStorageType
 COMMON SHARED /uitools/ GloWindowStack()  AS INTEGER
 COMMON SHARED /uitools/ GloBuffer$()

 DIM GloTitle(MAXMENU)           AS MenuTitleType
 DIM GloItem(MAXMENU, MAXITEM)   AS MenuItemType
 DIM GloWindow(MAXWINDOW)        AS WindowType
 DIM GloButton(MAXBUTTON)        AS ButtonType
 DIM GloEdit(MAXEDITFIELD)       AS EditFieldType
 DIM GloWindowStack(MAXWINDOW)   AS INTEGER
 DIM GloBuffer$(MAXWINDOW + 1, 2)

 CLS
 CALL WindowInit   'Initialize window and mouse routines.
 CALL MouseInit

 'Open window1. It is the current window..
 CALL WindowOpen(1, 4, 20, 20, 36, 14, 1, 14, 1, 15, FALSE, FALSE,_
                 FALSE, FALSE, 1, "Window 1")

 'Open window2, it is now the current window.
 CALL WindowOpen(2, 4, 45, 20, 61, 14, 1, 14, 1, 15, FALSE, FALSE,_
                 FALSE, FALSE, 1, "Window 2")

 CALL MouseShow        'Show the mouse cursor.

 CALL WindowDo(0, 0)   'Wait for a window event to happen.
                       'The program will not continue until window1 is
                       'clicked. This is because clicking in window2
                       '(the current window) is not trapped by the
                       'WindowDo procedure.

 'Assume window1 is the current window now.

 'Open an area button in the current window that is the same size as
 'the current window.
 CALL ButtonOpen(1, 0, "", 1, 1, 17, 17, 4)

 CALL WindowDo(0, 0)   'Wait for a window event to happen.
                       'The program will continue if either window is
                       'clicked. Clicking window2 will be trapped
                       'because it is not the current window. Clicking
                       'window1 will be trapped because there is a
                       'button (although invisible) in window1 that
                       'is the same size as window1.


 158. BASIC PDS 7.00 Supports Short-Circuit Boolean Expressions

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | B_QuickBas SR# S890703-44
 Last Modified: 20-JAN-1990    ArticleIdent: Q57866

 Microsoft BASIC Professional Development System (PDS) Version 7.00
 supports "short-circuit" optimization of Boolean expressions, as
 described below. To take advantage of this speed optimization in
 complex IF, WHILE, DO LOOP WHILE, or DO LOOP UNTIL statements, the
 quickest Boolean conditions should appear first.

 Microsoft QuickBASIC Versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00,
 4.00, 4.00b, and 4.50 and Microsoft BASIC Compiler Versions 6.00 and
 6.00b DON'T support short-circuit Boolean expressions.

 Boolean expressions are those expressions in BASIC that evaluate to
 true or false. In BASIC, the IF, WHILE, and DO LOOP {WHILE | UNTIL}
 statements all require Boolean expressions as part of their syntax.

 A "short-circuit" Boolean expression is a unique kind of Boolean
 expression. If a Boolean expression consists of more than one part,
 not all the parts may be evaluated. The evaluation of the expression
 may stop, or "short circuit," partway through. Consider the following
 two-part Boolean expression:

    IF <condition1> AND <condition2> THEN

 If <condition1> evaluates to false, it isn't necessary to evaluate
 <condition2>, because "false" AND "anything else" is still false.
 Therefore, we can short circuit the expression and not evaluate
 <condition2>.

 The same rule applies to the following expression:

    IF <condition1> OR <condition2> THEN

 If <condition1> is true, we do not need to evaluate <condition2>
 because "true" OR "anything else" always evaluates to true.

 Short-circuit Boolean expressions are desirable for two reasons.
 First, they allow you to optimize code by evaluating only as much of
 the Boolean expression as necessary. This can generate faster, more
 efficient code. In the examples above, if <condition2> were very
 complex, a short-circuit Boolean might speed up program execution by
 evaluating the whole expression only when absolutely necessary.
 Second, short-circuit Booleans can be used to prevent error
 conditions. In the code example below, BASIC PDS 7.00 prevents the
 "Division by zero" error in .EXE programs since it supports
 short-circuit Booleans. QBX.EXE programs in BASIC 7.00, and QB.EXE and
 .EXE programs in QuickBASIC 4.00, 4.00b, and 4.50, give the "Division by
 zero" error.

 BASIC 7.00 will short circuit IF expressions as long as doing so does
 not change the semantics of the statement. The following is an
 example:

    IF (a% < b%) OR (c! < d!) THEN PRINT

 The compiler compares a% and b%. If a% is less than b%, the compiler
 skips the floating-point comparison. On the other hand, consider the
 following statements:

    DECLARE FUNCTION Foo! (p!)
    IF (a% < b%) OR (c! < Foo!(d!)) THEN PRINT

 The compiler avoids the floating-point comparison when a% is less
 than b%, but it still calls the function Foo. This is because existing
 programs may rely on the side effects of the function Foo.

 This feature affects the best way to write code in BASIC PDS 7.00.
 Specifically, in complex IF, WHILE, DO LOOP WHILE, or DO LOOP UNTIL
 conditions, the quickest conditions should appear first.

 Code Example
 ------------

 The following program determines if a compiler supports short-circuit
 Boolean optimization for an IF statement. Since it supports
 short-circuit Booleans, BASIC PDS Version 7.00 prevents the "Division
 by zero" error in the .EXE program. QBX.EXE programs in BASIC 7.00,
 and QB.EXE and .EXE programs in QuickBASIC 4.00, 4.00b, and 4.50, give
 the "Division by zero" error.

 DEFINT A-Z
 ON ERROR GOTO errorhandle
 a = 1
 b = 1
 c = 0
 CLS
 LOCATE 10, 10

 ' In the following IF statement, b / c is not executed if
 ' short-circuit Booleans are supported because a = 1 evaluates to
 ' true, and therefore, the whole expression is true. This is
 ' because (true OR <anything>) evaluates to true.

 IF (a = 1 OR ((b / c) = 1)) THEN
    ' If this PRINTs, then short-circuit Booleans are supported.
    PRINT "This compiler supports short-circuit Booleans"
 END IF
 terminate:
 PRINT "End of program reached"
 END
 errorhandle:
    IF ERR = 11 THEN PRINT "Division by zero, Error="; ERR
    LOCATE 11, 10
    PRINT "This compiler does not support short-circuit Booleans"
    RESUME terminate     ' End the program.


 159. BUILDRTM.EXE Requires BASIC 7.00 Component Libraries; SETUP

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q57882

 The BUILDRTM.EXE utility program for Microsoft BASIC Professional
 Development System (PDS) Version 7.00 can be used to create custom
 run-time modules. For BUILDRTM to function, you must have the
 component libraries available.

 The component libraries are installed by the BASIC PDS 7.00 SETUP.EXE
 program, but are deleted unless you specify that they be maintained.
 (You are prompted to delete or keep the component libraries during the
 setup procedure).

 The following lists show the component libraries needed to use
 BUILDRTM under real mode (MS-DOS) and OS/2 protected mode (note that
 all component library files have a .LIB extension):

 Real Mode (MS-DOS) Component Libraries
 --------------------------------------

    B70OBJ.LIB    B70OBN.LIB    B70ORN.LIB    B70ROBJ.LIB   B70RORJ.LIB
    B70ROBN.LIB   B70RORN.LIB   B70ROEJ.LIB   B70ROEN.LIB   B70S.LIB
    BLIBFP.LIB    EMR.LIB       B70RLN.LIB    B70RCN.LIB

 MS OS/2 Protected Mode Component Libraries
 ------------------------------------------

    B70OBJ.LIB    B70OBN.LIB    B70ORN.LIB    B70POBJR.LIB  B70PORJ.LIB
    B70POBN.LIB   B70PORN.LIB   B70POEJ.LIB   B70POEN.LIB   B70S.LIB
    BLIBFP.LIB    EMP.LIB       B70PLN.LIB    B70PCN.LIB    OS2.LIB

 To install these libraries, run the BASIC PDS 7.00 SETUP.EXE program,
 select the libraries you want to install (real or protected mode), and
 then specify that you want to maintain the component libraries.


 160. UI Toolbox Menu Bar with Menu Past 64th Column Shows Garbage

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900112-171 buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57883

 The User Interface (UI) Toolbox shipped with Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10
 incorrectly processes menu bars when the last menu item starts in the
 64th or higher column. The symptom of this errant behavior is that
 garbage characters are displayed on the screen after that menu is
 deselected.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available. A correction
 for this problem in MENU.BAS is shown below.

 To correct the source code, MENU.BAS, so that it will handle longer
 menu bars correctly, change the following IF statement (found after
 the "menuDoShowPullDown" label near the end of the MenuDo SUB)

    LEN(GloTitle(currMenu).text)

 to

    LEN(RTRIM$(GloTitle(currMenu).text))

 in both of the following places:

   IF GloTitle(currMenu).rColItem - GloTitle(currMenu).lColItem _
        < LEN(GloTitle(currMenu).text) THEN
     GloTitle(currMenu).rColItem = _
        GloTitle(currMenu).lColItem + LEN(GloTitle(currMenu).text)
   END IF

 Note: The underscore (_) characters above indicate line continuation
 to fit in this article. This block IF is actually on three long lines
 in the original source.

 The changed code is as follows:

   IF GloTitle(currMenu).rColItem - GloTitle(currMenu).lColItem _
        < LEN(RTRIM$(GloTitle(currMenu).text)) THEN
     GloTitle(currMenu).rColItem = _
        GloTitle(currMenu).lColItem + LEN(RTRIM$(GloTitle(currMenu).text))
   END IF

 This correction should be made and the libraries rebuilt to enable
 correct handling of menus beginning past the 64th column.

 The above correction is the same as for a separate article describing
 a different symptom, where the mouse-selectable area for narrow menus
 is too wide. To find this and other problems with the User Interface
 Toolbox, query in this Knowledge Base on the following keywords:

    user and interface and toolbox and buglist7.00


 161. Listbox Initialized Incorrectly in BASIC 7.00 UI Toolbox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900109-123 buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57884

 The ListBox FUNCTION in the User Interface (UI) Toolbox WINDOW.BAS
 file provided with Microsoft BASIC Professional Development System
 (PDS) versions 7.00 and 7.10 does not behave correctly when a list box
 is first activated. On initialization, the keyboard cursor is set on
 the OK button instead of in the list box.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available.

 Without the modification listed below, you must press the TAB key
 twice before using the cursor keys to move into the list box.

 To correct this behavior, the initial value of currButton (set early
 in the ListBox FUNCTION) must be changed from 2 to 0. The following
 are the statements from the ListBox FUNCTION of WINDOW.BAS adjacent to
 (and including) the incorrect statement:

    currTop = 1
    currPos = 1
    currButton = 2       '****** Need to change this to currButton = 0

    GOSUB ListBoxDrawText

 This correction should be made and the libraries rebuilt to have the
 cursor positioned properly in the list box.

 To find other problems with the User Interface Toolbox, query in this
 Knowledge Base on the following words:

    User and Interface and Toolbox and buglist7.00


 162. Disabled First Menu Malfunctions in BASIC 7.00 UI Toolbox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900108-102 buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57885

 The User Interface (UI) Toolbox menu routines, provided with Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS, do not behave correctly when the first menu on the line is
 disabled. In this case, the menu can still be chosen with the ALT+X
 key combination.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available.

 This article provides an example demonstrating the problem and the
 correction to MENU.BAS.

 Use the following command line to set up QBX for demonstrating the
 problem:

    QBX /L UITBEFR

 The following code example disables the first (only) menu, but it can
 still be selected with the ALT+X keys. To demonstrate the problem,
 press ALT, which incorrectly highlights the first menu, then press the
 DOWN ARROW, which incorrectly brings down the menu item (without a
 proper menu box).

 REM $INCLUDE: 'General.bi'
 REM $INCLUDE: 'Mouse.bi'
 REM $INCLUDE: 'Menu.bi'
 COMMON SHARED /uitools/ GloMenu AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle() AS MenuTitleType
 COMMON SHARED /uitools/ GloItem() AS MenuItemType
 DIM GloTitle(MAXMENU) AS MenuTitleType
 DIM GloItem(MAXMENU, MAXITEM) AS MenuItemType

 CLS
 MenuInit
 MenuSet 1, 0, 0, "Menu Title", 1   '*** Disable main level menu
 MenuSet 1, 1, 1, "Exit", 1
 MenuPreProcess
 MenuShow
 MouseShow

 '*** It should not be possible to select the menu. Pressing
 '*** ALT highlights the first menu and the arrow brings down
 '*** other options (with incorrect highlighting).

 WHILE NOT ((menu = 1) AND (item = 1))
    IF MenuInkey$ = "menu" THEN
       menu = MenuCheck(0)
       item = MenuCheck(1)
    END IF
 WEND

 The following IF statement is taken from the end of the MenuDoInit
 GOSUB routine near the beginning of the MenuDo SUB:

     IF lButton THEN
         mouseMode = TRUE
         currMenu = 0
         currItem = 0
     ELSE
         mouseMode = FALSE
         currMenu = 1               '****** These lines need
         currItem = 0               '****** to be changed.
         GOSUB MenuDoShowTitleAccessKeys
     END IF

 The above IF statement should be replaced with the following IF
 statement:

     IF lButton THEN
         mouseMode = TRUE
         currMenu = 0
         currItem = 0
     ELSE
         mouseMode = FALSE
         currMenu = 0               '****** Set defaults to 0
         currItem = 0               '******
         FOR m=1 TO MAXMENU         '****** Search each menu
            IF GloTitle(m).state = 1 THEN ' check state
               currMenu=m           '****** set menu for 1st state
               EXIT FOR             '****** and exit
            END IF                  '******
         NEXT                       '****** last line of changes
         GOSUB MenuDoShowTitleAccessKeys
     END IF

 This correction should be made and the libraries rebuilt to properly
 disable a menu item.

 To find any other problems with the User Interface Toolbox, query on
 the following words:

    User and Interface and Toolbox and buglist7.00


 163. Overhead for /V and /W Event Trapping Is Reduced in BASIC 7.00

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q57890

 The code overhead for BC /V is only 3 bytes per statement, and the
 code overhead for BC /W is only 3 bytes per labeled or numbered line,
 in Microsoft BASIC Professional Development System (PDS) Version 7.00
 for MS-DOS and MS OS/2.

 The overhead for these event trapping options is 5 bytes in Microsoft
 QuickBASIC Versions 4.00, 4.00b, and 4.50 for MS-DOS, and in Microsoft
 BASIC Compiler Versions 6.00 and 6.00b for MS-DOS and MS OS/2.

 Event trapping for the ON <event> GOSUB statements is handled by
 polling. The <event> can be COM(n), KEY(n), PEN, PLAY(), STRIG, and
 TIMER. In BASIC 6.00, 6.00b, and 7.00, you can also use ON SIGNAL and
 ON UEVENT.

 At various points in your code, as controlled by the /V and /W options
 and the <event> ON and <event> OFF statements, the compiler places a
 call instruction to a routine that checks for events. /V places the
 call on every statement in the module. /W only places the call on
 every numbered or labeled line in the module. In QuickBASIC Versions
 4.00, 4.00b, and 4.50 and in Microsoft BASIC Compiler 6.00 and 6.00b,
 this call occupies 5 bytes. In BASIC 7.00, this has been reduced to 3
 bytes per call.


 164. How BC /G2 Option Makes Smaller .EXE Code in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified:  2-FEB-1990    ArticleIdent: Q57891

 In Microsoft BASIC Professional Development System (PDS) Version 7.00
 for MS-DOS and MS OS/2, the BC /G2 option generates code that is
 specific to computers containing an 80286 processor chip. Code
 generated with /G2 will run on computers with 80286 and 80386 chips,
 but will not run on computers with 8086 or 8088 chips.

 When compiled with the /G2 option, a program may be zero to ten
 percent smaller. The percentage by which the size decreases is usually
 more significant than the percentage by which the speed improves.

 Note: The 80286 chip is also known as the 286, for short. The 80386 is
 also known as the 386.

 The biggest gain from the use of 286 instructions is the PUSH
 immediate instruction. This is an operation frequently used by the
 compiler. To get an idea of how many bytes you would save, compile an
 existing program with the /A option and look for sequences of the
 following:

    MOV     reg,constant
    PUSH    reg

 These will be replaced with a single PUSH instruction, saving 1 or 2
 bytes per instance.

 We provided the BC /G2 option for developers who market their
 compiled-BASIC products to customers with 286 or 386 machines.


 165. Buttons Not Allowed in Resizeable Windows in 7.00 UI Toolbox

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891108-73
 Last Modified:  2-FEB-1990    ArticleIdent: Q57924

 Resizable windows created by the WindowOpen procedure of the
 WINDOW.BAS User Interface (UI) Toolbox file are not allowed to contain
 buttons. This design of the UI Toolbox is not documented. This
 information applies to Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for MS-DOS and MS OS/2.

 Microsoft BASIC PDS 7.00 comes with toolbox files that allow you to
 program windows, menus, scroll bars, edit fields, and buttons. One of
 the files, WINDOW.BAS, contains a procedure called ButtonOpen, which
 opens a button in the current window. Windows themselves can be opened
 with another procedure in WINDOW.BAS called WindowOpen.

 Among the many attributes you can specify when opening a window is
 whether or not the window can be resized. If this attribute is
 specified, making the window resizable, the ButtonOpen procedure will
 not open a button in that window. ButtonOpen doesn't report this as an
 error; it simply doesn't open the button.

 Although this design is not documented, it is obvious when examining
 the source code of the ButtonOpen procedure and is considered a
 limitation, not a problem.

 The source code of the User Interface Toolbox files (WINDOW.BAS,
 MENU.BAS, MOUSE.BAS, and GENERAL.BAS) is provided so that you can
 modify them if you want to overcome any of their inherent limitations,
 such as the one described above. This modification can be safely done
 only if you have a full understanding of every module of the User
 Interface Toolbox, which may require much time and effort.

 However, a less safe but much quicker workaround for the above
 limitation has been used successfully. (Note: This procedure has not
 been extensively tested and is not guaranteed by Microsoft to work
 properly under any circumstances.)

 To use this workaround, comment out the line "resize = TRUE" in the
 ButtonOpen procedure of the WINDOW.BAS file. It is the first and only
 line inside the first IF/END structure of the procedure. The following
 code fragment identifies the IF/END structure and the statement that
 must be commented out:

    IF MID$(WindowBorder$(GloWindow(WindowCurrent).windowType), 9, 1) =
    "+" THEN
        resize = TRUE   'Comment out this statement.
    END IF

 After commenting out the line, the ButtonOpen procedure will open
 buttons in a resizable window. However, it is your responsibility to
 make sure that any buttons opened stay within the window boundaries
 after any resizing has been done.


 166. BASIC Does Not Support 8514 VGA Text Modes in OS/2

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S891229-63
 Last Modified: 31-JAN-1990    ArticleIdent: Q57927

 Microsoft BASIC does not support the VGA-specific screen modes, such
 as 50-line mode, in MS OS/2 protected mode set up for 8514 video
 cards. If the 8514 card is set up as a VGA card only, then BASIC can
 recognize the VGA TEXT modes. BASIC offers no support for the 8514
 extended modes.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS OS/2, and to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS OS/2.

 When trying to utilize VGA-specific line modes, BASIC returns an
 "Illegal Function Call" error when using an 8514 card in MS OS/2.

 The following program demonstrates the problem:

    PRINT "This line will print"
    WIDTH 80,50         ' this line gives "Illegal Function Call"
    SYSTEM

 Compile and link as follows:

    BC /LP /O TEST.BAS;
    LINK TEST;


 167. EXE Does Nothing If BC.EXE Compiled from GW-BASIC Binary Code

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q57931

 Programs saved in the Binary (the default tokenized) format in the
 GW-BASIC or BASICA Interpreter will appear to compile in BC.EXE and
 LINK into an .EXE program without error in the BASIC compilers listed
 further below. However, the resulting .EXE file created from a Binary
 GW-BASIC or BASICA source program does nothing when run -- it just
 drops back to DOS.

 The BC.EXE compiler fails to abort and give an error message when you
 mistakenly give it GW-BASIC or BASICA Binary files. Microsoft has
 confirmed this to be a problem in Microsoft BASIC Compiler versions
 6.00 and 6.00b; in Microsoft BASIC Professional Development System
 (PDS) versions 7.00 and 7.10; and in Microsoft QuickBASIC versions
 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b, buglist4.50). We are
 researching this problem and will post new information here as it
 becomes available.

 To correctly create an EXE file from a GW-BASIC or BASICA program, it
 must first be saved in ASCII (text) format in the GWBASIC.EXE or
 BASICA.EXE editor. The following GW-BASIC or BASICA statement will
 save TEST.BAS in ASCII format:

    SAVE "TEST",A

 Binary format is the default SAVE format in BASICA and GW-BASIC; thus,
 you must explicitly save with the A (ASCII) option before BC.EXE can
 handle the source file.

 BASICA is an interpreter shipped in the ROM of some IBM and COMPAQ
 computers. Microsoft GW-BASIC Interpreter is shipped with some
 versions of DOS, depending upon the hardware vendor or the version of
 MS-DOS.

 Additional reference words: B_QuickBas B_GWBasicI


 168. BC 6.00 User's Guide, NOVGA.OBJ Affects SCREENs 11-13, Not 3

 Product Version(s): 6.00 6.00b | 6.00 6.00b
 Operating System:   MS-DOS     | OS/2
 Flags: ENDUSER | docerr SR# S900121-5
 Last Modified:  2-FEB-1990    ArticleIdent: Q58019

 On Page 10 of the "Microsoft BASIC Compiler 6.0: User's Guide," Table
 3.1 incorrectly states that NOVGA.OBJ removes support for screen mode
 3 features. The chart should actually show the following:

    NOVGA.OBJ    Video Graphics Array (VGA) features (screen modes
                 11, 12, and 13) absent.

 This correction applies to the user's guide for Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS-DOS and MS OS/2.

 This documentation error was corrected in the documentation for
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2.


 169. Can't Search on Blank String Field in BASIC 7.00 ISAM

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900119-140
 Last Modified:  2-FEB-1990    ArticleIdent: Q58020

 Blank string fields cannot be searched on with the ISAM file handler
 that comes with Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS.

 If a search is performed on a string field (whether the field is the
 entire index or part of a combined one) and the entire field is filled
 with spaces, the record will not be found and an end-of-file condition
 will be returned.

 To work around this problem, represent blank fields by inserting some
 other character into them and searching on the presence of that
 character in the field.

 Due to the way the ISAM engine stores string fields in a database
 table, completely blank string fields cannot be found when you use the
 SEEKGT, SEEKGE, or SEEKEQ statements. This is the case whether the
 string field represents the entire index or whether it is a field
 (primary or not) included in a combined index. Also, the same behavior
 is exhibited with fields that are unique and with those that have
 duplicates.

 This characteristic of the ISAM file handler is due to the way it
 strips off leading and trailing spaces from a string field to conserve
 disk space. For example, if the string " abc " (length of 5, with one
 leading and one trailing space) is inserted into a string field with a
 length of 10, "abc" (a length of 3) is actually written to the table.
 Therefore, inserting a string consisting entirely of spaces results in
 nothing being written to the table because every character is stripped
 off.

 The best workaround for this situation is to associate a special
 character with string fields that are to be completely blank and set
 the field equal to that character. Then, in all subsequent searches on
 this field, use that character as the key.


 170. BASIC 7.00 MousePoll Gives Screen, Not Window Coordinates

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S891108-92
 Last Modified:  2-FEB-1990    ArticleIdent: Q58024

 The MousePoll routine of the MOUSE.BAS file that comes with the User
 Interface (UI) Toolbox in Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS returns the absolute screen
 coordinates of the mouse text cursor as well as the status of the left
 and right mouse buttons.

 Using the window routines of the WINDOW.BAS toolbox file (also
 included) does not make the MousePoll routine return coordinates that
 are relative to the top-left corner of the current window. They are
 always relative to the top-left corner of the screen. This may not be
 apparent because the documentation presents all the toolbox files as
 being part of a user-interface unit; therefore, it may appear that the
 MousePoll routine returns coordinates that are relative to the current
 window.

 Included with Microsoft BASIC PDS is a toolbox source file called
 MOUSE.BAS. There is a routine in this module called MousePoll, which
 when called returns the vertical and horizontal coordinates of the
 mouse text cursor plus the status of the left and right mouse buttons.

 The coordinates returned are absolute screen coordinates. That is, if
 the mouse cursor is at the top-left corner of the screen, the
 coordinate pair (vertical, horizontal) returned is (1,1).

 This may lead to some confusion for those who are using another of the
 toolbox source files, WINDOW.BAS. This module contains (among many
 other things) routines used to open, resize, move, and print to
 windows. When addressing locations in these windows, relative (not
 absolute) coordinates are used. That is, the top-left corner of the
 window has coordinates (1,1) even if it is not in the same position as
 the screen's top-left corner (1,1).

 Therefore, it is important to note that the MousePoll subprogram does
 not return coordinates relative to any window's top-left corner, but
 always returns coordinates relative to the screen's top-left corner.


 171. BASIC PDS 7.10 Allows Line Numbers 40 Digits Long; Correction

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900120-1 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58027

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS and MS OS/2 are enhanced to allow line numbers as
 long as 40 numbers (characters) long. However, Page 697 of Appendix A
 in the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00 and 7.10)
 incorrectly states that the largest line number possible is 65,529.

 The following code example demonstrates using large line numbers in
 BASIC PDS 7.00 and 7.10

    ON KEY(1) GOSUB 1234567890123456789012345678901234567891
    KEY(1) ON
    CLS
    PRINT "starting"
    WHILE a$ <> "q" AND a$ <> "Q"
    a$ = INKEY$
    WEND
    END

    1234567890123456789012345678901234567891
              PRINT "That is the F1 key"
              PRINT "Hit 'q' or 'Q' to quit"
              RETURN


 172. Alternate Math (BC /FPa) Won't Always Produce Smaller .EXE's

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | docerr SR# S900122-49
 Last Modified:  8-JAN-1991    ArticleIdent: Q58035

 Using alternate math (BC /FPa) does not always produce smaller
 executable files than using the emulator math library (BC /FPi) when
 compiling with Microsoft BASIC Compiler Versions 6.00 and 6.00b for
 MS-DOS and MS OS/2 and Microsoft BASIC Professional Development System
 (PDS) Versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Page 8 of the "Microsoft BASIC Compiler 6.0: User's Guide" and Page
 562 of the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00 and
 7.10) misleadingly state that "it [the alternate math library] also
 creates a smaller executable file." Page 545 of the "Microsoft BASIC
 7.0: Programmer's Guide" misleadingly states that "alternate math is
 an IEEE-compatible math package optimized for speed and size."

 Although there is an initial space savings from using the alternate
 math libraries, each individual floating-point calculation can take
 more room using the alternate math library than the equivalent code
 for the emulator math library. This means that as the code grows in
 size, the initial space savings can be lost and the program can
 actually be larger using the alternate math package.

 Note: You will only notice a savings in the size of an executable
 compiled /FPa versus /FPi if the program is also compiled with the /O
 (stand-alone) option. If you compile as non stand alone with the
 alternate math library (/FPa) option, the program will actually
 contain both math libraries -- the compiled program will contain the
 alternate math routines, while the BASIC run-time module
 (BRUN60Ax.EXE, BRUN61Ax.EXE, or BRT70Axx.EXE) will contain the
 emulator math routines.

 The small program below demonstrates the size difference when
 compiling with and without the alternate math package.

 Compile the following program in these two ways:

   BC /FPa test, test1.obj;
   BC /FPi test, test2.obj;
   LINK test1;
   LINK test2;

 Code Example
 ------------

    REM  This is TEST.BAS
    a = 6.1
    b = 5.7
    c = a * b

 The program compiled with the alternate math package (/FPa) produces
 larger code for the floating-point operation than the equivalent
 instructions using the emulator math library (/FPi). There is,
 however, an initial savings of about 4K when compiling with the
 alternate math library. In most programs, this initial savings offsets
 any extra code generated by floating-point calculation. In larger
 programs with lots of floating-point calculations, the extra code for
 each floating-point operation can actually create a larger executable
 file.


 173. "Internal Error" Using Two-Dimensional Single-Precision Array

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist7.00 fixlist7.10
 Last Modified: 21-SEP-1990    ArticleIdent: Q58039

 The code example below generates the error message "Internal Error
 near 8C54" when compiled using the BC.EXE shipped with Microsoft BASIC
 Professional Development System (PDS) version 7.00 for MS-DOS and MS
 OS/2. This problem does not occur in the QBX.EXE environment or in
 earlier compiler versions.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00. This problem was corrected in BASIC PDS version 7.10.

 Code Example
 ------------

   DIM a (4, 4), b(4, 4)
   k% = i% + 1
   a(0, j%) = a(0, k%)
   b(0, j%) = b(0, k%)

 To work around this problem in 7.00, compile using the BC /D (Debug)
 option, or change the arrays to integer arrays or double-precision
 arrays. To cause the error, the array must be single precision,
 two-dimensional, and referenced with integer variables as shown.


 174. "Insufficient EMS to Load Overlays" at Run Time in 7.00, 7.10

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900808-19
 Last Modified:  5-SEP-1990    ArticleIdent: Q64876

 The run-time error message "Insufficient EMS to load overlays" occurs
 (if it is going to occur at all) when the first overlaid module is
 called. This error is documented on Page 656 of the "Microsoft BASIC
 7.0: Language Reference" manual for Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10. The article below
 explains in more detail why you might get this error condition.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS when using linked
 overlays.

 The "Insufficient EMS to load overlays" error message is not random.
 If you run a program on a particular machine and the error does not
 occur, the error will never occur for that program unless that
 machine's expanded memory configuration is changed. Common ways of
 changing the expanded memory configuration include the following:
 setting up a larger RAM drive in expanded memory; or moving the
 program to another machine with a different amount of free expanded
 memory.

 If a given program produces an "Insufficient EMS to load overlays"
 error on a given machine, the error will always occur for that program
 as long as the machine's expanded memory configuration and usage stay
 the same.

 When a BASIC program calls the first overlaid module, the program
 must estimate the space in expanded memory necessary to load all
 overlays at once. This estimate is based only on the following:

 1. The number of overlays
 2. The size of the largest overlay
 3. The fact that each overlay has less than 64K of code (otherwise, it
    would not be able to use expanded memory)

 The overlay manager in BASIC 7.00 and 7.10 requests expanded memory in
 16K pages (blocks). The overlay manager knows the size of only the
 largest overlay and must make a "best guess" at the size of the
 smaller overlays. When the overlay manager estimates how many 16K
 pages are necessary to hold all overlays at once in expanded memory,
 the estimate could be over or under the actual number of pages needed.
 If your overlays are all between 16K and 64K in size (according to the
 LINK .MAP file), and if the estimated or actual size of all overlays
 together exceeds the available expanded memory, the following
 initialization error occurs when the first overlay is called at
 run-time:

    Insufficient EMS to load overlays

 Note: You will never see this error if all your overlays are smaller
 than 16K each.

 If you want to force loading overlays from disk, thus avoiding the
 possibility of this overlay-initialization error in expanded memory,
 you must link with the stub file NOEMS.OBJ (with no parentheses around
 NOEMS.OBJ on the LINK command line). Alternatively, you can try
 reconfiguring expanded memory so more of it is available for BASIC
 overlays. Another alternative is to make overlays similar in size.

 To find out the size of each overlay, you must look at the .MAP file
 generated by the linker (LINK.EXE).

 References:

 For more information about how to use link overlays in BASIC 7.00 and
 7.10, search in this Knowledge Base for a separate article with the
 following words:

    How and link and overlays and expanded and memory and BASIC

 See also the section "Linking with Overlays" on Pages 612-614 in the
 "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10.


 175. INTERRUPTs Using Strings Need SSEG for Segment in QBX & BC /Fs

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_C H_MASM SR# S900112-133
 Last Modified:  2-FEB-1990    ArticleIdent: Q58041

 Because the QuickBASIC Extended (QBX.EXE) editor that comes with
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 uses far addresses for all strings, some CALL INTERRUPT statements
 that worked in earlier versions of Microsoft's BASIC products require
 modification for correct results.

 To correct for this behavior, change the segment passed to the
 INTERRUPT to be SSEG(stringvariable).

 This information applies to Microsoft QuickBASIC Extended (QBX.EXE)
 and to programs compiled with BC /Fs in Microsoft BASIC PDS Version
 7.00 for MS-DOS and MS OS/2.

 In earlier versions of Microsoft BASIC's, near strings were used.
 Because of this, the VARSEG of the string variable, or -1 in some
 cases, could be used for the segment. In BASIC PDS 7.00, you must use
 the SSEG function to return the segment of a string variable.

 The following table shows the difference in the method of assigning
 the registers for string variables:

    BASIC Versions 6.00/6.00b    BASIC PDS Version 7.00
    -------------------------    ----------------------

    inregs.DS = VARSEG(a$)       inregs.DS = SSEG(a$)   '**** SSEG
    inregs.DX = SADD(a$)         inregs.DX = SADD(a$)
    inregs.ES = -1               inregs.ES = SSEG(b$)   '**** SSEG

 In addition to INTERRUPTs, the change to far strings could also have
 the same effect on mixed-language programming with Microsoft C and
 Microsoft Macro Assembler (MASM).


 176. No Beep When Clicking Outside Modal Window of WINDOW.BAS

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900116-127 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58102

 Using a mouse to select outside a modal window created with the
 WindowOpen procedure of WINDOW.BAS does not produce a beep. This is
 contrary to Page 575 of the "Microsoft BASIC 7.0: Language Reference"
 manual (for 7.00 and 7.10), which incorrectly says:

    When a window is modal, any attempt to select outside the window
    is unsuccessful and results in a beep.

 WINDOW.BAS is a file provided with the User Interface (UI) Toolbox in
 Microsoft BASIC Professional Development System (PDS) Versions 7.00
 and 7.10 for MS-DOS.

 While a modal window is current, pressing certain keys generates a
 beep, but no beep is generated when you click outside the window with
 the mouse. The keys that generate a beep are as follows [Note: This
 list assumes a 101-key (enhanced) keyboard]:

    ESC
    UP ARROW
    DOWN ARROW
    LEFT ARROW
    RIGHT ARROW
    HOME
    END
    PGUP
    PGDN
    ENTER (on main keyboard)
    TAB
    ENTER (on numeric keypad)
    1, 2, 3, 4, 5, 6, 7, 8, 9 (on numeric keypad)


 177. Compiler Options Explained for QBX.EXE's Make EXE File Command

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified: 29-JAN-1991    ArticleIdent: Q58106

 The following is a complete description of the compiler options
 available when you choose the Make EXE File command from the Run menu
 in the QuickBASIC extended (QBX.EXE) environment. This information is
 also available in the "Microsoft BASIC 7.0: Language Reference" manual
 (for 7.00 and 7.10) under "appendixes," Page 608.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Although the QBX.EXE editor can run only under MS-DOS or the DOS real
 mode of MS OS/2, the Make EXE File command in QBX.EXE can use the /Lp
 option to create programs that require MS OS/2 protected mode.

 ------------------------ Make EXE File -------------------
                 ____________________________________
 EXE File Name: |____________________________________|

 This box lets you specify the name of the output .EXE file.

 ----- EXE Type -----------------------------------------
 [] Stand-Alone EXE           /O
 [] EXE Requiring BRT Module
 --------------------------------------------------------

 /O -- Substitutes the default stand-alone library for the default
 run-time library (creates a stand-alone executable file that can run
 without a BASIC run-time module). Stand-alone programs can be
 significantly larger than programs compiled to use the run-time
 module. /O is selected by default in this Make EXE File window.

 EXE Requiring BRT Module -- Makes an EXE program that requires the
 presence of BRT70XXX.EXE at run time. The XXX depends upon the /Fpi or
 /Fpa math package, near or far strings, and real or protected mode.

 ----- Speed -------------------------------------------
 [] 80x87 or Emulator Math   /Fpi
 [] Alternate Math           /Fpa
 [] Code Generation for 286   /G2
 [] Quick Call Optimization   /Ot
 -------------------------------------------------------

 /Fpi -- Causes the compiler to generate "in-line instructions" for use
 in floating-point operations. This option is the default.

 /Fpa -- Causes your program to use the alternate-math library for
 floating point operations.

 /G2 -- This option generates 80286-specific instructions (which
 actually affects size more than speed)

 /Ot -- Optimizes execution speed for SUB and FUNCTION procedures and
 DEF FN statements. To use this type of optimizing, certain conditions
 must be met. The frame size generated for SUB and FUNCTION procedures,
 and statements defined by DEF FN, depends on which of the following
 conditions exist in your code:

    For SUB and FUNCTION procedures:

    A reduced frame is generated with /Ot if no module-level handler
    exists in the code, and the /D or /Fs isn't used. A full frame is
    generated if your code uses local error handlers, calls a DEF FN or
    GOSUB statement, has returned (because of a GOSUB or other reason),
    or contains an ON event GOSUB.

    For statements defined by DEF FN:

    A full frame is generated if the /D, /Fs, /E, or /X option is used.
    In all other cases, no frame is generated if the /W or /V option is
    used. In all other cases, no frame is generated.

 ---- Target Environment --------------------------------
 [] DOS or OS/2 Real Mode     /Lr
 [] OS/2 Protected Mode       /Lp
 --------------------------------------------------------

 /Lr -- Creates a real-mode object file (the default). This makes
 .EXE programs that run in MS-DOS or the real mode (the DOS 3.x box)
 of MS OS/2.

 /Lp -- Creates a protected-mode object file (to make .EXE programs
 that run in OS/2 protected mode).

 ---- Size/Capacity -------------------------------------
 [] Far Strings                /Fs
 [] Near Strings
 [] Disable String Compression /S
 --------------------------------------------------------

 /Fs -- This option enables far-heap strings in user programs.

 Near Strings -- This option enables near (DGROUP) strings in user
 programs.

 /S -- Writes quoted strings directly to the object file instead of the
 symbol table in memory. Use this option when an "Out of memory" error
 message is generated while BC.EXE is compiling a program that has many
 string constants.

 ---- Debug ----------------------------------------------
 [] Run-Time Error Checking    /D
 [] CodeView Information       /Zi
 ---------------------------------------------------------

 /D -- Generates debugging code for run-time error checking; enables
 CTRL+BREAK. For ISAM programs, causes BASIC to write open database
 buffers to disk after every DELETE, INSERT, UPDATE, and CLOSE
 statement. You must use either /Ah or /D when you are compiling Quick
 library routines that will be loaded into QBX with the /Ea option
 (which moves arrays into expanded memory).

 /Zi -- This option adds debugging information to the object file that
 can be used by the Microsoft CodeView (CV.EXE, or CVP.EXE) debugger.

 QBX.EXE 7.10 adds an "Additional Options" field (not found in 7.00),
 which lets you specify any additional compiler options for invoking
 BC.EXE.

 There are four buttons at the bottom of the window:

 Make EXE -- This button shells out to DOS, runs BC.EXE with the
 specified options, runs LINK.EXE, creates an executable BASIC .EXE
 program, and returns to QBX.EXE.

 Make EXE and Exit -- This button transfers control to BC.EXE with the
 specified options, runs LINK.EXE, creates an executable BASIC
 .EXE program, and ends control in DOS, where you can run the .EXE.

 Cancel -- The Cancel button removes the Make EXE File window and
 returns you to the main QBX.EXE screen.

 Help -- The Help button briefly describes a few features of the Make
 EXE File window.


 178. BASIC 7.00 Wrong Integer FOR-NEXT Index Results in .EXE

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900123-121 buglist7.00 fixlist7.10
 Last Modified:  1-AUG-1990    ArticleIdent: Q58108

 In a compiled .EXE program, a FOR ... NEXT loop with an ending loop
 counter value that is a variable and with a body that contains an
 integer or long integer array assigned to a single- or
 double-precision value can PRINT an incorrect value for the loop
 counter. This problem occurs in a compiled .EXE program only, not in
 the QuickBASIC Extended environment (QBX.EXE). An example of this
 problem is shown in the program below.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) version 7.00 for MS-DOS and MS
 OS/2. This problem was corrected in Microsoft BASIC PDS version 7.10.

 The program below illustrates two conditions that, when occurring
 together, can produce an undesirable effect. The root of this error is
 embedded in the BASIC compiler (BC.EXE) optimization techniques. The
 two conditions necessary to show this problem are as follows:

 1. A variable (not a constant) is used as the stop (ending) loop
    counter value on a FOR ... NEXT statement.

 2. An integer or long integer array (which is subscripted with the
    loop counter) is assigned to a single- or double-precision number.
    (This is known as "typecasting" -- a single- or double-precision
    number is typecasted to an integer or long integer.)

 The problem occurs only on the first PRINT statement in the source
 file that prints the loop counter (i%). For all loop iterations, that
 PRINT i% statement incorrectly displays the fixed value of t#, the
 ending loop value. PRINT i% statements farther down in the source code
 work correctly.

 To eliminate the problem, use one of the following workarounds:

 1. Compile with the BC /X option.

      Note: In the example below, the debug compiler option (/D) does
      not correct the problem.

 2. Use the CINT() function to convert the real number to an integer
    before assigning it to the integer or long integer array.

 3. Use a numeric constant (instead of a variable) for the ending
    value of the FOR loop counter.

 4. Compile with the BC /FPa option (instead of the default /FPi).

 Code Example
 ------------

    Dim ia%(10)            'An integer or long array shows problem.
    t# = 5                 't# can be any numeric type (!, @, #, %, or &)
    FOR i% = 1 to t#       't# is the ending value of the loop counter, i%
    PRINT i%;              'This value incorrectly prints equal to t# in .EXE
    ia%(i%) = 46.7         'A real number is typecast to an integer or
                           'long-integer value and assigned to the array
 REM ia%(i%) = CINT(46.7)  'Workaround: use CINT(46.7) in the above line.
    PRINT i%;              'This value prints correctly.
    PRINT ia%(i%)          'This value prints correctly.
    NEXT i%
    END

 Below is the (incorrect) output from this .EXE (compiled without
 BC /X):

    5   1   46.7
    5   2   46.7
    5   3   46.7
    5   4   46.7
    5   5   46.7

 The output should be as follows:

    1   1   46.7
    2   2   46.7
    3   3   46.7
    4   4   46.7
    5   5   46.7


 179. BASIC 7.00/7.10: Incorrect Results with Alternate Math Library

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q58124

 Using Microsoft BASIC Professional Development System (PDS) version
 7.00 for MS-DOS and MS OS/2, the code example below produces incorrect
 results when compiled with the alternate math library (/FPa).

 This code works correctly in the QBX.EXE environment or when compiled
 with BC /D (debug) or /X. It also works correctly when compiled with
 BC /FPa in Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS
 and MS OS/2. Dimensioning the array as double-precision also works
 around the problem.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00. This problem was corrected in BASIC PDS 7.10.

 Code Example
 ------------

    DIM A(3)
    A(i%) = 5
    sx = A(i%)
    pr = .1 * A(i%)
    PRINT pr, sx, A(i%)

 Compile as follows:

    BC prog /o /fpa;

 Link as follows:

    LINK prog;

 The correct output from BASIC 7.10 is as follows:

    .5     5     5


 180. "Error Loading File (x.QLB)" After QBX /L x; Must Compile /Fs

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900126-5
 Last Modified: 26-FEB-1990    ArticleIdent: Q58125

 The error "Error in loading file (xxx.QLB )" occurs when loading a
 Quick library into QBX.EXE if the Quick library contains BASIC modules
 compiled without the BC /Fs (far strings) option. The BC /Fs option is
 needed because far strings are always used in the QuickBASIC Extended
 (QBX) environment.

 To create a Quick library that is usable in QBX, recompile with the BC
 /Fs option and relink (LINK /QU) to make a new Quick library.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 The necessity of using the /Fs option to make Quick libraries is
 documented on Page 617 of the "Microsoft BASIC 7.0: Programmer's
 Guide." For more information on Quick libraries, see Chapter 19,
 "Creating and Using Quick Libraries."


 181. BASIC PDS 7.00 List of Stub Files for Linking Smaller .EXE's

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900112-169
 Last Modified: 26-FEB-1990    ArticleIdent: Q58175

 Below is the list of linker stub files that come with Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS and MS
 OS/2. Stub files are special object files that block the inclusion of
 certain pieces of the BASIC run-time routines in the final .EXE file
 at link time. Most stub files can reduce .EXE program size and memory
 usage.

 This list can also be found on Pages 540-541 and 610-611 of the
 "Microsoft BASIC 7.0: Programmer's Guide," and on Pages 10-12 of the
 "Microsoft BASIC 7.0: Getting Started" manual.

 BASIC 7.00 Stub Files
 ---------------------

 Filename              Description
 --------              -----------

 OVLDOS21.OBJ          DOS 2.10 support to an overlaid program. Does
                       not reduce .EXE size.

 NOCGA.OBJ             Removes support for CGA graphics (SCREEN modes 1
                       and 2).

 NOCOM.OBJ             Removes communications ("COM1:", "COM2:") device
                       support in two cases. LINK includes
                       communications support overhead only if you use a
                       string variable in place of the file or device
                       name, as in OPEN A$ FOR OUTPUT AS #1, or if you
                       use a string constant starting with COMn in an
                       OPEN statement.

 NOEDIT.OBJ            Reduces functionality of the editor provided
                       with the INPUT and LINE INPUT statements to
                       support only ENTER and BACKSPACE keys (no HOME,
                       END, etc.).

 NOEGA.OBJ             Removes support for EGA graphics (SCREEN modes
                       7, 8, 9, 10, 11).

 NOEMS.OBJ             Prevents the overlay manager from using Expanded
                       Memory Specification (EMS); instead, the BASIC
                       .EXE program is forced to swap to disk.

 NOEVENT.OBJ           Removes support for EVENT trapping. This stub
                       file is effective only if linked with the BASIC
                       run-time module (BRT70xxx.EXE); it has no effect
                       when linked into stand-alone executables.

 NOFLTIN.OBJ           Replaces the numeric parsing code with an
                       integer-only version. If you link with
                       NOFLTIN.OBJ, all numbers used by INPUT, READ,
                       and VAL must be legal long integers.

 NOGRAPH.OBJ           Removes all support for graphics statements and
                       nonzero SCREEN modes. NOGRAPH.OBJ is a superset
                       of the following stub files: NOHERC.OBJ,
                       NOOGA.OBJ, NOCGA.OBJ, NOEGA.OBJ, and NOVGA.OBJ.

 NOHERC.OBJ            Removes support for Hercules graphics SCREEN 3.

 NOISAM.OBJ            Removes ISAM support from the BASIC run-time
                       module (BRT70xxx.EXE) and is not useful for
                       stand-alone programs (compiled with BC /O).

 NOLPT.OBJ             Removes line printer support.

 NOOGA.OBJ             Removes support for Olivetti graphics (SCREEN
                       mode 4).

 NOTRNEMR.LIB          Removes support for transcendental operations,
 and NOTRNEMP.LIB      including: SIN, COS, TAN, ATN, LOG, SQR, EXP,
                       ^ (the exponential operator), a CIRCLE statement
                       with a start or stop value, and the DRAW
                       statement with the A or T commands.

 NOVGA.OBJ             Removes support for VGA (Video Graphics Array)
                       graphics (SCREEN modes 11, 12, 13).

 SMALLERR.OBJ          Reduces size of error messages displayed.

 TSCNIOxx.OBJ          Removes certain features from BASIC programs to
                       produce text-only screen I/O. There are four
                       files, depending on string type and operating
                       system mode, as follows:

                          TSCNIONR.OBJ   Near string, real mode (DOS)

                          TSCNIOFR.OBJ   Far string, real mode (DOS)

                          TSCNIONP.OBJ   Near string, OS/2 protected mode

                          TSCNIOFP.OBJ   Far string, OS/2 protected mode

                       The TSCNIOxx stub files remove all support for
                       BASIC graphics modes and graphics statements,
                       except SCREEN 0. They also remove support for
                       special treatment of control characters. The
                       TSCNIOxx stub files cannot be used with any of
                       the other graphics stub files.


 182. BUILDRTM "Unresolved External" Using OVLDOS21.OBJ; Not Allowed

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58410

 The stub file OVLDOS21.OBJ, which is shipped with Microsoft BASIC
 Professional Development System (PDS) Versions 7.00 and 7.10 for
 MS-DOS, can be linked into an .EXE program that uses an extended
 run-time module, but is not allowed to be built into an extended
 run-time module.

 The link error "L2029: Unresolved external" displays a few times if
 you attempt to use the BUILDRTM.EXE utility to place the OVLDOS21.OBJ
 file into an extended run-time module.

 The following sentences need to be added to Pages 539, 611, and 663 of
 the "Microsoft BASIC 7.0: Programmer's Reference" manual (for versions
 7.00 and 7.10):

    Note that you cannot use BUILDRTM to build the OVLDOS21.OBJ stub
    file into an extended run-time module. You can link OVLDOS21.OBJ
    into an .EXE program that uses a normal or extended run-time
    module.

 The following is a correct example to link the OVLDOS21.OBJ stub file
 for use with an extended run-time module:

 LINK import.obj+main.obj+OVLDOS21.obj+(sub1)+(sub2),main.exe,,extrtm.lib;

 The OVLDOS21.OBJ stub file shipped with BASIC PDS Version 7.00 is
 provided to support code overlays under MS-DOS Version 2.10. This stub
 file is not required if overlays are to be used on MS-DOS Versions 3.00
 and later. For more information about overlays, search for a separate
 article by querying on the following words:

    how and use and LINK and overlays and BASIC and PDS and 7.00


 183. LIM 4.0 Expanded Memory Boards/Drivers for BASIC 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-FEB-1990    ArticleIdent: Q58547

 Listed below are some memory boards/drivers that are within the
 specifications of the LIM 4.0 EMS (Lotus-Intel-Microsoft Version 4.0
 Expanded Memory Specification) standard for MS-DOS. One list below is
 for 80386 computers, and another list is for 80286 computers.

 This information is useful for owners of Microsoft BASIC Professional
 Development System (PDS) Version 7.00 under MS-DOS. The following
 features in BASIC PDS 7.00 can take advantage of LIM 4.0 EMS expanded
 memory: ISAM file-handling, the QBX.EXE environment, and certain
 overlaid .EXE programs.

 Below is a list of expanded memory boards and drivers for machines
 with an 80386 processor chip. (The 80386 is also known as the 386):

 Company        Address / Phone              Memory board / Driver
 -------        ---------------              ---------------------

 Above
 Software       [phone]               Above Disk

 Everex         48431 Milmont Dr.            RAM8000 / EMM.SYS
                Fremont, CA 94538
                [phone]
                [phone]

 Intel          185 Berry                    InBoard 386 AT / Driver
                Suite 306
                San Francisco, CA 94107
                [phone]
                [phone]

 Microsoft      One Microsoft Way            HIMEM.SYS
                Redmond, WA 98052
                [phone]
                [phone]

 Orchid         45365 Northport              RamQuest XT / AT
                Loop West
                Fremont, CA 94538
                [phone]

 Qualitas       7101 Wisconsin Ave.          n/a / 386MAX
                Suite 1386
                Bethesda, MD 20814
                [phone]

 Quarterdeck    150 Pico Blvd                n/a / QEMM
                Santa Monica, CA 90405
                [phone]

 Tall Trees     2585 East Bayshore Rd.       JRAM / JEMS
                Palo Alto, CA 94303
                [phone]

 Techmar        6225 Cochran Rd.             MICRORAM 386
                Solan, OH 44139              MICRORAM (PS/2)
                [phone]

 Toshiba        2441 Michelle Dr.            n/a / EMM386.SYS
                Tustin, CA 92680
                [phone]
                [phone]

 Below is a list of expanded memory boards and drivers for machines
 with an 80286 processor chip. (The 80286 also known as the 286):

 Company        Address / Phone              Memory board / Driver
 -------        ---------------              ---------------------

 Above
 Software       [phone]               Above Disk

 AST            16215 Alton Parkway          Rampage Plus XT / AT
                Irvine, CA 92718             SixPak 286 XT / AT
                [phone]

 Intel          185 Berry                    Above Board Plus / EMM
                Suite 306                    Above Board Plus 8 / EMM
                San Francisco, CA 94107
                [phone]
                [phone]

 Microsoft      One Microsoft Way            HIMEM.SYS
                Redmond, WA 98052
                [phone]
                [phone]

 Orchid         45365 Northport              RamQuest XT / AT
                Loop West
                Fremont, CA 94538
                [phone]

 Qualitas       7101 Wisconsin Ave.          n/a / MOVE'EM
                Suite 1386
                Bethesda, MA 20814
                [phone]

 Quarterdeck    150 Pico Blvd                n/a / QEMM(IBM ONLY)
                Santa Monica, CA 90405       n/a / QEMM 50/60
                [phone]

 Tall Trees     2585 East Bayshore Rd.       JRAM / JEMS
                Palo Alto, CA 94303
                [phone]

 Techmar        6225 Cochran Rd.             MICRORAM
                Solan, OH 44139              CAPTAIN 286
                [phone]

 Toshiba        2441 Michelle Dr.            n/a / EMM.SYS
                Tustin, CA 92680
                [phone]
                [phone]

 Note: The MS-DOS interrupts necessary to access LIM 4.0 expanded
 memory are documented in the following book:

    Pages 25-68 of "MS-DOS Extensions: Programmer's Quick Reference,"
    by Ray Duncan (Microsoft Press, 1989).


 184. 7.10 Correction Passing Far Variable-String Array to MASM

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900207-62 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58563

 Page 515 of the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00
 and 7.10) incorrectly shows how to pass a far variable-length-string
 array to assembly. Page 515 states the following:

    To accomplish this, BASIC could call a MASM procedure, passing it
    the address of the first string descriptor in the array:

    DECLARE SUB ChangeArray(S$)
    CALL ChangeArray(A$(1))

 This does not, in fact, pass the address of the string descriptor of
 the first array element, but rather passes the near address of the
 descriptor of a copy of the string. To pass the address of the first
 descriptor, use BYVAL and VARPTR as follows:

    DECLARE SUB ChangeArray(BYVAL offset%)
    CALL ChangeArray(VARPTR(a$(1)))

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Note that all strings in the QBX.EXE environment are always far. When
 making .EXE programs with BC.EXE, you can enable far strings with the
 BC /Fs option.

 The following code example shows the correct way to pass an array of
 BASIC variable-length far strings to assembly language:

    DECLARE SUB ChangeArray(BYVAL offset%)
    DIM a$(1 TO 10)
    FOR i% = 1 TO 10
      a$(i%) = STRING$(i%, ASC("A") + i% - 1)
      PRINT a$(i%)
    NEXT
    CALL ChangeArray(VARPTR(a$(1)))
    FOR i% = 1 TO 10
       PRINT a$(i%)
    NEXT
    END

 To use the above program, the following assembly code (taken from
 Pages 516-517 of "Microsoft BASIC 7.0: Programmer's Guide") should be
 assembled and linked with the above program, or linked into a Quick
 library (.QLB) for use in the QBX.EXE environment:

       .model medium,basic
       .data
 array       dw 100 dup(0)
       .code
 ; arraydescriptor below is the pointer to the array:
 changearray proc uses si di, arraydescriptor: near ptr
       extrn stringassign:proc
       mov   cx, 10
       mov   si, arraydescriptor
       lea   di, array
 transferin: push cx

       push  ds
       push  si
       xor   ax,ax
       push  ax
       push  ds
       push  di
       mov   ax, 10
       push  ax
       call  stringassign
       pop   cx
       add   si, 4
       add   di,10
       loop  transferin

       mov   cx,100
       lea   bx, array
 more: cmp byte ptr[bx], 0
       jz    skip
       add byte ptr[bx], 32
 skip: inc   bx
       loop  more

       mov   cx, 10
       lea   si, array + 90
 transferout:push   cx

       push  ds
       push  si
       push  cx
       push  ds
       push  di
       xor   ax,ax
       push  ax
       call  stringassign
       pop   cx
       sub   si, 10
       add   di, 4
       loop  transferout

       ret

 changearray endp
       end

 Use the following Microsoft Macro Assembler command line to assemble
 the above code:

    MASM CHGARRAY.ASM ;

 To create a Quick library from CHGARRAY.OBJ, use the following LINK
 line:

    LINK /Q CHGARRAY,,,QBXQLB;

 To use this Quick library, enter QBX.EXE with the following statement:

    QBX /L CHGARRAY

 The output for the above code example is as follows:

    A
    BB
    CCC
    DDDD
    EEEEE
    FFFFFF
    GGGGGGG
    HHHHHHHH
    IIIIIIIII
    JJJJJJJJJJ
    jjjjjjjjjj
    iiiiiiiii
    hhhhhhhh
    ggggggg
    ffffff
    eeeee
    dddd
    ccc
    bb
    a


 185. How to Use Customize Menu Command of Utility Menu in QBX.EXE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900118-14
 Last Modified: 26-FEB-1990    ArticleIdent: Q58568

 This article explains how to use the Customize Menu command in the
 Utility menu in the QBX.EXE (QuickBASIC Extended) environment. The
 Customize Menu command allows you to add your own DOS commands
 (internal, external, or batch files) to the Utility menu. This
 provides easy access to these commands rather than having to shell out
 to DOS and type them in at the command line prompt.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 The following is a brief summary of the features of the Customize Menu
 dialog box:

 Applications List - A list of the DOS commands already included in the
                     Utility menu.

 Add button        - Adds a new command to the Applications List. For
                     details, see farther below.

 Edit button       - Edits the information associated with a command
                     already in the Applications List.

 Delete button     - Deletes a command from the Applications List.

 To Begin button   - Puts the currently selected command at the top of
                     the Applications List.

 To End button     - Puts the currently selected command at the bottom
                     of the Applications List.

 Save button       - Saves all the changes made to the Applications
                     List and closes the Customize Menu dialog box.

 Cancel button     - Cancels all the changes made to the Applications
                     List and closes the Customize Menu dialog box.

 Help button       - Provides online help for using the Customize
                     Menu command.

 The Customize Menu command in the Utility menu is a handy way to
 execute DOS-level commands from inside the QBX.EXE environment. It
 allows you to execute internal commands, external commands, and batch
 files by selecting a menu item with the keyboard or mouse. There is no
 need to shell out to DOS. When the command or batch file is finished,
 you can be prompted to "press any key to continue" or you can specify
 for QBX to reappear automatically.

 Adding, deleting, editing, and ordering commands in the Utility menu
 is very simple, and the discussion above should be adequate enough for
 every feature except the Add button, which is discussed below in
 detail.

 Add Button
 ----------

 When selected, the Add button brings up another dialog box containing
 edit fields that are used to enter information about the command to be
 added. The following is a list of the edit fields and buttons of this
 dialog box and information about each one:

 Menu Text (20 chars) - Enter the name you want displayed in the
                        Utility menu. This name will also appear in the
                        Applications List. This may or may not be the
                        name of the actual command.

 Pathname             - Enter the name of the command if it is internal
                        or the full path to the file if it is external
                        or a batch file. For example, "DIR" or
                        "C:\CHKDSK".

 Arguments            - Enter the arguments passed to the command. For
                        example, this may be "a:" if the command is
                        "FORMAT" or "/w" if the command is "DIR", etc.

 Initial Directory    - Enter the name of the directory you want the
                        command to operate in.

 Prompt Before        - Select this option if you want to be prompted
 Returning              with "press any key to continue" before control
                        is returned to QBX.

 Accelerator Key      - Select the None button if you do not want to
                        use an accelerator key or select the ALT+F
                        button if you do. The values that may be
                        entered into the box following ALT+F range from
                        2 to 10, specifying the function keys F2
                        through F10.

 OK button            - Select this button when you are satisfied with
                        the information in the dialog box. The Add
                        dialog box closes and the name of the new
                        command is added to the Applications List.
                        However, none of the changes to the Utility
                        menu are saved unless the Save button is
                        selected.

 Cancel button        - This button cancels the information entered in
                        the edit fields and closes the Add dialog box.

 Help button          - This button displays more online help.

 Below is a step-by-step example illustrating how to use the Customize
 Menu command. This example shows how to add the DOS command "DIR" to
 the Utility menu. This DIR command operates on the current directory
 and uses the "/w" parameter to display the listing in many columns
 rather than one. Also, an accelerator key (ALT+F5) is linked to the
 command for easy keyboard access and the user is prompted to "press
 any key to continue" after the DIR command is finished.

  1. Choose Customize Menu from the Utility menu. This can be done by
     holding down the ALT and U keys together, followed by the C key
     alone.

  2. The Customize Menu dialog box appears. Press the TAB key once to
     highlight the Add button and then press ENTER.

  3. Another dialog box appears, containing edit fields used to enter
     information about the command. The cursor is placed in the top
     edit field, "Menu Text (20 chars)." Type in "DIR" for this field
     and press TAB.

  4. The cursor advances to the next edit field, "Pathname". Since DIR
     is an internal command, it has no path, so you only need to enter
     the name of the command by itself, "DIR". Do this and press TAB
     again.

  5. The next edit field is "Arguments". A common argument to pass to
     the DIR command is "/w".  The "/w" argument (called a switch)
     breaks the directory listing into columns rather than listing them
     in one long column, which frequently scrolls off the screen. Type
     "/w" and press TAB.

  6. For the "Initial Directory" edit field, you can enter any valid
     pathname. Leaving this field blank causes the command to use the
     current pathname. Press TAB to leave it blank.

  7. The cursor is now placed inside the button titled "Prompt Before
     Returning." You can press SPACEBAR to toggle this button on or
     off. Toggle it on and press TAB.

  8. The cursor advances to the button titled "None". By default it is
     also selected, specifying that no accelerator key is to be defined
     for accessing the DOS command from the Utility menu. To enter an
     accelerator key, press the RIGHT ARROW. This toggles the None
     button off and the ALT+F button on. Press TAB to advance the
     cursor to the edit field following the ALT+F button and enter a 5
     (specifying F5). Press ENTER to continue.

  9. The current dialog box closes and the main Customize Menu dialog
     box reappears. You will see that "DIR" has been added to the
     Applications List. Press TAB until the Save button is highlighted,
     then press ENTER.

 10. The Customize Menu dialog box closes. You can now choose the DIR
     command from the Utility menu either by pulling down the menu and
     then choosing DIR or you can use the accelerator key sequence,
     ALT+F5. After displaying the contents of the current directory, you
     will be prompted with "press any key to continue" before control is
     returned to QBX.


 186. Token Ring Network Driver May Conflict with BASIC 7.00 Setup

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900207-50 B_BasicCom
 Last Modified: 26-FEB-1990    ArticleIdent: Q58639

 A customer reported that when running the SETUP.EXE installation
 program for Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS and OS/2, problems may occur if a Token Ring
 network device driver Version 1.10 has been loaded from the CONFIG.SYS
 file during a system boot. Upon removing the device driver and
 rebooting the system, everything seems to install and build correctly.

 The customer reported that the source files on the distribution disks
 were overwritten with the current system date and weren't properly
 unpacked onto the hard disk, and subsequent library and toolbox builds
 crashed because of the corrupt files used. Microsoft has not confirmed
 this information.


 187. LOCAL (Procedure) ERROR Handling Introduced in BASIC PDS 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 26-FEB-1990    ArticleIdent: Q58606

 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS and MS OS/2 offers structured error trapping and handling that
 make error handling much more flexible than in earlier versions of
 BASIC.

 In previous versions of BASIC, error handling routines existed at the
 module level. When a handler was turned on with the ON ERROR GOTO
 statement, it was active for all procedures within that module.

 With Microsoft BASIC PDS 7.00, you can now create both module-level
 and procedure-level error handlers. BASIC PDS 7.00 introduces the ON
 LOCAL ERROR GOTO statement to trap procedure-level errors. A given
 type of error can invoke different local error-handling routines,
 depending on which procedure is running. For example, you may want to
 invoke different error-handling routines for ERR code 54, "Bad File
 Mode," because the error has different meaning for different file
 operations.

 For more information, please refer to Chapter 8, "Error Handling," in
 the "Microsoft BASIC 7.0: Programmer's Guide," or see the ON ERROR
 statement "Details" in the Microsoft Advisor online Help system in the
 QBX.EXE environment.

 Error handling is the process of intercepting and dealing with errors
 that would otherwise stop your program at run time. BASIC PDS 7.00
 provides an ON [LOCAL] ERROR GOTO statement to enable the trapping of
 errors and takes the appropriate action so the program can continue
 executing. The ON ERROR GOTO statement jumps to a labeled
 error-handling  routine. The ON [LOCAL] ERROR GOTO 0 statement can be
 used to disable an error-handling routine.

 Procedure-Level Versus Module-Level Error-Handling
 --------------------------------------------------

 For many applications, procedure-level error handling is preferred
 because procedures tend to be organized by task (display, printing,
 general I/O, etc.), and errors are also task-related. Therefore,
 program organization can be simpler and more straightforward when
 related tasks and their error handlers are grouped together.

 The following is the syntax for ERROR handling:

    ON [LOCAL] ERROR { GOTO line | RESUME NEXT | GOTO 0 }

    LOCAL: The LOCAL keyword indicates an error-handling routine that
    is "local" to the procedure within which the error-handling routine
    is located. A local error-handling routine:

    -- Overrides any enabled module-level error-handling routines.

    -- Is enabled only while the procedure within which it is
       located is executing.

    GOTO <line>: Enables the error-handling routine that starts at
    <line>. Thereafter, if a run-time error occurs, program control
    branches to <line> (label or line number). The specified <line> is
    in either module-level code or in the same procedure (if the LOCAL
    keyword is used). If <line> is not found in either place, BASIC
    generates a "Label not defined" compile-time error.

    Exiting an Error-Handling Routine
    ---------------------------------

    RESUME NEXT: Specifies that when a run-time error occurs control
    goes to the statement after the statement where the error occurred;
    the ERR function can then be used to obtain the run-time error
    code.

    RESUME[0]: Returns to the statement that caused the error or the
    last call out of the error-handling procedure or module.

    RESUME <line>: Returns to the label or line number specified by
    <line>.

    ERROR ERR: Initiates a search of the invocation path for the next
    higher-level error-handling routine, if any. If no higher-level
    error handler exists, the program stops with the error reported by
    the ERR function.

    GOTO 0: Disables any enabled module-level error-handling routine
    within the current module, or disables any enabled error handler
    within the current procedure (if used together with the LOCAL
    keyword).

 Below is an example of how to use procedure-level (local) error
 handling and module-level error handling within the same module.

 This program consists of one module that contains a main program and a
 subprogram within the same module. At the module-level code, the ON
 ERROR GOTO is placed at the top of the program so that that there is a
 way to handle errors that occur in the module-level code. The
 subprogram "test" has its own local error handler. Two errors occur in
 this program; one in the module-level code (ERROR 2 "Syntax error"),
 and another in the subprogram (Error 51 "Division by zero"). Each
 error is handled independently by each error-handler routine.

 Code Example
 ------------

 'MODULE LEVEL CODE:
 DECLARE SUB test ()
 CLS
 'Enable module-level error handler:
 ON ERROR GOTO ModuleHandler
 PRINT "We are at the module-level code"

 'Call a SUBprogram procedure within the same module:
 CALL test
 PRINT "We are back at the module level"
 'Simulate an error ("Syntax Error") in the module-level code:
 ERROR 2
 PRINT "this is the end"
 END

 'Module-Level Error Handler:
 ModuleHandler:

 PRINT "You have encountered an error at the module-level code,"
 PRINT "and the program has trapped error number:"; ERR
 PRINT "Now resuming to next line..."
 'RESUME NEXT from a module-level error handler returns to the next
 'statement immediately following the one that caused the error
 '(or to the statement following the CALL to a procedure in which
 'an untrapped error occurred):
 RESUME NEXT

 'This SUB is called by the module-level code:
 SUB test
 PRINT "We are now at the procedure (local) level code."
 'Enable the local-error handler:
 ON LOCAL ERROR GOTO LocalHandler
 a! = 10
 b! = 0
 'A "Division by zero" error occurs when the following line executes:
 c! = a! / b!
 PRINT "We resumed past the statement with the division by zero error."
 PRINT "c! ="; c!

 'Place the EXIT SUB statement before the error-handling routine to
 'avoid incorrectly passing control to the local error handler:
 EXIT SUB

 LocalHandler:
 PRINT "You have encountered an error at the procedure-level code,"
 PRINT "and the program has trapped error number:"; ERR
 SELECT CASE ERR
    CASE 11
    PRINT "Error Message: Attempted to divide by zero"
 END SELECT
 PRINT "Now resuming to next line..."
 RESUME NEXT

 END SUB


 188. Bad EXE Result Assigning n Between 2 Statements Using Same n

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900207-44 buglist7.00 fixlist7.10
 Last Modified:  6-SEP-1990    ArticleIdent: Q58608

 Assigning a SINGLE-precision variable in a statement between two other
 statements that use that same variable can produce incorrect results
 in an .EXE compiled with BC.EXE in Microsoft BASIC Professional
 Development System (PDS) version 7.00 for MS-DOS and OS/2. This
 problem does not occur in the QBX.EXE (QuickBASIC Extended)
 environment. This error does not occur with the INTEGER, LONG, DOUBLE,
 or CURRENCY data types.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00. This problem was corrected in version 7.10.

 To work around this problem in 7.00, do ONE of the following:

 1. Use the BC /X compiler option.

 2. Make an assignment to a temporary variable before the second or
    third statement.

 3. Place a line number or label on the second or third statement.

 4. Place a DEFxxx statement in the program (such as DEFDBL A-Z), or
    explicitly DIMension the variable to be some data type other than
    SINGLE precision.

 This problem does NOT occur in Microsoft BASIC Compiler version 6.00
 or 6.00b for MS-DOS and OS/2, or in Microsoft QuickBASIC version 4.00,
 4.00b, or 4.50 for MS-DOS.

 The following code example illustrates the problem and contains
 workarounds #2 and #3 in comments:

    init = p
    'temp = init      'Uncomment this line for workaround #2
    'label:           'Uncomment this line for workaround #3
    p = 200
    wrong = p
    PRINT wrong, p    'In EXE compiled without /X, this prints 0 and 200


 189. "7.0: Programmer's Guide" Error Handling Example Correction

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900207-56 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58640

 The following are two corrections to the error handling example
 program on Page 291 of the "Microsoft BASIC 7.0: Programmer's Guide"
 (for 7.00 and 7.10):

 1. In Module #1, the line "ON ERROR GOTO Handler" should be removed
    because there is no line label "Handler" in the first module.

 2. In Module #2, the line "DEFINT A-Z" should be added before the line
    "Handler:". Since the default type for variables is SINGLE,
    variables A and B would be incorrectly typed as SINGLE instead of
    as INTEGER if the DEFINT A-Z line is not inserted.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 190. BASIC 7.00 Can Assign an Array to an Array If in a TYPE

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900131-59 B_QuickBas
 Last Modified: 12-NOV-1990    ArticleIdent: Q58733

 Some languages, such as Pascal, allow you to assign one array directly
 to another, which copies all the elements from one array to another.
 Microsoft BASIC cannot do this, except in Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 where you can now
 directly assign one static array to another by defining the array in a
 user-defined-TYPE variable and then assigning one variable of this
 TYPE to another.

 Using a variable of a TYPE that contains an array, you can also write
 an entire array to a file using a single PUT# statement.

 Note that in Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50 for
 MS-DOS, in Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS
 and MS OS/2, and in Microsoft BASIC PDS versions 7.00 and 7.10 for
 MS-DOS and MS OS/2, you can directly assign variables of a
 user-defined TYPE directly to one another if they are of the same
 TYPE. (LSET can be used for assignment if the record variables differ
 in TYPE.) The TYPEd variables are assigned in one simple statement,
 and each and every element of the user-defined TYPE is automatically
 copied.

 Microsoft BASIC PDS version 7.00 for MS-DOS and MS OS/2 introduces
 support for static arrays in user-defined TYPEs. In BASIC PDS 7.00 and
 7.10, you can directly assign one static array to another by defining
 the array in a user-defined-TYPE variable and then assigning one
 variable of this TYPE to another, as shown in Example 1.

 You can also write a whole array at once into a disk file, as shown in
 Example 2.

 Code Example 1
 --------------

 The following program can be used in BASIC PDS 7.00 and 7.10 to
 demonstrate the assignment of the contents of one static array to
 another. (Note that dynamic arrays cannot be placed in user-defined
 TYPEs.)

    TYPE rec1
      array1(20) AS INTEGER
    END TYPE
    DIM var1 AS rec1, var2 AS rec1
    CLS
    FOR i = 1 TO 20      ' Fill the array in var1:
      var1.array1(i) = i
    NEXT
      var2 = var1          ' Make the assignment.
    FOR i = 1 TO 20      ' Confirm that the array was copied to var2:
      PRINT var2.array1(i)
    NEXT
    END

 Code Example 2
 --------------

 The following example, compiled in BASIC PDS 7.00 or 7.10, shows how
 to write a whole array to disk at once, using just one PUT# statement:

    TYPE rec1
      array1(20) AS INTEGER
    END TYPE
    DIM var1 AS rec1, var2 AS rec1
    CLS
    FOR i = 1 TO 20      ' Fill the array in var1:
      var1.array1(i) = i
    NEXT

    OPEN "test.dat" FOR RANDOM AS #1
    PUT #1, , var1         ' write whole array to disk all at once.
    CLOSE

    OPEN "test.dat" FOR RANDOM AS #1
    GET #1, , var2      ' Reads array all at once into var2.
    FOR i = 1 TO 20     ' Print the contents of array var2:
      PRINT var2.array1(i);
    NEXT
    CLOSE


 191. Quick Libraries in BASIC 7.00 Don't Use Expanded Memory

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900207-70
 Last Modified: 27-JUL-1990    ArticleIdent: Q58658

 When using a Quick library in QBX.EXE, the programming environment
 included with Microsoft BASIC Professional Development System (PDS)
 version 7.00 or 7.10, the Quick library is always placed in
 conventional memory. If you have expanded memory (as defined in the
 LIM 4.0 EMS), QBX.EXE utilizes this expanded memory for loaded source
 code segments that are smaller than 16K; however, Quick libraries are
 always placed in conventional memory.

 Microsoft BASIC PDS 7.00 or 7.10 is the only Microsoft BASIC product
 that supports expanded memory, so this is not a consideration in
 earlier versions of Microsoft BASIC Compiler or QuickBASIC.

 Note: (LIM 4.0 EMS is an acronym for the Lotus/Intel/Microsoft version
 4.0 Expanded Memory Specification for MS-DOS.)


 192. TIMEVALUE# Function Documentation Correction in BASIC 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900208-180 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58660

 The following reference to the TIMEVALUE# function on Page 486 of the
 "Microsoft BASIC 7.0: Language Reference" manual (for 7.00 and 7.10)
 is incorrect. The second sentence in the remarks section states the
 following:

    Time can be entered as "2:24PM" or "14:24".

 This sentence should indicate a space between "2:24" and "PM" and read
 as follows:

    Time can be entered as "2:24 PM" or "14:24".

 The TIMEVALUE function is a routine in the "add-on library" included
 with Microsoft BASIC Professional Development System versions 7.00 and
 7.10 for MS-DOS and MS OS/2.


 193. ButtonOpen Incorrectly Handles Button in Resizable Window

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900202-66 buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q58673

 The ButtonOpen SUBprogram in the User Interface (UI) Toolbox (in
 WINDOW.BAS) incorrectly handles buttons in resizable windows and
 buttons with invalid states. When trying to create a button with an
 invalid state (such as state 3 for window type 2), the following
 message displays and the program stops:

    Cannot open button on window that can be re-sized.

 When you attempt to place a button in a resizable window, the above
 message is not displayed, but no button is created. In this case, the
 ButtonOpen SUB falls through without doing anything.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS. The necessary
 corrections to the WINDOW.BAS source code are listed below.

 For additional corrections to source code in the User Interface
 Toolbox, search in this Knowledge Base for the following words:

    User and Interface and Toolbox and buglist7.00

 The section of code that must be modified is at the end of the
 ButtonOpen SUB from WINDOW.BAS (Note: The underscores are used for
 display purposes only):

   IF (resize AND buttonType >= 6) OR NOT resize THEN
 ...*** not all code displayed
     IF (buttonType = 1 AND state >= 1 AND state <= 3)_
     OR (buttonType >= 2 AND buttonType <= 3 AND state >= 1 AND state <= 2)_
     OR (buttonType >= 4 AND buttonType <= 7) THEN
 ...*** not all code displayed
     ELSE
         PRINT "Cannot open button on window that can be re-sized!"
         END
     END IF
   END IF
 END SUB

 The problem with the existing code is that the ELSE clause matches the
 wrong level of the IF nesting. To modify the code to display correct
 messages, change the above code to the following:

   IF (resize AND buttonType >= 6) OR NOT resize THEN
   ...*** not all code displayed
     IF (buttonType = 1 AND state >= 1 AND state <= 3)_
     OR (buttonType >= 2 AND buttonType <= 3 AND state >= 1 AND state <= 2)_
     OR (buttonType >= 4 AND buttonType <= 7) THEN
     ...*** not all code displayed

 'The following lines have changed.
     ELSE
       PRINT "Illegal state ("; state; ") or button type ("; buttonType; ")"
       END
     END IF
   ELSE
     PRINT "Cannot open button on window that can be re-sized!"
     END
   END IF
 END SUB

 The following code examples demonstrate the two problems with the
 unmodified ButtonOpen SUB:

 Example 1
 ---------

 This first example attempts to open a button, type 2 (check box), with
 an invalid state, 3. This program displays the following incorrect
 message using the unmodified code shipped with BASIC PDS 7.00 or 7.10:

    Cannot open button on window that can be re-sized.

 After making the specified modifications to WINDOW.BAS, Example 1
 displays the following correct message:

    Illegal state ( 3 ) or button type ( 2 )

 REM $INCLUDE: 'General.bi'
 REM $INCLUDE: 'Mouse.bi'
 REM $INCLUDE: 'Menu.bi'
 REM $INCLUDE: 'Window.bi'
 COMMON SHARED /uitools/ GloMenu           AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()        AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()         AS MenuItemType
 COMMON SHARED /uitools/ GloWindow()       AS windowType
 COMMON SHARED /uitools/ GloButton()       AS buttonType
 COMMON SHARED /uitools/ GloEdit()         AS EditFieldType
 COMMON SHARED /uitools/ GloStorage        AS WindowStorageType
 COMMON SHARED /uitools/ GloWindowStack()  AS INTEGER
 COMMON SHARED /uitools/ GloBuffer$()
 '$DYNAMIC
 DIM GloWindow(MAXWINDOW) AS windowType
 DIM GloWindowStack(MAXWINDOW) AS INTEGER
 DIM GloButton(MAXBUTTON) AS buttonType
 DIM GloEdit(MAXBUTTON) AS EditFieldType
 DIM GloBuffer$(MAXWINDOW + 1, 2)
 CLS
 WindowInit
 Resize% = 0               'Not resizable
 WindowOpen 1, 3, 3, 24, 24, 7, 0, 7, 0, 7, 7, 7, Resize%, 0, 1, "test"
 buttonType% = 2              'Check box (valid states=1 and 2)
 state% = 3                   '3 is invalid state for check box
 CALL ButtonOpen(1, state%, "Foo", 10, 10, 20, 20, buttonType%)

 Example 2
 ---------

 The following example attempts to open a button in a resizable window.
 This program executes without messages using the unmodified code
 shipped with BASIC PDS 7.00 or 7.10, but no button is created.

 After making the specified modifications to WINDOW.BAS, Example 2
 displays the following correct message:

    Cannot open button on window that can be re-sized.

 REM $INCLUDE: 'General.bi'
 REM $INCLUDE: 'Mouse.bi'
 REM $INCLUDE: 'Menu.bi'
 REM $INCLUDE: 'Window.bi'
 COMMON SHARED /uitools/ GloMenu           AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()        AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()         AS MenuItemType
 COMMON SHARED /uitools/ GloWindow()       AS windowType
 COMMON SHARED /uitools/ GloButton()       AS buttonType
 COMMON SHARED /uitools/ GloEdit()         AS EditFieldType
 COMMON SHARED /uitools/ GloStorage        AS WindowStorageType
 COMMON SHARED /uitools/ GloWindowStack()  AS INTEGER
 COMMON SHARED /uitools/ GloBuffer$()
 '$DYNAMIC
 DIM GloWindow(MAXWINDOW) AS windowType
 DIM GloWindowStack(MAXWINDOW) AS INTEGER
 DIM GloButton(MAXBUTTON) AS buttonType
 DIM GloEdit(MAXBUTTON) AS EditFieldType
 DIM GloBuffer$(MAXWINDOW + 1, 2)
 CLS
 WindowInit
 Resize% = TRUE                 'Resizable
 WindowOpen 1, 3, 3, 24, 24, 7, 0, 7, 0, 7, 7, 7, Resize%, 0, 1, "test"
 buttonType% = 2
 state% = 1                     'Valid state.
 CALL ButtonOpen(1, state%, "Foo", 10, 10, 20, 20, buttonType%)


 194. MenuEvent$ Should Be MenuEvent, Page 495 BASIC 7.0 Reference

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900212-51 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58676

 On Page 495 of the "Microsoft BASIC Version 7.0: Language Reference"
 manual (for 7.00 and 7.10), the User Interface (UI) Toolbox routine
 "MenuEvent" is incorrectly referred to as "MenuEvent$". This is a
 documentation error, since the correct name is "MenuEvent".

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 MenuEvent is a SUB in the toolbox file MENU.BAS and is used to poll
 for any menu events activated by the mouse or keyboard.


 195. Limits for Nesting Arrays in TYPE Statements in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER |
 Last Modified: 28-FEB-1990    ArticleIdent: Q58790

 In the QBX.EXE (QuickBASIC Extended) environment for MS-DOS, you can
 have up to 16 nested-array TYPE definitions (see Code Example 1,
 below). If you exceed 16 nestings, you get a "Subscript out of range"
 error.

 In the QBX.EXE environment, nonarray nested TYPEs (see Code Example 2,
 below) can be nested until you run out of memory.

 As for the BC.EXE compiler, the limit on the number of TYPE statements
 for one module is 240 whether they are nested or nonnested TYPE
 definitions. If the number of TYPEs of all kinds exceeds 240, the
 BC.EXE compiler gives an error of "Too Many Type statements".

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 (This information does not apply to versions of Microsoft BASIC
 earlier than 7.00 because they do not support arrays in user-defined
 TYPEs.)

 Note that only static (nondynamic) arrays can be placed in TYPE
 statements in BASIC PDS 7.00.

 Code Example 1 (Arrays of Nested TYPEs)
 ---------------------------------------

 OPTION BASE 1

 TYPE test1
    a AS STRING * 1
 END TYPE

 TYPE test2
    b2(1) AS test1        'Nest it as the first TYPE
 END TYPE
 .
 .
 .
 TYPE test15
    b15(1) AS test14
 END TYPE

 TYPE test16
    b16(1) AS test15
 END TYPE

 DIM temp(1000) AS test16

 Code Example 2 (Nonarray Variables of Nested TYPEs)
 ---------------------------------------------------

 TYPE test1
    a AS INTEGER
 END TYPE

 TYPE test2
    b2 AS test1
 END TYPE

 TYPE test3
    b3 AS test2
 END TYPE
 .
 .
 .
 TYPE test237
    b237 AS test236
 END TYPE

 TYPE test238
    b238 AS test237
 END TYPE

 TYPE new
    none AS INTEGER    'Put in to see if the TYPEs had to be nested
 END TYPE

 TYPE new2
    none2 AS INTEGER
 END TYPE

 DIM temp(100) as test238


 196. DATEVALUE# Function in BASIC 7.00 Uses MM-DD-YY, Not DD-MM-YY

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58791

 The DATEVALUE# function that comes in the Date/Time Library of
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 does not interpret dates in the form of "dd/mm/yy" or "dd-mm-yy,"
 where the day number precedes the month number (dd stands for day, mm
 stands for month, and yy stands for year). Instead, the DATEVALUE#
 function interprets dates in the form of "mm/dd/yy" or "mm-dd-yy,"
 where the month number precedes the day number. For example, you get
 "Illegal Function Call" (error 5) when passing "30/12/88" or
 "30-12-88" to the DATEVALUE# function.

 Both Page 427 of the "Microsoft BASIC 7.0: Language Reference" manual
 (for 7.00 and 7.10) and also the "HELP: DateValue# Function Details"
 screen in the Microsoft Advisor online Help system in QBX.EXE
 incorrectly state that "30/12/88" is one of the acceptable formats.
 This should be changed to say that "12/30/88" ("mm/dd/yy") format is
 accepted by the DATEVALUE# function.

 Also, the "HELP: DateValue# Function Details" screen in the Microsoft
 Advisor online Help system in QBX.EXE incorrectly states: "To use
 DateValue# in the QBX environment, use the FINANCER.QLB Quick
 library." This should be changed to say the DTFMTER.QLB Quick library.
 (Page 427 of the reference manual correctly says to use DTFMTER.QLB in
 QBX.)

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 If you want to give the date before the month, you can use the name of
 the month instead of the numeric representation of the month.

 The following are not accepted ("Illegal Function Call"):

    B# = DateValue# ("30-12-88")
    B# = DateValue# ("30/12/88")

 The following are accepted (the workaround is to use the spelled
 instead of the numeric month):

    B# = DateValue# ("30-Dec-88")
    B# = DateValue# ("30/Dec/88")

 The following are accepted (but month, day, and year must be in
 order):

    B# = DateValue# ("12-30-88")
    B# = DateValue# ("12/30/88")
    B# = DateValue# ("December 30, 1988")

 DateValue# accepts dates between January 1, 1753, and December 31,
 2078.

 Complete Code Example
 ---------------------

 You can run this program with QBX /L DTFMTER.QLB, or link with the
 appropriate DTFMTxx.LIB file if making an .EXE program:

    REM $INCLUDE: 'DATIM.BI'
    d$ = "30-Dec-88"
    PRINT DateValue#(d$)   ' Prints 32507
    d$ = "12/30/88"
    PRINT DateValue#(d$)   ' Prints 32507


 197. PCOPY Can Fail from Page 0 in 43-Line Mode in SCREEN 0

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900214-56 buglist7.00 fixlist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q58792

 In Microsoft BASIC Professional Development System (PDS) version 7.00,
 when in 43-line mode in SCREEN mode 0, using a PCOPY statement to copy
 screen page 0 to some other screen page may fail. If screen page 0 is
 both the visual and active page during the PCOPY statement, it copies
 corrupt information to the other screen page. This problem occurs only
 in SCREEN mode 0 when in 43-line mode and only when PCOPYing from page
 0. It does not occur when PCOPYing from another page to page 0.
 Temporarily setting the active and/or visual page to a screen page
 other than 0 during the PCOPY corrects the problem.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00 for MS-DOS. This problem was corrected in BASIC PDS
 version 7.10.

 The following program demonstrates the problem. A string of 3440 X's
 that fills the screen is displayed, then copied from page 0 to page 1.
 The visual page is then set to page 1 to view the information copied
 from page 0. What appears in page 1 is only a few lines of text,
 either at the top or middle of the screen. Setting either the visual
 and/or active screen page to any page other than page 0 corrects the
 problem.

    WIDTH 80, 43
    PRINT STRING$(3440, "X");
    'SCREEN , ,0, 1    'Uncommenting this line corrects the problem
    PCOPY 0, 1
    LOCATE 10, 10: PRINT " HIT ANY KEY TO SWITCH PAGES "
    SLEEP
    SCREEN , ,0, 1
    END


 198. "Unresolved External" Using Wrong Linker with BASIC 7.00, 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900130-159 S_LINK
 Last Modified:  4-SEP-1990    ArticleIdent: Q58815

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS and MS OS/2 are shipped with Microsoft
 Segmented-Executable Linker versions 5.05 and 5.10 respectively.
 Because of the newer technology used in these linkers, it is more
 important than ever to use only the linker that comes with the product
 (or a later version of the Segmented-Executable Linker) to link BASIC
 PDS programs.

 Linking BASIC PDS modules with a version of LINK.EXE earlier than
 5.05, such as the Microsoft 8086-Object Linker, can result in "L2029:
 Unresolved external" errors, such as the following:

      B$IsamSetmemDown in file(s):
    C:\BC7\LIB\BCL70ENR.LIB(..\rt\isam.asm)

      B$IsamSetmemBack in file(s):
    C:\BC7\LIB\BCL70ENR.LIB(..\rt\isam.asm)

      B$RestoreEmsState in file(s):
    C:\BC7\LIB\BCL70ENR.LIB(..\rt\isam.asm)

      B$DoIsamTerm in file(s):
    C:\BC7\LIB\BCL70ENR.LIB(..\rt\isam.asm)

      B$FIsamInited in file(s):
    C:\BC7\LIB\BCL70ENR.LIB(..\rt\isam.asm)

 These errors should not occur when linking BASIC PDS modules with
 Microsoft Segmented-Executable Linker versions 5.05 or later.

 A very common mistake is running the Linker from a directory that does
 not contain LINK.EXE and thus invoking an older linker version found
 first in your DOS PATH. You must be sure to have the correct linker
 found in your DOS PATH or in the current directory.


 199. BASIC PDS 7.10 Does Not Support ILINK.EXE Incremental Linker

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900212-106 B_BasicCom docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58816

 Page 593 of the "Microsoft BASIC 7.0: Programmer's Guide" (for 7.00
 and 7.10) incorrectly states that you can use the LINKer switch /INC,
 which sets up your .EXE file for later use with the Microsoft
 Incremental Linker (ILINK.EXE). Microsoft BASIC Professional
 Development System (PDS) Version 7.00 or 7.10 does not support the
 Incremental Linker. This is a documentation error, and the section
 "Preparing for Incremental Linking (/INC)" should be removed from Page
 593.

 ILINK.EXE is also documented on Pages 261-269 (Chapter 14) of the
 "Microsoft CodeView 2.3 and Utilities User's Guide" provided with
 Microsoft BASIC PDS 7.00 and 7.10, but ILINK.EXE is NOT shipped with
 or supported by BASIC PDS 7.00 or 7.10. The reference to BASIC on Page
 263 should be removed.

 Also, the /INC option needs to be added to the table of "Invalid LINK
 Options" on Page 590 of the "Microsoft BASIC 7.0: Programmer's Guide"
 for 7.00 and 7.10.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 ILINK.EXE is shipped with and supported by Microsoft C Version 5.10,
 QuickC Versions 2.00 and 2.01, and Microsoft Macro Assembler Version
 5.10.


 200. BASIC 7.00 "Error Loading Run-Time Module: Incompatible"

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900201-67
 Last Modified: 20-SEP-1990    ArticleIdent: Q58817

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 maintain a date and time stamp for each of their run-time
 modules (BRT70xxx.EXE and BRT71xxx.EXE). This time stamp is inherited
 by the compiled BASIC PDS program linked with a given BASIC PDS
 run-time module. (This information does NOT apply if you compile with
 the BC /O stand-alone option.)

 The result of this inheritance is that the BASIC executable .EXE
 program does not run with a run-time module other than the one it was
 linked with. Attempting to use a BASIC PDS 7.00 or 7.10 run-time
 module other than the one that the .EXE program was linked with
 results in the following error message:

    Error loading run-time module <runtime name>.EXE: Incompatible
    run-time module.

 The time stamp association between BASIC PDS 7.00/7.10 run-time
 modules and executable programs helps ensure that the run-time module
 used by the program actually contains the routines the BASIC
 executable program expects to be able to call.

 For example, assume that you have created the BASIC run-time module
 BRT70ENR.EXE and the run-time library BRT70ENR.LIB during setup, and
 you specify that you do not want to include VGA graphics support
 (which removes the VGA graphics routines by linking the NOVGA.OBJ stub
 file into your run-time module). If you were allowed to execute a
 program that was compiled by another person using a different
 BRT70ENR.LIB run-time library, and that program used VGA graphics
 routines, that program would try to call the graphics routines it
 expected to find at certain locations in the BASIC run-time
 BRT70ENR.EXE. Because the VGA graphics routines will not be present in
 your BRT70ENR.EXE run-time, the code at that location is not going to
 be the expected VGA routine, and the results of such a call are
 unpredictable.


 201. Microsoft Editor Cannot Use QuickBASIC Extended Help Files

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900209-75 s_editor S_PWB
 Last Modified:  6-SEP-1990    ArticleIdent: Q58819

 Microsoft Editor (M.EXE and MEP.EXE) version 1.20, which is included
 with Microsoft BASIC Professional Development System (PDS) version
 7.00 for MS-DOS and MS OS/2, cannot use the QuickBASIC Extended
 (QBX.EXE) Microsoft Advisor online Help system files. (The QBX.EXE
 editor environment is also included with BASIC PDS 7.00.)

 The online Help files used by QBX.EXE are of the wrong size and format
 to be used by the M.EXE or MEP.EXE editor.

 No version of the M.EXE or MEP.EXE editor can use the Microsoft
 Advisor online Help files used by QBX.EXE.

 This problem is eliminated by using PWB (Programmer's WorkBench),
 which comes with Microsoft BASIC PDS 7.10. PWB.EXE replaces the
 M.EXE/MEP.EXE editor, and improves functionality.

 The help files of QBX.EXE and PWB.EXE can be created and modified
 using HELPMAKE.EXE, the Microsoft Help File Creation Utility.


 202. Cannot Link PROISAM.LIB or PROISAMD.LIB into Quick Library

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900205-118
 Last Modified: 27-FEB-1990    ArticleIdent: Q58922

 The libraries PROISAM.LIB and PROISAMD.LIB included with Microsoft
 BASIC Professional Development System (PDS) Version 7.00 for MS-DOS
 cannot be linked into Quick libraries to be used by the QuickBASIC
 Extended Environment (QBX.EXE).

 Trying to link PROISAM.LIB or PROISAMD.LIB into a Quick library
 generates the following error message:

    LINK : fatal error L4050: too many public symbols for sorting

 The terminate-and-stay-resident (TSR) programs PROISAM.EXE and
 PROISAMD.EXE are the programs that make the ISAM engine available to
 QBX. PROISAM.EXE or PROISAMD.EXE must be run prior to invoking QBX.EXE
 if you want to use ISAM statements in your BASIC program.

 PROISAMD.EXE supports all the ISAM routines. PROISAM.EXE does not
 support all of the features of ISAM because for many database
 applications certain features are not needed. It does not contain the
 "data dictionary" statements -- CREATEINDEX, DELETEINDEX, and
 DELETETABLE. It contains a restricted version of the OPEN...FOR ISAM
 statement that opens a database or table but does not create it if it
 does not already exist.


 203. CONFIG.SYS IOPL=YES to Run CodeView CVP.EXE in Protected Mode

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | S_CodeView
 Last Modified: 27-FEB-1990    ArticleIdent: Q58923

 To run the Microsoft CodeView debugger (CVP.EXE) in OS/2 protected
 mode, you must have the following line in your CONFIG.SYS file in MS
 OS/2:

    IOPL=YES

 This information applies to the Microsoft CodeView debugger (CVP.EXE)
 shipped with Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS and MS OS/2.


 204. Must LINK 87.LIB Stub File in .OBJ List, NOT in the .LIB List

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900215-30
 Last Modified:  1-MAR-1990    ArticleIdent: Q58953

 Page 612 of the "Microsoft BASIC 7.0: Programmer's Guide" correctly
 states the following concerning the .LIB stub files (87.LIB,
 NOTRNEMR.LIB, and NOTRNEMP.LIB):

    Stub files (including the .LIB files listed) are specified in the
    <objfiles> field of LINK. You must supply the /NOE
    (/NOEXTDICTIONARY) option when linking any of the stub files.

 If you mistakenly link the 87.LIB, NOTRNEMR.LIB, or NOTRNEMP.LIB stub
 file in the .LIB area instead of the .OBJ area of the LINK.EXE command
 line, the stub file will be ignored, and no code is excluded from your
 .EXE file.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 Example of Using 87.LIB Stub File
 ---------------------------------

 To remove floating-point-coprocessor emulation code from a stand-alone
 BASIC PDS 7.00 .EXE program, the 87.LIB file must be placed in the
 .OBJ area in the LINK.EXE command line, as follows:

    BC test/O;
    LINK test+87.LIB /NOE;

 The resulting .EXE program requires the presence of an 8087, 80287, or
 80387 (80x87) numeric coprocessor.

 87.LIB should be placed in the linker's objects (.OBJ) list, NOT in
 the libraries (.LIB) list. If you mistakenly link the 87.LIB file in
 the .LIB area of the LINK.EXE command line, 87.LIB is ignored, and no
 code is excluded from your .EXE file. (The resulting .EXE program will
 run on machines with or without a coprocessor.) Below is an example of
 the WRONG way to link the 87.LIB stub file:

    LINK test,,,87.LIB /NOE;

 This is wrong because the linker first searches the default BASIC
 libraries for the references it needs and only then searches your
 listed .LIB files for unresolved references (if any). For stub files
 to work, they must appear in the .OBJ area of the LINK command line to
 resolve routine references before the default library reference
 search.


 205. "R6002 - Floating Point Not Loaded" Without Math Coprocessor

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900215-15
 Last Modified: 27-FEB-1990    ArticleIdent: Q58954

 A BASIC PDS 7.00 program gives "run-time error R6002 - Floating point
 not loaded" on a machine WITHOUT a coprocessor when the BASIC run-time
 library or .EXE program is created with coprocessor-only support.
 Coprocessor-only support means that the BASIC run-time routines
 require an 80x87 (8087, 80287, or 80387) math coprocessor to run.

 The R6002 error is an initialization error that cannot be trapped in a
 BASIC program.

 Implementing coprocessor-only support in an .EXE program depends upon
 whether you compile with or without the BC /O (stand-alone .EXE)
 option, as follows:

 1. If you compile WITHOUT BC /O, BASIC programs require a run-time
    module (BRT70xxx.EXE) to be present at run time. If you want to
    build a BASIC run-time module and BRT70xxx.LIB file with
    coprocessor-only support, you must invoke the BUILDRTM.EXE utility
    with the /FPi87 switch. For example:

       BUILDRTM /LR /FPi87 /DEFAULT

    (See Page 611 of "Microsoft BASIC 7.0: Language Reference" for an
    explanation of the options of the BUILDRTM.EXE utility.) You can
    then link with your new coprocessor-only run-time module, as
    follows:

       BC test;
       LINK IMPORT+test,test,,{newlibname} /NOE;

 2. If you compile WITH the BC /O (stand-alone .EXE) option, you can
    directly link your BASIC .OBJ file with the 87.LIB stub file. For
    example:

       BC test /O;
       LINK test+87.LIB /NOE;


 206. Twice-Called String FUNCTION May Fail in QB/QBX Quick Library

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10 B_QuickBas
 Last Modified:  6-AUG-1990    ArticleIdent: Q58955

 In the QBX.EXE or QB.EXE environment, a STATIC string FUNCTION located
 in a Quick library (.QLB) that is invoked twice within the same PRINT
 or assignment statement may give incorrect results. This problem only
 exists with a STATIC string FUNCTION in a Quick library that is
 invoked twice in one statement with a plus sign (+, for string
 concatenation) connecting the two invocations. This problem can be
 worked around easily by using temporary variables and splitting the
 statement into two statements. The problem does not occur in compiled
 and linked .EXE programs.

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment shipped with Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS, in the QB.EXE
 environment shipped with Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS, and in the QB.EXE environment shipped with Microsoft
 QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b,
 buglist4.50) for MS-DOS. We are researching this problem and will post
 new information here as it becomes available.

 Code Example
 ------------

 The following code example demonstrates the problem:

    FUNCTION Foop$(x$) STATIC
      Foop$ = x$ + "Z"
    END FUNCTION

 The module above should be compiled and built into a Quick library,
 then QBX should be started with that Quick library. Calling this
 FUNCTION twice in a row gives the incorrect results, as follows:

    DECLARE FUNCTION Foop$(x$)
    PRINT Foop$("abc")+Foop$("def")

 This example prints "defZdefZ" instead of correctly printing
 "abcZdefZ".


 207. ListBox Redefines Window 1 and Closes All Windows When Done

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900209-66
 Last Modified: 26-FEB-1990    ArticleIdent: Q58957

 The ListBox function of the WINDOW.BAS toolbox file is not designed to
 be used when other windows are already open. This is because ListBox
 redefines Window 1 and closes all windows when it is finished
 executing. This is not a problem, but a limitation of the ListBox
 function.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 This behavior of the ListBox function can be changed by modifying two
 statements, the one that opens and redefines Window 1 and the one that
 closes all the windows at the end of the function.

 The statement that opens and redefines Window 1 is as follows:

    WindowOpen 1, 4, StartRowPos, 20, StopRowPos, 0, 7, 0, 7, _
        15, 0, 0, 0, 1, 1, ""

 The number mentioned immediately after "WindowOpen" (1 in this case)
 is the handle to the window that will be opened. If Window 1 already
 exists, it will be redefined and become the modal window that is used
 by the ListBox function. This statement must be changed so that the
 next available window handle is used, not always Handle 1. The
 function for getting this handle is WindowNext. Therefore, the
 modified WindowOpen statement would be as follows:

    WindowOpen WindowNext, 4, StartRowPos, 20, StopRowPos, 0, 7, 0, 7, _
       15, 0, 0, 0, 1, 1, ""

 Now when the statement is executed, the next available window handle
 is used instead of always using Handle 1. This ensures that a window
 that is already open will not be redefined.

 The statement that closes all of the windows at the end of the
 function is as follows:

    WindowClose 0

 Passing a 0 to the WindowClose statement closes all open windows.
 Passing any other handle closes just the window with that handle. This
 statement must be changed so that only the current window (the one
 being used by ListBox) is closed. The function that returns the handle
 of the current window is WindowCurrent. Therefore, the above statement
 should be changed to the following:

    WindowClose WindowCurrent

 When the above two changes have been made to the ListBox function, it
 can safely be used with other open windows.

 The following sample program illustrates how to use the ListBox
 function. It opens a window and then a button in that window. Then it
 invokes ListBox, passing it an array of strings to display. After the
 user has finished with the list, the WindowDo procedure is invoked,
 which polls the mouse, waiting for the user to click on the button
 opened in Window 1. When it is clicked, the program ends. However, if
 the above changes have not been made to the ListBox function, Window 1
 is redefined by the window opened by ListBox. Thus, the first window
 opened disappears, along with its button. After ListBox is finished
 executing, it closes the window that it created, leaving no windows
 for the WindowDo procedure to operate on. This causes the program to
 end immediately.

 Code Example
 ------------

 'The following INCLUDE, COMMON SHARED, and DIM statements are
 'generally needed for working with the toolbox library routines.

 '$INCLUDE: 'general.bi'
 '$INCLUDE: 'mouse.bi'
 '$INCLUDE: 'menu.bi'
 '$INCLUDE: 'window.bi'

 COMMON SHARED /uitools/ GloMenu           AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()        AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()         AS MenuItemType
 COMMON SHARED /uitools/ GloWindow()       AS WindowType
 COMMON SHARED /uitools/ GloButton()       AS ButtonType
 COMMON SHARED /uitools/ GloEdit()         AS EditFieldType
 COMMON SHARED /uitools/ GloStorage        AS WindowStorageType
 COMMON SHARED /uitools/ GloWindowStack()  AS INTEGER
 COMMON SHARED /uitools/ GloBuffer$()

 DIM GloTitle(MAXMENU)           AS MenuTitleType
 DIM GloItem(MAXMENU, MAXITEM)   AS MenuItemType
 DIM GloWindow(MAXWINDOW)        AS WindowType
 DIM GloButton(MAXBUTTON)        AS ButtonType
 DIM GloEdit(MAXEDITFIELD)       AS EditFieldType
 DIM GloWindowStack(MAXWINDOW)   AS INTEGER
 DIM GloBuffer$(MAXWINDOW + 1, 2)

 DIM text$(1 TO 15)

 FOR i = 1 TO 15                  'Load string array with some
 text$(i) = STRING$(15, i + 64)   'strings. This will be the list
 NEXT i                           'passed to the ListBox function.

 CLS
 CALL WindowInit   'Initialize window routines
 CALL MouseInit    'Initialize mouse routines

 'Open window #1.
 CALL WindowOpen(1, 3, 10, 20, 70, 14, 1, 14, 1, 15, false, false,
 false, false, 1, "Window")

 'Open button #1 in window #1.
 CALL ButtonOpen(1, 1, "OK", 10, 29, 0, 0, 1)

 'Make the mouse cursor visible.
 CALL MouseShow

 'Put up the list box.
 a% = ListBox(text$(), 15)

 'Trap the clicking of the button.
 CALL WindowDo(0, 0)
 END


 208. Size and Memory Limits in QBX.EXE in BASIC PDS 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900215-76
 Last Modified: 26-FEB-1990    ArticleIdent: Q58960

 The QBX.EXE environment offers programming versatility, but has
 limitations to keep file size and complexity manageable. As a result,
 you may reach these limits in some situations.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS and MS OS/2.

 The information below lists the boundaries that you may encounter in
 the QBX.EXE environment. Most of these limits also apply to the BC.EXE
 compiler. This information was taken from the Microsoft Advisor online
 Help system in QBX.EXE, under "Contents - QBX Memory and Capacity."

 ---------------------------------------------------------------
 QBX Environment Limits - Names, Strings, and Numbers
 ---------------------------------------------------------------
                               Maximum               Minimum

 Variable name length          40 characters             1
 String length                 32,767 characters         0
 Integers                      32,767               -32,768
 Long Integers                 2,147,483,647       -2,147,483,648
 Single precision numbers
                  (positive)   3.402823E+38         2.802597E-45
 Single precision numbers
                  (negative)   -2.802597E-45       -3.402823E+38
 Double precision numbers
                   (positive)
                     Maximum:
                          1.797693134862315D+308
                     Minimum:
                          4.940656458412465D-324
 Double precision numbers
                  (negative)
                     Maximum:
                         -4.940656458412465D-324
                     Minimum:
                         -1.797693134862315D+308
 Currency
                     Maximum:
                          922337203685477.5807
                     Minimum:
                         -922337203685477.5808

 ----------------------------------------------------------------
 QBX Environment Limits - Arrays
 ----------------------------------------------------------------
                                   Maximum              Minimum
 Array size (all elements)
   Static                          65,535 bytes (64 K)     1
   Dynamic                         Available memory
 Number of dimensions allowed      60                      1
 Dimensions allowed if unspecified 8                       1
 Array subscript value             32,767            -32,768

 Note: The maximum range between array subscript values is 32,767.

 -----------------------------------------------------------------
 QBX Environment Limits - Procedures and Files
 -----------------------------------------------------------------
                                   Maximum              Minimum

 Procedure size (interpreted)      65,535 bytes (64 K)     0
 Number of arguments passed        60 interpreted          0
 Nesting of include files          5 levels                0
 Module size (compiled)            65,535 bytes (64 K)     0
 DATA file numbers                 255                     1
 DATA file record number           2,147,483,647           1
 DATA file record size (bytes)     32,767 bytes (32 K)     1
 DATA file size                    Available disk space    0
 Path names                        127 characters          1
 Error message numbers             255                     1

 -----------------------------------------------------------------
 QBX Environment Limits - Editing
 -----------------------------------------------------------------
                                       Maximum         Minimum

 Text box entry                        127 chars          0
 Search for string                     127 chars          1
 Change to string                      127 chars          0
 Place markers                           4                0
 Watchpoints and/or watch expressions   16                0
 Number of lines in Immediate window    10                0
 Characters in View window on one line  255               0
 Length of COMMAND$ string              124 characters    0


 209. UI Toolbox Shortcut Keys Documentation Error in BASIC 7.00

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900220-48 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q58963

 On Page 496 of the "Microsoft BASIC 7.0: Language Reference" (for 7.00
 and 7.10) two of the procedure names under "Shortcut Keys" (for
 MENU.BAS) are incorrectly stated. ShortCutKeyDelete$ should be
 ShortCutKeyDelete and ShortCutKeyEvent$ should be ShortCutKeyEvent.
 Also on the same page, the WindowBorder function (detailed on Page 568
 of the same manual) should be added to the "Define Windows" summary
 (for WINDOW.BAS) in Table 3.5.

 This information applies to the User Interface (UI) Toolbox in
 Microsoft BASIC Professional Development System (PDS) Versions 7.00
 and 7.10 for MS-DOS.


 210. Bad Integer Output Using DEF FN, VAL, FOR-NEXT in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900217-5 buglist7.00 fixlist7.10
 Last Modified:  1-AUG-1990    ArticleIdent: Q59008

 When run as an .EXE program (compiled with BC.EXE), the program below
 gives incorrect output in Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and MS OS/2. The same program
 gives correct output when run in the QBX.EXE environment or compiled
 with the BC /D option.

 The program fails when it assigns an integer array (which is
 subscripted by a FOR...NEXT loop counter) to the VAL of a DEF FN
 string function operating on a temporary string that was assigned to
 an array element that is subscripted by the FOR...NEXT loop counter.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) version 7.00. This problem was
 corrected in BASIC PDS version 7.10.

 This problem does not occur with an .EXE compiled in QuickBASIC
 version 4.50 or earlier.

 The program below outputs "2 2" instead of "1 2" from an .EXE program.
 (The problem occurs whether compiled as a stand-alone .EXE or as an
 .EXE requiring the BRT module). This problem is corrected by doing any
 one of the following:

 1. Compiling with the BC /D option.

 2. Removing the DEFINT A-Z line.

 3. Replacing n (the ending value of the FOR...NEXT loop counter) with
    the constant 2 in the FOR...NEXT statement.

 4. Eliminating the use of the temporary (placeholder) variable t$ by
    putting s$(i) in place of it in the VAL function.

 5. Replacing d(i) with a nonarray (scalar) variable.

 Code Example
 ------------

    DEFINT A-Z
    DIM s$(1 TO 2), d(1 TO 2)
    DEF FNa$ (x$)
    FNa$ = x$
    END DEF
    CLS
    n = 2
    s$(1) = "1"
    s$(2) = "2"
    PRINT
    FOR i = 1 TO n
       t$ = s$(i)
       d(i) = VAL(FNa$(t$))
    ' One workaround is to use:   d(i) = VAL(FNa$(s$(i)))
       PRINT d(i);
    NEXT
    END


 211. "BASIC 7.0: Reference" Correction for CALL Statement Example

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900217-3 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q59073

 The corrections below apply to the Example program for the CALL
 statement (for calling BASIC procedures) on Page 32 of the "Microsoft
 BASIC 7.0: Language Reference" manual for 7.00 and 7.10:

 1. The following incorrect sentence should be changed to say "the
    24th line" instead of "the 25th line":

       The following example uses the CALL statement to call a SUB
       procedure that prints a message on the 25th line of the
       display....

 2. The following remark after the LOCATE 24,1 statement should be
    changed to say "the 24th line" instead of "the 25th line":

       LOCATE 24, 1 ' Move cursor to 25th line of display.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 212. BASIC 7.00 ISAM Cannot Store Single-Precision Numbers

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  2-MAR-1990    ArticleIdent: Q59289

 When using the ISAM file-handling feature of Microsoft BASIC
 Professional Development System (PDS) Version 7.00 for MS-DOS, you
 cannot use a single-precision variable in the TYPE ... END TYPE record
 structure. To store real numbers (numbers with a decimal point), you
 must use a CURRENCY or a double-precision variable. (You may also use
 an INTEGER and a LONG integer if you do not need a number with a
 decimal point.)

 This is not a software problem, but is a design limitation of BASIC
 PDS 7.00.

 For more information on this topic, see Pages 333-334 of the
 "Microsoft BASIC 7.0: Programmer's Guide."


 213. BASIC and C, /FPa, LINK L2025 "Symbol Defined More Than Once"

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# S900202-109 S_C buglist6.00 buglist6.00b buglist7.00
 Last Modified: 18-OCT-1990    ArticleIdent: Q59321

 When linking BASIC and C, where the C routine uses math functions
 (such as SIN, COS) and was compiled with the /FPa (alternate math)
 option and where the BASIC program was compiled with the /FPa option
 and without the /O (stand-alone) option, several "L2025 Symbol defined
 more than once" errors will occur. These errors are not affected by
 /NOD or /NOE LINK options.

 Any of the following three workarounds corrects the problem:

 1. Compile the BASIC program with BC /o (stand-alone).

 2. Compile BASIC and C with (default) BC /FPi.

 3. Call all math functions from BASIC. (C can call BASIC externs to do
    math -- see below.)

 Microsoft has confirmed this to be a problem in Microsoft C Compiler
 versions 5.00 and 5.10 (buglist5.00, buglist5.10), in Microsoft BASIC
 Compiler versions 6.00 and 6.00b for MS-DOS and MS OS/2, and in
 Microsoft BASIC Professional Development System (PDS) version 7.00 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 The following code example causes the "symbol defined more than once"
 errors when compiled as listed. The following are the compile and link
 lines for the BASIC and C programs:

    BC /FPa testb;
    CL -c -AL -FPa test.c ;
    LINK /NOD /NOE testb+test,,,brt70anr llibcar;

 When the code below is compiled and LINKed as specified, the following
 LINK errors will occur:

    llibcar.LIB(fcall.ASM) : error L2025: __fpmath : symbol defined
       more than once

    llibcar.LIB(..\ccalle.ASM) : error L2025: __fpsignal : symbol defined
       more than once

 For more information about calling C from BASIC, search in this
 Knowledge Base using the following word:

    BAS2C

 BASIC Program, TESTB.BAS
 ------------------------

 DECLARE SUB test CDECL
 CALL test

 'Function used by C for workaround #3
 FUNCTION BasSin#(a AS DOUBLE)
    BasSin#=SIN(a)
 END FUNCTION

 C Program, TEST.C
 -----------------

 #include <stdio.h>

 extern double pascal BasSin(double near *);  // BASIC function for
                                              // workaround #3
 void test()
 {
 double d=1.2;
 printf("%f",sin(d));           // Comment this line and
 //printf("%f",BasSin(&d));     // uncomment this line for workaround #3
 }


 214. PRINT Ignored After PRINT CURRENCY Variable in QBX.EXE 7.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q59398

 The program below demonstrates a problem with executing a PRINT
 statement to produce a blank line.

 After printing a variable or array element that has been dimensioned
 as a CURRENCY data type, a blank line cannot be produced by issuing a
 successive PRINT. This problem occurs only within the QBX.EXE
 environment, and does not occur with programs compiled with BC.EXE.

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment of Microsoft BASIC Professional Development System (PDS)
 version 7.00 for MS-DOS. This problem was corrected in BASIC PDS
 version 7.10.

 Code Example
 ------------

    DIM A AS CURRENCY
    A = 10
    PRINT A
    PRINT
    PRINT "Where did the space go?"
    END

 Output
 ------

    10
    Where did the space go?

 Workaround Code Example
 -----------------------

 Each additional PRINT statement will correctly produce a blank line,
 as shown in the following program:

    DIM A AS CURRENCY
    A = 10
    PRINT A
    PRINT
    PRINT
    PRINT "A blank line was printed"

 Output
 ------

    10

    A blank line was printed


 215. BASIC 7.0 UEVENT Example Causes Subsequent Programs to Hang

 Product Version(s): m7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900222-46 docerr buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q59399

 The sample program for trapping a user-defined event on Pages 310-312
 of the "Microsoft BASIC 7.0: Programmer's Guide" for Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 contains
 a misprint, but even if corrected, this sample program may cause the
 computer to hang after it is run.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10. We are
 researching this problem and will post new information here as it
 becomes available.

 Page 311 of "Microsoft BASIC 7.0: Programmer's Guide" contains a
 misprint in the MASM programming example for trapping a user-defined
 event. If the code is not corrected, an "A2009: Symbol not defined"
 error will result when the code is assembled.

 The last section of code for this example reads as follows:

     RestInt  proc  uses ds
        lds dx, cs:OldVector
        mov  x, 251CH          ; <== this line contains the misprint

 To correct the code, make the following change:

     RestInt  proc  uses ds
        lds dx, cs:OldVector
        mov ax, 251CH          ; <== change "x" to "ax"

 However, even when this misprint is corrected, if the BASIC program is
 compiled so that it requires a run-time module or if the assembly code
 is put into a Quick library, running the program may cause the
 computer to hang. The problem does not occur if the BASIC program is
 compiled with the BC /O option.

 The following compiling and linking steps will reproduce the problem:

 1. Assemble the MASM code as follows:

       MASM MASMPROG.ASM;

 2. Compile the BASIC code so that it requires a run-time module (no
    /O) and enables event trapping (/V). If the program is compiled as
    a stand-alone program (with the /O option), the problem does not
    exist.

       BC BASPROG.BAS /V;

 3. LINK the program using the BASIC PDS 7.00 or 7.10 linker, as
    follows:

       LINK BASPROG.OBJ + MASMPROG.OBJ;

 4. Run the program.

 5. The computer may hang instantly or may hang after attempting to run
    another program, such as QBX.EXE.


 216. CHDIR & SHELL "CHDIR" in OS/2 Protected Mode Differs from DOS

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900226-124
 Last Modified:  9-MAR-1990    ArticleIdent: Q59400

 In OS/2 protected mode, if a BASIC program issues a CHDIR, the command
 will affect only the current BASIC process; other processes in the
 system will not be affected. However, this behavior changes when a
 SHELL statement is issued because a SHELL statement executes a copy of
 CMD.EXE. The SHELLed program is considered to be a "child process" of
 the program that issued the SHELL. If the SHELLed program executes
 OS/2's CD or CHDIR command, only the SHELLed process will be affected,
 not the currently running BASIC program that issued the SHELL. This is
 not a problem with BASIC under OS/2; it is correct behavior that is
 dictated by the design of OS/2.

 This information applies to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for OS/2 and to Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for OS/2.

 The OS/2 API function, DosChDir(), has the same effect as the BASIC
 CHDIR statement. For both of these, the currently executing BASIC
 process is changed, but the parent process (which started the BASIC
 process) is unchanged. Similar to CHDIR, the ENVIRON statement (and
 other statements that modify the OS/2 protected-mode environment) has
 no effect on the parent process.

 This is a feature of the protected mode of OS/2; child processes
 cannot affect the parent process's environment. This represents a
 notable change from DOS. In DOS, there are "programs," but not
 "processes" as in OS/2. In DOS, you cannot have multiple programs
 running simultaneously. There is only one program running and
 therefore it is reasonable to assume that any change directory command
 will change the current DOS directory for both the parent and child in
 a program. Changing the "current directory" under DOS changes it for
 the entire operating system -- the change is global. This means the
 change also takes effect for any programs run later unless the user or
 program specifically changes the current directory. In OS/2 protected
 mode where there can be many programs running at once, having one
 global working directory that could be changed by any process at any
 moment would not be reasonable.

 Code Example
 ------------

 In OS/2 protected mode, the following code example has no effect on
 the screen group that starts the EXE file, but the FILES statement
 illustrates that the directory has been changed for the current
 process:

 a$ = "\bc7"
 CHDIR a$            'This only affects the current BASIC process
                     'API Function DosChDir has same effect as CHDIR
 'SHELL "cd "+a$     'This only affects the SHELLed process. After
 FILES "*.*"         'returning from the SHELL, it has no effect.

 In DOS, either the CHDIR statement or the commented SHELL statement in
 the above program will change the directory for the DOS command line.


 217. QBX & BC /Es Option Shares Expanded Memory with Mixed Language

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900227-66 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q59402

 This article discusses the /Es (share expanded memory) option for
 QBX.EXE and BC.EXE in Microsoft BASIC Professional Development System
 (PDS) Versions 7.00 and 7.10 for MS-DOS.

 The BC /Es Option
 -----------------

 The /Es option for BC.EXE needs to be added to the list of BC options
 on Page 559 of the "Microsoft BASIC 7.0: Programmer's Guide" for
 versions 7.00 and 7.10.

 The BC /Es option is correctly described on Page 608 of the "Microsoft
 BASIC 7.0: Language Reference" (Appendix C: "Command-Line Tools Quick
 Reference") for 7.00 and 7.10. The BC /Es option is also correctly
 documented as follows in the Microsoft Advisor online Help system in
 QBX.EXE, found by choosing Contents from the Help menu, then selecting
 "BC Command Line":

    "HELP: BC Command Line"
    /Es       Allows you to share expanded memory between BASIC and
              mixed-language routine(s) that make use of expanded memory.
              Specify /Es when you are going to use a mixed-language
              routine that makes use of expanded memory.

 Note: The only way an .EXE program compiled with BC.EXE can use
 expanded memory is with ISAM file buffers, or when linked to use
 overlays, as described in a separate article found with the following
 query:

    how and LINK and overlays and BASIC and 7.00

 The QBX /Es Option
 ------------------

 QBX.EXE, the programming environment included with Microsoft BASIC
 Professional Development System (PDS) Version 7.00, can use expanded
 memory for procedures smaller than 16K.

 Note that the QBX /Es option cannot be used together with the /Ea
 option. (The QBX /Ea option lets each non-variable-length string array
 smaller than 16K use one 16K page of expanded memory.)

 By invoking QBX with the /Es switch, QBX can share expanded memory
 with mixed-language routines (in Quick libraries) that make DOS
 interrupts to access expanded memory.

 The QBX /Es switch is correctly documented on Page 626 of the
 "Microsoft BASIC 7.0: Language Reference," and in the Microsoft
 Advisor online Help system in QBX.EXE, found by choosing Contents from
 the Help menu, then selecting "QBX Command Line":

    "HELP: QBX Command Line"
    /Es      Allows you to share expanded memory between QBX and
             Quick libraries or mixed-language routines that make use
             of expanded memory. Specify /Es when you are using a
             Quick library or mixed-language routine that makes use
             of expanded memory. Do not use /Es with the /Ea option.


 218. Illegal DIM x AS STRING*<Variable> Can Hang QB.EXE or QBX.EXE

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 fixlist7.10 B_QuickBas
 Last Modified: 20-SEP-1990    ArticleIdent: Q59405

 Illegally defining fixed-length strings (DIM AS STRING * N%) with
 integer variables (N%) can in some cases cause problems inside the
 QB.EXE and QBX.EXE environments. (The length of fixed-length strings
 must be defined with constants, not variables.)

 Microsoft has confirmed this to be a problem in the QB.EXE environment
 of Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00,
 buglist4.00b, buglist4.50); in the QB.EXE environment of Microsoft
 BASIC Compiler versions 6.00 and 6.00b; and in the QBX.EXE environment
 of Microsoft BASIC Professional Development System (PDS) version 7.00
 for MS-DOS. This problem was corrected in the QBX.EXE environment of
 BASIC PDS 7.10.

 To find a related article on this topic, query in this Knowledge Base
 on the following words:

    invalid and constant and variable and fixed and length and string

 The QB.EXE environment of QuickBASIC 4.00 and 4.00b runs Examples 1
 and 2 (below) without hanging; however, it fails to flag the variable
 on the STRING * flen declaration as an error.

 In both Examples 1 and 2, getting rid of flen and defining the string
 with a constant value (x AS STRING * 82) corrects the problem. You can
 also work around the problem by making flen a CONST constant, for
 example:

    CONST flen = 82

 Also, by changing flen to a noninteger variable, the QB.EXE or QBX.EXE
 environment correctly flags the error. BC.EXE (the command-line
 compiler) always correctly flags the error.

 Example 1
 ---------

 When the following program is run inside the QuickBASIC Extended
 (QBX.EXE) 7.00 environment, the error message "INVALID CONSTANT" is
 flagged on the line "flen = 82" instead of on the DIM line:

    DEFINT A-Z
    flen = 82
    DIM x AS STRING * flen

 Example 2
 ---------

 When the following program is run in QB.EXE 4.50 or QBX.EXE 7.00, the
 computer may hang, or the error message "STRING SPACE CORRUPT" may
 display and the computer may exit back to DOS:

    DEFINT A-Z
    flen = 82
    TYPE recordtype
       x AS STRING * flen
    END TYPE
    DIM datetest AS recordtype


 219. QB.EXE/QBX.EXE "Identifier Too Long" Using User-Defined TYPE

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10 B_QuickBas
 Last Modified: 20-SEP-1990    ArticleIdent: Q59429

 Inside the QuickBASIC environment (QB.EXE or QBX.EXE), an "Identifier
 Too Long" error is incorrectly generated under the following
 circumstances:

 1. Create a user-defined TYPE (record). Give it one field with a long
    name (20 to 40 characters).

 2. DIMension a variable of that TYPE. Give the variable a long name
    (20 to 40 characters).

 3. Use the variable in some statement in the program and run the
    program.

 4. If the length of the entire identifier (record name plus the field
    name) is longer than forty characters, an "Identifier Too Long"
    error message is generated in the environment.

 This error occurs in QB.EXE and QBX.EXE, but does NOT occur with
 BC.EXE.

 Microsoft has confirmed this to be a problem in the QB.EXE environment
 of Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00,
 buglist4.00b, buglist4.50); in the QB.EXE environment of Microsoft
 BASIC Compiler versions 6.00 and 6.00b; and in QuickBASIC Extended
 (QBX.EXE), the extended environment provided with Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10. We are
 researching this problem and will post new information here as it
 becomes available.

 When using TYPEd variables, both parts of the variable, the variable's
 name and its field name, are supposed to have a limit of 40
 characters. This means that the total possible length of a TYPEd
 variable when used in a statement is 80 characters.

 This problem can be worked around by either shortening the name of the
 variable, shortening the name of the field in the TYPE, or by placing
 the single variable into an array of that TYPE.

 Code Example
 ------------

 TYPE temp
   '012345678901234567890123456789; Forty characters is a legal name:
    thisisatesttoobutthisistoolong AS INTEGER
 END TYPE

 DIM thisisatest AS temp

 ' The following causes an "identifier too long" error
 ' when the entire name exceeds forty characters.
 '012345678901234567890123456789012345678901
  thisisatest.thisisatesttoobutthisistoolong = 10

 DIM thisisatest(1) AS temp

 'If you make "thisisatest" an array instead of a single type
 'variable the problem is eliminated.
 thisisatest(1).thisisatesttoobutthisistoolong = 10


 220. 3 Cases Where DIR$ Gives "Illegal Function Call" in BASIC 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q59430

 Page 107 of the "Microsoft BASIC 7.0: Language Reference" manual (for
 7.00 and 7.10) incorrectly states that you can only receive "Illegal
 Function Call" using the DIR$ function if you don't specify a
 filespec$ the first time you call DIR$.

 However, the DIR$ function returns an "Illegal Function Call" in the
 following three circumstances:

 1. Invoking DIR$ for the first time without a filespec$ parameter
    causes an "Illegal Function Call" error.

 2. If you invoke DIR$ with a filespec$ and no matching files are found
    (it returns a null string -- ""), if you then invoke DIR$ another
    time without the filespec$ parameter, you will receive an "Illegal
    Function Call" error. In other words, you must call DIR$ with a
    filespec$ until a match is found. After that, DIR$ can be called
    again with no filespec$ to get the next filename in the list of
    files found.

 3. Once the entire list of matched file names has been retrieved,
    using DIR$ without a filespec$ correctly returns a null string
    telling you that the end of the list has been reached. Invoking
    DIR$ one more time after that point generates an "Illegal Function
    Call." In other words, once you run out of files that matched your
    original filespec$, you must call DIR$ with a filespec$ again until
    another match is achieved.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The code example below demonstrates that when DIR$ is used
 incorrectly, it generates an "Illegal Function Call." If you comment
 out DIR$ after the WHILE loop, the program runs correctly.

 The DIR$ function is a new function introduced in Microsoft BASIC PDS
 7.00. It is designed to let you find files and browse through
 directories looking for files without having to use SHELL, as in
 earlier versions of BASIC. DIR$ takes a filespec$ parameter that is
 very similar to the parameters that can be passed to the DIR command
 found in MS-DOS or OS/2.

 Code Example
 ------------

    DIM test(200) AS STRING * 12
    CLS
    temp$ = DIR$("*.*")
    count = 0
    WHILE temp$ <> "" ' When it returns null,
                      ' the end of the list has been reached.
       test(count) = temp$
       count = count + 1
       PRINT temp$
       temp$ = DIR$
    WEND
    PRINT DIR$       ' If this line is left here, it will cause the error
                     ' "Illegal Function Call" to occur.
    END


 221. 7.10 Correction for OPEN COM Transfer & Receive Buffer; TB, RB

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900217-4 docerr
 Last Modified: 16-JAN-1991    ArticleIdent: Q59431

 This article corrects three documentation errors in the description
 of the Transfer Buffer (TB[n]) and Receive Buffer (RB[n]) options for
 the OPEN COM statement on page 240 of the "Microsoft BASIC 7.0:
 Language Reference" manual for BASIC PDS versions 7.00 and 7.10.

 Also, page 559 of "Microsoft BASIC 7.0: Programmer's Guide"
 incorrectly states that "the transmission buffer is allocated 128
 bytes for each communications port." This should be changed to "512
 bytes" for the default transmission buffer size.

 To illustrate the documentation corrections (listed below), consider
 the following program sequence. PROG1.EXE is started from the DOS or
 OS/2 command line. PROG1 sets the receive-buffer size to 4096 in the
 OPEN COM statement, CLOSEs the communications port, and CHAINS to
 PROG2.EXE. When PROG2 OPENs the COM port, if PROG2 does not use the RB
 parameter, the size of the receive buffer will still be 4096. This is
 true whether you compile with /O or use the BRTxxx.EXE run-time
 module.

 Note that the size of the transmit buffer (TB) in PROG1.EXE never
 affects the size of the transmit buffer in PROG2.EXE. The size of the
 transmit-buffer is not transferred across a CHAIN. (This is by
 design.)

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The following are three documentation errors in the description of the
 Transfer Buffer (TB[n]) and Receive Buffer (RB[n]) options for the
 OPEN COM statement on page 240 of the "Microsoft BASIC 7.0: Language
 Reference" manual:

 1. For the TB[n] option, the first sentence is incorrect, as follows:

       Sets the size of the receive buffer to n bytes.

    This sentence should be changed to read as follows:

       Sets the size of the transmit buffer to n bytes.

 2. For the TB[n] option, the last sentence incorrectly describes the
    default transmit buffer size, as follows:

       The default value, if n or the TB option is omitted, is the
       current receive buffer size.

    This sentence should be changed to read as follows:

       The default value, if n or the TB option is omitted, is 512
       bytes.

    (Note: The default size for the transmit buffer is 512 bytes; the
    only way to change this size is with the TB option in the OPEN COM
    statement. The transmit-buffer size is never affected by any
    receive-buffer options.)

 3. The description for the RB[n] option should be supplemented to say
    that the receive buffer size of the program currently being
    executed, if not changed by the RB in the OPEN COM statement or by
    the /C:n option on the QB or BC command line, will be the same as
    for the program from which the current program was CHAINed (if any)
    with the CHAIN statement.

 The OPEN COM statement can open the device names "COM1:" and "COM2:".


 222. Don't Use OPTION BASE 1 in UI Toolbox: "Illegal Function Call"

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900228-24
 Last Modified: 12-MAR-1990    ArticleIdent: Q59488

 When writing programs that utilize the User Interface (UI) Toolbox
 routines, it is not advisable to use the OPTION BASE 1 statement. This
 can create run-time errors, such as "Illegal function call," because
 the UI Toolbox uses index "zero" in arrays that must be in COMMON
 SHARED between your modules.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.


 223. INSTR, Documentation Correction for BASIC PDS 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900306-120 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q59562

 The following sentence describing the INSTR function on Page 138 of
 the "Microsoft BASIC 7.0: Programmer's Guide" for Microsoft BASIC
 Professional Development System (PDS) Versions 7.00 and 7.10 is
 incorrect. The second sentence under the "Searching for Strings"
 paragraph states the following:

    The INSTR(stringexpression1$, stringexpression2$) function tells
    you whether or not string2 is contained...

 This sentence should be changed to refer to stringexpresion2$ instead
 of string2, as follows:

    The INSTR(stringexpression1$, stringexpression2$) function tells
    you whether or not stringexpression2$ is contained...


 224. "Cannot Load File" Error with ISAMREPR.EXE and SHARE.EXE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900227-52 buglist7.00 fixlist7.10
 Last Modified: 14-FEB-1991    ArticleIdent: Q59565

 If SHARE.EXE is loaded, attempting to repair an ISAM file using
 ISAMREPR.EXE results in the error:

    Cannot open 'file.mdb'

 This error occurs regardless of the version of MS-DOS being used.

 ISAMREPR.EXE is an ISAM file repair utility provided with Microsoft
 BASIC Professional Development System (PDS) version 7.00. This
 information applies only to BASIC PDS for MS-DOS.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 7.00. This problem is corrected if you use SHARE.EXE from MS-DOS
 version 4.01 and ISAMREPR.EXE from BASIC PDS version 7.10. (You must
 recompile your programs in BASIC PDS version 7.10.)

 To reproduce the problem, load SHARE.EXE, then, using the ISAM
 database file "BOOKS.MDB" provided with BASIC PDS 7.00, attempt to
 repair the file using ISAMREPR.EXE, as follows:

    C:\> SHARE

    C:\> ISAMREPR BOOKS
    Microsoft  (R)  ISAM Repair Utility   Version 1.00
    Copyright  (C)  Microsoft Corp 1989.  All rights reserved.

    ISAMREPR : Cannot open 'BOOKS.MDB'


 225. OS/2 DosFindFirst Code Example Correction; Missing Comma

 Product Version(s): 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q59723

 On Page 525 of the "Microsoft BASIC 7.0: Programmer's Guide" for
 Microsoft BASIC Professional Development System (PDS) Versions 7.00
 and 7.10, the code example given is missing a comma to delimit the
 VARSEG and SADD parameters when invoking the function DosFindFirst%.

 The incorrect syntax documented in the manual is as follows:

    x = DosFindFirst%(VARSEG(flname$) SADD(flname$), dirh,_
                     atr, buffer, bufflen, searchcount, reserved)

 The correct syntax of the CALL is as follows:

    x = DosFindFirst%(VARSEG(flname$), SADD(flname$), dirh,_
                     atr, buffer, bufflen, searchcount, reserved)

 A comma is needed between VARSEG(flname$) and SADD(flname$).


 226. List Box Width Can Be Only 14-55 Characters in 7.00 UI Toolbox

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900222-126
 Last Modified: 26-MAR-1990    ArticleIdent: Q59724

 The ListBox() function of the WINDOW.BAS toolbox file takes two
 parameters: a string array containing the list of items to be
 displayed, and an integer variable containing the number of items in
 the list.

 The header comment of the ListBox() function describes how to add a
 third parameter, an integer variable (BoxWidth%) that contains the
 desired width of the list box to be displayed. Unless this parameter
 is added, the width of the list box always defaults to 14 characters.
 However, even if this parameter is given, the width cannot be less
 than 14 or greater than 55 characters. The ListBox() function ensures
 that the width is within this range.

 This information applies to the User Interface (UI) Toolbox in
 Microsoft BASIC Professional Development System (PDS) Version 7.00 for
 MS-DOS.

 After adding the modification that allows the desired list box width
 to be specified, a sample invocation of the ListBox() function would
 be as follows

    x% = ListBox(text$(),MaxRec%,BoxWidth%)

 where:

    x%         is the array element selected from the list box
    text$()    is the string(s) to display in the list box
    MaxRec%    is the number of strings to display in the list box
    BoxWidth%  is the desired width of the list box

 If BoxWidth% is less than 14, ListBox() changes it to 14. If BoxWidth%
 is greater than 55, ListBox() changes it to 55. The statements that
 perform these checks are located toward the end of the function under
 the subroutine heading ListBoxWidthCalc:

    IF BoxWidth < 14 THEN BoxWidth = 14
    IF BoxWidth > 55 THEN BoxWidth = 55

 It is NOT recommended that you change or delete these IF statements to
 allow any list box width. If the width is too small, the OK and Cancel
 buttons may not fit in the list box. If the width is too large, the
 resulting list box may not fit on the screen.


 227. BASIC 7.00 Can Write Whole Array (in TYPE) to Disk at Once

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  3-AUG-1990    ArticleIdent: Q59734

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 introduce support for static arrays in user-defined TYPE
 definitions. This means that you can write an entire array (in a user
 TYPE record) to a disk file at once. The code example below writes an
 entire array to a RANDOM or BINARY file using a single PUT# statement.

 Note that you cannot output arrays all at once (in one PRINT# or
 WRITE# statement) to files opened with sequential access (OPEN FOR
 OUTPUT). With sequential access (OPEN FOR OUTPUT or INPUT), you must
 output or input just one array element at a time.

 You must use RANDOM or BINARY access to write a static
 nonvariable-length string array to a file all at once (as shown in the
 examples below).

 Note that in Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50 for
 MS-DOS, in Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS
 and MS OS/2, and in Microsoft BASIC PDS versions 7.00 and 7.10 for
 MS-DOS and MS OS/2, you can directly write whole records (variables)
 of a given user-defined TYPE to disk as the third argument of the PUT#
 statement. Each and every element of the user-defined TYPE record is
 automatically copied to the file. If the data is numeric and you
 output to a file OPENed with RANDOM or BINARY access, the data is
 automatically stored in numeric format (without requiring a lengthy
 FIELD statement or numeric-to-string conversion functions such as
 MKS$, MKD$, MKI$, or MKL$).

 Since an array can be an element of a record of user-defined TYPE in
 BASIC 7.00 and 7.10 (but not in earlier versions), you can write a
 whole array at once into a disk file, as shown below.

 Code Example
 ------------

 The following example, compiled in BASIC PDS 7.00 or 7.10, shows how
 to write a whole array to disk at once, using just one PUT# statement:

 TYPE rec1
   array1(20) AS INTEGER
 END TYPE
 DIM var1 AS rec1, var2 AS rec1  'DIMension var1 & var2 with TYPE rec1
 FOR i = 1 TO 20      ' Fill each element of the array:
   var1.array1(i) = i
 NEXT

 ' The following OPEN statements may OPEN FOR either RANDOM or BINARY:
 OPEN "test.dat" FOR RANDOM AS #1
 PUT #1, , var1       ' Write whole array to disk all at once.
 CLOSE

 OPEN "test.dat" FOR RANDOM AS #1
 GET #1, , var2      ' Reads array all at once into var2.
 FOR i = 1 TO 20     ' Print the contents of the array var2.array1:
   PRINT var2.array1(i);
 NEXT
 CLOSE


 228. ISAMCVT.EXE Fails to Convert db/LIB File, Try Packing First

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900312-79
 Last Modified: 26-MAR-1990    ArticleIdent: Q59765

 A customer reported that when converting db/LIB (dBASE) files to
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 ISAM files with the ISAMCVT.EXE utility, the ISAM files are not
 created correctly if the db/LIB file contains logically deleted
 records. For the process to be successful, the logically deleted
 records must be physically removed from the file. According to the
 customer, db/LIB provides a packing feature to do this.

 This information applies to Microsoft BASIC PDS 7.00 for MS-DOS.

 The utility ISAMCVT.EXE is used to convert other types of indexed
 files to BASIC's ISAM format. One of these types is db/LIB. A customer
 reported that if the db/LIB file to be converted has records in it
 that are marked for deletion, ISAMCVT.EXE either produces a corrupted
 ISAM file or does not produce one at all.

 Packing an indexed file is a method of physically removing records
 that are marked for deletion. The utility ISAMPACK.EXE is used to
 perform this function on BASIC's ISAM files. According to the
 customer, using a similar utility on a db/LIB file that has records
 marked for deletion allows ISAMCVT.EXE to successfully convert the
 file to the ISAM format.

 Microsoft has not verified this information, but it is recommended to
 pack all data files before they are converted to BASIC PDS ISAM with
 the ISAMCVT.EXE utility.


 229. Problem with MID$ Statement and MID$ Function in QBX.EXE

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900315-77 buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q60131

 Using the MID$ function as an argument of the MID$ statement can
 produce incorrect results in the QBX.EXE environment that comes with
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10, as shown in the program below.

 The problem does not occur when compiled with the BC.EXE environment
 of Microsoft BASIC PDS 7.00 and 7.10; with the BC.EXE or QB.EXE
 environment of Microsoft QuickBASIC version 4.00, 4.00b, or 4.50; or
 with the BC.EXE or QB.EXE environment of Microsoft BASIC Compiler
 versions 6.00 and 6.00b.

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment of Microsoft BASIC PDS versions 7.00 and 7.10. We are
 researching this problem and will post new information here as it
 becomes available.

 The program below should correctly output "1212345678". However, when
 run from within the QBX.EXE environment, it incorrectly outputs
 "1212121212". This behavior also occurs if a length% argument of 10 is
 used in the MID$ function. If 8 or 9 is used as the length% argument
 of the MID$ function, the correct output is produced. If the start%
 argument of the MID$ function is not taken to be 1, correct output
 displays.

 Code Example
 ------------

    A$= "1234567890"
    MID$(A$, 3) = MID$(A$, 1)
    PRINT A$

 Note: The first MID$ occurrence above is the MID$ statement, and the
 second occurrence is the MID$ function.


 230. BASIC PDS 7.00: ISAMREPR Always Adds 32K to a .MDB File

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900321-28
 Last Modified:  3-APR-1990    ArticleIdent: Q60132

 The ISAMREPR.EXE utility provided with Microsoft BASIC Professional
 Development System (PDS) Version 7.00 always adds at least 32K to an
 ISAM database file during the repair process. This is correct behavior
 for ISAMREPR and is documented on Page 384 of the "Microsoft BASIC PDS
 7.0: Programmer's Guide."

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS.

 During the repair process, ISAMREPR allocates 32K or more of extra
 space as "work space" for use while repairing the file. This space is
 automatically added to the file at the beginning, before any deleted
 or damaged records are found during the process. For instance, if
 ISAMREPR is run twice on the same file, at least 64K will be added to
 the file, even though the repair might not have been necessary the
 first time. However, this added space is not "lost"; it is reused as
 new records or tables are added to the file.

 If the size of the file becomes unmanageable because of unused space,
 ISAMPACK.EXE can be used to remove the unused space and reduce the
 size of the file.


 231. L2025 Creating Quick Library Using Functions in SIGNAL.H

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900114-12
 Last Modified:  3-APR-1990    ArticleIdent: Q60135

 When placing a C program using the functions from SIGNAL.H into a
 Quick library for QuickBASIC (QB.EXE) or QuickBASIC Extended
 (QBX.EXE), LINK flags multiple occurrences of L2025 "Symbol defined
 more than once" in the CRT0DAT.ASM module of the C library. These
 errors are not affected by the /NOE (No Extended library search)
 option. This conflict is a limitation of Quick libraries. The SIGNAL.H
 functions work correctly when linked with a compiled BASIC program.

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50, QB.EXE from Microsoft BASIC Compiler Versions 6.00 and 6.00b
 for MS-DOS, QBX.EXE from Microsoft BASIC Professional Development
 System (PDS) Version 7.00 for MS-DOS, Microsoft QuickC Versions 1.00,
 1.01, 2.00, and 2.01, and Microsoft C Compiler Versions 5.00 and 5.10
 for MS-DOS.

 When the C code from the example below is compiled and linked into a
 Quick library as shown, the error L2025 is cited multiple times:

    QCL -c -AL signal.c ;     (QuickC)
    CL -c -AL signal.c ;      (C Compiler)

    LINK /Q signal,,,qbxqlb;      (LINK -> QLB in BC7)
    LINK /Q signal,,,bqlb45;      (LINK -> QLB in QB45)

 Code Example
 ------------

 The following code example demonstrates calling the raise() function
 from the SIGNAL.H file in C. When compiled and linked to a QLB as
 listed above, multiple L2025 errors occur:

    #include <signal.h>
    void test()
       {
       printf("SigFPE: %d\n",raise(SIGFPE));   /* Signal float error */
       }

 The following BASIC source demonstrates how to call the above C
 routine:

    DECLARE SUB test CDECL ()
    CALL test

 The above BASIC program compiles and links correctly to an EXE despite
 the fact that it fails to create a usable QLB file. The BASIC compile
 and link lines are as follows:

    BC testsig;
    LINK /NOE testsig+signal;

 The working EXE produces the following output:

    SigFPE: -1


 232. Near Strings Hotkey in Make EXE Dialog Box Does Not Toggle

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900319-29 buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q60136

 In the QBX.EXE editor, the Near Strings hotkey (ALT+N) in the Make EXE
 File dialog box does not move the option marker to the Near Strings
 option -- only the cursor is moved to the option. The arrow keys must
 be used to change this option.

 All other hotkeys -- ALT+F for Far Strings, ALT+A for Alternate Math
 and so on -- move the option marker to the desired option. Only the
 Near Strings hotkey (ALT+N) does not.

 To work around this problem, use the arrow keys to move to the Near
 Strings option. (The arrows can be used for any of the choices.)

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment that comes with Microsoft BASIC Professional Development
 System (PDS) version 7.00. This problem was corrected in QBX.EXE in
 BASIC PDS 7.10.


 233. WIDTH Syntax Correction; WIDTH Parameter Is Required

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900315-50 docerr B_QuickBas
 Last Modified: 15-JAN-1991    ArticleIdent: Q60137

 The following WIDTH statement syntax (taken from the documentation
 listed further below) incorrectly indicates that both "screenwidth%"
 and  ", screenheight%" are optional:

    WIDTH [screenwidth%][, screenheight%]

 According to the above syntax description, "WIDTH" with no parameters
 is a legal statement; however, WIDTH with no arguments correctly
 causes the following error in the QBX.EXE environment:

    Expected: # or LPRINT or expression or ,

 The syntax description for the WIDTH statement should be corrected to
 read as follows:

    WIDTH {screenwidth% | , screenheight% | screenwidth%, screenheight%}

 Note that screenwidth% is measured in columns, and screenheight% is
 measured in lines.

 This correction applies to the WIDTH statement on page 449 of the
 "Microsoft QuickBASIC 4.0: Language Reference" for 4.00 and 4.00b; on
 page 409 of the "Microsoft BASIC 7.0: Language Reference" manual for
 BASIC PDS 7.00 and 7.10; to the WIDTH statement in the QBX.EXE
 Microsoft Advisor online Help system from Microsoft BASIC Professional
 Development System (PDS) version 7.00; and in the QB.EXE QB Advisor
 online Help system from Microsoft QuickBASIC version 4.50.

 This documentation error has been corrected in the QBX.EXE online Help
 in BASIC PDS 7.10.

 The following section of the QBX.EXE online Help system defines the
 notation used for syntax description (in all of the above products):

 [optional item]      Items inside square brackets are optional; you
                      do not have to use them in the statement.

 {choice1 | choice2}  Braces and a vertical bar indicate a choice
                      between two or more items. You must use one of
                      the items in the statement unless the braces
                      are enclosed in square brackets.


 234. Explanation and Example of the NMAKE.EXE Utility

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900314-143
 Last Modified: 20-JUL-1990    ArticleIdent: Q60138

 Microsoft's NMAKE.EXE is a program-maintenance utility. It saves time
 by automating the process of updating project files. NMAKE compares
 the modification dates for one set of files, the target files, to
 those of another file type, the dependent files. If any of the
 dependent files have changed more recently than the target files,
 NMAKE executes a specified series of commands.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and MS OS/2.

 The main purpose of NMAKE is to help you update applications quickly
 and simply. However, it can execute any command, so it is not limited
 to compiling and linking. NMAKE can also make backups, move files, and
 do many other project management tasks.

 NMAKE works by comparing the times and dates of two sets of files,
 which are called "targets" and "dependents":

  - A target file is a file that you want to create, such as an
    executable file.

  - A dependent file is a file used to create a target, such as a BASIC
    source file.

 When you run NMAKE, it reads a "description file" that you supply. The
 description file consists of one or more blocks. Each block lists a
 target, the target-dependents, and the command that builds the target.
 If any dependent has changed more recently than the target, NMAKE
 updates the target by executing the command listed in the block.

 You can invoke NMAKE with the following two options:

 1. Specify options, macro definitions, and the names of targets to be
    built on the DOS or OS/2 command line.

 2. Specify options, macro definitions, and the names to be built in a
    command file, and give the filename on the DOS command line.

 NMAKE accepts a number of command-line options, which are described in
 detail in the Microsoft programmer's guide in Chapter 20.

 NMAKE reads a description file (text file, saved as text only with
 line breaks) to determine what to do. The description file may contain
 any number of description blocks.

 For example, if you have the following three source files that are
 part of the same program

    MAIN.BAS
    FILE1.BAS
    FILE2.BAS

 and if the files through the program-development process need to be
 updated, you would use NMAKE. First, you create the description file
 that will contain the description blocks, as follows:

 #####################COMPILE.MAK##########################

     ALL: Sample.exe
     main.obj: main.bas      #target : dependent
        BC main.bas;         #command field: any DOS command
     file1.obj: file1.bas        #line
        BC file1.bas;
     file2.obj: file2.bas
        BC file2.bas;
     files.lib: file1.obj file2.obj
        LIB files.lib file1.obj + file2.obj

     sample.exe: main.obj files.lib
        LINK main.obj + files.lib, sample.exe;

 ##########################################################

 Then, you invoke NMAKE. The syntax for invoking NMAKE is as follows:

    NMAKE  COMPILE.MAK

 Code Example
 ------------

 MAIN.BAS
 --------

 PRINT "We are in the Main Program"
 CALL file1
 CALL file2
 PRINT "We are DONE!!"

 FILE1.BAS
 ---------

 PRINT "We are in FILE1.BAS "
 SUB file1
   PRINT "We are in the sub of file1.bas"
 END SUB

 FILE2.BAS
 ---------

 PRINT "We are in FILE2.BAS"

 SUB file2
   PRINT "We are in the sub of file2.bas"
 END SUB


 235. LEN Function Returns Wrong Length in LEFT$ in OPEN Statement

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900319-95 buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q60139

 The LEN function in Microsoft BASIC Professional Development System
 (PDS) version 7.00 may return an incorrect string length when used
 within a string function in an OPEN statement. This occurs only when
 the program is compiled with the Far Strings (BC /Fs) option, and
 doesn't occur in the QuickBASIC Extended (QBX.EXE) environment or when
 the program is compiled without the Far Strings option (in other
 words, compiled with the BC.EXE default near strings).

 To work around this problem, use a temporary variable for the result
 of the LEN function and use that result in the string function.

 Microsoft has confirmed this to be a problem with BC /Fs in Microsoft
 BASIC Professional Development System (PDS) version 7.00. This problem
 was corrected in BASIC PDS 7.10.

 This problem occurs because the compiler incorrectly assumes that the
 length will be the first 2 bytes of the descriptor when LEN is used in
 a string function in the OPEN statement. This assumption is correct
 for near strings, but the far string descriptor is different and the
 length must be retrieved in a different manner.

 Code Example
 ------------

 The following are the compile and link lines that reproduce the
 problem in the code example:

    BC LENTEST /Fs;
    LINK LENTEST;

 The following code example OPENs the wrong file on the first OPEN
 statement:

    ' LENTEST.BAS
    tmp$ = "TEST.12X"
    l% = LEN(tmp$)        'Temporary for work-around

    'This should incorrectly create a file named 'TEST.12X'
    OPEN LEFT$(tmp$, LEN(tmp$) - 1) FOR RANDOM AS #1
    CLOSE #1

    'For a workaround, use temporary variable (l%) for LEN(tmp$) and
    'you will get 'TEST.12'
    OPEN LEFT$(tmp$, l% - 1) FOR RANDOM AS #1
    CLOSE #1

 Both OPEN statements in the above code example should open "TEST.12",
 but the first OPEN actually opens "TEST.12X" because the string length
 is returned incorrectly and is thus too large. Subtracting 1 from this
 larger value still leaves the full string to be returned from LEFT$.


 236. HELPMAKE ":p" Option Does Not Work Correctly

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist7.00 buglist7.10 s_utility
 Last Modified: 21-SEP-1990    ArticleIdent: Q60141

 When using the HELPMAKE.EXE utility (for modifying the online Help
 system of QBX.EXE environment), the ":p" command does not work as
 described on Page 681 of the "Microsoft BASIC 7.0: Programmer's
 Guide." The ":p" is described as setting a screen break for the Help
 environment. If ":p" is used, the Help environment behaves as if it
 were not used.

 Microsoft has confirmed this to be a problem with HELPMAKE in
 Microsoft Professional Development System (PDS) versions 7.00 and 7.10
 for MS-DOS. We are researching this problem and will post new
 information here as it becomes available.

 A workaround for this problem is to use the ":ln" command, which is
 also described on Page 681 of the "Microsoft BASIC 7.0: Programmer's
 Guide" for BASIC PDS 7.00 and 7.10. The ":ln" command specifies the
 size of the help window, where "n" is the number of lines. If this
 command is used, the size of the window is n + 1. If you want
 something to show up on the next page, you must have n + 1 number of
 lines before the next page. If this option is not used, the size of
 the window will default to the number of lines in the Help screen + 1,
 with 19 being the maximum number of lines.

 For any of the ":" commands described on Page 681 to take effect,
 HELPMAKE must be invoked with the /Ac option as described on Page 673.

 Note: HELPMAKE.EXE is the Microsoft Help File Maintenance Utility.
 HELPMAKE version 1.04 is shipped with BASIC PDS 7.00, and HELPMAKE
 version 1.05 is shipped with BASIC PDS 7.10.


 237. Configuring M.EXE to Epsilon Format

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900322-11
 Last Modified: 11-JUL-1990    ArticleIdent: Q60142

 This article describes the correct way to set up the Microsoft M
 Editor (M.EXE) to simulate the Epsilon editor environment. The Epsilon
 editor is a text editing utility published by Lugaru Software, which
 emulates EMACS-type editors running on larger computers.

 This article applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00.

 In the BIN directory that Setup installs on the hard drive, there is a
 file called EPSILON.INI. This file contains the keystroke assignments
 necessary to reconfigure the M.EXE Editor. To get this field
 recognized, do one of the following:

 1. Rename the file to TOOLS.INI.

 2. Copy this file into your current TOOLS.INI file.

 Then, make sure that your DOS INIT variable is set to the directory
 that your TOOLS.INI file is located in; for example:

    SET INIT=D:\BC7\BIN

 At the top of the EPSILON.INI file is the clause [M MEP]. This clause
 tells the computer that the following commands should be issued when a
 program called M.EXE or a program called MEP.EXE is executed. If you
 have changed the name of your M Editor, this label should be changed
 to include the current name of the editor.


 238. /FPa, /Lp, and Near Strings Disabled with Quick Library

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900321-16
 Last Modified: 17-JAN-1991    ArticleIdent: Q60143

 If QBX.EXE is invoked with the /L option to load in a Quick library,
 the following compiler options will be disabled when the Make EXE File
 command is chosen from the Run menu:

    Alternate Math        /FPa
    OS/2 Protected Mode   /Lp
    Near Strings

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 A Quick library must be compiled using 80x87 or Emulator Math (/FPi),
 DOS or OS/2 real mode (/Lr), and Far Strings (/FS). Therefore, even if
 BASIC 7.00 or 7.10 is installed to support the Alternate Math library,
 OS/2 protected mode, and Near Strings, these compiler options cannot
 be selected from the Make EXE File menu option when a Quick library is
 loaded.


 239. CHAINing with Additional Variables in COMMON Causes Hang

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q60147

 In a compiled BASIC program, CHAINing from a program that has a
 DYNAMIC variable-length string array in COMMON to a program that has
 an additional variable in COMMON whose length is greater than 530
 bytes will cause the program to either terminate and display an
 "Unprintable Error" message or hang, depending on the version of BASIC
 compiler being used.

 This problem does not occur in the QB.EXE or QBX.EXE editors or when
 the /Fs compiler option is used with Microsoft BASIC Professional
 Development System (PDS) versions 7.00 or 7.10.

 Microsoft has confirmed this to be a problem in Microsoft QuickBASIC
 versions 4.00, 4.00b and 4.50; in Microsoft BASIC Compiler versions
 6.00 and 6.00b for MS-DOS and OS/2; and in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS and OS/2. We are researching this
 problem and will post new information here as it becomes available.

 With BASIC PDS 7.00 or 7.10, the "Unprintable Error" message displays.
 In the other BASICs listed above, the program hangs.

 To duplicate the problem, the following conditions must be met:

 1. The first program must have a dynamic variable-length string array
    in COMMON.

 2. The first program must assign a value to an element of the array.

 3. The second program must have an additional COMMON variable (not in
    the first program's COMMON) with a length greater than 530 bytes.
    This can be either a fixed-length string or a user-defined TYPE.

 4. The second program must assign a value to the additional variable.

 5. Both programs must be compiled with near strings (no /Fs).

 Similarly, to work around the problem, any of the following methods
 can be used:

 1. Make the array $STATIC (DIM before COMMON in both programs).

 2. Put the additional COMMON variable in the COMMON block for the
    first program as well.

 3. Compile both programs with the Far Strings (/Fs) option in BASIC
    PDS 7.00 or 7.10.

 When the programs below are compiled for OS/2 protected mode, the
 problem is almost identical. The only difference in protected mode is
 the size of the additional variable in the COMMON block. The process
 will hang whenever the additional COMMON variable is greater than 20
 bytes (instead of 530 as in DOS). Besides the length of the COMMON
 variable, the conditions and the workarounds (listed above) apply to
 both OS/2 protected mode and DOS (and OS/2 real mode).

 Code Example #1
 ---------------

 The following program CHAINs to Code Example #2, which produces the
 "Unprintable Error" in BASIC PDS 7.00 or 7.10 and hangs in the other
 BASIC versions listed above when compiled as shown:

 'FIRST.BAS compile and LINK lines:
 '    BC FIRST;
 '    LINK FIRST;
 'NOTE: Compiling with the Far Strings option (/FS) corrects problem.

 'DIM VarStrArray(0) AS STRING      'Static array works correctly.
 COMMON VarStrArray() AS STRING
 'More COMMON variables can be added to both without changing
 ' problem.
 COMMON FixStr AS STRING * 531      'Full COMMON in both files works.
 DIM VarStrArray(0) AS STRING       'Dynamic array (any size) fails.
 VarStrArray(0) = "Test"            'Must assign a value to array.
 PRINT "Chaining FIRST->SECOND"
 CHAIN "SECOND"
 END

 Code Example #2
 ---------------

 The following is the CHAINed program, which will terminate and produce
 the "Unprintable Error" or hang (depending on the version of BASIC
 being used) when compiled as shown:

 'SECOND.BAS compile and LINK lines:
 '    BC SECOND;
 '    LINK SECOND;
 'NOTE: Compiling with the Far Strings option (/FS) corrects problem.

 'DIM VarStrArray(0) AS STRING  'Static array works correctly.
 COMMON VarStrArray() AS STRING 'Must be Dynamic string array.
 'More COMMON variables can be added to both without changing problem.
 COMMON FixStr AS STRING * 531  'Must be fixed STRING with LEN > 530

 PRINT "In SECOND"
 FixStr = "Test"                'Assignment to new COMMON var required.
 END


 240. No Space Needed in "/O MY.SRC" in HELPMAKE, Programmer's Guide

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q60220

 Page 673 in the "Microsoft BASIC 7.0: Programmer's Guide" (for
 versions 7.00 and 7.10) incorrectly shows a space between "/O" and
 "MY.SRC" in the following example for decoding a Help database:

    HELPMAKE /V /D /O MY.SRC MY.HLP > MY.LOG

 Using this syntax gives the error ":fatal error H1100: cannot open
 file." The correct syntax is as follows:

    HELPMAKE /V /D /OMY.SRC MY.HLP > MY.LOG

 The sample syntax given on the bottom of Page 672 shows the "/O"
 option as it should be used.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 241. How to Run the CHRTDEMO.BAS Example Program

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900329-119
 Last Modified: 11-APR-1990    ArticleIdent: Q60422

 The CHRTDEMO.BAS example program requires several additional files to
 run properly. If any of these files is not loaded in the QBX.EXE
 environment, the "Subprogram not defined" error occurs. If any of the
 files are left out when LINKing, the "Unresolved external" LINK error
 occurs.

 The steps to set up the files to run CHRTDEMO (for either the QBX.EXE
 environment or as an EXE program) are documented in the banner
 comments at the beginning of CHRTDEMO.BAS.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Version 7.00.

 The following table shows the files required to run the CHRTDEMO
 example program and in which Quick library the modules are contained
 (Note: Assembly modules are contained in each QLB):

    Source File    CHRTBEFR.QLB   UITBEFR.QLB
    -----------    ------------   -----------

    CHRTDEMO.BAS
    CHRTDEM1.BAS
    CHRTDEM2.BAS
    CHRTB.BAS            X
    FONTB.BAS            X
    CHRTASM.ASM          X              X
    FONTASM.ASM          X              X
    UIASM.ASM            X              X
    WINDOW.BAS                          X
    MENU.BAS                            X
    MOUSE.BAS                           X
    GENERAL.BAS                         X

 In addition to the files listed above, expanded memory [with an LIM
 4.0 EMM (Expanded Memory Manager)] is required to run in the QBX.EXE
 environment. In EXE form, the program will run without EMS (expanded
 memory support).

 When running the CHRTDEMO program, you must first enter data through
 the dialog box for the Data option of the View menu. When the program
 begins, the Chart option of the View menu is gray, since there are no
 series to chart. If a chart is requested without data entered in any
 series, the following dialog box message appears:

    No data in series.

 When entering the data, the Series name and Category labels are the
 same for the entire chart, but you must enter a different set of data
 for each series. Thus, the numbers entered in the Values column apply
 only to the currently selected Series. If an unnamed Series is
 selected, the values will be lost when OK is chosen to close the
 dialog box. When OK is chosen with data in an unnamed series, the
 following dialog box message appears:

    Series without names will be deleted upon exit.

 The following banner comment from CHRTDEMO.BAS describes the steps
 (and memory requirements) to run the CHRTDEMO program in either the
 QBX.EXE environment or as an EXE program:

 ' This demo program uses the Presentation Graphics and User
 ' Interface toolboxes to implement a general purpose charting
 ' package.
 '
 ' It consists of three modules (CHRTDEMO.BAS, CHRTDEM1.BAS, and
 ' CHRTDEM2.BAS) and one include file (CHRTDEMO.BI). It requires
 ' access to both the Presentation Graphics and User Interface
 ' toolboxes.
 '
 ' EMS is needed to load and run the demo under QBX. If you do not
 ' have EMS, refer to the command line compile instructions below,
 ' which will allow you to run the demo from the DOS prompt. Running
 ' the demo under QBX requires access to the Presentation Graphics
 ' and User Interface toolboxes. This can be done using one of two
 ' methods:
 '
 '   1. One large Quick library covering both toolboxes can be created.
 '      The library "CHRTDEM.LIB" and Quick library "CHRTDEM.QLB" are
 '      created as follows:
 '
 '         BC /X/FS chrtb.bas;
 '         BC /X/FS fontb.bas;
 '         LIB chrtdem.lib+uitbefr.lib+fontasm+chrtasm+fontb+chrtb;
 '         LINK /Q chrtdem.lib, chrtdem.qlb,,qbxqlb.lib;
 '
 '      Once created, start QBX with this Quick library and load the
 '      demo's modules (CHRTDEMO.BAS, CHRTDEM1.BAS and CHRTDEM2.BAS).
 '
 '   2. Either the Presentation Graphics or User Interface Quick Library
 '      may be used alone provided the other's source code files
 '      are loaded into the QBX environment. If CHRTBEFR.QLB is
 '      is used, then WINDOW.BAS, GENERAL.BAS, MENU.BAS, and MOUSE.BAS
 '      must be loaded. If UITBEFR.QLB is used, then CHRTB.BAS and
 '      FONTB.BAS must be loaded. Once a Quick Library is specified and
 '      all necessary source files are loaded, load the program
 '      modules (CHRTDEMO.BAS, CHRTDEM1.BAS and CHRTDEM2.BAS).
 '
 ' To create a compiled version of the chart demo program, perform the
 ' following steps:
 '
 '   BC /X/FS chrtb.bas;
 '   BC /X/FS fontb.bas;
 '   LIB chrtdem.lib + uitbefr.lib + fontasm + chrtasm + fontb
 '                   + chrtb;
 '   BC /X/FS chrtdemo.bas;
 '   BC /FS chrtdem1.bas;
 '   BC /FS chrtdem2.bas;
 '   LINK /EX chrtdemo chrtdem1 chrtdem2, chrtdemo.exe,, chrtdem.lib;
 '
 ' "CHRTDEMO" can now be run from the command line.


 242. Unresolved External Making Quick Library from CHRTB.BAS

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900402-93 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q60425

 The CHRTB.BAS file contains BASIC source code for the Presentation
 Graphics Toolbox Chart Routines.

 At the beginning of this file, there are instructions for creating a
 library and Quick library that contain the charting routines found in
 CHRTB.BAS. However, numerous unresolved external link errors (L2029)
 will be produced unless alterations are made to these instructions.

 This documentation error occurs in the CHRTB.BAS file in Microsoft
 BASIC Professional Development System (PDS) Versions 7.00 and 7.10 for
 MS-DOS.

 Since CHRTB.BAS makes calls to routines found in the Fonts Toolbox,
 FONTB.OBJ and FONTASM.OBJ must be included when making a library or
 Quick library out of CHRTB.BAS. These two files were mistakenly
 omitted from the instructions found in the CHRTB.BAS file.

 The correct method of creating a library and Quick library containing
 the charting routines found in CHRTB.BAS is as follows:

    BC /X /FS chrtb.bas
    BC /X /FS fontb.bas
    LIB chrtb.lib +chrtb+chrtasm+fontb+fontasm+qbx.lib;
    LINK /Q chrtb.lib, chrtb.qlb,,qbxqlb.lib;

 If the charting routines are going to be used in conjunction with the
 User Interface Toolbox source code (GENERAL.BAS, WINDOW.BAS, MENU.BAS,
 and MOUSE.BAS), the library should instead be created in the following
 manner:

    LIB chrtb.lib +chrtb+chrtasm+uiasm+fontb+fontasm+qbx.lib;


 243. TSCNIOxx.OBJ Stub Files Remove COLOR Border Parameter

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900327-66
 Last Modified: 20-APR-1990    ArticleIdent: Q60851

 When a Microsoft BASIC Professional Development System (PDS) Version
 7.00 program is linked with one of the TSCNIOxx.OBJ stub files, most
 graphics statements and functions are stubbed out. When a program that
 has been linked in this manner attempts to use the "border" parameter
 syntax of the COLOR statement, the run-time error "Feature
 unavailable" should be generated. This is because the border parameter
 syntax support is contained in the graphics portion of the BASIC
 run-time module and this is removed, or stubbed, during LINK time.

 The syntax for the COLOR statement that applies here is as follows:

    COLOR [foreground][,background][,border]

 This statement is only supported on a CGA graphics adapter in SCREEN 0.


 244. Passing Far Strings to C Using StringAddress and StringLength

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900328-95
 Last Modified: 19-APR-1990    ArticleIdent: Q60852

 Programs compiled with the /Fs option, functions and procedures
 (compiled with /Fs) in a Quick library, and programs designed to run
 under the QuickBASIC Extended (QBX.EXE) environment now need to handle
 strings passed to non-BASIC routines differently.

 The following program demonstrates how to pass a variable-length far
 string to a Microsoft C function using the BASIC run-time routines
 StringAddress and StringLength. These routines are necessary to obtain
 the string's far address and length.

 Code Example
 ------------

 '----------- Here is the file TESTB.BAS
 DECLARE SUB TestC CDECL (A$)
 A$ = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" + CHR$(0)
                 'Add Hex 0 at the end for the C printf function
 CLS : PRINT : PRINT
 PRINT "BASIC: "; A$
 PRINT "Len: "; LEN(A$)
 PRINT
 CALL TestC(A$)
 LOCATE CSRLIN + 3
 PRINT "Back in BASIC"
 SYSTEM

 /* ---------- Here is the file TESTC.C
 extern char far * pascal StringAddress(long near *);
 extern int pascal StringLength(long near *);

 void TestC (long near * Desc)
 {
   int  len;
   char far *segadd;

   len = StringLength( Desc );
   segadd = StringAddress( Desc );
   printf("C: %s\n", segadd);
   printf("Len: %i\n", len);
 }

 Compile and link options, as follows:

    BC /o TESTB;
    CL -c -AM TESTC.C
    LINK /noe TESTB TESTC;

 The output should from this program should be as follows:

    BASIC: ABCDEFGHIJKLMNOPQRSTUVWXYZ
    Len: 27

    C: ABCDEFGHIJKLMNOPQRSTUVWXYZ
    Len: 27

    Back in BASIC


 245. Floating-Point Bench Marks: QB vs BC6 vs PDS, /FPi vs /FPa

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900403-121 B_QuickBas
 Last Modified: 19-APR-1990    ArticleIdent: Q60858

 This article provides some informal benchmarks for various versions of
 Microsoft BASIC. It demonstrates the speed differences between them
 using certain mathematic operations with different versions of BASIC
 and different math packages. The data listed below was generated on a
 Wyse 386 16 MHz PC without a coprocessor.

 This information applies to Microsoft QuickBASIC Version 4.50,
 Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS and OS/2,
 and Microsoft BASIC Professional Development System (PDS) Version 7.00
 for MS-DOS and OS/2.

 The emulator (/FPi) is a math package that uses software to emulate
 the floating-point coprocessor functions as closely as possible when a
 coprocessor is not present. The alternate math package (/FPa) is
 another method of emulating the coprocessor functions. The main
 difference is that the emulator always uses an 80-bit temporary work
 area (to emulate the coprocessor's 80-bit register), whereas the
 alternate math package uses a smaller temporary storage area for most
 operations. The alternate math package can generate significantly
 faster code, but at a loss of precision for floating-point
 calculations.

 QuickBASIC uses only the emulator math (EM) package (/FPi). The
 alternate math package is not available with QuickBASIC, but is
 available with BASIC compiler 6.00 and 6.00b and BASIC PDS 7.00.

 The following table gives the times for the various operations in the
 program listed below (these operations were performed 10,000 times on
 a 386/16 MHz):

    10,000        PDS 7.00       BC 6.00b       BC 6.00       QB 4.50
    Operations  /FPi    /FPa   /FPi    /FPa   /FPi    /FPa   (EM only)
    ----------  ------------   ------------   ------------   ---------

    empty loop   3.19   1.87   3.91    1.21   3.94    1.22   3.56
    J#=I#+I#     4.53   1.84   5.78    1.84   5.78    1.85   5.15
    J#=I#*I#     4.72   2.03   5.97    2.12   5.91    2.03   5.19
    J#=I#^2     33.91   3.68  46.32    3.81  45.47    3.72  42.31
    J#=I#^.5    33.93  29.34  46.50   30.57  45.66   29.47  42.63
    J#=SQR(I#)   5.57   3.25   6.84    3.40   6.71    3.28   6.00
    J#=COS(I#)  16.87  15.90  31.44   16.22  31.47   16.15  29.94

 Please note the following about the above table:

 1. Any exponents are slow in the emulator. Equivalent multiplication
    is much faster for small cases.

 2. Fractional exponents are almost as slow with the alternate math
    package as the emulator. The times for other noninteger exponents
    are similarly slow with the alternate math package. Note that SQR
    is much faster than raising to the .5 exponent.

 3. BASIC PDS 7.00 greatly improves the emulator speed for many of the
    operations (COS, exponentiation) over previous versions. Since the
    alternate math package doesn't have the same factor of improvement,
    the emulator runs closer to the alternate package for many
    operations in BASIC PDS 7.00.

 4. The time of execution for most operations using /FPa in PDS 7.00 is
    40-60 percent of the time with /FPi in PDS 7.00.

 Code Example
 ------------

 The following code example demonstrates the times of various
 operations using the different versions of BASIC:

    'Compile and link lines for emulator (only mode for QuickBASIC):
    '
    ' BC /O BENCH.BAS;
    ' LINK BENCH;
    '
    'Compile and link for alternate math in BASIC compiler and PDS:
    '
    ' BC /O /FPa BENCH.BAS;
    ' LINK BENCH;
    orig = TIMER
    FOR I# = 1 TO 10000
    NEXT
    PRINT "Empty loop:"; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = I# + I#
    NEXT
    PRINT "J#=I#+I#:"; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = I# * I#
    NEXT
    PRINT "J#=I#*I#:"; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = I# ^ 2
    NEXT
    PRINT "J#=I#^2: "; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = I# ^ .5
    NEXT
    PRINT "J#=I#^.5: "; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = SQR(I#)
    NEXT
    PRINT "J#=SQR(I#):"; TIMER - orig

    orig = TIMER
    FOR I# = 1 TO 10000
    J# = COS(I#)
    NEXT
    PRINT "J#=COS(I#): "; TIMER - orig
    END


 246. Vectored Fonts Not Usable in BASIC PDS 7.00

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900408-2 bit map
 Last Modified: 21-SEP-1990    ArticleIdent: Q60859

 The font files MODERN.FON, SCRIPT.FON, and ROMAN.FON from Microsoft
 Windows/286 and Microsoft Windows/386 cannot be used with the
 Microsoft BASIC Professional Development System (PDS) version 7.00 or
 7.10 font toolbox.

 The "Microsoft BASIC 7.0: Language Reference" manual correctly states
 on Page 518 that the font toolbox supplied with BASIC PDS 7.00 works
 with any standard Windows bitmap .FON file. However, the files
 MODERN.FON, SCRIPT.FON, and ROMAN.FON are vectored fonts, not
 bitmapped fonts. The BASIC PDS font toolbox will use the rest of the
 fonts supplied with Windows/286 or Windows/386 without any problem.

 The difference between bitmapped and vectored fonts is that bitmapped
 fonts are fixed in size and shape. To get a different-sized font, you
 must use a different bitmap for each character. Vectored fonts, also
 called scalable or resizeable fonts, are actually made up of
 instructions for drawing the different characters. As a result, you
 can easily resize the figures.

 The same .FON files are supplied with Windows/286 and Windows/386.

 The message "Bad Font File" will be generated by the BASIC PDS font
 toolbox if it cannot use a specific font.


 247. CommandKeySet Subprogram Should Be ShortCutKeySet

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900410-29 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q60860

 Page 549 of the "Microsoft BASIC 7.0: Language Reference" (for 7.00
 and 7.10) incorrectly refers to the CommandKeySet SUBprogram where it
 should refer to the ShortCutKeySet SUBprogram.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) Versions 7.00 and 7.10 for MS-DOS.


 248. Problem When Using Integer Array and FOR Loop in BASIC 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900411-147 buglist7.00 fixlist7.10
 Last Modified:  1-AUG-1990    ArticleIdent: Q60965

 The code example below shows a case where using an integer variable
 for a FOR loop-counter can produce incorrect results in a compiled
 BASIC program. The program must have the following elements to
 reproduce the problem:

 1. The program must contain a simple FOR loop (not nested, etc.).

 2. The FOR loop must contain a call to the INT function.

 3. The upper bound of the FOR loop must be specified with a
    variable, not a literal.

 4. The loop-counter variable and upper-bound variable must be
    integers.

 The code example below demonstrates these conditions and prints out
 the value of the loop counter each time it loops. In a compiled BASIC
 program, this example always prints the upper bound of the loop
 counter.

 Microsoft has confirmed this to be a problem in the BC.EXE compiler
 that comes with Microsoft BASIC Professional Development System (PDS)
 version 7.00 for MS-DOS and MS OS/2. This problem was corrected in
 BASIC PDS version 7.10.

 This problem does not occur in QBX.EXE (the QuickBASIC extended
 environment that comes with BASIC PDS 7.00). This problem also does
 not occur in the BC.EXE or QB.EXE environments that come with
 QuickBASIC versions 4.00, 4.00b, or 4.50.

 Any of the following workarounds corrects the problem:

 1. Compile with the BC /X option.

 2. Compile with the BC /FPa option.

 3. Change the DEFINT statement to DEFtype, where "type" is anything
    but INT (integer).

 4. Change the upper bound on the FOR-LOOP to a literal.

 Code Example
 ------------

 DEFINT A-Z                    'Change to something other than INT
                               'or remove the line
 DIM test(4)
 temp = 4
 FOR k = 1 TO temp             'Use 4 instead of temp.
    PRINT k                    'In a compiled program, this line
                               'always prints the upper bound
                               'of the FOR-LOOP.
    test(k) = INT(1.0)         'Remove the INT function CALL.
 NEXT k

 The following is the output in the QBX.EXE environment (correct):

    1
    2
    3
    4

 The following is the output from a compiled 7.00 .EXE program
 (incorrect):

    4
    4
    4
    4


 249. QBX.EXE 7.10 Expanded Memory Usage Better Than 7.00; 32K Table

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900228-5
 Last Modified: 10-AUG-1990    ArticleIdent: Q60968

 The QuickBASIC Extended environment (QBX.EXE) can use up to 16 MB
 (megabytes) of Lotus-Intel-Microsoft (LIM) 4.0 expanded memory
 under MS-DOS. If the expanded memory is available, QBX.EXE
 automatically stores in it SUBs, FUNCTIONs, and module-level code
 units that are no greater than 16K in size. If QBX.EXE is invoked with
 the /Ea switch, arrays that are no greater than 16K in size are also
 stored in expanded memory.

 In QBX.EXE in BASIC PDS version 7.00, the memory is allocated in 16K
 pages; for example, a 2K procedure consumes 16K and wastes 14K (16K
 minus 2K) of expanded memory. Also, when one or more SUBs or FUNCTIONs
 are stored in expanded memory, QBX.EXE makes a one-time allocation of
 32K (two 16K pages) in expanded memory as overhead for its own
 internal tables.

 QBX.EXE in BASIC PDS version 7.10 is enhanced so that memory is
 allocated in 1K pages; for example, a 1K procedure or array takes up
 1K, thus using expanded memory much more efficiently than in QBX.EXE
 7.00.

 This article applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 Examples of Expanded Memory Usage in QBX.EXE 7.00
 -------------------------------------------------

 As an example for BASIC PDS 7.00, suppose QBX.EXE is run on a machine
 for which FRE(-3) reports that 2720K of expanded memory is available.
 When the first module-level statement is entered, FRE(-3) would then
 return 2704K, 16K less. When the first SUB or FUNCTION is created
 after that, FRE(-3) would return 2656K, 48K less -- 16K for the SUB or
 FUNCTION itself and 32K for QBX.EXE's internal tables.

 When SUBs, FUNCTIONs, module-level code units, or arrays (if /Ea is
 used) are deleted, QBX.EXE deallocates the expanded memory they were
 using. The tables, however, will not be deallocated unless New Program
 is chosen from the File menu.

 In 7.00, a single-element integer array takes the same expanded memory
 space (16K) as an array with 8192 elements. Likewise, a SUB with a
 single PRINT statement takes the same space (16K) as a large SUB with
 hundreds of statements. (This is no longer true in 7.10, where
 expanded memory usage is more efficient.)

 To use expanded memory to its best potential in the QBX.EXE 7.00
 environment, you should try to make your SUBs as close to the 16K
 limit as possible without exceeding it. (This is not necessary in
 7.10.) The size of the SUBs (in kilobytes) is listed in the View Subs
 (F2) dialog box to the right of each SUB.

 Likewise, arrays in QBX.EXE 7.00 will use expanded memory more
 efficiently if they are dimensioned to be just under the 16K page
 size. (This is not necessary in 7.10.)

 References:

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 offer expanded memory support under the Lotus-Intel-Microsoft
 version 4.0 Expanded Memory Specification (LIM 4.0 EMS) for code and
 data in the QBX.EXE environment under MS-DOS. Earlier versions do not
 offer any expanded memory support. LIM 4.0 EMS support is discussed in
 the "Microsoft BASIC 7.0: Getting Started" manual and in the
 "Microsoft BASIC 7.1: Getting Started" manual.

 To be compatible with BASIC PDS 7.00 or 7.10, the expanded-memory
 device driver must observe the LIM 4.0 EMS.


 250. NMAKE Example Using ALL, Pseudotarget and Macros

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900319-89
 Last Modified: 14-MAY-1990    ArticleIdent: Q60969

 NMAKE works by comparing the dates and times of two sets of files,
 which are called "targets" and "dependents." A target is a file that
 you want to create, such as an executable file. A dependent is a file
 used to create a target, such as a BASIC source file. If any dependent
 has changed more recently than the target, NMAKE updates the target by
 executing the command listed in the block.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and MS OS/2.

 The pseudotarget is a name that serves as a "handle" for building a
 group of files or executing a group of commands. In the following
 example, ALL is the pseudotarget. After ALL, you would list all the
 EXE files that you want to create with this NMAKE file.

 Inference rules are templates that NMAKE uses to generate files with a
 given extension. When NMAKE encounters a description block with no
 commands, it looks for an inference rule that specifies how to create
 the target from the dependent files, given the two file extensions.
 Inference rules eliminate the need to put the same commands in several
 description blocks. In this example, the inference rules are to
 compile BASIC source files with no options and also to link the files
 with no linker options. If you wanted to specify compiler options (for
 example, /W, /X, etc.), you must include the command line "BC
 myprog.bas /X ;" in your description block for myprog.obj :
 myprog.bas.

 The OBJS statement in the description block for mymain2 is called a
 macro. Macros provide a convenient way to replace a string in the
 description file with another string. This statement is telling NMAKE
 that MYLIB.LIB is made up of these object files. The "!" on the LIB
 command is a repetition modifier that tells NMAKE to repeat the
 command as many times as it needs for dependents that are out of date
 with respect to the target. If both members of the library were
 updated, they would both be compiled and the library would be
 incrementally updated. The following commands would be executed:

    lib mylib.lib -+ libsub.obj ;
    lib mylib.lib -+ libsub2.obj ;

 The library could also contain modules written in assembler or C. You
 would need to add an assemble or C compile line, either as an
 inference rule or specifically to the module's description block. For
 example, the inference rules for a C compile and a MASM assemble would
 be as follows:

    .c.obj:
       cl /c $?

    .asm.obj:
       masm $? ;

 The following is a sample NMAKE description file, MYMAKE.MAK, which
 compiles and links two programs. The first is a main module and a
 subprogram, and the second is a main module with a library containing
 two members. To execute the description file, type the following:

    NMAKE MYMAKE.MAK

 Code Example
 ------------

 #----------------MYMAKE.MAK-------------------

 #----------pseudotarget

 ALL : mymain.exe mymain2.exe

 #----------inference rules

 .BAS.OBJ:
    BC $< ;

 .OBJ.EXE:
    LINK $** ;

 #----------mymain description block

 # target : dependent
 mymain.obj : mymain.bas  # (these will use inference rules
 mysub.obj : mysub.bas    #  to compile and link)
 mymain.exe : mymain.obj mysub.obj

 #----------mymain2 description block

 mymain2.obj : mymain2.bas
     BC mymain2.bas /X ;    # (this command used for compile)

 libsub.obj : libsub.bas    # (these will use the inference
 libsub2.obj : libsub2.bas  #  rules for compiling)

 OBJS = libsub.obj libsub2.obj

 mylib.lib : $(OBJS)
       !lib mylib.lib -+ $?;

 mymain2.exe : mymain2.obj mylib.lib   # (this uses inference
                                       #  rule for linking)


 251. BASIC PDS 7.00 Not Compatible with C PDS Version 6.00

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# S900415-6 B_QuickBas S_C S_QuickC
 Last Modified: 18-OCT-1990    ArticleIdent: Q61337

 Microsoft BASIC Professional Development System (PDS) version 7.00,
 QuickBASIC version 4.50, and earlier versions of BASIC are not
 compatible with Microsoft C Professional Development System version
 6.00 or Microsoft QuickC version 2.50 or 2.51. You must obtain BASIC
 PDS 7.10 to be compatible with these versions of C and QuickC.

 Below are some of the LINK L2025 errors that can occur when you LINK
 an incompatible BASIC version with Microsoft C PDS version 6.00:

    E:\C600\LIB\MLIBCE.LIB(chkstk.asm) : error L2025: STKHQQ : symbol
     defined more than once

    E:\C600\LIB\MLIBCE.LIB(chkstk.asm) : error L2025: __aaltstkovr :
     symbol defined more than once

    E:\C600\LIB\MLIBCE.LIB(chkstk.asm) : error L2025: __chkstk :
     symbol defined more than once

 This information applies to Microsoft QuickBASIC versions 4.00, 4.00b,
 and 4.50 for MS-DOS, to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS, and to Microsoft BASIC PDS version 7.00 for MS-DOS
 and MS OS/2.

 A separate article, found by querying in this Knowledge Base using the
 following words, describes which specific Microsoft language compiler
 versions are designed to be linked together:

    BASIC and C and QuickC and calling and linked and modules

 For more specific information about how to do mixed-language
 programming with Microsoft C and Microsoft BASIC, query in this
 Knowledge Base on the following word:

    BAS2C

 Microsoft C PDS version 6.00 and Microsoft QuickC versions 2.50 and
 2.51 use different start-up and heap management code than previous
 versions of C and QuickC. Since the BASIC libraries must be put first
 on the LINK line, the BASIC libraries supply alternate start-up, heap,
 and low-level I/O code for the LINKed C routines. These alternate
 routines are specific to the versions of C available when the BASIC
 products shipped.

 Each version of BASIC is tested and designed to work with the versions
 of Microsoft C and QuickC currently on the market when the BASIC
 package is released. Incompatibilities caused by new releases of C and
 QuickC are resolved whenever an updated BASIC product ships.

 To find a separate article in this Knowledge Base that describes the /Gh
 option (which makes C 6.00 use the C 5.10 libraries, for Microsoft
 Windows 2.x compatibility), as mentioned in the C 6.00 README.DOC
 file, query on the following words:

    /Gh and 6.00 and 5.10 and C and library and compatibility

 However, BASIC PDS 7.00 and QuickBASIC 4.50 (and earlier versions) are
 not compatible with routines compiled with C 6.00, even when the C
 6.00 /Gh option is used.


 252. Docerr in MenuSet and MenuSetState in UI Toolbox of PDS 7.00

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900412-65 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q61338

 Pages 546 and 547 of the "Microsoft BASIC 7.0: Language Reference" for
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 incorrectly state that the subroutine MenuSetState treats -1
 as a legal value for the parameter state%. The lowest legal value for
 state% is 0. This is the scope of the MenuSetState routine. The
 MenuSet subroutine should be called to remove an item from a menu.

 The MenuSet subroutine, on Pages 545 and 546 of the same manual, is
 also documented incorrectly because the lowest legal value of MenuSet
 is actually -1, not 0. To make a menu item or menu title disappear,
 you must call MenuSet with state% equal to -1.


 253. Problem When Using IMP with a Variable and a Literal

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10 B_QuickBas
 Last Modified: 21-SEP-1990    ArticleIdent: Q61339

 The code example below using the IMP logical-implication operator
 incorrectly prints -1 when compiled with the BC.EXE environment of
 Microsoft BASIC Professional Development System (PDS) version 7.00 or
 7.10. When executed in the QBX.EXE (QuickBASIC Extended) environment,
 the correct answer of 0 (zero) prints.

 The only workaround is to change the -1 to a variable or change i% in
 the PRINT statement to a 0 (zero).

 Microsoft has confirmed this to be a problem in the BC.EXE environment
 of Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS and MS OS/2; in the BC.EXE environment of
 Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00,
 buglist4.00b, buglist4.50) for MS-DOS; and in the BC.EXE environment
 of Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS
 OS/2. We are researching this problem and will post new information
 here as it becomes available.

 For your information, the following definition of IMP is taken from
 the Microsoft Advisor online Help system in QBX.EXE:

 HELP: IMP Operator
 ------------------

    result = numeric - expression1 IMP numeric - expression2

 The logical-implication operator, IMP, compares corresponding bits in
 numeric-expression1 and numeric-expression2, and then sets the
 corresponding bit in the result according to the following table:

    Bit in first expression   Bit in second expression   Bit in result
    -----------------------   ------------------------   -------------
                 1                          1                    1
                 1                          0                    0
                 0                          1                    1
                 0                          0                    1

 Code Example
 ------------

    DEFINT A-Z
    i% = 0
    PRINT -1 IMP i%

 If a variable is used in the place of the -1 or the i% is replaced
 with a 0, then this program prints the correct answer of 0.

 Note that the constant -1 is stored internally (in two's complement
 signed binary integer format) with all 16 bits set equal to 1 (on).
 The constant 0, when stored in an integer variable, is stored with all
 16 bits set equal to 0 (off).


 254. CodeView Does Not Support the BASIC CHAIN Statement

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S900415-4 B_QuickBas S_CodeView CV CVP
 Last Modified:  4-SEP-1990    ArticleIdent: Q61341

 Versions 2.20, 2.30, 2.35, and 3.10 of the Microsoft CodeView debugger
 do not support the BASIC CHAIN command. When a program is CHAINed in
 BASIC, CodeView executes the entire CHAINed-to program and will not
 allow it to be single-stepped through.

 This information applies to Microsoft QuickBASIC versions 4.00, 4.00b,
 and 4.50 for MS-DOS; to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS and MS OS/2; and to Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for MS-DOS and MS
 OS/2.

 The CHAIN command is unique to BASIC and is not supported by the
 CodeView debugger. CodeView is a mixed-language source code debugger
 supplied with BASIC compiler versions 6.00 and 6.00b and BASIC PDS
 versions 7.00 and 7.10. CodeView is NOT shipped with QuickBASIC 4.00,
 4.00b, or 4.50 for MS-DOS.

 The following table lists which versions of CodeView are shipped with
 which versions of BASIC:

    BASIC Version      Is Shipped with CodeView Version
    -------------      --------------------------------

    6.00               2.20
    6.00b              2.30
    7.00               2.35
    7.10               3.10

 Note: CV.EXE is the CodeView utility for MS-DOS. CVP.EXE is the
 CodeView utility for MS OS/2.


 255. Description for L2043 in BASIC PDS 7.00 Manual Incorrect

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr SR# S900415-3
 Last Modified:  8-JAN-1991    ArticleIdent: Q61342

 Page 689 of the "Microsoft BASIC 7.0: Language Reference" for
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 incorrectly states for LINKer error message L2043 that the
 module QUICKLIB.OBJ was missing. This should be changed to say that
 the module QBXQLB.LIB was missing.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS.

 The description on Page 689 for the LINKer error message L2043 is
 incorrectly given as follows:

    L2043    Quick Library support module missing

             The required module QUICKLIB.OBJ was missing.

             The module QUICKLIB.OBJ must be linked when creating a
             Quick library.

 The correct explanation is as follows:

    L2043    Quick Library support module missing

             The required module QBXQLB.OBJ was missing.

             The module QBXQLB.OBJ must be linked when creating a
             Quick library.


 256. ON ERROR GOTO 0 in BASIC PDS Won't Give Error Line's Address

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900415-2
 Last Modified: 15-JAN-1991    ArticleIdent: Q61343

 Because of new flexibility added to the ON ERROR GOTO handling in
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10, the address given when an .EXE program aborts from within an
 error handler may not be the actual address of the line that produced
 the error.

 If error trapping is turned on, an error occurs, and an ON ERROR GOTO
 0 or ERROR ERR statement is used in the error handler to abort the
 program, then the address of the ON ERROR GOTO 0 or ERROR ERR line
 displays when the program stops. This behavior differs from .EXE
 programs compiled in previous versions of BASIC (including QuickBASIC
 4.x and BASIC compiler 6.00 and 6.00b), which return the address of
 the line that originally caused the error.

 This information applies to .EXE programs compiled in Microsoft BASIC
 PDS versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Because BASIC PDS versions 7.00 and 7.10 allow errors generated in a
 module's error handler to be trapped in another module's error
 handler, the compiler must generate the address of the ON ERROR GOTO
 0 (or ERROR ERR) line. Otherwise, if the error were transferred to
 another error handler that did a RESUME NEXT, the program would not
 resume to the error handler, but to the user code (because that is the
 address the compiler would have passed to it). This leaves the error
 handler still on the stack. If this occurred multiple times, the
 program would eventually run out of stack space.

 Note that the QB.EXE interpreter environment found in QuickBASIC 4.x
 and BASIC compiler 6.00/6.00b treats an ON ERROR GOTO 0 in an error
 handler as if it were an ERROR ERR, causing QB.EXE to stop the program
 and flag the error on the ON ERROR GOTO 0 line. However, the BC.EXE
 compiler in these products goes to the extra work of making .EXE
 programs that report the error back where the error originally
 occurred.

 The following program, ERR.BAS, when compiled using BC.EXE from BASIC
 PDS version 7.00 or 7.10, will abort with an error and display the
 address of the ON ERROR GOTO 0 line. Compile and LINK as follows:

    BC /x ERR.BAS,,ERR.LST;
    LINK ERR ;

 The following is ERR.BAS:

    ON ERROR GOTO handler
    y = 0
    x = 1/y
    END

    handler:
       ON ERROR GOTO 0
       RESUME

 In BASIC PDS version 7.00 or 7.10, when the program aborts, the
 following error message is given (note: the address given will be
 different on different machines):

    Division by zero in line 0 of module ERR      at address 23E5:0066

 Looking at the following listing file (ERR.LST) produced by the
 compiler shows that the address given when the program stops in error
 is that of the ON ERROR GOTO 0 line:

    0030   0006
    0030   0006            ON ERROR GOTO handler
    003A   0006            y = 0
    0046   000A            x = 1/y
    0057   000E            end
    005C   000E            handler:
    005C   000E               ON ERROR GOTO 0
    0066   000E               RESUME
    006B   000E
    008E   000E

 The address given (0066) shows as the RESUME statement. This is
 because the error occurs at the end of the ON ERROR GOTO 0 statement,
 which is the starting address of the RESUME statement line. In .EXE
 programs compiled in versions of BASIC earlier than 7.00, the address
 given was of the actual line that the error occurred on (the line at
 address 0046: x = 1/y).

 The address given in a program without ON ERROR trapping active is
 still the address of the actual error line, x = 1/y, in BASIC 7.00 and
 7.10 (and earlier versions of BC.EXE).


 257. Differences Between FormatX$ Functions & PRINT USING Statement

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900305-84
 Last Modified: 27-JUL-1990    ArticleIdent: Q61345

 This article demonstrates the differences between the FormatX$
 Add-On-Library (DTFMTxx.LIB) functions and the BASIC PRINT USING
 statement, specifically in the case of the "#" character.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2. FormatX$
 refers to the Add-On-Library functions FormatI$, FormatL$, FormatS$,
 FormatD$, and FormatC$ found in BASIC PDS 7.00 and 7.10.

 In the PRINT USING statement, the # sign is used in the string
 identifier to specify a digit placeholder. If there isn't a digit in
 that location, a space is put in its place. In the FormatX$ functions,
 the # is also a placeholder. However, if there isn't a digit, the
 location is not padded with a space.

 The FormatX$ functions can be invoked from within the QB.EXE
 environment by installing the DTFMTER.QLB Quick library. These
 functions can be invoked from .EXE programs by linking in the
 appropriate DTFMTxx.LIB library.

 The FUNCTION declarations necessary for the FormatX$ functions are
 contained in the FORMAT.BI include file, which can be included in your
 source file as follows:

    REM $INCLUDE:'FORMAT.BI'

 The syntax for the FormatX$ function(s) is as follows

    FORMATx$ (Variable, fmt$)

 where:

 1. "x" is the first letter of the data type being manipulated:

       Data Type           Syntax
       ---------           ------

       Integer             FORMATI$
       Long integer        FORMATL$
       Single precision    FORMATS$
       Double precision    FORMATD$
       Currency            FORMATC$

 2. "Variable" is the variable to be manipulated.

 3. "fmt$" is a string expression defining the output format.

 The format for the PRINT USING statement is as follows

    PRINT USING fmt$; Variable [,Variable2...][,|;]

 where:

 1. "fmt$" is a string expression defining the output format.

 2. "Variable" is an expression(s) to be manipulated.

 3. "," or ";" are optional output choices to print next output
    immediately following. (Note that PRINT USING does not support
    "print zones.")

 The following code example demonstrates the difference in the #
 operand in the fmt$ argument for FORMATX$ versus PRINT USING:

    ' $INCLUDE: 'FORMAT.BI'
    A = 123.456
    B = 88.99

    ' ------  PRINT USING STATEMENTS:
    PRINT USING "#####.##";A
    PRINT USING "######.###";B
    PRINT

    ' ------  FORMATX$ STATEMENTS:
    PRINT FORMATS$(A,"#####.##")
    PRINT FORMATS$(B,"######.###";B
    END

 The output will resemble the following:

      123.46
        88.990

    123.46
    88.99


 258. Dynamic Array Using INT in FOR Loop Returns Bad Results

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900409-113 buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q61346

 Assigning values to a dynamic array using the INT function in a FOR
 loop that contains a variable for the maximum index can produce
 incorrect results when compiled. The problem seems to be an addressing
 problem where all array values contain the result of the last
 computation.

 Microsoft has confirmed this to be a problem in the BC.EXE environment
 of Microsoft BASIC Professional Development System (PDS) version 7.00.
 This problem was corrected in BASIC PDS 7.10. This problem does not
 occur in the QBX.EXE editor in 7.00, or in earlier versions of
 Microsoft QuickBASIC or Microsoft BASIC Compiler.

 Any of the following workarounds will correct this problem:

 1. Compile with the BC /D compiler option.
 2. Use a static array.
 3. Use a temporary variable for the function value.
 4. Use a literal to define the FOR loop.

 Code Example
 ------------

 The following code example demonstrates the problem:

    'Compile and link lines:
    '
    ' BC FORARRAY;               NOTE: The BC /D compiler option
    '                                  corrects the problem.
    ' LINK FORARRAY;
    DEFINT A-Z                   'Any numeric type shows problem.
    n = 1                        'n=1 is required for FOR upper index.
    DIM a(n)                   'Array must be dynamic to show problem.
    a(0) = 1
    a(1) = 2
    FOR i = 0 TO n               'Variable n required to cause problem.
       a(i) = INT(a(i))          'INT or FIX functions cause problem.
       PRINT a(i)       'Incorrectly prints 2 for each iteration; it
                        'should have printed 1, then 2.
    NEXT
    END

 When compiled without /D, the above program displays the following
 incorrect results:

    2
    2

 When run in the QBX.EXE editor or compiled with /D option, the above
 program displays the following correct results:

    1
    2


 259. BASIC PDS 7.00 "Program Memory Overflow" with Too Many CONST

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900329-74
 Last Modified: 27-JUL-1990    ArticleIdent: Q61349

 When used with the /V switch, the BC.EXE compiler that comes with
 Microsoft BASIC Professional Development System (PDS) version 7.00
 produces a "Program memory overflow" error when compiling a program
 that has approximately 680+ CONSTants. The compiler can still have up
 to 13K "bytes free" of compiler workspace when reporting this error.

 "Program memory overflow" also occurs when compiling the TEST1.BAS
 program generated below using 756+ CONSTants with the BC /Fs (far
 strings) option.

 The CONST limits are improved in BASIC PDS version 7.10, which can
 handle significantly more CONSTants than BASIC 7.00.

 The error message "Program memory overflow" is misleading because
 normally the compiler only gives that error when more than 64K of code
 has been generated for the module being compiled. This error
 represents a limitation of the compiler. This error is generated when
 the number of CONSTants that can be included in a BASIC module has
 been exceeded.

 The "Program memory overflow" error above is due to the amount of
 internal overhead that the compiler sets aside to do its work with
 CONSTants. The error message is not generated because of a lack of
 compiler workspace. In this case, 13K "bytes free" is a valid number.
 There is actually 13K of compiler workspace free. A different
 limitation has been encountered -- the number of CONSTants BC.EXE can
 handle.

 The BC.EXE in QuickBASIC version 4.50 and the BC.EXE compiler in BASIC
 versions 6.00b and 7.10 will successfully compile a program with over
 1000 CONSTants.

 Illustration
 ------------

 To demonstrate the limitation in 7.00, use the FIRST.BAS program below
 to create the BASIC program TEST1.BAS with "n" number of CONSTants.
 For example, a TEST1.BAS program created with approximately 650
 CONSTants will compile with no errors in BASIC PDS 7.00. A program
 with 680+ CONSTants compiled with BC /V gives "Program-memory
 overflow" in BASIC PDS 7.00.

 As a comparison to versions earlier than 7.00, if you create a
 TEST1.BAS program with 1000 CONSTants, it will compile correctly with
 BC.EXE 4.50 and BC.EXE 6.00b (which have a greater capacity for
 CONSTants than 7.00).

 As a comparison to 7.10, in TEST1.BAS created below, 7.10 can handle
 1100 CONSTants when compiled BC /V (but 1200 CONSTants gives "Program
 memory overflow"). In TEST1.BAS created below, 7.10 can handle 2100
 CONSTants when compiled BC /Fs (but 2200 CONSTants gives "Compiler out
 of memory, 0 bytes free"). BASIC 7.10 can thus handle many more
 CONSTants than 7.00.

 FIRST.BAS
 ---------

 FIRST.BAS prompts you for a number, and then creates another BASIC
 program, TEST1.BAS, with that many CONSTants. Compile the resulting
 TEST1.BAS with BC /V or /Fs to test for compiler limitations.

    DEFINT A-Z
    CLS
    INPUT "How many CONSTants to you want in the file: ", Num%
    OPEN "test1.bas" FOR OUTPUT AS #1
    beg$ = "CONST p"
    equals$ = " ="
    FOR i = 1 TO Num%
       constant$ = beg$ + LTRIM$(RTRIM$(STR$(i))) + equals$ + STR$(i)
       PRINT #1, constant$
    NEXT
    CLOSE
    PRINT "File 'test.bas' successfully created"
    END


 260. Disk vs. RAM Memory of Stand Alone vs. Run Time in BASIC PDS

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900407-1 docerr
 Last Modified: 15-JAN-1991    ArticleIdent: Q61350

 There is an apparent contradiction, which needs clarification, at the
 top of page 566 in the "Microsoft BASIC 7.0: Programmer's Guide" for
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10. Page 566 first states, "Stand-alone programs require more
 disk space than those requiring the run-time module." Then it states,
 "Stand-alone programs do have the following advantages, however:
 Stand-alone programs always require less memory than their run-time
 equivalents."

 The first statement means to say that one stand-alone program requires
 more disk space than one equivalent run-time program if you do not
 count the size of the run-time module. The second statement means to
 say that stand-alone programs always require less memory in RAM than
 their run-time equivalents (counting the run-time module).

 One stand-alone program requires less RAM or disk memory than its
 run-time equivalent if you count the size of the run-time module.
 However, with a large enough number of .EXE programs, the combined
 stand-alone programs require more disk storage space than the combined
 run-time equivalents, which share one run-time module.


 261. LPRINT Followed by BLOAD or BSAVE Gives "File Already Open"

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900417-59 buglist7.00 fixlist7.10
 Last Modified: 13-AUG-1990    ArticleIdent: Q61403

 Performing an LPRINT statement prior to a BLOAD or BSAVE statement
 causes a "file already open" error to occur on the BLOAD or BSAVE
 statement if the program is run from the QBX.EXE environment or if it
 is compiled with the BC /Fs (Far Strings) option.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) version 7.00 for MS-DOS and MS
 OS/2. It does not occur in earlier BASIC versions. This problem was
 corrected in Microsoft BASIC PDS version 7.10.

 The program below demonstrates this problem. To generate the "file
 already open" error, run this program from the QBX.EXE environment or
 compile it with the Far Strings option.

 The following is a list of workarounds for this problem:

 1. Open the printer as a device and send output to the printer using
    the PRINT #<file number> statement instead of the LPRINT statement.

 2. Issue a CLOSE statement after the LPRINT statement.

 3. For an executable program, compile the program with the Near
    Strings option.

 Code Example
 ------------

    CLS
    PRINT "hello"
    DEF SEG = &HB800          'points to the segment at the screen buffer
    BSAVE "picture", 0, 4000  'save the screen in the file named picture
    DEF SEG                   'restore default segment
    LPRINT "bob"
    DEF SEG = &HB800
    BLOAD "picture", 0        '**file already open error occurs here
    DEF SEG


 262. NOFLTIN.OBJ: Hex Numbers Not Allowed with INPUT, READ, or VAL

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900409-55
 Last Modified: 21-SEP-1990    ArticleIdent: Q61406

 When you LINK the stub file NOFLTIN.OBJ into a program compiled with
 the /O switch, or into a custom run-time module built with
 BUILDRTM.EXE, the numeric parsing code will be replaced with an
 integer-only version.

 If you link with NOFLTIN.OBJ, all numbers used by INPUT, READ, and VAL
 must be within the range of legal long integers.

 Although it seems that a number represented in hexadecimal should fall
 into the category of "legal long integers," it does not. A program
 that INPUTs, READs, or uses the VAL function on a hexadecimally
 represented integer will either generate an error or return incorrect
 results. Hexadecimal number parsing is also eliminated with the
 NOFLTIN.OBJ stub file.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The following is an explanation of what happens when a program linked
 with the NOFLTIN.OBJ stub file uses either the INPUT, READ, or VAL
 commands on a hexadecimal number:

    INPUT - returns a "Redo from start"
    READ  - returns "Syntax error in module <module name>"
    VAL   - returns a value of 0


 263. Machine Hangs When BASIC PDS 7.00 Tries to Call QuickC 2.00

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900405-131 buglist7.00 S_QuickC
 Last Modified: 11-MAY-1990    ArticleIdent: Q61674

 When CALLing Microsoft QuickC version 2.00 from Microsoft BASIC
 Professional Development System (PDS) version 7.00, the machine hangs
 if a single- or a double-precision number is passed to the C routine
 and a comparison of that single- or double-precision number is then
 performed in the C routine.

 To work around this problem, do one of the following:

 1. CALL QuickC from QuickBASIC version 4.50 or from Microsoft BASIC
    Compiler versions 6.00 or 6.00b.

 2. Use Microsoft C Compiler version 5.10 instead of QuickC.

 3. Pass an integer or a long integer to QuickC instead of the
    floating-point number.

 The program below demonstrates the problem.

    Compile and LINK Instructions
    -----------------------------

       BC Basside.bas ;
       QCL /AM /c Cside.c ;
       LINK Basside + Cside,,,BRT70ENR.lib + MLIBCE.LIB ;

    Code Example
    ------------

    ' Here is the BASIC Code

    DECLARE SUB Mycfun CDECL (temp#)

    CLS
    PRINT "On the basic side"
    INPUT "Enter the double precision number "; one#
    CALL Mycfun(one#)
    LOCATE 10, 10
    PRINT "Enter any key to end"
    SLEEP
    CLS
    END

    ' Here is the C code

    #include <c:\qc2\include\stdio.h>

    void Mycfun( double *testdoub)
    {
      printf("I am in the C routine  %lf \n",*testdoub);
     if ((*testdoub) > 2000.0)
      {
         printf ("In the then \n");
      }
      else
      {
         printf("In the else \n");
      };

    printf ("Returning to BASIC \n");

    }


 264. Slow Printing from BASIC to Network Printer Under OS/2

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900122-142
 Last Modified: 10-MAY-1990    ArticleIdent: Q61438

 BASIC prints very slowly to a networked printer under OS/2 when
 compared to the same printing under DOS or the OS/2 DOS box. The
 printing speed is the same under OS/2 versions 1.00, 1.10, and 1.20.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2, and to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS OS/2.

 The following code, PTEST.BAS, demonstrates the slow printing speeds
 under OS/2. Compile and LINK the program as follows:

    BC /O PTEST.BAS ;
    LINK PTEST ;

 The following is the program PTEST.BAS:

    start = TIMER
    FOR x = 1 TO 50
       LPRINT "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLM:";x
    NEXT
    PRINT "Final time: "; TIMER - start

 The following is the output from a 386 machine running at 16Mhz with
 the print spooler disabled:

    Operating System     Printer          Time (seconds)
    ----------------     -------          ----

    OS/2                 Network            64
    DOS box              Network             6
    DOS 4.01             Network             4
    OS/2                 Direct             46
    DOS                  Direct             46

 Note: The direct connect times are longer because the printer has no
 spooler, and therefore, the computer must wait for the printer to
 print each line. Also, a similar C routine prints at normal speed
 under OS/2.


 265. TEXTCOMP in BASIC PDS 7.00 Must Have PROISAM Loaded

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900420-97
 Last Modified:  1-MAY-1990    ArticleIdent: Q61439

 When invoking the function TEXTCOMP in Microsoft BASIC Professional
 Development System (PDS) version 7.00, you must have PROISAM.EXE or
 PROISAMD.EXE in memory. If you do not have one of the PROISAM.EXE
 files in memory, you will get a "Feature Unavailable" error when you
 try to invoke the function.

 This information only applies to Microsoft BASIC Professional
 Development System (PDS) version 7.00 for MS-DOS.

 The TEXTCOMP function is in the ISAM terminate-and-stay-resident
 program (TSR) because it needs the international sorting tables, which
 are also in the ISAM TSR, to perform its comparison.

 To load TSR and QBX from DOS, type:

    C:\>PROISAM
 or
    C:\>PROISAMD

 Then type the following:

    C:\>QBX

 Code Example
 ------------

    areequal% = TEXTCOMP ("this is a test","this is a test too")


 266. "Illegal Function Call" CHAINing to Stand Alone, /Fpa, or /Fs

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S900416-144 B_QuickBas
 Last Modified: 20-SEP-1990    ArticleIdent: Q61483

 Attempting to CHAIN from an EXE that requires a run-time module to a
 stand-alone EXE causes the run-time error "Illegal Function Call" on
 the CHAIN statement.

 This error message does not occur when CHAINing in the reverse
 direction (from a stand-alone EXE to an EXE that requires a run-time
 module), or when CHAINing between identical EXE types (both stand
 alone, or both run time), or when using the RUN statement instead of
 CHAIN.

 "Illegal Function Call" also occurs when CHAINing from an EXE that
 requires a run-time module to an EXE compiled with a different math
 package (/Fpa versus /Fpi; found only in BC.EXE 6.00, 6.00b, 7.00, or
 7.10) or compiled with a different string option (/Fs far strings
 versus near strings; found only in Microsoft BASIC Professional
 Development System (PDS) version 7.00 or 7.10).

 This information applies to Microsoft QuickBASIC versions 4.00, 4.00b,
 and 4.50 for MS-DOS; to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS and MS OS/2; and to Microsoft BASIC PDS versions 7.00
 and 7.10 for MS-DOS and MS OS/2.

 When transferring control to an EXE with a different run-time module,
 the RUN statement is the preferred method. RUN makes no attempt to
 preserve any values on the transfer, whereas CHAIN tries to maintain
 COMMON variables. The CHAIN statement should be used only when
 transferring control to another BASIC program that uses the same BASIC
 run-time library as the one being CHAINed from.

 Code Example
 ------------

 The following code example produces an "Illegal Function Call" on the
 CHAIN statement when the two programs are compiled as indicated:

    'A.BAS
    'Compile and link lines:
    '   BC A;
    '   LINK A;
    CHAIN "B"         'RUN does not cause the error
    END

    'B.BAS
    'Compile and link lines:
    '   BC /o B;
    '   LINK B;
    PRINT "In Program B"


 267. Maximum Number of ISAM Files Open at Once in BASIC 7.00/7.10

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900408-3
 Last Modified:  6-FEB-1991    ArticleIdent: Q61485

 The number of ISAM tables that you can have open at one time is
 determined by the number of database files that you have open. (See
 table below.)

 The maximum number of database files that you can have open at once is
 4 files. However, this is not the maximum number of tables you can
 have open at once. The maximum number of tables that you can have open
 at once is 13 tables in 1 database file, 10 tables in 2 database
 files, 7 tables in 3 database files, or 4 tables in 4 database files.

 Attempting to open more than the maximum allowed number of tables or
 database files at once gives error 67, "Too many files."

 A database file in Microsoft BASIC Professional Development System
 (PDS) version 7.00 or 7.10 is created with the default extension .MDB
 and contains the physical data for each table plus the indexes used to
 define and point to the data.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and 7.10 for MS OS/2.

 The ISAM engine in Microsoft BASIC PDS 7.00 and 7.10 has a maximum
 number of 16 pointers or ISAM handles that it can use with ISAM files.
 These are NOT the same as DOS file handles.

 Each file still takes one DOS file handle for its first open, but it
 doesn't need any additional DOS file handles for additional tables
 opened in the same database file.

 Each database file takes four ISAM handles on its initial open: one
 handle for the file, one for the indexes, one for the data, and one
 for the initial table. Each additional table referenced in an already
 opened database takes only one additional ISAM handle and no more DOS
 handles. This is because ISAM handles that point to the same file,
 indexes, and data already exist.

 As a result, the number of tables that you can have open at once is
 determined by the number of database files you are using. The
 following table gives the combinations of databases (.MDBs) and
 additional ISAM tables that you can have open at one time:

             Maximum Number of ISAM Files and Tables

    ---------------------------------------------------------
    # of .MDBs (files):  |    1         2        3        4
                         |
    # of additional      |
    tables in already    |    12        8        4        0
    opened .MDBs:        |
                         |
    Total tables:        |    13        10       7        4
                         |
                         |
    Total ISAM handles:  |    16        16       16       16
    ---------------------------------------------------------

 Therefore, if you have all of your tables in only 1 database file, you
 can open a total of 13 tables at once. However, if you open tables in
 4 database files, you can open only those 4 tables at once.

 This information is taken from page 388 of the "Microsoft BASIC 7.0:
 Programmer's Guide" for versions 7.00 and 7.10 (Chapter 10, "Database
 Programming with ISAM").


 268. SSEGADD Example Requires Large Model (/AL) for C Routine

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900501-79 docerr S_C S_QuickC
 Last Modified: 11-MAY-1990    ArticleIdent: Q61675

 The SSEGADD example on Page 351 of the "Microsoft BASIC 7.0: Language
 Reference" manual requires that the C routine (printmessage) be
 compiled with the large memory model (/AL). The following compile
 lines should be added for the C routine:

    For C 5.00 and 5.10
    -------------------

      CL -AL printmsg.c ;

    For QuickC 1.00, 1.01, 2.00, and 2.01
    -------------------------------------

      QCL -AL printmsg.c ;

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00.

 In general, routines written in C (or other languages) need to be
 compiled either for the medium memory (/AM) or the large memory (/AL)
 model. The model size affects the default pointer type (near or far).

 When the SSEGADD example is compiled for medium model, the program
 runs without error, but the wrong data is displayed. This is because
 the printf() function is expecting a near pointer (offset in the data
 segment) and printmessage is accepting a far pointer (segment and
 offset). If you use the large memory model, printf() expects a far
 pointer, and the program runs correctly.


 269. EMS Corrupt in QBX When 386MAX Loaded with the Noframe Option

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900430-50
 Last Modified: 11-MAY-1990    ArticleIdent: Q61679

 The error "EMS Corrupt" occurs when running QBX.EXE with 386MAX using
 the "noframe" option for 386MAX. This option causes 386MAX to not use
 any page frames in base memory. QBX.EXE does not support this method
 of expanded memory management.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00.


 270. QBX ISAM Capitalizes the Field Names of a Table in an .EXE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900508-29
 Last Modified: 22-MAY-1990    ArticleIdent: Q62055

 Microsoft BASIC Professional Development System (PDS) version 7.00
 ISAM behaves in a slightly different manner in the QBX.EXE environment
 than when compiled. In a compiled program, when a database is created,
 the ISAM engine capitalizes all field names in the TYPE used to create
 the table. In the QBX.EXE environment, the ISAM engine leaves field
 names in whatever case they were coded in. This slight difference in
 behavior of the ISAM engine should not cause any problems in ISAM.
 BASIC variable names are not case sensitive. This includes the
 variable names used to create and access ISAM tables and indexes.

 This information applies to Microsoft BASIC PDS version 7.00 for MS-DOS.

 The following program displays this behavior. Run the program in the
 QBX.EXE environment, then use the ISAMPACK.EXE utility on the file the
 program creates. ISAMPACK.EXE displays the structure of the database
 as it repairs the file. It also shows the case on all tables, fields
 in the table, and indexes. Compile the program, run it, and use
 ISAMPACK to display the database structure again. This shows the
 difference in the case of the field names.

 This difference occurs no matter how ISAM is used. ISAM can be used
 in four different ways: PROISAM(d) TSR with or without the run-time
 module; linked directly into the program itself; or linked into the
 run-time module. All forms of accessing the ISAM engine behave the
 same way.

 Code Example
 ------------

     TYPE table
         Field1      AS LONG
         Field2      AS LONG
         Field3      AS LONG
     END TYPE
     ' Check if the table already exists. If so, delete it.
     IF (DIR$("db1.mdb") <> "") THEN
         DELETETABLE "db1.mdb", "Table1"
     END IF
     OPEN "db1.mdb" FOR ISAM table "Table1" AS 1
     CREATEINDEX 1, "Idx", 1, "Field1", "Field2", "Field3"
     CLOSE
     END


 271. Description of EM-Management Switches for BASIC PDS 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900503-164
 Last Modified: 22-MAY-1990    ArticleIdent: Q62056

 This article describes the purpose and use of the Microsoft BASIC
 Professional Development System (PDS) version 7.00 switches that allow
 you to configure the use of expanded memory (EM). Especially important
 is the description of the /Es switch and its relationship to the other
 EM switches.

 This information applies to Microsoft BASIC PDS 7.00 for MS-DOS and MS
 OS/2.

 Saving and Restoring the EM State
 ---------------------------------

 By default, QBX.EXE and programs compiled with BC.EXE 7.00 perform
 only the minimum saving and restoring of the EM state necessary to
 allow the program to work properly. This assumes that no third-party
 code using EM is present. To get more than this minimal amount of EM
 save and restore, you must specify /Es upon loading QBX.EXE or when
 compiling programs with BC.EXE. This is by design. If BASIC always
 saved and restored the EM state, the save and restore operations would
 significantly affect the speed of ISAM and quick library (QLB)
 calling. The purpose of the /Es switch is to allow programs to use
 third-party code that uses EM. The trade-off is a degradation in
 speed.

 Table of EM Switches and Where You Can Use Them
 -----------------------------------------------

    Use With     Switch Name   Switch Purpose
    --------     -----------   --------------

    QBX only     /Ea           Arrays > 512 bytes but < 16K in
                               EM. Default: no arrays in EM.

    QBX only     /E:n          n = amount in kilobytes of EM QBX
                               will use. 0 means QBX uses no EM.
                               Default: use all available EM.

    QBX and BC   /Es           Enable EM state save/restore.

    PROISAM(D)   /Ie:n         Reserves n kilobytes of EM for
                               other applications (Such as QBX).
                               ISAM will use only 1.2 MB of EM
                               maximum.

 Examples: Use of the Switches, Their Effects, and How They Interact
 -------------------------------------------------------------------

 QBX /E:0

    * This switch causes QBX.EXE to disable use of EM for code storage.

    * If the program has ISAM using EM, it is assumed that no
      third-party code that is accessing EM is present. With /E:0, the
      default for QBX.EXE is not to save and restore the EM state on
      ISAM use. This maximizes the speed of ISAM performance.

 QBX /E:0 /Es

    * Save and restore operations occur on any ISAM statement or QLB
      call. Use this combination if you are loading QLBs that use EM
      and ISAM using EM is being used as well.

 QBX /E:N and N Is Nonzero

    * The EM state on QLB calls is not saved and restored.

    * ISAM calls will be saved and restored when both QBX.EXE and ISAM
      are sharing EM.

    * It is assumed there are no QLBs using EM.

 QBX /Es or QBX /E:N /Es

    * This switch forces QLB calls and ISAM statements to be saved and
      restored.

    * This switch would be used if you are using QBX.EXE and calling
      QLB routines that access EM.

 BC with No EM-Management Switches, No Overlays, No ISAM

    * The EM state is not saved or restored.

    * Third-party routines accessing EM should work correctly.

 BC with Overlays That Will Load from EM

    * EM will be used by compiled code in the overlays.

    * The default is to save and restore EM on all ISAM statements in a
      program that uses overlays.

    * This could still cause problems if third-party library routines
      that use EM are called.

 BC /Es with Overlays and ISAM

    * EM will be saved and restored on ISAM statements.

    * Always use /Es when doing mixed-language calls to routines
      that use EM as well.

 BC /Es Without EM Overlays, but With ISAM

    * /Es always saves and restores ISAM statements when ISAM is using
      EM.

    * You would use this switch if the program uses ISAM, if ISAM is
      using EM, and if there are mixed-language CALLs to routines that
      use EM.

    * Note: /Es will not cause ISAM statements to be saved and restored
      if ISAM is NOT using EM.


 272. Multiple Duplicate Definition L2025 with Graphics Stub Files

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900329-130
 Last Modified: 22-MAY-1990    ArticleIdent: Q62058

 Linking a Microsoft BASIC Professional Development System (PDS)
 version 7.00 program with the NOGRAPH.OBJ stub file and any of the
 other graphics stub files (NOEGA.OBJ, NOOGA.OBJ, NOVGA.OBJ, or
 NOHERC.OBJ) produces multiple "L2025 symbol defined more than once"
 error messages. This is because the NOGRAPH object module is a
 superset of the other NOxxx.OBJ graphics files. If you use NOGRAPH,
 you remove all graphics support and should not use any of the other
 NOxxxx.OBJ graphics stub files. The individual NOxxx.OBJ graphics stub
 files contain a subset of the stub routines in the NOGRAPH.OBJ stub
 file. When you try to link them both, you are trying to include the
 same routines twice, and therefore, the linker generates L2025,
 telling you that the same stub routine is being linked in twice.

 NOGRAPH.OBJ should be used by itself. If you want to stub out all
 graphics support, link with NOGRAPH.OBJ and no other stub file.
 However, if you want VGA support but not EGA, HERC, or OGA, link your
 program with NOEGA, NOHERC, and NOOGA, but not with NOVGA and NOGRAPH.

 This information applies to Microsoft BASIC PDS 7.00 for MS-DOS and MS
 OS/2.


 273. WHEREIS.BAS Problem Under MS-DOS 4.00 and 4.01

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBas
 Last Modified: 25-MAY-1990    ArticleIdent: Q62202

 The sample program WHEREIS.BAS searches for the location of a specific
 file on disk. WHEREIS uses the BASIC SHELL statement to perform a DOS
 DIR command and redirects the results to a file that WHEREIS.BAS later
 scans for the file it is searching for.

 Under MS-DOS versions 4.00 and 4.01, the WHEREIS.BAS program SHELL
 command does not function correctly. The path specification string
 passed to the DOS DIR command from WHEREIS ends with a blackslash
 character, resulting in a DIR command something like the following:

    DIR C:\QB45\x\

 This form of the DIR command returns a list of files in the QB45
 directory when used under MS-DOS 3.x and earlier. Under MS-DOS 4.00
 and 4.01, this command fails with the error message "Invalid
 directory." Removing the trailing backslash allows the DIR command to
 operate under MS-DOS 4.00 and 4.01.

 To correct WHEREIS.BAS to operate under MS-DOS 4.00 and 4.01, you need
 to add several lines to the ScanDir SUBprogram in WHEREIS.BAS.

 In the original version of WHEREIS.BAS, line 12 of the ScanDir SUB
 reads as follows:

    SHELL "DIR " + PathSpec$ + " > " + TempSpec$

 To remove the trailing backslash from the string PathSpec$, replace
 the line above with the following:

    StripPath$ = PathSpec$

    IF RIGHT$(StripPath$,1) = "\" AND LEN(StripPath$) > 1 THEN
      StripPath$ = LEFT$(StripPath$, LEN(StripPath$) - 1)
    END IF

    SHELL "DIR " + StripPath$ + " > " + TempSpec$


 274. ADAPTER.BAS Needs SLEEP Statement When Compiled

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900504-3
 Last Modified: 29-MAY-1990    ArticleIdent: Q62203

 The sample program APAPTER.BAS included with Microsoft BASIC
 Professional Development System (PDS) version 7.00 must have the SLEEP
 statement added to the code after the call to the SUBprogram so that
 the message that states what video modes are supported on the monitor
 is displayed when the program is compiled.

 This information applies to Microsoft BASIC PDS 7.00 for MS-DOS and
 OS/2.

 ADAPTER.BAS works correctly when compiled, except that the message
 displayed at the end of the program that states what video modes are
 supported by the monitor is displayed and then erased. This is due to
 the statement "SCREEN 0, 0", which sets the screen mode back to mode 0
 following the test. This problem is related to the second parameter,
 0, which is the "Color switch" parameter. When anything in the video
 mode changes, the screen is erased. When the message is displayed in
 the compiled program, the program ends and the screen mode is set back
 to composite color monitor mode. A color switch parameter of 0 in the
 SCREEN statement sets it to noncolor. By removing the color switch
 parameter or setting it to 1, ADAPTER.BAS will work correctly.

 ADAPTER.BAS works in the environment because the SCREEN mode is not
 reset until you respond to the "Press any key to continue" message.
 This can be demonstrated in the compiled program by placing a SLEEP
 statement following the CALL to the SUBprogram Adapter and leaving the
 SCREEN 0, 0 statement as is.

 Code Example
 ------------

   -------ADAPTER.BAS-----------

   DECLARE SUB Adapter ()
   DEFINT A-Z
   Adapter
   SLEEP
   END


 275. LINK L1083 "Cannot Open Run File" on Novell Network

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900423-82
 Last Modified: 18-OCT-1990    ArticleIdent: Q62206

 A customer reported that when linking a program in Microsoft BASIC
 Professional Development System (PDS) version 7.00 on a workstation
 running Novell NetWare ELS Level I or Level II, you may get LINKer
 error L1083, "cannot open run file." Another customer reported the
 problem on Novell NetWare Advanced 286 version 2.15. This problem does
 not occur when the network software is not installed, according to the
 customers.

 The problem seems to occur only if there already is an .EXE file on
 disk with the same base name as the .OBJ file that was being linked.
 When the old .EXE file is deleted, the LINK command functions
 successfully. Microsoft has not tested or confirmed this information.

 Microsoft BASIC PDS 7.00 and 7.10 have not been tested under, and are
 not guaranteed to work under, any version of Novell NetWare.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS.

 The customer encountered this problem on both a workstation and server
 machine with the following configurations:

    286 12-MHz Clone
    Novell ELS Level 1 version 2.0 A
    (9/15/87)

 or

    Novell ELS Level 2 version 2.15
    DOS version 3.30
    Hercules video card


 276. Calling API Function to Get All Available Drives

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900517-71
 Last Modified:  7-JUN-1990    ArticleIdent: Q62214

 Microsoft BASIC Compiler versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) version 7.00 protected mode
 programs can call the OS/2 API function DosQCurDisk() to get all the
 available logical drives. DosQCurDisk() requires the following
 parameters:

    Parameter   Description
    ---------   -----------

    PTR WORD    Receives current drive code (1 = A, 2 = B, etc.)

    PTR DWORD   Receives logical drive bitmap (logical drives A-Z
                correspond to bits 0-25; a bit is set if a
                logical drive exists)

 The first parameter is not important in getting the available drives,
 but it is worthy to note that for API functions, a WORD (2 bytes) has
 a BASIC type of INTEGER. Likewise, a DWORD (4 bytes) has a BASIC type
 of LONG. Since the specification requires pointers to these data
 items, the DECLARE statement for DosQCurDisk() uses the SEG keyword for
 each of the parameters. This causes 4-byte addresses of the parameters
 to be passed instead of 2-byte addresses, which is the default because
 BASIC uses the medium-memory model. Also, API functions return an
 error code, so for BASIC to retrieve this code, you must declare
 DosQCurDisk() as a FUNCTION.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and Microsoft BASIC (PDS) version 7.00 for MS OS/2.

 For more information on calling OS/2 API functions from Microsoft
 BASIC Compiler versions 6.00 and 6.00b, see Page 21 of the "Microsoft
 BASIC Compiler 6.0: User's Guide" included with the product.

 For more information on calling OS/2 API functions from Microsoft
 BASIC PDS version 7.00, see Page 523 of the "Microsoft BASIC 7.0:
 Programmer's Guide" included with the product.

 For more information on DosQCurDisk(), see Page 547 of "Advanced OS/2
 Programming," by Ray Duncan (Microsoft Press, 1989).

 To see a BASIC PDS 7.00 sample program that finds all the available
 drives in DOS or OS/2 real mode, query in this Knowledge Base on the
 word "chdrive".

 The following sample program (LOGICAL.BAS) reports all the available
 logical drives.

 To compile the program, use the following:

    bc logical /lp;

 To link the program for BASIC 6.00 and 6.00b, use the following:

    link /nop logical,,,doscalls;

 To link the program for BASIC 7.00, use the following:

    link /nop logical,,,os2;

 Code Example
 ------------

 ' This declaration was taken from the include file
 BSEDOSFL.BI.

 DECLARE FUNCTION DosQCurDisk% (SEG CurrentDrive AS INTEGER,_
                                SEG DriveBitmap  AS LONG)

 ' CurrentDrive% receives the current drive code (A=1, B=2,
 ' etc.). DriveBitmap& receives a bitmap of each logical
 ' drive's availability.
 ErrorCode% = DosQCurDisk% (CurrentDrive%, DriveBitmap&)

 IF ErrorCode% THEN

    PRINT "An error occurred, the code is";ErrorCode%

 ELSE

    PRINT "The following drives are available:";

    ' Bit% is used to circulate through bits 0-25 (drives A-Z)
    ' of DriveBitmap&.  If (DriveBitmap& AND 2^Bit%) = 2^Bit%,
    ' then bit Bit% of DriveBitmap& is set and the
    ' corresponding logical drive is available.
    FOR Bit% = 0 to 25
       IF (DriveBitmap& AND 2^Bit%) = 2^Bit% THEN
          PRINT " ";CHR$(Bit% + 65);
       END IF
    NEXT Bit%

 END IF

 END


 277. QBX Hangs Using KEY with Two or More Characters, Then INPUT$

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 fixlist7.10 SR# S900517-71
 Last Modified: 29-JAN-1991    ArticleIdent: Q62216

 The program below hangs in the QBX.EXE environment of Microsoft BASIC
 Professional Development System (PDS) version 7.00. The problem occurs
 when you specify two or more characters in the KEY statement's string
 to specify a softkey and follow that with an INPUT$ statement. After
 you run the program in the QBX.EXE environment, press the softkey, and
 press an additional key, the program hangs after it ends with the
 "Press any key to continue" message.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00. This problem is corrected in BASIC PDS version 7.10.

 This is only a problem in the QBX.EXE environment. This program works
 correctly when it is compiled to an .EXE program (with either the Near
 Strings or Far Strings option).

 To work around this problem in BASIC 7.00, do any of the following:

 1. Use the INPUT statement (or INKEY$ function in a loop) instead of
    the INPUT$ function.

 2. Use only one character in the string for the KEY statement.

 The following code sample demonstrates this problem:

    KEY 10, "*" + CHR$(13)   ' Any two or more characters produce problem.
    my$ = INPUT$(1)          ' Press F10 then additional key as input.
    print my$


 278. EXEHDR.EXE Switch Omissions in 7.00/7.10 Manual

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900517-206 docerr
 Last Modified: 15-JAN-1991    ArticleIdent: Q62217

 The EXEHDR documentation on page 347 of the "Microsoft CodeView and
 Utilities User's Guide" for Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 mentions only the /v (verbose)
 option and omits many additional EXEHDR options. This manual also
 unnecessarily documents the EXEMOD utility (on pages 307-311), which
 is an older version of EXEHDR. EXEMOD is not shipped with BASIC PDS
 7.00 or 7.10 because EXEHDR contains all of EXEMOD's functionality.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS and MS OS/2.

 The full list of EXEHDR options can be displayed by typing EXEHDR /?
 at the DOS prompt. The options are as follows:

    Usage: EXEHDR [options] <file-list>
    Valid options are:

       /?
       /HEAP:(0H - ffffH)
       /HELP
       /MAX:(0H - ffffH)
       /MIN:(0H - ffffH)
       /NEWFILES
       /NOLOGO
       /PMTYPE:(PM | VIO | NOVIO | WINDOWAPI |
                   WINDOWCOMPAT | NOTWINDOWCOMPAT)
       /RESETERROR
       /STACK:(0H - ffffH)
       /VERBOSE

 Note: The hex values are listed in assembly notation (for example,
 ffffH). Hex values should actually be input with C notation using the
 "0x" prefix instead of the "H" suffix (for example, ffffH -> 0xffff).
 The values can also be entered in decimal notation without prefixes or
 suffixes.

 If the assembler notation for hex values is used with EXEHDR, the
 following errors will occur:

    EXEHDR: error U1110: malformed number FFFFH
    EXEHDR: error U1115: option /MAX:FFFFH ignored


 279. OS/2 API Function to Get Current Drive

 Product Version(s): 6.00 6.00b 7.00
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900517-70
 Last Modified:  7-JUN-1990    ArticleIdent: Q62218

 Microsoft BASIC Compiler versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) version 7.00 protected mode
 programs can call the OS/2 API function DosQCurDisk() to get the
 currently selected drive. DosQCurDisk() requires the following
 parameters:

    Parameter   Description
    ---------   -----------

    PTR WORD    Receives current drive code (1 = A, 2 = B, etc.)

    PTR DWORD   Receives logical drive bitmap (logical drives A-Z
                correspond to bits 0-25; a bit is set if a
                logical drive exists)

 The second parameter is not important in getting the current drive,
 but it is worthy to note that for API functions a DWORD (4 bytes) has
 a BASIC type of LONG. Likewise, a WORD (2 bytes) has a BASIC type of
 INTEGER. Since the specification requires pointers to these data
 items, the DECLARE statement for DosQCurDisk() uses the SEG keyword for
 each of the parameters. This causes 4-byte addresses of the parameters
 to be passed instead of 2-byte addresses, which is the default because
 BASIC uses the medium-memory model. Also, API functions return an
 error code; therefore, for BASIC to retrieve this code, it must
 declare DosQCurDisk() as a FUNCTION.

 The DECLARE statements for almost every API function are located in
 include files that come with BASIC 6.00 and 6.00b and BASIC PDS 7.00.
 To modify the DECLARE statement, you just have to include the right
 file. See the PACKING.LST file included with the product for a
 description of these include files.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and Microsoft BASIC PDS version 7.00 for MS OS/2.

 For more information on calling OS/2 API functions from Microsoft
 BASIC Compiler versions 6.00 and 6.00b, see Page 21 of the "Microsoft
 BASIC Compiler 6.0: User's Guide" included with the product.

 For more information on calling OS/2 API functions from BASIC PDS
 version 7.00, see Page 523 of the "Microsoft BASIC 7.0: Programmer's
 Guide" included with the product.

 For more information on DosQCurDisk(), see Page 547 of "Advanced OS/2
 Programming," by Ray Duncan (Microsoft Press, 1989).

 Note that BASIC PDS version 7.00 supports the function "CURDIR$",
 which can also be used to get the currently selected drive. However,
 using this method requires some string parsing, so although the code
 is smaller, it may be slower.

 The sample program below (GETDRIVE.BAS) reports the currently selected
 drive.

 To compile the program, use the following:

    bc getdrive /lp;

 To link the program for BASIC 6.00 and 6.00b, use the following:

    link /nop getdrive,,,doscalls;

 To link the program for BASIC 7.00, use the following:

    link /nop getdrive,,,os2;

 Code Example
 ------------

 ' This declaration was taken from the include file
 ' BSEDOSFL.BI

 DECLARE FUNCTION DosQCurDisk% (SEG CurrentDrive AS INTEGER,_
                                SEG DriveBitmap  AS LONG)

 ' CurrentDrive receives the current drive code (A=1, B=2,
 ' etc.)
 ' DriveBitmap receives a bitmap of each logical drive's
 ' availability

 ErrorCode% = DosQCurDisk% (CurrentDrive%, DriveBitmap&)

 IF ErrorCode% THEN
    PRINT "An error occurred, the code is";ErrorCode%
 ELSE
    PRINT "The current drive is "; CHR$(CurrentDrive% + 64)
 END IF

 END


 280. TSCNIOxx.OBJ Stub Files Remove Screen 0 Page-Switching

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900423-7
 Last Modified: 20-JUN-1990    ArticleIdent: Q62260

 If you link the stub file TSCNIOxx.OBJ to your BASIC object module,
 any attempt to change the visual or active page to any page other than
 Page 0 generates the error "Feature Removed." The run-time routines
 responsible for handling page switching are included in those run-time
 routines stubbed out by TSCNIOxx.OBJ. This information applies to
 Microsoft BASIC Professional Development System (PDS) version 7.00 for
 MS-DOS and MS OS/2.

 The TSCNIOxx.OBJ stub file is used to remove all graphics support that
 is automatically inserted in your program at link time so that you may
 generate smaller EXE files.

 For more information on this and other stub files, query on the
 following words:

    smaller and stub and EXE

 The sample code below reproduces the error "Feature Removed."

 Compile and link as follows:

    BC scrntest.bas /o ;
    LINK scrntest + tscionr.obj,,,bcl70enr.lib /noe ;

 Code Example
 ------------

    CLS
    PRINT "Switching pages"
    SLEEP
    SCREEN 0, , 1, 1        'This line will generate the Feature.
                            'Removed error because it tries to switch
                            'pages in Text mode.


 281. Problem with SCREEN 0 Paging on CGA in QB.EXE & QBX.EXE

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900517-177 B_QuickBas buglist7.00 buglist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q62270

 Paging through the active and visible pages of SCREEN 0 does not work
 correctly on a CGA monitor in the QBX.EXE or QB.EXE environment  This
 problem occurs only when single-stepping through a program and setting
 breakpoints to view the output of the various pages. Machines equipped
 with EGA or VGA video adapters do not demonstrate this problem.

 Microsoft has confirmed this to be a problem in the QB.EXE environment
 QuickBASIC version 4.50 (buglist4.50) and in the QBX.EXE environment
 of Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10. We are researching this problem and will post new
 information here as it becomes available.

 This problem does not occur in QuickBASIC versions 4.00 and 4.00b.

 The following code example demonstrates the problem in QB.EXE or
 QBX.EXE. Step through the program using the F8 key. After the PRINT
 statement, press the F4 function key to view the output screen. The
 screen will not be updated on a CGA monitor.

 Code Example
 ------------

    DEFINT A-Z
    DO UNTIL INKEY$ <> ""
       SCREEN 0, 0, x, x
       CLS
       PRINT "SCREEN MODE 0, PAGE"; x
       x = x + 1          ' Press F4 key to view the output screen
       IF x = 8 THEN x = 0
    LOOP


 282. Incorrect Results When Compiling with Near Strings

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900517-165
 Last Modified:  1-JUN-1990    ArticleIdent: Q62456

 A program compiled with the Near Strings option (without /Fs) may
 produce incorrect results when the program uses a combination of the
 following:

 1. The LEN function on a variable length string
 2. Integer division
 3. String concatenation

 The same program will run correctly when run from the QBX.EXE
 environment or when compiled with Far Strings (with /Fs).

 Microsoft has confirmed this to be a problem in the BC.EXE 7.00
 compiler provided with Microsoft BASIC Professional Development System
 (PDS) version 7.00 for MS-DOS and MS OS/2. We are researching this
 problem and will post new information here as it becomes available.
 This problem does not occur in earlier versions of Microsoft BASIC
 Compiler (BC.EXE).

 This problem results from incorrect optimization by the BC.EXE 7.00
 compiler. You can disable these optimizations by either compiling with
 the /X compiler switch or by including line numbers in the area of the
 program where the error occurs.

 The following steps reproduce the problem:

 1. Use the LEN function on a variable-length string.

 2. Take the number returned by the LEN function and perform integer
    division on that number.

 3. Reassign a concatenated string to the variable-length string
    mentioned in step 1.

 4. Again, use the LEN function on the variable-length string and
    perform integer division on that result.

 If the program is compiled with Near Strings, the result of the
 calculation in Step 4 will be incorrect.

 The program below demonstrates the problem. The second PRINT statement
 should display a value of 9; however, if the program is compiled with
 Near Strings, a 0 will be displayed instead. The value returned by
 LEN(a$) is correct, but when integer division is performed on this
 value, an incorrect result is produced.

    PRINT LEN(a$) \ 2
    a$ = "concatenate " + "strings"
    PRINT LEN(a$) \ 2        'the value printed here is incorrect
    END

 Listed below are four different methods to work around the problem:

 1. Compile the program with /X or include line numbers in the area
    of the program where the problem occurs. Both of these actions
    disable some of the compiler optimizations that are the cause
    of this problem.

 2. Do not use integer division. Instead, perform regular division
    and then use the INT function to get the desired result, as in the
    following example:

       PRINT INT(LEN(a$) / 2)
       a$ = "concatenate " + "strings"
       PRINT INT(LEN(a$) / 2)
       END

 3. Avoid string concatenation, as follows:

       PRINT LEN(a$) \ 2
       a$ = "concatenate strings"  'assign a$ to 1 string instead of
                                   'using concatenation
       PRINT LEN(a$) \ 2
       END

 4. Assign the string that was created by concatenating strings to
    another string variable. Then, perform the LEN function on the
    new string, as in the following example:

       PRINT LEN(a$) \ 2
       a$ = "concatenate " + "strings"
       b$ = a$                'insert this line
       PRINT LEN(b$) \ 2      'and perform the rest of the
                              'calculations on b$
       END


 283. ISAM INSERT with Duplicate Key Incorrectly Allocates Record

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist7.00 buglist7.10
 Last Modified:  8-AUG-1990    ArticleIdent: Q62460

 When you specify a unique key with CREATEINDEX using Microsoft BASIC
 Professional Development System (PDS) version 7.00 ISAM, inserting
 records with duplicate keys causes a trappable error (run-time error
 86). However, the ISAM engine still inserts one record into the ISAM
 file per attempt to insert a duplicate key record. The records
 inserted with the duplicate keys are marked as deleted. The BASIC
 function LOF, which returns the total number of records in a BASIC PDS
 7.00 ISAM file, will show the actual number of successful writes to
 the file, showing that the records written with duplicate keys are not
 valid. Since these records are marked as deleted, using the ISAMPACK
 utility will remove the records and reduce the file to its appropriate
 size.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS. We are researching this problem and will post new information
 here as it becomes available.

 The sample program below demonstrates the problem. If you execute the
 code below, a record will be inserted into the ISAM file, and then 999
 more attempts will be made to insert that record. Since the program
 specifies unique keys in the CREATEINDEX statement, run-time error 86,
 "Duplicate key," will occur. The program will trap the "Duplicate key"
 error and resume execution. When the program terminates, the LOF
 function will show there is only one legitimate record in the file.
 The file size, however, will be approximately 1.6 MB. Using
 ISAMPACK.EXE on the ISAM file created by the program will reduce the
 file to 64K in size.

 To execute the program below, you must load the BASIC PDS 7.00 or 7.10
 ISAM support by executing the PROISAMD.EXE TSR (terminate-and-stay-resident)
 program. After PROISAMD has been loaded, you can execute the program
 within the QBX.EXE environment.

 Code Example
 ------------

 'WARNING: Even though this program only successfully
 '         writes one ISAM record, it creates a 1.6 MB file.
 TYPE NewRec
    AString AS STRING * 8
 END TYPE

 40 ON ERROR GOTO errorhandler
 50 DIM NewBuf AS NewRec
 60 OPEN "output.mdb" FOR ISAM NewRec "NewRec" AS #1

 70 CREATEINDEX #1, "X", 1, "AString"    '* Specify unique key *

 80 NewBuf.AString = "ABCDEFGH"
 90 FOR i = 1 TO 1000
 100     INSERT #1, NewBuf      '* Causes 999 "Duplicate key" errors *
 110    PRINT i
 120 NEXT
 130 PRINT "Size of database (should be 1): "; LOF(1)
 135 DELETEINDEX #1, "X" ' Delete the index so the program
                         ' can be run over.
 140 END

 errorhandler:
 150     SELECT CASE ERR
             CASE 86: PRINT "duplicate key attempted":
             RESUME NEXT
         CASE ELSE
             CLS
             PRINT "An error occurred. The number is: "; ERR
             PRINT "It occurred on line: "; ERL
             DELETEINDEX #1, "X"
             END
         END SELECT


 284. Must Load PROISAM or PROISAMD to Use ISAM Utilities

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900509-65
 Last Modified:  8-AUG-1990    ArticleIdent: Q62770

 As stated on Page 389 of the "Microsoft BASIC 7.0: Programmer's Guide"
 for versions 7.00 and 7.10, when using the ISAM utilities ISAMIO,
 ISAMCVT, or ISAMPACK, you must have the ISAM support installed.

 Depending on how you ran SETUP.EXE, the ISAM utilities ISAMIO.EXE,
 ISAMCVT.EXE, and ISAMPACK.EXE are built either to run as stand-alone
 programs or to require the terminate-and-stay-resident (TSR) form of
 ISAM (PROISAMD.EXE). SETUP always installs the ISAMREPR.EXE (ISAM
 repair) utility to run as a stand-alone program. For more information
 about how SETUP installs the ISAM utilities, search for a separate
 article in this Knowledge Base with the following words:

    how and SETUP and builds and ISAMIO

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The following table describes what each of the ISAM utilities does:

    Utility Name        Use
    ------------        ---

    ISAMREPR            Repairs or rebuilds database

    ISAMCVT             Converts other ISAM file types to the ISAM
                        format used by BASIC PDS 7.00

    ISAMPACK            Rotates all deleted records to the end of the
                        ISAM file, and if a 32K section is marked for
                        deletion, it decreases the size of the data
                        file by 32K

    ISAMIO              Converts to or from simple ASCII text files and
                        ISAM files


 285. Record Number for PUT/GET Statement Can Be a Long Integer

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900319-92 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q62771

 Pages 147 and 280 in the "Microsoft BASIC 7.0: Language Reference"
 and Page 110 in the "Microsoft BASIC 7.0: Programmer's Guide"
 incorrectly state that when specifying the record number in a GET/PUT
 statement for a random file or the position number for a binary file,
 the record or position number should be an integer.

 The explanation for the GET/PUT statement should describe the record
 or position number as being either an integer or a long integer.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The correct syntax for the GET/PUT statement is as follows:

   {GET|PUT} [#]filenumber% [, [recordnumber&] ] [, [variable] ]

 When accessing a random file, "recordnumber&" represents the number of
 the record to be read or written. When accessing a binary file,
 "recordnumber&" represents the byte position of where the reading or
 writing starts.

 The online Help for BASIC PDS 7.00 and 7.10 correctly describes the
 record number as "recordnumber&". The following documentation,
 however, incorrectly describes the record number as "recordnumber%":

 1. Page 110 of the "Microsoft BASIC 7.0: Programmer's Guide" for
    7.00 and 7.10

 2. Pages 147 and 280 of the "Microsoft BASIC 7.O: Language Reference"
    manual for 7.00 and 7.10

 By specifying the recordnumber variable as "recordnumber&" instead of
 "recordnumber%", it is inferred that the record number variable may
 either be of type INTEGER or LONG INTEGER.

 Using recordnumber% would suggest that the largest possible record
 number to be 32,767. Since the largest possible record number is
 2,147,483,647, the record number should be described as recordnumber&.


 286. OPEN New Table with PROISAM Causes "Feature Unavailable"

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900312-94 docerr
 Last Modified: 15-JAN-1991    ArticleIdent: Q62772

 Page 234 of "Microsoft BASIC 7.0: Language Reference" (for versions
 7.00 and 7.10) incorrectly states that the error generated when
 attempting to OPEN a new ISAM table or database with the PROISAM TSR
 loaded will produce a "File not found" error message. The correct
 error message produced is actually "Feature Unavailable."

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 Note: The PROISAM TSR (or library) allows existing databases and
 tables to be accessed, but does not allow dynamic allocation of
 databases and tables. The PROISAMD TSR (or library) is required to
 dynamically allocate databases and tables.


 287. Overflow Error OPENing ISAM File with TYPE > 255 Elements

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900518-75 buglist7.00 buglist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q62773

 An "Overflow" error will occur when OPENing a file FOR ISAM with a
 TYPE containing a large number of elements. This number is 255 for
 INTEGERs, LONGs, and fixed-length STRINGs, and 239 for DOUBLEs and
 CURRENCYs. This problem occurs in both the QBX.EXE environment and
 compiled EXEs.

 To work around the problem, limit the number of elements in the main
 type by combining some elements in a nested type or arrays.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS. We are researching this problem and will post new information
 here as it becomes available.

 Code Example
 ------------

 The following program fragment (the majority of TYPE is left out for
 space reasons) demonstrates the problem. The "Overflow" error will
 occur on the OPEN statement:

 TYPE BigType
   I1 AS INTEGER
   I2 AS INTEGER
   I3 AS INTEGER
                           <... I4-I250>
   I251 AS INTEGER
   I252 AS INTEGER
   I253 AS INTEGER
   I254 AS INTEGER
   I255 AS INTEGER        '255 for INTEGER/LONG/STRING*n
 END TYPE                 '239 for DOUBLE/CURRENCY

 OPEN "BigType" FOR ISAM BigType "BigType" AS #1  'Overflow error
                                                  'here
 CLOSE

 To use the workaround listed above, the TYPE BigType should be made of
 nested types, such as the following:

 TYPE NestType
   A AS INTEGER
   B AS INTEGER
   C AS INTEGER
   D AS INTEGER
   E AS INTEGER
 END TYPE

 TYPE NewBigType
   I(1 TO 250) AS INTEGER
   N AS NestType
 END TYPE


 288. Using PC-DOS 3.00 and QBX.EXE Will Give SHELL Problems

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900522-12 buglist7.00 buglist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q62774

 When using QuickBASIC Extended (QBX.EXE) version 7.00 or 7.10 under
 PC-DOS version 3.00, if you first generate a PC-DOS "Bad command or
 file name" error on a SHELL statement, then any subsequent uses of the
 SHELL statement with any parameter will result in the "Bad command or
 file name" error until you restart QBX.EXE. To work around this
 problem, you can either use QuickBASIC version 4.50, or upgrade to
 either MS-DOS or a newer version of PC-DOS, or compile the program and
 run it outside of the environment with the near strings option
 (without /Fs).

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 under
 PC-DOS 3.00. We are researching this problem and will post new
 information here as it becomes available.

 This problem does not occur in Microsoft QuickBASIC versions 4.00,
 4.00b, or 4.50, or in Microsoft BASIC Compiler versions 6.00 or 6.00b
 under PC-DOS.

 The following code example demonstrates the problem:

 Code Example
 ------------

    SHELL "Errorxyz"      ' This will cause the first "Bad command or
                          ' file name" error.
    SHELL "CLS"           ' This is supposed to work but it gives a "bad
                          ' command or file name" error


 289. FRE(-1) Decreases with Repeated Use of DEF FNa$ in QBX.EXE

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900520-2 buglist7.00 fixlist7.10
 Last Modified:  2-NOV-1990    ArticleIdent: Q62813

 Repeated use of a DEF FN function to return a string in the QBX.EXE
 environment causes far heap memory to decrease as shown in the
 following program. This does not occur with a compiled .EXE program or
 if a FUNCTION procedure is used in place of the DEF FN function.

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment of Microsoft BASIC Professional Development System (PDS)
 version 7.00 for MS-DOS. This problem was corrected in BASIC PDS 7.10.

 To work around the above problem, use a BASIC FUNCTION procedure in
 place of the DEF FN function.

 This problem does not occur with any version of Microsoft QuickBASIC
 (QB.EXE) or any version of Microsoft BASIC Compiler (BC.EXE).

 Microsoft QuickBASIC versions 4.00 and later and Microsoft BASIC
 Compiler versions 6.00 and later have a method of implementing
 functions that is much more straightforward than DEF FN. These
 products allow true FUNCTION procedures to be created, much like the
 functions available in Pascal and C. A BASIC FUNCTION...END FUNCTION
 block is a procedure that allows you to return a value to the calling
 subprogram, but in all other respects is the same as a SUB...END SUB
 subprogram procedure. Using a FUNCTION procedure instead of DEF FN
 avoids the DEF FN problem described in this article.

 The following code example demonstrates the problem when run in the
 QuickBASIC Extended environment (QBX.EXE) that comes with BASIC PDS
 7.00.

 Code Example
 ------------

 DEF FNa$ = "This is a test string."
 FOR i% = 1 TO 100
   PRINT FRE(-1)   ' Show available far heap.
   PRINT FNa$
 NEXT

 Output
 ------

  179376
 This is a test string.
  179344
 This is a test string.
  179328
 This is a test string.
  179296
 This is a test string.


 290. "Not Enough Memory on Exec" When Using RUN with ISAM File Open

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900525-29 buglist7.00 fixlist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q62815

 From within the QBX.EXE environment or a compiled program, an attempt
 to execute a RUN statement while there are open ISAM files results in
 the run-time error R6007, "Not enough memory on EXEC." The RUN
 statement is documented as having the ability to close all files;
 therefore, this error should not occur.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) version 7.00 for MS-DOS. This
 problem was corrected in BASIC PDS version 7.10.

 To work around the problem in version 7.00, CLOSE all ISAM files
 before executing a RUN statement.

 The following code example demonstrates the problem:

 Code Example
 ------------

 TYPE testtype
   test AS INTEGER
 END TYPE
 OPEN "test.dat" FOR ISAM testtype "runexe" AS #1
 'CLOSE        'If this line is put in, the program will run correctly
 RUN "test"


 291. REPAIR.EXE Should Be ISAMREPR.EXE in BASIC 7.00 Error Guide

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr SR# S900601-15
 Last Modified:  8-JAN-1991    ArticleIdent: Q62818

 In the "Microsoft BASIC 7.0: Language Reference" manual for Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10,
 the error "Database needs repair" at the top of Page 639 incorrectly
 refers to the file REPAIR.EXE for use in repairing ISAM files. The
 correct name for this file is ISAMREPR.EXE.

 The error message summary om Page 639 should be changed read as
 follows:

    An OPEN FOR ISAM statement attempted to open a file that is in
    need of repair. You may want to use the ISAMREPR.EXE utility
    to recover (restore physical integrity to) the database.


 292. In SUB, Variable-Length Near String Array Element Losing Value

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900603-3 buglist7.00 fixlist7.10
 Last Modified:  2-NOV-1990    ArticleIdent: Q62820

 A program compiled with the Near Strings option (without BC /Fs) may
 lose the value of a variable-length string array element under the
 specific conditions described in this article.

 The same program will run correctly when run from the QBX.EXE
 environment or when compiled with the Far Strings option (with BC
 /Fs).

 Microsoft has confirmed this to be a problem with the BC.EXE 7.00
 compiler provided with Microsoft BASIC Professional Development System
 (PDS) version 7.00 for MS-DOS and MS OS/2. This problem was corrected
 in BASIC PDS 7.10.

 This problem does not occur in earlier versions of Microsoft BASIC
 Compiler (BC.EXE).

 Here is a description of the conditions under which the problem occurs
 (as shown in Examples 1 and 2):

 Two variable-length string arrays are dimensioned. Array "A" may be
 dimensioned either dynamically or statically. Array "B" must be
 dimensioned dynamically. Array "B" will lose a value even though the
 program never changes it. A string value is assigned to an element in
 array "B" and this array element is passed as a parameter to a SUB.
 Array "A" is passed to the same SUB either through a parameter list or
 by using SHARED in the DIM statement. Inside the SUB, an element in
 array "A" is directly assigned to a string value returned by the
 RTRIM$, LTRIM$, LEFT$, MID$, or RIGHT$ function. Array "B" is not
 assigned any values in the SUB. But when control is returned to the
 main-level code (or calling procedure), the string value that was
 assigned to an element in array "B" is lost.

 The following two examples exhibit the problem. Both examples pass an
 element in B$() as a parameter variable. In the first example, array
 A$() is declared globally in a DIM SHARED statement. In the second
 example, A$() is passed as a parameter to the SUB.

 Example 1
 ---------

 DECLARE SUB TheSub (temp$)
 REM $DYNAMIC
 DIM SHARED A$(1)
 DIM B$(1)
 B$(1) = "bas"
 PRINT B$(1)
 CALL TheSub(B$(1))
 PRINT B$(1)         'There is no longer anything in B$(1).
 END

 SUB TheSub (temp$)
      A$(1) = RTRIM$("   bob    ")
 END SUB

 Example 2
 ---------

 DECLARE SUB TheSub (temp1$(), temp2$)
 REM $DYNAMIC
 DIM A$(1), B$(1)
 B$(1) = "bas"
 PRINT B$(1)
 CALL TheSub(A$(), B$(1))
 PRINT B$(1)        'There is no longer anything in B$(1).
 END

 SUB TheSub (temp1$(), temp2$)
      temp1$(1) = RTRIM$("   bob    ")
 END SUB

 To work around the problem, alter the program with any one of the
 following choices:

 1. Compile with the Far Strings option (BC /Fs).

 2. Statically dimension the array that loses its value.

 3. Remove the RTRIM$ statement.

 4. Assign a temporary string variable to the string returned by
    RTRIM$, then assign this temporary variable to the desired element
    in array "B".

 The next program is an example of using workaround 4 described above:

 DECLARE SUB TheSub (temp$)
 REM $DYNAMIC
 DIM SHARED A$(1)
 DIM B$(1)
 B$(1) = "bas"
 PRINT B$(1)
 CALL TheSub(B$(1))
 PRINT B$(1)         'B$(1) now contains the correct value.
 END

 SUB TheSub (temp$)
      dummy$ = RTRIM$("   bob    ")  'Use a temporary string variable
      A$(1) = dummy$                 'to work around the problem.
 END SUB


 293. BOOKLOOK "...Forgot ISAM TSR" Despite PROISAM.EXE Being Loaded

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900531-18
 Last Modified: 20-JUN-1990    ArticleIdent: Q62829

 The BOOKLOOK sample program from Microsoft BASIC Professional
 Development System (PDS) version 7.00 displays the misleading error
 message, "You forgot to load the ISAM TSR program," when the file
 BOOKS.MDB is not in the current directory, even though PROISAM.EXE is
 loaded.

 To correct for this error, run BOOKLOOK from the directory that
 contains BOOKS.MDB, or run PROISAMD.EXE instead of PROISAM.EXE.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00.

 The message is shown this way because this is the message printed
 whenever a "Feature Unavailable" error (ERR=73) occurs in BOOKLOOK's
 error handler. BOOKLOOK is made to run with BOOKS.MDB already created;
 therefore, the only reason "Feature Unavailable" would occur in that
 case is if the PROISAM TSR is not loaded.

 PROISAM.EXE allows you to access existing ISAM files, but does not
 allow you to create files, tables, or indexes. To do this, you must
 use PROISAMD.EXE. This explains why loading PROISAMD instead of
 PROISAM corrects the error with BOOKLOOK.


 294. X=(-1*W)^2 Gives "Division by Zero" on 386 with 387; BASIC 7.1

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist7.00 buglist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q62830

 Executing the following line of code on a 80386 machine equipped with
 an 80387 math coprocessor results in a "Division by zero" error:

    X = (-1 * W) ^ 2

 The "Division by zero" error occurs in both the QBX.EXE environment
 and within a compiled .EXE in Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10. The error occurs only on 80386
 computers with 80387 coprocessors.

 Microsoft has confirmed this to be a problem with Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available. This problem does not occur
 with other Microsoft BASIC products.

 The following are two workarounds for the above problem:

 1. Use the DOS command SET NO87=NONE to disable BASIC's use of the 387
    coprocessor. The program will then execute correctly. Note that
    disabling BASIC's use of the coprocessor usually slows program
    execution.

 2. Change the line of code into two lines, using a temporary variable
    to hold the value of (-1 * W), as follows:

       TEMP = (-1 * W)
       X = TEMP ^ 2


 295. 7.00 CREATEINDEX Example Gives "No Current Record" at Run-Time

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr SR# S900606-48
 Last Modified:  8-JAN-1991    ArticleIdent: Q62832

 Running the sample program on Page 73 of the "Microsoft BASIC 7.0:
 Language Reference" manual returns a run-time error of 85, "no current
 record," on the RETRIEVE statement.

 The code should be changed as shown below for the program to run
 correctly.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The sample program found on Page 73 uses a file called BOOKS.MDB, the
 sample ISAM file that SETUP copies to your disk. However, in this
 program, the user-defined type, BookRec, does not match the record
 structure used in BOOKS.MDB. Also the program specifies a table name
 that does not exist in BOOKS.MDB.

 The user-defined type, BookRec, should be defined as follows:

    TYPE BookRec
       IDNum AS DOUBLE
       Price AS CURRENCY
       Edition AS INTEGER
       Title AS STRING * 50
       Publisher AS STRING * 50
       Author AS STRING * 36

 In addition, the table name should be defined as "BookStock" instead
 of "BooksStock".

 The corrected program is as follows:

 DEFINT A-Z
 TYPE BookRec                   'altered user-defined type
    IDNum AS DOUBLE
    Price AS CURRENCY
    Edition AS INTEGER
    Title AS STRING * 50
    Publisher AS STRING * 50
    Author AS STRING * 36
 END TYPE

 DIM Library AS BookRec
 DIM msgtxt AS STRING

 CONST Database = "BOOKS.MDB"
 CONST TableName = "BookStock" 'TableName = BookStock (not BooksStock)
 TableNum = FREEFILE

 OPEN Database FOR ISAM BookRec TableName AS TableNum
 CREATEINDEX TableNum, "A", 0, "Author"
 CREATEINDEX TableNum, "I", 1, "IDNum"
 CREATEINDEX TableNum, "T", 0, "Title"
 CREATEINDEX TableNum, "C", 0, "Price"
 SETINDEX #1, "A"
 CLS : LOCATE 13, 30
 PRINT "choose a key:"
 PRINT SPC(9); "move to:"; TAB(49); " order by: X "
 PRINT : PRINT SPC(9); "F - first record"; TAB(49); "A - Author"
 PRINT : PRINT SPC(9); "L - last record"; TAB(49); "I - ID number"
 PRINT : PRINT SPC(9); "N - next record"; TAB(49); "T - Title"
 PRINT : PRINT SPC(9); "P - previous record"; TAB(49); "C - Cost"
 PRINT : PRINT SPC(9); "Q - Quit"; TAB(49); "X- no order"
 LOCATE 3, 1: PRINT TAB(37); Books; ""
 PRINT STRING$(80, "-");
 VIEW PRINT 5 TO 10

 MOVEFIRST TableNum
 DO
     CLS
     RETRIEVE TableNum, Library
     PRINT "Author:   "; Library.Author;
     PRINT TAB(49); "ID #"; Library.IDNum
     PRINT "Title:      "; Library.Title
     PRINT "Publisher: "; Library.Publisher
     PRINT "cost:     "; Library.Price
     PRINT SPC(30); msgtxt
     PRINT STRING$(64, "-")
     IF GETINDEX$(TableNum) = "" THEN
          PRINT STRING$(15, "-");
     ELSE
          PRINT "index in use: "; GETINDEX$(TableNum);
     END IF

      validkeys$ = "FLNPQATICX"
      DO
          keychoice$ = UCASE$(INKEY$)
      LOOP WHILE INSTR(validkeys$, keychoice$) = 0 OR keychoice$ = ""
      msgtxt = ""

      SELECT CASE keychoice$
      CASE "F"
          MOVEFIRST TableNum
      CASE "L"
          MOVELAST TableNum
      CASE "N"
          MOVENEXT TableNum
          IF EOF(TableNum) THEN
              MOVELAST TableNum
              BEEP: msgtxt = "** at last record **"
          END IF
      CASE "P"
          MOVEPREVIOUS TableNum
          IF BOF(TableNum) THEN
              MOVEFIRST TableNum
              BEEP: msgtxt = "** at first record **"
          END IF
     CASE "Q"
          EXIT DO
     CASE ELSE
          VIEW PRINT
          LOCATE 13, 59: PRINT keychoice$;
          VIEW PRINT 5 TO 10
          IF keychoice$ = "X" THEN keychoice$ = ""
          SETINDEX TableNum, keychoice$
          MOVEFIRST TableNum
      END SELECT
 LOOP

 VIEW PRINT
 DELETEINDEX TableNum, "A"
 DELETEINDEX TableNum, "I"
 DELETEINDEX TableNum, "T"
 DELETEINDEX TableNum, "C"
 CLOSE
 END


 296. No Array Bounds Checking for Arrays in TYPEs in BC 7.00 .EXE

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | docerr SR# S900521-23
 Last Modified: 12-JUN-1990    ArticleIdent: Q62833

 In Microsoft BASIC Professional Development System (PDS) version 7.00,
 the run-time error checking code inserted by the BC /D compiler switch
 does not perform array bounds checking for arrays embedded inside
 user-defined TYPEs. However, this checking is performed inside the
 QBX.EXE environment. This is not a problem with the BC.EXE compiler
 but a design limitation. The overhead required for the check would
 cause speed degradation and a size increase for an .EXE file.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and MS OS/2.

 The BC /D compiler switch (Run-time error checking) inserts array
 bounds checking in a module. Whenever an access on an array is
 attempted with an illegal subscript, the message "Subscript out of
 range" is generated. Without /D, this type of error goes undetected
 under DOS and will most likely result in the corruption of other data.
 It can also cause corruption of code or possibly even parts of the
 operating system itself, which could cause unpredictable results,
 including hanging the machine. Under OS/2, an error of this type would
 cause a protection violation and abort the program. The /D switch
 performs array bounds checking on arrays that are NOT embedded in
 user-defined TYPEs, but won't for arrays that ARE embedded in types.
 However, in the QBX.EXE environment, the checking is done for all
 arrays.

 For example, the following program generates a "Subscript out of
 range" error in the QBX.EXE environment, but does not when compiled
 with the /D switch:

    TYPE aType
       Array (1 TO 100) AS INTEGER
    END TYPE

    DIM aVar as aType

    aVar.Array(1000) = 1000   '1000 as a subscript is out of range


 297. "Out of Stack Space" with ON ERROR, REDIM, GOSUB, Then ERASE

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist7.00 buglist7.10 SR# S900603-4
 Last Modified:  6-AUG-1990    ArticleIdent: Q62892

 When compiled with the Far Strings option (BC /FS) and run as a .EXE
 program, the program below results in the message "Out of stack space
 in line 4." This problem does not occur when the program is run in the
 QBX.EXE environment or when it is compiled with the Near Strings
 option and run. It also does not occur when lines 1 and 9 are removed,
 when line 4 is removed, or when the number of arrays erased is
 decreased by one or more.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 Code Example
 ------------

    1 ON ERROR GOTO 9
    2 FOR i% = 1 TO 100
    3   REDIM a$(1), b$(1), c$(1)
    4   GOSUB 8
    5   ERASE a$, b$, c$
    6 NEXT i%
    7 END
    8 RETURN
    9 RESUME


 298. BASIC 7.00 SETMEM Example Uses malloc/free; Should Be halloc

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900607-93 docerr
 Last Modified:  8-JAN-1991    ArticleIdent: Q63003

 The example for the SETMEM() function on Page 333 of the "Microsoft
 BASIC 7.0: Language Reference" manual (for 7.00 and 7.10) incorrectly
 uses the C malloc() and free() functions to allocate and free memory
 instead of the correct halloc() and hfree() functions.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 To be able to free memory for BASIC to reallocate, it is necessary to
 use the heap functions [halloc() and hfree()] instead of normal memory
 allocation functions. If SETMEM() is used to reallocate memory for
 BASIC after using free(), no memory will be reallocated. With hfree(),
 the memory will be returned for use with BASIC.

 For more information on using SETMEM() with C functions, query on the
 following keywords:

    SETMEM and halloc

 Code Example
 ------------

 The corrected C code for the SETMEM() example is as follows:

 void far cfunc(bytes)
 int bytes;
 {
     char *halloc();
     char *workspace;

     /* Allocate working memory (halloc) using amount BASIC freed. */
     workspace=halloc((unsigned) bytes, 1);

     /* Working space would be used here. */

     /* Free memory (hfree) before returning to BASIC */
     hfree(workspace);
 }

 Note: The C code must be compiled using the huge model (/AH).


 299. "Unknown Symbol" Setting Breakpoint on Label in CodeView 3.00

 Product Version(s): 6.00 6.00b 7.00 | 6.00 6.00b 7.00
 Operating System:   MS-DOS          | OS/2
 Flags: ENDUSER | SR# S900606-93 B_QuickBas S_CodeView
 Last Modified: 20-JUN-1990    ArticleIdent: Q63009

 When debugging a BASIC program in Microsoft CodeView, a breakpoint
 can be set on a BASIC label by typing the following command

    BP <label>

 where <label> is any valid BASIC label. In CodeView versions 2.x, this
 command works whether or not the program is started. In CodeView
 version 3.00, the program must have started executing before this
 command will work. If the program has not been started, CodeView 3.00
 generates the error message "Unknown symbol."

 This information applies to programs run under CV.EXE and CVP.EXE
 versions 2.x and 3.00 when compiled with the BC.EXE compiler that
 comes with QuickBASIC versions 4.00, 4.00b, and 4.50, with Microsoft
 BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS OS/2, or with
 Microsoft BASIC Professional Development System (PDS) version 7.00 for
 MS-DOS and MS OS/2.

 Breakpoints can also be set in four other ways. Each of the following
 methods can be used before the program is actually started:

 1. Use the following command

       bp .<line>

    where <line> is the line number that CodeView displays next to the
    label (not a BASIC line number). This works whether or not the
    program is started.

 2. Use the mouse to double-click the line you want to break on.

 3. Position the cursor on the line you want to break on and then
    choose Set Breakpoint from the Watch menu.

 4. Position the cursor on the line you want to break on and then press
    the F9 key.


 300. Cannot Display Array Pointer or Full BASIC Array with CodeView

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S900606-86 B_QuickBas S_CodeView
 Last Modified:  5-SEP-1990    ArticleIdent: Q63010

 The BC.EXE compiler in QuickBASIC versions 4.00, 4.00b, and 4.50, in
 Microsoft BASIC Compiler versions 6.00 and 6.00b, and in Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 can
 create programs that will run under Microsoft CodeView versions 2.x
 and 3.00. However, arrays or arrays in TYPEd records give "?CANNOT
 DISPLAY" for the CodeView commands ?, ??, or w?. This is not a problem
 with either the BASIC compiler or CodeView, but represents a
 limitation of debugging BASIC programs in CodeView.

 This information applies to programs run under CV.EXE and CVP.EXE 2.x
 and 3.00 when compiled with the BC.EXE compiler that comes with
 QuickBASIC versions 4.00, 4.00b, and 4.50, Microsoft BASIC Compiler
 versions 6.00 and 6.00b for MS-DOS and MS OS/2, and Microsoft BASIC
 PDS versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 In CodeView, the ? command is used to display an expression. The ??
 command is used to graphically view a variable in a dialog box. ??
 will expand a variable, such as a TYPEd record, to show the fields and
 the value currently assigned to each field.

 This limitation also applies to the CodeView 3.00 command ??, where
 the graphical display (??) can expand the elements of an array. For
 example, an array in C (int intarray[10];) can be displayed as a far
 pointer with ? and expanded to its elements with ??. With CodeView 2.x
 and C version 5.10, the ?? command won't display the elements of a C
 array, but will display the far pointer value that is the array's
 address.


 301. LINK /F of Overlaid BRT70xx Program Causes "Invalid Runtime"

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900615-62 buglist7.00 fixlist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q63040

 LINK-overlaid programs using the BRT70xxx.EXE run-time module from
 Microsoft BASIC Professional Development System (PDS) version 7.00
 should not be LINKed with the /F (/FARCALLTRANSLATION) option. When
 this is done, a CALL to an overlay causes an attempt to reload the
 run-time module. This results in an "Invalid runtime module" message
 and, in most cases, the machine hangs.

 To work around this problem, LINK without the /F option or compile
 for a stand-alone .EXE (with the BC /O option).

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 version 7.00. This problem does not occur in BASIC PDS 7.10.

 The /F (/FARCALLTRANSLATION) LINK option is described on Page 241 of
 the "Microsoft CodeView 2.3 and Utilities User's Guide" for Microsoft
 BASIC PDS version 7.00 for MS-DOS. Using this option may produce a
 slight gain in speed and size of executables by translating far calls
 to near calls. However, attempts to optimize overlaid calls cause a
 problem with the run-time module. Thus, /F should not be used with an
 overlaid program that is using the run-time module.

 Code Example
 ------------

 The following programs (which are separate .BAS source files)
 compose a simple overlaid program that demonstrates the problem:

 CALLOVL.BAS
 -----------

 INPUT "Call overlay (Y/N)? ",i$
 IF ((i$ = "Y") OR (i$ = "y")) THEN CALL test
 END

 OVL.BAS    **** NOTE: This is a file separate from the above file!
 -------

 SUB test
   PRINT "in overlay"
 END SUB

 The following are the compile and LINK lines to demonstrate the
 problem with the above separate modules:

    BC CALLOVL;
    BC OVL;
    LINK /F CALLOVL+(OVL);

 These programs can be run properly if either /O is added to each BC
 command line or the /F is omitted from the LINK line.


 302. Overlaid Modules Loaded into EM Only When 1st Overlay Called

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900608-158
 Last Modified:  5-SEP-1990    ArticleIdent: Q63161

 When using expanded memory with an overlaid program, the overlaid
 modules are not loaded when the EXE file is invoked. They remain on
 disk until the first overlay is called. When this occurs, all the
 overlaid modules are loaded from disk into expanded memory. From then
 on, the overlays are swapped to and from expanded memory and the disk
 is no longer needed for that purpose.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10.

 For more information about using linker overlays in BASIC PDS 7.00 and
 7.10, search for a separate article in this Knowledge Base with the
 following words:

    LINK and overlays and expanded and memory and BASIC

 To demonstrate this characteristic of BASIC overlays, boot up with an
 Lotus/Intel/Microsoft (LIM) version 4.0 Expanded Memory Specification
 (EMS) device driver and compile and link the three modules below as
 follows:

    bc main;
    bc overlay1;
    bc overlay2;

    link main+(overlay1)+(overlay2);

 MAIN.BAS
 --------

    '* Note: The disk activity will be most obvious if this test
    '        is run on a floppy drive.
    PRINT "MAIN"
    PRINT "HIT ANY KEY TO LOAD OVERLAYS INTO EMS"
    SLEEP
    CALL ovl1
    PRINT "OVERLAYS LOADED"
    PRINT "HIT ANY KEY TO CALL SECOND OVERLAY"
    PRINT "THERE SHOULD BE NO DISK ACTIVITY IF YOU HAVE EMS"
    SLEEP
    CALL ovl2
    PRINT "HIT ANY KEY TO END THE PROGRAM"
    SLEEP
    END

 OVERLAY1.BAS
 ------------

    SUB ovl1
       PRINT "OVERLAY1"
    END SUB

 OVERLAY2.BAS
 ------------

    SUB ovl2
       PRINT "OVERLAY2"
    END SUB

 When run, the resulting EXE file (MAIN.EXE) produces the following
 output:

    MAIN
    OVERLAY1
    OVERLAY2

 However, before "OVERLAY1" is displayed, there will be disk activity
 while the code for overlay1 is loaded into the overlay area of
 conventional memory (for execution) and overlay2 is loaded into
 expanded memory. To see this clearly, run MAIN.EXE from a floppy
 drive. When overlay2 is called, there will be no disk activity because
 it will be swapped in from expanded memory.

 Note that this is not a problem with BASIC PDS 7.00 or 7.10, but a
 feature of the overlay manager. However, it can present a speed
 problem for applications that rely on the quickness of swapping from
 expanded memory for the first-called overlay. To work around this,
 make the first executable statement in your program a CALL to an
 additional overlay with no code in it. When it is called, all the
 other overlays will be loaded into expanded memory. The functionality
 and speed of the application will remain intact while the difference
 in EXE size and load time will be minimal.

 For example, the module MAIN.BAS above would be modified as follows:

    CALL loadovls
    PRINT "MAIN"
    CALL ovl1
    CALL ovl2
    END

 The subprogram "loadovls" (meaning "load overlays") would be coded as
 the following:

    SUB loadovls
    END SUB

 When loadovls is called, the code for overlay1 and overlay2 will be
 loaded into expanded memory. This eliminates the disk activity between
 the display of "MAIN" and "OVERLAY1".


 303. When Out of Memory in QBX 7.00, Instant Watch Reruns Program

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 buglist7.10 SR# S900606-88
 Last Modified:  6-AUG-1990    ArticleIdent: Q63195

 Trying to set an Instant Watch variable on a large variable-length
 string in QBX.EXE can cause QBX to restart the program from the
 beginning if the program is almost out of memory. When the program is
 almost out of memory, QBX fails to add the watch and instead reruns
 the program.

 Microsoft has confirmed this to be a problem with the QBX.EXE
 environment that comes with Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS. We are researching
 this problem and will post new information here as it becomes
 available.

 To reproduce the problem, the following conditions must be duplicated:

 1. There must be less than 15K of memory free. Use PRINT FRE(-1) to
    show this.

 2. Create a large string, such as the following:

       a$=STRING$(10000,62)

 3. Stop the program just after the string is assigned. For instance,
    step through the program with the F8 key, or put a breakpoint on
    the line after you create the string.

 4. Move the cursor back up to the string variable.

 5. Press SHIFT+F9 to set an Instant Watch.

 6. If QBX allows you to set the watch, either decrease the amount of
    free memory, or keep setting Instant Watches on the same variable.
    Eventually, QBX will fail to add the watch, and will rerun the
    program from the beginning.

 Code Example
 ------------

 Use the above steps to reproduce the problem with the code below. The
 following code was used to reproduce this problem on a machine where
 CHKDSK.COM showed 508,200 bytes free:

    REM $DYNAMIC
    CLEAR
    REDIM array1(19000) AS DOUBLE
    PRINT
    a$ = STRING$(10000, 33)
    PRINT a$       ' Stop the program here. Move the cursor to a$.
    PRINT FRE(-1)  ' Press SHIFT+F9 several times.
    PRINT
    PRINT
    PRINT
    PRINT
    PRINT
    PRINT


 304. Using PWB with Both BASIC PDS 7.10 and C PDS 6.00

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900618-153 S_C S_PWB
 Last Modified:  6-SEP-1990    ArticleIdent: Q63197

 The Programmer's WorkBench (PWB) is designed as a multilanguage,
 project-oriented development environment for MS-DOS and MS OS/2.

 The key to each language's interface into PWB is the .HLP files and
 the .MXT files for MS-DOS and the .PXT files for MS OS/2. The .HLP
 files are the help files for each language product. The .MXT and .PXT
 files are PWB extensions for each language that define menus and
 dialog boxes for each compiler. Thus, to use PWB with both BASIC and
 C, you must copy the PWBC.MXT file (for MS-DOS) or PWBC.PXT file (for
 MS OS/2) into the directory containing the BASIC PWB.EXE file, and SET
 the HELPFILES environment variable to find both the C and BASIC help
 files.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.10 and to Microsoft C PDS version 6.00 for
 MS-DOS and MS OS/2.


 305. Main Module Must Be First BASIC File in Program List for PWB

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900618-147 S_PWB PWB
 Last Modified:  5-SEP-1990    ArticleIdent: Q63198

 The main module in a multiple-module program must be listed as the
 first BASIC source file in the Program List for PWB.EXE (the
 Programmer's WorkBench) to properly make the EXE file. If a
 supporting module is listed first, its module-level code (virtually
 nonexistent in most cases) is treated as the main entry point. This
 produces an EXE that is approximately the correct size, but does
 nothing.

 To convert a given module in the Program List to the main module,
 choose that module in the Edit Program List dialog and choose the To
 Top Of List button.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.10 for MS-DOS and MS OS/2.

 For example, to make a Program List containing everything necessary
 for the UIDEMO example program, UIDEMO.BAS must be listed at the
 beginning of the BASIC files list. The incorrect and correct orders
 are demonstrated below.

 The following order of files does NOT create a working UIDEMO.EXE:

    GENERAL.BAS
    MENU.BAS
    MOUSE.BAS
    UIDEMO.BAS
    WINDOW.BAS
    UIASM.OBJ
    QBX.LIB

 The above order does not work because GENERAL is taken as the main
 module. Since GENERAL.BAS has no executable statements at the module
 level, the program does nothing when run.

 The correct order must have UIDEMO.BAS first:

    UIDEMO.BAS
    GENERAL.BAS
    MENU.BAS
    MOUSE.BAS
    WINDOW.BAS
    UIASM.OBJ
    QBX.LIB


 306. BUILDRTM with PROISAM(D) Must Have OBJ and LIB in Export List

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900620-71
 Last Modified: 17-JAN-1991    ArticleIdent: Q63268

 To build ISAM support into a custom run-time module (instead of using
 ISAM from the separate TSR program), you must specify in BUILDRTM's
 Export List file both the object (.OBJ) and library (.LIB) forms of
 your chosen ISAM library (PROISAM or PROISAMD). If either the object
 or library form is left out of the Export List file, LINK.EXE flags
 numerous occurrences of L2025 ("Symbol defined more than once") and
 L2029 ("Unresolved external").

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The following Export List file (arbitrarily named ISAM.EXP) shows the
 files that need to be specified to put PROISAMD into a custom run-time
 module:

    # ISAM.EXP
    #OBJECTS
    PROISAMD.OBJ
    # (specify additional OBJs here)
    #LIBRARIES
    PROISAMD.LIB

 The command line to build the custom run-time module specified by the
 above Export List file is as follows:

    BUILDRTM /LR ISAMRUN ISAM.EXP

 This BUILDRTM command outputs three files: IMPORT.OBJ and ISAMRUN.LIB
 (used to resolve LINK references to your custom run-time module) and
 ISAMRUN.EXE (your custom run-time module).

 To LINK the above run-time module to a BASIC program, use the
 following LINK command:

    LINK IMPORT.OBJ+yourfile.OBJ,yourfile.EXE,,ISAMRUN.LIB;

 For more information about using BUILDRTM.EXE, see Chapter 21,
 "Building Custom Run-Time Modules," in the "Microsoft BASIC 7.0:
 Programmer's Guide" for 7.00 and 7.10.


 307. B_OVREMAP in 7.00 Programmer's Guide Should Be B_OVLREMAP

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900613-56 docerr
 Last Modified: 16-JAN-1991    ArticleIdent: Q63422

 Page 613 of "Microsoft BASIC 7.0: Programmer's Guide" (for versions
 7.00 and 7.10) incorrectly refers to the B_OVREMAP routine. This
 routine (contained in the BASIC run-time) is actually named
 B_OVLREMAP.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The B_OVLREMAP routine is used to remap the overlays in expanded
 memory after the state has changed. To use this from a BASIC program,
 you must map the name to a usable SUB name using the ALIAS keyword in
 the DECLARE SUB line.

 Code Example
 ------------

 The following code example demonstrates the use of the B_OVLREMAP
 routine:

    DECLARE SUB OvlReMap ALIAS "B_OVLREMAP"
    SHELL             'Do something to expanded memory in the SHELL
    CALL OvlReMap     'Remap overlays in expanded memory after SHELL
    END


 308. How to Set Up Programmer's WorkBench (PWB) for BASIC PDS 7.10

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900702-109 s_pwb
 Last Modified:  5-SEP-1990    ArticleIdent: Q63623

 The following information applies to Microsoft BASIC Professional
 Development System (PDS) version 7.10 for MS-DOS and MS OS/2.

 To successfully begin using the Programmer's WorkBench (PWB.EXE), you
 must make several changes in your environment, as follows:

 1. The file NEW-VARS.BAT (a batch file for MS-DOS) or NEW-VARS.CMD (a
    command file for MS OS/2) must be executed before using PWB.EXE.
    These files are located in the BC7\BIN directory (for MS-DOS) or
    BC7\BINP directory (for MS OS/2) if the default directory names
    were chosen during setup. The information in these files can be
    added directly to your AUTOEXEC.BAT (for MS-DOS) or CONFIG.SYS (for
    MS OS/2), as shown in the "More Information" section below.

 2. The file TOOLS.PRE must be renamed to TOOLS.INI or appended to an
    existing TOOLS.INI. The TOOLS.INI must be in the directory
    specified by the environment variable INIT. The TOOLS.PRE file is
    located in the BC7\BINP directory if the default directory names
    were chosen during setup.

 3. For MS OS/2, the LIBPATH environment variable must contain the
    directory where BASIC's run-time DLLs are stored. These files are
    located in the BC7\BINP directory if the default directory names
    were chosen during setup.

 4. To use Microsoft C with PWB.EXE in interlanguage calling, the file
    PWBC.MXT (for MS-DOS) or PWBC.PXT (for MS OS/2) must be unpacked
    and copied from the distribution disks to the directory containing
    PWB.EXE. PWB.EXE is located in the BC7\BIN directory (for MS-DOS)
    or the BC7\BINP directory (for MS OS/2) if the default directory
    names were chosen during setup. To find the disk PWBC.MXT or
    PWBC.PXT is located on, look in the PACKING.LST file on DISK 1 of
    the distribution disks.

 5. After any changes have been made to the AUTOEXEC.BAT file or
    CONFIG.SYS file, your machine must be rebooted.

 The following is more information about requirements 1 through 4
 above:

 1. The information in the NEW-VARS.BAT or NEW-VARS.CMD files can be
    added directly to your AUTOEXEC.BAT (for MS-DOS) or CONFIG.SYS (for
    MS OS/2).

    To avoid LINK and compile problems, make sure the directory for
    PWB.EXE comes first in your PATH.

    The following lines must be added to (or modified if the
    environment variables already exist) your AUTOEXEC.BAT file (for
    use with MS-DOS):

       set PATH=c:\bc7\bin;c:\bc7\binb;
       set LIB=c:\bc7\lib;
       set INCLUDE=c:\bc7\src;
       set HELPFILES=c:\bc7\help;

    The following lines must be added to (or modified if the
    environment variables already exist) your CONFIG.SYS file (for
    use with MS OS/2):

       set PATH=c:\bc7\binp;c:\bc7\binb;
       set LIB=c:\bc7\lib;
       set INCLUDE=c:\bc7\src;
       set HELPFILES=c:\bc7\help;

 2. The environment variable for INIT should resemble the following if
    your TOOLS.INI file is in the directory called INIT:

       SET INIT=C:\INIT;

    To append TOOLS.PRE to TOOLS.INI, use the following command:

       COPY TOOLS.INI + \BC7\BINB\TOOLS.PRE

 3. A sample LIBPATH after using the default setup for MS OS/2 and
    Microsoft BASIC PDS 7.10 is as follows:

       LIBPATH=C:\OS2\DLL;C:\;C:\BC7\BINP;

 4. To unpack the files PWBC.MXT and PWBC.PXT, the commands are as
    follows:

       UNPACK A:PWBC.MX$ PWBC.MXT
       UNPACK A:PWBC.PX$ PWBC.PXT


 309. "Permission Denied" If SHELL to 7.00 .EXE Using ISAM from TSR

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900702-42 buglist7.00 buglist7.10
 Last Modified:  2-NOV-1990    ArticleIdent: Q63782

 If you SHELL from one program that uses ISAM to another ISAM program
 that uses the PROISAM.EXE or PROISAMD.EXE terminate-and-stay-resident
 (TSR) program, a "Permission Denied" error occurs when the OPEN
 statement is executed in the child (SHELLed) process (see Example 2
 below). This problem does not occur when ISAM support is linked into
 the .EXE programs instead of using the TSR program.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10. We are
 researching this problem and will post new information here as it
 becomes available.

 To work around this problem, use a CHAIN statement instead of SHELL,
 or LINK ISAM support to your .EXE instead of using the ISAM TSR
 program.

 In addition, SHELLing to the ISAM utilities (ISAMIO.EXE, ISAMCVT.EXE,
 ISAMREPR.EXE, or ISAMPACK.EXE) may generate unusual error messages,
 because they are not designed to be SHELLed; this is not a software
 problem but is a design limitation. For example, ISAMPACK.EXE fails
 with the message "Unknown error number." A workaround is shown below
 in Example 1.

 Note that the SETUP.EXE program for BASIC PDS 7.00 and 7.10 lets you
 choose one of the following four ISAM support options for compiled
 .EXE programs:

 1. ISAM Routines in TSR
 2. ISAM Routines in LIB, Support Database Creation and Access
 3. ISAM Routines in LIB, Support Database Access Only
 4. No ISAM support

 Only Option 1 creates PROISAM.EXE and PROISAMD.EXE TSR programs that
 can be used with BASIC compiled .EXE programs. The TSR program created
 in Option 1 can also be used in QBX.EXE. Options 2 and 3 create
 PROISAM.EXE and PROISAMD.EXE TSR programs that CANNOT be used in
 compiled .EXE programs, and that can only be used by QBX.EXE and the
 ISAM utilities (ISAMIO.EXE, ISAMCVT.EXE, ISAMREPR.EXE, and
 ISAMPACK.EXE). Options 2 and 3 create .LIB libraries for linking ISAM
 support into your .EXE programs. The fourth SETUP option does not copy
 any ISAM-related files onto your computer.

 A problem occurs whenever a SHELLed (child) process attempts to access
 the PROISAM or PROISAMD TSR program. Specifically, the problem occurs
 when you SHELL to an ISAM utility (which requires the TSR program --
 see Example 1), or SHELL to a BASIC .EXE program that requires the
 ISAM TSR (see Example 2).

 Example 1
 ---------

 Because the ISAM utilities (ISAMIO.EXE, ISAMCVT.EXE, ISAMREPR.EXE, or
 ISAMPACK.EXE) require the ISAM TSR program, the best way to work
 around the SHELLing problem is to link the BASIC .EXE (the parent
 process that executes the SHELL) to the ISAM .LIB, and then SHELL to
 an MS-DOS batch (.BAT) file that loads the TSR program, executes the
 ISAM utility, and then unloads the TSR program. The following is an
 example of this type of batch file:

    REM  Start PACK.BAT
       PROISAMD
       ISAMPACK isamfile.dat
       PROISAMD /D
    REM  End PACK.BAT

 Example 2
 ---------

 The following program (when SHELLed to itself or any other program
 that OPENs any ISAM file) will cause a "Permission Denied" error in
 the SHELLed copy:

    ' ISAMTEST.BAS
    TYPE test
      x AS INTEGER
    END TYPE
    OPEN "test" FOR ISAM test "test" as #1
    CLOSE #1
    INPUT "Do you want to shell?", a$
    IF a$="Y" THEN SHELL "ISAMTEST"    ' Put the name of this .EXE here.
    END

 Compile and link this program as follows:

    BC ISAMTEST.BAS;   (BC compile options don't affect the problem)
    LINK ISAMTEST;

 To duplicate the problem, run the PROISAM.EXE or PROISAMD.EXE TSR
 program, then run the above program. To work around the problem, link
 ISAM support to the program instead of using the ISAM TSR program, or
 use CHAIN instead of SHELL.

 Note that if you chose the "ISAM routines in TSR" option during
 SETUP.EXE and also retained component files during SETUP.EXE, there is
 a special way to LINK ISAM support into your stand-alone .EXE program,
 as described in a separate article, which can be found by using the
 following query in this Knowledge Base:

    LINK and ISAM and component and even and SETUP and TSR


 310. In 7.00 UI Toolbox, WindowOpen Must Start at Row 3, Column 2

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900706-34
 Last Modified: 10-JAN-1991    ArticleIdent: Q63797

 When using the WindowOpen SUBprogram from the User Interface (UI)
 Toolbox in Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10, coordinates for the upper left-hand window
 location must be below row 2 and to the right of column 1.

 The reason for this is that the coordinates that you are giving
 represent the location of the first printable text space on the
 screen, not the actual upper left-hand corner of the window.
 Therefore, there has to be room for the window border to be drawn
 around the box.

 If you try to display a window with an upper left-hand coordinate of 1
 for col1%, or 1 or 2 for row1%, no window will be displayed on the
 screen and no error will display.

 Code Example
 ------------

 'The main body of code consists of the initialization routines that
 'allow the use of the User Interface (UI) Toolbox. The $INCLUDE files
 'contain the necessary TYPE definitions and SUB declarations. The
 'COMMON SHARED statements contain the necessary global variables for
 'communicating with the UI Toolbox routines.

 REM $INCLUDE: 'window.bi'
 REM $INCLUDE: 'mouse.bi'
 REM $INCLUDE: 'menu.bi'
 REM $INCLUDE: 'general.bi'

 COMMON SHARED /uitools/ glomenu AS MenuMiscType
 COMMON SHARED /uitools/ glotitle() AS MenuTitleType
 COMMON SHARED /uitools/ gloitem() AS MenuItemType
 COMMON SHARED /uitools/ glowindow() AS windowtype
 COMMON SHARED /uitools/ globutton() AS buttontype
 COMMON SHARED /uitools/ gloedit() AS editfieldtype
 COMMON SHARED /uitools/ glostorage AS windowstoragetype
 COMMON SHARED /uitools/ glowindowstack() AS INTEGER
 COMMON SHARED /uitools/ globuffer$()

 DIM glotitle(MAXMENU) AS MenuTitleType
 DIM gloitem(MAXMENU, MAXITEM) AS MenuItemType
 DIM glowindow(MAXWINDOW) AS windowtype
 DIM globutton(MAXBUTTON) AS buttontype
 DIM gloedit(MAXEDITFIELD) AS editfieldtype
 DIM glowindowstack(MAXWINDOW) AS INTEGER
 DIM globuffer$(MAXWINDOW + 1, 2)

 CLS

 'Windowinit and Menuinit initialize all of the necessary
 'variables for use with the UI Toolbox routines.

 MenuInit
 windowinit

 'The following windowopen statement will not create a window on the
 'screen, because the second parameter must be greater than 2, and the
 'third parameter must be greater than 1:
 '             /----- 2nd parameter must be greater than 2.
 '             v
 windowopen 1, 2, 1, 20, 20, 15, 0, 15, 0, 6, 0, 0, 0, 0, 2, "test #1"
 '                ^----- 3rd parameter must be greater than 1.

 SLEEP
 'The following windowopen statement correctly opens a window
 'that will have the minimum possible upper left-hand corner
 'coordinates:

 windowopen 2, 3, 2, 10, 20, 15, 0, 15, 0, 6, 0, 0, 0, 0, 2, "test #2"


 311. 7.00 UI Toolbox MENU.BAS Correction, Narrow Menu Selectability

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 buglist7.10
 Last Modified:  2-NOV-1990    ArticleIdent: Q63799

 The User Interface (UI) Toolbox provided in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10
 incorrectly allows a mouse cursor to choose a menu option from outside
 the confines of a narrow pull-down menu.

 Microsoft has confirmed this to be a problem in Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS. The correction is provided below.

 To correct this problem, the source code of MENU.BAS can be changed to
 correctly choose items in a narrow pull-down menu. Change the
 following IF statement found in the SUB MenuDo near the line label
 "menuDoShowPullDown:". (When you load MENU.BAS into the QBX.EXE
 editor, this label is at line number 650, and the IF statement is
 located at line 660.)

 Change the following line

      LEN(GloTitle(currMenu).text)
 to
      LEN(RTRIM$(GloTitle(currMenu).text))

 in both of the following places:

      IF GloTitle(currMenu).rColItem - GloTitle(currMenu).lColItem _
                < LEN(GloTitle(currMenu).text) THEN
           GloTitle(currMenu).rColItem = GloTitle(currMenu).lColItem _
                + LEN(GloTitle(currMenu).text)
      END IF

 Note: The underscore characters (_) above indicate line-continuation
 characters. The block IF statement actually appears as three lines in
 the original source code of MENU.BAS.

 The changed code is as follows:

      IF GloTitle(currMenu).rColItem - GloTitle(currMenu).lColItem _
                < LEN(RTRIM$(GloTitle(currMenu).text)) THEN
           GloTitle(currMenu).rColItem = GloTitle(currMenu).lColItem _
                + LEN(RTRIM$(GloTitle(currMenu).text)
      END IF

 To enable correct handling of narrow pull-down menus, this change
 should be made and the libraries rebuilt as follows:

      BC /X/FS MENU.BAS;

      LIB UITB -+MENU;     [Note: UITB.LIB is the library that
                                  GENERAL.BAS outlines how to build.]

      LINK /Q UITB.LIB,UITB.QLB,,QBXQLB.LIB;

 The correction in this article is the same as for a different symptom
 described in a separate article, where garbage characters appear after
 selecting a menu at or to the right of the 64th column. To find this
 and other problems with the UI Toolbox, query in this Knowledge Base
 on the following words:

    user and interface and toolbox and buglist7.00


 312. Illegal RESUME NEXT Hangs QBX After ON LOCAL ERROR RESUME NEXT

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900615-135 buglist7.00 buglist7.10
 Last Modified:  6-AUG-1990    ArticleIdent: Q63811

 QBX.EXE hangs if an illegal RESUME NEXT statement is encountered in an
 IF statement inside a SUB where the statement ON LOCAL ERROR RESUME
 NEXT is active. This problem does not occur in a compiled and linked
 .EXE program.

 Microsoft has confirmed this to be a problem with QBX.EXE in Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS. We are researching this problem and will post new information
 here as it becomes available.

 The problem can be worked around by knowing and not programming
 illegal "RESUME without error" conditions.

 Instead of hanging the program below, the QBX environment should
 return an Error 20 ("RESUME without error"), which means that there is
 no active error-handling routine from which to RESUME. Error 20 should
 then have been automatically handled by the ON LOCAL ERROR RESUME NEXT
 statement (which does a valid RESUME NEXT).

 A RESUME NEXT statement by itself is only valid when it is within an
 error-handling routine that was an object of an ON [LOCAL] ERROR GOTO
 <linelabel> statement. When the program below is compiled and linked
 into an EXE, the .EXE does not hang, and it correctly returns and
 handles error 20.

 Code Example
 ------------

 The following code example hangs QBX.EXE on the indicated line. Note
 that this program shows illegal usage of the second RESUME NEXT, which
 should have produced error 20. When run as an .EXE program, this code
 successfully returns error 20 and handles the error correctly with the
 local error handler:

 CALL test
 SUB test
   ON LOCAL ERROR RESUME NEXT
   ERROR 1
   ' The following RESUME NEXT is a programming error:
   IF ERR = 1 THEN RESUME NEXT   '*** This line hangs in QBX.EXE
   ' The above statement correctly causes error 20 ("RESUME without
   ' error") in a .EXE program, and ERR now returns 20 and prints as
   ' follows:
   PRINT "This is next line after programming error 20, and ERR= "; ERR
   PRINT "Now ending subprogram"
 END SUB


 313. How to LINK PROISAMD.LIB to .EXE Even If SETUP "ISAM in TSR"

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900706-104
 Last Modified:  6-SEP-1990    ArticleIdent: Q63834

 The following technique gives you the setup configuration with the
 greatest flexibility of choice for ISAM support (as either a TSR
 [terminate-and-stay resident] program or linkable .LIB) in compiled
 .EXE programs.

 If you chose "ISAM Routines in TSR" (instead of "ISAM Routines in
 LIB") when you ran SETUP.EXE, then to make a standalone .EXE program
 (that uses ISAM) that does not require the PROISAMD.EXE or PROISAM.EXE
 TSR program, you must LINK with the PROISAMD.OBJ and PROISAMD.LIB
 component libraries in the linker's object list. This technique
 requires that you choose to retain component libraries when you run
 SETUP.EXE.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 under MS-DOS. This also applies to
 version 7.10 under MS OS/2.

 With BASIC PDS 7.00, there are four SETUP.EXE options for installing
 ISAM support for compiled .EXE programs:

 1. ISAM Routines in TSR
 2. ISAM Routines in LIB, Support Database Creation and Access
 3. ISAM Routines in LIB, Support Database Access Only
 4. No ISAM support

 Only Option 1 creates PROISAM.EXE and PROISAMD.EXE TSR programs that
 can be used with BASIC compiled .EXE programs. The TSR program created
 in Option 1 can also be used in QBX.EXE. Option 1 is the default since
 it consumes the least disk space.

 Options 2 and 3 create PROISAM.EXE and PROISAMD.EXE TSR programs that
 CANNOT be used in compiled .EXE programs and that can only be used by
 QBX.EXE and the ISAM utilities (ISAMIO.EXE, ISAMCVT.EXE, ISAMREPR.EXE,
 and ISAMPACK.EXE). If you choose Option 2 or 3 and you want ISAM
 support in your .EXE program, you must link to the ISAM .LIB files
 instead of using the TSR support for ISAM.

 SETUP Option 4 does not copy any ISAM-related files onto your
 computer.

 You may want to have the option of creating .EXE programs with full
 ISAM support provided either in the TSR program or linked from
 libraries. This can be accomplished by choosing Option 1 ("ISAM
 Routines in TSR") and LINKing with PROISAMD.OBJ and PROISAMD.LIB in
 the object list, as follows:

    LINK /NOE ISAMPROG.OBJ+PROISAMD.OBJ+PROISAMD.LIB;

 The following are some important notes about the above LINK command
 line:

 1. The NOExtended library search option (/NOE) is necessary to prevent
    "Symbol Defined More than Once (L2025)" errors.

 2. Both object (PROISAMD.OBJ) and library (PROISAMD.LIB) files are
    required to LINK properly.

 3. The PROISAMD.OBJ is normally deleted with component libraries by
    SETUP.EXE. You must choose to retain component libraries when you
    run SETUP.EXE to retain this necessary file.

 4. PROISAMD.LIB must be specified in the object list instead of the
    library list on the LINK command line, as shown. (When LINKing a
    library in the object list, all object files contained in that
    library are LINKed into the EXE, as opposed to only the routines
    that are not otherwise resolved.)

 5. ISAMPROG.BAS must be compiled with the BC /O (standalone) option.
    If you don't compile with BC /O, then the LINK error L2029
    "Unresolved external" error will occur for 'b$IsamRtmUsed' and
    'B$DOS3CHECK'.

 Code Example
 ------------

 The following code example would normally require the PROISAMD.EXE TSR
 program (when the "ISAM Routines in TSR" option is chosen during
 SETUP), but using the LINK line given below, the TSR program is not
 necessary.

 Compile and link as follows:

    BC ISAMPROG /O;
    LINK /NOE ISAMPROG.OBJ+PROISAMD.OBJ+PROISAMD.LIB;

 ' Name this source file as follows: ISAMPROG.BAS
 TYPE test
   x AS INTEGER
 END TYPE
 OPEN "ISAMFILE" FOR ISAM test "table" AS #1
 CLOSE #1
 END


 314. Incorrect SEEK in Example in BASIC 7.00 Language Reference

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900712-2 docerr
 Last Modified: 15-JAN-1991    ArticleIdent: Q63901

 On page 323 of the "Microsoft BASIC 7.0: Language Reference" manual,
 the example for the SEEK statement (on the 6th line from the bottom)
 incorrectly shows that the process for backing up a file is as
 follows:

    SEEK #1, SEEK(1) - LEN(RecordVar)

 This statement is the correct method for backing up one record
 position in a binary file. In a binary file, the SEEK function refers
 to a byte in the file. Therefore, to move forward or backward a
 record, you would increment or decrement by the number of bytes in
 each record of the file.

 However, because the file in the SEEK example on page 323 is a RANDOM
 access file, a SEEK function refers to each record in the file, not to
 each byte in the file. Thus, the statement should be corrected to read
 as follows:

    SEEK #1, SEEK(1) - 1

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 315. How to Scroll Text in BASIC Protected Mode Program Using API

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900710-57
 Last Modified: 17-JAN-1991    ArticleIdent: Q63956

 This article describes how protected mode BASIC programs compiled with
 Microsoft BASIC Compiler versions 6.00 and 6.00b or Microsoft BASIC
 Professional Development System (PDS) version 7.00 or 7.10 can scroll
 text on the screen by calling the OS/2 API functions VioScrollUp(),
 VioScrollDn(), VioScrollLf(), and VioScrollRt(). A full example of
 using these routines is provided below.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS OS/2.

 BASIC 6.00 and 6.00b and BASIC PDS 7.00 and 7.10 can directly call
 OS/2 API functions by linking with the appropriate library. This
 library is called DOSCALLS.LIB for BASIC 6.00 and 6.00b and OS2.LIB
 for BASIC PDS 7.00 and 7.10.

 The API functions VioScrollUp(), VioScrollDn(), VioScrollLf(), and
 VioScrollRt() all require the following parameters:

    Parameter   Description
    ---------   -----------

    WORD        y (row) coordinate of upper left corner
    WORD        x (column) coordinate of upper left corner
    WORD        y (row) coordinate of lower right corner
    WORD        x (column) coordinate of lower right corner
    WORD        Number of lines or columns to scroll
    PTR WORD    Contains character (lower byte) and attribute
                (upper byte) used to fill blanked lines or columns
    WORD        Video handle (0 = default)

 The first four parameters specify the rectangle in which the scrolling
 is to take place. Any area outside this rectangle is not scrolled. The
 sixth parameter specifies the character and attribute to use for the
 new lines or columns created behind the scrolling text. Note that a
 WORD in BASIC is an INTEGER, and any parameters preceded by the word
 "PTR" must be passed using the SEG clause in the DECLARE statement;
 BYVAL is used otherwise. The default for BASIC is to pass by reference
 (not BYVAL).

 The following program (SCROLL.BAS) displays a message on the screen
 and allows you to scroll the message up, down, left, or right using
 the cursor keys. Note that this example uses only the cursor keys on
 the numeric keypad, not the extended cursor keys. Any part of the
 message that is scrolled off the screen is lost. Press the ESC key to
 terminate execution.

 To compile and link the program, enter the following lines at the OS/2
 command prompt:

    bc scroll /v ;
    link scroll;

 Code Example
 ------------

 'SCROLL.BAS
 DEFINT A-Z

 'Declarations for OS/2's Vio scroll functions.
 DECLARE FUNCTION VioScrollUp (BYVAL Y1      AS INTEGER,_
                               BYVAL X1      AS INTEGER,_
                               BYVAL Y2      AS INTEGER,_
                               BYVAL X2      AS INTEGER,_
                               BYVAL Lines   AS INTEGER,_
                               SEG   FillNew AS INTEGER,_
                               BYVAL Handle  AS INTEGER)

 DECLARE FUNCTION VioScrollLf (BYVAL Y1      AS INTEGER,_
                               BYVAL X1      AS INTEGER,_
                               BYVAL Y2      AS INTEGER,_
                               BYVAL X2      AS INTEGER,_
                               BYVAL Lines   AS INTEGER,_
                               SEG   FillNew AS INTEGER,_
                               BYVAL Handle  AS INTEGER)

 DECLARE FUNCTION VioScrollRt (BYVAL Y1      AS INTEGER,_
                               BYVAL X1      AS INTEGER,_
                               BYVAL Y2      AS INTEGER,_
                               BYVAL X2      AS INTEGER,_
                               BYVAL Lines   AS INTEGER,_
                               SEG   FillNew AS INTEGER,_
                               BYVAL Handle  AS INTEGER)

 DECLARE FUNCTION VioScrollDn (BYVAL Y1      AS INTEGER,_
                               BYVAL X1      AS INTEGER,_
                               BYVAL Y2      AS INTEGER,_
                               BYVAL X2      AS INTEGER,_
                               BYVAL Lines   AS INTEGER,_
                               SEG   FillNew AS INTEGER,_
                               BYVAL Handle  AS INTEGER)

 Y1 = 0    'Set the coordinates of the window scrolling area to define
 X1 = 0    'the whole screen (assuming 25 rows and 80 columns).
 Y2 = 24
 X2 = 79

 Lines    = 1       'Scroll one line at a time.
 FillNew  = 20010   'Fill the new lines/columns with yellow asterisks
                    'on a red background.
 Handle   = 0       'Specifies the default OS/2 screen group.

 CLS                 'Clear screen and display the message to scroll.
 LOCATE 12, 30
 PRINT "Use arrows on numeric keypad to scroll."
 PRINT "Hit Esc to quit."

 ON KEY(11) GOSUB UpArrow      'Setup event handlers for key trapping.
 ON KEY(12) GOSUB LeftArrow    'Keys 11-14 are the arrow keys on the
 ON KEY(13) GOSUB RightArrow   'numeric keypad.
 ON KEY(14) GOSUB DownArrow

 KEY(11) ON   'Turn key trapping on.
 KEY(12) ON
 KEY(13) ON
 KEY(14) ON

 DO UNTIL INKEY$ = CHR$(27)   'Loop until the ESC key is pressed.
 LOOP
 END

 'Event handlers for key traps.
 UpArrow:    E = VioScrollUp (Y1, X1, Y2, X2, Lines, FillNew, Handle)
             RETURN

 LeftArrow:  E = VioScrollLf (Y1, X1, Y2, X2, Lines, FillNew, Handle)
             RETURN

 RightArrow: E = VioScrollRt (Y1, X1, Y2, X2, Lines, FillNew, Handle)
             RETURN

 DownArrow:  E = VioScrollDn (Y1, X1, Y2, X2, Lines, FillNew, Handle)
             RETURN


 316. BEGINTRANS Example "Invalid Columnname" for Address

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900626-73 docerr
 Last Modified:  1-AUG-1990    ArticleIdent: Q64100

 The BEGINTRANS example on Pages 23-25 of the "Microsoft BASIC 7.0:
 Language Reference" manual for versions 7.00 and 7.10 incorrectly uses
 "Address" in the Borrower TYPE declaration when trying to OPEN the
 BOOKS.MDB sample database. The example should use "Street" instead.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10.

 The BEGINTRANS example gives the error message "Invalid column name"
 because it tries to OPEN the BOOKS.MDB database (an ISAM file), which
 actually uses "Street" as a column name instead of "Address."

 The following lines of the code example should be changed as follows:

 Page 23
 -------

 The following line

    Address AS STRING * 50        'Address

 should read as follows:

    Street AS STRING * 50         'Street address

 Page 24
 -------

 The following line

    PRINT LEFT$(People.Address, 25); "  ";

 should read as follows:

      PRINT LEFT$(People.Street, 25); "  ";


 317. Description of Expanded Memory Switches for BASIC PDS 7.10

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900503-164
 Last Modified: 15-JAN-1991    ArticleIdent: Q64101

 This article describes the purpose and use of the switches that allow
 you to configure use of expanded memory (according to the LIM 4.0
 Expanded Memory Specification [EMS]) in BASIC PDS 7.00 and 7.10.
 Especially important is the description of the /Es switch and its
 relationship to the other expanded memory switches.

 This information applies to Microsoft BASIC Professional Development
 System versions 7.00 and 7.10 for MS-DOS.

 Saving and Restoring the Expanded Memory State
 ----------------------------------------------

 By default, QBX.EXE and programs compiled with BC.EXE 7.00 or 7.10
 will only perform the minimum saving and restoring of the expanded
 memory state necessary to allow the program to work properly. This
 assumes that no third-party code using expanded memory is present. To
 get more than this minimal amount of expanded memory saving/restoring,
 you must specify /Es upon loading QBX or when compiling programs with
 BC.EXE. This is by design. If BASIC always saved and restored the
 state of expanded memory, the save/restore operations would have a
 significant speed impact on ISAM and on Quick library (.QLB) calling.
 The purpose of the /Es switch is to allow programs to use third-party
 code that uses expanded memory. The trade-off is a degradation in
 speed.

 Table of Expanded Memory Switches and Where You Can Use Them
 ------------------------------------------------------------

    Use With    Switch Name    Switch Purpose
    --------    -----------    --------------

    QBX only    /Ea            Arrays > 512 bytes but < 16K in
                               expanded memory. Default: No arrays in
                               expanded memory.

    QBX only    /E:n           n = amount in kilobytes of expanded
                               memory QBX will use. 0 means QBX uses no
                               expanded memory. Default: Use all
                               available expanded memory.

    QBX and BC  /Es            Enable saving/restoring of expanded
                               memory state.

    PROISAM(D)  /Ie:n          Reserves n kilobytes of expanded memory
                               for other applications (such as QBX).
                               ISAM will only use 1.2 megabytes of
                               expanded memory maximum.

 Examples: Use of Switches, Their Effects, and How They Interact
 ---------------------------------------------------------------

 QBX /E:0
 --------

 - Causes QBX to disable use of expanded memory code storage.

 - If the program has ISAM using expanded memory, it is assumed there
   is no third-party code accessing expanded memory. With /E:0, the
   default for QBX is not to save/restore the expanded memory state on
   ISAM use. This maximizes the speed of ISAM performance.

 QBX /E:0 /Es
 ------------

 - Save/restore operations occur on any ISAM statements or QLB calls.
   You would use this combination if you are loading QLBs that use
   expanded memory and you are also using ISAM that is using expanded
   memory.

 QBX /E:N and N Is Nonzero
 -------------------------

 - The expanded memory state is not saved/restored on QLB calls.

 - Save/restore operations occur on ISAM calls when both QBX and ISAM
   are sharing expanded memory.

 - It is assumed there are no QLBs using expanded memory.

 QBX /Es or QBX /E:N /Es
 -----------------------

 - Forces save/restore operations on QLB calls and ISAM statements.

 - This would be used if you are using QBX and calling QLB routines that
   access expanded memory.

 BC with No Expanded Memory Management Switches, No Overlays, No ISAM
 --------------------------------------------------------------------

 - The expanded memory state is not saved/restored.

 - Third-party routines accessing expanded memory should work
   correctly.

 BC with Overlays That Will Load from Expanded Memory
 ----------------------------------------------------

 - Expanded memory will be used by compiled code in the overlays.

 - The default is to save/restore expanded memory on all ISAM
   statements in a program that uses overlays.

 - This could still cause problems if third-party library routines that
   use expanded memory are called.

 BC /Es with Overlays and ISAM
 -----------------------------

 - Expanded memory will be saved/restored on ISAM statements.

 - Always use /Es when making mixed-language calls to routines that use
   expanded memory as well.

 BC /Es Without Expanded Memory Overlays, but with ISAM
 ------------------------------------------------------

 - /Es always causes save/restore operations on ISAM statements when
   ISAM is using expanded memory.

 - You would use this switch if the program uses ISAM, ISAM is using
   expanded memory, and there are mixed-language CALLs to routines
   that use expanded memory.

   Note: /Es will not cause save/restore operations on ISAM statements
   if ISAM is NOT using expanded memory.


 318. BASIC 7.0 Documentation Correction for Compiling OS/2 Programs

 Product Version(s): 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900719-162 docerr
 Last Modified:  1-AUG-1990    ArticleIdent: Q64102

 The second sentence in the "Compiling OS/2 Programs" section on Page
 527 of the "Microsoft BASIC 7.0: Programmer's Guide" manual for
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 incorrectly states the following:

    For protected-mode programs, make sure to specify the /LP option
    to LINK.

 This sentence should refer to the BASIC compiler (BC.EXE) instead of
 to the BASIC linker (LINK.EXE), as follows:

    For protected-mode programs, make sure to specify the /LP option
    to compile with BC.EXE.


 319. CURRENCY Variable of User-Defined TYPE Cannot Use @ Symbol

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900717-156 buglist7.00 buglist7.10
 Last Modified: 27-JUL-1990    ArticleIdent: Q64103

 A field in a user-defined TYPE ... END TYPE statement must be defined
 with the "AS VariableType" form. When accessing the variable in the
 program, however, the variable can be referred to with or without the
 appropriate type symbol (for example, % for integer, & for long,
 etc.). However, a variable of type CURRENCY defined in a user-defined
 TYPE cannot be referred to in this manner. If the currency symbol (the
 @ sign) is used when accessing the field, the error message "Equal
 sign missing" is returned by the BC.EXE compiler. No error occurs when
 this format is used in the QBX.EXE environment.

 Microsoft has confirmed this to be a problem with the BASIC compiler
 (BC.EXE) in Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS and OS/2. We are researching this
 problem and will post new information here as it becomes available.

 To reproduce this problem, no special compiler directives are
 necessary. Use the following command to generate the error:

    BC BasicProgramName ;

 The compiler error and output are as follows:

     me(1).a@ = 12
            ^  Equal sign missing

 Sample Code
 -----------

 TYPE mytype
   a AS CURRENCY
   b AS INTEGER
   c AS LONG
   d AS SINGLE
   e AS DOUBLE
   f AS STRING * 20
 END TYPE

 DIM me AS mytype
 COMMON SHARED me() AS mytype

 REDIM me(10)  AS mytype
 me(1).a@ = 12     REM  Remark this line to avoid the compiler error
                   REM  or remove the currency symbol (@).
 me(1).b% = 12
 me(1).c& = 12
 me(1).d! = 12
 me(1).e# = 12
 me(1).f$ = "12"
 PRINT me(1).a, me(1).b, me(1).c
 PRINT me(1).d, me(1).e, me(1).f


 320. GET from COM1 or COM2 Fails to Get Correct Data -- Use INPUT$

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900710-87 buglist7.00 buglist7.10
 Last Modified:  1-AUG-1990    ArticleIdent: Q64108

 The GET statement fails to read the correct information from a
 communications port (COM1, COM2) with Microsoft BASIC Professional
 Development System (PDS) version 7.00. Characters are removed from the
 buffer, but the values read in are not the correct values sent across
 the port.

 To work around this problem, use the INPUT$ function to read the data
 from the COM port.

 Microsoft has confirmed this to be a problem with Microsoft BASIC PDS
 versions 7.00 and 7.10 for MS-DOS and OS/2. We are researching this
 problem and will post new information here as it becomes available.

 This problem does NOT occur in Microsoft QuickBASIC version 4.50 or
 earlier or in Microsoft BASIC Compiler version 6.00b or earlier.

 Code Example
 ------------

 The following program attempts to read characters from COM1 using both
 GET and INPUT$:

    DIM a AS STRING * 1, b AS STRING * 1
    OPEN "COM1:300,n,8,1" FOR RANDOM AS #1
    GET #1, , a
    b = INPUT$(1, 1)
    PRINT a, b
    END

 In QuickBASIC 4.50, both the GET and INPUT$ statements return the
 correct values, but in BASIC PDS 7.00 and 7.10, only INPUT$ returns
 the correct data while GET returns meaningless data.


 321. 7.0 Manual Correction for BASIC Calling C Passing a Far String

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900719-55 docerr
 Last Modified:  1-AUG-1990    ArticleIdent: Q64109

 Page 501 of the "Microsoft BASIC 7.0: Programmer's Guide" for versions
 7.00 and 7.10 shows an incorrect example of passing a far string to C.
 The error is in the BASIC code. The C code is correct.

 The BASIC code needs to be changed in the following two places on Page
 501:

 1. The incorrect fourth line of the example is as follows (where the
    underscore means to place the statement all on one line):

       DECLARE FUNCTION addstring$(SEG s1$,BYVAL_
               s1length,SEG s2$,BYVAL s2length)

    and should be changed to read as follows (where the underscore
    means to place the statement all on one line):

       DECLARE FUNCTION addstring$ CDECL_
              (BYVAL s1offset%, BYVAL s1segment%, BYVAL s1length%,_
               BYVAL s2offset%, BYVAL s2segment%, BYVAL s2length%)

    In other words, to create a C far pointer, you have to pass the
    segment followed by the offset and pass this BYVAL so it will be
    pushed on the stack.

 2. The incorrect tenth line is as follows:

       C$ = addstring$(A$, LEN(A$), B$, LEN(B$))

    and should be changed to read as follows (where the underscore
    means to place the statement all on one line):

       C$ = addstring$(SSEG(A$), SADD(A$), LEN(A$), SSEG(B$),_
                       SADD(B$), LEN(B$))

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 For more information on passing parameters between BASIC and C, query
 in the Knowledge Base or in the Software/Data Library on the word
 BAS2C.


 322. PRINT USING Doesn't Work in UI Toolbox Window; Use FormatX$

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900717-4
 Last Modified: 27-JUL-1990    ArticleIdent: Q64185

 The WindowPrint subroutine included in the User Interface (UI) Toolbox
 allows you to print text strings inside a window that was defined with
 the WindowOpen UI subroutine. However, the WindowPrint subroutine does
 not allow you to print numbers or formatted numbers the same way a
 PRINT USING statement does. To print numbers or formatted numbers, you
 must first use the FormatX$ functions, available in the BASIC PDS
 Add-on Library DTFMTxx.LIB. The string of numbers formatted with
 FormatX$ can then be printed with the WindowPrint subroutine.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The term FormatX$ actually refers to the functions FormatI$, FormatL$,
 FormatS$, FormatD$, and FormatC$. For more information on the FormatX$
 functions, query in this Knowledge Base on the word "FormatX$".

 To use the FormatX$ functions with the User Interface Toolbox in the
 QBX.EXE environment, you must first create a Quick library (a .QLB
 file) containing the code for both the User Interface routines and
 also the FormatX$ routines. Here are two methods to do this:

 Method 1
 --------

 To create the Quick library from provided .LIB libraries, combine the
 libraries into a new library as follows

    LIB UITFMT.LIB+UITBEFR.LIB ;
    LIB UITFMT.LIB+DTFMTER.LIB ;

 then create the new Quick library (UITFMT.QLB) as follows:

    LINK /Q UITFMT.LIB, UITFMT.QLB,,QBXQLB.LIB ;

 Note that the first LIB command line above creates UITFMT.LIB. LIB.EXE
 creates UITFMT.LIB automatically since UITFMT.LIB did not previously
 exist. The second LIB command line appends DTFMTER.LIB to UITFMT.LIB.

 To invoke QBX.EXE (the QuickBASIC Extended environment) with the
 UITFMT.QLB Quick library (created in Method 1 above), use the
 following command:

    QBX /L UITFMT.QLB

 Method 2
 --------

 To create the .QLB file from the original .OBJ files, use the
 following LINK command:

    LINK /q WINDOW.OBJ+MENU.OBJ+MOUSE.OBJ+GENERAL.OBJ+UIASM.OBJ+
                         QBX.LIB+DTFMTER.LIB,UIFMT.QLB,,QBXQLB.LIB;

 Note: In the preceding LINK line, you must use DTFMTER.LIB, where "E"
 stands for Emulator math package, and "R" stands for DOS real mode.
 Quick libraries used in QBX.EXE cannot be compiled for Alternate math
 or protected mode.

 To invoke QBX.EXE (QuickBASIC Extended) with the UIFMT.QLB Quick
 library (created in Method 2 above), use the following command:

    QBX /L UIFMT.QLB

 To use the UI Toolbox routines and the FormatX$ routines in an
 executable (.EXE) program, you must link to the UITFMT.LIB (created in
 Method 1 above) to your program, or separately link the DTFMTxx.LIB
 and UITBxxx.LIB libraries (shipped by Microsoft) into your program.

 The following code sample gives an example of using the FormatS$
 function to convert a single-precision number into a dollar amount,
 and then print the result in a UI Toolbox window:

 Code Sample
 -----------

 DEFINT A-Z
 REM $INCLUDE: 'window.bi'
 REM $INCLUDE: 'mouse.bi'
 REM $INCLUDE: 'menu.bi'
 REM $INCLUDE: 'general.bi'
 REM $INCLUDE: 'format.bi'

 COMMON SHARED /uitools/ glomenu AS menumisctype
 COMMON SHARED /uitools/ glotitle() AS menutitletype
 COMMON SHARED /uitools/ gloitem() AS menuitemtype
 COMMON SHARED /uitools/ glowindow() AS windowtype
 COMMON SHARED /uitools/ globutton() AS buttontype
 COMMON SHARED /uitools/ gloedit() AS editfieldtype
 COMMON SHARED /uitools/ glostorage AS windowstoragetype
 COMMON SHARED /uitools/ glowindowstack() AS INTEGER
 COMMON SHARED /uitools/ globuffer$()

 DIM glotitle(maxmenu) AS menutitletype
 DIM gloitem(maxmenu, maxitem) AS menuitemtype
 DIM glowindow(MAXWINDOW) AS windowtype
 DIM globutton(MAXBUTTON) AS buttontype
 DIM gloedit(MAXEDITFIELD) AS editfieldtype
 DIM glowindowstack(MAXWINDOW) AS INTEGER
 DIM globuffer$(MAXWINDOW + 1, 2)

 CLS
 MenuInit
 windowinit

 windowopen 1, 3, 3, 20, 40, 7, 0, 7, 0, 15, 0, 0, 0, 0, 1, "Format Example"
 ' Set the variable name:
 a! = 123.34

 ' Convert the variable to a string:
 b$ = STR$(a!)

 'convert the variable to a formatted string:
 x$ = formats$(a!, "$0000.00")

 ' Print out the results:

 windowprint 1, "The unformatted variable is:"
 windowprint 1, b$
 windowprint 1, "The formatted variable using the"
 windowprint 1, "form '$0000.00':"
 windowprint 1, x$


 323. How to Simulate Bound Executables with BASIC 6.00 - 7.10

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S900724-5
 Last Modified: 27-JUL-1990    ArticleIdent: Q64210

 Although Microsoft BASIC Compiler versions 6.00 and 6.00b and
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS and MS OS/2 can create protected and real mode
 programs, they cannot create bound programs. A bound program is one
 that can run both in protected mode and real mode (DOS). However,
 there is a way to simulate the functionality of a bound program by
 creating a real mode version of the program and then linking the
 protected mode version with a module-definition file containing the
 STUB statement. The procedure for doing this is described below.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS and MS OS/2 and Microsoft BASIC PDS versions 7.00 and
 7.10 for MS-DOS and MS OS/2.

 The STUB statement adds a DOS versions 3.x (real mode) executable file
 to the beginning of the protected mode program being created by
 LINK.EXE. The syntax of the STUB statement is the following:

    STUB 'filename'

 Here, filename is the name of a real mode executable file. This real
 mode stub is invoked whenever the program is executed under DOS 2.x or
 DOS 3.x (or the DOS compatibility box of OS/2). By default, the linker
 adds its own standard stub that terminates after displaying a message
 similar to the following:

    This program cannot run in DOS mode.

 You can use the STUB statement to replace this standard stub with a
 real mode program that exactly emulates the behavior of a protected
 mode version, thus simulating a bound executable.

 The following is an example of the steps necessary to do this. This
 example uses the following two BASIC source files:

    REALMODE.BAS
    ------------

    PRINT "This program has the same output in protected and real modes."

    PROTMODE.BAS
    ------------

    PRINT "This program has the same output in protected and real modes."

 Here are the steps:

 1. Create a real mode version of the program as you normally would.
    For our example, the following two commands accomplish this:

       bc /Lr realmode.bas;
       link realmode.obj;

 2. Create a module-definition file containing the STUB statement. You
    can do this with any text editor. Make sure the file is saved as an
    ASCII text file. For our example, the module-definition file
    (PROTMODE.DEF) would look like this:

       STUB 'REALMODE.EXE'

 3. Create the protected mode version of the program, linking with the
    module-definition file created in Step 2. Compile the program as
    you normally would, but when linking, include the name of the
    module-definition file in the fifth link parameter. The compile
    and link commands for our example would be as follows:

       bc /Lp protmode.bas;
       link protmode.obj,,,,protmode.def;

 When PROTMODE.EXE is run from a protected mode session, the following
 will be the output:

    This program has the same output in protected and real modes.

 When PROTMODE.EXE is run from a DOS (real mode) session, REALMODE.EXE
 will be executed instead of PROTMODE.EXE. Remember that REALMODE.EXE
 is appended to the beginning of PROTMODE.EXE, so it is not necessary
 to have a copy of REALMODE.EXE in the current directory. The output
 will be the same as if PROTMODE were run from a protected mode
 session:

    This program has the same output in protected and real modes.


 324. LINK "Stack Plus Data Exceed 64K"; 7.00 BC /Fs Forces /S

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  6-AUG-1990    ArticleIdent: Q64424

 In Microsoft BASIC Professional Development System (PDS) version 7.00
 for MS-DOS and MS OS/2, the BC /Fs (Far Strings) option forces the
 compiler to also perform a /S. If you use many quoted strings in your
 program, this BC /S option places extra overhead in the .OBJ file
 that could (in some cases) overload the linker and give a "Stack plus
 data exceed 64K" error (L2041) at LINK time. Compiling without /Fs
 (using near strings) will not force /S, and the program may then LINK
 without the L2041 error.

 BASIC PDS version 7.10 is enhanced so that the BC /Fs option no longer
 forces an automatic /S option. This enhancement can help avoid the
 "Stack plus data exceed 64K" error as in the above case when you need
 to compile with the /Fs option.

 BC /S Option
 ------------

 The BC /S option helps you only at compile time. You only need to use
 the BC /S option when you get an "Out of memory" error message at
 compile time due to too many quoted string constants in the source
 program. Compiling with BC /S increases DGROUP usage at link time, in
 some cases contributing to the cause of the linker error "Stack plus
 data exceed 64K." Compiling with BC /S normally does not affect the
 size or speed of the final linked .EXE program.

 BC /Fs Option
 -------------

 The BC /Fs (Far Strings) option gives you more space for
 variable-length string variables at the cost of increasing the size
 and slowing the speed of .EXE programs.


 325. ISAMIO.EXE /I Imports ASCII Text File into BASIC ISAM File

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900531-47
 Last Modified:  6-AUG-1990    ArticleIdent: Q64495

 You can convert an ASCII text file into a Microsoft BASIC Professional
 Development System (PDS) ISAM database table by using the ISAMIO.EXE
 utility with the /I (Import) option. This article describes how to use
 the ISAMIO /I option.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 under MS-DOS.

 The syntax for importing (converting) an ASCII file into an ISAM
 database using the ISAMIO utility is as follows:

    ISAMIO /I ASCIIFIL.TXT DATBASE.MDB TABLNAME SPECFIL.TXT [options]

 ASCIIFIL.TXT can have two formats. It can appear in a fixed-width
 format where certain data appears in fixed columns of the file. The
 ISAMIO /F option is required for a file of this type. The file can
 also be comma delimited with string data enclosed in double quotation
 marks. In this format, blank spaces should not be used between the
 fields and the commas. If blank spaces are inserted between the commas
 and the data, an "Unable to Parse column xx of line xx" error may
 occur.

 The DATBASE.MDB and TABLNAME are names of the ISAM database and table
 into which the ASCII file is to be imported. If DATBASE.MDB or
 TABLNAME doesn't already exist, PROISAMD support must be available to
 create them. A related ISAMIO.EXE error message is as follows:

    ISAM command is not available" (in 7.00 or 7.10)

 This error message displays when PROISAM capability is currently
 installed but PROISAMD capability is needed (to create a new ISAM
 database or table). To avoid this error, do one of the following:

 1. If you ran SETUP.EXE with the "ISAM Routines in TSR" option, load
    PROISAMD.EXE instead of PROISAM.EXE.

 2. If you ran SETUP with "ISAM Routines in LIB, Support Database
    Access Only" option, run SETUP again and choose "ISAM Routines in
    LIB, Support Database Creation and Access."

 If the database and table already exist and you use the ISAMIO /A
 (Append) option, you can use either PROISAM or PROISAMD.

 SPECFIL.TXT is the file that ISAMIO uses to specify the data type and
 size for each column of a table. Each line of the file relates to a
 column of the table. The format is as follows:

    [fixedwidthsize,][type,[size],[columnname]]

 The fields in SPECFIL.TXT can be separated by spaces or commas. The
 "fixedwidthsize" field is valid only if the /F option is used. It just
 specifies the size of the field to read from ASCIIFIL.TXT.

 The "type" field in SPECFIL.TXT is one of the indexable ISAM data
 TYPEs. In the case of arrays, user-defined TYPEs, and strings longer
 than 255 characters, the "type" field must be specified as binary. If
 the "type" field is specified as variabletext (vt) or variablestring
 (vs), the "size" field must appear. The "size" field for string data
 tells ISAMIO the size of the field to put the string data into. The
 "size" field can be smaller, which truncates input data, or larger,
 which allows a larger string to be input later. These two types are
 the same except that variabletext (vt) is case insensitive while
 variablestring (vs) is case sensitive. Note that BASIC PDS' use of
 string data is case insensitive (that is, all comparisons made are
 case insensitive). Therefore, even if variablestring is specified, it
 is converted to variabletext.

 The "columnname" field in SPECFIL.TXT is any valid ISAM column name,
 but it is ignored if the /C option is used.

 The ISAMIO options that you can use for importing a file (/I) are /C,
 /F, and /A. The following table describes these options:

 Option     Description
 ------     -----------

 /A         Tells ISAMIO that you are importing ASCIIFIL.TXT and
            appending it to an existing table (TABLNAME). If /A is
            specified, column names cannot appear in ASCIIFIL.TXT
            (the /C option), only data. If you use the /A and /C
            options together, the following error message displays:

               APPEND & COLUMN_NAMES conflicts

            The SPECFIL.TXT file cannot appear on a command line that
            contains the /A option. ISAMIO uses the format of the
            existing table that is being appended to. If SPECFIL.TXT
            is specified along with the /A option, the following error
            message displays:

               APPEND and specfile conflicts

            If the table does not exist within the specified database
            (DATBASE.MDB), ISAMIO displays the following error message:

               Can't Open Table "TABLNAME"

 /C         Tells ISAMIO that the ISAM table's column names should be
            taken from the first line of ASCIIFIL.TXT. These column
            names need to be separated by a space, comma, or any
            combination thereof. If a column name is not consistent
            with the ISAM naming convention, ISAM displays the error
            message "Invalid Name." If this option is not specified
            when importing a new table, ISAMIO looks at SPECFIL.TXT
            for the column names. If ISAMIO doesn't find a column name
            in SPECFIL.TXT, it displays an error message that tells
            you that you must specify a column name in SPECFIL.TXT.

 /F         Tells ISAMIO that the text to be imported is of a
            fixed-width format (already in columns of a certain
            length). The size of the fixed-width format must be
            specified in the first column of SPECFIL.TXT. If the /F
            option is not used, the data in the fields of ASCIIFIL.TXT
            are assumed to be delimited by commas, with string data
            enclosed in double quotation marks. If you use /F and one
            of the fields is shorter than the specified length, you
            will receive the error message "Unable to parse column xx
            of line xx," where "column" refers to the column of a
            table.

 Depending on how you ran SETUP.EXE, the ISAMIO.EXE utility will be
 built either to run as a stand-alone program or to require the
 terminate-and-stay-resident (TSR) form of ISAM. A separate article,
 found by querying in this Knowledge Base on the following words,
 discusses this topic:

    SETUP and builds and ISAMIO

 When you run ISAMIO and receive one of the following error messages,
 you must install the PROISAM.EXE or PROISAMD.EXE TSR program if you
 are running MS-DOS; if you are running OS/2, you must put PROISAM.DLL
 or PROISAMD.DLL in your LIBPATH:

    ISAMIO: ISAM TSR is not loaded" (in 7.00 under MS-DOS)
    ISAMIO : error: ISAM DLL not found" (in 7.10 under MS-DOS or OS/2)

 The following are some examples of importing different ASCII files:

 Example 1
 ---------

 The contents of ASCIIFIL.TXT are as follows:

    CustomerName  Address  CustomerNumber
    Huck Finn   1606 Crest Dr. 3490
    Joe Henry   893 S. Scenic   5620
    Billy Bob   143 Maple St    0894

 The contents of SPECFIL.TXT are as follows (where BASIC PDS ISAM treats
 vt and vs the same way):

    12,vt,20
    16,vs,16
    4,integer

 Invoke ISAMIO.EXE in MS-DOS as follows:

    ISAMIO /I ASCIIFIL.TXT CUSTOMER.MDB TABLE1 SPECFIL.TXT /C/F

 Example 2
 ---------

 The contents of ASCIIFIL.TXT are as follows:

    "Huck Finn","1606 Crest Dr.",3490
    "Joe Henry","893 S. Scenic",5620
    "Billy Bob","143 Maple St",0894

 The contents of SPECFIL.TXT are as follows:

    12,vt,20,CustomerName
    16,vs,16,Address
    4,integer,CustomerNumber

 Invoke ISAMIO.EXE in MS-DOS as follows:

    ISAMIO /I ASCIIFIL.TXT CUSTOMER.MDB TABLE2 SPECFIL.TXT

 Example 3:  Appending a File to an Existing ISAM Table
 ------------------------------------------------------

 The following example shows how to append an ASCII file to an existing
 ISAM table:

 The contents of APENDFIL.TXT are as follows:

    "John Doe","1387 Main Blvd.",2490

 Note that a SPECFIL.TXT file is not used when appending a file to the
 ISAM table. Invoke ISAMIO.EXE as follows:

    ISAMIO /I APENDFIL.TXT CUSTOMER.MDB TABLE2 /A

 For more information on how to use ISAMIO, see Pages 389-391, Chapter
 10, "ISAM Utilities," of the "Microsoft BASIC 7.0: Programmer's Guide"
 for versions 7.00 and 7.10.


 326. SETUP Builds ISAMIO, ISAMCVT, ISAMPACK as Stand Alone or Not

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  3-AUG-1990    ArticleIdent: Q64496

 Depending on how you run SETUP.EXE, the ISAM utilities ISAMIO.EXE,
 ISAMCVT.EXE, and ISAMPACK.EXE are built either to run as stand-alone
 programs or to require the terminate-and-stay-resident (TSR) form of
 ISAM.

 SETUP always installs the ISAMREPR.EXE (ISAM repair) utility to run as
 a stand-alone program.

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 provides the following four SETUP.EXE options for installing
 ISAM support for DOS (or OS/2 real mode):

 1. ISAM Routines in TSR
 2. ISAM Routines in LIB, Support Database Creation and Access
 3. ISAM Routines in LIB, Support Database Access Only
 4. No ISAM support

 SETUP Option 1 builds ISAMIO.EXE, ISAMCVT.EXE, or ISAMPACK.EXE
 utilities that require the TSR form of ISAM (PROISAM.EXE or
 PROISAMD.EXE). Option 1 is the default because it consumes the least
 disk space.

 SETUP Options 2 and 3 create stand-alone ISAM utilities (ISAMIO.EXE,
 ISAMCVT.EXE, ISAMREPR.EXE, and ISAMPACK.EXE), which do not require the
 presence of the ISAM TSR programs (PROISAM.EXE or PROISAMD.EXE). If
 you choose Option 3 instead of 2, the ISAM utilities will not be able
 to create or delete any ISAM databases or tables, they will just be
 able to add and delete records for existing databases or tables.

 SETUP Option 4 does not copy any ISAM utilities, TSR programs, or any
 other ISAM-related files onto your computer.

 Because BASIC PDS 7.10 introduces ISAM support under OS/2 protected
 mode, it provides the following two additional SETUP options:

 1. ISAM Routines in DLL
 2. No ISAM Support

 The protected mode ISAM SETUP choices (above) do not affect how
 ISAMIO.EXE, ISAMCVT.EXE, ISAMREPR.EXE, or ISAMPACK.EXE are built,
 since these ISAM utilities run only under MS-DOS (and not under OS/2).

 Reference:

 For more information, see Pages 389-399, Chapter 10, "ISAM Utilities,"
 of the "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and
 7.10.


 327. How to Use Named, Shared Memory Segments in OS/2 BASIC Program

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900730-92
 Last Modified: 17-AUG-1990    ArticleIdent: Q64589

 Microsoft BASIC Compiler versions 6.00 and 6.00b and Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 can
 create OS/2 protected mode programs that use named, shared memory
 segments. Named, shared memory segments are areas of memory used for
 interprocess communications (IPC). Their use involves calling three
 different OS/2 API functions. Below are two sample BASIC programs that
 demonstrate the use of named, shared memory segments.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS OS/2.

 Named, shared memory segments can be used to communicate between
 processes. Their names have the following form:

    \SHAREMEM\name.ext

 ".ext" is optional. The size of the segment can be up to 65,536 bytes.
 After the segment is allocated, it can be read from and written to
 using PEEK and POKE, which examine and set (respectively) a 1-byte
 address location. Typically, one process (called the "creator") will
 allocate the segment and other programs (called "obtainers") will
 obtain the address (selector) to it. The minimum OS/2 API functions
 that need to be called to use named, shared memory segments are the
 following:

 For the Creator
 ---------------

 Function       Description
 --------       -----------

 DosAllocShrSeg()   Allocates a named, shared memory segment of up to
                    65,536 bytes and returns a selector for it.

 For the Obtainers
 -----------------

 Function       Description
 --------       -----------

 DosGetShrSeg()     Obtains a selector to a named, shared memory segment
                    that was allocated by DosAllocShrSeg().

 For Both the Creator and Obtainers
 ----------------------------------

 Function       Description
 --------       -----------

 DosFreeSeg()       Releases the selector to the segment. When all
                    selectors by all processes have been released, the
                    segment is reclaimed by OS/2.

 For more information on named, shared memory segments and other IPC
 methods, see Chapter 13, "Interprocess Communication," of "Advanced
 OS/2 Programming" by Ray Duncan (Microsoft Press, 1989).

 The following are two sample programs that demonstrate the use of
 named, shared memory segments. To compile the programs, enter the
 following commands at the OS/2 command prompt:

    bc creator;
    bc obtainer;

 How the programs are linked depends on which version of BASIC is being
 used. This is because in BASIC 6.00 and 6.00b, the name of the OS/2
 API functions import library is DOSCALLS.LIB. In BASIC PDS 7.00 and
 7.10, the name is OS2.LIB. The link lines are as follows:

 For BASIC 6.00 and 6.00b:  link creator,,,doscalls;
                            link obtainer,,,doscalls;

 For BASIC PDS 7.00 and 7.10:  link creator,,,os2;
                               link obtainer,,,os2;

 CREATOR.BAS
 -----------

 'CREATOR.BAS allocates a named, shared segment and writes the letters
 'of the alphabet to bytes 0 through 25 of the segment. It then waits
 'until byte 0 of the segment becomes 255 before releasing its selector
 'and terminating.
 DECLARE FUNCTION DosAllocShrSeg% (BYVAL SegmentSize%,
                                   BYVAL NameSegment%,_
                                   BYVAL NameOffset%, SEG Selector%)
 DECLARE FUNCTION DosFreeSeg%     (BYVAL Selector%)

 'Attempt to allocate the segment.
 SegmentName$ = "\SHAREMEM\SPIKE" + CHR$(0)
 ErrorCode%   = DosAllocShrSeg% (26, VARSEG(SegmentName$),_
                                 SADD(SegmentName$), Selector%)

 'Check if an error occurred.  If not, make the segment current.
 IF ErrorCode% <> 0 THEN
    PRINT "Error";ErrorCode%;" allocating segment"
    BEEP
    END
 ELSE
    DEF SEG = Selector%
 END IF

 FOR ASCII% = 65 TO 90         'Write the letters A through Z to bytes
    POKE ASCII% - 65, ASCII%   '0 through 25 of the segment.
 NEXT ASCII%

 PRINT "Waiting for data to be read..."   'When OBTAINER.BAS is done
 DO UNTIL PEEK(0) = 255                   'reading, it will put a 255
 LOOP                                     'in byte 0 of the segment.

 ErrorCode% = DosFreeSeg% (Selector%)   'Free the segment selector.
 END

 OBTAINER.BAS
 ------------

 'OBTAINER.BAS obtains a selector to the segment created by
 'CREATOR.BAS and reads bytes 0 through 25, display their contents. It
 'then POKEs a 255 into byte 0 of the segment so CREATOR.BAS will
 'terminate. Lastly, it releases its selector to the segment and
 'terminates itself.
 DECLARE FUNCTION DosGetShrSeg% (BYVAL NameSegment%,
                                 BYVAL NameOffset%, SEG Selector%)
 DECLARE FUNCTION DosFreeSeg%   (BYVAL Selector%)

 'Attempt to get a selector for the segment.
 SegmentName$ = "\SHAREMEM\SPIKE" + CHR$(0)
 ErrorCode%   = DosGetShrSeg% (VARSEG(SegmentName$),_
                               SADD(SegmentName$), Selector%)

 'Check if an error occurred.  If not, make the segment current.
 IF ErrorCode% <> 0 THEN
    PRINT "Error";ErrorCode%;" getting segment"
    BEEP
    END
 ELSE
    DEF SEG = Selector%
 END IF

 FOR Offset% = 0 TO 25
    PRINT CHR$(PEEK(Offset%));" ";   'Display bytes 0 to 25 of the
 NEXT Offset%                        'named, shared memory segment.

 POKE 0, 255                            'Signal CREATOR.BAS to end and
 ErrorCode% = DosFreeSeg% (Selector%)   'release the segment selector.
 END


 328. EMS40.SYS Is Valid LIM 4.0 Driver for EM Use in BASIC PDS

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900717-157 EMS40
 Last Modified:  5-SEP-1990    ArticleIdent: Q64591

 EMS40.SYS is a device driver that emulates the Lotus/Intel/Microsoft
 (LIM) Expanded Memory Specification (EMS) version 4.0. This software
 permits AT-class machines with extended memory to adapt their extended
 memory (defined by XMS) to expanded memory (defined by EMS). This
 driver is compatible with Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 and can map BASIC PDS source code
 segments less than 16K in size to the expanded memory of the machine.

 EMS40.SYS is freeware and it is available for downloading from the PC
 MagNet bulletin board. Although the source code is also available on
 MagNet, EMS40.SYS is already compiled and ready to use. Much of the
 information in this article comes from the "readme" file also
 available on MagNet.

 EMS40.SYS can be installed as a driver specified in your CONFIG.SYS
 file with the syntax shown below. The drive and path should be
 specified so the system can find the driver during machine boot-up.
 Once installed, EMS40.SYS cannot be removed from memory without
 rebooting the computer.

    DEVICE=[LogicalDriveName:\][path\]EMS40.SYS [xxx]

 The optional "xxx" parameter allows you to specify the amount of
 extended memory in kilobytes (K) to be used as expanded memory by
 EMS40.SYS. If the "xxx" parameter is omitted, the default value is
 384K. By setting "xxx: to a smaller value than that of the extended
 memory installed, space can be reserved for extended memory programs,
 such as HIMEM.SYS.

 EMS40.SYS maps extended memory into four contiguous 16K pages in
 conventional DOS memory and permits access to memory in situations
 that otherwise could result in a "Memory Full" error. EMS40.SYS is not
 as fast as a dedicated LIM 4.0 EMS board and driver, but it implements
 (within the limitations of software emulation) all 28 functions
 specified in the LIM 4.0 EMS. It does not attempt, however, to emulate
 the DMA functions included in Function 28, Alternate Map Register Set.


 329. QBX.EXE Color Loss & Hang on VGA on Tecmar BIOS 1.02; 1.11 OK

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | B_QuickBAS
 Last Modified: 17-OCT-1990    ArticleIdent: Q64899

 Several customers have reported that when running QBX.EXE from
 Microsoft BASIC Professional Development System (PDS) version 7.00 or
 7.10 on a machine with a Tecmar ROM BIOS version 1.02 or 1.04, if a
 VGA screen is being used, the environment loses color and the system
 eventually hangs or reboots itself.

 Tecmar is researching this problem and will provide a free upgrade to
 Tecmar ROM BIOS version 1.11. To obtain this free upgrade, call Tecmar
 technical support at [phone].

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.


 330. An Alternative If ISAMCVT Fails on IBM BASIC 2.0 ISAM Database

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900801-41
 Last Modified:  5-SEP-1990    ArticleIdent: Q64934

 ISAMCVT.EXE is a utility provided with Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for the purpose of
 converting files created with other database-management systems,
 including IBM BASIC Compiler version 2.00, to the Microsoft ISAM
 format.

 You can also convert the database using the REBUILD.EXE utility
 provided in IBM BASIC Compiler version 2.00. IBM's REBUILD can be used
 to strip the header information off the IBM ISAM data (.DAT) file. The
 file can then be read in as a random access file and written out to a
 Microsoft BASIC PDS 7.00 or 7.10 ISAM database.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 For more information on the ISAMCVT.EXE utility, see Pages 391-393 of
 the "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and
 7.10.

 This article contains the sample program CONVERT.BAS, which reads,
 with random access, the file created by the REBUILD utility with the
 /S option and writes the information out to a Microsoft BASIC PDS 7.00
 or 7.10 ISAM database. Please note that this process does not save
 indexes, so they will have to be rebuilt.

 When an IBM BASIC 2.00 ISAM file is created, two files are actually
 created: an index file with a .KEY extension, and a data file with the
 .DAT extension. The .DAT file has a structure very similar to a random
 access file except for the additional header information, known as the
 "data dictionary." The data dictionary can be removed by using the
 REBUILD utility with the /S option. The syntax is as follows:

    REBUILD SOURCE.DAT, TARGET.DAT /S;

 The "Single-key" switch (/S) tells REBUILD to copy the source file
 (the BASIC 2.00 data file) into the target file, removing the data
 dictionary and any free space. No key file is built. The format of the
 target file is a random access file with an additional 3-byte field
 added to the beginning of each record. When reading the random file
 into a BASIC 7.00 or 7.10 program, the TYPE...END TYPE statement must
 be formatted the same way as the corresponding FIELD statement used in
 the IBM BASIC 2.00 program, with the additional 3-byte field at the
 beginning of each record. For example:

 Used in BASIC 2.00 Program       Corresponding BASIC 7.00, 7.10 Declaration
 --------------------------       ------------------------------------------

     FIELD #1, _                    TYPE BASIC20Rec
      25 as Name$, _                      Basic2Index AS STRING * 3
      30 as Address$, _                   Name AS STRING * 25
      4 as Zip$, _                        Address AS STRING * 30
      1 as Sex$, _                        Zip AS STRING * 4
      2 as Age$, _                        Sex AS STRING * 1
      4 as Income$                        Age AS STRING * 2
                                          Income AS STRING * 4
                                    END TYPE

 Now you need to set up a TYPE...END TYPE statement to write the
 appropriate information to an ISAM database or to another random
 access file. This is to mask the BASIC 2.00 index off from the record.
 You will have to dimension a variable or array of each type and assign
 each of the individual fields, ignoring the 3-byte Basic2Index field.
 For example:

      TYPE BASIC70Rec
            Name AS STRING * 25
            Address AS STRING * 30
            Zip AS DOUBLE        '7.00/7.10 ISAM doesn't support SINGLE
            Sex AS STRING * 1
            Age AS INTEGER
            Income AS DOUBLE     '7.00/7.10 ISAM doesn't support SINGLE
      END TYPE

      DIM OldRec AS BASIC20Rec
      DIM NewRec AS BASIC70Rec
                .
                .
                .
      NewRec.Name = OldRec.Name
      NewRec.Address = OldRec.Address
      NewRec.Zip = CVS(OldRec.Zip)
      NewRec.Sex = OldRec.Sex
      NewRec.Age = CVI(OldRec.Age)
      NewRec.Income = CVS(OldRec.Income)

 Note that if floating-point values in records were written to the
 file, you will need to convert them by invoking the QBX environment
 with the /MBF option. This is because IBM BASIC Compiler 2.00 uses the
 Microsoft Binary Format (MBF) for floating-point numbers, and
 Microsoft BASIC PDS 7.00 and 7.10 use the IEEE format. For example:

    QBX /MBF

 For more information on the ISAM utilities, query in this Knowledge
 Base on the following words:

    ISAM and BASIC and UTILITY

 Code Example
 ------------

 'Below is CONVERT.BAS, the sample program that converts the sample ISAM
 'file "MAIL.DAT" found on the IBM BASIC Compiler 2.00 disks. MAIL.DAT
 'is rebuilt to the file "MAIL2.DAT" when the following command is typed
 'at the DOS prompt:
 '
 '   REBUILD MAIL.DAT, MAIL2.DAT /S;
 '
 'The file is then read as a random file and each record is inserted
 'into the database "CUSTOMER.MDB". For this example, invoke QBX.EXE
 'with the /MBF option and load the PROISAMD.EXE TSR program.

 DEFINT A-Z

 '  Record description of data file MAIL2.DAT after REBUILD utility is
 '  used:

 TYPE BASIC2Rec
      Basic2Index AS STRING * 3  'This is the 3-byte index from REBUILD
      Name AS STRING * 25        'First and last name
      Address AS STRING * 30     'Address
      Zip AS STRING * 4          'Zip, SINGLE written to file using
                                 'MKS$
      Sex AS STRING * 1          'Sex
      Age AS STRING * 2          'Age, INTEGER written to file using
                                 'MKI$
      Income AS STRING * 4       'Income, SINGLE written to file using
                                 'MKS$
 END TYPE

 TYPE BASIC7Rec
       Name AS STRING * 25      'First and last name
       Address AS STRING * 30   'Address
       Zip AS DOUBLE            'Zip, note the conversion process below
       Sex AS STRING * 1        'Sex
       Age AS INTEGER           'Age, note the conversion process below
       Income AS DOUBLE         'Income, note the conversion process
                                'below
 END TYPE

 DIM OldCust AS BASIC2Rec
 DIM NewCust AS BASIC7Rec

 OPEN "MAIL2.DAT" FOR RANDOM AS #1 LEN = LEN(OldCust)
 OPEN "CUSTOMER.MDB" FOR ISAM BASIC7Rec "TABLE1" AS #2
 CLS
 i = 0
 DO WHILE NOT EOF(1)
  i = i + 1
  GET #1, i, OldCust           'Get the old record

      'Assign the corresponding fields, ignoring the 3-byte index:

  NewCust.Name = OldCust.Name
  NewCust.Address = OldCust.Address
  NewCust.Zip = CVS(OldCust.Zip)        'Convert MBF to SINGLE
                                        'and assign into DOUBLE
  NewCust.Sex = OldCust.Sex
  NewCust.Age = CVI(OldCust.Age)        'Convert MBF to INTEGER
  NewCust.Income = CVS(OldCust.Income)  'Convert MBF to SINGLE
                                        'and assign to DOUBLE

      'Insert the array element into the ISAM database:

  INSERT #2, NewCust

 LOOP

 PRINT "The file is loaded into the database"   'tell user that the
                                                'file is loaded
 PRINT "Number of records read: "; i; "  hit key to continue"
 SLEEP

 SETINDEX #2
 MOVEFIRST #2                'Print out the database, to verify that
 DO WHILE NOT EOF(2)         'the information is there.
       RETRIEVE #2, NewCust

       PRINT
       PRINT NewCust.Name
       PRINT NewCust.Address
       PRINT NewCust.Zip
       PRINT NewCust.Sex
       PRINT NewCust.Age
       PRINT NewCust.Income
       MOVENEXT #2
 LOOP


 331. ISAM Benchmark of PDS 7.10 Versus 7.00, FoxPro, and Btrieve

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | fast faster slow slower quick
 Last Modified:  5-DEC-1990    ArticleIdent: Q64979

 The following article gives a benchmark comparison of ISAM file speed
 in Microsoft BASIC Professional Development System (PDS) version 7.10
 versus the following products: BASIC PDS version 7.00, Fox Software's
 FoxPro version 1.0, and Novell's Btrieve version 5.0c.

 These performance comparisons are taken from the Microsoft press
 release document (for BASIC PDS 7.10) dated July 24, 1990.

 ISAM DATABASE SPEED COMPARISONS
 -------------------------------

 The benchmark suites used by Microsoft for performance testing and
 comparison are similar to those used by Software Digest at National
 Software Testing Laboratories (NSTL) for benchmarking of relational
 databases. All benchmark tests below were performed on a COMPAQ 386
 20e with a 110 MB hard disk and 640K of conventional memory under
 MS-DOS.

 The following four files ("tables" in BASIC PDS) were used: two files
 (tables) with three indexed columns and 1000 records; one file (table)
 with three indexed columns and 10000 records; and one file (table)
 with two indexed columns and 10000 records. Each record (in each
 file/table) contained 10 text columns plus one integer column, for a
 total of 122 characters per record. The total database size for the
 four files (tables) was 6 megabytes in both BASIC PDS and Novell
 Btrieve. A disk unfragmentation utility was run to compact the
 databases before performing the benchmarks.

 BASIC PDS 7.10 Versus 7.00
 --------------------------

 All tests ran using 64K of ISAM buffer space.

                                                        PDS 7.10 Improvement
 Item                               PDS 7.00  PDS 7.10  Percent over PDS 7.00
 ----                               --------  --------  ---------------------

 Average Individual Record Search   1.4        1.3         8%
 Group Record Search On Index       6.3        5.6        13%
 Group Record Search w/o an Index  14          9.9        41%
 Subtotal 100 Groups/Short Field   34.8       20.7        68%
 Two-File Join with Subtotals     203.2      131.4        55%
 3-File Join w/ Hi Record Return  220.9      173.7        27%
 Three-File Join with Subtotaling 154.1       62.1       148%
 4-File Join w/ Lo Record Return   82.8       39.9       108%
 Two-File, Many to Many Join        5.6        3.1        81%

 Mean Speed Improvement of 61 percent BASIC PDS 7.10 over PDS 7.00

 Microsoft BASIC PDS 7.10 Versus FoxPro 1.0 (from Fox Software)
 --------------------------------------------------------------

 These tests ran using maximum buffer space available in 640K
 conventional memory.

                                                          PDS 7.10 over
 Item                               FoxPro 1.0  PDS 7.10  FoxPro, in Percent
 ----                               ----------  --------  ------------------

 Average Individual Record Search   1.5          1.3        15%
 Group Record Search On Index       4            4.4        -9%
 Group Record Search w/o Index      7.5          9         -17%
 Subtotal 100 Groups/Short Field   22.1         20.2         9%
 Two-File Join with Subtotals      34.3         30.8        11%
 3-File Join with Hi Record Return 72.1         46.4        55%
 Three-File Join with Subtotaling  44.9         34.2        31%
 4-File Join with Lo Record Return 30.3         32.1        -6%
 Two-File, Many to Many Join        4.7          3.1        52%

 Mean Speed Improvement of 16 percent BASIC PDS 7.10 over FoxPro

 BASIC PDS 7.10 Versus Novell's Btrieve 5.0c
 -------------------------------------------

 These tests were run using a maximum buffer space of 64K in Btrieve.

                                                        PDS 7.10 over
 Item                           Btrieve 5.0c  PDS 7.10  Btrieve, in Percent
 ----                           ------------  --------  -------------------

 Average Individual Record Search    0.8       1.3       -38%
 Group Record Search On Index        4.3       5.6       -23%
 Group Record Search w/o an Index   19.9       9.9       101%
 Subtotal 100 Groups/Short Field    64.3      20.7       211%
 Two-File Join with Subtotals      400       131.4       204%
 3-File Join w/ Hi Record Return   288       173.7        66%
 Three-File Join with Subtotaling  235.9      62.1       280%
 4-File Join w/ Lo Record Return   110        39.9       176%
 Two-File, Many to Many Join        15.3       3.1       394%

 Mean Speed Improvement of 152 percent BASIC PDS 7.10 over Btrieve


 332. QBX.EXE "Out of Data Space" for Variable-Length String Array

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER |
 Last Modified:  4-SEP-1990    ArticleIdent: Q65034

 The 4-byte string descriptor for each variable-length string resides
 in DGROUP (the 64K near heap) regardless of the compiler string option
 (near or far).

 When using the far strings option (BC /Fs option, or running within
 QBX.EXE), only the contents (not the 4-byte descriptors) of the
 variable-length string are stored in the far segments. Large string
 arrays (near or far) can quickly fill up DGROUP with string
 descriptors, as shown in the examples below.

 This article illustrates how you can get both "Out of Data Space" and
 "Out of Memory" messages in QBX.EXE using an empty variable-length
 string array (dynamic or static) that fills up DGROUP with 4-byte
 string descriptors.

 This article also illustrates how, from a compiled .EXE program, you
 can get an "Out of String Space" message at run time when allocating
 dynamic variable-length string arrays and how you can get a "LINK :
 Fatal error L2041: Stack plus data exceed 64K" message at LINK time
 when allocating static variable-length string arrays, due to filling
 up DGROUP with 4-byte string descriptors.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Code Example 1 (Static Array)
 -----------------------------

 This example shows size limits using a static array of variable-length
 strings.

 This DIM gives "Out of Data Space" followed by "Out of Memory" in
 QBX.EXE before the PRINT can be executed. The string descriptors (4
 bytes per string-array element) are using up all the memory in DGROUP.

    PRINT "This never prints in QBX.EXE"
    DIM b$(12000)    ' Note:  DIM b$(11000) works without error.

 If you compile this program with BC /Fs to a .EXE program, you can
 specify up to about DIM b$(14000) without error. DIM b$(15000) gives
 the LINK.EXE error "LINK : Fatal error L2041: Stack plus data exceed
 64K" because DGROUP is filled up with string descriptors.

 Code Example 2 (dynamic array)
 ------------------------------

 This example shows size limits using a dynamic array of
 variable-length strings.

 The following program gives "Out of Data Space" followed by "Out of
 Memory" at run time in QBX.EXE when the program reaches REDIM
 A$(12000). From a compiled .EXE program, an "Out of String Space"
 message occurs at REDIM A$(16000) or larger, again because DGROUP is
 filled up with string descriptors.

 Note that each string element has 2 additional bytes of overhead per
 element in the far heap segment (even for this array that is empty of
 any string contents).

 CLS
 FOR j = 5 TO 16
 REDIM a$(j * 1000)
 PRINT "DIM a$("; j * 1000; ")"; " Far string segment usage="; FRE(a$)
 ' STACK returns the space available in DGROUP:
 PRINT "DGROUP available="; STACK
 NEXT

 References:

 See Pages 719-720, "Variable Storage and Memory Use," and also Chapter
 11, "Advanced String Storage," in the "Microsoft BASIC 7.0:
 Programmer's Guide" for BASIC PDS versions 7.00 and 7.10.


 333. "Error During Run-Time Initialization" Mixing Near/Far Strings

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  4-SEP-1990    ArticleIdent: Q65082

 When you link separate modules together to make an .EXE program, all
 the modules must have been compiled with the same string option (near
 or far strings).

 If you LINK modules or libraries together and some were compiled with
 and some without the BC /Fs (far strings) option, the .EXE program can
 hang in version 7.00, or can give the following error message at run
 time in version 7.10:

    Error during run-time initialization

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Combining string options can cause unpredictable results in the .EXE
 program at run time. After the possible hang in 7.00, a warm boot
 (CTRL+ALT+DEL) may not work. To reboot, you may have to turn the
 computer off, then back on.

 To avoid this problem, only LINK routines that were compiled with the
 same string option (BC /Fs or no /Fs).

 Also, remember that the QBX.EXE environment of BASIC PDS 7.00 and 7.10
 only supports far strings, not near strings. In other words, all BASIC
 object modules linked into a Quick library (.QLB file) for use in
 QBX.EXE must be compiled with the BC /Fs option.

 What Are Far Strings?
 ---------------------

 The contents of far strings are stored in the far heap, and the
 contents of near strings are stored in near heap (the 64K DGROUP
 segment).

 Note that the BC /Fs (far strings) option affects only the storage
 location of variable-length string variables. The far strings option
 does NOT affect fixed-length string variables. (Also, fixed-length
 strings do NOT have a string descriptor.)

 Every variable-length string variable (or array element) has a 4-byte
 string descriptor. The 4-byte string descriptor for each
 variable-length string always resides in DGROUP (the 64K near heap)
 regardless of the compiler string option (near or far).

 References:

 See Pages 719-720, "Variable Storage and Memory Use," and also
 Chapter 11, "Advanced String Storage," in the "Microsoft BASIC 7.0:
 Programmer's Guide" for BASIC PDS versions 7.00 and 7.10.

 Code Example 1
 --------------

 Compile the following program with the BC /Fs option, as follows:

    BC TEST1/Fs;

 REM  TEST1.BAS
 CALL TEST

 Compile the following program with BC and no options, as follows:

    BC TEST2;

 REM  TEST2.BAS
 SUB TEST STATIC
 PRINT "This is a test"
 END SUB

 Link as follows:  LINK TEST1+TEST2;

 Now run TEST1.EXE. If compiled in BASIC 7.00, the program may display
 random garbage on the screen and hang. If compiled in BASIC 7.10, the
 program will give the error message "Error during run-time
 initialization."

 Code Example 2
 --------------

 Compiling and linking any program in BASIC PDS 7.10 as follows gives
 "Error during run-time initialization" when you run the BASFILE.EXE
 program:

    BC /Fs basfile.BAS;
    LINK basfile.OBJ,,,BRT71ENR.LIB;

 Note that "ENR" in BRT71ENR.LIB refers to "E" for IEEE math, "N" for
 near strings, and "R" for MS-DOS (real) mode.


 334. QBX Incorrectly Initializes Array in TYPE with OPTION BASE 1

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 buglist7.10 SR# S900205-152
 Last Modified:  4-SEP-1990    ArticleIdent: Q65083

 QBX.EXE may not correctly initialize programs with OPTION BASE 1 and
 arrays in user-defined TYPEs during their initial loading. The array
 in the type is treated as a zero-based array instead of a one-based
 array. This problem is corrected by saving the file or editing either
 the OPTION BASE 1 line or the TYPE statement. This behavior does not
 occur when the program is compiled with BC.EXE.

 Microsoft has confirmed this to be a problem with the QBX.EXE
 environment of Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available.

 Code Example
 ------------

 The following code example will give incorrect results (a length of 3
 and a lower bound of 0) on the initial run of the program, but after
 saving the file (without reloading), or after editing either of the
 indicated lines, the program runs correctly (giving a length of 2 and
 a lower bound of 1):

    OPTION BASE 1                      'Editing here corrects error
    TYPE ArrayType
         Array(2) AS STRING * 1        'Editing here also corrects
    END TYPE
    DIM varArrayType AS ArrayType
    PRINT LEN(varArrayType)               'Should be 2 (incorrectly 3)
    PRINT LBOUND(varArrayType.Array)      'Should be 1 (incorrectly 0)
    END


 335. OS/2 BASIC Program to Get Machine Configuration; DosDevConfig

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900820-52
 Last Modified:  4-SEP-1990    ArticleIdent: Q65103

 A protected mode BASIC program can call the OS/2 API function
 DosDevConfig() to find out machine-configuration information, such as
 how many printers are attached, how many serial ports and floppy disk
 drives are available, whether or not a math coprocessor is present,
 and the type of primary display adapter (monochrome or color). Below
 is a sample program demonstrating this.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS OS/2.

 DosDevConfig() takes the following parameters:

    Parameter   Description
    ---------   -----------

    PTR BYTE    Receives machine information

    WORD        Type of information needed
                0 = Number of printers attached
                1 = Number of serial ports available
                2 = Number of floppy disk drives available
                3 = Check math coprocessor (returns 1 = present, 0 = not)
                4 = PC Submodel type
                5 = PC model type
                6 = Primary display adapter type (returns 0 = monochrome,
                    1 = color)

    WORD        Reserved by OS/2, must be set to 0

 BASIC 6.00 and 6.00b and BASIC PDS 7.00 and 7.10 can directly call
 OS/2 API functions by linking with the DOSCALLS.LIB (for 6.00 and
 6.00b) or OS2.LIB (for 7.00 and 7.10) libraries. Note that a BYTE in
 BASIC has a type of STRING * 1, and a WORD has a type of INTEGER.
 Also, data items preceded by PTR can be passed using the SEG keyword
 in the DECLARE statement; otherwise, BYVAL is used.

 For more information on DosDevConfig(), see Pages 509-510 of "Advanced
 OS/2 Programming" by Ray Duncan (Microsoft Press, 1989).

 The following sample program (MACHINFO.BAS) displays configuration
 information about the machin, namely, how many printers are attached,
 how many serial ports and floppy disk drives are available, whether or
 not a math coprocessor is present, and the type of primary display
 adapter (monochrome or color). Note that a printer does not have to be
 online to be "attached."

 To compile the program, enter the following at the OS/2 command
 prompt:

    bc machinfo;

 The LINK command line for BASIC 6.00 and 6.00b is as follows:

    link /nop machinfo,,,doscalls;

 The LINK command line for BASIC PDS 7.00 and 7.10 is as follows:

    link /nop machinfo,,,os2;

 MACHINFO.BAS
 ------------

 DEFINT A-Z

 TYPE InfoType
    Info AS STRING * 1
 END TYPE

 DECLARE FUNCTION DosDevConfig% (SEG InfoVar AS InfoType,_
                                 BYVAL InfoNeeded%, BYVAL Reserved%)

 DIM InfoVar AS InfoType   'Will receive configuration information.

 'Get number of printers attached.
 ErrorCode% = DosDevConfig% (InfoVar, 0, 0)
 PRINT "There are" CVI(InfoVar.Info + CHR$(0)) " printers attached."

 'Get number of serial ports available.
 ErrorCode% = DosDevConfig% (InfoVar, 1, 0)
 PRINT CVI(InfoVar.Info + CHR$(0)) " serial ports are available."

 'Get number of floppy disk drives available.
 ErrorCode% = DosDevConfig% (InfoVar, 2, 0)
 PRINT CVI(InfoVar.Info + CHR$(0)) " disk drives are available."

 'Check if math coprocessor is available.
 ErrorCode% = DosDevConfig% (InfoVar, 3, 0)
 IF InfoVar.Info = CHR$(1) THEN
    PRINT "A math coprocessor is present."
 ELSE
    PRINT "A math coprocessor is not present."
 END IF

 'Get the type of primary display adapter (color or mono).
 ErrorCode% = DosDevConfig% (InfoVar, 6, 0)
 IF InfoVar.Info = CHR$(1) THEN
    PRINT "The primary display adapter is color."
 ELSE
    PRINT "The primary display adapter is monochrome."
 END IF

 END


 336. How to Call VioPopUp() from a Protected Mode BASIC Program

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900812-3
 Last Modified:  4-SEP-1990    ArticleIdent: Q65105

 A protected mode BASIC program that is running in a background session
 can temporarily seize control of the screen and interact with the
 user, regardless of which session is currently in the foreground. This
 is accomplished by calling the OS/2 API function VioPopUp(). Below is
 a sample program that demonstrates how to do this.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2 and to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS OS/2.

 VioPopUp() takes two parameters:

    Parameter   Description
    ---------   -----------

    PTR WORD    Contains option flags for pop-up
        WORD    Video handle (0 = default)

 If bit 0 of the first parameter is set, VioPopUp() will wait until a
 pop-up is available. If bit 0 is cleared, VioPopUp() will return
 immediately with an error if a pop-up is not available.

 If bit 1 of the first parameter is set, the pop-up will be
 transparent. This means that if the display is already in a text mode,
 no mode change will occur and the screen contents and cursor position
 will not be disturbed. Also session switching will be disabled. If the
 display is not in a text mode, the pop-up will have no special effect
 on any other process.

 If bit 1 of the first parameter is cleared, the pop-up will be
 nontransparent. This means that the display will be put into an
 80-by-25 text mode, the screen cleared, and the cursor placed into the
 upper-left corner. Also, session switching will be disabled.

 During a pop-up, all other processes run normally except that they
 can't interact with the user or modify the physical display. Any
 attempt to perform these actions is blocked until the process in
 pop-up mode calls the API function VioEndPopUp(). When this happens,
 the pop-up process reverts to the background, the process that was in
 the foreground when the pop-up occurred regains its status, and the
 physical display is restored.

 Microsoft BASIC 6.00 and 6.00b and Microsoft BASIC PDS 7.00 and 7.10
 can directly call OS/2 API functions by linking with the DOSCALLS.LIB
 (for 6.00 and 6.00b) or OS2.LIB (for 7.00 and 7.10) libraries. Note
 that a WORD in BASIC has a type of INTEGER. Also, data items preceded
 by PTR can be passed using the SEG clause in the DECLARE statement of
 the function; otherwise, BYVAL is used.

 For more information about VioPopUp() and VioEndPopUp(), see Pages
 113-115 of "Advanced OS/2 Programming" by Ray Duncan (Microsoft Press,
 1989).

 The following sample program generates a pop-up, displays a message
 while in the pop-up, and then ends the pop-up. Before doing so, it
 lets the user choose the type of pop-up (transparent or
 nontransparent) and then emits five delayed beeps to allow the user to
 switch sessions.

 To compile the program, enter the following at the OS/2 command prompt:

    bc popup;

 The command line for linking the program with BASIC 6.00 or 6.00b is
 as follows:

    link /nop popup,,,doscalls;

 The command line for linking the program with BASIC PDS 7.00 or 7.10
 is as follows:

    link /nop popup,,,os2;

 POPUP.BAS
 ---------

 DECLARE FUNCTION VioPopUp%    (SEG Flags%, BYVAL Handle%)
 DECLARE FUNCTION VioEndPopUp% (BYVAL Handle%)

 'Loop until the user chooses a valid option.
 DO UNTIL (Flags% = 1) OR (Flags% = 3)

    'Prompt the user for an option.
    INPUT "Transparent (1) or Nontransparent (2) pop-up"; Flags%

    'Setting bit 0 tells OS/2 to wait until a pop-up is available.
    'Bit 1 is set for transparent mode, cleared for nontransparent.
    SELECT CASE Flags%
    CASE 1
       Flags% = 3
    CASE 2
       Flags% = 1
    CASE ELSE
       PRINT "Invalid option!"
       BEEP
    END SELECT

 LOOP

 FOR I% = 1 TO 5   'Delay so user has time to switch sessions.
    BEEP
    SLEEP 1
 NEXT I%

 ErrorCode% = VioPopUp% (Flags%, 0)   'Start the pop-up.

 COLOR 13, 1                          'Display a colored message on the
 LOCATE 12, 36                        'the screen.
 PRINT "Surprise!"

 LOCATE 25, 35
 PRINT "Hit any key";                 'Wait until a key is pressed.
 WHILE INKEY$ = ""
 WEND

 ErrorCode% = VioEndPopUp% (0)        'End the pop-up and the program.
 END


 337. "Out of Stack Space" Using RETURN <linenumber> for SUB Event

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QuickBas
 Last Modified:  4-SEP-1990    ArticleIdent: Q65177

 If an event occurs in a procedure (SUB or FUNCTION), then returning
 from event-handling with the RETURN <linenumber> statement always
 leaves unrecoverable information on the stack, which can lead to the
 error message "Out of Stack Space" after many trapped events.

 This behavior is a result of violating the following design rule: to
 correctly restore (pop) the stack after handling an event, you must
 always return to the procedure level where the event occurred. This
 applies to all events trapped with the ON <event> GOSUB statement
 (where <event> includes COM, KEY, PEN, PLAY, TIMER, STRIG, and
 others).

 RETURN <linenumber> or <linelabel> is only designed to return from
 events that occur at the module-level (main-level) code. This
 correctly pops the stack.

 You must use RETURN without the <linenumber> or <linelabel> option if
 you want to RETURN to a SUB or FUNCTION procedure where an event was
 trapped. This correctly pops the stack.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2; to
 Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS
 OS/2; and to Microsoft QuickBASIC versions 1.00, 1.01, 1.02, 2.00,
 2.01, 3.00, 4.00, 4.00b, and 4.50 for MS-DOS.

 To demonstrate the "Out of stack space" message, run the following
 program and hold down the ESC key, which will be trapped in a loop
 until the error occurs. The "Out of stack space" error occurs because
 this program incorrectly allows events in the SUB to be handled by the
 RETURN <linelabel> instead of an ordinary RETURN.

 Code Example
 ------------

 DECLARE SUB test ()
 ' This is an example where the RETURN <linenumber>
 ' statement gives you "Out of Stack Space" (after about 53 ESC key
 ' trap iterations in QBX.EXE, or 118 if compiled in BC.EXE) when the
 ' event (pressing the ESC key) is trapped in a SUB procedure.
 KEY 15, CHR$(0) + CHR$(1)    ' Trap ESC key
 ON KEY(15) GOSUB escape
 KEY(15) ON
 PRINT "now in main"
 again:
   CALL test
   PRINT "Done"
 END
 escape:
   j = j + 1
 ' The FRE(-2) function returns a value decreased at each iteration by
 ' the number of bytes of stack (associated with the SUBprogram) that
 ' were lost:
   PRINT j; "ESC key was pressed. Continue in main. FRE(-2)="; FRE(-2)
   KEY(15) ON   ' <-- Must say KEY(15) ON here or else the
                '   RETURN <linelabel> statement will leave the
                '   ON KEY(15) GOSUB trap still active, which does an
                '   implied KEY(15) STOP. If the key had been trapped
                '   in the main program, then RETURN <linelabel> would
                '   work normally, and you wouldn't have to use
                '   KEY(15) ON here.
   RETURN again

 SUB test STATIC
 PRINT "Now in SUB"
 WHILE INKEY$ = "": WEND
 PRINT "You pressed some key other than ESC."
 END SUB

 References:

 The following is taken from Page 296 (under the "RETURN Statement") of
 "Microsoft BASIC 7.0: Language Reference" for versions 7.00 and 7.10:

    RETURN with a line label or line number can return control to a
    statement in the module-level code only, not in procedure-level
    code.

 The following is taken from Page 227 (under the heading "ON event
 Statement") of "Microsoft BASIC 7.0: Language Reference" for versions
 7.00 and 7.10:

    The RETURN linenumber or RETURN linelabel forms of RETURN can be
    used to return to a specific line from the trapping routine. Use
    this type of return with care, however, because any GOSUB, WHILE,
    or FOR statements active at the time of the trap remain active.
    BASIC may generate error messages such as NEXT without FOR. In
    addition, if an event occurs in a procedure, a RETURN linenumber or
    RETURN linelabel statement cannot get back into the procedure
    because the line number or label must be in the module-level code.

 The above information is accurate, but it should be added that if an
 event occurs in a procedure (SUB or FUNCTION), then returning from
 event-handling with the RETURN <linenumber> statement leaves
 unrecoverable information on the stack, which eventually leads to the
 error message "Out of Stack Space" after many trapped events.


 338. "Redo from Start" for Correct INPUT in QB and BASIC PDS

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QuickBas buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified:  4-SEP-1990    ArticleIdent: Q65194

 Normally, the INPUT statement correctly gives a "Redo from start"
 message if you mistakenly type a string as input when a number is
 expected. However, the INPUT statement incorrectly gives the error
 message "Redo from start" when all of the following conditions
 coincide:

 1. The program is using the INPUT "prompt", <variable list> form of
    the INPUT statement.

 2. The variable being INPUT is a single-precision element of a
    $DYNAMIC array.

 3. The program does NOT contain error trapping, was NOT compiled
    with BC /X, and does NOT have line numbers.

 The INPUT statement will also incorrectly display a question mark (?)
 prompt under the above conditions. The problem occurs in executable
 (.EXE) programs compiled with BC.EXE, but does not occur in the QB.EXE
 or QBX.EXE environment.

 Microsoft has confirmed this to be a problem with QuickBASIC versions
 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b, buglist4.50); with
 Microsoft BASIC Compiler versions 6.00 and 6.00b; and with Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 This problem can be easily worked around in any one of the following
 ways:

 1. Compile the program with BC /X.

 2. Include ON ERROR GOTO error-trapping in the program.

 3. Include a line number on the line where the INPUT occurs.

 4. Use the following format to prompt the user:

       PRINT "prompt message";
       INPUT "", <variable list>

 5. Use a static array instead of a dynamic array.

 Code Example:
 ------------

 The example below demonstrates this problem. Compile and link the
 program as follows:

    BC INPUT.BAS ;
    LINK INPUT ;

 When you run this program and correctly enter a number (such as 3.21
 or 0) or press ENTER alone, the program incorrectly gives a "Redo from
 start" message. You must press CTRL+C or CTRL+BREAK to stop the
 program.

    ' $DYNAMIC
    DIM z(4)
    i% = 1
    z(i%) = 0
    INPUT "Input a real number: ", z(i%)
    END


 339. Must Use BYVAL at Both Ends When CALLing 7.10 SUB or FUNCTION

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900820-85
 Last Modified:  4-SEP-1990    ArticleIdent: Q65287

 When passing parameters by value to a BASIC SUBprogram or FUNCTION
 procedure, you must use the BYVAL attribute from both the calling end
 and the receiving end.

 By itself, using BYVAL in the SUB or FUNCTION statement (at the
 receiving end) isn't enough to tell the SUB or FUNCTION to pass by
 value. If you don't also use the BYVAL attribute in the CALL statement
 or the DECLARE statement, then by default BASIC will pass by reference
 and push only the address of the variable on the stack. If you
 mistakenly use BYVAL only at the calling end or only at the receiving
 end, then an incorrect value will be passed.

 This information only applies to Microsoft BASIC Professional
 Development System (PDS) version 7.10, since passing parameters to
 BASIC SUBprograms and FUNCTIONS with the BYVAL attribute was first
 introduced version 7.10.

 Note for Versions Earlier Than 7.10: In Microsoft BASIC PDS version
 7.00, in Microsoft BASIC Compiler versions 6.00 and 6.00b, and in
 QuickBASIC versions 4.00, 4.00b, and 4.50, you could not DECLARE or
 CALL a BASIC routine with parameters having the BYVAL attribute, since
 BYVAL could be used only for parameters of non-BASIC routines (such as
 C or Macro Assembler).

 NOTE: If you create a program in an editor outside the QBX.EXE
 environment without DECLARE statements at the top of the program,
 DECLARE statements will not automatically be added to your code. As a
 result, a SUB statement that contains a formal parameter with the
 BYVAL attribute (at the receiving end) will have no BYVAL declaration
 at the calling end. Instead of specifying BYVAL in a DECLARE
 statement, you can specify BYVAL in the CALL statement.

 Code Example: Incorrect Way to Pass by Value
 --------------------------------------------

 The program below, written in an editor outside of the QBX.EXE
 environment, will pass the offset of the variable A& to the
 SUBprogram, although the SUBprogram is expecting the actual value
 contained in A&. This happens because each end of the call to the
 SUBprogram acts blindly on the information that it has. The call to
 TestPass blindly assumes that it is passing a value by reference,
 which is the default. It therefore passes the offset (in this case
 3030) of the variable A& to the SUBprogram TestPass. The SUBprogram
 TestPass is expecting to receive the value of the variable A&, as is
 dictated by the BYVAL attribute in the SUB statement. The program
 therefore prints 3030 (the offset) on the screen, instead of the
 constant 2 (the value).

 CALL TestPass (2&)  'Notice no declaration of BYVAL in CALL or
                     'DECLARE, so default is pass (send) by reference.
 SUB TestPass(BYVAL A&)  'BYVAL in SUB says to pass (receive) by value.
     B& = A&
     PRINT A&        ' Prints 3030, the offset of A&.
 END SUB

 Correct Way to Pass by Value, Using BYVAL in DECLARE and SUB
 ------------------------------------------------------------

 DECLARE SUB TestPass(BYVAL A&)
 ' BYVAL in the above DECLARE means to pass (send) by value.
 CALL TestPass (2&)
 SUB TestPass(BYVAL A&)  'BYVAL in SUB means pass (receive) by value.
     B& = A&
     PRINT A&      ' prints 2, the value (contents) of A&
 END SUB

 Another Correct Way to Pass by Value, Using BYVAL in CALL and SUB
 -----------------------------------------------------------------

 CALL TestPass (BYVAL 2&)  'BYVAL in CALL means pass (send) by value.
 SUB TestPass(BYVAL A&)    'BYVAL in SUB means pass (receive) by value.
     B& = A&
     PRINT A&      ' prints 2, the value (contents) of A&
 END SUB

 References
 ----------

 The following is taken from the README.DOC file for BASIC 7.10:

    In version 7.10, BASIC supports the use of the BYVAL keyword
    in CALL, DECLARE, SUB, and FUNCTION statements for BASIC
    procedures. You can use BYVAL to pass parameters by value
    rather than by reference (the default). It is no longer
    necessary to enclose parameters in parentheses to emulate
    passing by value. For more information and an example of using
    BYVAL in BASIC procedures, see the online Help for the DECLARE
    statement (BASIC procedures). For specifics on using BYVAL with
    CALL, see the online Help for the CALL statement (BASIC
    procedures).


 340. BASIC Program to Read COBOL BCD (COMP-3) Numbers

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S900828-36 B_COBOL
 Last Modified:  2-JAN-1991    ArticleIdent: Q65323

 Below is a BASIC program that reads a data file created by Microsoft
 COBOL containing binary-coded-decimal (COMP-3) numbers. This is
 accomplished by reading in the file one byte at a time, interpreting
 those bytes according to the binary-coded-decimal (BCD) format, and
 performing calculations based on those interpretations to generate
 equivalent BASIC double-precision floating-point numbers.

 This information applies to Microsoft QuickBASIC versions 4.00, 4.00b,
 and 4.50 for MS-DOS; to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS and MS OS/2; and to Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for MS-DOS and MS
 OS/2.

 The information about binary-coded-decimal numbers and the COMP-3
 format applies to Microsoft COBOL Compiler versions 3.00 and 3.00a for
 MS-DOS and MS OS/2, and to Microsoft COBOL Professional Development
 System version 4.00 for MS-DOS and MS OS/2.

 Microsoft COBOL 3.00, 3.00a, and 4.00 support a data type commonly
 referred to as binary-coded-decimal (BCD) format. The syntactical name
 for this data type in COBOL is COMP-3.

 The bytes used to store a COMP-3 number can contain two base-10 digits
 each. The high nibble (4 bits) stores one digit of the number and the
 low nibble (4 bits) stores the next digit to the right. That is, the
 high nibble stores a digit whose place in the number has a power of 10
 that is one greater than that of the digit in the low nibble.
 Moreover, the first byte used to store the number will contain the
 digit with the highest power of 10; subsequent bytes will hold digits
 that have successively lesser powers of 10. (Note: There are two
 nibbles in every byte.)

 A special case is made for the last byte, where the high nibble stores
 the last digit in the number, and the low nibble stores the sign of
 the number. The low nibble will contain 15 if the number is unsigned,
 12 for positive, and 13 for negative. Also, if the number of nibbles
 needed for digits plus the sign nibble will not fill a whole number of
 bytes, the high nibble of the byte storing the first digit is set to
 0.

 As an example, here is a binary representation of how the number 69
 (signed positive) would be stored:

    +---------- First Byte ---------+--------- Second Byte ---------+
    |                               |                               |
    +- High Nibble -+- Low Nibble --+- High Nibble -+- Low Nibble --+
    |               |               |               |               |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |               |               |               |               |
    +------ 0 ------+------ 6 ------+------ 9 ------+-- Positive ---+

 Below is a BASIC program (BCDTODBL.BAS) that converts the COMP-3
 numbers in a COBOL data file to BASIC's double-precision numbers. The
 program reads in each byte of the file sequentially, interpreting it
 as either a pair of digits or a digit and a sign. The program knows
 that it has read all the digits in a number when the low nibble of the
 last byte read contains a sign value (12, 13, or 15). When this
 happens, the program circulates through all the digits accumulated for
 the number and multiplies each by its associated power of 10. The
 result of this iterative calculation is assigned to a double-precision
 floating-point number. Finally, one more calculation is performed on
 the number so that it will contain the amount of decimal places
 specified by the user.

 Following the BASIC program is a COBOL program (WRITEBCD.CBL) that
 creates a file containing a user-specified amount of COMP-3 signed
 numbers. To compile and link the program in COBOL 3.00 or 3.00a, enter
 the following commands from the DOS or OS/2 prompt:

    cobol writebcd;
    link writebcd;

 The compile lines for COBOL Professional Development System (PDS)
 version 4.00 are as follows:

    cobol writebcd;
    link writebcd,,,coblib cobapi;

 The BASIC program can be run or compiled from within the QB.EXE or
 QBX.EXE environments. See your BASIC documentation for information on
 using the QB.EXE or QBX.EXE environments.

 BCDTODBL.BAS
 ------------

 DIM Digits%(15)       'Holds the digits for each number (max = 16).
 DIM BASICeqv#(1000)   'Holds the BASIC equivalent of each COMP-3 number.

 'Clear the screen, get the filename and the amount of decimal places
 'desired for each number, and open the file for sequential input:
 CLS
 INPUT "Enter the COBOL data file name: ", FileName$
 INPUT "Enter the number of decimal places desired: ", Decimal%
 OPEN FileName$ FOR INPUT AS #1

 DO UNTIL EOF(1)   'Loop until the end of the file is reached.
    Byte$ = INPUT$(1, 1)   'Read in a byte.
    IF Byte$ = CHR$(0) THEN  'Check if byte is 0 (ASC won't work on 0).
       Digits%(HighPower%) = 0       'Make next two digits 0. Increment
       Digits%(HighPower% + 1) = 0   'the high power to reflect the
       HighPower% = HighPower% + 2   'number of digits in the number
                                     'plus 1.
    ELSE
       HighNibble% = ASC(Byte$) \ 16      'Extract the high and low
       LowNibble% = ASC(Byte$) AND &HF    'nibbles from the byte. The
       Digits%(HighPower%) = HighNibble%  'high nibble will always be a
                                          'digit.
       IF LowNibble% <= 9 THEN                   'If low nibble is a
                                                 'digit, assign it and
          Digits%(HighPower% + 1) = LowNibble%   'increment the high
          HighPower% = HighPower% + 2            'power accordingly.
       ELSE
          HighPower% = HighPower% + 1 'Low nibble was not a digit but a
          Digit% = 0                  '+ or - signals end of number.

          'Start at the highest power of 10 for the number and multiply
          'each digit by the power of 10 place it occupies.
          FOR Power% = (HighPower% - 1) TO 0 STEP -1
          BASICeqv#(E%)=BASICeqv#(E%) + (Digits%(Digit%) * (10^Power%))
          Digit% = Digit% + 1
          NEXT

          'If the sign read was negative, make the number negative.
          IF LowNibble% = 13 THEN
             BASICeqv#(E%) = BASICeqv#(E%) - (2 * BASICeqv#(E%))
          END IF

          'Give the number the desired amount of decimal places, print
          'the number, increment E% to point to the next number to be
          'converted, and reinitialize the highest power.
          BASICeqv#(E%) = BASICeqv#(E%) / (10 ^ Decimal%)
          PRINT BASICeqv#(E%)
          E% = E% + 1
          HighPower% = 0
       END IF
    END IF
 LOOP
 CLOSE   'Close the COBOL data file, and end.

 WRITEBCD.CBL
 ------------

       $SET ANS85
        IDENTIFICATION DIVISION.
        PROGRAM-ID.  WriteBCD.

        ENVIRONMENT DIVISION.
        INPUT-OUTPUT SECTION.
        FILE-CONTROL.
            SELECT BCDFile ASSIGN TO "BCD.DAT".

        DATA DIVISION.
        FILE SECTION.
        FD BCDFile.
        01 BCDNumber      PIC S9(5) COMP-3.

        WORKING-STORAGE SECTION.
       *   Holds the number of COMP-3 items to write to the file.
        01 TotalNumbers   PIC 99 COMP-5.

        PROCEDURE DIVISION.

       *   Get the number of COMP-3 items to write to file.
           DISPLAY "Enter the number of items to write:".
           ACCEPT TotalNumbers.

       *   Open the COMP-3 file for sequential output and write each
       *   number out to the file as the user enters it.
           OPEN OUTPUT BCDFile.
           PERFORM TotalNumbers TIMES
              ACCEPT BCDNumber
              WRITE BCDNumber
           END-PERFORM.

       *   Close the COMP-3 file and end.
           CLOSE BCDFile.


 341. EOF in 7.00 Returns "Nonzero" for TRUE, But 4.50 Returns -1

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900822-29 B_QuickBas
 Last Modified:  4-SEP-1990    ArticleIdent: Q65396

 The EOF function has changed slightly from QuickBASIC versions 4.50
 and earlier to Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and later. In QuickBASIC, the EOF function will return 0
 (zero) for FALSE and -1 for TRUE. In BASIC PDS 7.00, EOF still returns
 0 for FALSE, but it returns "nonzero" for TRUE. This means that EOF
 will return a positive or negative number other than 0 if the end of
 the file has been reached or if you are at the "end" of an ISAM table.
 Previous QuickBASIC programs that hard coded a check for -1 will have
 to be changed to check for a nonzero value. Since 0 is equivalent to
 FALSE and nonzero evaluates to TRUE in BASIC, this is an easy change
 to make. For instance, you do not need to check "IF EOF = -1 THEN
 GOSUB foo"; instead, you can use "IF EOF THEN GOSUB foo". This second
 check will work in any version of Microsoft BASIC.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2. This
 article documents a change from Microsoft QuickBASIC 1.00, 1.01, 1.02,
 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50 for MS-DOS, and from Microsoft
 BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS OS/2.


 342. BC /R Makes UBOUND and LBOUND Incorrect for Multi-DIM Array

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QuickBas buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified:  4-SEP-1990    ArticleIdent: Q65402

 The UBOUND and LBOUND functions return the upper and lower bounds of
 an array. However, if a program is compiled using the BC /R compiler
 option, which stores multidimensional arrays in row major order, the
 UBOUND and LBOUND functions return incorrect dimension bounds for
 multidimensional arrays.

 Microsoft has confirmed this to be a problem with the BC /R option in
 QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b,
 buglist4.50) for MS-DOS; in Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS and MS OS/2; and in Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for MS-DOS and OS/2.
 Microsoft is researching this problem and will post new information
 here as it becomes available.

 Note that by default (without the /R option), BC.EXE stores arrays in
 column major order, and the UBOUND and LBOUND functions return correct
 values. Note also that the /R switch cannot be used within QBX.EXE;
 therefore, QBX.EXE can only store arrays in column major order. UBOUND
 and LBOUND work correctly in QBX.EXE.

 For more information on using the BC /R compiler switch, query in this
 Knowledge Base on the following words:

    MULTIDIMENSIONAL AND COLUMN AND ROW AND MAJOR

 Although the array is stored differently in memory by the /R compiler
 option, the upper and lower bounds of each dimension do not change.
 Therefore the values returned by UBOUND and LBOUND for a given
 dimension are supposed to be the same compiling with or without BC /R.

 When a program is compiled with the BC /R switch, the UBOUND and
 LBOUND (for a given dimension) incorrectly return the bounds for the
 opposite dimension. For example, in a two-dimensional array, if you
 request the UBOUND and LBOUND values for the first dimension, the
 values returned will incorrectly be those of the second dimension.
 Requesting the UBOUND and LBOUND values for the second dimension
 incorrectly gives you the bounds for the first dimension.

 In an odd-dimensioned array, UBOUND and LBOUND return correct bounds
 for the middle dimension, but incorrect bounds for all other
 dimensions when compiled BC /R. For example, in a three-dimensional
 array, UBOUND and LBOUND for the first dimension incorrectly return
 bounds for the third dimension; UBOUND and LBOUND for the third
 dimension incorrectly return bounds for the first dimension; but
 UBOUND and LBOUND for the second dimension correctly return bounds for
 the second dimension.

 Code Example
 ------------

 The following program example demonstrates the problem:

 DIM A(-1 TO 1, -2 TO 2)     ' DIMensions A() as a 2-dimensional array.
    ' Print lower and upper bound of first dimension:
 PRINT LBOUND(A, 1), UBOUND(A, 1)
    ' Print lower and upper bound of second dimension:
 PRINT LBOUND(A, 2), UBOUND(A, 2)

 Output when compiled without BC /R (correct):

    -1      1
    -2      2

 Output when compiled with BC /R (incorrect):

    -2      2
    -1      1


 343. LINK Creating Temporary File Can Hang on 3Com 3+ Open Network

 Product Version(s): 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900824-163 B_QuickBas
 Last Modified:  4-SEP-1990    ArticleIdent: Q65403

 A customer reported that when using LINK.EXE version 5.10 (the linker
 that comes with Microsoft BASIC Professional Development System [PDS]
 version 7.10) on a workstation running on a 3Com 3+ Open network, the
 computer may hang if the linker needs to generate a .TMP file.

 If you set the TMP environment variable to a directory on the
 workstation's own hard drive, the linker should function correctly.

 This information applies to Microsoft BASIC PDS version 7.10 and
 LINK.EXE version 5.10. The problem does not occur when using Microsoft
 BASIC PDS version 7.00 and LINK.EXE version 5.05.

 Please note that Microsoft BASIC PDS 7.10 is designed to support only
 the IBM PC-NET and MS-NET compatible networks.

 When the linker does not have enough room to work correctly in memory,
 it will write a temporary file to disk and display the message:

    Temporary file .\xxxxxxxx has been created

 This customer reported that without a TMP environment variable set,
 the linker attempted to write the temporary file on the server
 machine, which hung his computer. After he added the TMP environment
 variable and assigned it a path to a directory on the workstation's
 own hard drive, the computer did not hang. The TMP environment
 variable can be set by either typing a line such as the following at
 the DOS prompt or by putting it into your AUTOEXEC.BAT file:

    TMP=C:\directory name

 The problem only occurred when the workstation was running under DOS.
 While running under OS/2 version 1.20, the problem did not occur.

 The customer encountered this problem on a workstation with the
 following configuration:

    386 Clone
    3Com 3+ Open Network version 1.1e
    DOS 4.01


 344. Solve BASIC 6.0 "Unresolved External" with OS/2's DOSCALLS.LIB

 Product Version(s): 6.00 6.00b
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900821-150
 Last Modified:  4-SEP-1990    ArticleIdent: Q65404

 When you are creating Microsoft BASIC Compiler versions 6.00 and 6.00b
 protected mode programs that make calls to OS/2 API functions, the
 DOSCALLS.LIB library must be linked in. This library allows the linker
 to resolve external references to the API functions.

 However, the DOSCALLS.LIB that comes with BASIC will not allow the
 linker to resolve references to all of the API functions. This version
 of DOSCALLS.LIB was designed to support only a subset of them. The
 linker can use the DOSCALLS.LIB that comes with OS/2 to resolve those
 external references to API functions that are not supported by the
 BASIC version of DOSCALLS.LIB.

 This information applies to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2.

 If an API function is not supported by the BASIC version of
 DOSCALLS.LIB, the linker will generate an "Unresolved external" error
 if it finds a call to it in an object file. To remedy the situation,
 the program must be linked with the OS/2 version of DOSCALLS.LIB. This
 version of DOSCALLS.LIB is usually placed in the main OS/2 directory
 (C:\OS2, for example) by the OS/2 installation program.

 Note that Microsoft BASIC Professional Development System versions
 7.00 and 7.10 for MS OS/2 use a library named OS2.LIB (instead of
 DOSCALLS.LIB) to resolve external references to API functions. OS2.LIB
 provides support for all API functions, so linking with the OS/2
 version of DOSCALLS.LIB should never be necessary in BASIC PDS 7.00
 and 7.10.


 345. 7.10 Memory Lost If Reassign $DYNAMIC String Array to STRING$

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900816-176 buglist7.00 buglist7.10
 Last Modified: 26-DEC-1990    ArticleIdent: Q65478

 In a compiled .EXE file, assigning a $DYNAMIC variable-length-string
 array element directly to a BASIC intrinsic string function (such as
 STRING$) creates an internal temporary string that may fail to be
 deallocated. Repetitive reassignments can cause "Out of String Space"
 or "Out of Memory" errors. This article documents this problem with
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 and shows two examples of the problem.

 Microsoft has confirmed this to be a problem with BASIC PDS versions
 7.00 and 7.10 for MS-DOS and MS OS/2. This problem does not occur in
 the QBX.EXE environment, or in earlier versions of Microsoft BASIC
 Compiler or QuickBASIC. We are researching this problem and will post
 new information here as it becomes available.

 The problem can occur for dynamic variable-length-string array element
 assignments of the form A$(x)=STRING$(n). But this form of assignment
 may not give the problem in some cases, such as in Code Example 1
 where A$(x)=STRING$(n) appears within a FOR...NEXT loop.

 Any one of the following code modifications works around the problem:

 1. Use a $STATIC array instead of a $DYNAMIC array,

 -or-

 2. First assign a temporary variable such as temp$ to the BASIC
    string function (STRING$), then assign the array element to temp$:

    temp$=STRING$(12000)
    A$(1)=temp$
    temp$=""

 -or-

 3. Use the CLEAR statement to erase the memory wasted by the
    internal temporary string (but CLEAR also erases all other
    variables).

 -or-

 4. In some cases, surrounding the assignment with a FOR...NEXT
    structure may eliminate the problem, such as in Code Example 1.

 This problem is not affected by any compiler options that limit
 optimizations (BC /D, /X, etc.). The problem occurs with both near and
 far strings (BC /Fs, /Fn).

 Code Example 1
 --------------

 The following code example shows one case (in a FOR...NEXT block) that
 reclaims memory properly and three cases that fail to return the
 string memory. In the cases that fail, the a$()=SPACE$() statement
 fails to release an amount of string space equal to the length of the
 string assigned (due to an internal unreleased temporary string).
 Repeated assignments will decrease string memory until string memory
 eventually runs out.

 Compile and LINK as follows (compile and LINK options do not affect
 the problem):

    BC STRING;
    LINK STRING;

 REM $DYNAMIC
 CLS
 DIM a$(10)
   PRINT "FRE(a$(1)) at start of program: ", FRE(a$(1))

   PRINT "Case #1: memory recovered if string deallocated in FOR loop."
   PRINT "For loop works fine -- memory restored"
   FOR i% = 12000 TO 0 STEP -12000
     a$(1) = SPACE$(i%)
     PRINT "Free during FOR loop: ", FRE(a$(1))
   NEXT

   PRINT "Case #2: Prompt user for size of string."
   INPUT "Input big number (try 12000):", big%
   a$(1) = SPACE$(big%)   'Both A$(1) & internal string consume memory:
   PRINT "FRE(a$(1)) after allocation: ", FRE(a$(1))
   INPUT "Input a small number (0):", small%
   a$(1) = SPACE$(small%) 'Internal temporary string still wastes memory:
   PRINT "FRE(a$(1)) after deallocation: ", FRE(a$(1))

   PRINT
   PRINT "Case #3. String of 12000 bytes assigned."
   big% = 12000
   a$(1) = SPACE$(big%)
   PRINT "FRE(a$(1)) after allocation: ", FRE(a$(1))
   small% = 0
   a$(1) = SPACE$(small%)
   PRINT "FRE(a$(1)) after deallocation: ", FRE(a$(1))

   PRINT "Case #4: Another string of 12000 bytes assigned."
   a$(1) = SPACE$(12000)
   PRINT "FRE(a$(1)) after allocation: ", FRE(a$(1))
   a$(1) = SPACE$(0)
   PRINT "FRE(a$(1)) after deallocation: ", FRE(a$(1))
 END

 Code Example 2
 --------------

 The program below shows that the problem also occurs in $DYNAMIC
 arrays in SUBprograms.

 Compile and link as follows:

    BC STRING2.BAS ;
    LINK STRING2 ;

 DECLARE SUB sub1 ()
 CALL sub1
 END
 SUB sub1
   DIM s(2) AS STRING   'This array is dynamic, since SUB is non-STATIC
   PRINT "FRE before string allocation: "; FRE(s(0))
   s(1) = STRING$(1000, 255)
   PRINT "FRE after string allocation: "; FRE(s(1))
   s(1) = ""
   PRINT "FRE after string deallocation: "; FRE(s(2))
 END SUB


 346. BASIC PDS 7.00 and 7.10 Cannot Use IOCTL and Far Strings

 Product Version(s): m7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900904-34
 Last Modified:  6-SEP-1990    ArticleIdent: Q65480

 Some customers have reported that the IOCTL$ function and IOCTL
 statement do not work with far strings (BC /Fs) in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10.
 Microsoft has not confirmed this to be a problem.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The IOCTL$ function and IOCTL statement allow BASIC programs to
 interact with MS-DOS character device drivers that can give and
 receive control data strings. Not all character device drivers support
 IOCTL control data strings. For instance, ANSI.SYS, which replaces the
 standard CON device driver in DOS, is a character device driver, but
 it cannot receive or send control data strings.

 For more information on MS-DOS device drivers, device driver classes,
 character device drivers, and how IOCTL works, see "Advanced MS-DOS
 Programming" by Ray Duncan (published by Microsoft Press).

 Note that the IOCTL$ function and IOCTL statement cannot be used under
 MS OS/2. You can, however, make equivalent OS/2 API function calls to
 interact with OS/2 character device drivers.


 347. "Invalid Column" If CREATEINDEX on Field of Nested User TYPE

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900822-21 docerr
 Last Modified: 21-SEP-1990    ArticleIdent: Q65506

 In Microsoft BASIC ISAM, you cannot create an index on a user-defined
 TYPE, nor can you create an index on a field of a nested user-defined
 TYPE.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 under MS-DOS and version 7.10
 under OS/2.

 Page 333 of the "Microsoft BASIC 7.0: Programmer's Guide" and Page 72
 of the "Microsoft BASIC 7.0: Language Reference" manual for versions
 7.00 and 7.10 correctly state that an index cannot be created on an
 aggregate data type such as a user-defined TYPE. However, they fail to
 state that you cannot create an index on a field of that nested
 user-defined TYPE.

 For example, in the following TYPE...END TYPE declaration, you can
 create an index on the field "CustomerName" but not on the
 user-defined TYPE "CompanyInfo" or on the field of the nested
 user-defined TYPE "CompanyID". If you try to create an index on these
 fields, an "Invalid Column" error is generated on the CREATEINDEX
 statement.

    TYPE CompanyRec
              CompanyID AS INTEGER
    END TYPE

    TYPE CustomerRec
              CustomerName AS STRING * 20
              CompanyInfo AS CompanyRec
    END TYPE


 348. BASIC OS/2 Routines to Replace UIASM.ASM for UI ToolBox

 Product Version(s): 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900821-212
 Last Modified: 21-SEP-1990    ArticleIdent: Q65515

 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 provide sample User Interface (UI) Toolbox code written
 mostly in BASIC, with a few sections written in assembler. The code is
 written specifically for MS-DOS and does not support OS/2 unless the
 code is modified.

 The UI Toolbox uses three assembler routines to provide direct video
 access to get a window (GetCopyBox), put a window (PutCopyBox), and
 change the attributes of a window (AttrBox). These routines are
 located in the UIASM.ASM source file. These three routines do not work
 under OS/2 unless you modify them for OS/2 IOPL (Input Output
 Privileges) support, or rewrite them in BASIC using OS/2 Video I/O
 (VIO) API calls.

 The following code example provides one way to replace these three
 assembler routines with BASIC code utilizing the OS/2 VIO API Calls.

 Since this code is written in BASIC, you will need to compile these
 routines with the same options you use on the modules that call them.
 These compiler options include near/far strings, protected mode, and
 alternate/emulation math.

 GetCopyBox, PutCopyBox, AttrBox are currently written in assembly
 language (in UIASM.ASM on the 7.00 and 7.10 release disk) for greater
 speed. The UIASM.BAS program below contains the equivalent BASIC
 routines using OS/2 VIO API calls. Since the code is written in BASIC,
 the speed may be notably slower compared to straight assembler code.
 Also, the multitasking nature of OS/2 adds overhead compared to
 running the same program under MS-DOS.

 GetCopyBOX and PutCopyBox uses the MID$() statement and function to
 modify the Screen Buffer variable to store and restore the screen
 contents. An "Illegal Function Call" error may occur at run time if
 the size of the window is zero (0) bytes.

 UIASM.BAS
 ---------

 '| The module below contains the following three BASIC procedures:
 '|
 '|  DECLARE SUB GetCopyBox (ULRow%, ULCow%, LRRow%, LRCol%, buffer$)
 '|  GetCopyBox -- Gets screen box info and places the info into a
 '|                string variable.
 '|
 '|  DECLARE SUB PutCopyBox (ULRow%, ULCow%, buffer$)
 '|  PutCopyBox -- Puts screen box info back on the screen from a
 '|                string variable.
 '|
 '|  DECLARE SUB AttrBox (ULRow%, ULCow%, LRRow%, LRCol%, NewAttr%)
 '|  AttrBox -- Changes the color attributes of all characters within
 '|             a box.
 '|
 '| In the above parameter lists, the beginning two characters specify the
 '| portion of the rectangle of the box being referred to, as follows:
 '|      UL = Upper-left corner of the rectangle/box
 '|      LR = Lower-right corner of the rectangle/box
 '
 ' Below are DECLARE Statements for the OS/2 VIO (Video I/O) routines:
 DECLARE FUNCTION VioReadCellStr% ( BYVAL    CellAdd&,      _
                                    SEG      NumCells%,     _
                                    BYVAL    SRow%,         _
                                    BYVAL    SCol%,         _
                                    BYVAL    VidHandle%  )
 DECLARE FUNCTION VioWrtCellStr%  ( BYVAL    CellAdd&,      _
                                    BYVAL    NumCells%,     _
                                    BYVAL    SRow%,         _
                                    BYVAL    SCol%,         _
                                    BYVAL    VidHandle%  )
 SUB GetCopyBox (ULRow%, ULCol%, LRRow%, LRCol%, ScreenBuffer$)
     '| Subtract 1 from all screen coordinates to reflect the difference
     '| between BASIC's screen BASE 1 and the VIO API BASE 0.
     '| We also make a copy of the variables, since we do not force the
     '| caller to use BYVAL or by reference calling convention.
     '|    UL = Upper-left corner of the rectangle/box
     '|    LR = Lower-right corner of the rectangle/box
     URow% = ULRow% - 1
     UCol% = ULCol% - 1
     LRow% = LRRow% - 1
     LCol% = LRCol% - 1
     '| Find width and height of the Box
     BoxHeigth% = LRow% - URow% + 1
     BoxWidth% = LCol% - UCol% + 1
     '| Calculate the actual width of the line before the FOR-loop
     '| thus performing the operation once. We need a copy of the
     '| results, since the function call changes the value of
     '| parameter passed to it.
     ActualWidth% = BoxWidth% * 2
     OldBoxWidth% = ActualWidth%
     FOR i% = URow% to LRow%
         Work$ = Space$ (ActualWidth%)
         '| Read one line from the Box of BoxWidth% long into
         '| a Work String. The format of the string is
         '| character + attribute (every two bytes make a cell)
         VIORt% = VioReadCellStr ( SSEGADD (Work$), _
                                   ActualWidth%,    _
                                   i%,              _
                                   UCol%,           _
                                   VideoHandle%  )
         '| VioReadCellStr changes the value "ActualWidth%" to reflect
         '| how many characters were actually placed into the buffer.
         '| We reset the value after every call, so we don't lose one
         '| character and attribute each time through the FOR-Loop.
         ActualWidth% = OldBoxWidth%
         '| We calculate the offset into the string where we
         '| will place the line of text.
         ScrnOff% = ActualWidth% * (i% - URow%) + 3
         '| By using the MID$ statement, we can place the information
         '| over the existing information with little work on our part.
         Mid$ (ScreenBuffer$, ScrnOff%, Len (Work$) ) = Work$
     Next i%
     '| Store the Width and Height of the BOX in the first
     '| two characters of the buffer. The Height will be on the
     '| BASE of ONE, and PutCopyBox will convert it to a BASE zero.
     Mid$(ScreenBuffer$, 1, 1) = chr$(BoxWidth%)
     Mid$(ScreenBuffer$, 2, 1) = chr$(BoxHeigth%)
 END SUB

 SUB PutCopyBox (ULRow%, ULCol%, ScreenBuffer$)
     '| Subtract 1 from all screen coordinates to reflect the difference
     '| between BASIC's screen BASE 1 and the VIO API BASE 0.
     '| We also make a copy of the variables, since we do not force the
     '| caller to use the BYVAL or by reference calling convention.
     '|    UL = Upper-left corner of the rectangle/box
     '|    LR = Lower-right corner of the rectangle/box
     URow% = ULRow% - 1
     UCol% = ULCol% - 1
     '| The first two bytes are the Width and Height used by GetCopyBox.
     '| Where the Height is from BASE 1 rather then ZERO
     BoxWidth%  = ASC(Mid$ (ScreenBuffer$, 1, 1))
     BoxHeigth% = ASC(Mid$ (ScreenBuffer$, 2, 1)) - 1
     '| We calculate the actual width of the line before the loop,
     '| rather than inside the loop.
     ActualWidth% = BoxWidth% * 2
     FOR i% = 0 to BoxHeigth%
         '| Calculate the offset into the string for each line of the box.
         ScrnOff% = ActualWidth% * i% + 3
         '| The actual row on the screen that we are printing to:
         NewRow% = URow% + i%
         '| We extract a line of text with the attributes in a
         '| similar manner to how we placed them in the string:
         Work$ = Mid$ (ScreenBuffer$, ScrnOff%, ActualWidth%)
         '| Write the line of text and attributes to the screen:
         VIORt% = VioWrtCellStr ( SSEGADD (Work$),  _
                                  ActualWidth%      _
                                  NewRow%,          _
                                  UCol%,            _
                                  VideoHandle%   )
     Next i%
 END SUB

 SUB AttrBox (ULRow%, ULCol%, LRRow%, LRCol%, NewAttr%)
     '| Subtract 1 from all screen coordinates to reflect the difference
     '| between BASIC's screen BASE 1 and the VIO API BASE 0.
     '| We also make a copy of the variables, since we do not force the
     '| caller to use the BYVAL or by reference calling convention.
     '|    UL = Upper-left corner of the rectangle/box
     '|    LR = Lower-right corner of the rectangle/box
     URow% = ULRow% - 1
     UCol% = ULCol% - 1
     LRow% = LRRow% - 1
     LCol% = LRCol% - 1
     '| Find width and height of the Box:
     BoxHeigth% = LRow% - URow% + 1
     BoxWidth% = LCol% - UCol% + 1
     '| Calculate the actual width of the line before the FOR-loop,
     '| thus performing the operation once. We need a copy of the
     '| results, since the function call changes the value of
     '| parameter passed to it.
     ActualWidth% = BoxWidth% * 2
     OldBoxWidth% = ActualWidth%
     FOR i% = URow% to LRow%
         Work$ = Space$ (ActualWidth%)
         '| Read one line from the Box of BoxWidth% long into
         '| a Work String. The format of the string is
         '| character + attribute (every two bytes make a cell)
         VIORt% = VioReadCellStr ( SSEGADD (Work$), _
                                   ActualWidth%,    _
                                   i%,              _
                                   UCol%,           _
                                   VideoHandle%   )
         '| VioReadCellStr changes the value "ActualWidth%" to reflect
         '| how many characters were actually placed into the buffer.
         '| We reset the value after every call, so we don't lose one
         '| character and attribute each time through the FOR-Loop.
         ActualWidth% = OldBoxWidth%
         For j% = 2 to ActualWidth% STEP 2
             Mid$(Work$, j%, 1) = chr$ (NewAttr%)
         Next j%
         VIORt% = VioWrtCellStr ( SSEGADD (Work$), _
                                  ActualWidth%,    _
                                  i%,              _
                                  UCol%,           _
                                  VideoHandle%   )
     Next i%
 END SUB



 349. PDS 7.10 Can Now Buffer COM1 or COM2 Input Data During a SHELL

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900904-18 B_QuickBas
 Last Modified: 21-SEP-1990    ArticleIdent: Q65548

 In most versions of Microsoft BASIC Compiler and QuickBASIC, during a
 SHELL, data coming in through the communications port is not buffered
 and is lost. A new feature of Microsoft BASIC Professional Development
 System (PDS) version 7.10 allows programs compiled with the BC /O
 (stand-alone) option to continue to buffer communications input during
 a SHELL. However, programs that use the run-time module with BASIC PDS
 7.10 still cannot handle COM1 or COM2 input during a SHELL.

 This information applies to Microsoft BASIC PDS 7.10 for MS-DOS and MS
 OS/2. The above feature is not available in the following products:
 Microsoft QuickBASIC versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00,
 4.00, 4.00b, and 4.50 for MS-DOS; Microsoft BASIC Compiler versions
 6.00 and 6.00b for MS-DOS and MS OS/2; and Microsoft BASIC PDS version
 7.00 for MS-DOS and MS OS/2.

 This feature is available only when you compile with BC /O. The /O
 compiler switch causes the program to be completely stand alone, which
 means it will run without the run-time module. This feature is not
 available with the run-time module because the run-time module is
 taken out of memory during a SHELL and reloaded when the SHELL is
 exited. Since the code for communications support is contained in the
 run-time module, it is not available during the SHELL. Therefore, the
 program cannot continue to buffer the communications data because the
 code that supports communications has been removed from memory. With a
 stand-alone program, the code for communications support is directly
 linked to the program and stays in memory, thus allowing the program
 to continue to buffer communications data during a SHELL.


 350. Disappearing SUB Statement When Editing in QB.EXE/QBX.EXE

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900830-44 buglist7.00 buglist7.10 B_QuickBAS
 Last Modified: 21-SEP-1990    ArticleIdent: Q65549

 While programming inside the QB.EXE or QBX.EXE environment, a SUB
 statement may temporarily disappear when specific steps are performed.
 These steps involve a combination of deleting the comment line above a
 SUB...END SUB, moving the cursor with the DOWN ARROW key, and using
 the TAB key. The steps below demonstrate the problem.

 Microsoft has confirmed this to be a problem in the QB.EXE environment
 of Microsoft QuickBASIC version 4.50 (buglist4.50) for MS-DOS and in
 the QBX.EXE environment of Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS. We are researching
 this problem and will post new information here as it becomes
 available. This particular problem (using the exact steps below) does
 not occur in earlier versions.

 To reproduce this problem, create a SUB containing the following code:

    '
    SUB DeleteMe
        PRINT "dummy line"
    END SUB

 Do the following on the code above:

 1. Move the cursor to the first line and delete the comment.

 2. Press the DOWN ARROW key to attempt to move the cursor to the next
    line.

 3. The following error message box will pop up:

       Blank lines not allowed before SUB/FUNCTION line. Is remark OK?

    Press the ENTER key, which will accept the message and delete the
    blank line.

 4. Press the DOWN ARROW key again to move the cursor to the next line.
    If you are using the QB.EXE program that comes with Microsoft
    QuickBASIC version 4.50, the line that says "SUB DeleteMe" will be
    deleted. If you are using the QBX.EXE program that comes with BASIC
    PDS version 7.00 or 7.10, continue to Step 5 to reproduce the
    problem.

 5. After using the DOWN ARROW key to move the cursor to any line of
    code in the SUB, press the TAB key and that line will be replaced
    with the line "SUB DeleteMe".

 6. If you press the DOWN ARROW key again, the original line will
    reappear.

 Note: If the text is not returned, you may be able to recover the text
 in BASIC PDS versions 7.00 and 7.10 by choosing the Undo command from
 the Edit menu to reverse the previous edit. The Undo command reverses
 up to 20 previous edits.


 351. SHELL "CHDIR", "Input Path for Run-Time Module" if No BC /O

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900823-137 buglist7.00 buglist7.10 B_QuickBas
 Last Modified: 14-DEC-1990    ArticleIdent: Q65550

 A SHELL statement that changes the current directory or drive (using
 DOS's CHDIR command) will display the following message when returning
 control to the BASIC program if the program is compiled to require the
 BASIC run-time module (compiled without BC /O):

    Input path for run-time module brt7nxxx.EXE [or brun4n.EXE,
                                                 or brun6nxx.EXE]

 This problem occurs only when you run the .EXE from its own directory,
 and BASIC's run-time module is also in that current directory. The
 problem does not occur if the .EXE or the run-time module is in a
 non-current directory (that is along the DOS PATH).

 Microsoft has confirmed this to be a problem in the Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS; in Microsoft QuickBASIC versions 4.00, 4.00b, and 4.50
 (buglist4.00, buglist4.00b, buglist4.50) for MS-DOS; and in Microsoft
 BASIC Compiler versions 6.00 and 6.00b (buglist6.00, buglist6.00b) for
 MS-DOS. We are researching this problem and will post new information
 here as it becomes available.

 This problem does not occur in an OS/2 protected-mode program (in
 BASIC 6.00, 6.00b, 7.00, or 7.10).

 Any one of the following works around the problem:

 1. Create a stand-alone (BC /O) .EXE file.

 2. Run your compiled .EXE while a different directory is the current
    directory. For example, if your PROG.EXE program is in the
    directory C:\DIR1, then log on to any other directory and run
    C:\DIR1\PROG or take advantage of the DOS PATH to find PROG.EXE.
    (This problem occurs only when the current directory is the same
    directory as where both the PROG.EXE program and the BASIC run-time
    module sit.)

 Code Example
 ------------

 The code example below duplicates the problem. Compile as follows:

    BC TEST.BAS;
    LINK TEST;

 To duplicate the problem, put both the TEST.EXE program and the BASIC
 run-time module (BRT7nxxx.EXE or BRUN4n.EXE or BRUN6nxx.EXE) into a
 subdirectory, make that subdirectory the current directory, then run
 TEST.EXE.

    ' TEST.BAS
    SHELL "CHDIR \"
    PRINT "TEST"


 352. Correction to DIR$ Example In "BASIC 7.0: Language Reference"

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900909-1 docerr
 Last Modified: 21-SEP-1990    ArticleIdent: Q65597

 The DIR$ function example on Page 107 of the "Microsoft BASIC 7.0:
 Language Reference" manual contains an error. To correct the problem,
 the variable "FileCount" in the last line in the following code
 fragment should be changed to "FileCount&" to match the other
 references to it in the example:

    IF LEN(DIR$(filespec$)) = 0 THEN
       FileCount& = 0
    ELSE
       FileCount = 1

 The corrected code is as follows:

    IF LEN(DIR$(filespec$)) = 0 THEN
       FileCount& = 0
    ELSE
       FileCount& = 1

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.


 353. Differences/Enhancements from BASIC PDS 7.00 to 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900730-152
 Last Modified: 21-SEP-1990    ArticleIdent: Q65598

 In August 1990, Microsoft released the Microsoft BASIC Professional
 Development System (PDS) version 7.10 for MS-DOS and MS OS/2 systems.
 This article documents those features that were added to BASIC PDS
 7.10 that are not supported in BASIC PDS 7.00. The lists below are
 titled "Language Enhancements," "New Utilities and Utility
 Improvements," and "Software Corrections."

 This information applies to Microsoft BASIC Professional Development
 System version 7.10 for MS-DOS and MS OS/2.

 Language Enhancements
 ---------------------

 1. REDIM PRESERVE changes the upper bounds (top-right dimension) of an
    $DYNAMIC array and preserves the data in the array. Previous
    versions of BASIC initialized the array to zeroes or null strings
    on a REDIM.

 2. It is now possible to pass fixed-length-string arrays as parameters
    to SUB and FUNCTION procedures.

 3. A CALL by value using BYVAL for BASIC SUB and FUNCTION subprograms
    is now possible. Previously, BASIC only supported CALL by value
    using BYVAL when calling a non-BASIC language such as C. The BYVAL
    attribute for passed parameters is now allowed when calling a BASIC
    SUB or FUNCTION.

 4. ISAM is now supported under OS/2. ISAM in PDS 7.10 can be used in
    OS/2 protected mode. (Note that ISAM in PDS 7.10 is still
    single-user ISAM as in 7.00.)

 5. ISAM support in 7.10 operates up to 50% faster than in 7.00,
    depending on the program.

 6. Communications input is buffered during a SHELL if the program was
    compiled with BC /O (stand alone) option. All previous versions of
    BASIC disabled communications support and buffering of communications
    data during a SHELL. BASIC PDS 7.10 does not, however, buffer
    communications data during a SHELL if you are using the run-time
    module (BRT71xxx.EXE).

 7. Compatibility with Microsoft C version 6.00 for interlanguage
    calling. BASIC PDS 7.10 now allows interlanguage calling to
    functions created with Microsoft C Compiler version 6.00. (BASIC
    PDS 7.00 only allowed calling to Microsoft C Compiler version 5.10
    functions.)

 New Utilities and Utility Improvements
 --------------------------------------

 1. QBX.EXE improvement: The 7.10 QuickBASIC extended (QBX.EXE)
    environment uses expanded memory more efficiently than 7.00. In
    BASIC PDS 7.00, each subprogram from 1K to 16K in size uses a full
    16K of expanded memory. In BASIC PDS 7.10, subprograms smaller than
    16K will use expanded memory in 1K chunks. In 7.10, if a subprogram
    is 2K in size, it will use only 2K of expanded memory. (Subprograms
    larger than 16K are stored in conventional memory in both 7.00 and
    7.10.)

 2. Programmer's WorkBench (PWB), a new utility: The Programmer's
    WorkBench is the integrated development environment that is
    provided with Microsoft's newest "high-end" language products. It
    integrates the following features:

    - Keyboard-driven or mouse-driven control of the WorkBench through
      use of menus and scroll bars.

    - Other utilities can be launched from PWB such as NMAKE or
      CodeView.

    - Context sensitive online Help.

    - Multiple windows allow managing multiple files for large
      projects.

    - Multiple-language development within PWB.

    - Supports development under both DOS and OS/2.

    - Customizable program editor.

    - PWB is a combination of Microsoft's Quick environments (such as
      QuickBASIC and QuickC) and the Microsoft Editor, providing easier
      learning for anyone familiar with those environments. However,
      PWB offers many features over and above the Quick environments
      and the earlier Microsoft Editor.

 3. Source Browser: Source Browser is a powerful cross-referencing tool
    that can be launched from within PWB.

 4. CodeView 3.10 debugger is included.

 5. NMAKE facility: A superset of the earlier Microsoft MAKE facility.
    PWB saves you the inconvenience of remembering makefile syntax by
    building and maintaining makefiles for you.

 6. QuickHelp: QuickHelp allows you to access online documentation
    without running QBX.EXE or PWB.EXE. QuickHelp can be run from the
    DOS or OS/2 command line and can also be installed as a keyboard
    monitor under OS/2. Any Help files with the correct format can be
    used with QuickHelp.

 7. QBX.EXE improvement: In the QBX environment under the Run menu, the
    Make .EXE File command now lets you set any BC.EXE compiler option
    in the "Additional Options:" field.

 Software Corrections
 --------------------

 For a list of known problems with BASIC PDS 7.00 (or QuickBASIC 4.50)
 that are corrected in BASIC PDS 7.10, query in this Knowledge Base on
 the word "fixlist7.10".


 354. ERROR ERR May Cause "Illegal Function Call" in QBX.EXE 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900827-59 buglist7.00 fixlist7.10
 Last Modified: 20-SEP-1990    ArticleIdent: Q65640

 In a multiple-module program in which each of the modules contains an
 active error handler, executing the statement ERROR ERR within an
 error handler of any support module will normally pass control back to
 the next active error handler in the CALL tree. If an active error
 handler is not found, the program will terminate.

 Within the QBX.EXE environment of Microsoft BASIC Professional
 Development System (PDS) version 7.00, using ERROR ERR in a
 module-level error handler will incorrectly generate either "Illegal
 function call" or "Device I/O error". This problem does not occur when
 the same program is compiled using BC.EXE.

 Microsoft has confirmed this to be a problem in only the QBX.EXE
 environment of BASIC PDS 7.00 for MS-DOS. This problem was corrected
 in BASIC PDS version 7.10.

 When the following program is run in QBX.EXE version 7.00, an "Illegal
 Function Call" or "Device I/O error" results. When the program is
 compiled using BC.EXE, it will compile and run without error.

 MOD1.BAS
 --------

    '=================This is Module 1==========================
    DECLARE SUB mod2sub1 ()        'this sub is in Mod2
    ON ERROR GOTO MainErr          'Main error Handler
    CLS
    CALL mod2sub1                  'Calls the sub in Mod2
    END
    MainErr:
       PRINT "main error "; ERR    'prints the Error number
       END

 MOD2.BAS
 --------

    '===================This is Module 2========================
    Mod2ErrorHandler:            'This error handler is at the
       PRINT "Mod2 Error "       'Module level in Mod2.
       ERROR ERR                 'This causes the error again.
       RESUME NEXT
    SUB mod2sub1
       ON ERROR GOTO Mod2ErrorHandler  'Goto err handler in Mod2
       ERROR 5                         'Cause an Error 5
    END SUB

 Workaround for MOD2.BAS
 -----------------------

 To work around the problem, convert the module-level error handler (in
 the MOD2.BAS support module) into a local error handler, as follows:

    SUB Mod2Sub1
         ON LOCAL ERROR GOTO Mod2ErrorHandler
         ERROR 5
         EXIT SUB
         Mod2ErrorHandler:
             PRINT "Mod2 Error "
             ERROR ERR           'Forces the error again.
             RESUME NEXT
    END SUB


 355. BASIC 7.00 QBX.EXE: PAINT Statement Uses Far Heap

 Product Version(s): 7.00
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900920-17 buglist7.00 fixlist7.10
 Last Modified: 18-OCT-1990    ArticleIdent: Q65831

 In the QBX.EXE environment of Microsoft BASIC Professional Development
 System (PDS) version 7.00, the PAINT statement allocates an area of
 memory in the far heap that cannot be deallocated.

 Microsoft has confirmed this to be a problem in the QBX.EXE
 environment of Microsoft BASIC PDS version 7.00 for MS-DOS. This
 problem was corrected in the QBX.EXE environment of Microsoft BASIC
 PDS version 7.10 for MS-DOS.

 The following code example demonstrates the problem. When run inside
 the QBX.EXE environment of version 7.00, the values returned by the
 FRE(-1) function are different. The problem does not appear in a
 compiled .EXE program.

 Code Example
 ------------

    CLS
    SCREEN 1
    CIRCLE (190, 100), 100, 1, , , .3  'Draw an ellipse
    PRINT FRE(-1)                      'Print far heap memory available
    PAINT (190, 100), 2, 1             'Fill in the ellipse
    PRINT FRE(-1)   'This FRE(-1) value is different than previous FRE(-1)


 356. How to Pass a BASIC COMMON Block to a FORTRAN 5.00 Subroutine

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S900810-80 H_Fortran B_QuickBas
 Last Modified: 22-OCT-1990    ArticleIdent: Q65884

 This article explains how to pass a BASIC COMMON block to a FORTRAN
 version 5.00 subroutine.

 This information applies to Microsoft QuickBASIC version 4.50, to
 Microsoft BASIC Professional Development System (PDS) version 7.00 for
 MS-DOS and MS OS/2, and to Microsoft FORTRAN Compiler version 5.00.
 This information does not apply to earlier versions of these products
 (due to incompatibilities).

 To program interlanguage calling between FORTRAN 5.00 and BASIC PDS
 version 7.10, you must obtain the following application note from
 Microsoft Product Support:

    "How to Link BASIC PDS 7.10 with C 5.10, FORTRAN 5.00, or Pascal
     4.00." (application note number BB0345)

 (The FORTRAN 5.00 run-time libraries must be rebuilt as shown in this
 application note to be compatible with the BASIC PDS 7.10 run-time
 libraries.)

 The technique illustrated below shows how to pass a named BASIC COMMON
 block to a FORTRAN subroutine. This technique will not work with
 unnamed BASIC COMMON blocks. This technique will work only with
 FORTRAN version 5.00 because you must use a FORTRAN STRUCTURE...END
 STRUCTURE data type, which is not supported in earlier versions of
 FORTRAN.

 The strategy is to pass the segment and offset of the first variable
 in the named BASIC COMMON block as a parameter in the call to the
 FORTRAN subroutine. The FORTRAN subroutine should set up a
 STRUCTURE...END STRUCTURE type variable with the same format as the
 BASIC COMMON block. The FORTRAN subroutine must receive this STRUCTURE
 type variable as a formal parameter.

 Code Example
 ------------

 Below is the BASIC program BASCOMMN.BAS that sets up the named COMMON
 block, initializes the values, and calls the FORTRAN subroutine:

    'BASCOMMN.BAS **********************************************
    DECLARE SUB FORSUB (BYVAL segment%, BYVAL offset%)
    COMMON SHARED /Example/ a%, b&, c!, d#
    CLS
    a% = 10
    b& = 2000
    c! = 30.3
    d# = 40.125
    PRINT
    PRINT "Hit any key to call the FORTRAN subroutine"
    SLEEP
    CALL FORSUB(VARSEG(a%), VARPTR(a%))
    LOCATE 8, 1: PRINT "back in basic"
    END

 Below is the FORTRAN program FORCOMMN.FOR, which contains the
 subroutine Forub(). It sets up a STRUCTURE type variable similar to
 the corresponding named BASIC COMMON block, and prints out the values:

 C FORCOMMN.FOR   **********************************************
       SUBROUTINE FORSUB( VAR )
       STRUCTURE /BASCOMMON/
           INTEGER*2 A
           INTEGER*4 B
           REAL*4    C
           DOUBLE PRECISION D
       END STRUCTURE
       RECORD /BASCOMMON/ VAR
       PRINT *, VAR.A
       PRINT *, VAR.B
       PRINT *, VAR.C
       PRINT *, VAR.D
       END

 Below is the BASIC code for NEARHEAP.BAS, which allocates near heap
 space for the FORTRAN subroutine. If you are working inside the
 QuickBASIC QB.EXE or QBX.EXE environment, compile this routine and put
 it into a Quick library along with the FORTRAN program. If you are
 compiling and linking into an .EXE program, put these lines in the
 source code of the BASIC program or in a separate BASIC .OBJ module in
 a .LIB library.

    ' NEARHEAP.BAS **********************************************
    DIM Heap%(2048)
    COMMON SHARED /NMALLOC/ Heap%()

 Compile the FORTRAN program as follows:

    FL /c /AM FORCOMMN.FOR

 To work inside the QuickBASIC 4.50 QB.EXE environment, build the
 libraries as follows:

    BC NEARHEAP.BAS;
    LIB FORCOMMN.LIB+NEARHEAP+FORCOMMN;
    LINK /Q FORCOMMN.LIB, FORCOMMN.QLB,,BQLB45.LIB MLIBFER.LIB;

 To compile and link from DOS, build the libraries the same way and
 compile and link BASCOMMN.BAS as follows:

    BC BASCOMMN;
    LINK /NOE BASCOMMN+FORCOMMN.LIB,,,BRUN45.LIB+MLIBFER.LIB ;

 To work inside the BASIC PDS 7.00 QBX.EXE environment, build the
 libraries as follows

    BC /Fs/FPi NEARHEAP;
    LIB FORCOMMN.LIB+NEARHEAP+FORCOMMN;
    LINK /Q FORCOMMN.LIB, FORCOMMN.QLB,,QBXQLB.LIB MLIBFER.LIB ;

 and compile and link from DOS as follows:

    BC /Fs/FPi BASCOMMN;
    LINK /NOE BASCOMMN+FORCOMMN.LIB,,,BRT70EFR+MLIBFER.LIB ;

 The output from the program is as follows:

    Hit any key to call the Fortran subroutine
                 10
               2000
              30.300000
              40.125000000000000

    Back in BASIC


 357. Interrupt to Get QB/QBX Invocation Command Line; vs. COMMAND$

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900925-39 B_QuickBas
 Last Modified: 19-OCT-1990    ArticleIdent: Q65923

 Below is an example of how to do a DOS interrupt to obtain the
 command-line arguments used to invoked a QuickBASIC program. The
 sample program works in the QB.EXE/QBX.EXE environment and in an .EXE
 program. This program can be used to obtain the name of the Quick
 library that QB or QBX was invoked with.

 The program returns the complete command line entered (if any) after
 your .EXE or QB/QBX program name. The BASIC language offers the
 COMMAND$ function to do the same thing, but COMMAND$ returns nothing
 in the QB.EXE/QBX.EXE environment.

 This sample code applies to Microsoft QuickBASIC versions 4.00, 4.00b,
 and 4.50; to Microsoft BASIC Compiler versions 6.00 and 6.00b for
 MS-DOS; and to Microsoft BASIC PDS versions 7.00 and 7.10 for MS-DOS.
 (The code will also run under the DOS 3.x box in MS OS/2's real mode,
 but will not run under MS OS/2's protected mode.)

 The following program uses DOS interrupt 21 hex, with function 62 hex,
 to find the segment address of the program segment prefix (PSP). Based
 on this information, the program then uses the PEEK function to read
 the command line from memory. The Arguments$ function in the example
 returns a string containing all command-line arguments.

 The program arguments are located at an offset of &H80 (80 hex) from
 the PSP. The first byte at this offset is the number of characters in
 the command tail, followed by a string of ASCII characters terminated
 by a carriage return; the carriage return is not included in the
 count.

 For more information about MS-DOS interrupts, please refer to the
 following excellent book:

    "Advanced MS-DOS Programming, Second Edition", by Ray Duncan,
     published by Microsoft Press (1988).

 Sample Code
 -----------

 To use this sample code, QuickBASIC must be started with the /L option
 to load the default Quick library, QB.QLB or QBX.QLB, which contains
 the necessary INTERRUPT routine. (In QuickBASIC 4.x or BASIC compiler
 6.00x, the default Quick library is QB.QLB; in BASIC PDS 7.00 and
 7.10, it is QBX.QLB). Name the following program TEST.BAS:

 ' $INCLUDE: 'qb.bi'
 ' In QuickBASIC 4.x or BASIC compiler 6.00x, use the above include;
 ' but in BASIC PDS 7.00 and 7.10, change the above to use 'QBX.BI'
 DECLARE FUNCTION Arguments$ ()
 args$ = Arguments$
 PRINT args$
 END

 FUNCTION Arguments$
 DIM regs AS RegType
 regs.ax = &H6200
 CALL INTERRUPT(&H21, regs, regs)   ' Get the address of the PSP
 DEF SEG = regs.bx                  ' Set the current segment
 count = PEEK(&H80)                 ' Get the number of characters
 a$ = ""
 FOR a = 2 TO count                 ' Read the arguments from memory
      a$ = a$ + CHR$(PEEK(&H80 + a))
 NEXT
 Arguments$ = a$                    ' Return the arguments to program
 END FUNCTION

 If you invoked this program with

    QB TEST/L QB.QLB
       or
    QBX TEST/L QBX.QLB

 the program will print the following:

    TEST/L QB.QLB
       or
    TEST/L QBX.QLB

 If you invoked this program from an .EXE program (such as TEST.EXE) as
 follows

    TEST ARG1 ARG2

 then the program will print the following:

    ARG1 ARG2


 358. Using OS/2 API Calls for Keyboard Input from BASIC PDS

 Product Version(s): 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S900831-121
 Last Modified: 19-OCT-1990    ArticleIdent: Q65925

 This article contains a sample BASIC module, which calls the OS/2 API
 functions to perform a simple keyboard input routine in protected
 mode.

 This information applies to Microsoft BASIC compiler versions 6.00 and
 6.00b for MS OS/2 (for protected mode only) and Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for MS
 OS/2 (for protected mode only).

 For more information on the OS/2 keyboard input functions, please
 refer to the "Microsoft OS/2 Programmer's Reference" Volume 3, Pages
 164-180, published by Microsoft Press (1989).

 OS/2 protected mode allows for multiple logical keyboard buffers to be
 set up and used by a process. When a logical keyboard buffer is
 opened, it does not receive any characters until that buffer is given
 the focus by the KbdGetFocus function. When a keyboard buffer has the
 focus, it receives all characters that are typed in through the
 keyboard.

 The largest string that can be typed in is determined by the buffer
 that the program sets up; in this example, the buffer is set to 40.
 Any extra characters are ignored until the BACKSPACE, DEL, or arrow
 keys are pressed.

 This sample program uses the KbdOpen and KbdGetFocus function to open
 a logical keyboard. It then uses the KbdGetStatus and KbdSetStatus
 functions to preserve the status of the keyboard and then to modify
 the status, forcing the CAPSLOCK key on. It also uses the
 VioSetCurType function to set the display of the cursor (by default
 there is no cursor).

 To run the program in OS/2 protected mode, the program should be
 compiled and linked as follows:

      BC /Lp OS2KEY;
      LINK OS2KEY,,,BRT71ENP.LIB+OS2.LIB;

 OS2KEY.BAS
 ----------

 'This sample program OS2KEY.BAS uses OS/2 keyboard input routines.
 'Wait flags for keyboard input and status check:
 CONST IOWAIT     = 0
 CONST IONOWAIT   = 1
 'Constant declarations for KdbInfo.fsMask:
 CONST KEYBOARDECHOON            = &H0001
 CONST KEYBOARDECHOOFF           = &H0002
 CONST KEYBOARDBINARYMODE        = &H0004
 CONST KEYBOARDASCIIMODE         = &H0008
 CONST KEYBOARDMODIFYSTATE       = &H0010
 CONST KEYBOARDMODIFYINTERIM     = &H0020
 CONST KEYBOARDMODIFYTURNAROUND  = &H0040
 CONST KEYBOARD2BTURNAROUND      = &H0080
 CONST KEYBOARDSHIFTREPORT       = &H0100
 'Constant declarations for Keyboard flags:
 CONST RIGHTSHIFT    = &H0001
 CONST LEFTSHIFT     = &H0002
 CONST CONTROL       = &H0004
 CONST ALT           = &H0008
 CONST SCROLLLOCKON  = &H0010
 CONST NUMLOCKON     = &H0020
 CONST CAPSLOCKON    = &H0040
 CONST INSERTON      = &H0080
 CONST LEFTCONTROL   = &H0100
 CONST LEFTALT       = &H0200
 CONST RIGHTCONTROL  = &H0400
 CONST RIGHTALT      = &H0800
 CONST SCROLLLOCK    = &H1000
 CONST NUMLOCK       = &H2000
 CONST CAPSLOCK      = &H4000
 CONST SYSREQ        = &H8000
 TYPE KbdInfoType    'KbdInfo structure
     cb           AS INTEGER
     fsMask       AS INTEGER
     chTurnAround AS INTEGER
     fsInterim    AS INTEGER
     fsState      AS INTEGER
 END TYPE
 TYPE StringInBufType    'StringInBuf structure
     cb    AS INTEGER
     cchIn AS INTEGER
 END TYPE
 TYPE StringBufType    'Fixed length string to receive input characters
     Chars AS STRING * 40   'BASIC doesn't allow passing fixed length
 END TYPE                   'strings, so use a user-defined type of
                            'a fixed length string.
 TYPE VioCursorInfoType   'Type that holds the cursor attributes
     yStart AS INTEGER
     cEnd   AS INTEGER
     cx     AS INTEGER
     attr   AS INTEGER
 END TYPE
 'The fundamental OS/2 Keyboard functions
 DECLARE FUNCTION KbdOpen% (SEG hkbd%)
 DECLARE FUNCTION KbdClose% (BYVAL hkbd%)
 DECLARE FUNCTION KbdGetStatus% (SEG KbdInfo AS KbdInfoType, BYVAL hkbd%)
 DECLARE FUNCTION KbdSetStatus% (SEG KbdInfo AS KbdInfoType, BYVAL hkbd%)
 DECLARE FUNCTION KbdGetFocus% (BYVAL fWait%, BYVAL hkbd%)
 DECLARE FUNCTION KbdFreeFocus% (BYVAL hkbd%)
 DECLARE FUNCTION KbdStringIn% (SEG chBuffer AS StringBufType, _
         SEG StringInBuf AS StringInBufType, BYVAL fWait%, BYVAL hkbd%)
 DECLARE FUNCTION VioSetCurType% (SEG VioCursorInfo AS _
                                  VioCursorInfoType, BYVAL hvio%)
 'Dimension the structured variables
 DIM KbdInfo AS KbdInfoType
 DIM PrevkbdInfo AS KbdInfoType
 DIM StringInBuf AS StringInBufType
 DIM chBuffer AS StringBufType
 DIM VioCursorInfo AS VioCursorInfoType
 CLS
 ReturnVal% = KbdOpen%(hkbd%)             'Open a logical Keyboard
 IF ReturnVal% = 0 THEN
  PRINT "Opened logical keyboard"
  PRINT "Getting the focus: ";
  ReturnVal% = KbdGetFocus%(IONOWAIT, hkbd%)   'Make it the one to
                                               'receive keyboard
  IF ReturnVal% = 0 THEN                       'input
     PRINT "we have the focus"
     'Save the previous state of the keyboard, so it can be reset:
     PRINT "Saving the previous state of the input mode"
     PRINT "Getting the status and checking for echo mode, input mode"
     PrevkbdInfo.cb = LEN(KbdInfo)
     ReturnVal% = KbdGetStatus%(PrevkbdInfo, hkbd%)
     IF RetrunVal% = 0 THEN
       'Check echo mode:
       IF (PrevkbdInfo.fsMask AND KEYBOARDECHOON) THEN
        PRINT "Echo on, ";
       ELSE
        PRINT "Echo off, ";
       END IF
       'Check input mode:
       IF (PrevkbdInfo.fsMask AND KEYBOARDASCIIMODE) THEN  '
        PRINT "Ascii mode"
       ELSE
        PRINT "Binary Mode"
       END IF
       'Set the cursor type: size, and attribute:
       VioCursorInfo.yStart = 12    'beginning scan line for cursor
                                    'starting from top position
       VioCursorInfo.cEnd = 13      'ending scan line, zero-based
       VioCursorInfo.cx = 0         'default width, one character
       VioCursorInfo.attr = 0       'normal attribute, &hffff is hidden
       hvio% = 0                    'video handle
       ReturnVal% = VioSetCurType%(VioCursorInfo, hvio%)
       IF ReturnVal% = 0 THEN
        PRINT "Cursor is the normal TWO scan lines tall"
       END IF

       'Initialize KbdInfo to the new status:
       PRINT "Setting the CAPSLOCK on"
       KbdInfo.cb = LEN(KbdInfo)
       KbdInfo.chTurnAround = PrevkbdInfo.chTurnAround
       KbdInfo.fsInterim = PrevkbdInfo.fsInterim
       KbdInfo.fsMask = (PrevkbdInfo.fsMask OR _    'Turn on the modify
                         KEYBOARDMODIFYSTATE)       'state
       KbdInfo.fsState = (PrevkbdInfo.fsState OR _  'force caps lock on
                          CAPSLOCKON)
       ReturnVal% = KbdSetStatus%(KbdInfo, hkbd%)   'Set the status
       IF ReturnVal% = 0 THEN
        PRINT "Caps lock should be on"
        PRINT "Input some characters: ";
        StringInBuf.cb = LEN(chBuffer)
        'Input the string:
        RetrunVal% = KbdStringIn%(chBuffer, StringInBuf, IOWAIT, hkbd%)

      'During input, OS/2 does not advance the cursor, to prevent
      'writing over what was typed, use a LOCATE statement, or a double
      'PRINT to advance the cursor position
        PRINT : PRINT "This is what you typed: "; chBuffer.Chars
        SLEEP (3)                       'Sleep for three seconds
       ELSE
        PRINT "Caps on failed"
       END IF
       'Start cleaning up, restore the status, free focus, and close
       'keyboard:
       PRINT "Restoring the status"
       RetrunVal% = KbdSetStatus%(PrevKbdInfo, hkbd%)
       IF RetrunVal% = 0 THEN
        PRINT "Status Returned"
       ELSE
        PRINT "Status Could Not Be Restored
       END IF

       'Free the focus and close the logical keyboard
       PRINT "Freeing the focus and closing keyboard"
       ReturnVal% = KbdFreeFocus%(hkbd%)
       IF ReturnVal% = 0 THEN
        ReturnVal% = KbdClose%(hkbd%)
        IF ReturnVal% = 0 THEN
          PRINT "Keyboard closed"
        ELSE
          PRINT "Keyboard could not be closed, Error= "; ReturnVal%
        END IF
       ELSE
        PRINT "Focus could not be freed: "; ReturnVal%
       END IF
     ELSE
      PRINT "Get status failed: "; RetrunVal%
     END IF
  ELSE
     PRINT "ERROR on Focus, ReturnVal% = "; ReturnVal%
  END IF
 ELSE
     PRINT "Logical keyboard could not be opened"
 END IF
 END


 359. How PutCopyBox Determines Window Size in 7.00/7.10 UI ToolBox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900924-84
 Last Modified:  8-NOV-1990    ArticleIdent: Q65926

 The User-Interface (UI) ToolBox uses three assembler routines to "Get
 a window from the screen" (GetCopyBox), "Put a window to the screen"
 (PutCopyBox), and "Change the attributes of a window" (AttrBox). The
 source code for these three assembler routines are located in the
 UIASM.ASM file.

 GetCopyBox and PutCopyBox are complimentary routines, except for the
 parameters that they use. GetCopyBox needs five parameters; four to
 define the rectangle of the window and one for the string to store the
 information. PutCopyBox uses only three parameters; two for the
 upper-left corner and one for the string where the information will
 come from.

 PutCopyBox determines the size of the rectangle by the window width
 and window height stored in the first four bytes of the string.
 GetCopyBox stores this information in the string as the first four
 bytes, then places the contents of the window following the height and
 width of the window.

 The window width is the first two bytes and the window height is the
 next two bytes.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 The following is an extraction of code from UIASM.ASM used by the UI
 ToolBox routines to preserve and restore a window on the screen.

 The sections of code listed below that refer to "si,offset" are moving
 the data from memory to the string. The references to "di,offset" are
 moving the data from the string to memory.

 Sample Code
 -----------

 get_setstr:
         mov     al,x1
         sub     al,x0                   ;find width of box
         mov     bwidth,al               ;and save
         add     al,1                    ;add one to width
         mov     ah,0                    ;to find # words to move
         mov     movword,ax              ;MovWord = (width+1)
         mov     al,y1
         sub     al,y0                   ;find height of box
         mov     height,al               ;and save
         mov     es,strdseg
         mov     di,strdoff              ;string is the destination

         ; Place the Windows Width in the first word of the string
         ; The first and second bytes of the string

         mov     si,offset bwidth        ;point to width
         movsb                           ;put width in string

         ; Place the Windows Height in the second word of the string
         ; The third and fourth bytes of the string

         mov     si,offset height
         movsb                           ;and the height, too

 put_setstr:
         push    ds
         pop     es                      ;equate ES to DS

         mov     si,strdoff              ;point DS:SI to string mem
         push    ds
         mov     ds,strdseg

         ; Get the Windows Width from the string

         mov     di,offset bwidth
         movsb                           ;get width

         ; Get the Windows Height from the string

         mov     di,offset height
         movsb                           ;and height out of string

         pop     ds


 360. ISAMIO /E Cannot Extract Aggregate Types from ISAM Database

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901001-69
 Last Modified: 18-OCT-1990    ArticleIdent: Q66139

 The ISAMIO.EXE utility can extract the data from an ISAM table into an
 ASCII text file by using the /E switch. However, the ISAMIO.EXE
 utility cannot completely extract aggregate items in a table.
 Aggregate items are items in the TYPE record that are not simple
 types. Simple types are INTEGER, LONG, CURRENCY, DOUBLE, and STRING.
 Aggregate types are items such as nested TYPEs or an array in the
 TYPE. This is not a problem with the ISAMIO.EXE utility, but is a
 result of the way in which the ISAM engine stores aggregate types in
 the table and in the data dictionary. This article also describes two
 ways to view a database's data dictionary.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and version 7.10 for MS-DOS and
 MS OS/2.

 This behavior of ISAMIO results from the way in which the ISAM engine
 stores an aggregate item in the database. For an aggregate type, it
 calculates the size of the whole aggregate item, and then inserts an
 entry in the data dictionary describing it as a binary object of that
 many bytes. For example, consider the following TYPE:

 TYPE nested ' This gets nested in the TYPE below.
     junk1 AS DOUBLE
     junk2 AS STRING * 7
 END TYPE

 TYPE record
    key1 AS STRING * 20
    key2 AS nested
    key3 AS INTEGER
    key4(5) AS INTEGER
    key5 AS LONG
    key6(4)  AS DOUBLE
    key7 AS DOUBLE
    key8 AS CURRENCY
 END TYPE

 If you create a table in a database with this TYPE, the ISAM engine
 will put entries in the data dictionary saying that key2, key4, and
 key6 are "binary" objects of a certain size. Thus, when ISAMIO later
 tries to extract these items, it cannot determine what their original
 data types were; it only knows how big they were. Therefore, ISAMIO
 extracts these binary objects as a string (usually full of graphics
 characters).

 You can show what is in a database's data dictionary in two ways, as
 described in the following:

 1. ISAMIO can access the data dictionary. When you run ISAMIO to
    extract a database as a text file, you can specify a <specfile>
    parameter. For example, to extract the table called "test" in a
    database called "test.mdb" made with the above TYPEs, you use the
    following line:

       ISAMIO /E data.txt test.mdb test specfile.txt /C

    After this, DATA.TXT contains the output data. While it's
    extracting, ISAMIO takes the information in the data dictionary and
    builds "SPECFILE.TXT". Note that SPECFILE.TXT doesn't have to exist
    before you run ISAMIO. After running ISAMIO, this specfile will
    describe the data items in the ASCII text file just created. For
    instance, for the TYPE example above, the specfile created is as
    follows:

       variabletext,20,key1
       binary,,key2
       integer,,key3
       binary,,key4
       long,,key5
       binary,,key6
       double,,key7
       currency,,key8

    This clearly shows key2, key4, and key4 are seen as binary objects
    by ISAMIO.EXE.

 2. The second way to examine the data dictionary is to run the
    ISAMPACK.EXE utility. If you redirect the output from ISAMPACK into
    a file, you will have a record of the database's contents. For
    instance, use the following:

       ISAMPACK test.mdb > report.dat

    This creates a file called REPORT.DAT, which (among other things)
    has a description of the structure of each table in the database.
    The structure of the tables is determined by what is in the data
    dictionary. For the table discussed above, a part of REPORT.DAT
    will contain the following:

       Column Name               Column Type         Maximum Size
       -----------               -----------         ------------

       key1                      VarText             20
       key2                      Binary              64K
       key3                      Integer             2
       key4                      Binary              64K
       key5                      Long                4
       key6                      Binary              64K
       key7                      Double              8
       key8                      Currency            8

    Again, this shows that the data dictionary describes aggregate
    objects as being "binary".

 Code Example
 ------------

 To build the code example described above, you can use the following
 program. To run this program in QBX.EXE, you must first load the
 PROISAMD.EXE TSR. To compile and run the program, use the following:

    BC test.bas ;
    LINK test ;

 DEFINT A-Z
 TYPE nested
     junk1 AS DOUBLE
     junk2 AS STRING * 7
 END TYPE

 TYPE record
    key1 AS STRING * 20
    key2 AS nested
    key3 AS INTEGER
    key4(5) AS INTEGER
    key5 AS LONG
    key6(4)  AS DOUBLE
    key7 AS DOUBLE
    key8 AS CURRENCY
 END TYPE

 DIM Record1 AS record, Record2 AS record, Record3 AS record
 ' Code part.

 OPEN "test.mdb" FOR ISAM record "test" AS #1
 'SETINDEX #1, "testindex"

 FOR i = 1 TO 20
    PRINT "***********************************"
    PRINT "*       Get a new record          *"
    PRINT "***********************************"

    INPUT "Input a STRING * 20: ", Record1.key1
    INPUT "Input a DOUBLE: ", Record1.key2.junk1
    INPUT "Input a STRING * 7: ", Record1.key2.junk2
    INPUT "Input an INTEGER: ", Record1.key3
    FOR j = 1 TO 5
      INPUT "Input an INTEGER: ", Record1.key4(j)
    NEXT
    INPUT "Input a LONG: ", Record1.key5
    FOR j = 1 TO 4
      INPUT "Input an INTEGER: ", Record1.key6(j)
    NEXT
    INPUT "Input a DOUBLE: ", Record1.key7
    INPUT "Input a CURRENCY: ", curr1
    INSERT #1, Record1
 NEXT
 CLOSE
 END


 361. How to Change User Interface Global CONSTants in GENERAL.BI

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900313-103
 Last Modified: 18-OCT-1990    ArticleIdent: Q66140

 The GENERAL.BI $INCLUDE file in the User Interface (UI) Toolbox, which
 comes with Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10, contains several global constants (defined
 with CONST) that dictate how the Toolbox FUNCTIONs and SUBs will
 behave. When one of these CONSTants is changed, the entire Toolbox
 usually must be recompiled and linked, all libraries must be rebuilt,
 and the quick libraries must be rebuilt. This article gives
 instructions for this process.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS.

 To change the constants in the UI $INCLUDE files, follow these steps:

 1. Load the file GENERAL.BI into any editor (such as QBX.EXE).

 2. Move the cursor down to the Global Constants section.

 3. Change the CONSTant.

 4. Save the GENERAL.BI file.

 5. If you are loading the entire source code for the Toolbox into the
    QBX.EXE editor, then you can just load and run the current program
    and the changes will take effect.

 Most people use the Toolbox in the form of a compiled library or Quick
 library. To enable these changes to take effect in your Quick library
 or library, you must recompile and create both UITBEFR.QLB and
 UITBxxx.LIB. The "xxx" depends on what compiler options you use to
 create your final .EXE application and what compiler options you use
 to create the Toolbox.

 Within the QBX.EXE environment, you must use UITBEFR.QLB (which
 supports the emulator library, far strings, and real-mode). Therefore,
 a full example is provided here of altering UITBEFR.LIB and
 UITBEFR.QLB. To re-create these files, use the following commands (as
 shown in the form of an MS-DOS batch file to make rebuilding the
 libraries easier):

    REM  Recompile the four BASIC modules which make the Toolboxes
    REM  Note that the .OBJ names below MUST be used:
    BC /x /Fs /Lr /FPi GENERAL.BAS, GENEREFR.OBJ;
    BC /x /Fs /Lr /FPi MOUSE.BAS,   MOUSEEFR.OBJ;
    BC /x /Fs /Lr /FPi MENU.BAS,    MENUEFR.OBJ ;
    BC /x /Fs /Lr /FPi WINDOW.BAS,  WINDOEFR.OBJ;

    REM  Replace the existing modules in the UITBEFR.LIB. Note that
    REM  the following command should be on just one DOS command line:
  LIB UITBEFR.LIB -+GENEREFR.OBJ -+ MOUSEEFR.OBJ -+MENUEFR.OBJ -+WINDOEFR.OBJ;

    REM  Don't forget to save the old version of your library in case
    REM  an error occurs:
    RENAME UITBEFR.QLB UITBEFR.BAK

    REM  Link the new Quick library:
    LINK /q UITBEFR.LIB, UITBEFR.QLB,,QBXQLB.LIB;

 If you want to modify any of the other UITBxxx.LIB libraries, then the
 BC compile and LIB commands given above can easily be modified to work
 properly with all of these other libraries.

 The global constants that can be changed in GENERAL.BI are: FALSE,
 TRUE, MINROW, MAXROW, MINCOL, MAXCOL, MAXMENU, MAXITEM, MAXWINDOW,
 MAXBUTTON, MAXEDITFIELD, and MAXHOTSPOT. For a description of these
 constants, see page 533 of the "Microsoft BASIC 7.0: BASIC Language
 Reference."


 362. Problems May Occur When Passing the Same Array Element Twice

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | SR# S901018-67 B_QuickBAS
 Last Modified: 12-NOV-1990    ArticleIdent: Q66455

 The following program may give unexpected results when the same array
 element is passed twice to the subprogram. The problem results from a
 form of variable aliasing, where the same memory location is
 referenced by two different variables.

 To avoid aliasing problems, never pass the same variable twice in a
 given parameter list.

 Passing the same array element twice in the same parameter list can
 give incorrect or unexpected results regardless of array type or
 dynamic or static array allocation. The results may also vary between
 compiler versions. A customer reported that the program below gave the
 results that he wanted in QuickBASIC 4.00, but not in Microsoft BASIC
 Professional Development System (PDS) version 7.10; Microsoft has not
 confirmed this report.

 This behavior results from the fact the BASIC often requires a far
 pointer to access arrays, but parameters need to be passed as near
 pointers. On a CALL, BASIC sets aside a temporary location holding the
 array element and then passes a pointer to the temporary area.

 There are two options in this sort of situation: Recode the subprogram
 so that it is not necessary to pass the array element twice, or assign
 one of the parameters to a temporary variable and then pass the
 temporary variable.

 References:

 For a similar article on variable aliasing when a parameter is both
 SHARED and passed as a parameter to a subprogram, query in this
 Knowledge Base on the following words:

    DYNAMIC and ARRAY and ALIASES

 A variable should not be passed twice in the list of arguments passed
 to a procedure; otherwise, variable-aliasing problems will occur. This
 restriction is documented under "The Problem of Variable Aliasing" on
 Page 64 in the "Microsoft BASIC 7.0: Programmer's Guide" for BASIC PDS
 versions 7.00 and 7.10, on Page 68 of the "Microsoft QuickBASIC 4.5:
 Programming in BASIC" manual, and on Page 78 of the "Microsoft
 QuickBASIC 4.0: Programming in BASIC: Selected Topics" manual for
 QuickBASIC versions 4.00 and 4.00b.

 Code Example
 ------------

    DECLARE SUB MakeUpper(instring AS STRING, outstring AS STRING)
    DIM a$(15)
    a$(4)="abcdefg"
    CALL MakeUpper(a$(4), a$(4))
    PRINT a$(4)
    END

    SUB MakeUpper(instring AS STRING, outstring AS STRING)
      outstring = UCASE$(instring)
    END SUB


 363. BASIC PDS Reply Letters: Appnotes BB0354, BB0355, BB0356

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | policy appnote BB0354 BB0355 BB0356
 Last Modified: 14-NOV-1990    ArticleIdent: Q66490

 Below are the three form letters that Microsoft sends in response to
 unsolicited letters from customers who have Microsoft BASIC
 Professional Development System (PDS) version 7.00 or 7.10 for MS-DOS
 and MS OS/2:

    Appnote Number        Description
    --------------        -----------

    BB0354                BASIC PDS Question Reply Letter
    BB0355                BASIC PDS Suggestion Reply Letter
    BB0356                BASIC PDS Problem/Docerr Reply Letter

 These form letters are sent out from Microsoft Product Support
 Services (PSS) as application notes.

 Note: Page 1 of 2 is shown below for each reply letter. Page 2 of 2,
 the "Product Assistance Checklist," is the same for each reply letter
 and is shown in a separate article that can be found by querying for
 the following words:

    product and assistance and checklist

 BB0354: BASIC PDS Question Reply Letter
 ---------------------------------------

 Dear BASIC Professional Development System Customer:

 Thank you for your letter concerning the BASIC Professional
 Development System (PDS). Although we are unable to respond to your
 technical questions by letter, we do forward your letters to our BASIC
 PDS development team. This procedure provides developers with customer
 feedback, which will in turn make Microsoft's products even better.
 Now that we can no longer respond to letters (unless solicited by
 Microsoft), we are providing the following new service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 We are also offering a 900-number service to provide a higher quality
 of service, extended hours, and a shorter waiting time. To access
 "OnCall(TM) for BASIC," call [phone]. The cost is $2 per
 minute, and the service is available Monday through Friday from 6 AM
 to 6 PM Pacific Standard Time. To obtain the best possible service, we
 recommend you be at your computer and have your BASIC Professional
 Development System reference manuals and disks handy when you call.

 There are many supplemental sources of information relating to the
 BASIC languages, including reference guides and books published by
 Microsoft Press, or you can contact our "OnCall for BASIC" service at
 [phone]. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800)
 443-4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 BASIC Languages Team Manager
 Product Support Services
 BB0354

 BB0355: BASIC PDS Suggestion Reply Letter
 -----------------------------------------

 Dear BASIC Professional Development System Customer:

 Thank you for your letter and suggestion concerning our BASIC
 Professional Development System (PDS). Although we are unable to
 respond to your technical questions by letter, we do forward your
 letters to our BASIC PDS development team. This procedure provides
 developers with customer feedback, which will in turn make Microsoft's
 products even better. Now that we can no longer respond to letters
 (unless solicited by Microsoft), we are providing the following new
 service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 We are also offering a 900-number service to provide a higher quality
 of service, extended hours, and a shorter waiting time. To access
 "OnCall(TM) for BASIC," call [phone]. The cost is $2 per
 minute, and the service is available Monday through Friday from 6 AM
 to 6 PM Pacific Standard Time. To obtain the best possible service, we
 recommend you be at your computer and have your BASIC Professional
 Development System reference manuals and disks handy when you call.

 There are many supplemental sources of information relating to the
 BASIC languages, including reference guides and books published by
 Microsoft Press, or you can contact our "OnCall for BASIC" service at
 [phone]. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800)
 443-4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 BASIC Languages Team Manager
 Product Support Services
 BB0355

 BB0356: BASIC PDS Problem/Docerr Reply Letter
 ---------------------------------------------

 Dear BASIC Professional Development System Customer:

 Thank you for your letter concerning your BASIC Professional
 Development System (PDS) problem and/or documentation error. Although
 we are unable to respond to your technical questions by letter, we do
 forward your letters to our BASIC PDS development team. This procedure
 provides developers with customer feedback, which will in turn make
 Microsoft's products even better. Now that we can no longer respond to
 letters (unless solicited by Microsoft), we are providing the
 following new service:

 Our toll-line number, [phone], is available Monday through
 Friday (except holidays), 8 AM to 5 PM Pacific Standard Time, and is
 designed to answer questions about set up and installation procedures,
 problem reports, and documentation errors. We also address most
 programming, code debugging, and problem solving issues.

 We are also offering a 900-number service to provide a higher quality
 of service, extended hours, and a shorter waiting time. To access
 "OnCall(TM) for BASIC," call [phone]. The cost is $2 per
 minute, and the service is available Monday through Friday from 6 AM
 to 6 PM Pacific Standard Time. To obtain the best possible service, we
 recommend you be at your computer and have your BASIC Professional
 Development System reference manuals and disks handy when you call.

 There are many supplemental sources of information relating to the
 BASIC languages, including reference guides and books published by
 Microsoft Press, or you can contact our "OnCall for BASIC" service at
 [phone]. Support is also available electronically through
 Microsoft OnLine and CompuServe. One of the features of these services
 is to provide access to the Microsoft Knowledge Base. The Microsoft
 Knowledge Base contains the latest technical information about
 Microsoft language products. For more information about Microsoft
 OnLine, which is designed for software developers, call (800)
 443-4672. For more information about CompuServe, which is the largest
 general online information service for personal computer users, call
 [phone].

 Sincerely,

 Blain Barton
 BASIC Languages Team Manager
 Product Support Services
 BB0356


 364. "Illegal Function Call" Using Coprocessor in BASIC 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901018-77 buglist7.00 buglist7.10
 Last Modified: 12-NOV-1990    ArticleIdent: Q66560

 The following program gives an "Illegal Function Call" error when run
 as a .EXE program using a math coprocessor; however, it works
 correctly in the QBX.EXE environment or with the coprocessor disabled.

 Microsoft has confirmed this to be a problem in Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 Workaround
 ----------

 To work around this problem, do one of the following:

 1. Break the complex equation into smaller parts that are evaluated
    separately.

 -or-

 2. Turn off use of the coprocessor with SET NO87="message" at the DOS
    prompt.

 -or-

 3. Compile using the alternate math (/FPa) option.

 Code Example
 ------------

 a = .475
 b = 75
 c = 62
 d = .007
 e = 22
 f = (b * e ^ 2 / d) * SQR(1 / ((2 * b * c * a) ^ 2 + (b ^ 2 - c ^ 2))

 Simplifying the equation eliminates the problem. For example, removing
 the (b * e ^ 2 / d) factor eliminates the error.


 365. ALT+240 Hangs QBX.EXE or QB.EXE with Phoenix BIOS

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901025-47 B_QuickBas
 Last Modified: 12-NOV-1990    ArticleIdent: Q66591

 The extended ASCII characters can be typed into a BASIC program using
 the combination of the ALT key plus the three digits that correspond
 to the character. However, in Microsoft QuickBASIC version 4.50 and
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10, typing ALT+240 can hang the QB.EXE and QBX.EXE environments
 temporarily. This problem has been reproduced on a Wyse 386 with a
 Phoenix BIOS version 3.53. Pressing CTRL+BREAK will get you out of the
 hang.

 To work around the problem, use the PRINT CHR$(240) statement instead.

 This problem also occurs in a WYSE 286, running Phoenix 286 ROM BIOS
 version 2.72, and has been reported with a clone computer running
 Phoenix ROM BIOS version 3.07.

 For a related article concerning how to enter extended ASCII and
 control characters into QB.EXE and QBX.EXE, search in this Knowledge
 Base for the following words:

    extended and ASCII and ALT and 240 and 255


 366. ALERT Function in BASIC 7.10 UI Toolbox Destroys TEXT$

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901030-181 buglist7.00 buglist7.10
 Last Modified: 14-NOV-1990    ArticleIdent: Q66690

 The ALERT function in the User Interface (UI) Toolbox destroys the
 string sent to it in the TEXT$ field of the function call.

 Microsoft has confirmed this problem in Microsoft BASIC Professional
 Development System (PDS) versions 7.00 and 7.10 for MS-DOS. Suggested
 workarounds for this problem are shown below.

 Workarounds
 -----------

 Any one of the following workarounds will correct the problem but
 choices 1 and 2 may be easiest because they don't require recompiling
 WINDOW.BAS or building new UI Toolbox support libraries:

 1. Enclose the TEXT$ parameter in parentheses. For example, the
    following statement

       Alert(4, a$, 6, 20, 15, 60, "OK", "CANCEL", "")

    should be changed to the following:

       Alert(4, (a$), 6, 20, 15, 60, "OK", "CANCEL", "")

 2. Make a copy of the string before calling the ALERT function, as
    follows:

       temp$ = a$
       ALERT(4, a$, 6, 20, 15, 60, "OK", "CANCEL", "")
       a$ = temp$

 3. Modify the ALERT function in WINDOW.BAS as follows:

       a. Right after the line that says

             FUNCTION Alert (style, text$...

          put the following statement:

             TempText$ = test$

        b. Right before the END FUNCTION at the bottom of the function,
           put the following statement:

              test$ = TempText$

    You should then make a new Quick library (.QLB) and a new LINK
    library (.LIB) that use the new version of ALERT, as shown in the
    following:

       BC /X/FS GENERAL.BAS;
       BC /X/FS WINDOW.BAS;
       BC /X/FS MOUSE.BAS;
       BC /X/FS MENU.BAS
       LIB UITB+GENERAL+WINDOW+MOUSE+MENU+UIASM+QBX.LIB;
       LINK /Q UITB.LIB, UITB.QLB, , QBXQLB.LIB;

    Invoke QBX.EXE using the new UITB.QLB Quick library, as follows:

       QBX /L UITB


 367. No "Block IF Without END IF" Using IF...THEN REM in QB/QBX.EXE

 Product Version(s): 6.00 6.00b 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | B_QUICKBAS buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified: 14-NOV-1990    ArticleIdent: Q66691

 In compiled BASICs that support block IF statements, the following
 statement correctly implies a block IF ... END IF statement, instead
 of a single-line IF statement syntax (whereas GW-BASIC correctly
 treats this as a single-line IF because GW-BASIC has no block IF
 syntax):

    IF expression THEN ' Comment

 However, using a THEN REM statement, as follows, poses a problem:

    IF expression THEN REM Comment

 The problem is that the QBX.EXE (or QB.EXE) environment interprets
 THEN REM as indicating a single-line IF statement, whereas BC.EXE
 compiler interprets THEN REM as indicating a block IF.

 This inconsistency applies to Microsoft QuickBASIC versions 4.00,
 4.00b, 4.50 (buglist4.00, buglist4.00b, buglist4.50) for MS-DOS; to
 Microsoft BASIC Compiler versions 6.00 and 6.00b for MS-DOS and MS
 OS/2; and to Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 When compiling the code example below, BC.EXE gives a "Block IF
 without END IF" error but the QBX.EXE or QB.EXE environment doesn't
 give an error, and interprets the IF ... THEN REM statement as a
 single-line IF statement. If an END IF statement is put at the end of
 the code, the code example will compile with no error in BC.EXE but
 the QBX.EXE or QB.EXE environment will give an "END IF without block
 IF" error.

 The problem is caused by the REM statement on the IF line. In the
 QBX.EXE or QB.EXE environment, this case is interpreted as a
 single-line (non-block) IF. The BC.EXE compiler, however, strips off
 the REMark and interprets the line as the start of a block IF
 statement.

 Microsoft is researching which consistent syntax requirement should be
 adopted for IF ... THEN REM and will post new information here as it
 becomes available.

 Code Example
 ------------

 IF a = 3 THEN REM  Gives "Block IF without END IF" in BC.EXE
 a = 5

 To a avoid this problem, a remark should never be placed after a THEN
 statement. For example, the following code example avoids this problem
 by putting the remark on a separate line:

 REM   This remark doesn't cause a problem.
 IF a = 3 THEN
 a = 5
 END IF


 368. How to Re-create BASIC Help Files Using HELPMAKE.EXE

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901105-139
 Last Modified:  8-NOV-1990    ArticleIdent: Q66771

 HELPMAKE.EXE is designed to allow you to decode/encode the Help files
 included with BASIC PDS, and to create your own Help files for use
 with BASIC, QuickHelp, and other products that use these files.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 To decode a BASIC Help file, use the following command:

    HELPMAKE /D <HelpFileName> /O<OutputFile>

 You may now modify (customize) the decoded Help file.

 To re-encode the Help file after you have edited it, use the following
 command:

    HELPMAKE /E <SourceFile> /A: /T /W78 /O<HelpFileName>

 The options on the above encode line are explained below:

   /E   Encode the file. /E with no value gives the maximum
        compression. /E may optionally be followed by a value
        specifying the amount of compression to use:

            0 - No Compression
            1 - Run-length compression
            2 - Keyword compression
            4 - Extended keyword compression
            8 - Huffman compression

        These values may be added together to combine compression
        types. For example, /E5 will generate Run-length and Extended
        keyword compression.

   /A:  Specifies a colon as the control character. This is the default
        value so it may be omitted.

   /T   Translates dot commands. This is required to re-encode the
        BASIC Help files.

   /W78 Specifies the width of the resulting Help file. BASIC uses a
        width of 78 characters. The default is 76 so this option must
        be included.

 For a more detailed discussion of HELPMAKE, refer to Chapter 11 of
 "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10.


 369. Far FIELD Variable Assigned to Itself Doesn't UnFIELD in PDS

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901114-86
 Last Modified:  5-DEC-1990    ArticleIdent: Q67107

 When using far strings in the example below, BASIC Professional
 Development System (PDS) doesn't unFIELD a FIELDed variable when that
 variable is assigned to itself. The variable does get unFIELDed if the
 program is compiled with near strings or compiled in earlier versions
 of BASIC, or if the variable is assigned to a new value.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS and MS OS/2.

 This behavioral inconsistency emphasizes the point that you should
 never make your program depend on a variable being unFIELDed. You
 should set the contents of a FIELDed variable only with the LSET or
 RSET statement; never assign values to FIELDed variables with LET or
 direct assignment.

 If you want to use and reassign a variable without affecting the
 FIELDed buffer, copy the FIELDed variable to a permanent variable that
 is not used in a FIELD statement. Better yet, for easier programming,
 Microsoft recommends using user-defined TYPE variables instead of
 FIELD statements for defining random-access file records.

 Reference:

 The following is taken from the FIELD statement description on page
 131 of the "Microsoft BASIC 7.0: Language Reference" manual for
 versions 7.00 and 7.10:

    Do not use a variable name defined as a field in an INPUT or
    assignment statement if you want the variable to remain in a field.
    Once a variable name is a field, it points to the correct place in
    the random-access file buffer. If a subsequent INPUT or assignment
    statement with that variable name is executed, the variable's
    pointer no longer refers to the random-access record buffer, but to
    string space.

 The example below describes a specific exception to the last sentence,
 where the variable still points to the random-access record buffer and
 not to a new location in string space.

 Code Example
 ------------

 First, create a text file "data.dat" that contains the following
 data on one line:

    abcd defg hijk lmno pqrs tuvw xyz1 2345 6789

 Then run the following program in QBX.EXE, or as an .EXE compiled with
 BC /Fs (the far variable-length strings option):

 DEFSTR A-Z
 OPEN "data.dat" FOR RANDOM AS #1 LEN = 15
 FIELD #1, 5 AS a, 5 AS b, 5 AS c
 GET #1   ' Get first 15 bytes.
  PRINT a; b; c
 GET #1   ' Get next 15 bytes.
 a = a
  PRINT a; b; c
 GET #1   ' Get next 15 bytes.
  PRINT a; b; c
 CLOSE #1

 With far strings, the above example will give an output of the
 following:

    abcd defg hijk
    lmno pqrs tuvw
    xyz1 2345 6789

 The above output shows that the variable "a" was retained as a FIELDed
 variable. Adding a null string, for example < a = a + "" >, also does
 not cause the variable to be unFIELDed.

 However, if the line < a = a > is changed to < a = "test" >, then the
 variable "a" becomes unFIELDed, and the output will be as follows:

    abcd defg hijk
    test pqrs tuvw
    test 2345 6789

 The variable is only unFIELDed when it is changed.


 370. OS/2 "Path/File Access Error" Instead of "Permission Denied"

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S901024-38 buglist6.00 buglist6.00b buglist7.00 buglist7
 Last Modified:  5-DEC-1990    ArticleIdent: Q67206

 When attempting to open a file under multiple OS/2 processes or in an
 OS/2 networking environment, a BASIC program will incorrectly generate
 the error message "Path/File access error" (error code 75) when
 attempting to open a locked file. The error message it should generate
 is "Permission denied" (error code 70). This problem does not occur in
 a DOS networking environment, such as when accessing files on a server
 from a DOS LANMAN workstation. Under these conditions, the BASIC
 program generates the correct error message, "Permission denied."

 This problem occurs in Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS OS/2, and in Microsoft BASIC PDS (Professional
 Development System) versions 7.00 and 7.10 for MS OS/2. Microsoft is
 researching this problem and will post new information here as it
 becomes available.

 The following test program demonstrates the problem. To reproduce the
 problem, compile and run the program in an OS/2 session. Then switch
 to a new session and run the same program again. The file should be
 locked for writes; the second program is supposed to terminate with a
 "Permission denied" error, but instead, displays "Path/file access
 error."

 Code Example
 ------------

 OPEN "TESTFILE" FOR APPEND LOCK WRITE AS #1
 PRINT #1, "Hello"
 WHILE INKEY <> "q": WEND


 371. "Bad Record Number" Using Network Printer in OS/2, LANMAN 2.00

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified:  5-DEC-1990    ArticleIdent: Q67313

 When the DOS device "LPT1" or "LPT2" is OPENed to print over a
 Microsoft LANMAN version 2.00 network printer under OS/2, the error
 "Bad record number in line <nn> in module <module name> at address
 xxxx:xxxx" will occur when the device is closed. This error does not
 occur when printing to a local printer or to a LANMAN 2.00 network
 printer under DOS.

 Microsoft has confirmed this problem in programs compiled in Microsoft
 BASIC Compiler versions 6.00 and 6.00b for MS OS/2 and in Microsoft
 BASIC PDS (Professional Development System) versions 7.00 and 7.10 for
 MS OS/2. Microsoft is researching this problem and will post new
 information here as it becomes available.

 The following code segment demonstrates the "Bad record number" error
 when compiled and run under OS/2 with logical device "LPT1:" connected
 to a Microsoft LANMAN 2.00 network.

 Note: The code example will compile and run without error when run
 under DOS or if the logical device LPT1: refers to a local printer.

    OPEN "LPT1" FOR OUTPUT AS #1
    PRINT "Hello world"
    CLOSE #1

 To work around the problem, open the BASIC logical device "LPTn:"
 instead of the DOS "LPTn" device. The following code example will
 compile and run without error when run under DOS or OS/2, and printing
 to a local or network printer device:

    OPEN "LPT1:" FOR OUTPUT AS #1
    PRINT "Hello world"
    CLOSE #1

 Note: There is a problem when the BASIC device "LPTn:" is opened
 across two CHAINed programs. For more information, please query on the
 following words:

    CHAIN and device and I/O and LPT1 and LPRINT


 372. BC.EXE "Out of Memory" with Numeric Array Elements and SWAP

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | buglist7.00 buglist7.10
 Last Modified:  5-DEC-1990    ArticleIdent: Q67314

 Compiling the following code segment with the BC.EXE compiler gives a
 "BC : Out of memory" error. The problem will occur for any simple
 mathematical operation (addition, subtraction, multiplication, or
 division) performed on the two static-array elements appearing in the
 assignment statement below. The problem does not occur in the QBX.EXE
 environment.

    DIM d#(1), e#(1), b!(1), c&(1)
    n = 1
    a% = b!(n) + c&(n)
    SWAP d#(n), e#(n)

 Microsoft has confirmed this to be a problem in BC.EXE in Microsoft
 BASIC Profession Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 You can work around the problem in any one of the following ways:

 1. Compile the program with the BC /D option to produce debug code.

 2. Use the CINT or CLNG function to convert the first array element in
    the mathematical expression to an integer type. The example above
    will compile without error if the assignment statement is changed
    as follows:

       a%= CINT(b!(n)) + c&(n)

 3. Save one of the variables being swapped to a temporary variable and
    use the temporary variable as an argument to the SWAP statement.
    The example above will compile without error if the SWAP statement
    is changed as follows:

       f# = d#(n)
       SWAP f#,e#(n)

 4. Use dynamic arrays (instead of static arrays) by adding
    REM $DYNAMIC to the top of the program.

 The problem occurs when all of the following conditions occur
 simultaneously (as shown in the first code example):

 1. An integer variable (INTEGER or LONG type) is assigned to the
    addition, multiplication, division, or subtraction of two numeric
    static-array elements.

 2. The first array element in the mathematical expression is of type
    SINGLE.

 3. The second array element in the mathematical expression is of type
    LONG.

 4. A SWAP of two array elements of any numeric type occurs after the
    assignment statement.

 5. The code is compiled using BC.EXE


 373. In QBX 7.10, F8 Step then Editing Active Statement Can Fail

 Product Version(s): 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.10
 Last Modified:  5-DEC-1990    ArticleIdent: Q67363

 When you single step (F8) through a program in the QBX.EXE version
 7.10 environment, editing the active (highlighted) statement can give
 unexpected results under certain circumstances. For example, if you
 attempt to split the active line in two by pressing the ENTER key, the
 next line may duplicate the current line. Sometimes the first line
 splits correctly but the next line becomes an altered version of the
 first line. Note that pressing "ALT+BACKSPACE" will usually undo the
 editing problem.

 Microsoft has confirmed this to be a problem with the QuickBASIC
 extended environment (QBX.EXE) that comes with Microsoft BASIC
 Professional Development System (PDS) version 7.10 for MS-DOS. We are
 researching this problem and will post new information here as it
 becomes available.

 This problem can occur on any statement where a variable is first
 declared, including the following statements: COMMON SHARED, DIM
 SHARED, REDIM, FOR, WHILE, DO...LOOP, or IF. When creating the problem
 with FOR, WHILE, DO...LOOP, or IF statements, you must actually try
 and divide the BASIC reserved word (for example, put the cursor in the
 middle of WHILE and press ENTER).

 To reproduce the problem, perform the following steps:

 1. Add the line below to the beginning of an empty program window:

       COMMON SHARED A, B

 2. Make the line the current executing line by single stepping with
    the F8 key until that line is highlighted.

 3. Now put the cursor anywhere before the "B" (for example, put the
    cursor on the "A") and press ENTER.

 4. A dialog box will appear saying "You will have to restart your
    program after this edit. Proceed anyway?" Press ENTER.

 5. Your source code will now resemble the following:

       COMMON SHARED A
       COMMON SHARED A, B

 To reproduce the problem with an assignment statement, enter the
 single BASIC line of code "x = a + b + c" and follow the steps above.
 When the line is highlighted, place the cursor on the variable "a" and
 press ENTER. This will not duplicate the current line but will cause
 the "+" to be deleted between a and b.


 374. QBX.EXE "EMS Corrupt" Using Expanded Memory in Windows 3.00

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified:  9-JAN-1991    ArticleIdent: Q67364

 When trying to utilize expanded memory, QBX.EXE (from Microsoft BASIC
 PDS versions 7.00 and 7.10) will have problems running under Microsoft
 Windows version 3.00 enhanced mode if Windows 3.00 has not set the
 starting page-frame address for expanded memory. QBX.EXE will try to
 use expanded memory if it is available, unless the QBX /E:0 switch is
 used.

 For QBX.EXE to successfully use expanded memory, Windows needs to
 create a consecutive 64K page-frame area in the High Memory Area
 (HMA), C000 hex to EFFF hex. If this memory area is not available for
 use by QBX.EXE 7.00, QBX.EXE will give an "EMS corrupt" error message
 and return to the DOS window, or if run from an application icon, will
 return back to the Program Manager. QBX.EXE version 7.10 will fail to
 make use of expanded memory and will not give an error message.

 If QBX.EXE fails when trying to use expanded memory, the EMMExclude
 setting in the [386enh] section of your Windows SYSTEM.INI file may
 need to be changed. EMMExclude is needed to keep Windows from using
 the same memory as another device that Windows cannot detect, such as
 a network card, video card, or parts of BIOS for certain machines. To
 enable QBX.EXE to work correctly, use the EMMExclude setting for the
 minimum amount of memory, and try to move the address space used by
 network and video cards to consecutive addresses starting at C000 hex.
 Also, if there is an area of memory that you know is NOT in use, then
 the EMMInclude or EMMPageFrame setting can be used to tell Windows
 that this area is available for use.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 (For more information, see the application note "Memory Management
 Under Windows 3.00," which is available from the Windows Applications
 Support Group at Microsoft Product Support Services.)

 Windows 3.00 attempts to determine what other devices are using the
 address space C000 to EFFF hex before creating the page frame area.
 Sometimes Windows will not detect that another process is using a
 section of memory and will try to use that section of memory for
 itself. The following are symptoms that this may be happening:
 hanging; Windows immediately returning to the MS-DOS prompt after
 displaying the Windows logo; or video problems such as garbage on the
 screen or flashing colors. In this situation, the command EMMExclude
 is used to prevent Windows from conflicting with other devices.

 Also, in some situations Windows will sometimes mistakenly think that
 a section of memory is in use and will avoid creating the page frame
 area there. To make sure that Windows uses an area of memory, you can
 use the EMMInclude command. Also, the EMMPageFrame command can be used
 to specify the specific area for the expanded memory page frame.
 EMMPageFrame will only work if Windows thinks that area is available.

 The following memory map shows the common usage of each area of memory
 from A000 to EFFF hex:

 Address    Used By                  Common Usage
 -------    -------                  ------------

 A000-BFFF  Display adapter reserve  EGA and VGA use all, CGA and MDA
                                     use a portion.

 C000-DFFF  ROM expansion            Used for I/O channel BIOS.

                                     C000-C3FF: EGA BIOS.
                                     C000-DFFF: many VGA cards use the
                                     whole range.
                                     C600-C63F: PGA communications area.
                                     C800-CBFF: hard disk BIOS.
                                     D000-DFFF: unused.
                                     C800-DFFF: commonly used by
                                     network cards.

 E000-EFFF  Expansion of system      Used by many ATs and PS/2s but
            ROM                      not used by other computers.

 For example, if you have video card A, which requires address space
 C000 to C7FF hex, and network card B, which requires C800 to D7FF hex,
 use the following EMMExclude command:

    EMMExclude=C000-D7FF

 This should provide enough space for QBX.EXE to use expanded memory.

 If it is not possible to move the required HMA for the given
 applications to consecutive addresses, then you can give multiple
 EMMExclude commands. For example, if you have an IBM PS/2 that uses
 E000-EFFF hex for parts of its BIOS area that cannot be moved, and a
 network card that can use addresses C000 to CFFF or C7FF to D7FF, then
 you need to use the following EMMExclude commands:

    [386enh]
    EMMExclude= C000-CFFF
    EMMExclude= E000-EFFF

 The lower memory area for the network card should be chosen to limit
 memory fragmentation in the High Memory Area. If you know you are not
 using the area C800-DFFF and Windows still does not create a page
 swapping area, then use the EMMInclude command to force Windows to try
 and use that area of memory. The EMMInclude command overrides the
 EMMExclude command for the parts of memory that the two statements may
 have in common:

    [386enh]
    EMMInclude= C800-DFFF
    EMMExclude= C000-CFFF
    EMMExclude= E000-EFFF

 Instead of using the EMMInclude command, the EMMPageFrame command can
 be used to tell Windows exactly where to start the page frame area if
 Windows believes that the specified area is available for use:

    [386enh]
    EMMPageFrame=C800
    EMMExclude= C000-CFFF
    EMMExclude= E000-EFFF

 Making Windows create a page swapping area may not be possible with
 some machine configurations. If the above clues do not help create a
 page frame area, then the Windows Applications Unit of Microsoft
 Product Support Services may have more information about your
 particular machine configuration and may be able to help you further.

 Code Example
 ------------

 The following BASIC PDS program will tell you at what address, if any,
 a page frame has been set. By compiling as shown and running the
 program in the Windows DOS box, you can determine if and where Windows
 is creating the expanded memory page frame.

 To make a stand-alone executable program out of the following code
 sample, perform the following steps from the DOS prompt:

    BC emspage.bas /o;
    LINK emspage.obj,,,QBX.LIB;

 'This is the sample program emspage.bas
 REM $INCLUDE: 'QBX.BI'
 DIM inregs AS regtype
 DIM outregs AS regtype
 inregs.ax = &H4100
 CALL interrupt(&H67, inregs, outregs)
 IF (outregs.ax AND &HFF00) = 0 THEN
    PRINT "PAGE FRAME ADDRESS: "; HEX$(outregs.bx)
 ELSE
    PRINT "PAGE FRAME ADDRESS: NONE "
 END IF


 375. Recursive CALL in 7.0 .EXE Forgets Parent's Passed Near String

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901116-127 buglist7.00 fixlist7.10
 Last Modified:  5-DEC-1990    ArticleIdent: Q67372

 When the first layer (first call) of a recursive procedure passes a
 near string to the next layer of recursion, the value of the initial
 string passed by the parent recursive layer is forgotten within the
 parent SUB after returning from subsequent recursive layers of the
 routine. This problem does not occur if you compile with far strings
 (BC /Fs).

 This problem applies to Microsoft BASIC Professional Development
 System (PDS) version 7.00 for MS-DOS and MS OS/2. This problem has
 been corrected in BASIC PDS version 7.10.

 The code below demonstrates the problem when passing a near string in
 a recursive subprogram CALL. You can work around the problem by
 compiling with far strings.

 CLS
 CALL RecCall("A")
 END

 SUB RecCall (Text AS STRING)
    PRINT Text; "<"
    IF Text <> "B" THEN
       CALL RecCall (CHR$(ASC(Text) + 1))
       'Could use CALL ReCall("B") with same problem
    END IF
    PRINT Text; "<"
 END SUB

    Compiled with   Interpreted in QBX.EXE
    Near String     or Compiled with Far
    (Problem)       String Option (No Problem)
    -------------   --------------------------
       >A               >A
       >B               >B
       >B               >B
       >                >A


 376. CIRCLE(x,y),rad,,-0.1,0 Draws Only the Radius in BASIC

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | B_MQuickB B_QuickBas
 Last Modified: 17-JAN-1991    ArticleIdent: Q67374

 This article describes a problem with the CIRCLE statement. The CIRCLE
 command takes the following parameters:

    CIRCLE[STEP](x,y),radius!,,start!,stop!

 If you specify start! and stop!, with start! slightly larger than
 stop!, then the CIRCLE command should draw an almost complete circle.
 However, if the difference between start! and stop! is very small,
 CIRCLE may draw only a point or radius, instead of an almost complete
 circle. This problem happens in both the interpreter environment and
 in compiled programs.

 Microsoft has confirmed this to be a problem in Microsoft QuickBASIC
 version 1.00 (buglist1.00) for Apple Macintosh systems; in Microsoft
 QuickBASIC versions 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b,
 buglist4.50) for MS-DOS; in Microsoft BASIC Compiler versions 6.00 and
 6.00b (buglist6.00, buglist6.00b) for MS-DOS and MS OS/2; and in
 Microsoft BASIC Professional System (PDS) versions 7.00 and 7.10
 (buglist7.00, buglist7.10) for MS-DOS and OS/2. We are researching
 this problem and will post new information here as it becomes
 available.

 Changing the size of radius changes the requirement for the distance
 between start! and stop! necessary to reproduce the problem. When
 start! is near zero, leaving off the stop! will produce different
 results than if stop! is specified. Use the following code examples
 to reproduce the problems described above.

 Code Examples
 -------------

 ' When start! or stop! is negative, CIRCLE draws a radius and
 ' treats the angle as positive. Without the negative sign, no
 ' radius is drawn.
 '
 SCREEN 12  'Problem occurs in any graphics screen mode.
 10 CIRCLE (50, 50), 50, , -.01         'Works correctly.
 20 CIRCLE (50, 150), 50, , -.01, 0     'Should be same as line
                                        '10 but draws only the radius.
 30 CIRCLE (50, 250), 50, , -.011, 0    'Slightly larger difference
                                        'from start & stop works.
 40 CIRCLE (420, 240), 200, , -.01, 0   'This works with same end/start
                                        'as line 20 but has larger
                                        'radius

 On the Apple Macintosh, use the following code:

 CIRCLE (50, 50) 10, ,-0.001, 0


 377. OPEN "SCRN:" or "CONS:" Wrong Output in QBX.EXE When Step (F8)

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901109-37 buglist7.00 buglist7.10
 Last Modified:  5-DEC-1990    ArticleIdent: Q67378

 When you single step (F8) through a program that redirects screen
 output to either of the DOS standard devices "SCRN:" or "CONS:", the
 output will incorrectly flash momentarily on the QBX.EXE programming
 environment, instead of going to the output window.

 This problem occurs in the editing environment (QBX.EXE) of Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10.
 This problem does not occur in the Microsoft QuickBASIC environment
 (QB.EXE) shipped with QuickBASIC version 4.00, 4.00b, and 4.50.
 Microsoft is researching this problem and will post new information
 here as it becomes available.

 The following short program demonstrates the problem:

 OPEN "SCRN:" FOR OUTPUT AS #1   ' "CONS:" also shows problem.
 FOR i = 1 TO 10
         PRINT #1, i
 NEXT i

 Single step through this program in the QBX.EXE 7.00 or 7.10
 environment by repeatedly pressing the F8 key. The output will
 momentarily flash on the environment screen; no text will be displayed
 on the output screen. Note that just running the program (F5) will
 correctly print to the output screen.


 378. "BASIC 7.0: Programmer's Guide" Correction for ISAMCVT.EXE

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr SR# S900918-59
 Last Modified:  5-DEC-1990    ArticleIdent: Q67449

 The ISAMCVT utility shipped with Microsoft BASIC PDS (Professional
 Development System) versions 7.00 and 7.10 requires a "specfile" when
 converting MS/ISAM files (created by IBM BASIC Compiler version 2.00)
 that have been rebuilt without a data dictionary. Page 391 of the
 "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10
 omits the "specfile" field in its example of the ISAMCVT.EXE
 command-line syntax, when in fact, the "specfile" may be necessary if
 no data dictionary is present in the MS/ISAM file.

 Page 392 of the same manual incorrectly states that the "specfile" is
 required for converting MS/ISAM files; it should say that the
 "specfile" is required only when no data dictionary is present in the
 file. MS/ISAM database files usually contain a data dictionary, and
 only if a database is rebuilt without a data dictionary is "specfile"
 required. Therefore, the command-line syntaxes on page 391 should be
 changed as follows:

 For db/LIB
 ----------

    ISAMCVT /D filename tablename databasename

 For MS/ISAM
 -----------

    ISAMCVT /M filename tablename databasename [specfile]

 For Btrieve
 -----------

    ISAMCVT /B filename tablename databasename specfile


 379. Use hmamin Not tsrmin on Page 86 "BASIC 7.1: Getting Started"

 Product Version(s): 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901031-88 docerr
 Last Modified: 12-DEC-1990    ArticleIdent: Q67589

 On page 86 of the "Microsoft BASIC 7.1: Getting Started" manual, the
 first sentence of the second paragraph under the "Extended Memory"
 section has a typographical error. The word "tsrmin" should be changed
 to read "hmamin".

 The corrected sentence should read as follows:

    When using the HIMEM.SYS device driver, you should set hmamin to 63
    (64512 bytes) to ensure that QBX has access to the high-memory
    area.

 This information applies to Microsoft Professional Development System
 (PDS) version 7.10 for MS-DOS.


 380. UI Toolbox: "Subscript Out of Range" or Hang on WindowDo Call

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist7.00 buglist7.10
 Last Modified: 14-DEC-1990    ArticleIdent: Q67697

 If more than 20 buttons and edit fields are opened simultaneously
 within a single window, a "Subscript out of range" error will occur on
 a call to the SUB procedure WindowDo at run time. In some instances, a
 call to WindowDo may lead to a "String space corrupt" error message or
 cause the computer to hang.

 Microsoft has confirmed this to be a problem with the User Interface
 (UI) Toolbox provided with Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10. The correction for this problem
 is provided further below.

 This information applies to BASIC PDS versions 7.00 and 7.10 for
 MS-DOS.

 To avoid the problem, change the default value of the constant
 MAXHOTSPOT, which appears in the file, GENERAL.BI. Two other constants
 MAXBUTTON and MAXEDITFIELD, which appear in GENERAL.BI, set the
 maximum number of buttons and edit fields allowed. The value of
 MAXHOTSPOT should be changed from its current setting of 20 to the sum
 of these two constants. The default setting for MAXBUTTON is 50, and
 the default setting for MAXEDITFIELD is 20. MAXHOTSPOT should be
 changed to 70.

 If a call to the SUB program WindowDo leads to a computer hang or a
 "String space corrupt" error message, Microsoft suggests changing the
 constants as described in the above paragraph and rebuilding the UI
 Toolbox default libraries, UITBEFR.LIB and UITBEFR.QLB. A computer
 hang or "String space corrupt" error message usually occurs when the
 default libraries have been modified and the modules that make up the
 UI Toolbox have not been compiled with the /D option. The /D option
 enforces array bounds checking on arrays. Using the /D compile option
 will help to avoid a computer hang or a "String space corrupt" error
 message at run time.

 The following assumes that you are using the default LINK library
 UITBEFR.LIB and the Quick library UITBEFR.QLB built during set up of
 BASIC PDS.

 Once the modifications to GENERAL.BI have been made, update the
 library UITBEFR.LIB and re-create the default Quick library
 UITBEFR.QLB. Below are the steps necessary to update the .LIB file and
 re-create the .QLB file.

 Because the files GENERAL.BAS, MENU.BAS, MOUSE.BAS, and WINDOW.BAS all
 require GENERAL.BI, they must be recompiled from DOS as follows:

         BC GENERAL.BAS /FS/X/D;
         BC MENU.BAS /FS/X/D;
         BC MOUSE.BAS /FS/X/D;
         BC WINDOW.BAS /FS/X/D;

 Enter the following command line from DOS to modify the library,
 UITBEFR.LIB:

         LIB UITBEFR.LIB-+GENERAL.OBJ-+MENU.OBJ-+MOUSE.OBJ-+WINDOW.OBJ

 Enter the following from DOS to re-create the Quick library,
 UITBEFR.QLB:

         LINK /Q UITBEFR.LIB,,,QBXQLB.LIB;


 381. VAL() Fails When BASIC 7.10 NOFLTIN.OBJ Stub File Is Linked

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | buglist7.10
 Last Modified:  2-JAN-1991    ArticleIdent: Q67886

 Any argument passed to the VAL() function makes VAL() return zero or
 incorrect results in a program linked with the NOFLTIN.OBJ file from
 BASIC PDS version 7.10.

 Microsoft has confirmed this to be a problem with Microsoft BASIC
 Professional System (PDS) version 7.10 for MS-DOS and MS OS/2. We are
 researching this problem and will post new information here as it
 becomes available. (This problem does not occur in BASIC PDS 7.00.)

 The code example below prints an incorrect result for VAL() at run
 time when linked with the BASIC 7.10 stub file NOFLTIN.OBJ.

 ' File name: STUB.BAS
 d$ = "5"
 PRINT VAL(D$)   ' Is supposed to print "5".

 Compile and link with the following command lines:

    BC STUB.BAS /O;
    LINK /NOE STUB.OBJ+NOFLTIN.OBJ;


 382. "Illegal Function Call," Negative Number to Fractional Power

 Product Version(s): 1.00a 1.00b | 6.00 6.00b 7.00 7.10
 Operating System:   MACINTOSH   | MS-DOS
 Flags: ENDUSER | B_QuickBas B_GWBasicI
 Last Modified:  2-JAN-1991    ArticleIdent: Q67887

 Raising a negative number to a fractional power gives an "Illegal
 function call" in BASIC because the result will be a complex number,
 which is not supported in BASIC. (A complex number is of the form
 x+y*i where x is the real component and y is the imaginary component;
 i is the square root of -1.)

 Note: -5^(-Y) is not the same as X^(-Y) when X = -5 because -5^(-Y) is
 actually parsed as -(5^(-Y)). In other words, the exponentiation
 operator (^) has greater precedence than the subtraction (-) operator.

 This information applies to most versions of Microsoft BASIC,
 including the following:

 1. Microsoft QuickBASIC version 1.00 for the Apple Macintosh.
 2. Microsoft BASIC Compiler version 1.00 for the Apple Macintosh.
 3. Microsoft BASIC Interpreter versions 1.00, 1.01, 2.00, 2.10, and
    3.00 for the Apple Macintosh.
 4. Microsoft QuickBASIC versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00,
    4.00, 4.00b, 4.50 for MS-DOS.
 5. Microsoft BASIC Compiler versions 5.35 and 5.36 for MS-DOS.
 6. Microsoft BASIC Compiler versions 6.00 and 6.00b for MS OS/2 and
    MS-DOS.
 7. Microsoft BASIC Professional Development System (PDS) versions 7.00
    and 7.10 for MS-DOS and MS OS/2.
 8. Microsoft GW-BASIC Interpreter versions 3.20, 3.22, 3.23 for
    MS-DOS.

 The first PRINT statement below gives "Illegal function call." Many
 programmers will try debugging this code by substituting an actual
 constant for X, and the PRINT will seem to give the correct result.
 However, upon close examination of the precedence of operators, it
 will be apparent that the exponential symbol takes precedence over the
 minus sign. The expression 5^(-1/6) is parsed first and then the
 negation of this expression is performed. The third PRINT demonstrates
 what is actually happening in the first PRINT statement:

 X = -5
 PRINT X ^ (-1 / 6)       ' generates "Illegal function call"
 PRINT -5 ^ (-1 / 6)      ' same as PRINT -(5 ^ (-1 / 6)); no error
 PRINT (-5) ^ (-1 / 6)    ' generates "Illegal function call"

 To avoid the "Illegal function call" message, raise the absolute value
 (ABS) of X to the fractional power. If you do this when X is a
 negative number, please remember that you must multiply by i (the
 square root of -1) to get the true mathematical result. Because the
 square root of -1 cannot be represented in BASIC, you must keep track
 of imaginary number results yourself using a flag variable or warning
 message, for example:

    X=-5
    PRINT ABS(X) ^ (-1 / 6)
    IF SGN(X) < 0 THEN
       PRINT "Warning: the resulting root is an imaginary number. This"
       PRINT "root should be multiplied by i, the square root of -1."
    END IF


 383. LOCK May Fail to Properly Return Error After CHAIN Under OS/2

 Product Version(s): 7.00 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S901205-16 buglist7.00 buglist7.10
 Last Modified:  9-JAN-1991    ArticleIdent: Q68021

 Under MS OS/2, the following program demonstrates how a LOCK statement
 can fail to properly give a "Permission Denied" error for a locked
 record in a file kept open across a CHAIN. This problem does not occur
 under MS-DOS.

 Microsoft has confirmed this to be a problem with Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for MS
 OS/2. We are researching this problem and will post new information
 here as it becomes available.

 Code Samples
 ------------

 TEST01.BAS
 ----------

 10 ON ERROR GOTO 70
 20 OPEN "pippo" FOR RANDOM ACCESS READ WRITE SHARED AS #1 LEN=128
 30 LOCK 1, 1
 40 CHAIN "TEST02"
 70 PRINT ERR; ERL
 80 END

 TEST02.BAS
 ----------

 10 ON ERROR GOTO 70
 20 LOCK 1, 1
 30 END
 70 PRINT ERR; ERL
 80 END

 Compile and link the above programs as follows:

   BC /X/LP test01;
   LINK test01;
   BC /X/LP test02;
   LINK test02;

 Under MS-DOS, the second (CHAINed) program correctly returns a
 "Permission Denied" error (error code 70) for the LOCK statement;
 however, under OS/2, this program fails to give an error.


 384. BC "Internal Error" with Array of TYPE Using Array of STRING*1

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901222-1 buglist7.00 buglist7.10
 Last Modified:  9-JAN-1991    ArticleIdent: Q68023

 The following code example demonstrates a problem using an array of
 user-defined TYPE variables that contain an array of fixed-length
 strings of length one. The BC.EXE compiler incorrectly gives the
 message "BC : Internal Error near XXXX" when compiling this example.
 The QBX.EXE environment compiles the same example without error.

 This problem applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2. We are
 researching this problem and will post new information here as it
 becomes available.

 Code Sample
 -----------

 '$DYNAMIC
 TYPE rectype
   a(10) AS STRING * 1
 END TYPE
 DIM b(10) AS rectype
 byte% = 0
 10 b(1).a(byte%) = "a"

 Save the file as TEST.BAS and then attempt to compile with BC.EXE
 using the following command line:

    BC TEST;

 The compiler will issue the "Internal Error" message.

 The error occurs only if ALL the following conditions are met:

 1. The array b() is dynamic.

 2. The second array element in line 10 is referenced with a
    variable.

 3. The fixed-length string in the TYPE is of length one (STRING * 1).

 4. The program is compiled without run-time error checking (without
    the BC /D option).

 To work around this problem, just counteract any one of the above
 conditions, using one of the following four suggested workarounds:

 1. Make the array b() static. For example, if you add the '$STATIC
    metacommand before the DIM as follows, the program will compile
    correctly:

       '$STATIC
       DIM b(10) AS rectype
       '$DYNAMIC

 2. Reference the second element in line 10 with a constant instead of
    a variable.

 3. Use STRING * 2 or a longer length.

 4. Compile with the BC /D option.


 385. BC.EXE "AS Missing" in TYPE Using Space Between Array and ()

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901121-21 buglist7.00 buglist7.10
 Last Modified:  9-JAN-1991    ArticleIdent: Q68024

 The BC.EXE compiler gives the error "AS Missing" on an array in a TYPE
 statement if you mistakenly leave a space between the last letter in
 the array name and the left parenthesis. (This misleading error
 message will occur only if you create the program in an editor other
 than QBX.EXE. The problem doesn't occur when you save the program in
 QBX.EXE because QBX.EXE automatically removes the offending space
 character.)

 Microsoft has confirmed this to be a problem with the Microsoft BASIC
 Professional Development System versions 7.00 and 7.10 for MS-DOS and
 MS OS/2. We are researching this problem and will new information here
 as it becomes available.

 Workaround
 ----------

 To work around the problem in any editor other than QBX.EXE, remove
 the offending space character.

 To reproduce this problem, enter the following code example into any
 text editor other than QBX.EXE. (Note that if you load this program
 into the QBX.EXE environment, the space between the array name and the
 "(" character will automatically be removed.)

 TYPE t1
   s (1 TO 45) AS SINGLE
 END TYPE

 The BC.EXE compiler produces the following output when compiling this
 code:

 Microsoft (R) BASIC Compiler Version 7.10
 Copyright (C) Microsoft Corporation 1982-1990. All rights reserved.
  0030   0006       s (1 TO 45)  AS SINGLE
                      ^ AS missing
                      ^ Skipping forward to END TYPE statement

 45962 Bytes Available
 45853 Bytes Free

     0 Warning Error(s)
     2 Severe  Error(s)


 386. "Feature Removed" Using WIDTH "LPT1:",wdth% and BC /Fs in 7.00

 Product Version(s): 7.00   | 7.00
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901220-9 buglist7.00 fixlist7.10
 Last Modified:  9-JAN-1991    ArticleIdent: Q68025

 Compiled with the far strings (BC /Fs) option, the following statement
 incorrectly gives the error message "Feature removed":

    WIDTH "LPT1:",137

 This statement works correctly within the QBX.EXE environment.

 Microsoft has confirmed this to be a problem in BASIC Professional
 System (PDS) versions 7.00 for MS-DOS. This problem was corrected in
 BASIC PDS version 7.10.

 Enter the following program and name it SAMPLE.BAS:

    wdth% = 137
    WIDTH "LPT1:",wdth%

 Compile the program with the following options:

    BC SAMPLE.BAS /D/O/Fs/Lr/FPi/T/C:512;
    LINK SAMPLE.OBJ;

 Now, run SAMPLE.EXE to demonstrate the error message "Feature removed
 in line No line number in module <name>".

 To work around the problem, compile without the far strings option
 (without /Fs), or upgrade to version 7.10, or change the program to
 read as follows:

    WIDTH LPRINT wdth%


 387. QBX.EXE, PWB.EXE Help Files "Not Found," Conflict Under OS/2

 Product Version(s): 7.10
 Operating System:   OS/2
 Flags: ENDUSER | SR# S901116-141 S_PWB
 Last Modified:  9-JAN-1991    ArticleIdent: Q68027

 If you are running under OS/2 and you have QuickBASIC Extended
 (QBX.EXE from Microsoft BASIC Professional Development System) version
 7.10 running in the DOS box, as well as Programmer's WorkBench
 (PWB.EXE) in an OS/2 window, you may be unable to access BASIC help
 files from QBX.EXE.

 The error message

    File <HelpFile>.HLP not found -
    Correct your help path in options + set paths

 will appear in QBX.EXE when you attempt to use the online help if
 PWB.EXE is already using the same help files. Ending the PWB session
 will allow QBX.EXE to use the BASIC help files.

 Note: PWB does not need to have open the same help screen as QBX.EXE
 for this error to occur.

 Microsoft has confirmed this to be a problem in BASIC Professional
 Development System (PDS) version 7.10 for MS OS/2. A workaround is
 given below.

 If you have PWB configured to use the BASIC help files, then while
 running it in protected mode, the BASIC help files cannot be accessed
 from QBX.EXE. It does not matter in what order you start the programs;
 PWB.EXE can access the help files, and QBX.EXE cannot.

 The following error message is misleading:

    File <HelpFile>.HLP not found - ...

 In the test performed, the help file existed, the HELPFILES
 environment variable was set correctly, and the help files path under
 the Options menu within QBX.EXE was set correctly.

 Workaround
 ----------

 Make two copies of the help files on your hard drive and set the help
 files path in PWB.EXE and QBX.EXE, each to a different set of help
 files. Make sure that the help files are not in the same directory as
 either PWB.EXE or QBX.EXE. In this situation, the two programs will
 not conflict with one another.


 388. 7.10 "Subscript Out of Range," WindowDo with No Open Windows

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901228-57
 Last Modified: 17-JAN-1991    ArticleIdent: Q68123

 If a WindowDo statement is executed before any windows are opened, a
 "Subscript out of range" error will occur. This article explains why
 the error happens and gives two ways of correcting the error.

 This information applies to the User Interface (UI) ToolBox provided
 with Microsoft BASIC Professional Development System (PDS) versions
 7.00 and 7.10 for MS-DOS.

 The problem is caused by WindowInit incorrectly initializing the
 variable GloStorage.currMenu to -1 instead of 0 (zero). WindowDo
 checks to see if currMenu is 0 (zero) to determine if there are no
 open windows, and WindowDo generates the error when it tries to access
 window number -1.

 To work around this problem, do one of the following:

 1. Open a window and then immediately close it. This will set currMenu
    back to 0 (zero). For example:

       WindowInit
       WindowOpen 1,6,5,12,25,0,7,0,7,15,FALSE,FALSE,FALSE,FALSE,0,""
       WindowClose 1
       WindowDo 0,0

 2. To correct the problem permanently, modify WINDOW.BAS:

    a. Load the WINDOW.BAS module into QBX.EXE.

    b. Push F2 to view the subprograms and then move to WindowInit.

    c. Locate the line that reads "GloStorage.currMenu = -1", and change
       it to "GloStorage.currMenu = 0".

    d. Save the new copy of WINDOW.BAS. Then follow the instructions at
       the beginning of GENERAL.BAS to create a new LINK library (.LIB)
       and Quick library (.QLB).

 Code Sample
 -----------

 When the following program is run in the QBX.EXE environment, it will
 generate a "Subscript out of range in Quick library module: WINDOW"
 error.

 ' QBX must be started with "QBX /L UITBEFR" to load the UI ToolBox
 ' Quick library

 '$INCLUDE: 'general.bi'
 '$INCLUDE: 'mouse.bi'
 '$INCLUDE: 'menu.bi'
 '$INCLUDE: 'window.bi'
 COMMON SHARED /uitools/ GloMenu           AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()        AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()         AS MenuItemType
 COMMON SHARED /uitools/ GloWindow()       AS windowType
 COMMON SHARED /uitools/ GloButton()       AS buttonType
 COMMON SHARED /uitools/ GloEdit()         AS EditFieldType
 COMMON SHARED /uitools/ GloStorage        AS WindowStorageType
 COMMON SHARED /uitools/ GloWindowStack()  AS INTEGER
 COMMON SHARED /uitools/ GloBuffer$()
 DIM GloTitle(MAXMENU)           AS MenuTitleType
 DIM GloItem(MAXMENU, MAXITEM)   AS MenuItemType
 DIM GloWindow(MAXWINDOW)        AS windowType
 DIM GloButton(MAXBUTTON)        AS buttonType
 DIM GloEdit(MAXEDITFIELD)       AS EditFieldType
 DIM GloWindowStack(MAXWINDOW)   AS INTEGER
 DIM GloBuffer$(MAXWINDOW + 1, 2)
 WindowInit
 WindowDo 0,0
 END


 389. BASIC 7.10 LINK "L4051 Cannot Find Library" If Using 7.00 .LIB

 Product Version(s): 7.10   | 7.10
 Operating System:   MS-DOS | OS/2
 Flags: ENDUSER | SR# S901113-69 LINK.EXE 4051
 Last Modified: 15-JAN-1991    ArticleIdent: Q68158

 If you get the linker warning message "L4051 : BCL70xxx.LIB : cannot
 find library" while linking a program in BASIC PDS version 7.10, the
 problem may be that you are linking to a .LIB library you created with
 BASIC PDS 7.00. This will happen even if BASIC PDS version 7.00 has
 been deleted from your hard disk. If you created your own .LIB library
 in 7.00 and then link it to your BASIC 7.10 module, then you will need
 to recompile the BASIC routines in the .LIB using BASIC version 7.10
 and rebuild the .LIB library (using the LIB.EXE Library Manager).

 The L4051 error can also occur because of an incorrectly set LIB path.
 Type "SET" at the DOS command line to be sure that the LIB environment
 variable points to the BASIC 7.10 libraries. You can set the LIB path
 (automatically at boot time) in your AUTOEXEC.BAT batch file as
 follows:

    SET LIB=C:\BC71\LIB

 This information applies to Microsoft BASIC Professional Development
 System (PDS) version 7.10 for MS-DOS and MS OS/2.

 To duplicate the "L4051 : cannot find library" warning, build a
 library from the following code using BASIC version 7.00:

 'test.bas
 'demo file built with BASIC PDS 7.00
 SUB Pds70sub
 print "this is from the library built with PDS 7.00"
 END SUB

 Compile and build the library as follows in BASIC version 7.00:

    BC /O /Fs test ;
    LIB mylib + test ;        [builds MYLIB.LIB]
    LINK /Q mylib.lib,mylib.qlb,,qbxqlb.lib ;    [links MYLIB.QLB]

 Then create a module to CALL the above SUBprogram Pds70sub from the
 library MYLIB:

 'main.bas
 'This module calls the SUBprogram in a library created with PDS 7.00
 print "this is the calling module"
 call pds70sub

 Compile and link as follows in BASIC version 7.10:

    BC /O /Fs main ;
    LINK main,,,BCL71EFR.LIB + MYLIB.LIB ;

 Now you should receive the warning message:

    LINK : warning L4051 : BCL70EFR.lib : cannot find library
    Enter new file spec:

 To correct the problem, recompile, relink, and rebuild the library
 MYLIB using BASIC PDS version 7.10.


 390. StringAssign of Zero-Length (Null) String Fails; BASIC 7.10

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S901016-16 S_C S_QuickC
 Last Modified: 15-JAN-1991    ArticleIdent: Q68225

 There is no way to use the StringAssign routine to create a
 zero-length string. For example, the following gives unpredictable
 (bad) results, and should not be done:

    StringAssign(NULL,0,basicstring,0)
    // (The NULL pointer is defined in STDIO.H in Microsoft C.)

 This statement is NOT the same as the BASIC statement A$ = "". This
 article explains this limitation of the StringAssign routine, and
 gives the correct method to create a null BASIC string by using
 StringRelease.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 The StringAssign routine lets you transfer far or near string data
 from one language's memory space to another, using the following C
 syntax:

    StringAssign(sourceaddress&,sourcelength%,destaddress&,destlength%)

 StringAssign expects to receive a far pointer (sourceaddress&) either
 to a valid BASIC string descriptor or to the beginning of some string
 text. If the length of the source string (sourcelength%) is 0 (zero),
 StringAssign assumes that sourceaddress& is a pointer to a valid BASIC
 string descriptor. StringAssign then dereferences the descriptor and
 assigns the value to the destaddress& supplied.

 Each programmer is responsible for making sure that the pointer passed
 to StringAssign is valid. StringAssign doesn't validate the pointers.
 Thus, to pass the NULL pointer is an error. If the address passed does
 not point to a string descriptor, then the results will be
 unpredictable.

 Note: Someone might want to do this to set a BASIC variable-length
 string to the empty or null string from some other language. The
 intention is to simulate the following line of BASIC code:

     A$ = ""

 To assign a null string, you can use the StringRelease routine.
 StringRelease isn't exactly the same as A$="", but it does result in a
 string descriptor that will be treated as a null string. It deletes
 the string data associated with the string descriptor and zeros the
 string descriptor. A string descriptor that contains 0 (zero) as the
 length and 0 (zero) as the offset is the same as an uninitialized
 string, which is treated as null. This method should work around the
 limitation of StringAssign described above.

 Code Example
 ------------

 The following is an example of this workaround in Microsoft C and
 BASIC. To compile and link the program, you can use the following
 compile and link lines:

    bc test1.bas /Fs /o /Zi ;
    cl /c /AL /Zi test2.c ;
    link /NOE /NOD /CO test1 test2,,,bcl71efr.LIB llibcer.lib;

 Note that the following program prompts you for input. If you input a
 string, then the C function will StringAssign the string. However, if
 you literally type "null" (with no quotation marks), then the function
 will use StringRelease to null the string.

 Test1.BAS -- BASIC Routine
 --------------------------

 DECLARE SUB cfunc CDECL (a$)
 CLS
 locate 10, 1
 print "Before call to cfunc"
 a$ = "This is a test"
 print "A$ = ", a$
 PRINT "Len A$: "; LEN(a$)
 print
 CALL cfunc(a$)    ' CALL the C function
 print "After call to cfunc"
 print "A$ = ", a$
 PRINT "Len A$: "; LEN(a$)
 print

 Test2.C -- C Routine
 --------------------

 #include <stdio.h>
 #include <stdlib.h>
 extern void far pascal StringAssign(char far *,int,char far *, int);
 extern void far pascal StringRelease(char far *);
 void cfunc(BasicString)
      char far * BasicString;
 {
     char name[80] ;
     char NullStr[] = "";
     printf("Input name[]: ");
     scanf("%s",name);
     if(stricmp(name,"null") == 0) {
       name[0] = '\x00'; // Set it to null
     }
     if ((name == NULL) | (name[0] == '\x00')) {
        StringRelease(BasicString);
     } else {
         StringAssign(name, strlen(name), BasicString,0);
     }
 }


 391. Can't Use LINK Overlays in a BASIC OS/2 Dual-Mode Application

 Product Version(s): 7.00 7.10 | 7.00 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S900920-70
 Last Modified: 29-JAN-1991    ArticleIdent: Q68236

 Dual-mode applications are programs that can run under both OS/2 and
 DOS. You can use the Microsoft BASIC PDS 7.00 or 7.10 to create a
 dual-mode application; however, you cannot use BASIC to create a
 dual-mode application that also uses LINKed overlays for the DOS part
 of the program.

 This information applies to Microsoft BASIC Professional Development
 System 7.00 and 7.10 for MS-DOS and MS OS/2.

 A dual-mode application is not the same as a bound application under
 OS/2. A dual-mode application is actually two programs, one DOS and
 one OS/2, that are "glued" together to form one executable file.

 Every OS/2 program, when linked, has the option to link-in a "stub"
 DOS program. Originally, the stub DOS program was meant to print an
 appropriate message when you attempt to run an OS/2 program under DOS.
 Usually the message is "This program cannot be run in DOS mode," or a
 similar message. You include this stub DOS program by putting the
 following line in the linker .DEF file when you link the OS/2 program
 (where DOSPROG.EXE is the name of your own DOS program):

    STUB 'DOSPROG.EXE'

 Originally, the only purpose of this stub file was to print this
 user-friendly message, and then exit back to DOS. Eventually,
 programmers began to let this "stub" program get larger and larger
 until it became a full-blown application that ran under DOS when you
 attempted to run the OS/2 program in DOS. (The user can't tell the
 difference.) Commercial applications, such as Microsoft Word version
 5.00, were created this way. Because dual-mode applications are
 literally two full applications glued together, they tend to be huge.

 This technique can be used with programs created with the Microsoft
 BASIC PDS product. However, one limitation of dual-mode applications
 is that the DOS portion cannot contain overlays. Attempting to run a
 dual-mode application, where the DOS portion was linked with overlays,
 will hang the machine.

 Illustration
 ------------

 The following compile and link lines create two dual-mode program
 examples, OS2OVL.EXE and OS2NOOVL.EXE. (Source code is not provided
 but you can write it easily). OS2OVL.EXE is an OS/2 program and
 includes a DOS stub program that uses overlays.

 WARNING: Running OS2OVL.EXE will hang your machine, requiring you to
 reboot.

 OS2NOOVL.EXE is an OS/2 program, with an identical DOS version of the
 program enclosed as its stub file. OS2NOOVL.EXE does not use overlays,
 and will run without problem under DOS or OS/2.

 To compile and link the hypothetical programs, use the following
 commands:

 bc dosprog.bas /Lr /o ;
 bc mod1.bas    /Lr /o ;
 bc mod2.bas    /Lr /o ;
 link dosprog mod1 mod2, dosnoovl.exe ;
 link dosprog (mod1) (mod2), dosovl.exe ;
 bc dosprog.bas /Lp /o ;
 bc mod1.bas    /Lp /o ;
 bc mod2.bas    /Lp /o ;
 link os2prog mod1 mod2, os2noovl.exe,,, os2noovl.def ;
 link os2prog mod1 mod2, os2ovl.exe ,,, os2ovl.def ;

 DOSPROG.BAS is a main program that calls subprograms contained in
 separate support modules, MOD1.BAS and MOD2.BAS.

 OS2NOOVL.DEF contains the following line:

    STUB 'DOSNOOVL.EXE'

 OS2OVL.DEF contains the following line:

    STUB 'DOSOVL.EXE'

 (A LINK.EXE .DEF file is a module definition file that BASIC can use
 when linking OS/2 protected-mode programs.)


 392. ISAM Files Cannot Be Opened by Multiple Networked Workstations

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S910107-151 docerr
 Last Modified: 16-JAN-1991    ArticleIdent: Q68339

 The note on page 336 of the "Microsoft BASIC 7.0: Programmer's Guide"
 for Microsoft BASIC PDS 7.00 and 7.10 incorrectly states that you can
 open an ISAM database for read-only by one BASIC process and then have
 another BASIC process open it for reading as well.

 If a database is already open, even if it is opened for read-only
 access, the ISAM engine will generate a "Permission denied" error when
 another process attempts to open the database. If the first process
 closes the file, then the second process can access it.

 This information apples to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS and 7.10 for MS OS/2.

 Note that "processes" refer to two separate programs or users
 attempting to access a file on a network server. However, this can
 also apply to two separate programs under multitasking, systems such
 as OS/2 or Microsoft Windows.

 For an in-depth explanation for why BASIC PDS 7.10 does not yet
 support multiuser ISAM, query on the following:

    why and BASIC and multiuser and ISAM


 393. WIDTH "CONS:" or "SCRN:" Uses Only 40 or 80 in BASIC 7.00/7.10

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901023-92 buglist7.00 buglist7.10 docerr
 Last Modified: 29-JAN-1991    ArticleIdent: Q68446

 In BASIC PDS 7.00 and 7.10, the WIDTH for the screen device is
 restricted to 40 or 80 characters across all the different WIDTH
 syntaxes.

 The WIDTH statement fails to set widths other than 40 or 80 for the
 "CONS:" device name in QuickBASIC 4.50 (buglist4.50) and BASIC PDS
 7.00 and 7.10. The WIDTH statement also fails to set widths other than
 40 or 80 for the "SCRN:" device name for BASIC PDS 7.00 and 7.10, but
 succeeds in QuickBASIC 4.50. (The problem occurs both in the
 environment and in a compiled .EXE program.) The documentation does
 not explicitly say what is expected for the WIDTH dev$,wid% syntax.

 This may be a design restriction. Microsoft is researching this
 problem and will post new information here as it becomes available.

 This information applies to QuickBASIC version 4.50 and to Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS.

 BASIC PDS 7.00 and 7.10 only lets you use WIDTH of 40 or 80 for the
 WIDTH dev$,wid% syntax when dev$ is the screen device name "CONS:" or
 "SCRN:". (This behavior actually matches the documented restriction
 for the separate WIDTH wid%,height% syntax for screen output.)

 The following code example demonstrates this behavior:

 Code Example
 ------------

 CLS
 WIDTH "scrn:", 11   ' Sets screen width to 11 characters.
 OPEN "scrn:" FOR OUTPUT AS #1                ' OK in 4.50, but
 PRINT #1, "123456789012345678901234567890"   ' WIDTH ignored in BASIC
 CLOSE                                        ' 7.x in .EXE and QBX.EXE
 OPEN "scrn:" FOR OUTPUT AS #2
 WIDTH #2, 11                                 ' OK in 4.50, but WIDTH
 PRINT #2, "123456789012345678901234567890"   ' ignored in BASIC 7.x
 CLOSE
 WIDTH "cons:", 11
 OPEN "cons:" FOR OUTPUT AS #3
 PRINT #3, "123456789012345678901234567890"  ' WIDTH ignored, 7.x, 4.50
 CLOSE
 OPEN "cons:" FOR OUTPUT AS #4
 WIDTH #4, 10
 PRINT #4, "123456789012345678901234567890"  ' WIDTH ignored, 7.x, 4.50
 CLOSE

 ' Note that the problem doesn't occur with the "LPT1:" device:
 WIDTH "lpt1:", 11   ' Sets printer width to 11 characters.
 OPEN "lpt1:" FOR OUTPUT AS #1
 PRINT #1, "123456789012345678901234567890"  ' Works find in all versions.
 CLOSE

 Reference:

 The following partial description of the WIDTH statement is taken from
 the QBX.EXE online help:

    WIDTH {#filenumber% | device$}, width%

 WIDTH {#filenumber% | device$}, width%
   The WIDTH #filenumber%, width% form:
     - Sets the line width of an output device already opened as a file
       (for example, LPT1: or CONS:).
     - The argument filenumber% is the number associated with the
       file in the OPEN statement.
     - The "#" character in front of filenumber% is not optional.
     - The width assignment takes place immediately.
   The WIDTH device$, width% form:
     - Sets to width% the line with of device$ (a device filename).
       The device should be a string expression (for example, "LPT1:").
     - The width assignment is deferred until the next OPEN statement
       affecting the device.
     - The assignment does not affect output for an already open file.


 394. ISAM Files Open at Once, "Too Many Files" Error 67, Correction

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | docerr
 Last Modified: 29-JAN-1991    ArticleIdent: Q68462

 Page 673 of the "Microsoft BASIC 7.0: Language Reference" (under the
 "Too many files" error in Appendix D) incorrectly states that ISAM is
 limited to opening 12 databases at once.

 This should be corrected to read as follows:

    At run time, the "Too many files" error may occur because:

    ISAM has a limit to the number of databases and tables that can be
    open at one time and your program has exceeded this limit.
    The maximum number of database files that you can have open at once
    is four. Also, the maximum number of tables that you can have
    open at once is 13 tables in one database file, or 10 tables in 2
    database files, or 7 tables in 3 database files, or 4 tables in 4
    database files.

 This information applies to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS and 7.10 for MS OS/2.

 Reference:

 An ISAM database file in Microsoft BASIC Professional Development
 System (PDS) version 7.00 or 7.10 is created with the default
 extension .MDB and contains the physical data for each table plus the
 indexes used to define and point to the data.

 (This correct ISAM information is taken from page 388 of the
 "Microsoft BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10
 [Chapter 10, "Database Programming with ISAM"].)


 395. OutGText% Works Only on First Call If WINDOW Invoked; UI Font

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910114-77
 Last Modified: 29-JAN-1991    ArticleIdent: Q68588

 Using the OutGText% function more than once does not display the text
 in the same location if you have invoked the SCREEN command prior to
 invoking OutGText%. GTextWindow must be called before any OutGText%
 commands.

 This information applies to the User Interface (UI) Toolbox Font
 procedures in Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS. (See GTextWindow in the README.DOC
 file.)

 The procedure OutGText% initializes the screen to its full-screen
 parameters before displaying the user's text. To reinitialize the
 screen back to its original user-specified parameters, GTextWindow
 must have been called. GTextWindow stores the screen coordinates for
 later use (for example, in the OutGText% function).

 Because the WINDOW statement uses the same parameters as GTextWindow,
 you may want to include the command WINDOW(X1,Y1,X2,Y2) in the
 GTextWindow procedure, and substitute the GTextWindow call whenever
 referencing the WINDOW statement.

 Code Example
 ------------

 The code below demonstrates the correct method to display the text
 "Hello world" in the location (0,100). If GTextWindow is not called,
 "Hello world" will be displayed twice in two different locations.

 SCREEN 9
 FontNum% = RegisterFonts("TMSRB.FON")
 var1% = LoadFont%("N4,N5,N6")
 a$ = "Hello world"
 CALL GTextWindow(-200, -200, 200, 200, FALSE)   'store coordinates
 WINDOW (-200, -200)-(200, 200)
 PSET (0, 100)
 var1% = OutGText%(0, 100, a$)
 var1% = OutGText%(0, 100, a$)
 PSET (0, 100)
 END

 Reference
 ---------

 According to the README.DOC file for BASIC PDS 7.00 and 7.10, after
 the first call to OutGText to output text, you must precede each
 subsequent call to OutGText with a call to GTextWindow in order to
 preserve logical coordinates of the window.


 396. How to Display Mouse Pointer on Multiple Pages, in UI Toolbox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910111-277 B_QuickBas H_Mouse
 Last Modified: 29-JAN-1991    ArticleIdent: Q68589

 The User Interface (UI) Toolbox demonstration programs supplied with
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 are not written to accomodate mouse support on video pages
 other than page 0 (zero). If you change the SCREEN statement to use
 any video page other than page 0, the mouse cursor (pointer) will not
 be visible. To make the mouse cursor visible, you must call DOS
 interrupt 33 hex.

 Note that you may also use interrupt 33 hex with QuickBASIC version
 4.00, 4.00b, and 4.50 to show the mouse cursor on desired video pages.

 DOS function 33 hex, with function 1D hex, selects the display page
 for the mouse pointer. Before calling this DOS service, you must load
 the AX register with 1D hexadecimal, and the BX register with the
 desired page number. This page number coincides with the second
 argument to BASIC's SCREEN statement.

 Code Example
 ------------

 Combine (load into QBX.EXE) the following main-module code and
 subprogram along with the MOUSE.BAS source file provided with BASIC
 PDS 7.00 and 7.10.

 '$INCLUDE: 'qbx.bi'
 DIM SHARED Regs as Regtype
 MouseShow
 SelectPage(9,0,0)
 SLEEP
 SelectPage(9,1,0)
 END
 SUB SelectPage(Mode%, Page%, Visible%)
    Regs.AX = &H1D
    Regs.BX = 0
    Interrupt &H33, Regs, Regs
 END SUB


 397. "Symbol Defined More Than Once" LINKing BASIC 7.10/FORTRAN 5.0

 Product Version(s): 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910111-256 H_FORTRAN
 Last Modified: 29-JAN-1991    ArticleIdent: Q68590

 Below is an example where linking BASIC PDS 7.10 with FORTRAN 5.00
 gives several "Symbol defined more than once" errors. In this specific
 case, the problem can be worked around by compiling with BC /O (the
 stand-alone .EXE option, using BCL71ENR.LIB).

 =======================================================================

 IMPORTANT NOTE: Linking Microsoft BASIC Professional Development
 System (PDS) 7.10 with Microsoft FORTRAN 5.00 requires first changing
 the FORTRAN library and including a Microsoft C 6.00 library, as
 explained in a separate application note, "How to Link BASIC PDS 7.10
 with C 5.10, FORTRAN 5.00, or Pascal 4.00." To find this application
 note in a separate article in this knowledge base, search for the
 words shown in the title of the application note, or BB0345. Despite
 using the steps in the application note, linking certain BASIC 7.10
 and FORTRAN 5.00 programs may generate the "Symbol defined more than
 once" errors described in the example below.

 Although the methods in the application note have been designed to
 produce compatible results, we have not put the methods through a
 standard Microsoft mixed-language testing cycle, and it is possible
 that you may still encounter compatibility problems under certain
 conditions. We cannot guarantee the complete success of mixed-
 language programming of BASIC PDS 7.10 with C 5.10, FORTRAN 5.00, or
 Pascal 4.00. Further problems or questions can be directed to
 Microsoft Language Support Services.

 =======================================================================

 To duplicate the problem, create the following code:

 BASIC.BAS
 ---------

 REM *********************BASIC CODE*****************************
 DIM x%(2048)
 COMMON SHARED /nmalloc/ x%()
 DECLARE SUB Test()
 CALL Test
 END

 FORTRAN.FOR
 -----------

 C  *********************FORTRAN CODE***************************
       SUBROUTINE Test
       REAL frq(1)
       WRITE(6,*)wreal
       i=INT(frq(i))
       RETURN
       END

 Compile and link with the following commands:

    (Note: To create MIXED.LIB, you must obtain the application note
    "How to Link BASIC PDS 7.10 with C 5.10, FORTRAN 5.00, or Pascal
    4.00.")

  BC /E /FPi /Zi basic.bas;
  fl /c /4Yb /FPi /Zi fortran.for
  link /NOD/NOE/CO basic.obj + fortran.obj,s.exe,,brt71enr.lib+
                    llibcer.lib+mixed.lib;

 LINK.EXE generates the following errors:

 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __flds : symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fsts : symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fadds: symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fdivs: symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fsubs: symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fmuls: symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fstsp: symbol defined
 more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fdivsr: symbol
 defined more than once.
 mixed.lib(\mrt\c\87ccallf.asm) : error L2025: __fsubsr: symbol
 defined more than once.

 To work around this problem, add /O to the BASIC compiler command line
 and then relink, as follows:

    BC /O /E /FPi /Zi basic.bas;
    link /NOD/NOE/CO basic.obj + fortran.obj,s.exe,,BCL71ENR.LIB+
                    llibcer.lib+mixed.lib;


 398. "Illegal Function Call" Selecting Menu Item Using UI Toolbox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S901120-94
 Last Modified: 14-FEB-1991    ArticleIdent: Q69109

 An "Illegal function call" error can occur when you select an item
 from a user-defined menu with the ALT+Key1+Key2 combination, even
 though selecting the same item with the mouse does not give an error.
 This error can be caused by using an incorrect parameter in the
 MenuSet procedure. The fifth argument of the MenuSet SUB is
 accesskey%. If zero is passed as the fifth parameter, then that menu
 item and any after it will generate an error when selected with key
 combinations. This error does not occur if you use the mouse. This
 article shows why this error occurs, and gives a workaround for this
 problem.

 This information applies to the User Interface (UI) Toolbox in
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS.

 The MenuSet SUB is described on pages 545 and 546 of the "Microsoft
 BASIC 7.0: Programmer's Guide" for versions 7.00 and 7.10.

 The accesskey% argument specifies the position of the character within
 the menu item text that is used in conjunction with the ALT key to
 select that item. You may want accesskey% to be zero if you don't want
 the item to be selected. If you don't want the item to be selected,
 pass a zero as the third parameter (the State% argument).

 Code Example
 ------------

 The following code example demonstrates the "Illegal function call"
 error. In this case, a zero is passed as the fifth parameter of
 MenuSet because the text is just a horizontal line across the menu.

 To run this example, save the code as <filename>.BAS, then invoke
 QBX.EXE with the following command:

 QBX <filename> /L UITBEFR

 ' UIERROR.BAS
 DEFINT A-Z
 '$DYNAMIC
 '$INCLUDE: 'GENERAL.BI'
 '$INCLUDE: 'MENU.BI'
 '$INCLUDE: 'MOUSE.BI'
 '$INCLUDE: 'WINDOW.BI'

 'These global variables are required by the UI Toolbox routines:
 COMMON SHARED /uitools/ GloMenu         AS MenuMiscType
 COMMON SHARED /uitools/ GloTitle()      AS MenuTitleType
 COMMON SHARED /uitools/ GloItem()       AS MenuItemType

 '******************************************************************
 'MAXMENU and MAXITEM are constants defined in *.BI above.
 'The TYPEs MenuTitleType and MenuItemType are also defined
 'in the *.BI files above.
 '******************************************************************
 DIM GloTitle(MaxMenu)         AS MenuTitleType
 DIM GloItem(MaxMenu, MaxItem) AS MenuItemType
 COLOR 2, 1
 CLS
 MenuInit
 COLOR 15, 1                       'Sets the background to blue
 MenuSet 1, 0, 1, "Salutation", 1  'Menu title
 MenuSet 1, 1, 1, "Hello", 1       'First item under Salutation
 MenuSet 1, 2, 1, "-", 0           'Line across the menu
 MenuSet 1, 3, 1, "Goodbye", 1     'Last item under Salutation
 MenuPreProcess
 MenuShow
 MouseShow
 ProgramFinished = False
 WHILE NOT ProgramFinished
   kbd$ = MenuInkey$
   WHILE MenuCheck(2)
     GOSUB MenuTrap
   WEND
 WEND
 MouseHide
 END

 MenuTrap:
   Menu = MenuCheck(0)
   item = MenuCheck(1)
   COLOR 2, 1
   SELECT CASE Menu
     CASE 1
       SELECT CASE item
         CASE 1                        'If hello was selected then
           LOCATE 12, 37               'print hello.
           PRINT "Hello"
         CASE 3                        'If goodbye was selected then
           LOCATE 13, 36               'print goodbye and end.
           PRINT "GoodBye"
           ProgramFinished = True
         CASE ELSE
           ProgramFinished = False
       END SELECT
     CASE ELSE
       ProgramFinished = False
   END SELECT
   RETURN

 Workaround
 ----------

 This problem can be solved by either not passing a zero as the fifth
 parameter in MenuSet or by changing a few lines of code in the
 MENU.BAS program. The problem lies in the MENU.BAS program in the
 MenuDo SUB. There is a DO LOOP shortly after the following comment:

 '==================================================================
 'If menu is selected, search items for matching access key, and
 'select that (menu,item) and exit MenuDo if item is enabled
 '==================================================================

 The LOOP statement reads:

 LOOP UNTIL UCASE$(MID$(GloItem(currMenu, newItem).text,_
 GloItem(currMenu, newItem.accesskey,1)) = kbd$ AND GloItem(currMenu,_
 newItem).state > 0 AND RTRIM$(GloItem(currMenu, newItem).text) <>_
 "-") OR newItem = loopEnd

 Note: The above is one line of code in MENU.BAS. The underscore (_)
 characters indicate line continuation.

 If zero was passed as the fifth parameter in MenuSet, then
 GloItem(currMenu, newItem).accesskey = 0 when the loop reaches that
 menu item. This condition causes an "illegal function call" in the
 MID$ function. Adding the following IF statement to the loop will
 solve the problem:

 DO
   newItem = (newItem) MOD MAXITEM + 1
   IF GloItem(currMenu, newItem).accesskey = 0 THEN
     LoopDone% = (newItem = loopEnd)
   ELSE
     LoopDone% = UCASE$(MID$(GloItem(currMenu, newItem).text,_
     GloItem(currMenu, newItem.accesskey,1)) = kbd$ AND_
     GloItem(currMenu, newItem).state > 0 AND RTRIM$(GloItem(currMenu,_
     newItem).text) <> "-") OR newItem = loopEnd
   END IF
 LOOP UNTIL LoopDone%

 To include these changes in the files UITBEFR.LIB and UITBEFR.QLB, do
 the following:

 1. At the DOS prompt, type:

       QBX MENU

 2. Make the changes in the DO LOOP as stated above.

 3. Save the new MENU.BAS.

 4. Exit QBX.EXE.

 5. At the DOS prompt, type:

       BC MENU /X/Fs;

 6. Type:

       LIB UITBEFR - MENU.OBJ + MENU.OBJ

 7. Type:

       LINK /Q UITBEFR.LIB, UITBEFR.QLB,, QBXQLB.LIB;


 399. Correction for Scroll SUB in GENERAL.BAS, UI Toolbox

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910115-118 buglist7.00 buglist7.10
 Last Modified: 14-FEB-1991    ArticleIdent: Q69111

 The subprogram Scroll within GENERAL.BAS will not display the correct
 attributes if you select a negative number for "lines" when you want
 to scroll the window down. A correction for this problem is shown
 below. (Scrolling in the up direction displays the correct attributes,
 and needs no correction.)

 This correction applies to the User Interface (UI) Toolbox in
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS.

 The DOS Interrupt call 16 hex with function 7 or 6 requires that the
 BX register be set with the color attribute. The bits 6 through 4 are
 set to the desired background attribute. The following formula shifts
 this attribute into the correct location in the word register BX:

    regs.bx = 256 * (attr MOD 8) * 16

 The original code for subprogram Scroll has the following attributes
 set for the BX register:

    regs.bx = 256 * attr

 The following excerpt is from Scroll with the correct modifications:

 SUB Scroll (row1, col1, row2, col2, lines, attr)
           .
           .
           .
      MAXCOL THEN
         DIM regs AS RegType
         IF lines < 0 THEN
             regs.ax = 256 * 7 + (-lines)
            'regs.bx = 256 * attr                 <=== old code
             regs.bx = 256 * (attr MOD 8) * 16   '<=== change to this
             regs.cx = 256 * (row1 - 1) + (col1 - 1)
             regs.dx = 256 * (row2 - 1) + (col2 - 1)
         ELSE
             regs.ax = 256 * 6 + lines                  'AH = 06
             regs.bx = 256 * (attr MOD 8) * 16
             regs.cx = 256 * (row1 - 1) + (col1 - 1)
             regs.dx = 256 * (row2 - 1) + (col2 - 1)
         END IF
         INTERRUPT 16, regs, regs
     END IF
 END SUB


 400. How to Estimate Size of BASIC PDS ISAM Database Components

 Product Version(s): 7.00 7.10 | 7.10
 Operating System:   MS-DOS    | OS/2
 Flags: ENDUSER | SR# S910114-194
 Last Modified: 14-FEB-1991    ArticleIdent: Q69112

 Using the output of ISAMPACK.EXE can give you a rough estimate of the
 size of an ISAM database.

 This information applies to Microsoft BASIC Professional System (PDS)
 versions 7.00 and 7.10 for MS-DOS and 7.10 for OS/2.

 Because an ISAM file contains descriptive information, it has some
 size overhead. This overhead is required for the speed and efficiency
 that ISAM files possess compared to random access files. With this
 overhead, data manipulation, such as searches, seeks, and sorts,
 becomes extremely easy. The ISAM engine is responsible for all this
 data manipulation, which allows you to spend your time developing the
 code, and frees you from worrying about the fine details of the
 database management.

 You can use the output of the ISAMPACK.EXE utility to roughly guess
 the size of the components of an ISAM database.

 The ISAM database is divided into several components, which have the
 following size requirements:

 1. A database requires a header of 3K for its own use.
 2. The system data dictionary requires 39K.
 3. Each table requires 4K of overhead beyond the data space.
 4. Each index is allocated in 2K chunks.
 5. Actual data is allocated in 2K increments.

 Additionally, to optimize speed and flexibility, the file will grow in
 large increments of 32K, rather than in record-size increments as
 single records are added. For this same reason, the indexes and data
 are allocated in 2K chunks. Although the files are quite large
 compared to random access files, the ISAM file has room for growth and
 can be extremely fast. This can be a hurdle for some programmers, and
 is an important consideration when designing a program. Please read
 "ISAM Components/When to Use ISAM" on page 329 of the "Microsoft BASIC
 7.0: Programmer's Guide" (for 7.00 and 7.10) to determine which is
 more appropriate for your needs, ISAM files or random access files.

 The following tables were constructed using the sample database
 AMAZRAYS.MDB and the output from ISAMPACK.EXE.

 To run ISAMPACK.EXE, first invoke the PROISAMD.EXE TSR (terminate and
 stay resident) program, then use the following arguments for
 ISAMPACK.EXE:

    ISAMPACK AMAZRAYS.MDB AMAZRAYS.RPT

 More information on ISAMPACK.EXE can be found on page 394 of the
 "Microsoft BASIC 7.0: Programmer's Guide."

 Header
 ------

  * Each database requires a 3K header.                           3K

 Data Dictionary
 ---------------

  * Five system tables and eight system indexes.                  39K

 Tables Overhead
 ---------------

  * Each table has 4K of overhead beyond its actual data records.

       CustTable
       InventTable
       InvoiceTable
       TransTable          4 * 4K =                               16K

 Indexes
 -------

  * Each index is allocated in 2K chunks:

    IndexName      Columns        Size   NumRecords  Size   Actual
    ---------      -------        ----   ----------  ----   ------

    AcctIndex      AcctNo(5)        5      7           35    2K

    CompanyIndex   Company(70)
                   AcctNo(5)       75      7          525    2K

    ItemIndex      ItemNo(5)        5      8           40    2K

    InvoiceIndex   InvoiceNo(6)     6     24          144    2K

    DateIndex      Date(6)
                   InvoiceNo(6)    12     24          288    2K

    InvAcctIndex   AcctNo(6)
                   Date(6)
                   InvoiceNo(6)    36     24          864    2K

    TransInvIndex  InvoiceNo(6)
                   TransNo(2)      12     46          552    2K

                                        Total Index Space...    14K

 Database
 --------

  * Each database is allocated in 2K chunks.

    Table        b/rec    #rec     Calc(K)  Act(K)
    -----        -----    ----     -------  ------

    CustTable     326        7     2.282       4
    InventTable   163        8     1.304       2
    InvoiceTable   33       24     0.792       2
    TransTable     23       46     1.058       2
                                                    Total...    10K

 Database Size
 =============

  * Growth is in 32K chunks.

                                   Grand total(82K)....   83,968 bytes
    Adjusted for 32K chunk (3 * 32K * 1024 bytes/K)....   98,304 bytes
            Actual file reported after packing file....   98,304 bytes


 401. ISAMCVT Doesn't Properly Convert db/LIB Date Fields

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910116-88 buglist7.00 buglist7.10
 Last Modified: 11-FEB-1991    ArticleIdent: Q69158

 Page 393 of the "Microsoft BASIC 7.0: Programmer's Guide" (for
 versions 7.00 and 7.10) states that the ISAMCVT utility will convert
 db/LIB date fields to BASIC double-precision numbers for use with the
 Date/Time add-on libraries.

 ISAMCVT does convert a date field to a double-precision number, but
 the resulting number is not a serial number that can be used with the
 date libraries included with BASIC.

 Microsoft has confirmed this to be a problem with the ISAMCVT.EXE
 utility for Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS. We are researching this problem and
 will post new information here as it becomes available.

 When ISAMCVT converts a date field, it converts it to a 8-byte string,
 but tags it internally as a double. To see the string, you must use
 the MKD$ function to convert the double to a string.

 However, ISAMCVT also converts the year portion of the date
 incorrectly by dropping the last two digits (for example, 1990 becomes
 19, and 1890 becomes 18.)

 For example, if you have a db/LIB file ("test.dbf") containing
 three fields and one record

    NUMERIC (length=4, # decimals=1)   = 1.2
    CHARACTER (length = 50)            = My Name
    DATE                               = 19901214

 and then you converted it using

    ISAMCVT /D test.dbf table test.mdb

 the program below will then show that the ISAM file contains the
 following:

     CustNum = 1.2
     Name    = My Name
     Date    = 12/14/19

 Code Sample
 -----------

 Note: PROISAM.EXE must be loaded before running this program inside of
 QBX.EXE.

 TYPE rectype
     CustNum AS DOUBLE
     Name AS STRING * 50
     Date AS DOUBLE
 END TYPE
 DIM a AS rectype
 OPEN "test.mdb" FOR ISAM rectype "table" AS #1
 SETINDEX #1, ""
 MOVEFIRST #1
 RETRIEVE #1, a
 PRINT a.CustNum
 PRINT a.Name
 PRINT MKD$(a.Date)
 CLOSE #1


 402. Example of How to Call BASIC SetUEvent from C; ON UEVENT GOSUB

 Product Version(s): 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S910107-180 B_QUICKBAS S_C
 Last Modified: 14-FEB-1991    ArticleIdent: Q69159

 Page 310 of the "Microsoft BASIC 7.0: Programmer's Guide" states:

    Trapping a user-defined event involves writing a non-BASIC
    routine, such as in Microsoft Macro Assembler (MASM) or C, ....

 On the same page, this statement is followed by an example of how to
 set up the ON UEVENT GOSUB routine in assembly language.

 This article shows how the same example can be written in the
 Microsoft C language.

 The code example below applies to Microsoft QuickBASIC versions 4.00b
 and 4.50, to Microsoft BASIC Compiler versions 6.00 and 6.00b, and to
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10 for MS-DOS.

 Compile the C program below with:

    CL -Od -AM -c uevent.c

 Compile the BASIC program below with:

    BC /O/V BASIC.BAS;

 Link the programs together with:

    LINK /NOE BASIC+UEVENT, UEVENT.EXE;

 When the program is executed, the line "Arrived here after 4.5
 seconds" will print every 4.5 seconds.

 Note: The C program must be compiled with the medium memory model
 because the DS register must point to BASIC's DGROUP space when
 SetUevent is called.

 BASIC Code Example, BASIC.BAS
 -----------------------------

 DECLARE SUB SetInt
 DECLARE SUB RestInt
 ' Install new interrupt service routine:
 CALL SetInt
 ' Set up the BASIC event handler:
 ON UEVENT GOSUB SpecialTask
 UEVENT ON

 DO
 ' Normal program operation occurs here.
 ' Program ends when any key is pressed.
 LOOP UNTIL INKEY$ <> ""

 ' Restore old interrupt service routine before quitting:
 CALL RestInt
 END

 ' Program branches here every 4.5 seconds:
 SpecialTask:
 ' Code for special task goes here, for example:
 PRINT "Arrived here after 4.5 seconds"
 RETURN

 C Code Example, UEVENT.C
 ------------------------

 #include <dos.h>
 void (_interrupt _far *OldInt) (void);    // The old interrupt vector.
 void _interrupt _far EventHandler (void);       // The UEVENT handler.
 char TimerTicks = 0;                      // Number of ticks elapsed.

 void pascal SetInt()                      // Set up the interrupts
 {                                         //   to point to the UEVENT
     OldInt = _dos_getvect(0x1C);          //    handler.
     _dos_setvect(0x1C, EventHandler);
 }

 void interrupt EventHandler()            // This is the UEVENT handler.
 {
     extern pascal SetUevent();
     if (++TimerTicks > 82)               // Check to see if 4.5 secs
       {                                  //    has elapsed (18.2
         TimerTicks = 0;                  //    ticks = 1 sec).
         SetUevent();
       }
     _chain_intr(OldInt);                // Continue through old
 }                                       //    interrupt routine.

 void pascal RestInt()                   // Restore old interrupt
 {                                       //    when done to avoid
     _dos_setvect(0x1C, OldInt);         //    conflicts after exit.
 }


 403. "Subscript Out of Range," Graphics GET with LONG Integer

 Product Version(s): 6.00 6.00b 7.00 7.10 | 6.00 6.00b 7.00 7.10
 Operating System:   MS-DOS               | OS/2
 Flags: ENDUSER | b_quickbas buglist6.00 buglist6.00b buglist7.00 buglist7.10
 Last Modified: 14-FEB-1991    ArticleIdent: Q69160

 If the graphics GET statement is used in a subprogram with a LONG
 integer array and if the starting index of the array is not the first
 element, a "Subscript out of Range" error will be generated if the
 program is compiled with BC /D. If the program is compiled without the
 /D option, BC.EXE will give an "Illegal function call" error.

 This problem does not occur in the QBX.EXE or QB.EXE environment.

 Microsoft has confirmed this to be a problem with Microsoft QuickBASIC
 versions 4.00, 4.00b, and 4.50 for MS-DOS; Microsoft BASIC compiler
 versions 6.00 and 6.00b for MS-DOS and MS OS/2; and Microsoft BASIC
 Professional Development System (PDS) versions 7.00 and 7.10 for
 MS-DOS and MS OS/2. We are researching this problem and will post new
 information here as it becomes available.

 The program below demonstrates the problem. Compile and link as
 follows:

    BC /D SAMPLE;
    LINK SAMPLE;

 When the program is run, it will draw a circle and then print
 "Subscript out of Range in line 7 of module SAMPLE."

 To work around this problem, either place the array in COMMON SHARED
 or use a local array instead of one that is passed as a parameter. It
 is also possible to uses SINGLE precision numbers instead of LONG
 integers.

 Code Sample: SAMPLE.BAS
 -----------------------

 DECLARE SUB test (array() AS LONG)
 1 DIM array(1000) AS LONG
 2 SCREEN 1
 3 CIRCLE (50, 50), 50
 4 CALL test(array())
 5 CLS
 6 PUT (100, 100), array(4)

 SUB test (array() AS LONG)
 7  GET (50, 50)-(100, 100), array(4)
 END SUB


 404. ISAMCVT Btrieve Specfiles Cannot Have Spaces; Must Use Commas

 Product Version(s): 7.00 7.10
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr SR# S910205-152
 Last Modified: 14-FEB-1991    ArticleIdent: Q69343

 Page 392 of the "Microsoft BASIC 7.0: Programmer's Guide" (for BASIC
 PDS 7.00 and 7.10) gives an incorrect example of a Btrieve specfile.
 The fields of each entry are incorrectly shown separated by spaces;
 instead, the fields should be separated by commas.

 ISAMCVT specfiles must not contain spaces.

 This information applies to Microsoft BASIC PDS versions 7.00 and 7.10
 for MS-DOS.

 The specfile on page 392 should be changed to the following:

    string,4,StringCol
    integer,2,IntColumn
    Long,10,LongColumn
    Double,5,DoubleCol

 If ISAMCVT is run with this specfile and an appropriate Btrieve file,
 the Btrieve file will be successfully converted. Note that the
 specfile must specify the format for every column in the Btrieve file
 (for both indexes and non-indexes).

 Page 392 gives the following incorrect example of a Btrieve specfile:

    string 4 StringCol
    integer 2 IntColumn
    Long 10 LongColumn
    Double 5 DoubleCol

 ISAMCVT gives the following error message when using the above
 specfile:

    ISAMCVT: Invalid data type 'string 4 StringCol
    ' in line 1 of <specfilename>.

 ISAMCVT does not allow spaces as field separators. It is also illegal
 to mix commas and spaces as in the next example:

    string, 4, StringCol
    integer, 2, IntColumn
    Long, 10, LongColumn
    Double, 5, DoubleCol

 ISAMCVT gives the following error message when using the above
 specfile:

    ISAMCVT: Missing or invalid column name in line 1 of <specfilename>

 The fields of an ISAMCVT specfile must be separated by commas and no
 spaces should be in the file.






 Microsoft QuickBASIC
 =============================================================================


 1. Getting the DTA Address Using INT86

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 28-DEC-1989    ArticleIdent: Q11785

 Problem:

 I would like to search for files with a given extension, save them in
 an array, and display them on the screen for user selection using
 QuickBASIC Version 2.00 and the DOS interrupt routine INT86. I have
 written a sample program that calls function 4E and 4F to find the
 desired files. They appear to be working correctly, as the flag
 returned in the low byte of register AX is showing 0 for each
 successful find and 18 when no files exist or when the last file has
 been found. However, I do not know how to read the DTA (Disk Transfer
 Address) after I successfully find a file, thus I cannot store the
 filename for later display.

 Response:

 In QuickBASIC Versions 2.00, 2.01, and 3.00, you can perform DOS
 Interrupts by calling the external routine INT86. In QuickBASIC
 Versions 4.00, 4.00b, and 4.50, you can call the external routines
 INT86OLD INT86XOLD INTERRUPT and INTERRUPTX.

 It is difficult to find the current DTA of a program (and its offset
 is subject to change without notice); therefore, it is better to ask
 DOS (via INT 21, function Hex 1A "Set DTA") to reassign the DTA to a
 location over which you have control. For the application indicated,
 you should try the following:

 1. Issue the DOS function call to change the DTA address (INT 21,
    function Hex 1A) to an address of a structure in your code space
    (this way you will know where to find it).

 2. Perform your "Find first" (INT 21, function Hex 4E).

 3. Perform your loop of "Continue file search" (INT 21, function Hex
    4F).

 Within your loop you may check your variables in the structure as
 desired. The "Microsoft MS-DOS Programmer's Reference" manual includes
 an example of how to set up the structure for the DTA in assembler.

 The book "Advanced MS-DOS," by Ray Duncan (Microsoft Press, 1986) also
 is a very helpful reference for using DOS function calls.


 2. "Illegal Number" Using -2147483648& in Long Integer Notation

 Product Version(s): 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S890824-44 B_BasicCom
 Last Modified: 20-DEC-1989    ArticleIdent: Q48725

 BC.EXE, QB.EXE, and QBX.EXE do not allow the "&" character on the end
 of the smallest (negative) constant allowed for a long integer,
 -2147483648. To enter the smallest long integer constant in your
 source code, you must use either (-2147483647& - 1&) or -2147483648#.

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50 for MS-DOS, to Microsoft BASIC Compiler Versions 6.00 and
 6.00b for MS-DOS and MS OS/2, and to Microsoft BASIC PDS Version 7.00
 for MS-DOS and MS OS/2.

 The BC.EXE compiler reports an "Illegal type character in numeric
 constant" error, and the QB.EXE and QBX.EXE editors report an "Illegal
 number" error for the following statement:

    A& = -2147483648&

 The error may have surprised you since -2147483648& is within the
 allowed range for long integers (-2147483648& to [phone]&).

 However, this is not a software problem. Both the BASIC compiler and
 the QB and QBX interpreters parse -2147483648& as follows:

    - (2147483648&)

 In other words, "take a large long integer and negate it." This means
 that the number is first parsed as a positive long integer and then it
 is negated before it is assigned to the number. However, the largest
 positive long integer is 2147483647 (one fewer than the largest
 negative number), making 2147483648& an illegal number, and therefore,
 causing an error.

 You must use one of the following instead:

    A& = (-2147483647& - 1&)
 or
    A& = -2147483648#


 3. Printing Delayed when DOS PRINT Command Invoked from SHELL

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified:  7-FEB-1989    ArticleIdent: Q28208

 If you invoke the DOS Print utility during a SHELL, the printer output
 does not print until you exit QuickBASIC. This problem occurs because
 DOS Print is a terminate-and-stay-resident (TSR) program.

 Note: You should never install a TSR program, such as DOS Print, with
 the SHELL statement because it fragments memory. This can result in
 the following error messages: "Out of Memory" and "Program Too Large
 to Fit in Memory". You must reboot to eliminate the memory
 fragmentation.

 If you must SHELL to a TSR program, it must have been installed in
 memory before running the QuickBASIC program. Note: Many TSR programs
 may conflict with QuickBASIC with other symptoms, and may not be
 compatible.

 We do not recommended you use DOS Print, or any TSR program, with
 QuickBASIC. Due to a memory conflict, the printing will be delayed
 when the DOS Print is invoked during the execution of a SHELL command.

 In the first example below, printing occurs immediately because the
 Print is invoked (i.e., loaded into memory) prior to the running of
 QuickBASIC. In this case, Print takes a portion of memory for its
 buffer, QuickBASIC loads, the SHELL executes, and the previously
 allocated buffer is used.

 If DOS Print is initially invoked by the SHELL statement itself, then
 printing does not occur until after exiting QuickBASIC. In this case
 QuickBASIC loads, the SHELL executes, Print tries to set up the buffer
 but does not have enough room so it spools. Once memory is freed up,
 either after exiting QuickBASIC or after the SHELL is executed, a
 print buffer can be allocated and the DOS Print is executed. Similar
 limitations occur in earlier versions of the QuickBASIC compiler.

 Below is the first example. DOS Print is loaded prior to running
 QuickBASIC, and no delayed printing occurs in the following example:

 1. Invoke DOS Print utility. Resident portion of Print gets loaded
    into memory.

 2. Invoke the QuickBASIC editor (QB.EXE).

 3. Run the following program:

              CLS
              Shell "print filename"
              End

 Below is the second example. DOS Print is loaded by the SHELL
 statement itself, and printing is delayed until after leaving
 QuickBASIC, and memory is fragmented in the following example:

 1. Reboot.

 2. Invoke the QuickBASIC editor (QB.EXE).

 3. Run the program above. Print loads resident portion.


 4. Negative Array Subscripts Checked with Debug, /D

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 28-DEC-1989    ArticleIdent: Q11880

 Question:

 I have two questions on subscripts in QuickBASIC, as follows:

 1. What is supposed to happen when I use negative array subscripts in
    QuickBASIC?

 2. Does QuickBASIC check the validity of subscripts?

 Response:

 The following are responses to your questions:

 1. Negative subscripts are not supported in Versions 3.00 and earlier,
    so when you use negative subscripts, the results are unpredictable.
    Versions 4.00 and later support the "TO" optional syntax, which allows
    for subscripts in the range of -32768 to 32767. However, invalid
    subscripts, such as negative values in Versions 3.00 and later, and
    subscripts out of range in all versions, are not checked for unless
    you have compiled with /D.

    For example, compile the following program with BC.EXE without /D:

       DIM A(10), B(10)
       A(9) = 1
       A(10) = 2
       PRINT B(-1)  'the value printed is 2, which is value of A(10)
       PRINT B(-2)  'the value printed is 1, which is the value of A(9)
       END

       Since BASIC may move items around in memory, the above results
       might not occur if there were other operations between the
       assignment statements and the PRINT statements.

 2. QuickBASIC checks subscript range validity when the /D switch is
    on, or when the Debug option is selected in the editors in Versions
    2.x and 3.00.


 5. List of BASICs Using MBF versus IEEE Floating-Point Format

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 14-FEB-1991    ArticleIdent: Q11936

 This article lists which BASIC versions (for MS-DOS) use Microsoft
 Binary Format (MBF) and which versions use IEEE format for storing
 single- and double-precision floating-point numbers.

 Single- and double-precision real numbers are stored in the Microsoft
 Binary Format (MBF) in the following languages:

 1. QuickBASIC versions 1.00, 1.01, 1.02, 2.00, 2.01, and the
    non-coprocessor QB.EXE version 3.00, for MS-DOS

 2. IBM and Compaq BASICA Interpreters (BASICA.COM) for MS-DOS

 3. GW-BASIC Interpreter versions 3.20, 3.22, and 3.23 (GWBASIC.EXE)
    for MS-DOS

 4. Microsoft BASIC Interpreter version 5.28 for MS-DOS

 5. Microsoft BASIC Compiler versions 5.35 and 5.36 for MS-DOS

 QuickBASIC versions 4.00, 4.00b, and 4.50 (QB.EXE, BC.EXE) and the
 coprocessor version of QuickBASIC version 3.00 (QB87.EXE) use IEEE
 floating-point format for single- and double-precision real numbers.

 Note that Microsoft Business BASIC Compiler versions 1.00 and 1.10 use
 a different floating-point format called Decimal Math. Decimal Math is
 very slow but has no rounding or representation errors because numbers
 are stored in their exact decimal form, instead of in an approximate
 binary form. (Sales of Business BASIC were discontinued.)

 In QuickBASIC version 3.00, the coprocessor version of QuickBASIC uses
 IEEE format numbers. Conversion routines are provided in version 3.00
 to convert between the MBF used in the non-coprocessor version
 (QB.EXE) and the IEEE floating-point format used in the coprocessor
 version (QB87.EXE).

 QuickBASIC versions 4.00, 4.00b, and 4.50, Microsoft BASIC Compiler
 versions 6.00 and 6.00b, and Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 only use IEEE format numbers, but
 conversion routines and a compiler switch are provided to convert
 between MBF and IEEE format. This conversion is necessary if you want
 to retrieve floating-point numbers from random access files that were
 created using MBF.

 References:

 For additional articles that discuss MBF and IEEE, search for the
 following words:

    floating and point and format and QuickBASIC


 6. "Bad File Name"; OPEN "COM1:"; 8 Data Bits Must Have No Parity

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified:  4-SEP-1990    ArticleIdent: Q12027

 When you use the OPEN "COM" statement with the data bits set to 8 and
 parity set to Even or Odd, you will get a "Bad File Name" error. For
 example, "Bad File Name" occurs at run time when you open the serial
 communications port as follows:

    OPEN "COM1:9600,E,8,1" AS 2

 This error disappears using 7 data bits, or No (N) parity.

 When you specify 8 data bits, you must specify a parity of N. This is
 a limitation in the design of QuickBASIC versions 1.00, 1.01, 1.02,
 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50; Microsoft BASIC Compiler
 versions 6.00 and 6.00b for MS-DOS and MS OS/2; and Microsoft BASIC
 PDS versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 As a workaround in QuickBASIC versions 4.00 and later, Microsoft BASIC
 Compiler versions 6.00 or 6.00b, or BASIC PDS, you can call a
 Microsoft C version 5.10 routine from BASIC to do the communications
 with 8 bits and odd or even parity. The following book will help in
 doing this:

    "Microsoft C Programming for the IBM" by Robert Lafore (published by
    the Waite Group)

 The QuickBASIC Compiler, BASIC compiler 6.00, and BASIC PDS 7.00 are
 designed with a 10-bit data frame for communications. The frame is as
 follows:

             1 2  -  8 9 A
             S DDDDDDD P S

 Bit  1     = Start Bit    (Always 1)
 Bits 2 - 8 = Data Bits    (7 or 8)
 Bit  9     = Parity       (Odd, Even, or None)
 Bit  A     = Stop Bit(s)  (1 or 2)

 The combination of the bits should add up to 10 bits. When you try to
 set 1 start + 8 data + 1 parity + 1 stop, that adds up to an 11-bit
 data frame, which BASIC is not designed for.


 7. CLEAR Should Not Be Used in Event Trap

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified:  4-JAN-1990    ArticleIdent: Q12074

 The presence of a CLEAR statement in the following event handling
 routine generates an "Illegal function call" error at compile time:

       CLEAR ,,800
       KEY(2) ON
       ON KEY(2) GOSUB 200
       WHILE INKEY$="" : WEND
       PRINT "this is a test"
       END
   200 CLEAR ,,800
       PRINT "this worked"
       RETURN

 The error occurs because the CLEAR statement changes the stack. The
 CLEAR statement is not allowed in an event handler because it would
 destroy the return address.


 8. How to Obtain Upper and Lower Bytes of an Integer

 Product Version(s): 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 28-DEC-1989    ArticleIdent: Q27097

 The following program demonstrates how to obtain the upper and lower
 bytes of an integer. The following is sample code:

 CLS
 a% = &HA0B0
 ah% = (a% AND &HFF00) \ 256 AND &HFF   'Note: "\" means integer division
 al% = a% AND &HFF
 PRINT HEX$(ah%)                 'Prints upper bytes: A0
 PRINT HEX$(al%)                 'Prints lower bytes: B0

 This information applies to Microsoft QuickBASIC 4.00 4.00B and 4.50
 for MS-DOS, to Microsoft BASIC Compiler 6.00 and 6.00B for MS-DOS and
 MS OS/2, and to Microsoft BASIC PDS Version 7.00 for MS-DOS and MS
 OS/2.


 9. No Error Listing File in QB 2.00; Error-Only File in 2.01/3.00

 Product Version(s): 2.00 2.01 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 19-OCT-1989    ArticleIdent: Q12243

 QuickBASIC Version 2.00 cannot list compiler errors to a file when
 compiling from the DOS command line (outside the QB.EXE editor) (see
 "Separate Compilation Method" in Appendix D of the "Microsoft
 QuickBASIC Compiler" Version 2.0 and 3.0 manual). This means that all
 debugging must be done in the QB.EXE Version 2.00 editor.

 In contrast, earlier versions of QuickBASIC (1.00, 1.01, and 1.02)
 give a listing (.LST) file that includes all source lines and flags
 those lines that have errors.

 Versions 2.01 and 3.00 have enhanced the Separate Compilation Method
 so that you can redirect compiler error messages to a file or device.
 If you compile from a DOS batch (.BAT) file, this feature allows you
 to automatically report the errors to an output file. For example:

    Command Line               Action
    ------------               ------

    QB TEST.BAS;               Compile TEST.BAS and display any errors
                               encountered on the screen.

    QB TEST.BAS; > TEST.LST    Compile TEST.BAS and redirect any error
                               messages generated to the file TEST.LST.

    QB TEST.BAS; > PRN         Redirects output to the DOS printer device.

 Only the lines in error and their associated error messages are sent
 to the screen or output file in 2.01 and 3.00. Source lines that don't
 have errors aren't listed.

 As there is no full-source-listing (.LST) output feature in QuickBASIC
 Versions 2.00, 2.01, and 3.00, there is also no compiler /A option to
 output the assembler translation of the BASIC code. The compiler /A
 option is supported only in QuickBASIC Versions 1.00, 1.02, 1.02,
 4.00, 4.00b, and 4.50.


 10. Explanation of String Space Garbage Collection; FRE Function

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q12337

 This article discusses three topics regarding string space
 compression:

 1. When QuickBASIC compresses string space during execution of a
    program

 2. Whether disabling string space compression is possible

 3. Whether string descriptors are fixed in memory or if they move

 This information applies to Microsoft QuickBASIC 4.00 4.00B and 4.50,
 to Microsoft BASIC Compiler 6.00 and 6.00B, and to Microsoft BASIC PDS
 Version 7.00 for MS-DOS and MS OS/2.

 1. When a string variable is assigned a new value, the new string
    takes the next available memory in string space. The old string
    value is deallocated but takes up space until string space "garbage
    collection" occurs.

    A program compresses string space as part of "garbage collection"
    when deallocated strings fill up the 60,000 bytes of available data
    space and the program needs to reallocate a string variable or a
    temporary string variable. You can force string compression with
    the FRE function [PRINT FRE("")], but there is no other way to
    predict when it will occur. An OPEN or CLOSE of a file can also
    trigger garbage collection.

 2. There is no way to disable the automatic garbage collection. At
    the time garbage collection occurs, your program is out of memory,
    so that if you were to disable it, your program could not continue
    to execute.

    You can schedule garbage collection to some extent by using the FRE
    function before executing code where you do not want garbage
    collection to occur, but if memory is tight, garbage collection may
    occur again anyway.

 3. String descriptors are the first bytes of each string, and they
    move as the strings move.


 11. Sperry PC BASIC's SCREEN B Is Not Supported

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 28-DEC-1989    ArticleIdent: Q21792

 QuickBASIC does not support the SCREEN B statement found in the BASIC
 sold by Sperry with its PC/IT. This information also applies to
 Microsoft BASIC Compiler Versions 6.00 and 6.00b and to Microsoft
 BASIC PDS Version 7.00.


 12. No Support for More Than Two Communications Ports in BASIC

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 26-MAR-1990    ArticleIdent: Q21789

 QuickBASIC does not support more than two communications ports.
 QuickBASIC supports only the devices COM1 and COM2. Some computers
 supply COM3 and COM4 devices, but these are not supported in compiled
 BASIC. This information applies to Microsoft QuickBASIC Versions 1.00,
 1.01, 1.02, 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50; to Microsoft
 BASIC Compiler Versions 6.00 and 6.00b; and to Microsoft BASIC
 Professional Development System (PDS) Version 7.00.

 To access COM3 and COM4, it may be possible for compiled BASIC to call
 third-party library routines, which are listed in catalogs such as the
 "Programmer's Connection Buyer's Guide," which can be obtained by
 calling [phone] in the United States; [phone] in Canada;
 or [phone] for the Customer Service department. Using this
 catalog, you may wish to contact the company Software Interphase at
 401) 274-5465, for example, to determine if its product QuickComm
 supports COM3 and COM4 called from Microsoft compiled BASIC.

 When purchasing add-on products, make sure the vendor has tested its
 product under your version of BASIC. For a list of other catalogs,
 query on the following words:

    programmer and tool and catalog


 13. "/" Switches on the Wang PC

 Product Version(s): 1.00 1.01 1.02 2.00 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 17-FEB-1989    ArticleIdent: Q21795

 Problem:

 I cannot use compiler switches when I run BASCOM on a Wang PC. For
 example, BASCOM test.bas/E/D does not work correctly.

 Response:

 On some Wang PC models, you must use "-" instead of "/" for the
 QuickBASIC Version 1.x compiler switches.


 14. Compatibility with AT&T PC 6300: No SCREEN 100 or SCREEN B

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |  B_BasicCom
 Last Modified: 27-DEC-1989    ArticleIdent: Q21790

    In general, QuickBASIC works very well on the AT&T PC 6300
 computer. However, please note that in QuickBASIC Versions 2.x, 3.00,
 4.00, 4.00b, and 4.50 you must run QB with the /B option to see the
 QuickBASIC editor menus and help screens properly on the AT&T's
 monochrome monitor.
    The BASIC that comes with the AT&T PC 6300 has SCREEN B and SCREEN
 100 statements that are not supported in any version of QuickBASIC or
 IBM BASICA. However, QuickBASIC Version 4.00b has added a new screen
 mode, SCREEN 4, which is supported on the following machines:

    Olivetti Personal Computers, models M24, M28, M240, M280, M380
    AT&T 6300 Personal Computer series

    SCREEN 4 is a 640x400 graphics mode that allows you to specify one
 of 16 colors (0-15) as the foreground color. Use the SCREEN statement
 to select the mode and 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

    You must invoke QB with the /B option on the AT&T PC 6300 because
 the AT&T has a graphics card and a monochrome monitor installed.
 QuickBASIC can detect what graphics card is installed, but you have to
 tell it with the /B option that a monochrome monitor is installed.
 (Please read about the QB /B option on Page 72 of the "Microsoft
 QuickBASIC Compiler" manual for Versions 2.x and 3.00, or Page 49 of
 the "QuickBASIC Version 4.00: Learning and Using" manual.)
    The BASIC interpreter provided with the AT&T 6300 gives a cursor on
 graphics screens; however, there is no cursor in IBM BASICA or
 Microsoft QuickBASIC when working with graphics screens.
    On the AT&T machines, the communications ports ("COM1:" and
 "COM2:") produce errors such as "Device not available" in QuickBASIC
 Versions 1.00, 1.01, and 1.02. QuickBASIC Versions 2.x and later have
 had few reports of problems with communications on the AT&T PC 6300.


 15. Communications Device Buffer Size Can Be Set with /C: Switch

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21787

 The communications device receiving buffer size can be set with the
 /C: compiler switch. For example, in Versions 1.x, you can set the COM
 receiving buffer to 1000 bytes by compiling BASCOM/C:1000. This
 information needs to be added to Pages 46 and 176 in the "Microsoft
 QuickBASIC Compiler" documentation for Versions 1.x. Note that for
 Version 1.x, if you specify a buffer between 1 and 255 in QuickBASIC,
 you always get 255 bytes; in IBM BASICA Interpreter you get whatever
 buffer size you specify.

 In Versions 2.x and 3.00, the communications buffer must be set before
 invoking the editor. This action is done in a similar manner, for
 example, QB/C:xxxx, where xxxx represents the desired number of bytes.
 The command line method of compilation is also similar, but the
 command line ends with a semicolon (;), for example, QB program/C:xxxx;.

 In Versions 4.00, 4.00b, and 4.50, you may set the transmission buffer
 size as well as the receiving buffer size.


 16. Cannot Access FIELDed Variables After CLOSE in Compiled BASIC

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr B_BasicCom
 Last Modified: 15-MAR-1989    ArticleIdent: Q21815

 Problem:

 I cannot access FIELDed variables after I close the random access
 file. I am able to access the variables in IBM BASICA, but not in the
 QuickBASIC compiler.

 Response:

 This is a difference between the IBM BASICA Interpreter and the
 QuickBASIC Compiler.

 You must assign the FIELDed variables to unFIELDed string variables to
 access the data in the FIELD buffer after the file is closed.

 Note: If the file is closed, and a FIELD variable is used as an
 argument to a function, you may receive an "Illegal Function Call"
 message.

 This information needs to be added to Appendix A "Converting BASICA
 Programs to QuickBASIC" in the following manuals:

 1. "Microsoft BASIC Compiler Version 6.00 for MS OS/2 and MS-DOS:
    Learning and Using Microsoft QuickBASIC"

 2. "Microsoft QuickBASIC: Programming in BASIC Version 4.50"

 This information can also be added to Chapter 10,
 "Compiler-Interpreter Language Differences," of the "Microsoft
 QuickBASIC Compiler" Versions 2.0x and 3.00 manual.


 17. QB 4.50 SETUP.EXE Hanging Problem on Leading Edge Model D

 Product Version(s): 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | SR# S900510-44
 Last Modified: 27-JUL-1990    ArticleIdent: Q64099

 Two separate customers reportedly hung their Leading Edge Model D
 computers after executing the QuickBASIC version 4.50 installation
 program (SETUP.EXE on the Setup/Microsoft QB Express Disk) under DOS
 version 3.20. Microsoft could not duplicate this problem using either
 MS-DOS or PC-DOS version 3.20. The reported problem did not occur when
 the customers attempted installation with the next version of the
 operating system, DOS version 3.21, on their Leading Edge Model D
 computers.

 Please note that the SETUP.EXE program for QuickBASIC 4.50 is mostly a
 file-transferring program. To work around the problem above without
 upgrading DOS, you can set up QuickBASIC by simply copying the files
 directly from the original distribution disks.

 The QB Express program can also be copied and run from a hard disk. To
 run QB Express, copy all files on the root directory of the
 Setup/Microsoft QB Express disk. Then type LEARN to start QB Express.


 18. Support for IBM EGA and Hercules Graphics Cards

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21839

 This article describes which versions of QuickBASIC support the IBM
 EGA (Enhanced Graphics Adapter) Card and which versions support
 Hercules Monochrome Graphics Cards.

 EGA Support
 -----------

 QuickBASIC Versions 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50 support
 EGA through the use of SCREEN modes 7, 8, 9, and 10. QuickBASIC
 Versions 1.00, 1.01, and 1.02 do not support the EGA. The 43-line EGA
 mode is supported in the Editor and in the WIDTH statement in
 QuickBASIC Versions 3.00, 4.00, 4.00b, and 4.50. The EGA is also
 supported in OS/2 real mode and MS-DOS for programs compiled with
 Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS and MS
 OS/2, and Microsoft BASIC PDS Version 7.00. The EGA is not currently
 supported for BASIC programs that run in OS/2 protected mode.

 Hercules Support
 ----------------

 Microsoft QuickBASIC Versions 4.00 and later, the Microsoft BASIC
 Compiler 6.00 and 6.00B, and Microsoft BASIC PDS 7.00 all support the
 Hercules Monochrome Graphics Card, Hercules Graphics Card Plus,
 Hercules InColor Card, and cards that are 100 percent compatible with
 these cards. The following describes how Hercules cards are supported
 in QuickBASIC:

 1. Hercules graphics mode is SCREEN 3.

 2. Hercules text mode is SCREEN 0.

 3. With Hercules, you must use a monochrome monitor.

 4. You must load the Hercules driver (QBHERC.COM) before running your
    program. If the driver is not loaded, the SCREEN 3 statement gives
    an "Illegal function call" error message. Type "QBHERC" to load the
    driver.

 5. The text dimensions are 80x25 (9x14 character box); the bottom two
    scan lines of the 25th row are not visible.

 6. The resolution is 720x348 pixels, monochrome.

 7. SCREEN 3 supports two pages (0 and 1); SCREEN 0 used with Hercules
    supports only one page.

 8. The PALETTE statement is not supported.

 9. To make function calls to the Microsoft Mouse, you must follow
    special instructions for Hercules cards in the "Microsoft Mouse
    Programmer's Reference Guide." (This manual must be ordered
    separately; it is not supplied with either the QuickBASIC or the
    Microsoft Mouse packages.)

 The use of Hercules cards is also documented in the README.DOC file on
 the QuickBASIC Version 4.00, 4.00b, and 4.50 release disk, which
 supplements the Microsoft QuickBASIC Compiler documentation.


 19. Integer Overflow Handling in Compiler Differs from Interpreter

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-DEC-1989    ArticleIdent: Q21844

 Question:
    Why does the compiler give negative numbers or "Overflow" errors in
 intermediate calculations involving two integers, when the same program
 works correctly in the IBM BASICA and GW-BASIC Interpreters?
    The following program is an example of the problem:

    10 FOR I%=240 TO 300
    20 Z! = INT( 130 * I% )
    30 PRINT I%,Z!
    40 NEXT

    The above program will give incorrect negative results in
 QuickBASIC Version 1.x when I% exceeds 252 and Z! exceeds 32K
 (32,767).
    In QuickBASIC Versions 2.x and greater, you will get an "Overflow"
 error.
    The same program will run in GW-BASIC and IBM BASICA completely
 through to I%=300 and print the correct values for Z!.

 Response:
    The above program will work properly if you make the integer
 constant "130" into a single-precision constant ("130!" or "130.") or
 double-precision constant "130#" as shown in the following example:

    20 Z! = INT( 130! * I% )

    QuickBASIC Version 1.x should not give negative results when an
 integer overflow occurs. This problem was corrected in Version 2.x and
 later, in which you properly get an "Overflow" message.
    The QuickBASIC compiler handles integer overflow differently than
 the GW-BASIC and IBM BASICA Interpreters handle it.
    When the compiler compiles a mathematical expression, it has to
 decide at compile time how to most efficiently optimize the expression
 into machine language. When the compiler sees the intermediate
 calculation 130*I% in the above program, it decides to restrict it to
 integer limits at compile time because 130*I% is the product of two
 integers. Changing the intermediate expression to the product of an
 integer and a higher-precision constant or variable will prevent the
 overflow problem.
    The interpreters are able to dynamically make the decision at
 run time to convert 130*I% to a single-precision constant to avoid
 integer overflow. The disadvantage of dynamic handling is the slower
 speed of the interpreters when compared with the compiler.


 20. Duplicate Labels Can Only Be Separately Compiled             s

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 27-DEC-1989    ArticleIdent: Q21862

 Question:

 Can I use the same line numbers or line labels in different
 subprograms that are compiled in the same source file?

 Response:

 No, but you can use the same line numbers or line labels if the
 subprograms are separately compiled.

 Line numbers and labels are local to the compiled module in which they
 occur. Line numbers and labels must be unique within a given compiled
 module. You do not need to worry about duplicate labels in separately
 compiled modules.

 Note that using the REM $INCLUDE metacommand to include source code
 from a separate file is similar to putting the two sources into one
 file. Any files included at compile time with the REM $INCLUDE
 metacommand are considered as part of that module, and are included in
 the .OBJ file.

 This information needs to be added to Section 9.2.1, "Using Line
 Labels", on Page 160 of the "Microsoft QuickBASIC Compiler" manual for
 Versions 2.00, 2.01, and 3.00.


 21. CALL ABSOLUTE "Unresolved Subprogram Reference," "Not Defined"

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 27-DEC-1989    ArticleIdent: Q21899

 Problem:

 When I attempt to use the CALL ABSOLUTE statement in the QB.EXE
 editor, I get an "Unresolved Subprogram Reference" error message at
 compile time in QuickBASIC Versions 2.00, 2.01, and 3.00. I get a
 "Subprogram not defined" error message in QB.EXE in QuickBASIC
 Versions 4.00, 4.00b, 4.50.

 Response:

 For QuickBASIC Versions 4.00, 4.00b, 4.50
 -----------------------------------------

 The routine named ABSOLUTE is an external assembly language routine
 located in the QB.QLB Quick library (and in the QB.LIB linker
 library). To invoke CALL ABSOLUTE from within the QB.EXE 4.00, 4.00b,
 or 4.50 editor, you must invoke QB /L to load the QB.QLB Quick
 library. If you choose Make EXE File... from the Run menu, QuickBASIC
 then automatically links your program with QB.LIB.

 For QuickBASIC Versions 2.00, 2.01, 3.00
 ----------------------------------------

 The routine called ABSOLUTE is an external assembly language routine
 located in a file called USERLIB.OBJ in QuickBASIC Versions 2.00 and
 2.01, and in a file called ABSOLUTE.OBJ in Version 3.00. To CALL
 ABSOLUTE, you will need to build a user library containing ABSOLUTE's
 .OBJ file, or link your program directly to it, as in the following
 examples:

 1. To CALL ABSOLUTE from a user library in Versions 2.00 and 2.01, do
    the following:

       BUILDLIB USERLIB.OBJ,USELIB1.EXE;
       QB test.bas/L USELIB1.EXE;

    To LINK TEST.BAS to ABSOLUTE in Versions 2.00 and 2.01, do the
    following:

       QB test.bas;
       LINK test.OBJ+USERLIB.OBJ;

 2. To CALL ABSOLUTE from a user library in Version 3.00, do the
    following:

       BUILDLIB ABSOLUTE.OBJ,USELIB1.EXE;
       QB test.bas/L USELIB1.EXE;

    To LINK TEST.BAS to ABSOLUTE in Version 3.00, do the following:

       QB test.bas;
       LINK test.OBJ+ABSOLUTE.OBJ;


 22. QuickBASIC and BASIC Compiler 6.00 Support Only MS-NET, PC-NET

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21850

 The only network supported by QuickBASIC versions earlier than and
 including Version 4.50 is the MS-NET family, including IBM PC-NET.

 Microsoft BASIC Compiler Versions 6.00 and 6.00b and Microsoft BASIC
 PDS Version 7.00 also only support networks in the MS-NET family,
 including IBM PC-NET.


 23. FILES Statement Always Displays Name of Current Directory

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-DEC-1989    ArticleIdent: Q21809

 Problem:
    When I request a directory listing of a subdirectory other than the
 current directory using FILES "\subdir", I get the file list for the
 different subdirectory, but I get the name of the current directory
 displayed at the top. I expected the requested subdirectory name to be
 at the top.

 Response:
    The FILES statement in QuickBASIC is behaving in a manner
 consistent with BASICA and GW-BASIC Version 3.20. It is not likely that
 this behavior will change.


 24. 8087 Coprocessor Support for QuickBASIC

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-DEC-1989    ArticleIdent: Q21819

 Question:

 Does QuickBASIC support the 8087 or 80287 coprocessor?

 Response:

 QuickBASIC Versions 3.00 and later support the 8087 and 80287 coprocessor.

 The QuickBASIC Versions 1.x and 2.x do not support the 8087 chip.
 However, Hauppage Computer Works, New York (516-360-3827), may offer a
 library to which you can link to provide this support.


 25. Compatibility of Compiled BASIC with Microsoft Windows

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |  B_BasicCom
 Last Modified: 21-SEP-1990    ArticleIdent: Q21831

 This article discusses compatibility between Microsoft Windows and the
 following BASIC products and their compiled programs: QuickBASIC for
 the IBM PC, Microsoft BASIC Compiler versions 6.00 and 6.00b for
 MS-DOS, and Microsoft BASIC Professional Development System (PDS)
 versions 7.00 and 7.10 for MS-DOS and MS OS/2.

 Windows 3.00 Compatibility
 --------------------------

 If you use Microsoft Windows version 3.00 with the special 386
 enhanced mode, you can run a BASIC program in a text window, which you
 could not do in earlier versions of Windows. In 386 enhanced mode,
 BASIC programs can run as background processes in the text window. In
 earlier Windows releases, you could only run BASIC programs as
 full-screen processes. However, in both Windows 3.00 and in earlier
 versions, you cannot run the QB.EXE or QBX.EXE editor in a window; you
 must instead run QB.EXE or QBX.EXE as a full-screen process.

 In Windows 3.00 standard mode (WIN /r) and real mode (WIN /s), you can
 run a compiled program, QB.EXE, or QBX.EXE only as full-screen
 processes, which means that they won't run in the background. You
 cannot press the Windows key combinations CTRL+ESC or ALT+ESC to get
 out of the full-screen BASIC program. Furthermore, other Windows
 processes will be stopped while you run the full-screen process. You
 must terminate the BASIC program to return to Windows.

 Windows 1.x, 2.x Compatibility
 ------------------------------

 Compiled BASIC programs, QB.EXE, and QBX.EXE run only as "bad
 applications" in Microsoft Windows versions 1.x and 2.x. "Bad
 applications" require you to create a PIF (Program Information File)
 using the Windows PIFEDIT.EXE program. When you make a PIF for QB.EXE,
 QBX.EXE, or BASIC compiled programs, you need to specify that the
 program directly modifies the screen, the keyboard, COM1, COM2, and
 memory. QuickBASIC version 4.00, 4.00b, and 4.50 programs have been
 successfully tested under Microsoft Windows 1.x and 2.x.

 The QB.PIF or QBX.PIF file provided on the QuickBASIC 4.00, 4.00b, and
 4.50, BASIC compiler 6.00 and 6.00b, or BASIC PDS 7.00 and 7.10
 release disks can be studied in PIFEDIT.EXE as a guideline for making
 your own PIF files for your compiled .EXE programs.

 Neither QuickBASIC version 3.00 and its earlier versions nor Microsoft
 BASIC Compiler 5.36 or earlier versions have been tested under
 Microsoft Windows. Therefore, they may or may not run successfully as
 bad applications.


 26. Reserved Words Not Necessarily Implemented as Features

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 28-DEC-1989    ArticleIdent: Q21832

 This article discusses why some of the reserved words listed in the
 manual are not implemented in QuickBASIC. For example, LCOPY is not
 supported in QuickBASIC Version 1.00, 1.01, 1.02, 2.00, 2.01, 3.00,
 4.00, 4.00b, or 4.50 for MS-DOS, Microsoft BASIC Compiler Version
 6.00, 6.00b for MS-DOS and MS OS/2, or Microsoft BASIC PDS Version
 7.00 for MS-DOS and MS OS/2. Another case is where PALETTE and PALETTE
 USING were not supported in QuickBASIC Versions 1.x, but were added in
 Versions 2.00 and later.

 Keywords are reserved for reasons of compatibility with past, present,
 and future versions of Microsoft BASIC. A list of reserved words is
 provided to warn programmers not to use keywords used in past and
 present versions of Microsoft BASIC. Some words are on the list but
 not currently implemented or supported because these reserved words
 represent possible additions for future versions of BASIC.


 27. .EXE File Size Larger than Other BASIC Compilers

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 27-DEC-1989    ArticleIdent: Q21833

 Question:

 Why is an .EXE file compiled in QuickBASIC larger than an .EXE file
 compiled in the IBM Version 1.0 BASIC Compiler or the generic
 Microsoft MS-DOS BASIC Compiler Version 5.36?

 Response:

 QuickBASIC .EXE programs are larger because of added features and
 functionality. A program compiled with QuickBASIC will usually be
 larger than one compiled with older compilers.


 28. Last SOUND Truncated at End of Program

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 28-DEC-1989    ArticleIdent: Q21835

 Question:

 When I put SOUND statements at the end of the program and run the .EXE
 file, why is the sound truncated at the end?

 Response:

 When a program ends, the BASIC run-time system is exited, which
 immediately stops any SOUND whose duration exceeds the time taken to
 execute any remaining statements in the program. If you have
 QuickBASIC Version 2.00 or later, the problem will not occur in the
 editor environment, because the run-time system is still available.

 To give the program time to complete its SOUND statements, give the
 program something to do after the SOUND (a dummy loop for example) so
 that the SOUND has time to finish before the program terminates.


 29. Length of Strings, String Descriptors in Compiler, Interpreter

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom B_GWBasicI
 Last Modified:  1-AUG-1990    ArticleIdent: Q21836

 String variables in QuickBASIC versions 1.00 through 4.50 and in
 Microsoft BASIC Compiler versions 6.00 and 6.00b and in Microsoft
 BASIC Professional Development System (PDS) versions 7.00 and 7.10 can
 contain up to 32,767 characters (32K). Each variable-length string
 variable has a 4-byte string descriptor, which is composed of a 2-byte
 length followed by a 2-byte address.

 Fixed-length strings (which were introduced in QuickBASIC versions
 4.00 and later and in BASIC compiler 6.00 and later) do not have a
 string descriptor.

 For comparison, variable-length string variables in Microsoft GW-BASIC
 (versions 3.20, 3.22, 3.23) and IBM BASICA Interpreters have 3-byte
 string descriptors, with 1 byte of length followed by 2 bytes of
 address. String variables may contain up to 255 characters in GW-BASIC
 and IBM BASICA.


 30. Maximum Number of Records in a Random Access File

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 22-JAN-1990    ArticleIdent: Q21811

 Question:

 What is the largest number of records that I can use in a random
 access file?

 Response:

 The maximum relative record number for QuickBASIC Versions 3.00 and
 earlier is 16,777,215 (16 megabytes).

 QuickBASIC Version 4.00 is capable of handling up to 2 to the 31st
 power minus 1 (or 2,147,483,647), but DOS limits you to 32 megabytes
 of one-byte records.

 For all versions of QuickBASIC, a record length cannot exceed 32,767
 bytes.

 DOS versions up to Version 3.30 and OS/2 Version 1.00 limit you to a
 total file size of 32 megabytes, or 32,768,000 bytes. The following
 are two examples of the maximum number of records allowed:

 1. 8.192 million records with 4 bytes each

 2. 2.048 million records with 16 bytes each


 31. WIDTH 40, WIDTH 80; "Illegal Function Call"

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 21-DEC-1988    ArticleIdent: Q21859

 Question:

 Why do I get an "Illegal Function Call" using a WIDTH statement with a
 width other than 40 or 80?

 Response:

 The WIDTH statement operates the same way in QuickBASIC as it does in
 the GW-BASIC Version 3.20 and IBM BASICA interpreters.

 To change the allowed width of screen output, you need to open the
 "SCRN:" device and output as follows:

   width "scrn:",11    ' Sets screen width to 11 characters.
   open "scrn:" for output as #1
   print#1, "123456789012345678901234567890"
   close


 32. < RESUME Linenumber > Is Not Allowed for Subprograms

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr
 Last Modified: 16-NOV-1988    ArticleIdent: Q21805

 Question:

 How can I use ON ERROR GOTO to trap errors that occur inside of
 subprograms separately compiled from the main program in QuickBASIC
 Versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00, and 4.00 for MS-DOS?

 Response:

 The following information should be added to the "Microsoft QuickBASIC
 Compiler" documentation for Versions 1.x, 2.x, and 3.00:

 Error handling in separately compiled subprograms should be coded in
 the following fashion:

    SUB test STATIC
    ON ERROR GOTO errortrap
       ' body of subprogram
    END SUB
    errortrap:
       ' The error is handled here:
       PRINT "Error Number Trapped="ERR
       RESUME NEXT

 In QuickBASIC Versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00, and 4.00,
 the ON ERROR GOTO Label statement must be established for each module;
 otherwise, an error occurring in that module will not be trapped, and
 the program will stop. In QuickBASIC Versions 4.00 and earlier, error
 handling routines are local to each separately compiled module. A
 given error handling routine serves all subprograms that are compiled
 in the same module. To trap errors, the ON ERROR GOTO statement should
 appear in each subprogram that is compiled separately from the main
 module.

 In contrast to earlier versions, QuickBASIC Versions 4.00b and 4.50,
 and the Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS
 and MS OS/2 offer global handling of ON ERROR (as explained in the
 UPDATE.DOC disk file). With global error-handling, an ON ERROR handler
 in the main program handles errors occurring in separate modules when
 those modules do not have their own ON ERROR handlers.

 All versions of QuickBASIC do not allow you to use < RESUME
 linenumber > or < RESUME linelabel > to handle errors that occur in
 subprograms. QuickBASIC only allows the use of RESUME or RESUME NEXT
 with subprograms. This fact needs to be added to Pages 128 and 129 of
 the "Microsoft QuickBASIC Compiler" documentation for Versions 2.x and
 3.00.

 In Version 1.02, if a < RESUME linenumber > or < RESUME linelabel >
 statement is used in a separately compiled subprogram, an "SB"
 (subprogram) error displays, but an OBJ file still will be created.
 You should not LINK the OBJ file if it receives an "SB" error, or if
 it uses < RESUME linenumber > or < RESUME linelabel > with
 subprograms. If you did use the file, you could receive unpredictable
 errors at run time due to eventual stack overflow.

 QuickBASIC Versions 2.00 and later will properly give you a
 "Subprogram Error" message and will not produce an OBJ file if you use
 < RESUME linenumber > or < RESUME linelabel >.

 Note also that < RETURN linenumber > or < RETURN linelabel > is not
 allowed with "ON event GOSUB" trapping used with subprograms; only
 RETURN is allowed. This fact applies to ON TIMER GOSUB, ON KEY GOSUB,
 ON PLAY GOSUB, ON STRIG GOSUB, and ON PEN GOSUB. Event trapping should
 be structured similar to error trapping in the sample program above.

 For a related article, you may query on "subprogram module error
 resume QuickBASIC" in this database.


 33. Passing Variables to ON ERROR and ON Event Handlers

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21863

 This article discusses how a QuickBASIC program can I pass variables
 to ON ERROR and ON "event" handler routines compiled with subprograms
 that are separate from the main program.

 (The different ON "event" statements are ON TIMER GOSUB, ON KEY GOSUB,
 ON PLAY GOSUB, ON STRIG GOSUB, and ON PEN GOSUB.)

 This information applies to Microsoft QuickBASIC 1.00 1.01 1.02 2.00
 2.01 3.00 4.00 4.00B and 4.50, to Microsoft BASIC Compiler 6.00 and
 6.00B, and to Microsoft BASIC PDS Version 7.00 for MS-DOS and MS OS/2.

 Variables can be passed through the COMMON SHARED statement to ON
 ERROR and ON "event" handler routines compiled separately from the
 main program. Variables that are not in COMMON SHARED are not
 accessible to the handler routines (unless the handler is in the same
 source file as the main program).

 The following is an example of a separately compiled subprogram that
 shares a flag variable with its error handler routine:

    ' TEST.BAS
    COMMON SHARED FLAG
    errortrap:
       ' The error is handled here:
       PRINT "Error Number Trapped="ERR
       FLAG=5
       RESUME NEXT  ' Resumes to line after where error occurred.
    SUB test STATIC
    ON ERROR GOTO errortrap
    FLAG=0
    ERROR 5  ' Forces a test error number 5 to occur.
    PRINT "FLAG=",FLAG  ' Execution resumes here after the error.
    END SUB

 This program is called by the following separate main program module:

    ' MAIN.BAS
    CALL TEST

 First, compile as follows:

    BC MAIN/X;
    BC TEST/X;

 You then can LINK MAIN+TEST; run the resulting program as an example.

 You cannot use the linenumber or linelabel option of RETURN or RESUME
 in conjunction with subprograms.

 In QuickBASIC Versions 1.00, 1.01, 1.02, 2.00, 2.01, 3.00, and 4.00,
 error and event handling routines are local to each separately
 compiled module. A given error or event handling routine serves all
 subprograms compiled in the same module. The ON ERROR GOTO or ON event
 GOSUB statement should appear in each subprogram that is compiled
 separately from the main program.

 QuickBASIC Versions 4.00b and 4.50, Microsoft BASIC Compiler Versions
 6.00 and 6.00b, and Microsoft BASIC PDS Version 7.00 offer global
 error handling, which is described in a separate article. For more
 information, query on the following words:

    global and error and handling and QuickBASIC


 34. COMSPEC; SHELL "Illegal Function Call", Can't Find COMMAND.COM

 Product Version(s): 1.00 1.01 1.02 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21901

 Customers who have floppy disk drive systems frequently find that the
 SHELL command fails in the QuickBASIC editor or in a program running
 on the system because QuickBASIC cannot find COMMAND.COM.

 Note that the SHELL command will work reliably only under DOS Version
 3.00 or later.

 Failure to locate COMMAND.COM during a SHELL can generate one of the
 following errors:

 1. The error message "File not found"

 2. The error message "Could not load COMMAND.COM"

 3. The error message "Illegal Function Call"

 4. A refusal to SHELL

 A program needs to find COMMAND.COM before it can execute a SHELL
 statement. The SHELL command in the File menu in the editor in
 QuickBASIC Version 2.00, 2.01, 3.00, 4.00, 4.00b, or 4.50 also needs
 to find COMMAND.COM before executing.

 QuickBASIC looks first for COMMAND.COM in the directory specified by
 the system COMSPEC environment variable and then in the current
 directory.

 The COMSPEC environment variable can be set by the MS-DOS SET command
 in your AUTOEXEC.BAT file or in the MS-DOS command line, as follows:

    SET COMSPEC=drive:\directory

 To tell MS-DOS where to find COMMAND.COM, you can also specify the
 following command in your MS-DOS Version 3.20 CONFIG.SYS file (which
 is executed at boot time):

    SHELL=A:\COMMAND.COM /E:1000 /P

 In the above command, /E:size sets the size (in bytes) for MS-DOS
 environment space, and /P tells the command processor that it is the
 first program in the system so that it can process the MS-DOS EXIT
 command. This SHELL= statement may not work under MS-DOS Version 3.30,
 but works properly under MS-DOS Version 3.20. Under MS-DOS Version
 3.30, you need to use SET COMSPEC.

 This article applies to QuickBASIC Versions 2.00, 2.01, 3.00, 4.00,
 4.00b, and 4.50 for the IBM PC and compatibles, Microsoft BASIC
 Compiler Versions 6.00 and 6.00b for MS-DOS, and Microsoft BASIC PDS
 Version 7.00 for MS-DOS.


 35. EGA 43-Line Mode Supported in QuickBASIC Version 3.00 Editor

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 24-JAN-1990    ArticleIdent: Q21911

 This article discusses which versions of QuickBASIC will display EGA
 43-line mode in the editor or "environment."

 QuickBASIC Versions 2.00, 2.01, and earlier do not support EGA 43-line
 mode.

 QuickBASIC Versions 3.00 and later do support EGA 43-line mode. The
 MODE43.EXE program can be run in DOS to toggle 43-line mode on or off
 before running QuickBASIC.

 In Versions 4.00 and later, an /h option for QB has been added to
 automatically display the highest resolution possible on your
 hardware. For example, if you have an EGA card, QuickBASIC displays 43
 lines and 80 columns of text when you type the following at the DOS
 prompt:

    QB DEMO1.BAS /H

 As with QuickBASIC Version 3.00, a compiled program itself can also
 put the screen into 43-line mode on an EGA-equipped computer by using
 the WIDTH statement. The 43-line mode syntax for WIDTH is documented
 in the README.DOC file for QuickBASIC Version 3.00, in the BASIC
 language reference for QuickBASIC Versions 4.00, 4.00b, and 4.50, and
 also in the QB Advisor in Version 4.50.


 36. Beep When Editing INPUT or LINE INPUT Statement Responses

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21915

 This article explains why the UP, DOWN, PGUP, and PGDN cursor keys
 produce a beep when editing what is typed in response to the INPUT or
 LINE INPUT statement at run time.

 The input editor used by INPUT and LINE INPUT is a line editor only.
 This means you can move and edit only horizontally, such as with the
 LEFT and RIGHT ARROW cursor-control keys and the BACKSPACE key.
 Attempts to use the UP, DOWN, PGUP, and PGDN cursor keys produce a
 beep.

 This information applies to Microsoft QuickBASIC 2.00 2.01 3.00 4.00
 4.00B and 4.50, to Microsoft BASIC Compiler 6.00 and 6.00B, and to
 Microsoft BASIC PDS Version 7.00 for MS-DOS and MS OS/2.


 37. CIRCLE Starting Angle of -0 Does Not Draw Line from Center

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 29-DEC-1989    ArticleIdent: Q21947

 In SCREEN 1 or 2 (or a higher graphics mode such as SCREEN 8), a
 CIRCLE statement with a start or end angle value of negative zero (-0)
 does not generate a line from the circle edge to the center in
 QuickBASIC Versions 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50, Microsoft
 BASIC Compiler Versions 6.00 and 6.00b for MS-DOS, and Microsoft BASIC
 PDS Version 7.00. It does generate the line in BASICA or GW-BASIC
 Version 3.20.

 The following is an example:

    10 SCREEN 1
    20 X=0
    25 REM  Radius=100, -x=start angle, 1=end angle:
    30 CIRCLE (160,100),100,,-X,1

 A workaround is to use x=.00001 instead of x=0 in the above program,
 as follows:

    10 SCREEN 1
    20 X=.00001
    30 CIRCLE (160,100),100,,-X,1

 Microsoft considers this to be an acceptable difference between the
 QuickBASIC Compiler and the BASIC interpreters.


 38. ENVIRON Statement Produces "Out of Memory" Error Message

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | b_basiccom
 Last Modified: 29-APR-1990    ArticleIdent: Q21963

 Most forms of the ENVIRON statement produce the run-time error message
 "Out of memory" (on DOS Versions 2.x through 3.30). The following
 example produces the "Out of memory" error message:

    ENVIRON "PATH=C:\COBOL"

 The following example usually works correctly, however, the ENVIRON
 statement is not very practical in QuickBASIC:

    ENVIRON "PATH=;"

 Expanding the environment table cannot be done in a QuickBASIC program
 because the size of the environment table is limited to its size
 rounded up to the nearest multiple of 16 bytes, when QuickBASIC or a
 QuickBASIC program is initiated.

 QuickBASIC does not modify the actual DOS environment table; it only
 modifies a local copy.

 You can work around this problem by doing the following:

 1. SET a large string in the MS-DOS environment table before running
    QB.EXE or a compiled program, as in the following example:

    SET JUNK=123456789012345678901234567890

 2. Use the following ENVIRON statements in your program to set the
    large string equal to a null string, then you can allocate strings
    whose length totals up to the size that was deallocated:

    PRINT ENVIRON$("JUNK")  ' DOS environment variables MUST be
                            ' uppercase.

 ENVIRON "JUNK=;"           ' This deallocates environment table
                            ' space.

 PRINT ENVIRON$("JUNK")     ' This confirms deallocation; prints
                            ' nothing.

 ENVIRON "TEST=C:\COBOL"    ' This sets up new environment string.

 PRINT ENVIRON$("TEST")     ' This displays the new environment
                            ' string.

    Note that the MS-DOS environment variable names must be uppercase.


 39. "Subscript Out of Range" Dimensioning a Dynamic Numeric Array

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 11-JAN-1990    ArticleIdent: Q21964

 Problem:
    I can dimension a single-dimensional dynamic integer array with
 32,000 elements; however, I get the message "Subscript Out of Range"
 dimensioning a two-dimensional integer array with only 30,000
 elements. The following is an example:

    Rem $dynamic
    dim b%(32000) 'this is okay
    dim c%(10,2850) 'this is also okay
    dim a%(10,3000) ' this will give a "subscript out of range" error

 Response:
    The statement DIM A%(10,3000) exceeds the 64K size limit that
 exists for each dynamic numeric array. In QuickBASIC Version 4.00 and
 greater, you can compile with QB /AH or BC /AH to allow dynamic
 numeric (or fixed-length string) arrays to exceed 64K. The /AH switch
 is not implemented in QuickBASIC 3.00 and previous versions.
    An array dimensioned DIM B%(32000) actually has 32,001 elements
 because the counting begins at element 0 by default, and the array
 will take up 64,002 bytes, since there are two bytes per integer
 element.
    You may change the default starting element to 1 with the OPTION
 BASE 1 statement. An array dimensioned DIM C%(10,2850) actually has
 31,361 elements (11 multiplied by 2,851) which would take up 62,722
 bytes. An integer array dimensioned (10,3000) gives a "subscript out
 of range" error because it has 33,011 elements, or 66,022 bytes, which
 exceeds the dynamic numeric array size limit of 65,536 bytes (64K).
    Note that there are 1,024 bytes per Kilobyte (K), therefore 64K
 multiplied by 1024 bytes per Kilobyte equals 65,536 bytes.


 40. ON KEY Trap Fails If CAPS/NUM LOCK Active; Need Separate KEY

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom docerr
 Last Modified: 15-JAN-1990    ArticleIdent: Q21987

 This article describes a necessary addition to the "Microsoft
 QuickBASIC Compiler" manual for Versions 2.00, 2.01, and 3.00. This
 information is already covered in the documentation for QuickBASIC
 Versions 4.00, 4.00b, and 4.50, Microsoft BASIC Compiler Versions
 6.00, 6.00b, and Microsoft BASIC Professional Development System (PDS)
 Version 7.00. The information below also applies to these versions.

 Key trapping does not function while the CAPS LOCK key or NUM LOCK key
 is activated, unless you specifically set up special user-defined keys
 for that key combination. The program below (and the similar program
 on Page 317 of the "Microsoft QuickBASIC Compiler" manual for Versions
 2.00, 2.01, and 3.00) demonstrates the ignored key trapping when CAPS
 LOCK or NUM LOCK is active.

 The following program correctly traps CTRL+C when CAPS LOCK and NUM
 LOCK are NOT active, but does NOT trap CTRL+C if either CAPS LOCK or
 NUM LOCK (or both) is activated:

    key 15,chr$(&H04)+chr$(&H2E)
    key(15) on
    on key(15) gosub test
    while x$<>chr$(27)
    x$=inkey$
    if x$<>"" the print x$,asc(x$)
    wend
    end
    test:
    print "Control-C has been trapped"
    return

 This behavior is not a problem in the compiler. The following notes
 should be added to Page 317 of the "Microsoft QuickBASIC Compiler"
 manual for Versions 2.0x and 3.00; these notes also apply to
 QuickBASIC Versions 4.00, 4.00b, and 4.50, BASIC Compiler Versions
 6.00, 6.00b, and BASIC PDS Version 7.00.

 To trap the desired key in combination with the CAPS LOCK or NUM LOCK
 key active, a different keyboard flag must be used for each
 combination. A value of &H20 hex must be added to the keyboard flag if
 you want to trap a key while the NUM LOCK key is down. An &H40 must be
 added to the keyboard flag if you want to trap a key while the CAPS
 LOCK key is down. For example, a KEY 16 can be added to the above
 program to trap CTRL+C while the CAPS LOCK key is down, as in the
 following:

    KEY 16, CHR$(&H44)+CHR$(&H2E)
    ON KEY (16) GOSUB TEST

 The &H44 above reflects the sum of &H40 (for CAPS LOCK active) and
 &H04 (the keyboard flag for CTRL).

 A KEY 17 can be added to the above program to trap CTRL+C when both
 CAPS LOCK and NUM LOCK are pressed down, as in the following:

    KEY 17, CHR$(&H64)+CHR$(&H2E)
    ON KEY (17) GOSUB TEST

 The keyboard flag &H64 above reflects the sum of &H40 (for CAPS LOCK
 active), &H20 (for NUM LOCK active), and &H04 (the keyboard flag for
 CTRL).


 41. Using Page 2 in SCREEN 9 Gives "Illegal Function Call" on EGA

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JAN-1990    ArticleIdent: Q21956

 Question:

 Why do I get an "Illegal Function Call" error message when I reference
 Page 2 in SCREEN mode 9 on a computer with an EGA card? The following
 is an example:

    SCREEN 9,1,2,2  'EGA mode=9, 1=colorswitch on, apage=2, vpage=2
    COLOR 2,0
    LINE (1,1)-(100,100)

 Response:

 Screen 9 does have two pages available, but the pages are referenced
 as "0" and "1". Note that "2" is not a valid page number in screen 9.
 The program will work correctly if coded as follows:

    SCREEN 9,1,1,1  'EGA mode=9, 1=colorswitch on, apage=1, vpage=1
    COLOR 2,0
    LINE (1,1)-(100,100)


 42. CTRL+BREAK Doesn't Break Program on Tandy 1000; Use CTRL+HOLD

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 11-JAN-1990    ArticleIdent: Q21973

 On a Tandy 1000, running a program from the QuickBASIC editor, the
 CTRL+BREAK key sequence does not break execution of the program.

 This is not a problem with QuickBASIC but is rather a nonstandard
 keyboard sequence on the Tandy 1000. CTRL+HOLD should be used instead
 of CTRL+BREAK on a Tandy 1000. This also applies to the Tandy 1000 SX.

 This information applies to the QB.EXE environment in Microsoft
 QuickBASIC Versions 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50 for
 MS-DOS, to QB.EXE in Microsoft BASIC Compiler Versions 6.00 and 6.00b
 for MS-DOS, and to QBX.EXE in Microsoft BASIC PDS Version 7.00 for
 MS-DOS.


 43. SCREEN 1 COLOR Yellow Is Brown (Muddy) on EGA Versus CGA Card

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 11-JAN-1990    ArticleIdent: Q21969

 The following program, which uses the COLOR statement on SCREEN 1, may
 give different colors on a machine with an EGA card compared to the
 colors on a machine equipped with a CGA card:

    10 SCREEN 1
    20 COLOR 8,0
    30 LINE (30,100)-(40,150),3,bf
    40 LINE (10,40)-(60,100),2,bf
    50 LINE (100,100)-(130,130),1,bf

 The background color selected is dark gray (8). Palette 0 is selected,
 and includes red, green, and yellow on a CGA. Under QuickBASIC on an
 EGA card, the colors may appear "muddy" compared to running on a CGA
 card: the red and green are less intense than shown on a CGA card and
 the yellow is brown.

 This is not a problem with QuickBASIC, but is a difference between CGA
 and EGA cards. The EGA allows only nonintensified colors. The same
 colors occur on an EGA card in the Microsoft GW-BASIC Version 3.20,
 3.22, or 3.23 Interpreter on an EGA card.

 Note that in SCREEN 1 on an EGA or VGA, the PALETTE statement can
 change the color used by output from the PRINT statement, for example

    PALETTE 3,n

 where n can be a color from 0 to 15. On an EGA card, PALETTE 3,6
 (where 6 is brown) is the default. PALETTE 3,14 will make PRINT output
 appear in yellow.

 The PALETTE statement is not supported on CGA cards. On a CGA card,
 the color of text output with the PRINT statement can only be changed to
 one of two possible colors by changing the palette argument of the
 COLOR statement. For example

    COLOR b,p

 where b is the background color, and p (the palette) can be 0 or 1. If
 the p argument is 0, PRINT output displays in color number 6 (brown on
 an EGA, yellow on some CGA cards). If the p argument is 1, PRINT
 output displays in color number 7 (white). See the COLOR statement in
 the BASIC language reference documentation for more information.

 Graphics statements such as LINE and CIRCLE can use color (attribute)
 arguments 0, 1, 2, or 3 to allow simultaneous display of four colors
 at once (including the background) in SCREEN 1 on CGA, EGA, or VGA.


 44. SHELL Can Give "Out of Memory" Error or Fragment Memory

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 21-DEC-1989    ArticleIdent: Q21902

 Question:

 Why do I get an "Out of Memory" error when I use the SHELL statement
 or the Shell command?

 Response:

 The SHELL statement does not clean up or compress memory. If not
 enough contiguous memory is available (for example, if many CHAIN
 statements have been executed, or several dynamic arrays were
 allocated then erased), a SHELL statement may fail with an "Out of
 memory" error. This includes both the Shell command from the File menu
 and also the SHELL statement in a running program.

 Also, if you mistakenly install any TSR (terminate and stay resident)
 program during a SHELL command, you will fragment memory, which often
 results in an "Out of Memory" error. For example, if you run the
 QuickBASIC environment, choose the Shell command from the File menu,
 install a TSR, EXIT the Shell, Exit the QuickBASIC environment, and
 reinvoke the QuickBASIC environment from DOS, then you get an "Out of
 Memory" error immediately before you can do anything in the
 environment. You must reboot to unfragment DOS memory.

 This information applies to Microsoft QuickBASIC Versions 2.00, 2.01,
 3.00, 4.00, 4.00b, and 4.50, to Microsoft BASIC Compiler Versions 6.00
 and 6.00b for MS-DOS, and to Microsoft BASIC PDS Version 7.00 for
 MS-DOS.

 TSR programs should NEVER be installed during a SHELL statement or a
 Shell from the File menu. Examples of TSR programs are MSHERC.COM
 (from QuickBASIC 4.50) and QBHERC.COM (from QuickBASIC 4.00/4.00b and
 the BASIC compiler 6.00/6.00b).


 45. "Type Mismatch" Using TAB() Between PRINT USING Variables

 Product Version(s): 4.00 4.00b
 Operating System:   MS-DOS
 Flags: ENDUSER | buglist4.00 buglist4.00b fixlist4.50 B_BasicCom
 Last Modified: 22-JAN-1990    ArticleIdent: Q32968

 When using the TAB function between variables in the following PRINT
 USING and LPRINT USING statements, a "Type Mismatch" error displays in
 the QB.EXE Version 4.00 or 4.00b environment:

    PRINT USING "$$##.##";x;TAB(10);z
    LPRINT USING "$$##.##";x;TAB(10);z

 However, when run as an .EXE program, the above statements print
 successfully. They also run correctly in QuickBASIC Version 3.00,
 either in the editor or as an .EXE program.

 Microsoft has confirmed this to be a problem in QuickBASIC Versions
 4.00 and 4.00b and in the QuickBASIC editor provided with Microsoft
 BASIC Compiler Versions 6.00 and 6.00b for MS-DOS (buglist6.00,
 buglist6.00b). This problem was corrected in QB.EXE in QuickBASIC
 Version 4.50 and does not occur in the QBX.EXE environment of
 Microsoft BASIC Professional Development System (PDS) Version 7.00
 (fixlist7.00).

 Note: The documentation for PRINT USING and LPRINT USING does not say
 whether TAB is legal in the PRINT USING expressionlist. TAB should be
 avoided in PRINT USING statements because compatibility with future
 Microsoft BASIC versions cannot be guaranteed.

 The best workaround for the above problem is to avoid using the TAB
 function in the PRINT USING or LPRINT USING statement, as shown in the
 following examples:

 1. To output at a desired column, use spaces between the desired
    format strings, instead of using the TAB function, as follows:

       x = 12.34 : z = 56.78
       PRINT USING"$$##.##         $$##.##";x;z

 2. To position the cursor at a desired column, use the LOCATE
    statement before executing the PRINT USING statement, as in the
    following example:

       x = 12.34: z = 56.78
       LOCATE 2, 1
       PRINT USING "$$##.##"; x
       LOCATE 2, 10
       PRINT USING "$$##.##"; z

 Note: When you type the following statement in QB.EXE Versions 4.00 or
 4.00b, the editor automatically inserts the missing semicolon in front
 of z:

    PRINT USING "$$##.##";x;tab(10) z

 The program then usually runs correctly (without getting a "Type
 Mismatch" error) in QB.EXE.


 46. PLAY "N0" First Note of Rest Clicks Speaker in QuickBASIC

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom buglist3.00 buglist4.00 buglist4.00b buglist4.50
 Last Modified: 20-SEP-1990    ArticleIdent: Q22018

 In QuickBASIC, the PLAY statement can produce a click on the speaker
 for the first note of rest (but not for subsequent notes of rest). For
 example, the following program will produce no sound when run under
 the BASICA or GW-BASIC Interpreter, but produces a single click when
 run as a compiled QuickBASIC program:

    10 while inkey$ = ""
    20 play "N0"    ' N followed by zero (0) means play a note of rest.
    30 wend

 Microsoft has confirmed this to be a problem in QuickBASIC versions
 2.00, 2.01 (buglist2.00, buglist2.01), 3.00, 4.00, 4.00b, and 4.50; in
 Microsoft BASIC Compiler versions 6.00 and 6.00b (buglist6.00,
 buglist6.00b); and in Microsoft BASIC Professional Development System
 (PDS) versions 7.00 and 7.10 (buglist7.00, buglist7.10). We are
 researching this problem and will post new information here as it
 becomes available.


 47. XON/XOFF Communications Protocol Not Supported in QuickBASIC

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr B_BasicCom
 Last Modified: 17-JAN-1991    ArticleIdent: Q22019

 The XON/XOFF handshaking protocol of the ASC option of the OPEN COM
 statement is not implemented in any version of QuickBASIC (including
 versions 2.00, 2.01, 3.00, 4.00, 4.00b, and 4.50), in Microsoft BASIC
 Compiler version 6.00 or 6.00b for MS-DOS, or in Microsoft BASIC
 Professional Development System (PDS) version 7.00 or 7.10 for MS-DOS.

 Except for XON/XOFF protocol, the other features of the ASC option of
 the OPEN COM statement work properly. During communications, the ASC
 option expands tabs to spaces, forces carriage returns at the
 end-of-line, treats CTRL+Z (ASCII value 26) as the end-of-file flag,
 and transmits CTRL+Z when you CLOSE the communications channel.

 When you OPEN the COM1 or COM2 communications port and specify the ASC
 option, XON and XOFF bytes have no effect. A program will continue to
 transmit and pass all received XON and XOFF characters to the program
 without halting or resuming transmission. This behavior occurs because
 the XON/XOFF handshaking protocol of the ASC option of the OPEN COM
 statement is not implemented.

 The sentence saying "XON/XOFF protocol is enabled" should be deleted
 in the documentation for the ASC option of the OPEN COM statement in
 the following manuals:

 1. Page 375 of the "Microsoft QuickBASIC Compiler" manual for
    QuickBASIC versions 2.x and 3.00

 2. Page 297 of the "Microsoft QuickBASIC 4.0: BASIC Language
    Reference" manual for QuickBASIC versions 4.00 and 4.00b

 3. Page 297 of the "Microsoft BASIC Compiler 6.0: BASIC Language
    Reference" manual for versions 6.00 and 6.00b

 This documentation error has been corrected in the documentation for
 Microsoft QuickBASIC 4.50 and the BASIC Professional Development
 System (PDS) for MS-DOS and MS OS/2.

 Additional Background Information
 ---------------------------------

 XOFF is also known as CTRL+S, which is a character with an ASCII
 value of 19. CTRL+S tells a device or program that knows XON/XOFF
 protocol to stop transmission.

 XON is also known as CTRL+Q, which is a character with an ASCII value
 of 17. CTRL+Q tells a device or program that knows XON/XOFF protocol
 to continue transmission.

 The CTRL+S (XOFF) and CTRL+Q (XON) bytes pass without special handling
 through devices or programs that do not support the XON/XOFF
 communications protocol. While it is possible to write a BASIC program
 that checks every character for XON or XOFF and then programmatically
 starts or stops communications, such a program is unlikely to be as
 reliable as the XON/XOFF handshaking that is built into dedicated
 commercial communications software or hardware packages.


 48. SHELL "PATH=\..." Affects Only a Local Copy of DOS

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 31-JAN-1990    ArticleIdent: Q22015

 SHELLing to the DOS PATH command fails to change the default directory
 search path when you exit QuickBASIC. BASICA Version 3.10 behaves
 similarly.

 The following is an example:

    SHELL "PATH=\BASIC"

 According to Page 458 of the "Microsoft QuickBASIC Compiler" manual
 for Version 3.00 and Page 396 of the "Microsoft QuickBASIC Version
 4.0: BASIC Language Reference" manual, the SHELL statement allows
 execution of DOS commands such as DIR, PATH, and SORT.

 When you invoke a SHELL command from a QuickBASIC program, a local
 copy of COMMAND.COM and the DOS environment is spawned. When paths are
 changed, only the local environment copy is changed, not the original
 DOS environment.


 49. OPEN LEN=reclen Effect on Sequential File Buffering and Speed

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | docerr B_BasicCom
 Last Modified: 19-JAN-1990    ArticleIdent: Q22021

 QuickBASIC Versions 2.00, 2.01, and 3.00 don't behave according to the
 following statement on Page 370 of the "Microsoft QuickBASIC Compiler"
 manual for Versions 2.00, 2.01, and 3.00, which discusses the
 recordlength option of the OPEN statement for sequential files:

    When used to open a sequential file, recordlength specifies the
    number of characters to be loaded to the buffer before it is
    written to, or read from, the disk. A larger buffer means more room
    taken from BASIC, but faster file I/O.

 Changing the LEN=reclen statement will not change the sequential
 file-access speed or buffering for QuickBASIC Versions 2.00, 2.01, or
 3.00, but WILL change speed and buffering for QuickBASIC 4.00 and
 later versions.

 For greater file-access speed, boot with a BUFFERS=20 statement in
 your CONFIG.SYS file (DOS configuration file) on the root directory of
 your start-up disk.

 Please note that in QuickBASIC Versions 4.00, 4.00b, and 4.50 for
 MS-DOS, Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS
 and OS/2, and Microsoft BASIC Professional Development System (PDS)
 Version 7.00, the LEN=reclen statement changes both the buffer size
 and sequential file-access speed. The default sequential-access buffer
 size is 512 bytes in these versions.

 The 512-byte size gives fast disk input/output speed because it
 matches the sector size or a multiple of the sector size for most disk
 drives. This is correctly documented in the "Microsoft QuickBASIC 4.0:
 BASIC Language Reference" manual for Versions 4.00 and 4.00b.

 By changing LEN=256 to LEN=10 or LEN=1000 in the following program, no
 file-output buffering or speed changes are apparent in QuickBASIC 2.x
 and 3.00 when you watch the disk-access light on the drive. However,
 you will notice buffering and speed changes in later QuickBASIC
 versions:

    PRINT "Start of program"
    OPEN "buf.dat" FOR OUTPUT AS #1 LEN=256
    PRINT "File was just opened"
    WHILE INKEY$="":WEND
    FOR Index% = 1 to 30
    PRINT "Record number --> ";Index%
    WRITE #1, STRING$(79,CHR$(48+Index%))
    WHILE INKEY$="":WEND
    NEXT Index%
    CLOSE #1
    END


 50. PRINT Forces Contiguous String to Next Row & Doesn't Wrap It

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_GWBasicI B_BasicCom
 Last Modified: 19-JAN-1990    ArticleIdent: Q22022

 The PRINT statement displays a contiguous string constant on the next
 row below the current print position (without breaking or wrapping the
 string) if printing it from the current screen column exceeds the 80th
 column.

 This behavior is by design. You will need to break the string into a
 piece small enough to fit within the space before the 80th column to
 avoid forcing the whole string to the next line (see example below).

 This standard behavior occurs in most retail Microsoft BASIC versions
 for MS-DOS, including the following products:

 1. QuickBASIC Compiler (Versions 2.00, 2.01, 3.00, 4.00, 4.00b,
    and 4.50) for MS-DOS

 2. Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS and
    OS/2

 3. Microsoft BASIC Professional Development System (PDS) Version 7.00
    for MS-DOS and OS/2

 4. GW-BASIC Versions 3.20, 3.22, and 3.23

 The following is a code example:

    5  CLS
    10 LOCATE 1,1    ' LOCATEs in column 1.
    20 PRINT "LOCATED ON ROW 1, THIS STRING STAYS ON ROW 1."
    30 LOCATE 2,70    ' LOCATEs in column 70, leaving no room.
    40 PRINT "DESPITE BEING LOCATED ON ROW 2, THIS PRINTS ON ROW 3"
    50 LOCATE 4,71   ' To make it wrap, break up the string as follows:
    60 PRINT "1234567890";"THIS STARS IN COLUMN 1"


 51. SCREEN 7,8,9 "Illegal Function Call" Using Foreground COLOR 0

 Product Version(s): 2.00 2.01 3.00 4.00 4.00b 4.50
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 15-JAN-1991    ArticleIdent: Q22036

 Executing the COLOR statement with a zero (0) as the foreground color
 gives "Illegal Function Call" on the EGA SCREEN modes 7, 8, and 9. For
 example:

    10 SCREEN 9
    20 COLOR 0,0   ' Gives "Illegal function call"

 This is because zero (0) is not within the allowed range of attributes
 with the EGA. The range of attributes is 1 to 3 for an EGA with 64K,
 and 1 to 15 for an EGA with more than 64K of memory.

 You can work around this behavior by using the PALETTE statement to
 reassign the color of zero to another attribute number. This can be
 accomplished by doing the following:

    DIM Pal%(16)
    SCREEN 7
    Pal%(0) = 15
    Pal%(15) = 0
    PALETTE USING Pal%(0)
    COLOR 15,1
    CLS

 This information applies to QuickBASIC versions 2.00, 2.01, 3.00,
 4.00, 4.00b, and 4.50; to Microsoft BASIC Compiler versions 6.00 and
 6.00b for MS-DOS, and to Microsoft BASIC Professional Development
 System (PDS) versions 7.00 and 7.10 for MS-DOS.

 Another way to simulate a foreground color of zero (0) in screen mode
 9 or 12 is shown in a separate article in this Knowledge Base. To find
 this article, query on the following words:

    foreground and background and GET and PUT and 16 and simultaneously

 (The graphics GET and PUT technique and sample program shown in this
 separate article could be modified for QuickBASIC 2.0x and 3.00.)


 52. CTRL+UP and CTRL+DOWN ARROW Keys No Longer Scroll the Screen

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 22-JAN-1990    ArticleIdent: Q23388

 CTRL+UP ARROW and CTRL+DOWN ARROW do not scroll the screen in QB.EXE
 in QuickBASIC Version 3.00, but they do in QuickBASIC Versions 2.00,
 2.01, 4.00, 4.00b, 4.50, in the QB.EXE editor that is included with
 Microsoft BASIC Compiler Versions 6.00 and 6.00b for MS-DOS, and in
 the QBX.EXE editor of Microsoft BASIC Professional Development System
 (PDS) Version 7.00 for MS-DOS.

 Changes were made in the QuickBASIC Version 3.00 editor to allow
 Superkey support; support for CTRL+UP ARROW and CTRL+DOWN ARROW was
 removed during this change. In the non-3.00 product versions above,
 these keys successfully scroll the screen down or up one line at a
 time.


 53. Unexpected Result from CINT(.5) in QB87; IEEE Rounds to Even

 Product Version(s): 3.00
 Operating System:   MS-DOS
 Flags: ENDUSER | B_BasicCom
 Last Modified: 21-FEB-1991    ArticleIdent: Q23389

 The coprocessor version of QuickBASIC version 3.00 (QB87.EXE) returns
 0 (zero) in the following example (as do QuickBASIC versions 4.00,
 4.00b, and 4.50; Microsoft BASIC Compiler versions 6.00 and 6.00b; and
 Microsoft BASIC Professional Development System (PDS) versions 7.00
 and 7.10, which all use the IEEE floating-point format):

    PRINT CINT(1/2)
    PRINT CINT(.5)
    PRINT CINT(1.0/2.0)

 Three zeros (0) are printed. This differs from the non-coprocessor
 version of QuickBASIC version 3.00 (QB.EXE) and earlier versions,
 which instead prints three ones (1).

 Compare this with the fact that PRINT CINT(1.5) returns 2 in both the
 coprocessor and non-coprocessor versions of QuickBASIC version 3.00
 (and in the other more recent products listed above).

 The observed rounding difference in the first case above is not caused
 by any bug. The IEEE standard dictates that rounding of x.5 occurs to
 the even integer nearest to x, for example, CINT(.5)=0, CINT(1.5)=2,
 CINT(2.5)=2, CINT(3.5)=4, CINT(4.5)=4, etc.

 The non-coprocessor version of QuickBASIC 3.00 (QB.EXE) supports a
 different floating-point format, the Microsoft Binary format (MBF),
 which rounds differently than the IEEE standard.


 54. Workarounds for CLOSE of COM(n) Disconnecting Phone Connection

 Product Version(s): 4.00
 Operating System:   MS-DOS
 Flags: ENDUSER |
 Last Modified: 16-APR-1990    ArticleIdent: Q26471

 QuickBASIC disconnects the phone connection when a program CLOSEs the
 communications port or when the program ENDs. This happens because the
 DTR line is dropped on a CLOSE or END statement. Below are several
 possible workarounds that might help you to overcome this design
 limitation of Microsoft QuickBASIC.

 This information applies to Microsoft QuickBASIC Versions 4.00, 4.00b,
 and 4.50, to Microsoft BASIC Compiler Versions 6.00 and 6.00b for
 MS-DOS, and to Microsoft BASIC Professional Development System (PDS)
 Version 7.00 for MS-DOS.

 The first workaround is to attempt to reset the DTR line immediately
 after the CLOSE statement. To do this, the correct OUT instruction is
 sent to the modem control register to set DTR (pin 20) high. Consider
 the following example:

      OPEN "COM(n): <parameters>" FOR <mode> AS #n
      ' The rest of your program code goes here.
      CLOSE #n
      OUT &H3FC,3
      END

 However, this example may not work because there is a small period of
 time between the CLOSE and the OUT statements. The modem may
 disconnect the phone connection even in this small time period.

 Some "smart" modems allow you to adjust the time-out period for the
 DTR line. If you set this time-out period higher, the modem will wait
 longer before disconnecting the phone connection. This gives you just
 enough time to execute the OUT instruction to set the DTR line higher.
 The following is an example:

      OPEN "COM(n): <parameters>" FOR <mode> AS #n
      PRINT #n, <control string>
      ' The rest of your program code goes here.
      CLOSE #n
      OUT &H3FC,3
      END

 In the above example, <control string> is a series of control codes
 sent to the modem to set the DTR time-out period higher. Consult the
 manual for your modem to determine the correct control code string.
 The following is an example of the above code modified to work with a